Tag: Security Good Practices

To this day, people are surprised when an organisation is breached after having achieved PCI compliance.

Why?

The SSC has never claimed that PCI compliance ensured the protection of cardholder data, especially when you consider most organisations don’t DO PCI compliance for security, they do it to get their acquiring banks off their backs. All the SSC have ever claimed is that it helps, and it does.

Security is not about being impenetrable, that’s impossible, it’s about knowing your two main enemies; thieves and ignorance.

Thieves are lazy. In fact, I’d go as far as to say that laziness, more than a desire to be bad, is the leading driver behind computer crime. This drives them to steal first what is most easily available; the so called low hanging fruit. So to avoid thieves, just have YOUR fruit higher up the tree. That’s what PCI compliance does, and that’s all.

Continue reading “Stop Confusing PCI Compliance With Actual Security” →

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

Remember when CheckPoint were just firewalls, Symantec were just AV, and security companies could just provide consultancy?

Neither do I, it’s been too long.

Security has now become too complex, and too important to play the mix-and-match game with individual vendors, it’s only integrated, multi-function, solutions that will now make the cut.  But there are so few of them out there.  Well, so few that actualy do what they say they do anyway.

As security became a multi-billion £/$/€ a year industry, hundreds of companies started up to bring us the silver bullet appliances that will end our problems forever.  Not only do silver bullets not exist in security – and you should be shot for using the phrase in any way that’s non-derogatory – but where are those companies now?

They either failed, or have been bought up by larger companies who have tried to duct-tape the disparate products into silver-bullet SOLUTIONS.

Which have also failed.

It’s not that the products don’t work, some of them actually do, it’s that;

  1. Businesses threw technology at problems without knowing WHY they were doing it
  2. The big companies that collected the smaller ones tried to integrate the individual products together under one GUI, instead of unifying the functionality under a single code base
  3. There has never been, and there never will be, a one-size-fits-all solution to security

But the market is still ripe for innovation, and there will continue to be companies starting up with the goal of bringing a single product to market that will catch the latest security hype/wave/buzz and make them their fortunes (MDM for example).  They may even succeed, but only if they make their impact in the first year or two, otherwise the market will have moved on.

If they’re VERY lucky, the larger companies that collect little ones will be naive / ignorant enough to buy them and save them the trouble.

I am not against combining single products into a larger solutions, in fact it’s the only way to go, but only if it’s done correctly.  Single product companies have 100% focus, which gives them drive, goals, and a dedication to making their one product the best. The second you absorb that company, every one of those attributed that put them on (or near) the top, is lost in the larger mix.  The functionality is diluted, innovation ceases, and the the whole thing quickly becomes obsolete.

True integration of functionality can only be accomplished with a single code base, and a single platform, which means that any organisation that absorbed the smaller companies better have a plan in mind to migrate not only the applications over to their growing solution, but they will need to consider all of the clients who bought the product prior to the M&A.  These guys often suffer from a total lack of customer service and support, and there’s no way they’ll buy into the larger programme.

From what I have heard, the due diligence necessary to combine product companies is not overly abundant, and until it is, we should all be VERY careful when we look to resolve our security issues with multi-function solutions.

That’s why I call these ‘collage companies’, as the picture might be pretty, but it’s in no way whole.

Here are a few questions you might want to ask your potential providers;

  1. Can your solution replace some / most of my current functionality?
  2. Do you provide a consultancy ‘wrapper’ around these solutions to help us manage them against our business goals?
  3. Will the output from your solution feed into my current collection mechanism, or can my current output feed into yours?
  4. Are the various aspects / functions of your solution ‘home grown’, or obtained through acquisition?  If acquisition, how have you unified the back end code and platforms?
  5. How do you ensure that the different functions of the solution receive a similar attention to what the single product vendors provide?
  6. Do you have a single customer support process to handle all functionality questions?

Regardless of the shenanigans going on in the security product market, your choice of vendor should only be driven by what your risk assessment and gap analysis said you need, and your due diligence should cover any requirements you may have regarding integration and ongoing maintenance.

If is doesn’t, don’t expect the collage companies to help, they have enough problems keeping their own houses in order.

Choose wisely.

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

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