A ‘Defensible Position’

It is difficult to know how far one must go to be GDPR (General Data Protection Regulation) compliant – do we gold plate everything to ensure we are complaint? Well, obviously not but it raises the question on what approach to take when actually remediating privacy risks.

A lot of the GDPR is at best subjective and at worst, wildly ambiguous. Many of the articles can be interpretable in many different (and significant) ways by different people, different organisations in different industries. In order to respond to this kind of uneven environment, a pragmatic approach to compliance must be adopted to ensure the most appropriate risk mitigation strategies are employed in the right areas. In doing this, we build organisations towards a ‘Defensible Position’ which both acknowledges mandatory items that need addressing in full in terms of both their scope and scale, but also acknowledging that some GDPR requirements can adopt a more typical risk based approach.

Some examples of the areas we see that fall within those mandatory items include areas such as;

  • Governance & Accountability
  • Retention and Transparency of Processing
  • Consent
  • Subject Access Requests
  • Breach Notification

And some example areas where we typically believe a risk based approach can be adopted include;

  • Data Portability
  • Right to be Forgotten

For example, for both of these you perform an analysis of the systems and processes that store and process personal information and based on risk indicators, categorise these into critical, high, medium and low risk bands. Remediation efforts can then be driven by these risk categorisations.

The whole premise of the defensible position allows an organisation to press on with risk remediation and not getting tied up worrying about being 100% compliant, 100% of the time. It means that if the regulator comes knocking 25th May next year, they will be able to sufficiently justify their actions and fully demonstrate the approach they have adopted to tackling GDPR compliance. This in turn, will likely help prevent them from being the TalkTalk of their industry who is made an example of when it comes to handing out regulatory actions and fines.

Quick & Snappy! … Lite Cyber Maturity Assessments

A lite cyber maturity assessment is similar to a full cyber maturity assessment, but with reduced scope of assessment for the purposes of either speed or reduced budget. To perform such a short assessment without compromising on quality, typically this is achieved either through a reduction in depth of assessment (e.g. we will interview stakeholders and review documentation, but not perform any sampling to assure what we have been told by stakeholders is reflective of real life) or a reduced number of security domains is covered.

These kinds of Lite cyber maturity assessments are a fantastic methodology in a number of circumstances. For example, for smaller organisations who don’t have the annual security/audit budget to afford £30-60,000 full blown cyber maturity assessments, then performing a slimmed down version (circa £20-30k) can get them the view on cyber maturity they need without having to blow the bank. Additionally, for organisations who for whatever reason need to act fast (e.g. report to a quarterly board meeting in only a few weeks time) then these types of assessments can be performed over 1-3 weeks and a view of cyber maturity provided as a result.

Whilst useful, there are a number of pitfalls organisations should be careful to avoid. Most of these, due to the significantly reduced timescales, almost all result in a catastrophic reduction in assessment quality and a complete loss of confidence in all of the assessment results. The main pitfalls are;

  1. Trying to do a full maturity assessment, just quicker – if scope is not reduced in any form the assessment is then just conducted in a rushed manner, resulting in possibly not meeting enough stakeholders, not meeting the right stakeholders or quite simply poor information collected from the stakeholders that will ultimately undermine the assessment results.
  2. Having the right people – performing lite maturity assessments requires a higher calibre of security professional. Not only do you have to cover the ground faster, but you have to do so in a manner that maximises the time you spend with stakeholders. By the very nature of a Lite assessment, it is fast and over quite quickly. There are not the usual luxuries you have in a standard assessment where if you’ve forgotten to ask the CISO or CTO an important question or set of questions, you can’t organise another session with them or send them an email. This may take another 2-3 days of time which you don’t have. As such, the security professional leading the assessment needs to have the ability to get to the answers they need quickly in each stakeholder interview/workshop and maximise their time with each and everyone involved. That means asking the right questions and being able to drill down into the detail where it is required, and knowing when it is not required and moving on.
  3. Trying to get the same level of assurance – do not think that you can get the same level of assurance from a Lite Maturity assessment as you can from a full assessment, you cannot. But this is not to mean that it is not valuable – just ensure that the foundational reasons why you are performing a lite maturity assessment align to the specific outputs that will be delivered. For example, if you do not need to test the operational effectiveness of your security controls but just need a high level view of security following a small breach or in the lead up to an annual board meeting, then yes a Lite assessment will deliver what you need. However, if you’re looking to use the output of the assessment to structure and drive out your entire security strategy and roadmap for the next 3-5 years, then it’s probably worthwhile investing the extra £30-40k in a full cyber maturity assessment.
  4. Accepting a Report that is Not Detailed At All if you have hired in external consultants to perform a Lite assessment and come reporting time you read it and think that this is so high level that it is not valuable, challenge them on the level of detail they are providing. Just because you are performing a Lite assessment, it does not mean the report is also Lite. It should be and can still be very insightful, but it is likely that they have fallen foul of one of the above pitfalls prior to reaching the reporting stage of the engagement. Always ask to see an example of the end report so you can familiarise yourself with the level of detail that’ll be provided, but also use it as a tool to keep the consultants true to their word.

By avoiding some of these fundamental pitfalls of Lite cyber maturity assessments you can successfully apply this useful assessment type, saving you both time and money in the process.

When More is More – Using A Multi-Standard Assurance Framework for Cyber Maturity Assessments

Often when organisations perform these assessments internally, or with some of the less capable consultancies out there, single standard assurance frameworks are used as the basis of the assessment. Often the framework itself is picked, seemingly at random, from the typical ‘acceptable list of cyber security standards’, so namely;

  • NIST
  • ISO27001
  • SANS Top20 Controls
  • C2M2
  • COBIT

Whether one standard is selected over another tends to be as a result of either;

  1. what is quite simply the flavour of the month for the client, and/or;
  2. what is the personal preference of the person sponsoring the cyber maturity assessment
  3. what the board is used to seeing

Now, what we have seen in recent years is a move towards creating bespoke assurance frameworks, made up of 2 or more security standards to perform these kinds of assessment. There are a number of benefits we have found in doing so;

1. Not all Standards are Born Equal – I think everyone would agree that there is no utopic security standard that accurately and completely encompasses all ‘security’ domains. As such, you have security standards that are a little more focused on IT controls (e.g. ISO) and some that are are focused a little more on the technical domains (e.g. SANS Top20) and some that focus more on IT risk, etc. etc. By combining these standards together into a single framework, you start to cover some of the shortfalls a particular standard has with the strengths of another. This produces a much broader framework to be able to assess against. I’ve demonstrated this conceptually in a very basic format below.

As you can see, some standards will overlap in terms of the scope and coverage, but they will also add to one another, making for a much more valuable and insightful framework.

2. Granularity of Reporting – as the framework broadens not only do you have an increased number of security domains you can report on, but also you have an enriched set of security domains in themselves. E.g. more sub-capabilities within capabilities and more insight into what organisations should be expected to be doing at certain cyber maturity levels.

3. Dynamic Reporting – often within organisations different parts of the business require reporting against different standards. If you build your framework correctly and you assess the cyber capabilities in the right way, one can perform a cyber maturity assessment and then slice and dice the reporting according to the requested security standard in question. So for example, you’ve used a framework that encompasses NIST, ISO and SANS however the risk and audit committee has requested to see the results of the cyber maturity assessment through only a NIST lens. Using this type of framework, you can fairly easily and quickly filter out the controls that were assessed against NIST and then provide a NIST only view.

As you can see, applying a multi-standard security assurance framework has its benefits. Just ensure that if you intend to apply this to your organisation, you have people performing the assessment who have done this a number of times before and are familiar with how these assessments are performed. Done right, they can be a fantastic tool for cyber assessment.

PCI DSS – Strategically De-scoping

When it comes to Payment Card Information (PCI) compliance, one of the typical pit falls I have seen over and over again is organisations jumping straight into assessment and remediation of PCI DSS risks, without time to pause and reflect on how to strategically de-scope the impacted IT infrastructure so that PCI DSS can become much more manageable but also much cheaper to maintain over the longer term.

In essence, strategically de-scoping refers to the evaluation of an organisations payment journeys to then rationalise and remove as many superfluous journeys and processes as possible. This simplification has a number of desirable effects;

  1. Cost Reduction – reduces the number of processes and systems that payment card information flows through and as a result, reduces the amount of money that needs to be spent on annual audits or pre-QSA type assessments.
  2. Risk Reduction – it significantly reduces risk as the attack surface is being made considerably smaller. i.e. number of processes, systems, applications, etc. being used to store or process card information is reduced.
  3. Easier Ongoing Management – for example, if payment information is only flowing through two customer journeys (e.g. website and mobile) both of which use the same business processes, the ongoing management of the security of the systems within this process is considerably improved. For every single system or process that is de-scoped from PCI DSS, that is another area of the business/group of stakeholders that need to be engaged with.

There are a number of ways organisations can strategically de-scope their PCI estate. Firstly, the most preferable (but most invasive) is to completely outsource the handling of payment card information to an external payment gateway, where payment details are passed directly from the customer to the payment gateway. This significantly reduces the need to store and process payment information internally, but it does also require the greatest amount of change if you already have payment card information widely dispersed within your business.

The second option is to simply perform a payment journey review. Typical payment journeys include;

  • Website
  • Mobile
  • Telephone/Call Centre
  • Via a Third Party Supplier

It might be that within a particular journey, there is considerable duplication of systems and processes that are using credit and debit card information. This is essentially an exercise in rationalisation, looking at what is business critical and getting rid of everything else.

There are other methods of achieving the same thing but hopefully these two examples give you an idea of why we would recommend performing an exercise like this to de-scope the PCI landscape before even considering remediation activities and plans.

Cyber Maturity Assessments: Through the Ages…

A cyber maturity assessment on the surface can seem quite a blunt tool for security posture assessment, however, lift the lid a little and you’ll discover that there is an entire range of assessments that can be applied in all kinds of different forms, resulting in valuable insights.

The stereotypical use of a cyber maturity assessment is to assess an organisation’s maturity of cyber capability, usually against some kind of CMM (Capability Maturity Model). Many of the big4 and security consultancies do this in many different ways but it often boils down to the same components.

Firstly, you make your assessment against a cyber capability assurance framework which holds a set number of cyber domains or capabilities that are used to assess and report against, for example;

  • Identity and Access Management
  • Network Security
  • Physical Security
  • Security Platform Administration and Management
  • Secure Development Lifecycle Management (SDLC)
  • The list goes on…

A team of security professionals then come into your organisation, interview members of IT Security, IT, the business, CISO, Heads of IT/Change/Technology/etc. to understand your capabilities in the defined capabilities in the framework. Using various methods and tools to ensure objective and consistent assessment across all domains, the cyber capabilities are then reported on by maturity, usually using the CMMI cyber maturity scale (1-5, 1 being the most immature and 5 being the most mature).

In a nutshell, that’s what a cyber maturity assessment entails. However, over the years the foundational reasons why organisations are using these types of assessments has been changing dramatically.

Almost a decade ago, these assessments were being primarily used as a tool to drive education and awareness to more senior decision makers in an organisation to try and convince them of the importance and need for focus on security issues. It was a time when even in some of the largest FTSE100 and Fortune 500 companies, boards of directors still needed convincing that security should be at the top of their list. Simply put, the maturity assessment was a great tool to show the awful state that our internal controls were in and thus instigate some action (and ultimately gain funding) to help uplift the security capabilities of the firm.

However, as security and the industries have moved on, this moved away from simple awareness and moved towards a decent mechanism by which you could actually gain funding by. It no longer was simply used as a scare mongering tactic for board members, it was forming parts of business cases to demonstrate where the funds needed to be applied. One could use ‘Target Maturities’* to show where different levels of investment would take the organisation in terms of cyber capability maturity. In my opinion, this is where we start to get into the powerful applications of the cyber maturity assessment.

*Target Maturity – based on the same CMM as the assessed “current state maturity”, a target maturity sets out either; a) where an organisation wants to be in terms of future cyber maturity for a given cyber capability, or; b) as a result of a defined scope of work (e.g. an in-flight project that is establishing a Security Operations Centre) it can illustrate what the progression in cyber maturity will be once the project has completed.

Furthermore, with the tools for delivering and reporting these kinds of assessments expanding and becoming more fully fledged offerings, organisations have more recently started using cyber maturity assessments as a strategic tool to drive change through the business and report on the strategic risk reduction over time. This has been typically done by performing an initial ‘normal’ assessment (usually 4-10 weeks in duration depending on scope) and then agreeing to perform assessment ‘snapshots’ on an ongoing basis at a set frequency (usually 6 or 12 months, depending on the level of change occurring in the firm). A 6 month frequency can be good for organisations that have significant security programmes in flight and they want to regularly report/validate cyber maturity improvement, otherwise annual snapshots are adequate.

This journey for cyber maturity assessments from a simple tool for awareness to senior executives, through to being an active part of funding requests, all the way to becoming a tool for demonstrating strategic risk reduction in the long term is quite remarkable. It is testament to how far the market has come and also demonstrates the ongoing applicability of a seemingly ‘basic’ tool for many interesting and valuable purposes.

GDPR…Playing Catch-up

The General Data Protection Regulation is a significant compliance hurdle for all but the most mature organisations. It unapologetically adds new complexity on top of the existing Data Protection Act currently in force in the UK and introduces a whole new set of compliance domains on top of it.

One issue we’re seeing in the run up to the implementation of GDPR at the end of May 2018, is that organisations are coming to the slow realisation of the size and scale of remediation required. More so than ever because of the realisation that they are not even compliant to the Data Protection Act as of yet and now there is very much the feeling of ‘playing catch-up’ – catching up to the compliance of the DPA, which GDPR simply adds to and expands on, even before minds can be directed into how to comply with the GDPR.

What are the key changes from the DPA to GDPR? The below list summarises the key ones;

1. Governance & Accountability – in addition to appointing a Data Protection Officer, organisations must ensure they have a suitable operating model and governance structure that fully supports the DPO function. Gone are the days where data privacy can be done in isolation from the business and other risk functions, it must now be an integral cog in the machine. This includes ensuring senior stakeholder accountability is clearly defined and the roles of data management are clearly defined as well as ensuring the justifications for data collection are clearly defined.

2. Consent Collection – increased stringent requirements around consent collection. It must be unambiguously provided by customers, clearly being an affirmative action (e.g. opt-in not just opt-out) and as simply to withdraw consent as it is to provide it (often firm’s make the channels for withdrawal considerably harder for customer retention purposes).

3. Data Portability – a completely new requirement that permits customers to request their data be shared with third parties. If necessary, this must represent the totality of their data (already difficult without single customer records) and must be in an easily understandable and uniform format. With huge amounts of legacy infrastructure and different systems processing the same data, again another considerable technology challenge.

4. DSARs (Data Subject Access Requests) – although not a new requirement, the changes around DSARs (e.g. free service and must be provided within 4 weeks of the request being made) makes this another business challenge. Nobody really knows as yet how many people will fully exercise their rights around this come May 25th 2018. I feel if there is sufficient media coverage in the build up to May next year there may be a significant spike in requests but this should peter out over time.

5. Breach Notification – organisations will soon be required to notify the regulator (and in some instances customers) within a 72hr window of discovering a breach. Exactly what defines a breach, when the clock starts ticking and the feasibility of this time frame is yet to be determined.

6. Transparency – there are significant new requirements around ensuring customers are truly well informed by organisations in how they process they personal data. This includes more thorough privacy notices that no longer are allowed to sit in the back of websites hidden within lengthy and complicated legal statements. They must be simple, concise and easily comprehensible by the layman and presented to the customer during the right times in the custumer journey.

7. Right to be Forgotten – the much publicised ‘Right to Erasure’ will come into effect, essentially allowing customers to request the deletion of their personal data (including third party processors). Although organisations won’t have to bend to a customers every beck and call – they will legitimately be able to hold on to a lot of information for valid reasons (e.g. fraud prevention), this will require more processing capability than already exists in most organisations. Especially considering legacy infrastructure and some systems simply will not even have the ability to delete data!

This state of ‘catching up’ to the DPA even before we start to think about the GDPR has  significant impacts, most obviously for the level of risk and timescales but also, maybe more subtly, impacts on funding and internal stakeholder buy-in.

Firstly, the level of risk and gap of compliance is clearly more for organisations who are still bringing themselves up to the standards of the DPA. This will directly impact the timescales that organisations are able to bring themselves up to speed from a GDPR perspective as attention first is given to fixing the basics (DPA). In most cases where funding isn’t available for these exercises to run in parallel, these organisations will be significantly delayed in both their risk assessment (gap analysis) and the subsequent remediation of the issues found.

The second impact is on funding and internal stakeholder buy-in. For those already responsible for risk mitigation against DPA, will find increasing resistance against requests for funding GDPR remediation, if the gap to DPA is already significant. For one, the size of the request will naturally be much greater and is likely to impact a much greater area of the business. But also, confidence to place a large amount of funding in the hands of those who have already struggled to enact change to meet the DPA, will face an uphill battle to be provisioned the much greater sums of money that will be required for the remediation under GDPR.

What we’re starting to see in organisations who are successfully making this transition is the types of character they are placing in positions of GDPR accountability. They are placing people are not necessarily experts or SMEs in the regulation itself (or even data privacy as a whole) but those with regulatory background and significant experience in enacting change with sufficient clout in the business to perform this autonomously. One of the key crippling factors we have seen restricting buy-in from audit committees and boards, is not a lack of expertise to identify and assess the level of risk, but the expertise in driving change throughout the breadth of the business once the risk is known.