Been Breached? The Worst is Yet to Come, Unless…

The information security sector is rife with negativity and pronouncements of doomsday, and while the title is no better, this blog is not meant to scare, but to provide an alternative view of the worst case scenario; a data breach and resulting forensics investigation. The fact remains that if your data is online, someone has the necessary skill-set and wants it badly enough, they are going to get it. So the sooner you prepare yourself for the inevitable, the better you will be able to prevent a security event from becoming a business-crippling disaster.

By the time you make your environment as hack-proof as humanly possible, the chances are you have spent far more money than the data you’re trying to protect was worth, which in security equates to career suicide. Instead, you are supposed to base your security posture on the only thing that matters; a business need, then maintain your security program with an on-going cycle of test > fix > test again.

Unfortunately what happens in the event of a breach is that you are told what was broken and how to fix it from a technical perspective. This is analogous to putting a plaster / band-aid on a gaping wound. You’re not actually fixing anything. A forensics investigation, instead of being seen as the perfect opportunity to re-examine the underlying security program, is seen as an embarrassment to be swept under the carpet as soon as possible. Sadly, valuable lessons are lost, and the organisation in question remains clearly in the sights of the attackers.

For example, let’s say a breach was caused by an un-patched server. The first thing you do is fix the server and get it back online, but all you have you have done is fix the symptom, not the underlying cause;

  1. How did you not KNOW your system was vulnerable? – Do you not have vulnerability scanning and penetration testing as an intrinsic part of a vulnerability management program?
  2. How did you not know your system wasn’t patched? – Is not patch management and on-going review of the external threats landscape also part of your vulnerability management program?
  3. Did the breach automatically trigger a deep-dive examination of your configuration standards to ensure that your base image was adjusted accordingly?
  4. Did you fix EVERY ‘like’ system or just the ones that were part of the breach?
  5. Did your policy and procedure review exercise make ALL necessary adjustments in light of the breach to ensure that individual accountability and requisite security awareness training was adjusted?
  6. Were Incident Response, Disaster Recovery and Business Continuity Plans all updated to incorporate the lessons learned?

And perhaps the most important part of any security program; Is the CEO finally paying attention? Ultimately this was their fault for not instilling a culture of security and individual responsibility, so if THIS doesn’t change, nothing will.

If the answer is no to most of these, you didn’t just not close the barn door after horse bolted, you left the door wide open AND forgot to get your horse back!

Most breaches are not the result of a highly skilled and concerted attack, but by those taking advantage of the results of  systemic neglect on the part of the target organisation. i.e. MOST organisations with an Internet presence! Therefore, organisations that can work towards security from the policies up, and the forensics report down, have a distinct advantage over those who do neither.

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

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.

Incident Response & Disaster Recovery

Security Core Concept 5: Incident Response (IR) & Disaster Recovery (DR)

A little background first;

My Core Concept series is broken down 50/50 into both mostly technical, and mostly business concepts;

  1. Risk Assessment (RA) & Business Impact Analysis (BIA) Business
  2. Security Control Selection & ImplementationTechnical
  3. Security Management SystemsTechnical
  4. Governance & Change ControlBusiness
  5. Incident Response (IR) & Disaster Recovery (DR) Technical
  6. Business Continuity Management (BCM) & Business As Usual (BAU) Business

I’ve done this because the majority of consultants fall mostly in one or the other camp. There are very few true generalists, even though the majority of regulations require just that.

PCI for example requires a fairly in-depth knowledge of everything from policies to encryption, and from software development to access control. If no one consultant can possibly know all of this stuff – in a depth sufficient to provide true guidance – , why do you more often than not only get one assessor?

A Consultant is not the same as a Subject Matter Expert (SME), and these should not be confused. A consultant knows enough about everything to tell you what else you need. Or the old, but VERY relevant cliche; I don’t know, but I know someone who does.

I have taken DR / IR out of Business Continuity Management, so that it can be addressed by the relevant technical SMEs.

OK, enough background, what is Incident Response and Disaster Recovery?

Incident Response can be defined as; “The reaction to an incident that could lead to loss of, or disruption to, an organisation’s operations, services or functions.”

Disaster Recovery therefore is; “The recovery from an incident that caused loss of, or disruption to, an organisation’s operations, services or functions.”

What does this mean in reality? It means that whatever your business, you must know enough about its processes that anything out of the ordinary is either prevented outright, or detected soon enough to stop the incident from becoming a disaster. While you absolutely must have formalised DR capability, your IR should be robust enough to – hopefully – negate its use. In theory…

In practice, it does not work that way. Organisations generally do not have sufficient knowledge of the normal workings of their systems (infrastructure and applications) to detect when things go wrong. Or if they do, it’s probably too late to do anything about it except initiate DR.

The whole point of the Security Core Concept series is to help you stay in business, otherwise, why bother? The first 4 Core Concepts help bring your environment into a baseline that can, and must, be maintained;

  1. The Risk Assessment told you what was most important to you, and put a value on it;
  2. The controls you put in place mitigated the risk from threats;
  3. The ISMS forces you to continually optimise your systems in a way that supports their baseline functions; and
  4. Governance hopefully removes (or at least reduces) the internal threats.

What IR does is force you standardise, centralise, and simplify.

You will only have the ability to baseline your systems if you have a few ‘known good’ templates. If you have 10 flavours of Windows, and 10 more *nix, all configured differently, you really don’t stand a chance of baselining anything. You must therefore develop standard templates for all systems, wherever possible.

How do you manage 1,000 devices if not centrally? You don’t. Without a way to centralise the management and monitoring of your disparate systems, again, you will never have a baseline.

IR becomes self-explanatory in the face of known baselines; anything NOT within the baseline is an event to be investigated. The process for this investigation must be rapid, comprehensive, and above all PRACTICED! You can have 11 of the best football players in the world and still lose if they don’t play as a team. That’s the simplification.

As for DR, that too is fairly simple, IF, and ONLY if you know what your limits are. Back to the e-commerce example; If you need 100% up-time, forget it, it’s not possible, but 99.9% should be. However, going from 99% – 99.9% is exponentially more expensive, so you need to understand the VALUE of your business assets to define what is acceptable downtime for your business. That’s what the Risk Assessment is supposed to do; provide the input into your IR/DR plans and components.

OK, so I really haven’t given you anything to work on, have I? But like most aspects of security, there are no standards / frameworks / good practices that will fit YOUR business exactly. Everything that’s written down for you to follow can only EVER be a beginning, the rest is up to you.

Your business is unique in some way (probably in many ways), so you must take only the parts that are appropriate from each of the guidance frameworks or you’ll wind up with a security program that is unsustainable, and most likely ignored. Your security program becomes as unique as your business, and even saying that is ‘based on’ something is probably stretching it to the point that Hollywood bases its movies on books.

Security is simple, it’s not easy, but it is simple. Your IR and DR processes must be just that if you hope to stay secure.

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