Virtual CISO

Are ‘Virtual CISOs’ a Good Idea?

Type “virtual CISO” into Google and you’ll get ~240,000 hits, with the top 10 being mostly vendors who offer this as a service. I have no doubt much of the remaining pages are the same.

In other words, just about every security vendor out there is seeing a need, and they want to be the ones to fill it. As a corollary, if organisations weren’t crying out for the service, no-one would be offering it.

I am no different, in that I too see a massive gap in senior leadership security expertise that no one in-house can fill. Due to price constraints, it is quite often inappropriate to fill such a senior and specialised role on a full-time basis. Where I differ is the length and function of the v-CISO, as I cannot see how an indefinite ‘outsourcing’ is in my client’s best interest.

Let’s face it, once you outsource the function of something, it is a very small step to try and outsource the responsibility for it too. And finally, if you got away with that, an attempt at shirking the accountability is never far behind. This is where both organisations asking for help, and v-CISOs alike, make their biggest mistake.

The v-CISO should never be a long-term proposition, which is why I call my service an ‘Interim Security Chief’. While this may seem like semantics, it’s the difference between doing the work for you, and enabling you to do it for yourselves.

First and foremost, a v-CISO should be a teacher and a mentor, not [necessarily] a ‘doer’. Yes, they can design big-picture processes, from secure architecture to governance charters, but they had better not be expected to own them. A good v-CISO is nothing more than an consultant at the senior management level, and any deliverables must be sustainable long after they have moved on.

That said, I see nothing wrong with a v-CISO remaining part of ‘steering committees’, providing ongoing security awareness training, or even taking part in incident response testing. But, once the CISO functions have been absorbed internally, the v-CISO becomes part of the cycle for continuous improvement only. They stay around to provide strategic input on industry trends and the changing threat landscape, they don’t dictate the enterprise goals.

What You Should  Expect From a v-CISO

These are the three main things you should expect from a v-CISO, take particular note of the transience of each deliverable.

  1. Governance Charter Development – There is no security program without Governance, and there is no better platform onto which the v-CISO can pass on their operational function. This committee can in fact replace the v-CISO in due course, but may bring them back in as a trusted advisor or SME. The members of the governance committee will share the CISO function amongst themselves based on individual capability, and their meetings will bring it all together.
    o
  2. Policies & Security Awareness Training – Along with governance, policies are intrinsic to a security program, and along with the formation of that committee, represent the most important part of a v-CISO’s role. Unless the polices are in place, and all employees appropriately trained, nothing else they try to do will work effectively.
    o
  3. Process Development – Security programs consist of a number of critical processes, all of which must be developed, tested, tested again, and take their place in the never-ending cycle of improvement and business as usual. These are the big ones:o
    • Risk Management – Includes the enterprise-wide risk assessment and risk treatment procedures.
    • Vulnerability Management – Keeping up with the threat landscape.
    • Vendor Due Diligence & RFPs – Significant aspects of the security program will likely be outsourced to skilled providers, so the right questions must be asked.
    • Event Management & Incident Response – Bringing all the controls together into a business saving process.
    • Disaster Recovery & Business Continuity – What to do if everything goes completely pear-shaped.

Anything else the v-CISO does will depend on the organisation’s needs and the v-CISO’s skill-set.

But what about Strategic Advice, Board Level Interface, Regulatory Compliance Lead and a whole host of other fancy names / clichés? Yes, these are all important, but are utterly meaningless until the basics are in place.

Any security program put in place by a v-CISO must be in-line with the business’s goals, appropriate to their needs, and sustainable in their absence. So if you’re on the market for a v-CISO, you had better know what you need, or you’ll get what a salesperson thinks you asked for.

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

What is a Security Program?

It occurred to me that after 15 years of consulting, 10 years of public speaking, 3 years of blogging, and saying things like; “All regulatory compliance falls out the back-end of a security program done well.” and; “If you fail to develop an appropriate security program, it’s the CEO’s fault and no-one else’s.” that I have never actually defined what I consider to be a good security program.

In my defence, a good (i.e. appropriate) security program is as unique as the organisation trying to implement one. However, like any other discipline, there are basics that ALL security programs must have to be successful.

All of the best security experts on the planet pretty much agree on these basics. But just try looking for something you can apply to your business and you’ll soon be as confused as I am when trying to read anything written by a lawyer. Regulatory compliance, greedy product vendors, incompetent consultants and a whole host of other factors conspire to take security out of the hands of those who need it most.

Nothing I am about to write has not be said by me many times over, or by a thousand others much smarter than me, but for some reason it never seems to stick. As much as I hate the concept of rebrand-it-to-sell (e.g. a ‘service on the Internet’ is now called The Cloud), I can see the attraction. If we could make security ‘sexy and new’, perhaps we’d have an easier time bringing back the basics. 99% of security lives and breathes in the basics.

For example, everyone knows that there is no security program without senior leadership support (i.e. CEO). This is free, takes a fraction of a percent of the CEO’s time per calendar year, and has benefits well beyond anything you can imagine. But try getting it.

Anyway, on with the program detail, but first; If you don’t believe that a security program is a balance of People, Process, and Technology, stop reading, this will all be lost on you.

8 Steps to an Appropriate Security Program

o

  1. Senior Management Support – Been over this a million times. If you don’t have it, stop here, you’re wasting your time. Can you have some security without it? Yes, but guess who will be blamed when things go wrong.
    o
  2. Governance Committee – Senior stakeholders who will run the program with the full and visible support from senior leadership. Governance runs everything from risk assessments to change control, and without this centralised function your security program will collapse like a flan in a cupboard.
    o
  3. Policies & Procedures – Again, if you don’t know by now how important this one is, don’t bother reading the rest, you’ll never understand.
    o
  4. Risk Management – The primary function of the risk management is to ensure that all security controls meet the organisation’s risk appetite. Risk Assessment, Business Impact Analysis, Risk Treatment, and the Risk Register all sit here.
    o
  5. Appropriate Security Controls – No, I do NOT mean technology! Technology supports security, it does not define it. Your controls will be a direct result of the risks determined by Governance, and the requirements as defined in your policies (requirement for hardening guides for example). Technology purchases are the last resort.
    o
  6. Vulnerability Management / Change Control – I don’t lump these together very often, but from a program perspective, they have similar results. i.e Don’t make things easy for the attacker by a) ignoring the evolving threat landscape, and b) introducing potential vulnerabilities without due diligence respectively.
    o
  7. Testing Program – Test everything, then when you’re done, go back and test it again. Repeat. You simply have no idea whether or not your security program is working until you test it. Test results feed back into everything done before it in order to make the necessary adjustments.
    o
  8. Security Awareness & Training – Again, if this makes no sense, you’re reading the wrong blog. None of the above works unless EVERYONE knows what part they play.

That’s it. Finished. there is nothing more to do for any organisation to develop an appropriate security program. Nothing here is complicated, perhaps that’s why people ignore it, it’s just not dramatic enough.

However, making this process simple can be extremely difficult, as is getting the program in place, and these difficulties should not be underestimated. It’s the difficulty, not the complexity that ruins most security programs, especially when you don’t have the support you need.

FWIW, done well, a security program based on the above will not only make you more secure than most of your competition, but give you demonstrable compliance with every regulation out there. How’s that for an ROI?

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

An Agile Security Program? I Don’t Think So.

In my vast experience of the Agile Methodology (just over a month now), I have managed to go from a proponent (as in Running PCI as an Agile Project?) to someone who is rather more circumspect when the objective in question falls outside the realm of a short-term project. An easily defined short-term project at that.

In other words, NOT a soup-to-nuts security program.

The overused adage; “If all you have is a hammer, everything looks like a nail.” is particularly relevant here, as Agile proponents have actually gone looking for nails to the point where some security ‘professionals’ are designing their entire program around this single tool! Being generous, this shows a spectacular naiveté,  at worst, it shows a complete ignorance of what constitutes a sustainable and effective security program.

And to be clear; Agile is a tool, nothing more. It is not a philosophy, it’s not even a framework, it is used for very specific requirements at very specific times for an easily quantifiable result; like a new user interface, a segmentation project, or even the installation of a centralised logging technology. Where it make absolutely NO sense is the exact place a good security program starts; with the culture.

The implementation of a good security program has always been, and will always be, more art than science, and completely dependent on the prevailing culture, a culture defined by the CEO’s attitude towards it. In other words, trying to implement a security program AND instill a culture at the same time with nothing more than a single tool, is no different from trying to build an entire house with just a hammer. It simply does not work that way.

Also, those focusing on Agile tend to come from a highly technical background and therefore focus on technology over process, which just compounds the problem to the point where any short-term gains will be built on nothing but air (like my sandcastle ‘metaphor’). Technology is critical for the automation of KNOWN-good processes, it can never be the solution in and of itself.

In one of my first blogs I posited that there are only Four Foundation of Security:

  1. Management Buy-In / Culture
  2. Policies & Procedures
  3. Governance
  4. Education & Training

…I would now actually add a fifth; Vision (or perhaps just include it in the first one), as it’s the CEO’s vision for the organisation that will drive the development of an appropriate security program.

Assuming you agree with the Foundations, perhaps you can now see how using Agile for any one of them is utterly meaningless. Implementing two week sprints and daily stand-ups to ask whether or not the CEO has signed-off on the security policy framework, or if all relevant staff have taken their annual awareness training, makes no sense whatsoever.

In the development of a security program, a competent security practitioner at the CSO / CISO level would usually follow these steps (gross oversimplification):

  1. Get the CEO to agree to take an active role in the program’s implementation / socialisation. Get this in writing.
  2. Define the governance framework to get all relevant senior stakeholders to the table. Have the CEO ratify it.
  3. Draft Information Security Policy Framework for the policy committee’s review and approval. Have the CEO sign it.
  4. Distribute the relevant policies to the right people as part of the socialisation and initial training exercise. Have the CEO visibly endorse it.
  5. Implement an ongoing awareness program to solidify the culture changes. Have the CEO evangelise it.

If you can’t even get the first step in place, you needn’t bother with the rest, as no matter what you do your security program will collapse under the weight of indifference.

No tool is going to fix this, certainly not Agile.

Buzzwords Are Killing Real Security!

If you’re a security professional and there’s a new phrase or product going around with which you are unfamiliar, there’s a better than even chance you won’t need that thing. Ever.

The reasons are myriad, but the major offenders are:

  1. It’s something that product vendors invented to scare you into thinking you’ve missed something; [e.g. Advanced Persistent Threats]
    o
  2. It’s something Gartner was paid to promote into a magic quadrant of some sort, [e.g. most of Gartner’s output]
    o
  3. It sells column inches, or;
    o
  4. It’s something you already have but now it has a sexier name. [e.g. Logging and Monitoring is now Security Incident and Event Management (SIEM)]

For me, this pet peeve started with ‘The Cloud’. Suddenly everything had to be “In The Cloud”, that adoption of Cloud-based services was the only way to stay up with your competition …blah blah blah. Basically The Cloud was the only way you were going to stay in business in the digital age.

“But wait David!” I hear you gasp; “Isn’t The Cloud just an application on the Internet? Haven’t we had this capability for, I don’t know, DECADES!?!” Why yes Dear Reader, we HAVE had this capability for decades, but clearly you didn’t know you needed it until it had a fancy name and had vendors shoving the concept down your throat!

I know of organisations who quite literally renamed their ‘Managed Security Services’ to ‘Cloud Security Services’ without changing a SINGLE piece of infrastructure or a single process. And yes, this hid all manner of sins, but for some reason the new name stopped clients asking difficult questions like; “Can you tell me how it works?”

By sheer coincidence, I gave a webinar last week titled “Ignore Future Attacks, Fix Your Broken Security Program First”, it could just as easily be called “Ignore Buzzwords, Fix Your Broken Security Program First” and the content would be almost identical. We need to stop focusing on the new when we usually don’t even know what assets we’re trying to protect, who has access to what, or what any given system should look like from a normalised perspective.

Business needs information in context in order to compete, and the data that makes up that information is stored somewhere on a physical system. I don’t care if it’s virtualised, containerised or whatever-ised, it’s still a piece of hardware running an operating system sitting in a room somewhere (yes, I know it can be distributed). Nevertheless, there is NOTHING you need outside of an established good security practice to protect this data from what’s out there now, and what will be out there in the future. REGARDLESS of its name!

Segmentation, configuration standards, access control, logging and monitoring and a host of other old fashioned and boring names all boil down to one thing; baseline. What should a system look like all day every day, and how do I report anything different. No innovation in security capability (i.e buzzword) will be of any use whatsoever if you don’t have the basics right, because you’ll have no idea what you have, let alone how it should normally behave.

Ignore the hype, ignore the press, ignore Gartner and their ilk, focus on the stuff that you’ve likely relegated to a ‘previous generation’s problems’. They are still your problems too.

Privacy Shield (ex. Safe Harbor), Here Come the Vultures!

You can almost feel it happening, can’t you? Every time there is an introduction of, or a change to some regulation or another, the vultures of the legal, security consulting, and even security product vendors spin up their marketing machines to invent new promises on how they will ‘guide you through the pending minefield’.

The thing is, I in no way blame them. I’ve likened selling security to selling insurance, in that no-one WANTS to buy something that seems to have absolutely no tangible benefit to the bottom line (it does though; How Information Security Enables Transformational Change). This results in a vast majority of organisations taking extreme liberties with the terms ‘reasonable’ and ‘appropriate’, which is as specific as most regulations go in terms of meeting their requirements.

Unfortunately, regulations are written by lawyers, who have a language all of their own. How is an IT Director supposed to translate legal-ese into geek-speak without some help? That’s where a PROPERLY run security program comes in; the translation become almost unnecessary.

I have made statements like this many times; “If an organisation was doing security properly, they would already be [enter regulation name here] compliant.

Bold statement, but think about it this way:

  1. ALL information security and most compliance regimes relate [at least in part] to the protection of data
  2. The principles of information security have not, and will not ever change
  3. NOT doing these basics is the fault of the organisations, not the regulators (except PCI)

The only thing that’s different from one compliance regime to the next is how you report what you’re doing. PCI requires a very detailed (though mostly meaningless) controls-based Report on Compliance, SoX and HIPAA require something else, and the old Safe Harbor just required a SELF-assessment (and you wonder why it failed…).

Regardless, the underlying validation evidence is the same; policies, procedures, standards, operational integrity, incident response and so on. You are either doing these things or you’re not. And let’s be clear, you should be.

“But they’re moving the goal posts!” is a complaint I frequently hear, and is usually the foundation of an excuse to do nothing. Just because YOU don’t know where the goal posts are doesn’t mean they’ve moved. All that really happened is that every time a regulation comes out and they ask for more and more detail / accountability / transparency etc, it further exposes the fact that you weren’t doing things properly in the first place.

The General Data Protection Directive (GDPR) for example is freaking organisations out with its potentially enormous penalties. Penalties for what? Not using data for its original intent? Not obtaining explicit customer consent? Not LOSING the data in a breach? How is ANY of that unreasonable!?

OK, so the above is a gross simplification of the GDPR, but it’s not far off, and frankly, Privacy Shield will be even easier. If your organisation is not in a position to meet the intent of these data privacy regulations, then you are part of the reason they exist in the first place. And if your security program is in such a state that the vultures have easy picking over the carcass of your IT budget, that’s your fault too.

Non-compliance with any regulatory requirement relevant to data protection is just a symptom of the same underlying problem; a crap security program. Fix that, worry about the reporting afterwards.