Risky Business

Leave a comment

<updated with missing risk matrix image>

Risk is a topic that I like to talk about a lot, mainly because I managed to get it ‘wrong’ for a very long time, and when I finally did realise what I was missing, everything else I struggled with fell into place around it. For me, therefore, Risk is the tiny cog in the big machine that, if it is not understood, greased and maintained, will snarl up everything else.

In the early days of my career, risk was something to be avoided, whatever the cost. Or rather, it needed to be Managed, Avoided, Transferred or Accepted down to the lowest possible levels across the board. Of course, I wasn’t so naive as to think all risks could be reduced to nothing, but they had to be reduced, and “accepting” a risk was what you did once it had been reduced. Imagine my surprise that you could “accept” a risk before you had even treated it!

There are many areas of risk that everyone should know before they start their risk management programme in whatever capacity they are in, but here are my top three:

Accepting the risk

If you want to know how not to accept a risk, look no further than this short music video  (which I have no affiliation with, honestly). Just accepting something because it is easy and you get to blame your predecessor or team is no way to deal with risks. Crucially, there is no reason why high-level risks cannot be accepted, as long as whoever does it is qualified to do so, cognizant of the potential fallout, and senior enough to have the authority to do so. Certain activities and technologies are inherently high risk; think of AI, IoT or oil and politics in Russia, but that doesn’t mean you should not be doing those activities. 

A company that doesn’t take risks is a company that doesn’t grow, and security risks are not the only ones that are being managed daily by the company leadership. Financial, geographic, market, people, and legal risks are just some things that need to be reviewed.

Your role as the security risk expert in your organisation is to deliver the measurement of the risks clearly as possible. That includes ensuring everyone understands how the score is derived, the logic behind it and the implications of that score. This brings us neatly to the second “Top Tip”:

Measuring the risk

Much has been written about how risks should be measured, quantitatively or qualitatively, for instance, financially or reputationally. Should you use a red/amber/green approach to scoring it, a percentage, or figure out of five? What is the best way to present it? In Word, Powerpoint or Excel? (Other popular office software is available.)

The reality is that, surprisingly, it doesn’t matter. What matters is choosing an approach and giving it a go; see if it works for you and your organisation. If it doesn’t, then look at different ways and methods. Throughout it all, however, it is vital that everyone involved in creating, owning and using the approach knows precisely how it works, what the assumptions are, and the implications of decisions being made from the information presented.

Nothing exemplifies this more than the NASA approach to risk. Now NASA, having the tough job of putting people into space via some of the most complicated machines in the world, would have a very rigorous, detailed and even complex approach to risk; after all, people’s lives are at stake here. And yet, their risk matrix comprises a five-by-five grid with probability on one axis and consequence on the other. The grid is then scored Low-Medium or High:

Seriously. That’s it. It doesn’t get much simpler than that. However, a 30-page supporting document explains precisely how the scores are derived, how probability and consequence should be measured, how the results can be verified, and so on. The actual simple measurement is different from what is important. It is what is behind it that is.

Incidents and risk

Just because you understand risk now, you may still need to be able to predict everything that might happen to you. For example, “Black Swan” events (from Nicholas Nasim Taleb’s book of the same name) cannot be predicted until they are apparent they will happen.

By this very fact, creating a risk register to predict unpredictable, potentially catastrophic events seems pointless. However, that differs from how an excellent approach to risk works. Your register allows you to update the organisational viewpoint on risk continuously. This provides supporting evidence of your security function’s work in addressing said risks and will enable you to help define a consensual view of the business’s risk appetite.

When a Black Swan event subsequently occurs (and it will), the incident response function will step up and address it as it would any incident. Learning points and advisories would be produced as part of the documented procedures they follow (You have these, right?), including future areas to look out for. This output must be reviewed and included in the risk register as appropriate. The risk register is then reviewed annually (or more frequently as required), and controls are updated, added or removed to reflect the current risk environment and appetite. Finally, the incident response team will review the risk register, safe in the knowledge it contains fresh and relevant data, and ensure their procedures and documentation are updated to reflect the most current risk environment.

Only by having an interconnected and symbiotic relationship between the risk function and the incident response function will you benefit most from understanding and communicating risks to the business.

So there you have it, three things to remember about risk that will help you not only be more effective when dealing with the inevitable incident but also help you communicate business benefits and support the demands of any modern business.

Risk is not a dirty word.

Links to other interesting stuff (affiliate links)

Building a Modern Exposure Management Program

Access Controls that Move – The Power of Data Security Posture Management

Vulnerabilities and Insights: A Look at Cybersecurity Challenges

Document and Review

2 Comments

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.

Too Much of a Good Thing

Leave a comment

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 weeks Lost CISO episode talks about when too much security, like chocolate, is a bad thing.

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.

Strategic Defense

Leave a comment

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 strategy is to ensure that your future is not an inevitability you have no control over, but rather you can invent it to be what you want and need it to be.

Looking to take your security team to the next level of productivity and business engagement? (TL)2 Security can help you define, establish and operationalise your strategy and vision ensuring you go beyond just keeping the lights on, and actually providing competitive advantage to your business. Contact us to find out more.

The Runners and Riders of Lockdown

Leave a comment

After over six weeks of some kind of lockdown here in the UK, and similar amounts of time elsewhere in the world, it has become very obvious to me that many companies out there are simply ill-equipped to deal with the change in lifestyle the lockdown demands.

By ill-equipped, I don’t just mean from a technology perspective, although we see some of that as companies reduce security requirements to get users online from home. What I mean is that culturally they are not equipped to deal not only with a workforce that needs to work remotely but also a market that is doing the same. Put simply; companies are struggling to re-gear their sales and marketing departments to this brave new world we find ourselves.

I say this because as an industry we are used to a plethora of in-person events happening where vendors can either have stalls displaying their latest products, or stages where carefully polished presentations and panels are put on for us to watch, learn and hopefully decide to buy their product from. Webinars and online events were there but were the distant, impoverished, uglier cousin of something live, in-person and your face. Indeed, just a few weeks before the lockdown I was at RSA Conference in San Francisco, where the very epitome of what I describe was played out for the world to see.*

Then suddenly, it all stopped. Conferences and shows were cancelled, events postponed indefinitely, and in many cases, the security product landscape just stopped. I understand why, in many cases, cash flow needed to be conserved in these unprecedented times. However, it very quickly became apparent that this was the new normal, and that the companies that didn’t embrace it would quickly become irrelevant. after all, if you can’t adapt to a few weeks of disruption, what kind of company are you, delivering products to an industry that needs to plan for disruption?

I watched “Have I Got News For you” in those first few weeks on the BBC, a topical panel show comprised of 5 people, and they did it by having the guests record from their homes.

Have I Got News For You, March 2020

It was different, the dynamic was… a little off… but the show went ahead, the jokes landed, and each subsequent show got better. In other words, the BBC just got on with it, embraced the change, and made it work.

The same needs to happen to many of the security vendors, as unfortunately, it is a case of remaining relevant throughout the lockdown, in the front of people’s minds, and showing that they can overcome adversity by delivering knowledge and information. Those that don’t do it, retract into their proverbial shells and wait for “normality” to return will suffer.

Also, let us assume that normality does return, whatever form that might take. Those that have embraced these alternative Zoom/Skype/Teams/Hangouts/whatever approaches may find they are just as valuable as in-person events and can operate both, side by side, now unconstrained by the lockdown and able to use film and audio in even more creative ways. Which company would you choose to work with in the future, the one who sat tight, and did little market outreach during the lockdown, or the company that continued to communicate with their clients and potential clients through different mediums, sometimes getting it wrong but continually innovating and improving. Which company has the better culture?

It isn’t even a matter of cost. The LinkedIn Live, Zoom, Webinar etc. technologies already existed and were invested in, just woefully underutilised.

The same argument also applies to work from home, as many organisations now realise that productivity isn’t hours sat at the office desk, but rather results.  Which organisation/manager would you want to work for? The one that never changes or the culturally adaptive one that is based on results and trust?

These are challenging times, but these are the times that are going to show many companies in their true light, and you can use this time to differentiate between them.

 

*I do love a good conference, and the benefits they bring to my peers and me are fabulous, in case you think I am biased against them.