CISO Basics, Part 1

1 Comment

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:

  1. Don’t say no to everything
  2. Stop testing your perimeter
  3. 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

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.

The New Etiquette of Webinars (insert post-Covid statement here)

Leave a comment

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 BrightTALK. 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 Livestorm 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.
The steps you go to ensuring you look good on screen. I need all the help I can get.
  • 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.

When Auditors Attack!

Leave a comment

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.

And attack they will.

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.