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!]

Want to Stay Compliant, Work WITH Internal Audit

Internal Audit.

It’s right up there with Traffic Wardens, Used Car Salesman, and Lawyers, isn’t it? You get a phone call from Internal Audit (IA) and it feels like you’ve just been sent to the Head Master’s office!

But why? If you have been doing everything right, following appropriate policies and procedures, have ACTUALLY read the Acceptable Use / Code of Conduct, why would this be any different? I mean, even SECURITY winces at IA, and we’re total pariahs ourselves!

This is unfortunate, because like it or not, every department needs someone to provide checks and balances. Someone who can look at everything with a fresh and objective pair of eyes, someone not answerable to YOUR boss so can tell them how it is without repercussions, someone who can suggest changes that you know should happen, but fear / politics prevents you from saying anything.

Take your pick, regardless of how you view IA, they, like InfoSec, are an necessary evil in a world where both the threat and regulatory landscapes are spinning out of control.

Best practice frameworks like ISO 27001 call for Internal Audit by name, and an ever increasing number of regulators are requiring  evidence FROM IA processes so that organizations demonstrate that they are actually complying with their own policies. This should not be a hardship, if your corporate security culture was adequate, this would not be an issue. Look to the senior leadership, it they don’t care, no-one else will.

I have stated over and over again that if you were doing security properly, EVERY compliance regulation on the planet would fall out the back-end (plus or minus some customised reporting). Not one has ever, and likely WILL never go above industry accepted best practices, as no-one is looking for perfection, just risk-reduction enough.

It makes perfect sense to me therefore that you would put a watcher on the watchers. Security have their fingers in almost every business pie, just to make sure that proper security controls are built in from the beginning. Like Legal, security is there to save the business from itself, and done properly, it should NEVER get in the way.

This can lead to a certain complaisance, or blinkered view of the world, IA can provide the necessary perspective to continually test processes that that could potentially stagnate if not seen through an objective lens. And who knows, because IA generally have direct (if dotted line) access senior leadership, there is a very good chance your requests for budget/resources will be looked on favorably if supported by an entity mostly immune from repercussions.

In this context therefore, Internal Audit is the conscience of Security; Are the controls enough?; Are they too much?; Are they easily measured?; are they flexible enough to adapt to business goals?; etc…

From the very first policy draft, to the almost ubiquitous Plan, Do, Check, Act of ISO 2700X, security professionals need to look to IA for support and guidance, but the opposite is equally true. IA can tend to rely on their unassailable positions to hide behind lack of expertise in security subject matter, they need to work just as closely with security to make sure they are up to the task.

The Automation of PCI Reports on Compliance

If you really want to piss off the PCI Security Standards Council (PCI SSC), show them how you are writing your Reports on Compliance (RoCs) automatically. You’ll find yourself in remediation very quickly.

But why? What possible difference could it make that you say things the same way from report to report as long as the validation of the controls was performed correctly?

For example, let’s take Requirement 2.2.b; “Examine policies and interview personnel to verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.1.

In order to validate that this in place you must perform the following three processes;

  1. Identify the policy documentation verified to define that system configuration standards are updated as new vulnerability issues are identified;
  2. Identify the personnel interviewed for this testing procedure, and;
  3. For the interview, summarize the relevant details discussed that verify that the process is implemented.

So, for 1.,  if you have mapped all relevant documentation to the PCI requirements (which you should) in your RoC Writing Tool (RWT), this will simply be an automated regurgitation of the document names, and hopefully section numbers. If not, you have the relevant documents already summarised in Section 4.10.

For 2., you should already have your personnel mapped against system grouping in your asset register, so again, this is just a regurgitation. If not, you have the relevant group(s) already summarised in Section 4.11.

For 3., this is where the SSC is looking for a true narrative, but all validation relevant to 2.2.b is performed in the same way for each system type, so as long as the QSA and their client are actually doing their jobs properly, the contents of this narrative will be basically the same;

For [asset group]:

QSA interviewed [personnel], examined [documents], and obtained [validation evidence] for [client] [name of vulnerability management process] and [name of configuration standard process], as well as examined production configurations for [sample(s)].

…and so on for each distinct and relevant asset grouping.

A huge advantage of this is that for any asset type you add, the list of related DSS Requirements, and the related validation evidence all become pre-defined and mandatory action items, assigned to an individual. Assuming you have also defined a compliance goal, you will also have due dates. Even further, with a correctly defined hierarchy you also have the beginning of true project management.

Imagine that, with asset management done well, you have an up-front list of EVERYTHING required to achieve compliance, along will full accountability for the collection of the necessary validation evidence. As the target organisation collects and uploads the evidence, the RoC is writing itself in the background, thereby giving full insight into the gaps and level of effort indicators required to either adjust resources, or justify technology or outsourcing investments.

Now imagine how simple APIs could accept information from end-point technologies like A/V for FIM, or from centralised management stations for logging or IDS, or how a simple agent could report against running services / listening ports / registry settings for an operating system, and you are starting to perform the validation itself automatically. Not against PCI requirements, but against your full gamut of corporate policies and standards, all of which are mapped against you asset type. And not annually, but all day, every day.

Forget PCI compliance, this is the type of Continuous Compliance Validation everyone needs, regardless of the data type, compliance regime, or industry sector.

Difficult? Yes. Simple? Always.

Continuous Compliance Validation: Why The PCI DSS Will Always Fall Short

Just about everyone who writes on information security has had ample blodder from the numerous high profile breaches, myself included. Some blame the PCI standards or the card brands themselves, some blame the retailers for not doing enough, and those that are a little more charitable, just blame the thieves.

In the end, it’s not about blame, it’s about learning the lesson, making the necessary adjustments, and moving on responsibly. Unfortunately, this will NOT include being able to move on from credit cards or from the PCI DSS v3.1 any time soon, so organisations wanting to avoid becoming the next Target (excuse the pun), had better pay more attention to their enterprise-wide security program, not just their annual compliance ‘projects’.

Just as importantly, they need to pay VERY close attention to innovation in the payment / authentication space, and advances in more real-time security measures / technologies.

Nothing in the PCI DSS is anything other than a bare minimum, and represents enough security for the card brands to say they are doing what they can. But any organisation who thinks this is enough will eventually lose data, and I for one have no sympathy.

You can look at every single requirement and come up with two choices: 1) Good enough for PCI, and 2) Appropriate for the business. 9 times out of 10, the second option is more difficult to implement, but in almost every instance, it is both easier to maintain, and more secure.

For example;

PCI DSS Requirements 1.X are all about networking, firewalls, segmentation and the like, and while it does stress that every service/protocol/port must have a business justification, it does not state specifically that every individual in-scope device must have least-privilege inbound and outbound rules applied.

  1. 1.1.6.a – Verify that firewall and router configuration standards include a documented list of all services, protocols and ports, including business justification for each
  2. 1.2.1.a – Examine firewall and router configuration standards to verify that they identify inbound and outbound traffic necessary for the cardholder data environment.
  3. 1.2.1.b – Examine firewall and router configurations to verify that inbound and outbound traffic is limited to that which is necessary for the cardholder data environment.

Yes, we can imply it means each device (especially 1.2.1.b), and yes, it’s the right thing to do, but no QSA can enforce anything that is not specifically written within the standard. If they had just replaced “the cardholder data environment” with “each in-scope system” DSS Section 1 would be VERY different, and instil a significantly better security posture.

However, if they DID change it to least privilege for every device, is it actually possible to implement and maintain it? Same goes for more robust configuration standards (DSS Section 2), or real-time logging (DSS Section 10), what should be done is very different from what the DSS requires.

In answer to the question, yes, it is possible, and it all boils down to one thing; baselines

Security is not about crunching big data to determine patterns, that’s only truly relevant in forensics when it’s already too late. Real security is knowing exactly what something SHOULD look like performing normally, and reporting everything outside of that. Keep it simple, or it cannot be monitored, maintained, or measured, but the PCI DSS can never go this far.

Hypothetically, if you knew every running service, listening port, and permitted connections each in-scope device should maintain to perform its function, then anything NOT those things should be investigated. That’s a baseline. Security would dictate that you have alerts based on these anomalies for all systems, not a sample of them and certainly not once a year (point-in-time).

How difficult would it be to automate this process so that EVERY system (not just PCI ones) reports back on a daily/weekly/monthly – or ANY period of time less than a year! – basis to a centralised management console to perform the baseline comparisons? Then what’s to stop you comparing the device’s listening ports to firewall rule sets to make sure they are properly defined? Or comparing them against enterprise policies and standards, or known business data flows?

Not one organisation or security vendor is doing this properly, at least not that I have seen, or not yet. Some vendors do bits of this, but the last thing you want to do is patch together a bunch of separate, non-integrated systems, as the effort to do so will usually outweigh the risk mitigation, or the cost-to-benefit ratio.

However, none of this can happen until you have centralised and accurate asset management, and seeing as the PCI DSS just added that as a requirement in v3.0, most organisations have a long way to go before they can ever achieve this ultimate in security; continuous compliance validation.

Continuous Vulnerability Management: Security as a Baseline

Ask 100 security ‘professionals’ what vulnerability management is and at least half of them will begin with patching, another 25% will focus on vulnerability scanning and penetration testing, and the majority of the rest will start quoting the gamut of Risk Assessment to Business Continuity. I’m not saying they are wrong, but most will not be right enough.

If you accept this description as standard; “Vulnerability Management is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities, especially in software and firmware. Vulnerability Management is integral to computer security and network security.“, it’s no wonder that actually performing appropriate vulnerability management is a concept rife with misinterpretation and bad decisions.

The old adage; “You can’t manage what you can’t measure.”, while often incorrectly interpreted from the original work of W. Edwards Deming, is actually completely relevant in information security. Security is series of baselines / whitelists /  known-goods, and is only ever effective if it’s simple and repeatable. In other words, if you don’t have a point to measure security from, how can you possibly know if it’s enough, or too much?

Like every process in security, vulnerability management  is only as good as the context in which you place it, and ANY security process out of context from the underlying business goals is doomed to failure. Rightfully so. The vulnerability management controls you put in place relevant to your environment therefore go through the exact same process as every other control, from firewalls to outsourcing.

Step 1: Determine your business goals – in order to conduct an appropriate Risk Assessment (RA) and Business Impact Analysis (BIA)

Step 2: Conduct a gap analysis – to determine the shortfalls or over-extensions between current security capability and desired capability

Step 3: Fill the gaps – to the capability level determined by the BIA (accept residual risk)

Step 4: Determine appropriate baselines – for the management, maintenance and monitoring of the ‘new’ infrastructure/processes

Step 5: Place appropriate ISMS-esque controls – around the ongoing management, maintenance and monitoring of the new infrastructure/processes

Step 6: Develop appropriate mechanism for the decision making process – from responsibility / function, to scoring / rating, to mitigation, everything must be in-line with Step 1 in order to be effective and sustainable

Step 7: Determine all control inputs to the process – including – and certainly not limited to – patching, vulnerability scanning, penetration testing, code review (if applicable), logging, FIM, and so on…

Step 8: Determine all appropriate internal and external sources of threat intelligence  – from relevant vendors to paid-for services.

Step 9: Bring everything together into a Management capability – one with a specific charter and report structure.

Step 10: Re-examine every step for continued relevant and effectiveness – on a regular basis

If this sounds complicated, it’s likely that you don’t understand one or several of the steps. All aspects of security are simple, they have to be, and while is can be difficult to implement, that’s almost always because you are not asking the right questions. In any endeavour outside of your business’s core competencies, the trick is not to ask for what you think you need, it’s to ask for help from someone who KNOWS what you need.

You don’t tell your doctor you have a brain tumour, you tell them you have a headache a leave the diagnosis up to the expert.

[Ed. Written in collaboration with Voodoo Technology, Ltd.]