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

How to Lose All Credibility in Cybersecurity

There are some things in life that you assume everyone must know by now; give a firm handshake, never accept credit for someone else’s efforts, never be rude to waiters and so on. Yet so many vendors in the information security industry fall foul of an offence far worse than these.

They use phrases like:

  • 100% secure
  • Unbreakable
  • Completely safe
  • Fraud-proof
  • Hack-proof
  • and so on…

The fact remains that NOTHING in information technology is 100% secure. Nothing. If someone wants it badly enough, and they have the necessary skill-set/support, they are going to get it, and anyone who espouses differently should find another line of work before they cause any[more] damage.

And it’s all so unnecessary. You don’t need 100% security even if it was possible, what you need is security ENOUGH. The bad guys are lazy, and if you’re too difficult to breach they will move on, so just ‘build your fence higher than your neighbour’s’ From what I’ve seen in the 15 years I’ve been consulting across the globe, this should not be too difficult.

The calculation you have to make is this;

If the Cost of Security > Value of Data = do what you can afford and no more, OR, if the Cost of Security < Value of Data = do it, but do only what makes sense.

So what process magically gives you the answers to this equation? Easy, the Risk Assessment. One of the most basic tenets of a security program done well, and one of the most under-utilised business tools in every organisation I’ve helped. A risk assessment process performed appropriately will tell you what you’re not doing well, how to fix it, AND how much to spend on doing so.

But I digress.

I can actually empathise with organisations and individuals trying to sell security. It’s tough, but that’s no excuse for lying about your products, and that’s exactly what you’re doing if you claim 100% security. Lying. You have a responsibility to your customers, and whether you like it or not, and whether you ARE or not, you are the usually the expert in the room (if you know 1% more than the other person you are the expert). Your client came to you for help, it’s up to you to provide what they NEED, not necessarily what they asked for.

Your credibility as a provider of information security services or products goes hand-in-hand with your integrity as an organisation and/or individual. Think of your integrity as a form of currency; you can either invest it in your credibility, or spend it on quick wins. Only one of these has a long-term future.

I will note however that if you’re a buyer of security services, you have as much responsibility as the seller to buy only what you need. YOU must ask the right questions, and the only way you can do that is to either do your homework, or hire someone to do it for you. Never expect a salesperson to think twice about giving you what you ask for, then charging you again for providing what you should have asked for in the first place. This scope creep is your fault as much as theirs.

This white paper is not how to sell, I can’t do that, this is how I think you sell with integrity; How to Sell Security

PCI – Going Beyond the Standard: Part 1, The Risk Assessment

In this, my first instalment of the PCI DSS ‘Going Beyond the Standard Series‘, I will begin where not only every PCI assessment should begin, but where the development of every security programme should begin; the Risk Assessment.

Just because you take branded cards, or in any way transmit process or store cardholder data, does NOT mean you should drop what you are doing and dedicate an enormous chunk of your IT capital or manpower resources into achieving certification unless a) there is a distinct business benefit for doing so, and/or b) you are actually increasing the security posture of your entire business.

PCI is not about compliance, it’s about not losing cardholder data.

Compliance with the PCI DSS does not equal security, and security out of context has no business benefit. Either start your PCI program with an eye to staying in business responsibly, or don’t bother.

Also, there is a very good chance that taking card payments is not core to your business. If you’re a retailer, your core business function is to sell things, taking payment is just a means to that end, so the payment acceptance channels in your business should be simple, inexpensive, and secure. If you can do this well yourself, great, if not, why take the risk? And can you truly innovate away from credit cards if you have to do all the work yourselves?

Should you decide that your existing payment channels are fit for purpose, the second question to ask that is how much should you be spending to fix / mitigate / transfer / remove any problems. i.e. a Business Impact Analysis. You would not spend £100,000 to protect £1,000 worth of data, but you likely would the other way around. Do you know that balance for your organisation? From my experience, the answer is usually no, and countless hours and capital are/is lost chasing a goal that was never properly defined.

That said, in terms of PCI, if you were doing security properly, you would already BE PCI compliant (mostly anyway), so it makes sense to just focus on security first and achieve compliance in your own time. As long as you have a reasonable project plan to show your acquirer, report your progress on time, and actually work towards your plan, you will pretty much get as much time as you need to get there. It’s the organisations that couldn’t care less, or are egregiously lax in protecting cardholder data that get the negative attention, and possibly the fines.

Sadly, along with Policies & Procedures, the Risk Assessment is often one of the last requirements to close during a PCI assessment, when, if they were in place at the beginning, the cost, the level of effort, AND the effort to sustain compliance would all have been cut in half.

However, the issue is that most organisations do not have internal resources qualified to perform, or dedicated to, this task. It’s far too specialised, and has never been seen as a true value-add to the business. And unfortunately, the resources available to you in the QSA consulting arena are on the whole inadequate to the task of doing anything other than a PCI ‘audit’, so unless you know security, you would probably not even know the right questions to ask.

I probably should have made choosing the right QSA / consultant for your business the first of this series, but I have basically covered those in previous articles / white papers;

  1. How to Sell Security: While designed primarily to help salespeople in the information security arena, it doubles as a paper for anyone looking to BUY security services.
  2. Selecting The Right QSA For Your Business: This could just as easily be called ‘Questions For Your QSA Request For Proposal (RFP)’ as getting the help of a real security consultant and not ‘just a QSA‘ is critical.
  3. It Takes a Consultant to Hire a Consultant: One of the most difficult aspects of choosing the right help for your organisation, which begins with asking the right questions.

Bottom line; If you haven’t performed a Risk Assessment, go back and do it, and if you cannot do this yourself, find someone who can.

If you don’t know the right questions to ask, ask someone who does.

DSS v3.0

DSS v3.0 – Nothing New, If You Were Already Doing PCI Properly

Now that I’ve had the opportunity to review the full draft standard, it’s clear that there’s very little that’s difficult for you to achieve in the short term if, and I mean IF, you were doing PCI properly from v2.0 onwards. The majority of the changes are simple clarifications, and if your QSA was doing their validation and QA correctly, you would already be doing 99% of them.

That’s really all v3.0 is; a closer approximation to the Report on Compliance (RoC) scoring mechanism that’s been around for years. I understand the clarifications and the guidance are supposed to bring everyone’s understanding of the INTENT of each requirement into closer alignment, but all that does is reflect very badly on the current quality of the QSAs and the available guidance.  The corollary is that the QSA and ISA training needs some serious attention, and the DSS needs to focus less on the detail, and more on the senior management buy-in.

I also understand that it is VERY difficult to make dramatic changes to a standard when organisations have already invested significant capital and resources into achieving compliance. But even the SSC made it VERY clear from the beginning that the DSS was a MINIMUM set of controls around a single form of sensitive data, and should not be seen as a security programme that meets the entire business’s needs (per the PCI DSS v3.0: “PCI DSS comprises a minimum set of requirements for protecting cardholder data…“).

So why aren’t the changes in v3.0 more significant?  Or more in line with good practices?  I don’t really have a constructive (a.k.a. non-soapbox) answer to that, so I’ll focus on what I perceive to be the major flaws.

Here’s my Top 3 Flaws:

Governance:  This has as many definitions as there are people defining it, but in the end it’s very simple; Governance is the Business side and the IT side having conversations.  Business has the requirements (growth, profit, transformation etc.), IT has the enablement, and the organisation as a whole moves forward appropriately. Nothing should happen in an organisation outside of this framework if the business wants to grow/innovate/adapt effectively (for more see Security Core Concept 4: Governance & Change Control and Security Core Concepts: Tying it All Together)

Guess how many times the word ‘Governance’ (or equivalent) appears in v3.0?

Not once.

Risk Assessment (RA): The whole business/IT/security life-cycle starts with a risk assessment.  The business wants something, the RA determines the balance of risk/reward, and you move on to implementation if the balance is favourable.  The DSS calls for a RA, but it’s still woefully understated, and stuck down in the ‘paperwork’ section (Section 12).  This should have been performed even before you chose a QSA, should be intrinsic to services you eventually receive from them, and should have driven all purchase(s) of technology used to achieve both compliance and security in general (for more see Security Core Concept 1: Risk Assessment / Business Impact Analysis).

The Risk Assessment even had its own Special Interest Group (SIG) to improve the quality of the guidance, but the results were so watered down as to be ineffectual.

Sampling: MUCH better explanation than previously, but it’s missing the most important phrase; “There is no sampling in PCI DSS validation unless the client can reasonably demonstrate how all ‘like’ systems are configured and maintained identically, managed and monitored centrally, and are promoted into production through a well defined and documented  process.”

For too long sampling has been seen as a right, it’s not, it’s a privilege (like spandex). Saying “Sampling is an option…” is not enough to avoid clients demanding ‘pragmatism’ from their QSAs in the ‘this-is-too-difficult’ sense of the word.

I have so much more to say, and some of it is actually positive (like pushing policy enforcement validation), but I’ve already overrun my self-imposed word limit.

Finally, every organisation that relies totally on PCI for their security deserves to be hacked – sorry, but you do – but the SSC and the card brands still have an obligation to do more to evolve the standard into something that can be integrated seamlessly into an established, and comprehensive good-security-practice framework.  By the time the DSS catches up with the real world of security, payments will have moved on from payment cards.

Just ask any non-QSA security expert what you should be doing with your IT budget, I’ll bet it’s not PCI compliance.

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

Security Core Concepts

Security Core Concepts: Tying it All Together

With number 6, I completed my Security Core Concept series:

  1. Security Core Concept 1: Risk Assessment / Business Impact Analysis
    • Management buy-in
    • Examine your business processes 
    • Valuate and prioritise your data assets 
  2. Security Core Concept 2: Security Control Choice & Implementation
    • Perform gap analysis to determine control weaknesses
    • Mitigate control gaps based on priority
    • Think twice before throwing technology at a gap, perform robust vendor diligence if you do buy anything
  3. Security Core Concept 3: Security Management Systems
    • Make sure your controls are working
    • Begin control optimisation and measurement
    • Begin PDCA cycle 
  4. Security Core Concept 4: Governance & Change Control
    • Management buy-in
    • Interdepartmental co-operation and communication
    • Manage all business process and changes
  5. Security Core Concept 5: Incident Response (IR) & Disaster Recovery (DR)
    • Know what your baselines are
    • Standardise, centralise, and monitor
    • Test it, test it again, and keep testing it until everyone knows their part 
  6. Security Core Concept 6: Business Continuity Management (BCM) & Business As Usual (BAU)
    • Management buy-in (yes, that’s the THIRD time I’ve said that)
    • The goal is not security, it’s staying in business securely
    • BAU is where the true value of the core concepts is realised

…and have hopefully expressed in enough detail, the advantages of not only each of these steps, but of a security program ‘done right’.

What I have only alluded to, but will now examine in greater detail, is how the 6 Core Concepts make any regulation / standard / framework related to data security an afterthought.  Not that they aren’t useful, nor can they be ignored, but you’d already be ‘compliant’ with them.  The concepts themselves have been around for generations, and there are many treatises on each and every one.  There are even entire institutions dedicated to perfecting single concepts, but it’s only when you combine them all in a manner appropriate to YOUR business do they make sense.

I’m also talking about the fact that not one regulation the world-over goes deeper, and/or broader in their data security requirements, than you need to go for your business. They can’t, as the very names ‘standard’ and ‘framework’ automatically preclude, provide complete relevance to your organisation.  Nor can they possibly cover every nuance of every business type, sector, and culture.

What these regulations are trying to accomplish – but none state this outright – is a shift in culture away from function/profit only, to security enabled function/profit.  All 6 core concepts are basic fundamentals of security, yet are mostly ignored for reasons innumerable.  I hesitate to use the phrase business responsibility – I have enough issues with sounding like a lecturer – but that’s what it amounts to; you are responsible to protect the data in your possession.

But can you imagine going about your business, secure in the knowledge that no matter what security requirement or regulation gets thrown at you, you are already there!  Maybe not entirely, but the adjustments will be minimal, and will never require the level of effort that even PCI requires from you year after year.

In a nutshell;  If you do security properly, you will ALREADY be compliant with the security requirements of PCI / HIPAA / PoPI / SoX / SSAE-16 / GDPR / Swedish Personal Data Act / …and so on!

No more multiple annual audits / assessments (assuming you have some form of GRC tool), you will not only be compliant ALL the time, you can easily VALIDATE your compliance!

But none of this will be possible if your CEO doesn’t believe in it.  One again this phrase applies;

The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities.  If the organisation fails to achieve [enter business goal here], it’s the CEOs fault, and no-one else’s.

It does not matter what the goal, from PCI compliance, to great customer service, to an ethical salesforce, to a security culture that enables to business to grow responsibly, it’s the CEO who is responsible. And accountable.

I am pulling the following from where the sun doesn’t shine (no, not Scotland), but I would estimate that any time the CEO spends evangelising an appropriate security culture will be paid back 100-fold in terms of resource / capital / DR cost savings.

And it’s all so simple.  Not easy, but it is simple.

It may take years, even in smaller organisations, but the major costs are all front-loaded, and the long-term savings way in excess of the annual costs associated with constantly reacting.  Security is only effective if it’s mostly pro-active, and that’s exactly what the 6 Core Concepts are designed to do.

Don’t know where to start?

Ask.

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