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

Risk Assessment

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

In this, my first installment of the PCI DSS ‘Going Beyond the Standard Series‘, I will begin where not only every PCI assessment should start, but where the development of every security program should start; 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 compliance. 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. Payment acceptance channels in your business should therefore 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 what that balance is for your organisation? From my experience, the answer is generally 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, Standards & 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 AND level of effort to sustain compliance would 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 that 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.

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

Security Core Concept 1: Risk Assessment / Business Impact Analysis

This begins a series of posts related to my theory of The 6 Security Core Concepts. I am assuming that The 4 Foundations of Security are either already in place, or at least being addressed in parallel.

So, in terms of cybersecurity, what is a risk assessment? According to Wikipedia it’s; “…the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized threat.”

NIST SP800-30 Revision 1 states; “Risk assessments are used to identify, estimate, and prioritize risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation and use of information systems.”

Great David, now what? I know what a risk assessment is, I just don’t know how to do one!

There are 5 golden rules of conducting a risk assessment;

  1. Get Management Buy-In – I know, surprising huh?;
  2. Agree on the Scope – region, department, business line, compliance regulation etc. Keep it simple or you’ll never finish;
  3. Agree the Methodology & Deliverables – whether you use something based on methodologies such as NIST or OCTAVE, or a combination of many, agree the method up front and stick to it for ALL of your risk assessments;
  4. Agree the Timeframe – from the beginning to the delivery of the results stick to the agreed timeframe, even if you’re not finished.
  5. Get Started! – don’t get caught in ‘analysis paralysis

Once these are agreed, start your interview process, and again, don’t over-complicate this. Each department is going to have a different take on what’s important, and it’s not your job – yet – to argue priorities. You simply ask them what they consider to be the major threats to the business (from their perspective), and what is the likelihood of that threat being realised.

Bear in mind, this will not just be IT threats – IT does not corner the market – but it IS a big chunk of them; malware, data theft or other loss, network outage, Internet outage, server crash and so. That said, even such concepts as operational resilience have a majority foundation in IT systems, so that’s why the IT department have traditionally – and incorrectly – owned this process (if it exists at all).

Done correctly, the risk assessment will be driven by the Governance Committee (Core Concept 4), and have equal input from both the IT and the business sides. If not, it won’t have the management buy-in I go on so much about.

Once the data is collected, it must be put into some kind of perspective. This is where the words quantitative and qualitative come into play. Only very mature risk management processes should attempt quantitative, it’s simply too difficult for most organisations. Qualitative allows for better adoption by non-technical personnel, and will most likely speak better to the immediate needs of the business; i.e. reducing risk.

Assuming you’ve chosen qualitative, you must still put some value on the identified risks; 1 -5, 1 – 100, high-medium-low etc., as well as some indication of its likelihood of occurrence. For example; a planetary implosion would be catastrophic, but VERY unlikely. The payroll server going down has much less impact, but will occur more often, so should be the priority in this ridiculous example.

Now that you have your risks ranked in terms of impact and likelihood, you need to put some kind of monetary value on each in order to put the final prioritisation against it. It is VERY difficult to put $/£/¢ values against these risk rankings, but unless you do, you can’t prioritise, nor can you set the baselines required in your operational resilience (OR) / incident response (IR) / disaster recovery (DR) plans.

For example, if your e-commerce sites makes 100% of your revenue downtime is not an option. Therefore you not only need full redundancy in your systems and apps etc, and real-time monitoring of system health, you also need extremely robust SLAs against your 3 party vendors (hosting facilities etc.). Only this will ensure that both IR and DR processes are in line with your Business Continuity Management (Core Concept 6) plans.

You have those, right?

If it is determined that the risk is just too great for the organisation to stomach, you will move on to the next step in the process; Security Control Selection & Implementation (Core Concept 2). You will start by performing a gap analysis of your infrastructure to see where the gaps are between your current capability, and the agreed standards accepted by management in the risk assessment phase.

The purchase of technology is always the LAST resort! Business process review is the first, enhancing the capability of existing infrastructure is the second. Rushing to throw technology at gaps can lead to bigger problems as I have suggested in Insecurity Through Technology.

One of the themes I have running through my posts – other than the terrible grammar – is the concept of how not knowing where to start often leads to organisations doing nothing at all. As in every other instance, the way to avoid this issue is to ask the people who DO know. A good consultant will not only be able to help you design a risk assessment methodology for your organisation, they will be able to teach you to run it yourself. Remember, the role of your consultant is to teach, not just do.

Finally, like every other business process, the risk assessment methodology should be standardised across the enterprise so that the results are compatible with the business culture and comparable against each other. However, they should also be reviewed at least annually, or after significant organisational, change for continued suitability. As your organisation changes and adapts to the future business environment, so must your risk assessment keep up in order to stay relevant, and useable.

This post is not meant to tell you how it’s done (there is an infinite variety of risk assessment methodologies), but to ease the confusion that is still prevalent. Hopefully I have done that enough that you at least begin to ask the right questions.

Like all security, the risk assessment is simple, not easy, but simple.

To summarise;

  1. Don’t do ANYTHING until you’ve conducted a risk assessment, and this includes starting your PCI compliance project (if applicable). This is beginning of all security, and the initiation of all future business plans;
  2. Don’t over-complicate it, just choose your target, set a time goal and stick to it. Whether you are finished or not isn’t important, you can always get back to it later and reducing your risk as soon as possible is more important;
  3. Get an expert in the first time, learn from them;
  4. Don’t BUY anything until you know where it fits in, and how you’re going to manage it; and
  5. Unless the solutions you choose costs well under the estimated value of the data, don’t buy them, it’s career limiting.

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

It's Not All Bad, Right?

Why PCI Isn’t ALL Bad

Anyone who’s worked in PCI for more than 5 minutes knows it has serious limitations with regard security. Even security of cardholder data, which is the only type of date to which it relates!

That’s because PCI DSS was not written with comprehensive security in mind, or would not start and end where it does.  It was designed to be security-enough to keep the US Federal Government off Visa/MC/Amex/et al backs.  You would not be surprised to hear that things like this generally happen when someone important is inconvenienced.  In this case, a couple of senators were the victims of credit card breach.

Good security never ends, but it almost always starts with a business need, followed by a Risk Assessment.  The end of a security life cycle instance is when the business continuity plan has been updated, and security processes become business as usual.  PCI builds in the Risk Assessment (that’s what the 260-odd controls are), does not allow for residual risk, and stops at Incident Response.

In other words, and if you take the PCI DSS to the negative extreme, neither the card brands nor the SSC care if compliance fits your business needs, nor does it care if you even stay in business (as long as the cardholder data is safe).

Clearly this is not the case, they do care (to a point), but the issue is that the majority of organisations working towards compliance either do not care about security themselves (it’s just another cost of doing business), or they do care and just don’t know how to go about it.

So where is the good in PCI?  It’s twofold (for the purposes of this post);

1. It has significantly raised the profile of security in general as a business necessity, and;

2. It has driven innovation to an amazing degree into a SIXTY+ year old payment technology …the credit card number (blog pending on this).

OK, so the PCI DSS is limited, but at least they did what NO-ONE has done before, or since; actually defined what they consider to be a minimum standard of data protection.  Every other standard says things like ‘appropriate’, or ‘reasonable’.  Appropriate and reasonable to whom?  The PCI DSS says you must have a firewall capable of stateful packet inspection, you must have up to date configuration standards, encryption, logging, POLICIES and so on.  The way to compliance is WRITTEN DOWN FOR YOU!

Of course, it’s not that easy, and the confusion is where to start, and how to implement compliance in a way that suits the business, not the other way around.  A good QSA can help (White Paper:  Selecting the Right QSA), but the assessment process starts with the CEO and a culture of security.

The PCI DSS has, and continues to change the security climate for the better, all you need is the right perspective, and the right guidance.