Wishes

So You Want to be a Cybersecurity Professional? – Redux

At the end of last year I wrote a blog that proved to be my most popular yet, by several orders of magnitude. In So You Want to be a Cybersecurity Professional? I threw together some very high-level thoughts for those wishing to get into the field. However, it’s wasn’t until the last week or so that it occurred to me to question why this blog in particular resonated as it did.

On the assumption that it’s because there are literally thousands of people out there struggling to find their way into security, I figured I’d expand a little on the original.

With the proliferation of both certifications and U”niversity degrees, there are many avenues that attempt to fast-track cybersecurity careers. Add to this a ridiculous number of ‘new’ technologies all claiming to address a rapidly growing number of threats and regulatory compliance regimes, and you have a combination that could not be better planned to lead candidates to a career dead-end.

The new modus operandi for cybersecurity professionals seems to be; University degree > industry certifications > Technology. But if your ultimate goal is CSO/CISO you have derailed yourself even before you start. I do not know one CSO/CISO who is primarily focused on technology …not any good ones anyway. It’s the people and processes that give technology context, not the other way around.

No course on the planet can teach you people and process, that’s something you must to learn for yourself. In security, experience is key.

While technology is an indispensable aspect of security, the majority of the product and security vendors who say they are trying to help are actually causing enormous damage. In their mad rush to stake a claim to a piece of multi-billion $/£/€/¥ security industry (and still growing), they are developing technologies so far removed from the basic principles as to be almost unrecognisable. Not only are these largely inappropriate to most businesses, but far too fleeting and ethereal to ever be rely on as a career foundation.

While I assume most University degrees will cover the ages-old basics of governance, policy & procedure, risk management etc. (like the CISSP’s CBKs do), without a real-world understanding of their implementation you will never be able to put a technology into a context your clients or employer has the right to expect. Basically you will be lost in a never-ending cycle of throwing technology after technology at something that could likely be fixed by adjusting the very business processes you’re trying to protect. Technology can only enhance what’s already working, it cannot fix what’s broken.

So where should new candidates start? I have no issue with University degrees or certifications, but from my own experience it was starting out at the most basic level that gave me the greatest foundation. From firewall and IDS administrator, to a stint in a 24X7 managed security service security operations centre I received an education that has stood the test of time. Networking, protocols, secure architecture, system management, incident response / disaster recovery, and just as important; the power of great paperwork. There is no-one who appreciates a comprehensive set of procedures and standards as someone who has just taken down a client’s firewall.

For the next phase of my career I was, for want of a better word, lucky. PCI was just kicking off and the desperate shortage of QSAs meant it was relatively easy for me to become one and be thrown immediately in front of customers. I learned as much in the next year as I did in the preceding 5. Not technical stuff per se, though that was certainly part of it, but the soft skills necessary to provide a good service.

From that point forward I have stayed in consulting, as I am fully aware of that is where both my interest and skill-set lay. I am not technical, never have been, so I’ll leave that up to others. I have also never wanted to be a high-level executive, that’s too far removed from anything I have ever enjoyed. What this means is, I already know a CISO role is very likely not in my future, and I’m absolutely fine with that.

I have my own thoughts in what a CISO is anyway.

I’m not saying that CSO/CISO need be your goal, if you’re quite happy managing firewalls, that’s great, but you absolutely have to know what your goal is or you’ll flounder around the edges of security missing every boat that comes along.

So:

  1. If you want to be a CISO, remember that the vast majority of the CISO function is just a series of consulting projects designed to help the business meet its goals. The final aspect of a CSO’s job borders of politics, so that had better be what you want.
  2. If you love technology, great, but get an understanding of how your technology(ies) fits into the client’s business goals before trying to shove it down their throats. And jumping straight out of Uni into a technology start-up may seem like a good move, but only 1 in 1,000 companies make any difference. Be prepared to fail many times.
  3. If consulting is your thing, stay high-level and stay with the basics. Be the person that your clients come to to solve their challenges, regardless of who ends up performing the actual remediation. A Trusted Advisor is a very rare thing, and very few ever earn it.

Regardless of your career goal, the basics of security will never change, and you will only be at the top of your game when what you are doing benefits everyone involved.

Finally, a warning: if you think anyone other than those making a career out of it care about security, you are mistaken. Not one, I repeat not ONE of my clients actually cares about security, they care about things ranging from genuine concern for their customers to just money. Security is only, and will only ever be, a means to an end. It enables a business, it does not direct one. It’s these things that you cannot learn from school or from technology alone.

Get a mentor, one who has been where you are and is where you want to be. And never, I mean NEVER follow the money.

[If you liked this article, please share! Want more like it, subscribe!]

Policies & Procedures

Information Security Policy Set: It All Starts Here

Information Security Policies, or more accurately; Policies, Standards, & Procedures (a Policy Set) are the cornerstone of every security program. It is therefore rather odd, that not one client I have ever helped started with any of them in place. While not everyone is a security expert, everyone can be security savvy enough if, and ONLY if, what they are supposed to do is written down!

That’s what a good Policy Set is; an instruction manual on what to do, what not to do, why, and how.

I have written too many many times on why a good Policy Set is important, and have used the term ‘baseline’ more times than I’ve had hot dinners. I have described what a Policy Set consists of, and even how to manage one, but what I have not do up till now was to describe how to find a Policy Set that’s right for your business.

First, you may be wondering what’s so hard about finding policies. And I agree; type “information security policy example” into Google and you’ll get tens of millions of hits. Universities readily publish theirs for the world to see (e.g University of Bristol), and a whole host of organisations even make editable versions freely available. On top of that, online services with ridiculous promises like “THE ONLY WAY TO GET AN INFORMATION SECURITY POLICY CUSTOMIZED FOR YOU IN AN HOUR, GUARANTEED.” are depressingly common.

The challenge is that if you’re looking for information security policies in this fashion you clearly have no experience implementing them, let alone actually writing one yourself. An overly-dramatic analogy; I found thousands of instructions on emergency appendectomies, would you now trust me to perform one on you? A good Policy Set is one that is appropriate to your business. Not your industry sector, not the prevailing regulatory requirement, your business!

Therefore, if you don’t have security expertise in-house, it is very unlikely that you know the right questions to asks providers of Policy Sets. The vast majority of vendors will sell you what you ask for (can’t really blame them for this), so ensuring you get what you actually need is entirely based on the homework you performed beforehand.

To that end I have written something vaguely resembling a white paper to help you. In the imaginatively named ‘Choosing the Right Policy Set‘ I have broken the choosing of a policy set vendor into 15 Questions. These could easily form the core of an RFI or RFP if you were taking this seriously enough.

Simple questions like; “Can you provide a Document Management Standard and Procedure?” or “Does your service include a mapping of policy statements to the PCI DSS?” are sometimes not even considered. But when you consider that the choosing of a policy set can be the difference between compliance and non-compliance, it makes sense to ask them. Up front!

90% of organisation will end up either throwing something together themselves, or buying the cheapest option available. That’s fine, when regulatory fines start getting handed out they will realise just how expensive their choice was.

[If you liked this article, please share! Want more like it, subscribe!]

Change Control

Change Control: Break the Vicious Cycle

Have you ever tried to fill a colander with water? Of course not, that would be ridiculous given that it’s full of holes. So why would you try to implement a security program without ensuring that whatever you fix does not get broken behind you?

Do you give your IT administrators permission to change the setting on your personal phone? Again, of course not, so why would you allow them to make significant changes to corporate assets without proper oversight?

While these analogies are flippant and geared toward emphasising my point, I would not be writing this blog if the issue of change control was not an enormously important one. At best, poor change control can cause additional unnecessary work, at worst you could be out of business. It’s bad enough that bad guys want to break in, most organisations I have seen are making it easier for them from the inside.

The definition of change control is; “…a systematic approach to managing all changes made to a product or system.“, and it’s purpose is “…to ensure that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted and that resources are used efficiently.” Sounds fair, right? No disruption? Efficient? Are these not good things?

The biggest issue is that change control requires not only planning, but extra effort. You have to fill out a form, send an email, or log into a GUI of some sort, all of which may take longer than making the change in the first place. Change control is time-consuming and can be seen as a bottleneck, both of which are no-nos in the rapid evolution towards more and more function. But what would you rather have; 1) an insecure service quickly, or 2) a secure service a very short time later?

Unfortunately, given that change control is a primary function of governance, few organisations have the oversight to implement change control well. so how can organisation perform this most critical of processes?

First, it has to be appropriate. There is little point in a 5 person company buying a change control software, but larger organisations should not be using email and spreadsheets. As long as the right people are involved in making the change decisions, this process can be as formal or informal as is sustainable. If this is ever seen as a burden, it will be either circumvented, or ignored altogether.

Often overlooked, but critical to change control success, are a few pre-requisites…

Change Control Pre-Requisites:

  1. Ensure that the asset register contains not only physical devices, but applications, CotS software, data stores, location, unique skill-sets etc.
  2. Assign business criticality and maximum data classification to all assets;
  3. Assign ownership to all assets;
  4. Map all assets to the business processes they support (note: these maps becomes assets in and of themselves); and
  5. Ensure that the change request form includes a list of the affected assets.

Change Control Form:

Every change request must, at a minimum, include these things.

  1. List of affected systems;
  2. Details related to affected users (if applicable);
  3. Criticality of change request;
  4. Indication of additional risk;
  5. Success criteria / test plan;
  6. Back-out or fix-forward plan; and
  7. Appropriate authorisation.

By mapping the affected asset to their corresponding business processes, their owners, and both their criticality and maximum data classification, you can automatically bring the right decision maker to bear to authorise the change.

Too often the business owners have little to no insight to technology changes, when in reality, they are the only ones who should be authorising the change. IT and IS are, and have always been, business enablers, nothing more. First and foremost, change control need to reflect the goals of the business. In the absence of governance, the above minimums are about the only way to see that this happens.

Of course, if you also link change control to your ticketing system and incident response processes you would have the Holy Grail, but baby steps…

[If you liked this article, please share! Want more like it, subscribe!]

Reasonable Security Measures

GDPR: How Do You Define ‘Appropriate’ Security Measures?

Ask a lawyer what ‘appropriate’ or ‘reasonable’ means and they’ll come back with something like; “What would be considered fair by a disinterested third party with sufficient knowledge of the facts.”, or “Fair, proper, or moderate under the circumstances.”

Now translate that into what kind of security measures are considered appropriate? How would you justify that what you are doing is reasonable, fair, or proper under the circumstances?

Because that’s what you’ll have to do if things go wrong under GDPR. You’ll have to justify that the measures you took to protect personal data were underpinned by an appropriate program for measuring and treating risk. If your breach was shown to be anything other than a determined attacker, all you’ll have in your defence will be poor excuses. This is no better than negligence.

When you consider that the General Data Protection Regulation (GDPR) – and every other regulatory compliance for the matter – was written by lawyers, should we not be able to work out what ‘appropriate’ means for a security program? After all, lawyers have no problem defining the word ‘reasonable’, they even apply it to their fees!

The good news is that the process is not only well known, it’s simple; it’s called Risk Management, and it’s been around for decades.

Step 1: Complete your Asset Register;

Step 2: Map your assets to your business processes (which should already be mapped to revenue);

Step 3: Map your business processes to your business goals;

Step 4: Run a Risk Assessment against all business processes and / or key IT systems;

Step 5: Document the business impact of each risk (mapped against both revenue and business goals);

Step 6: Document Senior Leadership’s risk appetite against each business goal;

Step 7: Perform full analysis of security controls, determine if there are any gaps between the current state and the risk appetite;

Step 8: Fill the gaps;

Step 9: Document everything; and

Step 10: Repeat annually, or prior to any major changes.

Now put yourself in the shoes of an auditor after you have been breached. What are they going to task you for? What could anyone reasonably expect of you to have in place if you were taking your duties seriously?

If I was an auditor I’d ask for 5 things up front, as without them I know there is no way you have an appropriate security program in place:

  1. A mapping of your policies, standard and procedures to whatever security framework you based your on;
  2. Your risk assessment procedure, and the results of the last one conducted;
  3. Your risk register;
  4. Your change control procedure; and
  5. Your incident response procedure.

At this stage I would care nothing for your technology, or how much you spent on it. A technology purchase outside of a properly defined business need is nothing more than smoke and mirrors. Besides, no regulator has ever tried to qualify how much you spent. It’s up to you to show why you spent what you did, and why you didn’t spend more.

Thing thing to bear in mind here is that the validation of ‘appropriateness’ is not a conversation, it’s documentation. It’s not even evidence of the technologies you have running, it’s showing that the technologies you do have meet the risk you have defined. While from a lawyer’s perspective, appropriate is demonstrated by precedent, in cybersecurity, appropriate is demonstrated by the extent and capability of your security program.

Complying with the cybersecurity of the GDPR is simple, every step is written down for you somewhere. There are a few things to bear in mind though:

  1. GDPR is 90% about how you get the data, and what you then do with it when you have it. Anything you spend on security should be justified against the business goals, not a compliance requirement;
  2. There is no cyber insurance against loss of reputation, this should not be about the money;
  3. Any security vendor offering “GDPR Compliance” is at best telling you 10% of the story, at worst, is lying to you.

While I agree it may be difficult to sort through the good advice and the crap when it come to this stuff, there is no excuse for  doing nothing. GDPR and every regulation to come will not change the basics, security will be same regardless.

The issue is not regulation, it’s that organisations still aren’t asking the right questions.

[If you liked this article, please share! Want more like it, subscribe!]

CISO Sacrifice

How to Hire a CISO

In my experience, the hiring of a CISO is one of the last things on the minds of the overwhelming majority of Board of Directors (BoD). Well, maybe more accurately; it’s the last role they want to hire. Who wants to spend money on security? Where’s the ROI? While there is often significant kudos for corporate responsibility, its effects on the bottom line are invariably lost in translation.

I’ve written more than enough blogs on why cybersecurity is so essential to every organisation. Even tried to spell out some of its many benefits, but 180 subscribers will hardly change the course of a multi-billion £/€/$/¥ industry.

However, I will count this blog a HUGE success if I succeed in one, and especially both of the following:

  1. An organisation hires the exact right person for their cybersecurity needs; and/or
    o
  2. A prospective CISO asks all the right questions and gets the right job for them.

By far the biggest challenge for organisations in hiring a CISO is doing it for the right reason(s). Unfortunately the reason, 99 times out of 100, is necessity. From landing a big contract, to regulatory compliance, to post-breach PR, the CISO role is often nothing more than an empty suit. Compound this with the BoD having no idea of the right questions to ask the prospective candidates, the whole thing likely started out with little idea of what they were actually trying to achieve.

Security is not about technical requirements, it is a business process, and until the BoD see it as such no CISO job description (JD) will ever land the right candidates. In security, if you’re not an expert, never ask for what you want, find someone  who can fully detail the things you need. You’d be amazed how often these things are very different.

Steps to Hiring the Perfect CISO

But first, we need to stop thinking about the CISO as a person, CISO is a function. Or rather, a series of projects that culminates in a function. Security begins with a plan, then evolves through several phases into a coherent cycle of business enabling processes. I’ve never met a single individual with either the skill-set, or even the interest, to perform all of these phases. I for one would rather chew tinfoil than babysit something that does not require fixing.

Second, I am going to assume that the hiring of the CISO is going to be managed by the BoD, if not, none of these steps make sense.

Finally, I am going to use the types of CISO I defined in The 3 Types of CISO: Know Which You Need to illustrate my point.

Step 1: BoD must finalise three things: 1) their Mission Statement, 2) their Value Statement(s), and 3) their short / medium / long-term business goals.

Step 2: BoD uses all resources at their disposal to find the right resource(s) to turn the Mission/Values/Goals into an appropriate security strategy.

Step 3: Hire a p-CISO (Planner) for Phase 1 – skill-set prerequisites must include:

  • drafting Governance charters and policy sets;
  • standardising and performing initial risk assessments;
  • controls gap analysis;
  • developing business impact analyses (BIA);
  • defining a basic set of minimum security controls; and
  • chairing a Governance Committee meeting (this is a requirement across all 3 CISO types).

[Once Phase 1 tasking is roughly 75% complete, Phase 2 can begin. the p-CISO will be expected to fine-tune the draft JD for the e-CISO and hand over all relevant knowledge / duties.]

Step 4: Hire an e-CISO (Executor) for Phase 2 – skill-set prerequisites must include:

  • matching Policy Set with both business goals and the prevailing corporate culture;
  • socialisation and distribution of procedure and standard document coordination to relevant SMEs;
  • integration and centralisation of security control output into a unified incident response capability;
  • assignment and formalisation of all security responsibilities; and
  • implementation of disaster recovery (DR) and business continuity planning (BCP).

[Once Phase 2 tasking is roughly 75% complete, Phase 2 can begin. the o-CISO will be expected to fine-tune the draft JD for the o-CISO and hand over all relevant knowledge / duties.]

Step 5: Hire an o-CISO (Optimiser) for Phase 3 – skill-set prerequisites must include:

  • performing an objective review of all security controls including policies (with Internal Audit if available);
  • maintain their aspect of the company-wide Risk Register in-line with the security strategy and business goals;
  • formalise management information and security/risk metrics into a BoD-level reporting process; and
  • implement a cyclical program for continuous improvement.

Sample Phased Approach

That’s it, 5 simple steps. Very difficult and potentially expensive steps, yes, but simple nonetheless. Clearly these steps are VERY high level, and there is a lot more detail involved than that. This process could also take many months or even years. But the hiring of a CISO is not about finding people, it’s about committing to an idea and doing whatever it takes to bring that idea to life.

For that to happen, the BoD must stay involved. For the CISO roles as defined above to succeed the BoD needs to use as much of its influence as necessary to fully support them. A dotted line reporting structure directly to the BoD works best.

In my experience, if you’re looking to hire a CISO to sort out your security, you’ve already started down the wrong path. It’s the CISO who usually ends up paying the price.

If you’ve made it this far, you are probably thinking that the title of the blog should have been: How to Implement a Security Program. And you’d be right, it should, but the people wanting to hire a CISO probably wouldn’t have read it.

[If you liked this article, please share! Want more like it, subscribe!]