Only the Data Matters

Forget the Systems, Only the Data Matters

I have written quite a few blogs on GDPR and data discovery, but it’s not about regulations, it’s about securing the only thing that really matters to an organisation; its data.

My premise stems from the fact that there is no such thing as 100% secure. That with the right motivation, skill, and time, a bad guy will get in. Anywhere. The criminals in question spend a significant amount of effort mapping the target systems to eventually find the weak spot(s), and because the environment rarely changes, their end goal is always achievable.

The analogy used most often in security is one of a castle. You build up many layers of defence (thick walls, moat, arrow-slits, battlements etc.) and your most precious possessions are held in the most secure room in the centre of it. However, because that castle can only change very slowly, a concerted attack will eventually result in the loss of the ‘crown jewels’.

All it takes is time.

However, all of these defences are really just a means to an end, it’s the data itself that’s the only thing that matters. The real problem therefore lies not so much in the systems, but their predictability. Spending money and resources on more and more ways to protect the systems is just building higher walls. Eventually you have to stop, and eventually someone is going to break them down. And to take the analogy one stage further, the higher the walls, the more fragile they become (see Insecurity Through Technology).

So what can we do when the rising interest in privacy, and the ongoing train-wreck that is PCI, is causing a tidal wave of new products and services all claiming to be the missing link in your security program? Oddly enough (given my dislike of buzz-phrases), the only one that makes sense in the context of this blog is Cloud-based services, where scalability, redundancy and resilience are generally built into the platform from the beginning. A system goes down and you bring a new one back up. Instantly.

But how about taking this one stage further? Don’t just replace when something breaks, instead change as a matter of course! From firewall functionality, to ‘servers’, to encryption, even as far as location, change something in your environment to negate as much of the reconnaissance as possible. For every benefit of this, there will likely be at least one, or even several reasons to keep things the same, but the benefits are extensive:

  1. Security – The entire premise of this blog; if you change things frequently, bad-guys are less able to keep up and the rewards become less and less worth the effort. Back to building your fence higher than your neighbour;
    o
  2. Simplicity – To even think about replacing a system outside of a disaster recovery scenario, everything you do has to be simple. There is no security without simplicity;
    o
  3. Business Transformation / Competitive Advantage – I contend that in terms of competitive advantage in the Information Age, any head start will be closed in a matter of weeks / months, not years / decades. Any organisation that has the capability to quickly change aspects of their environment clearly has a thorough understanding of their business processes. Understanding is knowledge, the correct application of knowledge is wisdom, or in this case; appropriate transformation;
    o
  4. Business Continuity – Most organisations have distinct gaps between their continuity needs, and their ability to meet them. Even if Incident Response and Disaster Recovery processes are tested annually, only an organisation that makes significant changes frequently has the well-honed skill-set to meet or exceed the continuity plan goals. Practice, in this case, can indeed make perfect. Perfect enough anyway;
    o
  5. Innovation – Only from simple and well-known can innovation be truly effective. When you’re not worrying about how to keep things running and can focus on what else you could be doing with what you have, you are free to be either more creative, or recover quicker from your mistakes. Too often the inability to adjust begets the fear to even try.

As I stated previously, there are probably more reasons that this theory is completely unsustainable than there are apparent benefits, but I don’t think that means it’s not worth a try. Humans tend to overcomplicate things and then get lost in the detail, but with simplicity comes the freedom to focus on what really matters; the data from which all of your knowledge springs.

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

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