It’s unlikely that you will read a more dull and despairing title for a practical blog series than “Document & Review”, and there is a high chance that you will even consider skipping this one. If you do, however, you will be missing the most foundational aspect of your entire information security programme. Without documentation primarily of Policies, Procedures and Guidelines, you have nothing to build your grand information security plan upon. Nothing to reference, fall back on or even educate people with.

Neil Postman, American author, educator, media theorist and cultural critic, summed it up:

“The written word endures, the spoken word disappears.”

If you want to build for the future, you must ensure your message, whatever that might be, endures over time and is easily understood and referenceable throughout its lifetime.

You may think this is obvious, and everybody knows there has to be documentation, as who hasn’t heard the refrain, “it’s in the policy, go read it!”? That said, subsequently pointing towards a meaningful policy document, procedure, or guideline only sometimes produces the results intended. Policies are overly long and descriptive. Procedures either repeat the policy or don’t exist, and the story is similar for Guidelines.

So, dear reader, here is the low down on what each of those terms means and their relationship to each other, laid bare and thoroughly before you:

The Policy

The policy is a high-level document that, after its first 6-12 months of existence, won’t change very often, perhaps every 3-5 years.

It defines the requirements of people, departments and the organisation without specifying the technology or specifics needed to make it happen. For example, here is a statement from a poorly written policy about email security:

“All email transmissions must be protected using the TLS 1.3 protocol to avoid unauthorised interception.”

A better policy statement would be:

“All email transmissions must be protected to avoid unauthorised interception.”

It is a simple change that gives the IT team the choice of a method of securing email that makes the most sense for them. Such policies (and, to a greater extent, the security team as a whole) are technology agnostic, focussing the policy on outcomes and not delivery methods.

Finally, for policies, focus on clear, understandable language that does not use TLAs* or other jargon; policies are designed for as broad a readership as possible and help support educational activities.

The Procedure

A procedure should follow naturally from the policies it supports in that it takes the required outcomes as laid out in the policy and then defines how it is to be achieved. For example, the definition of TLS 1.3 is precisely the information described in the procedure from the above example. Therefore a procedure has a more frequent update cycle, i.e. whenever technology or working practices change.

It’s important to note that “Policy” and “Procedure” are often used interchangeably, yet nothing could be further from the truth. A policy does not state how something is to be achieved, merely that it needs to be achieved. Additionally, a policy may be supported by multiple procedures.

The Guideline

A guideline is a document where the security function can get involved in the technology! It describes a best practice for implementing email. It may well define what version of TLS should be used along with other information about hardening the email server and will inform the reader accordingly. It does not have to be adhered to, and it is not mandatory to follow the guidance there. Dependent upon the culture of the company and the relationship between the security function and the rest of the company, it may also be defined as a Standard. In contrast to a guideline, the standard is a mandatory requirement and establishes minimum expected requirements for the activity/services it supports. A guideline and a standard may be used interchangeably, while the intent and adherence to them are different.

Good Practise

As you might expect, there are some good practices when managing this kind of documentation that should be adhered to:

Review Schedule

Fix a schedule and adhere to it. Every document should be reviewed at least once a year or whenever a significant change in technology, process or even culture occurs. Out-of-date documentation can slow a business down, inhibit innovation and mark the security team out as gatekeepers.

Version control

Always have version control, formal sign-off procedures and clear ownership and accountability of every document. It is an overhead that ensures any audit or review is passed with ease and warrants that the documentation is up to date and, more importantly, relevant.

Distribution

Policies should be made available to everyone. Liaise with the HR department, include them in the staff handbook, post them on the intranet and reference them accordingly. Procedures and guidelines will have a more limited audience, but make sure that the audience knows where they are.

Approvals

These documents should be approved at the appropriate levels, depending on the work environment. However, as a rule of thumb, policies should be approved by company leadership, procedures by department heads and guidelines/standards by the senior technical lead. In this way, there is a clear ownership hierarchy, and the documents create a support structure building upwards.

This sounds like a lot of work…

It is, especially in the early days of setting the work programme up, but its importance cannot be emphasised enough. Without these foundational documents, there is no linchpin to define and guide current and future activities and no frame of reference describing how individuals and the company should behave and work. Finally, there is no way of proving that the security function is meeting its goals and objectives as approved by the company leadership.

Define what you do and ensure your message will endure.

(I found this piece deep in the vaults at (TL)2 Towers, so I figured I would break my non-blogging streak.)

“Sensitive client code has been discovered on a GitHub repository, and it looks like one of our developers put it there. The client is upset, and their Chief Information Security Officer (CISO) wants to meet with you in New York to discuss what happened.”

Not the best email start to a Tuesday morning, I grant you, but I did at least have two things in my favour; six days before the meeting with the client and an excellent Cyber Incident Response Team (CIRT) headed up by a very talented and focussed individual based out of Miami. So I felt confident we could get to the bottom of the incident.

Fast forward to the following Monday afternoon (don’t worry, this isn’t a blog about cyber forensic investigations), and I am walking out to the cab back to the airport with a thankful, happy client and the promise of more billable work in the form of security testing.

It sounds like the beginning and end of two different stories, but this is a real example from back in 2016 during my tenure as a CISO. What initially felt like a nightmare scenario was quickly turned around, and three things became apparent very quickly:

1. Proper incident management is crucial because it is not a case of “if we have a data breach” nowadays but “when we have a data breach”.
2. Agile working methods are a double-edged sword; we get work done quickly and effectively, but if we are not careful, boy, can it bite us in the ass.
3. Focusing on the client, their perceptions, need for honesty, demands, and wishes are paramount.

I want to focus on 2 and 3 from above because let’s face it, incident management is often carried out by the cool-looking security folks who swoop in when it all goes wrong.

Is it Agile or FrAgile?

Agile working methodologies are, I am told, wonderful ways to get work done quickly and effectively. Flexible working, the heavy reliance on technologies, still often in early release stages and updated daily. You can reuse and share code through various repositories, test things out with the rallying cry of “Fail fast! Fail often!”, pull out your credit card and spin up servers on the other side of the world by the time the kettle has boiled or the coffee machine dripped its last drop.

The problem with this is that if we are not careful, the environment becomes the wild west, with code flying around various platforms containing hardcoded admin credentials and schematics shared openly as you struggle to squash that last bug with the help of the internet. (I am having palpitations just thinking about it.)

Sticking code up onto GitHub doesn’t make you agile; it makes you fragile. You must prepare and plan, work as a cohesive unit with your team and have established (and secure) ways of working with these new and funky tools that are not only effective but also in the best interests of the client.

The client is King AND Queen.

I recall another incident where a client contacted us to say they had found their code and credentials on a GitHub-type site. They were (unsurprisingly) very upset and demanded our response. Upon investigation, it turned out the data in question was uploaded there some two years earlier, was out of date, and the credentials were changed long ago anyway. It was severe, but we were off the hook with confirmation that third parties downloaded none of the data!

Famous last words. The client was livid.

The incident escalated to their board, and we were bought to task for the security lapse in no uncertain terms. However, we had forgotten one crucial thing in all of this; it wasn’t our data to lose in the first place. 

There is a saying in information security circles; “my risk model is not your risk model”. It means that what risks affect you are not the same as those that affect me. Precisely the mistake we made with this client. It didn’t matter that nothing had happened; it didn’t matter that the data and credentials were stale; we were sloppy and slapdash with their intellectual property. We had broken their trust.

In the middle of the high-pressure project environment, losing sight of what the client holds dear versus what you are trying to achieve in the here and now is easy.

Making the Leap

Do you need to address your agile working practises and understanding of your client’s motivations and risks? Here are two data points to consider:

1. A constant increase in the inclusion of unlimited liability clauses in your contracts. Right or wrong, they aren’t going away, and as you access more of a client’s sensitive and confidential data to “make digital work” for them, it will continue to do so.
2. When it happens, the cost of a data breach is increasing. According to the Ponemon Institute/IBM Security report “2019 Cost of a Data Breach Report – A comprehensive analysis of data breaches reported in 2018,” the average cost of data breaches has increased by 12%, a whopping $3.92M in the healthcare industry alone. You won’t get much change out of that for a satisfactory bonus pool.

When you leave your house in the morning, you lock your door, maybe enable an alarm system. When you leave your car, park it in a reputable garage and lock the door, immobilising the engine and setting the alarm.

Then you go to work and copy someone else’s confidential data and credentials to an open file share. Can you see the paradox?

Taking that leap in maintaining client confidence, assuring them of intelligent decision-making, agile (not fragile) working practises and mental rigour to maintaining their crown jewels is challenging. But it is essential.

Why did that first client give me more business after a breach? Demonstrating that we were in control of our processes and ensuring he and his risks were obviously the centre of our world helped: that and a high degree of transparency. But that initial breach was too high a price for extra business and a warm handshake.

Hands up if you have been to an in-person conference or summit since the middle of March this year. Yeah, me neither.

And so we saw the rapid build-up of the online webinar, starting from the first tentative steps made by the BBC’s Have I Got News For You, through to LinkedIn Live, Zoom based cabinet briefings being “hacked”, and the advent of the vanity backdrop. And there was much celebration amongst members of ISACA and (isc)2 as we could now still get CPE’s for sitting around drinking coffee and chatting with our infosec mates.

Some fo the first ones were, frankly, a little bit crap. Poor sound and video, and events organisers more used to managing people in person rather than at the end of a dodgy video link. But these were pioneering days, and let’s face it, we needed those CPEs. It didn’t take long for features to start pouring into platforms like Zoom, Teams, Discord, even Webex (used only by employees of Cisco and people trapped in a Cisco building), and other platforms like BrighTalk. Events people got better at putting them on and using the tools, and the quality went up. New tools (or tools that found a new audience) such as StreamYard and Livestoem have truly democratised the ability to produce slick online conferences with a big budget feel at pocket-friendly pricing.

But.

The rot is starting to seep in, and quickly too. It’s only been a few months as well.

For context since the beginning of this month (October) to the end of next month, I will have hosted over 30 hours of online events, mostly as a full-on Host but also as a panel moderator, and some poor behaviours are starting to seep in already.

So I present to you my Top Ten Webinar Peeves, from both sides of the screen

• Start on time. Even if some of your speakers are suffering from technical difficulties, start on time. You should always have a plan B anyway, or a host that can think on their feet quickly enough to engage the audience for the few extra minutes needed. Unlike a physical conference, you don’t have a captive audience. They will leave to do something else or assume it was cancelled last minute. Be on screen straight away and engage immediately.
• Finish on time. Or slightly earlier. Never overrun. Your attendees are busy people and have meetings and places to be. Again, they are not a captive audience with the promise of a free drink or six at the end of the show and will leave the session at the published time. This means any closing remarks, thanks to sponsors or calls to action will be lost, and the benefit of the session in the first place significantly reduced.
• Test the platform upfront. There are so many different platforms out there now, all with their own quirks and foibles. Each one has a different workflow to share your screen to give a presentation or require an upload prior to the session. Others require a certain browser to work properly, and they all seem to handle audio devices in different ways. Get it sorted upfront.
• Position your camera properly. Everybody’s home setup is different, but there are basics that need to be observed. Don’t sit with a window or other light source right behind you as it will darken your image such that you can’t be seen. Can’t move? Then close the curtains. Try out different lights in different locations to get the best picture of you (you want to be recognised at a real conference, later on, don’t you?), and get the camera at the same hight as your eyes. Nobody wants to look into your nostrils. This might mean putting your laptop on a stack of books or similar, but the change is very noticeable.
• Use a wired microphone and headphones. Having audio coming out of your speakers is suboptimal and can result in feedback. Wired is best because of latency and sound quality. There are some Bluetooth headsets and buds available that do a good job here, but they are the exception, not the rule.

• Present to the schedule. As a speaker, if you have been given a 15-minute slot, speak for 15 minutes (give or take a couple of minutes I am not a heartless monster). the organisers will have some buffer built-in and can work on the fly for genuine accidental overruns, but if your 15-minute slot goes on for 40 minutes, that is rude and disrespectful to the organisers, the speakers following you, and the audience who may not have even joined to watch you but rather subsequent speakers.
• Have a timer. Conversely, more organisers should have a visible countdown clock on-screen that will allow everyone to see how much time they have remaining. Additionally, confirming on a regular basis that the speaker knows they will be interrupted and shut down if they exceed their slot by too much is a good way of reinforcing the message to the speaker.
• Have a discussion area available. Not all questions are going to be answered in the session, so having a Slack, Discord or other platforms available will help immensely and ensure your speakers have an opportunity to connect to the audience after the session if need be.
• Let everyone speak. A good host will ensure that everyone on a panel or discussion gets the opportunity to put their point across. Most of the time everyone is happy for this to happen, but sometimes people like the sound of their own voice over everyone else’s. Short of removing that person from the session, it is very difficult to manage that without causing embarrassment. Don’t be that person. Let the moderator/host guide you through the whole session as they have a much better idea of what is supposed to happen and when.
• For goodness’ sake, have fun! As if this year hasn’t been tough enough already, having an opportunity to get together and listen to good talks should be embraced and be enjoyable.

So, speakers, presenters and organisers alike, some tips to make these new (obligatory post-COVID statement here) webinars and sessions more effective for everyone. There are plenty of other tips (don’t use a virtual background if you don’t have a green screen for instance), but these will certainly improve any even you are involved in, and in whatever capacity.

The best thing about virtual events though is that I can get my tea and snacks whenever I want, and not when the venue staff decide. Win-win.

Although I am not a formally qualified auditor, I have had a fair amount of experience of carrying out audits and risk assessments in met various roles towards becoming a CISO. I have also been able to present on the topic and have articulated many of the unique challenges faced by auditors and audits alike.

Reading about auditors on social media, articles and LinkedIn is never a pretty affair, and there is rarely any love lost between them and those posting about them. For instance, the QSA who asked for (amongst other things) a list of usernames and plain text passwords. This auditor then doubled down when pressed, accusing the auditee of ntrying to hide a poorly maintained system.

A similar thing happened to a (barely adequate) friend of mine recently, when his auditor reported a finding that “users have read access to the Windows System32 folder” flagging it as a high risk. Even Microsoft stated that this is how their operating system works, and under “normal operation” cannot be changed. My (barely adequate) friend does not run nuclear power stations, by the way.

Pushing back against these decisions in a formal manner is the only approach you can take; remove the emotion from the conversation and engage as soon as possible, even if it means potentially derailing the audit for an hour or so. If you are able to get team members to do research on the subject, or call in recognised SME’s, then all the better, but establishing the facts early is important. The longer the matter goes on though, the harder it is to resolve.

If that fails, wait until the report or draft comes in. This is an opportunity to formally respond and present evidence to the contrary. This response should be sent not just to the auditor, but also the company they work for (i.e. up the chain of command), as well as other stakeholders such as the clients that commissioned the audit. Their input is important as they are the ones both paying for the audit and with the most vested interest in its outcomes.

Finally, getting everyone involved around an actual table (difficult at the moment I know, but a videoconference will do the trick too) is the last course of action. Hopefully having line management, client/stakeholder, SME’s etc facing off will produce a more amenable result. Don’t expect it to disappear though, perhaps just be downgraded to medium or low.

Being an auditor has a complex dynamic. Third party auditors need to show value to whomever is paying the bills and can sometimes extend the scope or severity of issues to show “value for money”. They can also, ironically, be risk averse and not stand down for fear of being accused of wasting time and a subsequent law suit. An auditor is also trying to be an expert across multiple disciplines at once, as well the one of actually being an auditor, so there are always going to be knowledge gaps. Acknowledging that is a huge step to being a better auditor, and taking time to do independent research on topics you might have not understood as well as you have thought is vital.

For me, auditing/risk assessing was always an opportunity to help the people being assessed; this was a skill as well as a level of emotional intelligence that was shown to me by an ISO 27001 auditor in India, someone I remains friends with after over 12 years. That two-way engagement has been vital to establishing trust and subsequent transparency during audits, and has resulted in better quality findings and a willingness to address them.

Worst case, when it comes to an auditor that won’t back down, you can always just be Accepting the Risk and moving on with the day job.

(TL)2 Security has experience is risk assessment and audit across the security organisation. From a high level risk and gap assessment through to advisory and support services on meeting various certification audits, contact us to find out more.

Business Continuity Plans; probably the most important, yet undervalued and underfunded, part of your security team. This is the team that deals with what might happen to kill you tomorrow, versus what is actually killing us today. A justifiable investment is very hard to make, because they prove their worth when nothing happens; much like the rest of security, but that nothing is going to happen at some unspecified time in the future.

And then something happens, and the leadership are baying for your blood, crying “why didn’t we do something about this before?”. After an initial flurry of investment and interest, it dies down again to pre-crisis levels, and trhe sequence continues.

Maintaining that level of interest is very difficult in virtually any modern business because of the common demands on any listed company; quarterly earnings reports that continually drive down general and administration costs (you are an overhead there, Mr Security), and lurching from one poor investment briefing to another mean there is little room for “what if” investment.

So let’s play some games instead. If they won’t take its seriously, then neither will we. (That’s supposed to be sardonic, by the way.)

Doing tabletop exercises and practising the the plans you have in place is a great way of gaining interest in what it is you are doing, but can be very challenging g to start. The people you are targeting are, after all, the most senior and time poor people in the company. So, let’s start small.

Start with a team within your sphere of influence that has a role to play; maybe the SOC team, and include if you can the departments of peers, such as Legal or Communications. Run a scenario over an hour, record it, document it, create a transcript if need be, and share that report as widely as possible. Make sure you clearly record somewhere that you carried out the test as well, it’s useful fro compliance reasons.

Then rinse and repeat, and each time rely ion the success of the most recent exercise to build the scale and seniority of the exercise. It always surprises me frankly, ho much senior executive try and avoid the exercises, but thoroughly enjoy them when they finally submit to one. it is like they finally see the real world impact of what it is they are doing and the influence they can leverage during times of crisis. I could theorise about the egotistical nature of the phenomenon, but i will leave that to the psychologists and other trick-cyclists.

As the scale of the tests get larger, consider not only running them over longer periods of time and bringing in third parties to manages. This helps in two ways:

1. You get to be directly involved in the exercise without knowing all the “answers”.
2. They can bring a level of expertise you won’t have had, as well as tools and bespoke environments to practise with.

These can be run over extended periods, normally no more than a day, but can go beyond if supported. Four hours is a good place to start, with a working lunch in the middle (it helps attract people; everyone loves a free lunch). These third parties may be able to bring additional technology such as a dedicated virtual environment that includes a physically separate network, dedicated laptops, tablets and phones, that ensure the environment is carefully tracked and recorded, and no real world disruptions are encountered. Finally, they can also add real people to interact with, actually phoning the participants, “tweeting” or posting on other social media as part of the exercise, giving an even more realistic feel.

If you want to go extra fancy, you can even run them over multiple geographies, but make sure you can walk before you run!

Given recent circumstances with COVID-19, the lockdown and massive changes to working practises, being able to respond quickly to dramatic changes in the working environment is no longer an exercise in the impossible future, but rather planning on how to operate in a fast moving, ever changing and dangerous environment whilst still maintaining a running and profitable business.

That doesn’t sound like a game to me.

Are you trying to get your Business continuity and Crisis Management plans out of the document and into an actual exercise for your business but don’t know how to start? (TL)2 Security can help with everything from your initial plan to a full day exercise. Partnering with industry leading organisations to bring the Situation Room to your business, and ensuring you have real world and actionable improvements and observations at the end of the process, contact (TL)2 Security for more information.

The one thing the current lockdown has taught me is that you really can eat too much chocolate… who knew?

Left to my own devices and without the distraction of a routine, regular work and people observing my unhealthy eating habits, my faulty brain tells me that more chocolate can only be a good thing and that I should continue to eat it until physical discomfort forces me to stop (in spite of my brain’s protestations.). It is an obsessive and compulsive behaviour that I recognise in myself, and do my best to contain, but it is a constant struggle arguing with myself that chocolate is not the most important thing in my life.

The same could be said to be true of many security professionals and their desire to roll out security practises to their organisations, implementing new procedures, standards, policies and ways of working that are designed to make the organisation very secure. They do this despite the protestations of the organisation itself telling them they have had enough, the new ways of working are too restrictive, difficult to follow and ultimately leave them with a security stomach ache.

This compulsion to think that security is the most important part of a business’ life is one that leads to users having security headaches all day and the business itself feeling slovenly, bloated and sluggish. (OK, that’s enough of the analogies.)

It is ultimately self-defeating, as users will do their best to work around draconian working practices, and the perception of a security organisation will be one of business prevention than vital service. I, and many others, have spoken about not being the department of “no”, but it goes well beyond just saying “yes”.

Agreeing to everything without thought of the consequences is potentially even more dangerous than saying no, especially in the short term. The vital distinction that needs to be made is that of a two way conversation between security and the end users and business. Finding out what is trying to be achieved is far more valuable than just focusing on what is being asked. Requests can be addressed in many different ways, not just by punching a whole in the firewall or switching off 2FA on the VPN, for instance.

In fact, this very conversation helps create even stronger relationships as it highlights two things:

1. How seriously you take their request.
2. How much you care about the organisation you both work for.

A great example of this in the above video is that of companies relaxing their security stance during the remote working ramp up of the lockdown. If the response was simply “no”, or even a straight “yes” with no consequences there would have been issues sooner or later. Working with the business, relaxing the standards for the initial growth and then methodically scaling and tightening the security once the initial growth is over is absolutely the right way to go.

So next time you feel yourself reaching for the chocolate wanting to say “no”, think beyond the the immediate consequences and how you can use security for the long term betterment of your organisation rather than your simple security stats.

And one bar of chocolate/security is always enough for everyone, right?

Do you need two re-align your security team to your business and don’t know where to start? (TL)2 Security has a proven track record helping security leaders and teams creat strtaegies and business plans that make real, competitive, differences to organisations. Contact (TL)2 to find out more.

Most people who know me will understand when I say I am not technical in my field. Indeed, I have often spoken about how a CISO should not be technical; that doesn’t mean a CISO should not understand technology, but rather that is not the focus of the daily job. So what should a CISO focus on? I often talk about “Powerpoint and politics” and have even heard that expanded to …” and people” which makes sense really. Interestingly though, I used to say it as a joke, and then it came true. Huh.

This weeks video from The Lost CISO series talks about how to build a strategy. Or rather, it talks about how to build the platform upon which to build your strategy. One of the biggest mistakes I see organisations and CISO’s make is thinking that a security strategy comes from the roadmap of projects they will be rolling out over the next 1-3-5 years. Sure, they may feed into a strategy, but they play a small part of it.

Building a strategy requires knowing where you want to go, and what you are supporting. Essentially, it is a vision of the future, so no surprises for guessing that you start with a Vision statement. If, like me from 10 years ago, thought a Vision Statement was a way for expensive pony-tailed consultants to charge thousands a day to simply tell you to “strive to support our customers in a meaningful manner”, you may baulk at this starting point. Fully understandable, but also cynical, and let’s not allow past bad experiences taint our new approach.

The reason I say this is not because I have a ponytail, expensive or otherwise, but rather because a vision is effectively a rallying point around which your security team can focus on. If they do not know what they are working towards, you and your team will be in a perpetual state of fire fighting and reactive work. It doesn’t matter how many projects you have in place, or roadmaps printed nicely on A0 on the design teams plotter; if you don’t know what you are working towards how do you know if you are succeeding?

Make sure you know what the company vision is as well, otherwise you might create one that is pulling in the opposite direction, which helps no-one. Thom’s Top Tip: If you can create a security vision without the word “security” in it, you will definitely be on the right track (although this is by no means mandatory). Your vision, therefore, may look a little like this:

Delivering competitive advantage through trust and transparency.

It’s pretty high-level, doesn’t mention security, and gives people on the team some key pointers on how to consciously modify their behaviour towards a common goal.

But a Vision by itself isn’t enough, you also need some business outcomes to be achieved in order to achieve this Vision. Think of 3-5 or so outcomes that you want to achieve in order to fulfil your Vision, then add a metric (how you know it is being achieved) and an outcome (what benefit does it bring?). You then have one element of your 3-5 business outcomes that allow you to plan work, focus resources and (you will be glad to hear) add to your roadmap. So, for example, here is a business outcome, metric and value in support of the above Vision:

Business Outcome: Frictionless and scalable business processes.

Metric: Higher quality and faster outcomes.

Value: Standardisation resulting in increased efficiencies including easier decision making and better use of time, effort and money.

Add some more like this, and you have a robust vision upon which to build your strategy. Now you can think about how you are going to be doing that because you now have a better idea of what you need to do to achieve the company goals, what resources you need (including skills), and more importantly how you want to shape the future of your security team, and more importantly, your organisation. The whole point of a startegy is to ensure that your future is not an inevitability you have control over, but rather you can invent it to be what you want and need it to be.

 

When you are faced with managing third-party risks, it can feel like a Sisyphean task at best. Even a small organisation is going to have  20+ third parties and vendors to deal with, and by the nature of a small business, absolutely not a full-time person to carry them out. As an organisation grows, at the other end of the extreme there will be many thousands of vendors and third parties in different countries and jurisdictions; even a large team is going to struggle to deal with that volume of work.

In The Lost CISO this week I talk about how to manage a third-party risk management programme from the perspective its sheer volume of work.

The key to dealing with this volume is, of course, to take a risk-based approach, and consciously decide to do nothing about a large proportion of them. It sounds counter-intuitive, but then a risk-based approach to anything can seem counter-intuitive. (Why would you “accept” a high-level risk for goodness sake?!) In this case, you would quite literally be putting some effort into deciding what not to do:

We’re busy doing nothing.

Working the whole day through.

Trying to find lots of things not to do.

Busy Doing Nothing, written by Jimmy Heausen-Van & Johnny Burke

This means your best approach is to filter who you absolutely must assess, who you should assess, and who can be reasonably ignored. In theory, the last group will be the majority of your third parties. How you filter is of course down to what is important to your organisation, industry, clients, the data you hold, the physical location of your environment (office or hosted) and any other criteria you can consider. Ultimately, it is what is important to your organisation, not what is important to you as a security person. Why? Because if security has the final say, there is a potential for a conflict of interest and the limiting of the organisation to operate effectively and efficiently. Here is a sample list of criteria you can sort your third parties by:

1. Do they have access to our client’s (or our client’s customers) confidential/sensitive data?
2. Do they have access to our confidential/sensitive data?
3. Do they have data access to our IT infrastructure?
4. Do they have physical access to our premises?
5. Is our organisation reliant on their services being available at all times?

Inside each of these selected criteria, you may wish to refine further; in answer to the question, think “yes, but…” and you may find a particular vendor does not make your list as a result.

Congratulations! You have now hopefully reduced your third-parties needing to be assessed by hopefully about 80%. If that is not the case, go back to the beginning and validate your criteria, perhaps with business leadership themselves, or (ironically) a trusted third-party.

This may well still leave a formidable list to get through, so there are some more tricks you can use.

When assessing some of the larger third-parties (think Apple, Google, Microsoft etc.), you may wish to accept their certifications on face value. The chances of getting a face to face meeting and tour of the facility, whilst not impossible, are remote, and very much dependent upon how much you spend with them. The more reputable vendors will be transparent with their certifications, findings and general security programmes anyway.

You can then use this filter again with the slightly less well-known vendors but include a handful of questions (no more than fifteen) that you would like answered outside of certifications.

The smallest vendors with the least formal certification and publicly available can be presented with a more detailed set of “traditional” third-party risk questions. Make sure they are relevant, and certainly no more than 100 in total. You are better off getting a good idea of most of the vendor environments from a returned questionnaire than you are a perfect idea of a handful of environments from a barely returned questionnaire. The idea here is to get a consistent, medium level view across the board in order to spot trends and allocate your resources effectively.

Still overwhelmed with sheer volume? If this is the case, look to a three-year cycle rather than an annual cycle. You can reduce the workload by up to two-thirds this way, but you may wish to consider that some vendors are simply too crucial to have on this kind of cycle.

So all that is left is to ensure all of this is carefully monitored, tracked and managed. For instance, what are you going to do with a vendor that doesn’t meet your standards?

And that, my friends, is for another blog.

(You can download a sample third-party security questionnaire from the (TL)2 security Downloads area. There will be more templates arriving soon that you can download and use for yourself, or you may wish to contact (TL)2 if you would like some help and support in creating a third-party risk programme.)

 

 

Back in the ’90s, there was a game released called Command and Conquer, a strategic game whereby you had to manage resources, build, train and mobilise armies and conquer the neighbouring armies. It was a classic that spawned many spin-offs, sequels and addons for decades. What struck me about it though was how multi-skilled you had to be, especially in the later levels.

You couldn’t just be an excellent Field Marshall as you also had to manage resources, cash and other materials to create your buildings and structures that allowed you to create your army in the first place. You had to know logistics, how long something would take to build, train and mobilise, look into the future at new locations for better access to materials, and also have plans in place if the enemy attacked before you were ready.

Essentially, you were skipping from one crisis to the next, finely balancing between success and crashing failure. It sounds a lot like any modern-day incident management situation really.

In this week’s The Lost CISO (season 2), I take a quick look at incident management and highlight four key points to remember during an incident. In case you haven’t seen it yet. here it:

The bottom line is that, much like in the Command & Conquer game, you could plan ahead what you were doing because the environment was constantly changing, the unknowns were stubbornly remaining unknowns and the literal (in the case of the game) fog of war meant you can’t see more than just a few steps ahead. There are though some keys to success.

The first key point is that having a plan is all well and good, but as my military friend regularly tell me;

no plan survives contact with the enemy

Why? Because the enemy much like life does random, unexpected and painful things on a regular basis. Incidents have a habit of doing the same thing, so if your plan is rigid, overly explicit and has little room to ad-lib or manoeuvre in, it will fail.

Therefore, my approach has always been to build any kind of plan around four simple areas:

• Command
• Control
• Communication
• Collaboration

In other words, decide who is in charge, decide who is responsible for what areas, ensure everyone knows how to talk to each other, ensure everyone works openly and honestly with everyone else. There may be some other details in there as well, but really, if you have these four areas covered your plans will remain flexible and effective, and you may find yourself being able to close incidents more quickly and efficiently.

With all that extra time on your hands, you can then spend some time basking under the Tiberian sun.