Category: Continuous Compliance

You are probably wondering why I have taken a single aspect of the security program; change control, and raised it to the importance of a Core Concept. You are then probably wondering why I placed it under Governance, and not just an ISMS.

If you’re NOT wondering these things, I suspect you are new to security, or a friend of mine who’s reading this just to be nice.

However, if you accept my interpretation of what Governance is, it may make a little more sense; “Governance is where the IT and Business sides have appropriate conversations.” It’s a communication facilitator, where historically the business side rules and the IT side must do as it’s told, often without question.

You must also accept the concept of cybersecurity as a business enabler, and NOT a roadblock to profit or innovation. As I rather facetiously put it in The 6 Security Core Concepts;

Business: “I want this new functionality.”;

Security:“Sure, but do it this way.”

The business side is responsible for maintaining business growth / profit / market standing and a host of other objectives.This is far from easy, so they will do almost anything to meet those goals. It is up to IT and Security to encourage this innovation and out-of-the-box thinking, but do it in such a way as to ensure that the IT and security needs are built in from the beginning.

In a company with a well run Governance program, any ideas the business have will be run by the Governance Committee (or equivalent), which will include at least one, or more likely several members of the IT / Security teams (security, infrastructure, development etc.). The ideas will be discussed, input accepted EQUALLY from all participants, and a specific risk assessment report put together for senior leadership to review.The IT side’s input needs to include not only the risks, but the viability of the concept based on capital cost, resource allocation, outsourcing and so on.

That’s why they are enablers, because they are the ones who put the ideas into practical application. The greatest ideas in the world are useless if they stay on paper, and are potentially destructive if applied incorrectly.

Assuming I’ve made my point on Governance, and that you somewhat agree, I’ll move on to change control…

Change Control is defined by Wikipedia as; …”a formal process used to ensure that changes to a product or system are introduced in a controlled and coordinated manner.”

This needs no simplification, that’s EXACTLY what change control does …if it’s implemented properly. And that’s the issue in many organisations; the concept may be understood, but there are so many exceptions, and / or ways to circumvent the process, that you may as well not have change control at all.

Again, in The 6 Security Core Concepts I said; “If things don’t change, the only increase in security risk is from external sources. The threat landscape changes almost daily, why make things worse by screwing up internally?“

That’s really what it boils down to; known, and acceptable change. If you’re following the Core Concept series, you have:

  1. Given Governance full responsibility and maybe some accountability for the institution and maintenance of the security program;
  2. Performed your Risk Assessment with the full knowledge and blessing from senior leadership;
  3. Made all appropriate adjustments to your processes and infrastructure based on the RA’s finding and accepted priorities, and
  4. Initiated the Check and Act portions of the ISMS function to ensure that the controls work, and are on their way to being optimised

So why would you now undo all of that work by changing something without the Governance committee’s blessing?

Change Control includes EVERYTHING that changes; systems, applications, data stores, patching, policies, procedures, new functionality, people …EVERYTHING.

Of course Governance can turn some changes into operational norms; patching for example. As long as the process for testing new patches, and rolling them out across the enterprise is appropriately formalised, the Governance committee does not have to discuss it.

But what about firewall rule-set changes? The business side is demanding the testing of some new functionality that involves “Turning off the firewalls for a couple of minutes.”? The answer is of course, no, or HELL no to be more precise, but who has the authority to tell the business that? Right, the Governance Committee.

The institution of a change control culture is painful and slow, as new processes will always meet with resistance. But this is one area where there is no room for half measures, you either do it (and make the negative consequences clear to all), or don’t bother starting.

Finally, I have not gone into any detail of who should actually be ON the Governance committee, and what its charter should be, but that’s because it varies too much between organisations of difference size, complexity, and function. As long as you have equal representation from the IT and business sides, the individuals themselves will make themselves obvious over time. A limited tenure is important though, or the committee may either stagnate, or be controlled by the most forceful individual.

Governance is the heart and soul of your security program, and change control it’s most potent weapon, neither can be ignored.

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

If Governance (Core Concept 4) is the most ‘diversely interpreted’ of the 6 Core Concepts, Information Security Management Systems (ISMS) is the most widely MIS-interpreted and mis-understood.

As the de facto standard for ‘security frameworks’ , ISO 27001 is designed to; “…provide a model for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an ISMS.”. Or more simply; It’s how you keep your security program in place, relevant, and appropriate to your business.

ISMS can be summarised by the old ‘Plan > Do > Check > Act (PDCA)’ cycle:

Risk_Management_Elements

  • The Plan phase is about designing the ISMS, assessing information security risks and selecting appropriate controls;
  • The Do phase involves implementing and operating the controls;
  • The Check phase objective is to review and evaluate the performance (efficiency and effectiveness) of the ISMS;
  • In the Act phase, changes are made where necessary to bring the ISMS back to peak performance.

We already covered the Plan in Core Concept 1, and Do in Core Concept 2, so this; Core Concept 3, is a continuation of the security life cycle development.

With reference to a misquoted cliché; “You can’t manage what you can’t measure.”, the Check phase is designed to ensure that the controls you put in place to mitigate the risks detailed in the Risk Assessment (RA), are actually working. For example; your RA calls for segmentation between trusted and untrusted segments. Are the rules now in place to effect the segmentation? Is there any negative impact on performance? Are the firewall logs part of the established monitoring processes? Is the asset management system updated with all relevant detail? And so on…

If the answer to all of your success metrics above is positive, you must prepare to perform the cycle all over again at a time specified by your Governance Committee (usually annually at the very least). If the answer is no to ANY of the agreed metrics, you must go back and determine if the impact of the short-fall is sufficiently material to warrant major adjustment; e.g. fix it NOW, or no action at this time, or anything in between. This is the Act part of the ISMS.

As you can see, this is not actually that complicated. ‘ISO certification’ would be relatively easy if you were performing the first 3 Core Concepts correctly. However, because you can perform ISO certification of any aspect of your business, it is fairly meaningless unless you cover your entire infrastructure. Basically, unless you have a real business need to be ISO ‘certified’, don’t bother, just follow the Core Concepts.

While this Core Concept would SEEM to be the easiest (after all, it’s just determining if something is working or not), it’s the one that gets most ignored. It seems that most organisations lose interest after ‘fixing the problem’, so the additional expense of seeing if the controls actually worked gets put on hold. That ‘hold’ turns into forever, and continuous improvement is nothing more than a pipe-dream.

This is almost the same as doing nothing at all. Because not only do you not know if you are more secure than before, even if you WERE for while, you would soon fall back into your old ways. The entire investment is lost. In fact, it’s worse, because now you’ve wasted all that time and money as well.

Ensuring your ISMS is maintained is a critical function of the Governance Committee, along with Change Control, so we’ll tackle that in the next blog in the series; Security Core Concept 4: Governance & Change Control.

ISMS is where the rubber meets the road in terms of your corporate policies, standards, and procedures. These are the true baseline from which to measure the success of your security program. This is why they are one of The 4 Foundations of Security, and must receive the attention they deserve.

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

As you probably know, the PCI DSS is a minimum set of security controls that must be in place around anything that transmits, stores, or processes cardholder data. That’s probably why the card brands and the SSC get so irritated that even this basic set of good practices is so hard to achieve.

That said, unless you have a way of monitoring and maintaining your compliance within these baselines, it’s not only VERY difficult to stay compliant (let alone secure), it makes validation of your compliance an annual nightmare of gathering screenshots, log samples, and so on. I estimated that validation of controls can take up to 50% of the entire annual assessment cycle.

This is a tremendous loss of resource time, and does nothing for your ROI. So why DOES the PCI DSS only require an annual point-in-time validation and not validation of continuous compliance? Yes, you are accountable to stay compliant at all times, but you only have to validate it once a year, and – if you’ve earned it – on only a sample of your systems.

The answer is, they simply cannot go that far. Continuous compliance validation is far more difficult than achieving PCI compliance, and is firmly in the realms of good security practices. They can enforce minimums, they cannot enforce more than that and get the necessary acceptance.

So what IS Continuous Compliance Validation? “It is the near real-time notification of a variation from your baseline norms.” Or to put it another way; once you know what something should look like all day every day, you want to know if it changes from that.

For example, the PCI DSS specifies over 20 validation points for an operating system; e.g. business justification for all listening ports; access control; logging; FIM and so on. Once a year, you have to show your assessor that these validation points meet the DSS requirements, and that’s it for the YEAR! All too often, systems fall out of compliance within a matter of days.

Instead, what I propose, is that you should automate (as much as possible) the collection of that validation data, and compare it to not only the PCI DSS requirement minimums, but to ALL of your compliance / regulation / internal policies / standards. And not yearly, but hourly, daily, weekly, whatever makes sense. Wouldn’t you rather show your assessor a green checkmark for ALL of your systems than a dozen screenshots for a mere sample?

If this can be configured for just 50% of your in-scope devices, your entire annual validation burden will be enormously reduced. Plus, you also have a very convincing addition to your compensating controls for lack of FIM or AV (if applicable).

Best of all, you are now doing security as it was meant to be done; Enterprise wide, and Business As Usual.

Any operating system experts out there want to help me put this together?

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

In my White Paper on Selecting the Right QSA, I liken security to the law, in that it is becoming increasingly complicated, specialised, and inaccessible to businesses too small to afford in-house expertise. Unless you’re Fortune/FTSE 100, this is most likely your business.

I also introduce these core concept in the form of a highly artistic and creative Word table (what’s the punctuation for irony?).

With the plethora (one for you Three Amigos fans) of regulations, enforcement bodies, and good practice standards out there, it’s no surprise organisations are stuck in the mode of analysis paralysis. Every requirement for data protection cares only for their specific data type / jurisdiction / use / retention etc, so who is supposed to make sense of this for a business that just wants to sell their widgets?

Unfortunately, only the business concerned can put the necessary commercial perspective on this. However, seeing as ALL security boils down to the same core concepts or common denominators, this is likely easier than you think. Yes, you may still need professional help, but if all you are doing is talking about your business goals, you can leave the security part up to your consultant.

In my experience, there are only 6 security program core concepts:

1. Risk Assessment (RA) & Business Impact Analysis (BIA) – If you can’t (in some form) qualify/quantify your business risks related to your sensitive data, and then determine an estimated cost-of-loss related to data theft or unavailability, how will you know how much to spend on security? Put simply; if the cost of security outweighs the value of the data, don’t do it (this includes compliance). This does NOT mean you should do nothing at all, it just means you need to re-evaluate how you perform some of your business functions. The first question is not “How do I protect it?”, it’s “Do I need it?”

2. Security Control Selection & Implementation – The RA, done correctly, will show you where you can make improvements in your security posture. This does not necessarily involve capital expenditure – which should always be the LAST resort – it can be something as simple as destroying every instance of redundant data. Regardless, at some point you will probably purchase technology, but even here you should be careful (In Security, Technology is Always the Last Resort) and ensure that this new technology meets all of the business needs defined in the RA.

3. Security Management Systems – There’s not much point putting security controls in place if you don’t manage them properly to keep them in place. This is where standards like ISO 2700X come into play. This includes the day-to-day procedures used to maintain the operational aspect of your security infrastructure. Obviously this will vary dramatically by organisation; from a simple check-list for your corner sandwich shop, to a full time job for larger more complex organisations. The trick is doing only what’s appropriate without going overboard.

4. Governance & Change Control – Ask 100 people what Governance is, and you’ll get 105 different answers. I believe governance provides a function that trumps all others; it allows the business side of an organisation to talk to the IT side in the same language. Business: “I want this new functionality.”, IT: “Sure, but do it this way.” is the perfect conversation. IT, and especially IT security, are typically seen as roadblocks, but this is just a symptom of immature Governance processes. As for change control, that’s just common sense. If things don’t change, the only increase in security risk is from external sources. The threat landscape changes almost daily, why make things worse by screwing up internally as well?

5. Incident Response (IR) & Disaster Recovery (DR) – Fairly self-explanatory; what’s the point of being in business if you don’t intend staying in business? For example; if you are an e-comm company, you should know from the RA what your maximum downtime is, and both your security controls and IR & DR processes need to fit according.

6. Business Continuity Management (BCM) & Business As Usual (BAU) – You may ask why this is broken out from IR & DR. I do this because BCP and BAU are more related to the business side of the table, and IR & DR are on the IT side. IT never leads, IT enables, it’s the business side that needs to lay down the plans for staying in business, as well as how to do so efficiently, and cost effectively.

I know its a bold statement, but if you follow these core concepts, it won’t matter the compliance regime, the data type, of even the type / location you’re business is in, you’ll be covered …mostly. These are the concepts on which I founded Core Concept Security, Ltd.

Yes, this is a lot of work, and the up-front costs in both capital and resource terms can be significant, but it’s a damned sight cheaper than the cost of non-compliance, fines, and particularly; being breached. In the extreme, what if it’s the difference between you being in business at all?

As the Americans say, it’s a no-brainer.

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