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 24, Disaster Recovery (DR) & Business Continuity Management (BCM)

You may be wondering why I would put this after Governance seeing as that seems to bring everything together, and you may also be wondering why I did not included Disaster Recovery (DR) in the same post as Incident Response (IR) which everyone else always does.

They would be good questions, and my reasoning is relatively simple; You cannot HAVE Business Continuity Management (BCM) without Governance so that must be formalised first, DR represents the detailed processes summarised in the BCM, and IR is the feed INTO the DR/BCM, not the output from it.

To put it another way; the Business Continuity Plan (BCP) details what must be done, in what order, and how quickly to save the business, DR puts that plan into effect, and IR would have uncovered the inciting incident that brought both the BCP and DR plans into play in the first place.

Assuming that made any sense, the question is; What if I don’t HAVE a BCP?

I am surprised every time I ask a client for a BCP and don’t get one. Mostly because I’m not too bright, but partly because it makes absolutely no sense to me that ANY organisation in any industry sector, anywhere in the world would not make such a simple effort to help themselves STAY in business. While both DR and BCP represent what amounts to contingency planning and will hopefully never have to be invoked (assuming your IR is top notch of course), NOT having a plan is nothing short of irresponsible.

There are several well known standards related to Business Continuity, and for obvious reasons they encompass more than just IT systems:

  1. ISO 22301:2012: Societal security — Business continuity management systems – Requirements
    o
  2. ISO 22313:2012: Societal security — Business continuity management systems – Guidance
    o
  3. ISO/IEC 27031:2011: Information security – Security techniques — Guidelines for information and communication technology [ICT] readiness for business continuity
    o
  4. NIST Special Publication 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems
    o
  5. ANSI/ASIS SPC.1-2009 Organizational Resilience: Security, Preparedness, and Continuity Management Systems

Unfortunately the ISO stuff will set you back a few hundred quid, so start with the NIST / ANSI stuff to ge yourself familiar enough with the concept to at least ask the right questions.

For DR, start with mapping out all of your business processes and asset dependencies. If you don’t know how things fit together, you’ll have no idea how to put them back in place. Clearly, if your asset management processes are not robust, you can’t even begin the mapping process, so get that done first.

Once you have mapped out your business processes, it’s a relatively simple task to organise all of your procedural documentation into how you reestablish all the moving parts. You have all that, right? So whether you have full redundancy in all things, hot swap, warm spares or a whole host of other DR clichés, how you get your systems back online boils down to a series of easily followed instructions.

From an IT perspective, all the BCP plan does is tell you in which order to bring those systems back online and in what timeframe. It should be needless to say – but it isn’t – the plan and all of its moving parts must be tested on an annual basis or even explicit instructions cannot get the response times to an optimal state.

No aspect of security should be performed half-arsed, DR and BCP processes are no exception. Even within the field of security BCP is a speciality, and making the plan simple and appropriate is a talent more than a skill. Expect to pay a lot for these services but rest assured it is money well spent.

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

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