Security in mergers and acquisitions: conducting due diligence

M&A 1

Recently I’ve had an opportunity to support a number of high-profile mergers and acquisitions (M&A) from the cyber security perspective. Although, due to the confidentiality of these projects I won’t be able to share any details, I would like to talk about some learnings and common approaches that might be useful.

The focus of this blog will be on the due diligence process and the role of security in it. It’s written from the buyer’s perspective, but insight into this thought process can be useful if you’re selling too.

Acquiring firms usually seek to fill the gaps in their capabilities (e.g. new technologies) in line with their strategy or to find overlaps allowing for cost reductions through greater consolidation.

Due diligence during M&A is rarely simple, quick or 100% accurate. It aims to reduce risk for both parties involved in the transaction and identify value creation opportunities. Although it might feel brief due to the business pressures, no amount of time will allow you to detect all the threats and identify every risk facing the business.

The main questions you would like to have clarity on from the security perspective are: “What security measures does the company have in place?” and “Are these the right measures?”

Sometimes, it feels like an art rather than a science.  But there are ways to reduce the uncertainty surrounding this process.

Jason Weinstein, former Deputy Assistant Attorney General, U.S. Department of Justice, once said: “When you buy a company, you’re buying their data, and you could be buying their data-security problems.”

Security teams, however, are not always welcome during M&A activities. Why? For one thing, it takes time and costs money to involve them. They may also scare or annoy employees of the target company and can be perceived as slowing things down or, worse still, hampering the deal.

So even when security gets involved, it’s usually quite late in the process with a few days left before the deal needs to be finalised.

To make matters worse, access to the target company is often restricted and the best you can get is a (partially) filled questionnaire. Your security-related questions form a part a broader pre-deal survey, so it’s a good idea to put some thinking what you should ask and why.

A number of subject matter experts in the deal team are all scrambling for limited available time and priority is sometimes given to understanding financials, legal aspects or broader IT strategy, rather than security specifically. Cyber risks, however, should form a core part of the process.

To alleviate some of the challenges outlined above, it helps if the value of the security involvement is clearly articulated (yes, it’s your job to do that). In short, it brings additional expertise to the table, protects the negotiating position and informs senior executives about potential risks, providing recommendations on mitigating them.

To save time, I’ve developed a high-level assessment template that covers all the possible areas of interest from the cyber security perspective and helps identify key assets, systems, processes and employees, but I would never send it as is. You need to do your homework and learn as much about the company and its culture as you can using the information in the public domain.

There are paid-for services out there but Google often does the job, as many OSINT experts would argue. Assuming, of course, you know how to use it! Open source intelligence and research skills at this stage are more useful than ever. Checking the dark web to see if target’s confidential information is being sold by cybercriminals can be useful too.

After the initial research, you can now tailor the questionnaire to verify your initial thoughts. Don’t be shy to ask for evidence if you want to see their policies or latest pentest reports: there are usually secure data rooms set up to share these kinds of documents.

The aim here is to understand the target company risk profile and make the deal team aware of the potential risks and opportunities. You can go one step further and quantify the risk, as this would help inform the value of the deal, potentially reducing the asking price to account for remediation activities during the post-deal phases. Despite the number of unknowns (believe me, it’s normal) it is also a good practice to provide recommendations.

It’s helpful to group your recommendations into three broad categories:

  1.  Risks that should be addressed before the deal can be signed (red flags)
  2.  Items that should be included in the contract (conditions on signing the deal)
  3. Post-deal activities as part of a 30-60-90 day plan that helps prioritise risks mitigation actions

Ask the target to disclose any known security flaws, issues and incidents. It’s probably also a good idea to reserve some funds for the remediation activities post deal. It shouldn’t be all negative; identify value creating opportunities too, if you can.

If you’re a seller, you can increase your marketability by assessing your own assets, discovering your own vulnerabilities and addressing these. Establishing processes to demonstrate compliance is a bonus. But don’t just focus on the current state, think about how your assets are going to stay so post-deal.

Congratulations! You successfully supported the business in making the right decision about this company. But the role of cyber security doesn’t end here. If the board decides to go ahead and the agreement is reached, we are moving into the post-deal stage.

Now, we need to ensure a smooth and secure integration.

Early Stage Cybersecurity Accelerator Programme

HutZero

A few weeks ago I learnt that my application to attend the HutZero cyber entrepreneur bootcamp had been successful.  I am excited to start the programme next week and will keep you posted!

Whether you are just finishing your studies on cyber security, or have worked in the corporate world for a number of years, HutZero supports individuals at the very start of their entrepreneurial journey.

DevOps and Operational Technology: a security perspective

3391525700_187606bd23_z

I have worked in the Operational Technology (OT) environment for years, predominantly in major Oil and Gas companies. And yes, we all know that this space can move quite slowly! Companies traditionally employ a waterfall model while managing projects with rigid stage gates, extensive planning and design phases followed by lengthy implementation or development.

It’s historically been difficult to adopt more agile approaches in such an environment for various reasons. For example, I’ve developed architecture blueprints with a view to refresh industrial control assets for a gas and electricity distribution network provider in the UK on a timeline of 7 years. It felt very much like a construction project to me.  Which is quite different from the software development culture that typically is all about experimenting and failing fast. I’m not sure about you, but I would not like our power grid to fail fast in the name of agility. The difference in culture is justified: we need to prioritise safety and rigour when it comes to industrial control systems, as the impact of a potential mistake can cost more than a few days’ worth of development effort – it can be human life.

The stakes are not as high when we talk about software development.  I’ve spent the past several months in one of the biggest dot-coms in Europe and it was interesting to compare and contrast their agile approach to the more traditional OT space I’ve spent most of my career in. These two worlds can’t be more different.

I arrived to a surprising conclusion though: they are both slow when it comes to security. But  for different reasons.

Agile, and Scrum in particular, is great on paper but it’s quite challenging when it comes to security.

Agile works well when small teams are focused on developing products but I found it quite hard to introduce security culture in such an environment. Security often is just not a priority for them.

Teams mostly focus on what they perceive as a business priority. It is a standard practice there to define OKRs – Objectives and Key Results. The teams are then measured on how well they achieved those. So say if they’ve met 70% of their OKRs, they had a good quarter. Guess what – security always ends up in the other bottom 30% and security-related backlog items get de-prioritised.

DevOps works well for product improvement, but it can be quite bad for security. For instance, when a new API or a new security process is introduced, it has to touch a lot of teams which can be a stakeholder management nightmare in such an environment. A security product has to be shoe horned across multiple DevOps teams, where every team has its own set of OKRs, resulting in natural resistance to collaborate.

In a way, both OT and DevOps move slowly when it comes to security. But what do you do about it?

The answer might lie in setting the tone from the top and making sure that everyone is responsible for security, which I’ve discussed in a series of articles on security culture on this blog and in my book The Psychology of Information Security.

How about running your security team like a DevOps team? When it comes to Agile, minimising the friction for developers is the name of the game: incorporate your security checks in the deployment process, do some automated vulnerability scans, implement continuous control monitoring, describe your security controls in the way developers understand (e.g. user stories) and so on.

Most importantly, gather and analyse data to improve. Where is security failing? Where is it clashing with the business process? What does the business actually need here? Is security helping or impeding? Answering these questions is the first step to understanding where security can add value to the business regardless of the environment: Agile or OT.

Image by Kurt Kurasaki.

Developing Global Cyber Services

UNADJUSTEDNONRAW_thumb_3078

Over the past year I’ve worked as a core part of the KPMG’s Global Cyber Strategic Growth Initiative as the lead for service development activities, with a focus on working with member firms to deploy capabilities in order to ensure consistent delivery and quality across key growth areas.

I was responsible for the roll-out of cyber security services that included developing sales and delivery accelerators, accreditation requirements, learning pathways, vendor ecosystem and quality and risk management principles across EMEA, APAC and Americas.

To achieve this, I created a service development framework and worked with numerous stakeholders across the firm’s network: global deployment, service development leads, acquisition leads, risk management and key member firm cyber representatives and regional leads.

I also developed a method for the in-country adoption of deployed capabilities and supported both global and in-country risk team members in the evaluation of risk when taking services for client use.

I ensured the sustainability of deployed capabilities through the implementation and use of delivery frameworks and tools, and assigned ownership for the upkeep of deployed capabilities. I worked with member firms to promote the adoption of prioritised services; developed adoption timelines and targets for deployed service.

One of the existing aspects of the role was alliance, acquisition and investment integration support where I collaborated with the relevant stakeholders to deploy and embed offerings obtained through alliances to member firms while monitoring progress against agreed budgets, milestones, deliverables and benefits for capabilities being deployed.

By the end of the programme, I deployed Cyber Maturity Assessment, Identity and Access Management, Industrial Internet of Things Cyber Security, Privacy and Cyber Incident Response services to 19 countries around the world.

This resulted in achieving significant revenue and market share growth for cyber security services of my firm globally. KPMG International was also named a leader in information security consulting services in 2016 and 2017 according to Forrester Research.

cq5dam.web.512.99999

Security function review

When determining the level of maturity of a security function, I focus on the following areas and try to answer these questions:

Business alignment

  • Is security strategy aligned with business strategy (including vision and mission)?
  • Is it documented and communicated?
  • Is it supported by the leadership?
  • Is there a guiding policy in place to achieve set objectives?

Governance

  • Have accountable individuals been identified?
  • Have risk management practices been established?
  • Have audit and assurance practices been established?

Operating model

  • Have performance measurement practices been established (including KPI definition)?
  • Have global and regional interfaces been defined?
  • Has team structure and funding been agreed?

How to conduct a cyber security assessment

NIST SCF

I remember conducting a detailed security assessment using the CSET (Cybersecurity Evaluation Tool) developed by the US Department of Homeland Security for UK and US gas and electricity generation and distribution networks. The question set contained around 1200 weighted and prioritised questions and resulted in a very detailed report.

Was it useful?

The main learning was that tracking every grain of sand is no longer effective after a certain threshold.

The value add, however, came from going deeper into specific controls and almost treating it as an audit where a certain category is graded lower if none or insufficient evidence was provided.  Sometimes this is the only way to provide an insight into how security is being managed across the estate.

Why?

What’s apparent in some companies – especially in financial services – is that they conduct experiments often using impressive technology. But have they made it into a standard and consistently rolled it out across the organisation? The answer is often ‘no’. Especially if the company is geographically distributed.

I’ve done a lot of assessments and benchmarking exercises against NIST CSF, ISO 27001, ISF IRAM2 and other standards since that CSET engagement and developed a set of questions that cover the areas of the NIST Cybersecurity Framework.

I felt the need to streamline the process and developed a tool to represent the scores nicely and help benchmark against the industry. I usually propose a tailor-made questionnaire that would include 50-100 suitable questions from the bank. From my experience in these assessments, the answers are not binary. Yes, a capability might be present but the real questions are:

  • How is it implemented?
  • How consistently it is being rolled out?
  • Can you actually show me the evidence?

So it’s very much about seeking the facts.

As I’ve mentioned, the process might not be the most pleasant for the parties involved but it is the one that delivers the most value for the leadership.

What about maturity?

I usually map the scores to the CMMI (Capability Maturity Model Integration) levels of:

  • Initial
  • Managed
  • Defined
  • Quantitatively managed and
  • Optimised

But I also consider NIST Cybersecurity framework implementation tiers that are not strictly considered as maturity levels, rather the higher tiers point to a more complete implementation of CSF standards. They go through Tiers 1-4 from Partial through to Risk Informed, Repeatable and finally Adaptive.

The key here is not just the ultimate score but the relation of the score to the coverage across the estate.

The Psychology of Information Security book reviews

51enjkmw1ll-_sx322_bo1204203200_

I wrote about my book  in the previous post. Here I would like to share what others have to say about it.

So often information security is viewed as a technical discipline – a world of firewalls, anti-virus software, access controls and encryption. An opaque and enigmatic discipline which defies understanding, with a priesthood who often protect their profession with complex concepts, language and most of all secrecy.

Leron takes a practical, pragmatic and no-holds barred approach to demystifying the topic. He reminds us that ultimately security depends on people – and that we all act in what we see as our rational self-interest – sometimes ill-informed, ill-judged, even downright perverse.

No approach to security can ever succeed without considering people – and as a profession we need to look beyond our computers to understand the business, the culture of the organisation – and most of all, how we can create a security environment which helps people feel free to actually do their job.
David Ferbrache OBE, FBCS
Technical Director, Cyber Security
KPMG UK

This is an easy-to-read, accessible and simple introduction to information security.  The style is straightforward, and calls on a range of anecdotes to help the reader through what is often a complicated and hard to penetrate subject.  Leron approaches the subject from a psychological angle and will be appealing to both those of a non-technical and a technical background.
Dr David King
Visiting Fellow of Kellogg College
University of Oxford

More

Presenting on cyber security at UCL

ucldark_0.jpg

The UCLU Technology Society invited me to deliver a talk on information security to UCL students. Together with my colleague, I discussed various aspects of information security focusing on both technical and non-technical topics.

We talked about Advanced Persistent Threats and common misconceptions people have about them. When referring to protection measures, I emphasised the importance of considering human aspects of security. I described typical causes of a poor security culture in companies, along with providing some recommendations on improving it.

I concluded the evening with a discussion on managing and communicating the necessary changes within the organisation and the skills required to successfully do that.