Category: Continuous Compliance

I am constantly surprised and disappointed that the Policy Set (policies, standards, procedures, and guidelines) aren’t taken more seriously. They are the blueprint of your corporate culture, the single most important aspect of your security program, and by far the easiest and cheapest things to put together (in terms of capital costs anyway).

Even a ‘controls only’ standard like the PCI DSS is roughly 40% ‘paperwork’, but, with the possible exception of the risk assessment, remains the most common tick-in-the-box exercise of them all. Which is a shame really, as it should be enough that thieves want to steal your data, to make things worse by not preventing your own employees from virtually giving it away is just plain dumb?

A Policy Set generally consist of 4 main components:

  1. Policies – the dos-and-don’ts of your entire organisation and use language like will / must / shall. e.g. Your authentication policy states that you; ‘MUST use strong authentication for access to systems containing data above a certain classification.’;
    o
  2. Standards – A very detailed document that explains exactly HOW something is to be configured. From operating system hardening guides to firewall rulesets. e.g. the details the actual password elements that constitute ‘strong’ (7 characters, alpha-numeric, change every 90 days etc.).;
    o
  3. Procedures – describe HOW you implement the policies in YOUR organisation. They are detailed, ‘living’ documents that prevent the constant re-inventing of the wheel when faced with performing standard functions. e.g. this is how you long into X system using 2-factor authentication.; and
    o
  4. Guidelines – The only non-mandatory element of the Policy Set, they provide good-practice guidance on how to implement a policy or standard requirement. e.g. For passwords, don’t use birthdays, don’t use names of children, consider a pass-phrase instead etc.

However, you can have the most polished documentation ever, and still completely miss the mark. It’s not about the paperwork itself, it’s about the enforcement of what’s IN the paperwork. A policy is only ever as good as the understanding of it, and the adherence to it.

Unfortunately, this is where most organisation fall down, and one or most of the following challenges apply:

  1. Policies not in-line with corporate culture or day-to-day business process – Policies should be owned, and even written BY the CEO / BoD. Who else is responsible for the culture, direction, and future of an organisation more than them? Too often this is delegated to departments or individuals without the necessary authority or experience to perform the function properly. A document coordinator MUST be a subject matter expert;
    o
  2. Undocumented procedures result in numerous (usually unintentional) breaches in policy outside of formal exception/variance processes – Just because a policy is in place, does not mean everyone knows how to implement it. Every department in an organisation is responsible to describe how each and every task is accomplished. Without procedures and standards, policies can become unenforceable, and every new employee has to reinvent the wheel every time they want to accomplish what should be a standard task;
    o
  3. Policies are undistributed, unenforced, or mis-understood – Just because you HAVE policies, or even procedures, if no-one knows where they are, what they mean, or how to measure against them, they are just pieces of paper. Security Awareness Training programs should start with a comprehensive look at ‘role-relevant’ corporate policies;
    o
  4. Poor document management or lack of integration with formalised training mechanisms – Without a robust document management system, it’s very difficult to both maintain the integrity of the Policy Set, and very difficult to distribute and enforce it; and/or
    o
  5. No feedback or measurement processes – Per the old misquoted cliché; ‘you can’t manage what you can’t measure‘, unless policies are seen as living documents with company wide feedback mechanisms in place, they can rapidly become obsolete.

I do not use the word ‘recommend’ lightly, but I HIGHLY recommend that before you implement ANY aspect of your security or compliance program, you get your Policy Set in place. At the VERY least do this in parallel with a risk assessment and business process mapping exercise.

While most high profile breaches focus on what went wrong technically, I can almost guarantee the original failure was one of education in the most basic of all security foundations; policies, standards, and procedures.

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

I provided my first PCI guidance way back in 2005, and my first on-site assessment was in 2006. Since then I have performed dozens of on-sites across the globe, my last one in 2009. Until December 2012, I ran teams that delivered PCI assessments across EMEA and APAC, all of whom followed a proven methodology that took all the guesswork out of how to achieve compliance, and STAY compliant.

Over the last few months, my changed circumstances have led me back into the PCI weeds, and frankly, I am more than a little disappointed. The payment card industry is no closer to ‘getting it’ than they were 8 years ago, and the guidance provided by a significant portion of PCI professionals leaves a lot to be desired.

After >8 years, the industry SHOULD be integrating their PCI assessment processes into some form of overarching security framework, re-certification SHOULD be nearing business as usual, and QSA quality should have improved.

They’re not, it’s not, and it hasn’t respectively.

I have written several articles on the major issues with the DSS, and what to do about them, I have stated more times than I probably should that the problems begin and end with the CEO, and I have repeatedly quoted my tag-line;

“Security is not easy, but it can be simple.”

I even wrote white papers on How to Sell Security (and therefore how to BUY security), and Selecting The Right QSA For Your Business in an effort to help standardise and optimise the most important step towards compliance; asking for help.

For some reason this has not had the industry changing effect I had expected. Surely my 18 subscribers – 4 of whom are family members – should have had a bigger impact than this!? [uncomfortable silence]

I have said for a few years now that I should put all of my experience into a PCI self-help book. Well, now I’m going to. Not all at once mind you, I’m going to write each chapter as a stand-alone ‘white paper’ over the course of the next few months, and will request your feedback on each. When they are as polished as they are going to be, maybe I’ll try to get it published, but I’ll still give it all away here on my blog.

I will also include any tool-sets I use to conduct an assessment (plus samples / examples), and I will provide options for free-ware / cheap-ware tools that I have seen be of some use. I will NEVER recommend anything, and only offer up options upon which you must perform your own due diligence. I may highlight my OWN preferred solutions, but the choices, and therefore responsibility, will always be yours.

These are the chapters I have in mind, and in this order:

  1. So You Want To Be PCI Compliant? (a.k.a. Buy Nothing Until You Read This!)
  2. Biased Perspective – What The PCI DSS Is, And What It Can Never Be
  3. Prepare Your Organisation (i.e. Your CEO) For The Assessment
  4. The Assessment Pre-Requisites
  5. Report on Compliance Executive Summary – If You Can’t Write This, Start Again
  6. DSS Requirement 1 – Networking Stuff
  7. DSS Requirement 2 – System Configuration Stuff
  8. DSS Requirement 3 – Encryption Stuff
  9. DSS Requirement 4 – More Encryption Stuff
  10. DSS Requirement 5 – Anti-Virus Stuff
  11. DSS Requirement 6 – Vulnerability Management, Change Control, Secure Coding Stuff
  12. DSS Requirement 7 – Access Control Stuff
  13. DSS Requirement 8 – Password Stuff
  14. DSS Requirement 9 – Physical and Back-Up Stuff
  15. DSS Requirement 10 – Logging Stuff
  16. DSS Requirement 11 – Testing Stuff
  17. DSS Requirement 12 – Policy, Training & Incident Response Stuff
  18. Compensating Controls
  19. Validation and Evidence Collection
  20. The Holy Grail of Security, Continuous Compliance Validation
  21. The Future Of PCI – Things To Bear In Mind

There are entire companies founded on, and still making fortunes from, PCI. I can, quite literally, thank PCI for my entire career in security (well, that and Windows), but it’s time we put PCI into the proper perspective, and start spending that money on the only thing that makes sense; staying in business responsibly.

If anyone would like to collaborate of any of these chapters, feel free to reach out to me. Especially encryption!!

PCI DSS

The answer, as any good consultant will tell you, is; “That depends.”

Usually that’s a our way of saying we don’t know the answer, but then again, we don’t have to, we’re consultants, and it’s up to you to tell us more so we can now go get the answer for you.

Like most things, GRC must start with a definition in order to apply context, and according to my old friend Wikipedia, GRC is “… the umbrella term covering an organization’s approach across these three areas.”

Which tells us absolutely nothing, so now we have to break it down:

  • Governance – Per my Security Core Concept 4: Governance & Change Control, governance is “…where the IT and business sides have conversations.”
    o
  • Risk [Management] – “…is the set of processes through which management identifies, analyses, and, where necessary, responds appropriately to risks that might adversely affect realisation of the organisation’s business objectives.”
    o
  • Compliance – “…means conforming with stated requirements (defined for example in laws, regulations, contracts, strategies and policies)“

Hopefully you are asking yourself why these 3 things were ever apart in the first place for us to even need GRC to bring them together.  Done properly, Risk Management is owned by Governance, who have already taken compliance into account while designing their overarching security framework.  In other words, if Governance had been doing their job correctly, the way they approach risk management would spit compliance out the back end.

To understand why this is not the case in an overwhelming percentage of businesses, is to get back to how security is viewed in the first place; 1) Governance does not exist, or if it does, it has no authority,  2) Risk Management is woefully inadequate, and is certainly nowhere near the old Plan > Do > Check > Act (PDCA) cycle, and 3) Compliance is seen as an annual project and not part of  Business-as-Usual.

Despite the fact that GRC is a term that should be redundant, it is seen as a goal in and of itself, and in my view, may detract from the business’s true end goal; Staying in business responsibly, with IT/IS as enablers.  The 4 Foundations of Security, and the 6 Security Core Concepts lay down some of the groundwork necessary to design an effective security framework, but neither these, nor GRC really get to the detail of how you begin this process.

You should start with an inventory of your assets, ALL of them.  i.e. Asset Management.

There are a significant number of GRC tools and applications out there, and while I’m sure their intentions are good, they fall a long way short of providing the functionality necessary to do GRC well.

For a start, how can any GRC tool not begin with Asset Management, and I don’t just mean input from vulnerability scans, or network enumeration tools, which are only a small part of what asset management entails.  Assets are not just network devices and servers, assets are applications, processes, people, locations and so on, and without a good understanding of what these are, how can you perform a risk assessment, or monitoring, or incident response, or disaster recovery, or…..

True asset management will include all the following, and no GRC tool I know of can do it all;

  1. Front-End, Off-Line Audit and Data Collection Tool – inputting the information into the GRC tool is a laborious process, and not all information can be gathered while online. An offline assessment tool should be configured to run both your asset data collection processes, as well as any compliance process that you are subject to (PCI for example).  This offline tool can be used by external auditors, and internal auditors alike to build the full asset picture;
  2. Integration of System Settings Policies – your policies will dictate your minimum security standards; passwords, access control, logging etc.;
  3. Integration of Data Classification Policies – if your systems are to be configured differently for different data classification levels, this will need to be defined;
  4. Network Enumeration & Network Mapping –  accept feeds from network mapping and enumeration tools in order to a) find and make initial stab at node identification, and b) gather any other ad hoc information available;
  5. Vulnerability Scanning – accept feeds from scanning tools to ensure that a) all systems are covered in the scans, and b) systems meet both policy and security minimums.  Ideally, the GRC tool would also feed into the scanning tools to provide up-to-date scan profiles, and exception rules;
  6. Automated Collection of Validation Evidence – PCI requires an annual validation of compliance, and only against a sample of systems. Security done correctly will have continuous compliance (i.e. near real-time), and automated validation of requirements (access control, passwords, logging etc).  This could be achieved by either server based agents, or integration with AD/LDAP for credentialed remote procedure calls;
  7. Baselined System Profiles – it is not enough to know the OS, IP, Hostname, location, owner etc (the usual asset management minimums), you should have record of it’s patch level, running services, listening ports, disk space, memory, even temperature.  A baselined system can then report against ANY anomalies;
  8. Firewall & Router Ruleset Validation – if you can feed a firewall or router ruleset into this system, you can a) compare it to the known business justifications, but you can also compare it to the system profiles to ensure you have no rules without corresponding business processes, running services on systems without corresponding rules, insecure services and so on.  Ideally, you could even create and maintain your network diagrams from this;
  9. Change Control & Trouble Ticketing – The change control process should feed into the ‘GRC’ tool to ensure that all monitoring and alerting mechanisms are up to date, and not triggering false positives.  Alerts FROM the GRC tool should automatically create trouble tickets based on a the data classification, system ‘sensitivity’/priority;
  10. Ease of Use – there is no point have ANY system or process that is too difficult to set-up, or impossible to maintain.

There are two main ways GRC vendors get you to use their product; 1) they ‘give’ you the software to use as part of a consultancy engagement, then charge you licensing fees if you want to keep the product after the engagement is complete, and 2) sell you the product, set it up for free (or a nominal charge), then hope you need them to come back and engage them as a managed service provider for ongoing maintenance.

I’m not saying either of these is bad, you just need to decide EXACTLY what it is you want from your GRC tool and perform your due diligence accordingly.

No GRC tool can do everything I described, so you either must buy several different systems and integrate them yourselves, or forget the GRC tool and run the above functionality in an operations centre.

Call it GRC if you want, but it’s not security until it’s simple enough to implement, and cost-effective enough to add real business value.

Do your due diligence before you buy anything, and again, if you need help, ask.

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

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

A little background first;

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

  1. Risk Assessment (RA) & Business Impact Analysis (BIA) – Business
  2. Security Control Selection & Implementation – Technical
  3. Security Management Systems – Technical
  4. Governance & Change Control – Business
  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] into 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!]