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.

Why I Offer a ‘CEO Discount’

A CEO discount is when I offer an organisation a 10% reduction on my consultancy day-rate if they can arrange for a 30 minute, 1-on-1, face-to-face, meeting with the CEO.

Sound like a gimmick? Well, it is partially, I’m trying to run a business, but it’s also extremely beneficial to both sides. Not only that, addresses the most fundamental of all security challenges; management buy-in/support. Continue reading