Category: Security Controls

In a previous blog How to Achieve Compliance on the Road to Real Security I stated my intention to write a series of articles on; “…the intent of the 12 main sections of the PCI DSS, as well as provide guidance and options on how to go above and beyond PCI…”  Well, here it is …finally.

For this series, I will provide 3 distinct elements for each aspect of the PCI assessment process, the LAST 12 of which will be the PCI DSS v3.0 requirements sections themselves. I do this because you should not even be LOOKING at these until you have completed several pre-requisites.

The first is performing a Risk Assessment, the second is choosing the right QSA / consultant to help you.

Element 1 – Intent: One of the most confusing things about the DSS – to both layman and crappy QSAs alike – is how can a controls standard that is the most prescriptive of any regulation to date, be open to so much interpretation? How can QSAs have different opinions, or worse, how can QSAs working for same QSA company have different opinions?

Well, you just have to look at how many times the word ‘periodic‘ appears in the DSS to begin to figure this one out; 11 times against 5 distinct requirement sections (3, 5, 8, 9 & 10). Or how about ‘appropriate‘?; 15 times, also in 5 distinct requirement sections (2, 4, 6, 9 & 12). Or ‘applicable‘?; 15 times in 6 distinct requirement sections (2, 3, 5, 6, 8, 11 & 12).

But the prize for ambiguity goes to 2.2.1.a.; “Select a sample of system components and inspect the system configurations to verify that only one primary function is implemented per server.”  The SCC does – in v3.0 anyway – provide guidance that this means you should not have functions at different ‘security levels’ on the same server, but ‘security levels’ as defined by whom?

For a number of years the SSC has been trying desperately to bring the standard into line with a more risk based approach. For example, in the requirements section, the word ‘risk’ appears 20 times in v3.0, compared to v1.2 in which it appeared only 5 times; Patching requirements have gone from ‘you will do it in 30 days’, to ‘do it in 30 days IF it’s appropriate’; and so on…

It all boils down to the INTENT of each section, and too often, the standard is seen as a black and white / all-or-nothing checklist with no room to actually fit the security goals into the business as a whole. This is not the case, so an understanding of the intent is critical before making ANY move to become compliant.

Element 2 – Above & Beyond: The second thing I will attempt to do is explain that every requirement is a bare minimum, so going just a little bit above and beyond is not only the RIGHT thing to do, it builds a portfolio of compensating controls that, if applied in total, should enable you and your QSA to have conversations related to risk and not semantics.

Element 3 – Continuous Compliance Validation: The third thing I will do is try to provide some guidance on how to KEEP the controls in place through either automation or process change. Unless your goal is to develop your management systems into those that can provide Continuous Compliance Validation, you’re working much harder than you have to, and your incident response capability will never be optimal.

In the end, this series will NOT be about PCI compliance, it will be about doing security properly and appropriately for your business, compliance will be nothing more than a by-product.

And finally, this is not about credit card data, this is about protecting ALL your information assets. Credit cards are approaching their end-of-life, and with the card brand’s acceptance of Host Card Emulation (HCE) and the enormous pressure to migrate payments to mobile devices, this will happen at an ever increasing pace. Don’t waste your time and effort on ‘just PCI’.

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

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

I’ve only been blogging a month, and I have already repeated the following statement a dozen times in a variety of ways. It’s not that I’ve run out of things to say, or even ways to say it – if you know me, you know that’s not possible – it’s just that it’s THAT important;

Don’t buy ANYTHING until you’ve performed a Risk Assessment, and you know exactly WHY you’re buying it.

The only exception to that rule is buying a risk assessment obviously.

In Core Concept 1: Risk Assessment / Business Impact Analysis, and Insecurity Through Technology, I have tried to stress that technology, for technology’s sake, can actually reduce your ability to perform both security monitoring, and incident response. Security needs to be simple to be effective and sustainable.

Your risk assessment will detail exactly what your security posture should be in terms of mitigation / transfer / acceptance of risk, and operational resilience. The next step therefore is to see just how close you are to achieving those goals with your current controls. This will include policies, standards and procedures, data flow and storage (business processes), applications, infrastructure and so on. This is not just an IT gap analysis, this is a security and business continuity gap analysis.

Like the risk assessment, I’m not going to bore you with a list of the things that may need attention, it’s up to you to ensure you are conducting the gap analysis with the right resources to paint the most accurate picture possible. If you can do this with just internal resources, great, but consider bringing in external consulting help to ensure both objectivity, and deeper coverage of the security relevant skills and experience.

OK, let’s assume you now have your gap analysis, which includes a list of recommendations. These will most likely be far broader and/or deeper than you will ever have the ability or budget to fix completely. That’s OK, there’s no such thing as 100% secure, and you should not be striving for perfection. The idea is to now match the cost of mitigating controls with the risk assessment conclusions to ensure that you are not only addressing the highest priority risks, but you are also doing so at an appropriate cost.

Cost is not just capital expense (i.e. technology), it’s resources (existing, or additional), down-time, and so on. Whatever is required to meet the goals of the business are prioritised and an implementation plan created and given to the Governance committee. It is their responsibility to ensure that not only are the current business goals (and possibly the future as well) met by the proposal, but that the estimated cost of doing so does not exceed the value of the data.

So now you know what you need to do, the order in which they are to be achieved (hopefully in parallel), and who is going to run the project (or projects).

Now you have to decide HOW you are going to achieve the goals, and I HIGHLY recommend it’s done in this order;

  1. Adjust your non-technical business processes to remove both the requirement for, and the instances of, sensitive data. If you have no data, you have nothing to steal;
  2. Consider outsourcing the non-core function elements of your business to known-good vendors (e.g. if you’re e-commerce, outsource the payments piece to a 3rd party shopping cart);
  3. Review your infrastructure in detail, I can almost guarantee there are some efficiencies, or adjustments that can be made without the need for more technology;
  4. Buy more technology, but there are some VERY important consideration with this, and the choices you have should be driven by your business needs, and not by the brightest, shiniest toys.

The first three are too specific to drill down into, but for new technology to even be considered the following must be kept in mind;

  1. Are you going to manage it yourselves, or outsource? – If the former, you will need to ensure you actually have the skill-set to do so. Too often the device ends up sitting on the IT managers desk because s/he was pretty much lost after the sales engineers left. Or worse, they plug it in and leave it there un-patched, which is the primary basis for insecurity through technology;
  2. How are you going to monitor the device? – Does it have its own management station, or can it be integrated with an existing one, SIEM for example? If it has it’s own management station, how many will that make now for your organisation? 5? 10? More? The more GUIs you have, the less you will have the time to monitor and you will quite literally lose sight of what’s really important. Integration is key;
  3. Who will maintain the devices operationally? – Any security device is only as good as its tuning and optimisation, and this process is cyclical, and never ending, regardless of whether or not your business changes. The thieves never stop, nor can your baselining efforts;
  4. Will the technology you’re purchasing scale with the possible growth of your business? – Regardless of your short term goals, you will need to keep the businesses future plans in mind. There is nothing the business hates more than wasted investments.

I know I’m simplifying this drastically, but as I keep saying, security IS simple, it’s just difficult to achieve. Especially if you don’t get started.

Clearly there is a lot more involved in the due diligence necessary to make the right security control choices, but the above framework will fit the majority of businesses. All you have to do is fit it to YOUR business.

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