I remember back in early 1996 arriving home from work and telling the future ex Mrs Langford that was going to be very busy “for the next two to three months”. There was a project going on that I decided I was going to get involved in (outside of my normal IT Manager day job) and that it was going to be good for my career. In modern parlance, I had decided to “lean in”.

Those busy two to three months ended for me on the 10th September 2017. I had pushed myself professionally as hard as I could, burnt the candle at both ends, worked long hours, was only off work sick when I euphemistically “called in dead”, accrued millions of air miles, and was ostensibly successful in my career. Without wishing to dwell here on the events of that fateful night/morning in September 2017, I had reached the end of the line; all of that work and effort had ultimately netted my severe anxiety and stress, diabetes, alcoholism, and a desire to make it all stop very violently.

All of which brings us neatly to right now. I am currently off work sick. I’m very likely to head back tomorrow 9even though I am not 100%, but boredom is a keen medicine sometimes), but I have had the best part of five working days of, plus a weekend in between. I had been feeling under the weather for about a week or so beforehand, but at about midday on my first day off I decided to just switch off my computer and go to bed, and there I more or less stayed for the best part of a week. I had tested positive for COVID, but a few days later that was now negative and I still felt like a bag of rusty spanners had taken residence in my lungs, and my energy levels were depleting like a Death Star tractor beam. Looks like I worked through a second bout of COVID and then got taken down by another virus; but those are details for me and my GP and work HR I guess.

But “SO WHAT?!” I hear you cry? Well, throughout these last few days of being off I made a conscious effort to disconnect from work as much as possible and focus on my recovery. I learnt my lesson those few years back, and realised I needed to get myself back to fitness, despite the many pressing deadlines and meetings I was missing, and the importance of the work I was doing. I focussed on myself and my health as I knew I don’t want to go back too early and jeopardise not only my health but my work performance.

And you know what? Despite everything I had experience before and told myself, I still felt guilty about taking the time out.

This shouldn’t come as a surprise to anybody, anywhere though, not least the information security industry. A few weeks ago, my good friend and all round good chap Sarb Sembhi, who along with Peter Olivier and Paul Simms authored a paper on Mental Health in Cyber Security, and of which I was asked to peer review. I will leave you to read the paper yourself, but the figures in there are both unsurprising as well as making for uncomfortable reading regarding anxiety, depression, anger, alcoholism etc..

I was asked by a client over dinner recently “what keeps you up at night?”. Obviously they were fishing for gossip/insight into the state of our joint business, but I told them that basically nothing does because after my life changing experience back in 2017, I refuse to get stressed or anxious over work matters because it simply isn’t worth it, especially as I am not CISO for something that may save/take lives. And yet here I am feeling guilty about taking maybe another day off sick, and deciding to go back even though I am still not breathing right and feeling fatigued. Surely I should know better?!

To be clear, we are (normally) compensated well and a have privileged positions at work to get the job done properly; we have responsibilities to our colleagues and to the clients and markets we support to do the right job and put the effort in, and frankly most of us even enjoy our jobs. But I can absolutely guarantee you that none of that is worth anxiety, depression, anger, diabetes, alcoholism and suicidal tendencies if that pressure to perform is maintained indefinitely.

Taking care of business ultimately means taking care of yourself first.

---

I am going to be at InfoSecurity Europe in a few weeks time on stage with the Sarb and Peter, authors of the above mentioned Mental Health in Cyber Security paper.

---

Links to other interesting stuff on the web (affiliate links)

What Exactly is the Cyber Scheme?

Solving today’s Security Challenges With Device Centric SSE

Sneaky Tricks In Enterprise Pricing

We all remember the Ocean’s 11 styles of antics that criminals can emulate to gain access to IoT devices and, subsequently, the enterprise network on which they are hosted. It may have been an isolated incident, but it underscores that ANY vulnerability can be exploited.

The question of “why should we be bothered now?” begs to be answered, given that these risks have been around for a long time. But, interestingly, the 2020 COVID lockdown (and subsequent ones) and the impacts it had on the supply chain may help us to answer this question with surprising clarity.

Do you remember how difficult it was to get hold of toilet paper, pasta and hand gel in March of 2020? Panic buying meant that the supply chain struggled to meet demand; combined with the “just in time” supply models employed by most manufacturers and retailers, stocks were diminished quickly with no replenishment in sight. So far, so what, right?

According to the UK’s Office for National Statistics, there are well over 8,000 small to medium sized food suppliers in the UK (probably exacerbated by the gig economy as well). How many companies of this size do you know of that have a robust cybersecurity programme in place?

This puts them at a significant disadvantage when it comes to recognising a cyber-attack and defending against it. Given the fish tank scenario from my last blog, it is no stretch of the imagination to see circumstances whereby chilled and perishable goods are sabotaged and destroyed, either in situ or in transit. Remote monitoring is rapidly becoming the norm and will reduce costs and effort, something any small business would jump at. So protecting these environments, the sensors, and the control devices from the get-go becomes critical.

The incentives to disrupt and destroy the supply chains are sometimes manifest, but only occasionally. Terrorism, both domestic and international, will always try and attack a nation’s weakest point. But there are other threats to consider as well.

The (fairly) recent global lockdowns and various actions carried out by governments worldwide have changed the business and planetary ecosystem, and not always for the better. Without commenting on the politics of the situations themselves, activism has been on the rise globally, with people taking to the streets to defend their particular viewpoints and air their grievances.

The hacker group, Anonymous, are the epitome of so-called “hacktivism”, using their collective skills to disrupt and expose governments and corporations. Their particular flavour of activism involves attacking their targets and exploiting their weaknesses for political and social leverage. So again, it doesn’t take a leap of the imagination to see these current troubling times being a catalyst for more hacktivism, attacking vulnerable supply chains through their reliance on IoT technology.

The positive impact of technology always needs to be balanced against the sociological and cultural impractical it may have, as well as the environment in which it operates. With the commoditisation of security testing capabilities and offensive technological tools, the ability to attack and exploit weaknesses in the supply chain becomes open to the general populace. If that populace suffers a more significant division of wealth and disenfranchisement, the risk of the supply chain being attacked is greater.

Ocean’s 11 suddenly becomes The Hunger Games; the implications of an insecure supply chain vulnerable to attack can have severe consequences for what we consider to be our ‘normal’ lives. So taking precautions now to protect our society’s lifelines must be imperative.

Links to other interesting stuff on the web (affiliate links)

Introducing Cyber Advisor

BSidesAustin 2023: CyberSecurity In The Texas Tech Capital

Understanding ‘Lone Wolf’ Attacks Dissecting and Modeling 2022’s Most Powerful Cyber Attacks

Gone are the days when being a CISO (or even just ‘the security guy/gal’) was about actual information security or IT security. Even the term IT Security is outdated now and emphasises a one-dimensional view of what security is really about. However, I digress…

The Information Security element of CISO is correct, but for various reasons, the CISO’s role is very different from what it was a decade ago. The role then required a strong technologist who understood the firewalls, their rules, the cryptographic controls and even how to code hotfixes on the fly. This isn’t surprising given the role almost wholly came from an IT background; after all, back in the day, mere lip service was paid to the human element, and the legal considerations were considered simply “someone else’s job”.

I was often asked what my job as a CISO entailed, and because I didn’t initially understand what I had actually got myself in for when I took on my first CISO job I used to jokingly say;

PowerPoint and politics

Me. Back Then.

The odd thing is that this response is not far from the truth. My role became significantly less about my understanding of specific niches of information security knowledge and more about putting across to the business what this information security lot was all about and how it helped the company stay competitive, out of trouble or even just in business. The more I was doing this, the more I was embroiled in the day-to-day machinations of how a business works and the inescapable conclusion I came to was this; even if information security is seen as essential to the business, it is still just one voice of many that are trying to influence, cajole and be heard.

Moreover, this is where the politics come in, unfortunately. It is human nature and the way of businesses around the world. Politics is everywhere, and any CISO who doesn’t see and at least understand what is going on is, at best, going to be ignored and, at worst, eaten alive.

Which brings me to my second quote from me (well, it makes attribution a whole lot easier, doesn’t it?);

The purpose of a CISO is not to make the company more secure per se, but rather to help it sell more beer/widgets, increase shareholder value (as appropriate), and let the business make risky decisions more easily… through the judicious use of security

Me, Just now. Again.

The CISO should not be concerned with the name on the front of the firewall or the specifics of the latest penetration test. Instead, they should focus on how best to align their security services to the business and ensure security isn’t just a cost centre but a capability that allows teams and the company to run faster, more efficiently, and with less risk.

That doesn’t take technical knowledge; that takes strategic and business knowledge.

Links to other interesting stuff on the web (affiliate links)

Shift Gears: How to Leverage Data-Centric Security Controls in AWS

Changes to the OWASP API Security Top Ten 2019 to 2023

Cybersecurity as an Operational Effort

Murphy’s Law states:

“If something can go wrong, it will go wrong”

Many CISOs will also state:

“it is not a case of if you have been breached, but rather that you have, you just don’t know it yet”

Depressing as both statements sound by themselves, put them together, and you enter into a worldview of doom and gloom from which it is hard to crawl. It doesn’t matter what you do; there will always be a breach and multiple mistakes in your team. These factors create a perfect storm for finding a new job relatively quickly.

But there is hope that when you start a new role or join a new company, there is one thing that needs to be in place before anything else; the Incident Management Plan*. In all but the most security mature organisations, any improvements put into place by you will take months and years to bear fruit, during which time a disaster can strike without notice (the unknown unknowns hitting at an unknown time, if you will.) So making sure you have a plan to fall back on at a moment’s notice gives you space and time to respond appropriately while still being able to focus on the more fundamental changes you have in mind for the organisation.

But what to put into these plans? There are a few key points that should always be adhered to whenever writing a response plan;

Keep it Simple

Human beings are emotional sacks of meat and adrenalin when things go wrong. They can simultaneously be forgetful, angry, scared, sad, and even stupid. Therefore your plans, and by association, your writing and grammar, need to be as simple as possible. It’s not an easy task and will require many edits, reviews and rewrites, but simplicity is your friend during a confusing and rapidly changing situation. 

Keep it Flexible

Extending the first point, you also cannot create a prescriptive document. If you define every action based on a specific input, your plan will fail when that particular input isn’t happening. The plan needs to work on the principles of what must occur during an incident rather than the specifics of what needs to be done. It is useful, for instance, to focus on roles and responsibilities rather than activities; in this way, someone is accountable for “public communications”; how they achieve that is up to them, but the plan does not define it.

Know What’s Important

This is another way of saying, “Understand your critical services”. These services could be technology-based, process focussed or even role/person-specific. During an incident, the immediate focus is to get the bare minimum of services/capabilities/business operating again as quickly and safely as possible. Going back to Business As Usual is for later on. You need to know what the bare minimum is to achieve it.

The ISO 22301:2019 – Security & Resilience – Business continuity management systems standard is a great place to start to understand the mechanics of this element in more detail (and great for this topic as a whole).

Collaborate While Creating

It never ceases to amaze me how often plans like this get created in isolation across companies, divisions and departments. What that means, more often than not, is a competition for resources because they all assume they will have exclusive access to the resources required to see them through a crisis just because they have a plan.

Ideally, there should be a single master plan for the organisation that allows each discrete business area to manage their plans (essential in larger organisations). Then, all of these plans and their requirements are fed back into the overarching strategy to carry out capacity planning and coordination more effectively and efficiently.

Multi-channel Sharing and Education

This is the one time I will permit using a few trees to print out your plans. Electronic documents are still valuable and should be saved in different formats and on other devices and platforms (for redundancy, obvs). Having paper copies of the entire document, in addition to aide memoirs, laminated “cheat sheets”, credit card numbers and any other creative approaches to ensuring the needed information is always available. Remember, this is a time of crisis; your laptop may be burning down with your building, and your phone may be out of battery with nowhere to charge. Base your communication and distribution methods on the assumption of Murphy’s Law above.

Test the Plan, Learn and Review

You must test the plan as much as possible, especially when creating it. If you feel brave enough, you can have a tabletop walkthrough or pull the plug on a data centre. Some third-party services allow you to test your plan in a virtual space using specialised communications tools that are even more realistic. Whatever the case, every time you check it, review it and feed the findings back into the plan. Even a slight improvement could make all the difference.

Test the Plan Again

Did I mention testing? Even if you have a real-life crisis, use the learnings and feedback to improve the plan again. Every opportunity to stress the crisis plan, people and procedures must happen.

Test it Again

It must be tested, whatever happens, at least once a year, and reviewed yearly. You will be surprised at how much your business changes over a year; a process may be updated, people and roles change, and telephone numbers and email addresses frequently updated. If your plan doesn’t reflect even these simple changes, it is more likely to fail.

The Holy Trinity Mantra

Finally, if in doubt, remember these three elements of your plan. I like to ensure they are seen through in this order, but you may feel differently according to your business and how it operates. (If people don’t list as number one on your list, take a long, hard look at yourself.) Nonetheless, The Trinity remains the same.

1. Focus on People – without your people, you have no business to speak of, recovered or otherwise.
2. Focus on Facilities – even with just a pen, paper, telephone, and somewhere to work, your people can work miracles in keeping the business afloat. Keep them safe, secure and happy.
3. Focus on Technology – get the systems running to take the strain off the people. This may have taken days or weeks, depending on the incident. Ensure your critical systems are running first, and that includes payroll. Paid people pull together in a crisis. Unpaid people don’t.

Hopefully, you will never have to use the plan, but if you do, feeling prepared for anything is a powerful way to ensure your best work on everything else on your list. Knowing that you have it ready to go is like remembering to take your umbrella with you when you leave the house. Because you have it, it isn’t going to rain; mildly annoying but so much better than getting caught in a monsoon in your best work attire.

*Also known as the Crisis Management Plan, Business Continuity Plan, When It Hits The Fan Plan, or any other variable that works for you, your company, and your business culture.

Links to other interesting stuff on the web (affiliate links)

How to Upskill Your Cybersecurity Team

The AWS Security Cheat Sheet

Think Before You Share The Link

It is an accepted truth (trust me, I am a professional), that security is often seen as just a technical profession; firewalls, DLP, DMARC, SFTP and TLAs (Three Letter Acronyms)are thrown around with gay abandon. Being resilient is a matter of hardening the OS, having a SOC fully staffed, and running the industry’s latest SIEM services. CISOs should be technical and know all of the TPLAs (Three Plus Letter Acronyms) having spent their formative years in their Mother’s basement while they hacked the Pentagon/GCHQ/Kremlin.

It may surprise you that I dislike this approach and viewpoint.

I found a wonderful quote on (where else?) the internet that, unfortunately, I cannot attribute to anyone. So, if you know where this comes from, please do tell me:

“People aren’t the weak link in security; they are the ONLY link.”

(Unknown)

Information security is primarily a people industry. Technology isn’t a panacea but merely an accelerant and amplifier of the existing processes and solutions. Without the people, there is no information to secure in the first place. If we, as CISOs and business leaders, don’t embrace and support our people, we make our jobs so much more problematic when securing the business and helping it do more, sell more, and create more.

So, in my usual style, here are the three things I suggest everyone who has “people” in their business and is responsible for education in one form or another should bear in mind.

Crowd Sourcing

So many of us (I know I did for the longest time) overlook the rather undeniable fact that having many people means they can all carry a small part of the security load. Crowdsourcing works because many people put a small amount of something in to help someone else build something big. You can make this approach work for you in several different ways.

Firstly, approach certain people to be “super contributors” to your infosec crowdsourced campaign. These are the folks that are your primary eyes and ears on the ground, the folks that people go to when they have an immediate problem. Think of them as the cyber first-aiders, if you will, with a few of them dotted around each floor or department.

Give them some face-to-face training if you can or at the least some detailed role briefing notes. They are doing this role because, like first-aiders, they want to help people and be a part of the solution. Reward them with a token monetary compensation, some swag, recognition or whatever fits into your organisational culture.

Secondly, the rest of the people in the organisation can also be encouraged to play a part; connect their ability to spot phishing, social engineering, reporting incidents and breaches to their role in the organisation and its successes. Finally, make it fun (see below), make it engaging and make it educational. 

Doing that is, of course, an essential subject in of itself, but the real message here is to embrace what you might see as your biggest weakness as your biggest strength. Making this leap of faith in your mind means your approach to training, problem-solving, and how you address the people in your organisation changes to positive and collaborative rather than cynical and combative.

Story Telling

 Storyteller is probably the second oldest profession in the world; we can easily imagine stories being told from one generation to the next around the campfire. But, before the written word was used, it was vital before Grandpa died that he told us the secret to successfully hunting that particular breed of rabbit/buffalo/mammoth (depending upon what part of the world you came from).

And yet we can also imagine that after hearing the same story over and over again, night after night, while Grandpa gets slowly drunk on his fermented yak’s milk becomes quite tedious. His tales of daring-do and athletic ardour, as he leapt onto the back of the killer rabbit, became very tiresome after the 954th time. And then last night, as he was getting carried away with the demonstration of his rabbit chokehold, he broke wind. Not only was that the version of the story you passed on to your children, but it was also the birth of the third oldest profession: Comedian (probably).

I am a huge fan of humour in the workplace, especially when it comes to educating people; a good joke conjures up images, feelings, experiences, and smells. But, above all, it is a story. Stories help people create worlds in their minds, relate their experiences to those worlds, and establish a visceral feeling in their bodies, an actual chemical change. Of course, there are few guarantees in this world. Still, one I pass on with a cast-iron guarantee is that no positive, memory-creating chemical changes in any brain anywhere in the world were created by putting people in a room and shouting PowerPoint at them for an hour.

The lesson here is that a good story goes a long way to helping people retain the information; build your message with a strong start, a fantastic middle and a resounding end, and you have the makings of impactful and memorable education.

Don’t Stop

“Oh no, it is that time of year again; we must do our security training”.

Don’t be this company. If you do something once a year because you have to, it becomes an obstacle, something that needs to be completed quickly and with as little effort so you can get on with the fun stuff.

If educational activities in the rest of our lives are continual activities, then why do we not apply this to our infosec training? First, of course, it is not an educational experience that people have opted into, but keeping a cadence to the activities that go beyond just one activity works. Ensuring the format changes and evolves, so it isn’t just posters all year round but lunch and learns, videos, emails, intranet, competitions, and the like means people who struggle to learn in one format can pick it up in another and keeps them on their toes, wondering what the next activity is. It piques their interest and keeps them engaged.

Try creating a 24-month schedule of activities and subjects; it’s not easy, but even having that schedule open and visible allows you to think much more long-term rather than just at a compliance, box-ticking level. Of course, you can still do quizzes (so many auditors and standards require that kind of box-ticking, unfortunately), but by avoiding the one-shot PowerPoint training and ten easy-to-guess questions, you are keeping the content new and fresh. You are also building a reputation as someone who cares about the educational process and the positive outcomes it brings, not just ticks in boxes.

Wrestling Rabbits can be fun AND educational.

Links to other interesting stuff on the web (affiliate links)

Five Key Dark Web Forums to Monitor in 2023

What is Cybersquatting? The Definitive Guide for Detection & Prevention

Seven Questions About Firmware and and Firmware Security

In the last post, I looked at some of the less apparent activities upon becoming a new CISO, namely:

1. Stop thinking that infosec is your business.
2. Stop making technology purchases.
3. Ask your vendors to explain what you have in your services inventory.

In this post, we will take this a step further and closer to actual business as usual and maintaining your security team as a functional part of the organisation.

Don’t say “NO!” to everything.

This is an obvious thing to do, but it is much harder to do in practice. The reality is that this requires a complete change in mindset from the traditional view of the everyday CISO. As a species, the CISO is a defensive creature who is often required to back up every decision and be the scapegoat of every mistake (see One CISO, Three Envelopes https://thomlangford.com/2014/12/01/three-envelopes-one-ciso/) and generally rubber-stamp choices that are out of their bailiwick and control.

The mindset shift requires a leap of faith wholly because of this perceived threat of blame and accountability when, in fact, it does just the reverse. 

It starts naturally enough with the language that is used by the CISO and the team, for instance, changing the Change Approval meeting to the Risk Review meeting and not communicating a yes/no or go/no-go response to changes but rather a level of risk associated with the request and alternative approaches as appropriate. There is a need to communicate this shift in the culture, of course, but people will see that they are accountable for decisions that affect the business, not the security team. Shifting the mindset away from being a gatekeeper to a security team that provides sensible and straightforward advice based upon clearly understood risk criteria is a fundamental step towards avoiding being known as the Business Prevention Unit. Politely correct other’s language when they mention an action that requires sign-off or approval from “Security” and help them understand their role in the business decision.

This approach does not require a snap of the fingers for 50% of the problems to go away. Still, carefully planning and educating your stakeholders alters the impact you can have on the business dramatically for the better. It also allows you to more easily draw a line between the activities of the security team and the company’s performance, all for the price of merely no longer saying “no”.

Stop Testing Your Perimeter

What? Are you serious?! 

Absolutely.

As you enter a new environment, you will be taking many critical pieces of information on trust and from people with vested interests in their careers, livelihoods and reputations. Your arrival upsets the status quo and has the potential to disrupt the equilibrium; all reasons to not always be forthcoming with every piece of information you request. It isn’t about people being dishonest or deliberately misleading you, but merely being complex, multi-faceted human beings with multiple drivers and influences.

Your perimeter is one of the fundamental pieces of your information security puzzle. Despite cries of “the perimeter is dead”, it remains a prominent place for attacks to happen and where you should feel fully confident that you know every node in that environment to the best of your ability.

Whatever your testing cycle is, suspend it for some time and conduct as complete an investigation as possible into precisely what your perimeter comprises. It can be done automatically with discovery tools, manually through interviews with those responsible, visually in data centres (where you have old school “tin” still being used, and any combination of the above. You will likely find devices that you, and probably existing team members, weren’t aware of, especially with the proliferation of the Internet of Things devices being used throughout the enterprise now. Did facilities install a new access control system or room booking system? Did they consult IT, or more to the point, you?

It sounds like the stuff of legend or the script to the Ocean’s 11 movies, but do you remember when a Las Vegas casino was broken into… through their fish tank? Knowing what devices are where on your network and perimeter is vital and must be considered table stakes in any decent security programme. An alternative is simply a form of security theatre that gives the impression of security and does nothing but create a false sense of security. A cycle of no testing is worth discovering what you don’t know because you can do something about it.

Building your plan

Now you have a grip on your environment in a relatively straightforward, simple, effective and quick way. Through this process, you will ascertain your stakeholders, advocates and even a few potential adversaries. Then, armed with this information, you can provide an accurate picture of the business to the business in a way that makes sense and displays a grasp of the fundamentals.

Building your plan will always start with your initial assessment and what needs to be done to become operational or steady-state. The trick, however, is to ensure that this baseline achievement is perceived as the end state of security but rather merely the first stepping stone to ever more impressive services, capabilities and ultimately, profit and growth for the company.

The plan itself, however? That is yours and yours alone. Although other posts in this Blog will help as you plot your course into the future, nothing will replace your understanding of the local culture, organisation and, ultimately, what you need to achieve to meet the expectations of the business leadership. Know what the rules of your organisation are, when to adhere to them, when to bend them, and most importantly, when to break them (but only when experience tells you it is the right thing to do):

“The young man knows the rules, but the old man knows the exceptions.” 

Oliver Wendell Holmes

Be the Old Man, be the CISO.

Links to other interesting stuff on the web (affiliate links)

5 Ways Penetration Testing Reduces Overall Security Costs

Avoiding Security Theater: When is a “Critical” Really a Critical?

Game of Life Security and Compliance Edition

So you want to be a CISO? Perhaps you want to be a better CISO? In many cases, you could pick up a book, attend a conference or even talk to some peers and colleagues. Of course, there will be some good advice in these approaches too, but you don’t want to be just any CISO; you want to be THE CISO.

Across two blog posts, I will look at some of the more unexpected but necessary activities you can do from the moment you start in a new role or start with a new approach to being a CISO. Some may be counterintuitive; some may be a little odd, and you may even disagree with a few. But, whatever you feel about them, they should start you thinking about different ways to approach your role and how you see the contributions you make.

In summary, in this particular post, you will learn to:

1. Stop thinking that infosec is your business.
2. Stop making technology purchases.
3. Ask your vendors to explain what you have in your services inventory.

Stop Thinking InfoSec is Your Business

As a CISO, your primary purpose is not to secure the business; as odd as that may sound, it simply isn’t. Instead, the objective of a company is to sell more stuff, increase profit and maximise shareholder value (there are exceptions such as charities, government and the like, but they still have goals that include maximising value nonetheless).

If that is the case, your purpose is to help it achieve that goal through your activities. However, if you put your (security) activities ahead of those of the business, you are, ergo, hindering its ability to achieve its goals. So flip the situation around and ensure that when you come into the picture, you are fully cognizant of what your organisation does, its goals, ambitions and vision. Then, look at how your security team can make that a reality. Simply slapping security measures onto the business without regard for its purpose and intent will, at best, cause friction and disgruntlement and, at worst, diminish its business operations.

Read the company report, talk to the CFO, talk to people on the shop floor, the road warriors, delivery leadership, and, wherever possible executive leadership. Understand where the business came from, its roots, its beginnings, the founding values and vision, and even how it has evolved (if at all) over the years. By doing this, you will understand how you and your security team can help. Then, and only then, can you start to build your services and security posture.

Stop Your Technology Purchases

Unless the ink is drying on the cheques, you should pause purchasing until you have a better idea of the business. This makes completing the first step all the more critical, as some of the purchases may be vital. However, purchasing something that aligns differently with your new way of thinking about the business makes no sense, and significant amounts of money can be wasted and misdirected.

You may find much pushback from various stakeholders in the business, mainly as their pet projects and mini-kingdoms rely on those purchases. As a result, you are stymying their efforts and potentially making them look bad. Your long-term security strategy, though, depends on solid business cases supporting sensible purchasing decisions that will actively help the company and its long-term goals. Anything else is a distraction and can drain the company’s resources.

Ask your vendors to explain what you have in your services inventory

Why would you ask your vendors what they have sold you? Surely you know that already. Probably not, actually, and it is down to human nature as to why.

Purchases and contracts entered into may have supported failed initiatives or even not been appropriately implemented at all. This so-called “shelfware” is an issue in many companies, supported by 451 Research in 2014 (https://www.rsaconference.com/writable/presentations/file_upload/mash-t07a-security-shelfware-which-products-gathering-dust-and-why.pdf), with an evident rise in the problem when it comes to larger organisations. Asking your vendors for a catalogue of services will reap more accurate results as they have a vested interest in maintaining correct records as they charge you for their services (even if you use them or not). Any vendor worth dealing with will happily sit down with you and discuss what they have sold you and what value it brings. If they don’t, alarm bells should be ringing!

Armed with this information, you can start to build a picture of technology services in the company and ascertain what is shelfware, what is used effectively, and what isn’t. At this point, and no earlier, should the old purchasing go live again, minus the services that provide little to no value to the company.

These basics will be challenging because you will be pushing against the weight of expectations from other people in the company or because it takes time and effort. That doesn’t mean that they shouldn’t be done, and in doing so, they will help set you up for the following three sets of basics that we will cover in the next blog. If you can’t wait until then, here is a little teaser:

4. Don’t say no to everything
5. Stop testing your perimeter
6. Building your plan

Are you sufficiently intrigued?

Links to other interesting stuff on the web (affiliate links)
How the Dark web is Embracing ChatGPT and Generative AI
How To Upskill Your Cybersecurity Team
A Trip to the Dark Side of ChatGPT

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:

<image>

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.

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.