PCI – Going Beyond the Standard: Part 20, Incident Response (IR)

First, you may be asking why this blog does not include Disaster Recovery (DR) and Business Continuity Management (BCM, which governs the entire IR / DR process). Because the PCI DSS section 12.10.x is almost entirely related to IR (with the exception of a VERY brief nod to DR / BCP, below in red), I will handle DR / BCP separately in the series (post 23 in fact).

“12.10.1 – Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum:

    • Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum
    • Specific incident response procedures
    • Business recovery and continuity procedures [This is the only requirement in the DSS that goes beyond the protection of CHD.]
    • Data backup processes
    • Analysis of legal requirements for reporting compromises * Coverage and responses of all critical system components
    • Reference or inclusion of incident response procedures from the payment brands.

With regard Incident Response, I put it this way; “What’s the point of being in business, if you don’t intend staying in business?”, and; “Good incident response is what prevents a security event from becoming a business crippling disaster.”

It makes absolutely no sense to me that organisations who basically depend on IT for significant chunks of income (which is most of them), have very little idea how to stop bad things from happening in the first place, let alone fix things when they go wrong. Of course, no incident response is going to predict an earthquake at the datacenter, but the organisations I’ve seen don’t even perform log monitoring properly, let alone consider the impact of acts of nature.

The development of a good incident response plan start with? Yep, a good policy, from there you agree on an appropriate Risk Assessment / Business Impact Analysis process, which in turn provides you everything you need to not only determine if you have any control gaps (after a gap analysis), but – if you’ve done it properly – a good indication of what your incident response and disaster recovery plans should entail.

There is no appropriate IR without an understanding of the business goals. If you have a 4 hour Recovery Time Objective (RTO), your IR will be significantly more robust than one where you can take a week to be back online. Yes, I know that RTOs (and RPOs (Recovery Point Objective for that matter) are DR terms, but if your incident response cannot detect a business crippling event in good time, then neither of those DR goals is an option for you.

When setting up your IR program, the most important word to keep in mind is ‘baseline’. Without a baseline, you don’t have much of a concept of what constitutes an incident in the first place. Only a baseline can give you both context and relevance.

From your baselined system configuration standards (DSS 2.x), to AV (DSS 5.x), to logging (DSS 10.x), to scanning (DSS 11.1.x, and 11.2.x), to FIM (DSS 11.5.x), you have many available inputs into your IR program, none of which will be of the slightest help if you don’t know what they SHOULD look like.

That’s all IR is;, a process whereby an exception to the norm is investigated, and appropriate action taken.

In each of my individual going-beyond-the-standard blogs related to the above DSS requirements, I have stressed the importance of baselining (well, except AV perhaps). The reason I did so was because they all lead up to this. I don’t care how well you have done ANY of the previous requirements, unless you can bring the outputs all together into a comprehensive process of taking action, all you have is a bunch of data to give to your forensics investigator.

You’ll notice though that I did not say a CENTRAL process, because while having a 24X7 Security Operations Centre t manage all of this, it’s rarely practical, even if it involves a outsourced managed service provider (MSP). However, having the correct assignments and procedures to MANAGE the response is of utmost importance, and the details of this plan will vary considerably from company to company.

No IR is not easy, but there is simply too much information and help out there for this difficulty to be any sort of excuse. And no, there is not much in this blog that actually provides guidance, but if this makes SENSE, then you at have at least got enough to begin to ask the right questions.

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

Business as Usual

Security Core Concept 6: Business Continuity Management (BCM) & Business as Usual (BAU)

This will be the shortest of my blogs on the Security Core Concepts for a number of reasons;

  1. The majority or organisations will not raise their security program to the point that this is even possible;
  2. It will be assumed that this is all covered in the previous steps; and
  3. It’s often only perceived as a nice to have, but not critical.

…and so on.

But the biggest reason I’m not going to focus on this, is because the preceding Core cOncepts tell you what you need to know, and reading my additional thoughts should be unnecessary. If you introduce the first 5 Core Concepts, this will be the only logical next step, and the benefits clear.

Business Continuity Management (BCM) is; “…a compilation of processes that identifies and evaluates potential risks to an organization and develops the organization’s resilience by ensuring critical objectives are met the resources necessary to achieve those objectives are available.

I have emphasised resilience because this is really what it’s all about; staying in business. The Security Core Concepts deal with only one part of what Business Continuity is all about. Yes, a very important part, but your data, and the ability to process that data, is not all your business encompasses.

This is why BCM belongs under your Governance framework. As the gatekeepers of your change control, and focal point for conversations between all departments, they are best placed to manage the never ending adaptation of your resiliency processes in light of internal changes, and the external threat landscape.

It’s shocking just how unprepared most organisations are for this contingency planning. What would have been an inconvenience is now a full blown event, and what should have stayed an event, is now a business crippling disaster. All for the want of a few more conversations, a few additional processes, and an annual test.

Seems a small price to pay for staying is business, doesn’t it?

As for Business as Usual (BAU), it’s; “…the normal execution of standard functional operations within an organisation.”

How can something so blatantly obvious not be the Holy Grail of security? Why is getting to this point so difficult for every organisation I’ve even worked for?

Back to my Ikea analogy from a previous post; Let’s say the instructions to build a bed-side table are lost, and it’s your job to work out how it’s put together.  You will eventually work it out (unless you’re me), and you’ll be happy.  But now let’s say you didn’t write down HOW you did it, will you be able to put another one together as fast as you could if you had instructions? More to the point, could someone else who is new to the task?

BAU is the standardisation of all of your processes to the point that they become second nature, AND are documented in such a fashion that anyone can pick up where the previous person left off. The phase ‘Knowledge Management’, which is intrinsic to BAU, was a big deal in years past, but seems to been usurped by the next security-shiny-thing.

Either way, knowledge management is the difference between doing everything all over again every time (reinventing the wheel), and doing it properly every time. Or being able to safely and quickly transition your business towards innovation and market competition, and away from disaster or obscurity.

And now you know why policies and procedure are so important, and one of The 4 Foundations of Security?

Take a guess as to who is responsible for driving an organisational culture that embraces BAU?  Yep, the CEO, and I hope you weren’t surprised.

There is clearly more involved in both BCM and BAU, but we’re keeping things simple.

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