IoT Security Foundation

IoT

It’s the second year I’m attending the IoT Security Foundation conference and it continues to be a great event.

Strategic and technical tracks run in parallel with vendor showcases and means that there’s something interesting for everyone.

It’s great to see industry practitioners and academics coming together to discuss the ethics of IoT, challenges with design and development and the direction of travel of security.

Some of recorded talks are available on the IoTSF website.

Best practice guidance on vulnerability disclosure, connected consumer products and security compliance framework are available to download.

Helping clients in Saudi Arabia

 

I’ve recently completed an assignment for one of the largest companies in Saudi Arabia where I had the pleasure of helping my clients improve their cyber security posture. During my time there I had the opportunity to explore this beautiful country, learn about its rich history and make a few friends.

And in case you are wondering how an Arabic keyboard looks like, here you go:

jvGavCsCSG6MP5VGAobf6g_thumb_3cf0

Security in mergers and acquisitions: integration

M&A 2

This blog is the second part of the discussion of security in mergers and acquisitions (M&A). I suggest to read Part 1 first, as I’m going to build on it and talk about what happens after the deal is finally signed.

Ok, it’s time to put that champagne glass down. I have bad news: closing the deal was the easy part. Now the hard work begins.

The purpose of the integration phase is to create value. More bad news: 83% of the M&A deals did not boost the shareholder value (according to KPMG global research report) and total average returns on M&A are negative (A.T. Kearney research).

All too often the root cause of these failures lies in poor integration.

There are ample opportunities to start losing the value right at the start during the handover between the deal and integration teams.

To alleviate this, I suggest identifying key resources and preparing implementation plans early in the process. Just like having an overall acquisition strategy and plan precedes the negotiation and due diligence phases, having an approach to integration is key to success. Deliverables, due dates, milestones, information flows are all need to be defined in advance. And cyber security plays a big role here.

A newly acquired company is a prime target for cyber criminals due to the magnitude of change it’s going through during the M&A process. Lack of governance, employee turnover, security vulnerabilities and many other factors can contribute to embarrassing security breaches that affect the reputation of the combined entity.

Key cyber security risks to consider:

  • Regulatory compliance liabilities and impact (e.g. GDPR fines)
  • Theft of intellectual property (data leaks, key employees leave with all the secrets, etc.)
  • Reputational damage (unwanted media attention due to data leaks)

The focus of cyber security post-deal is on protecting the value from internal and external threats, enabling secure integration, achieving long-term security and minimising cultural impact.

This can be attained in the following ways:

  • Supporting the project team deployment (security education, secured laptops, secure remote connection, encryption, etc.)
  • Identifying and prioritising key assets, systems, people and processes
  • Assessing the security of these assets (a carefully scoped pentest might be a good idea)
  • Ensuring confidentiality, integrity and availability of these assets (backups, antivirus, firewalls, patches, etc.)
  • Establishing and controlling access
  • Supporting the rationalisation of normalisation of processes
  • Developing an approach to cyber risk management (including third-party risk)
  • Rolling out security training
  • Supporting secure migration of applications and data
  • Supporting with incident management
  • Supporting with achieving compliance with relevant laws and regulations
  • Setting up a security monitoring capability of the merged entity
  • Establishing governance
  • Developing integrated security strategy and roadmap

Different cultures, attitudes to security and varying control frameworks are among many challenges to consider. Controls are typically relaxed to allow for the integration to go faster. This is where you need to be on a look out for increased threat levels.

To address these effectively, it’s a good idea to split your efforts in two stages: interim and long-term integration.

From the cyber security perspective, during the interim phase, the aim is to assess cyber maturity across the acquired entity rather than come up with a permanent solution.

High-risk areas should be addressed first by establishing interim controls. Long-term integration efforts should be initiated in parallel, starting with development of a security strategy, governance and roadmap.

Proportionality and risk-based approach is key here when integrating the acquired company into your governance structure and control framework. Focus on what matters most and prioritise security controls to protect the value and avoid backlash.

Don’t forget that people would need to still be able to carry out their duties with minimal disruption, but it’s a good idea to establish who needs access to what and why.

Some things can be outside of your control, like losing key employees after deal completion due to inadequate incentive structure. While it might not be your job to design the right retention mechanisms, it’s your responsibility to protect intellectual property, as mentioned above.

Above all, cyber security efforts during the integration process should be joined up with other functions and stakeholder groups. Work closely with the Legal team to minimise potential impact of compliance-related risks, engage Procurement for third-party risk management and align with the executive team to establish the right security culture.

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.

GDPR compliance automation: responding to data subject requests

What is GDPR?

The General Data Protection Regulation (GDPR) is a new European legislation intended to strengthen personal data protection for European citizens and harmonise personal data protection rules within the European Union. GDPR replaces the 1998 EU Data Protection Directive and the national laws that implemented this Directive. GDPR becomes the law in all EU Member States without the need for further legislation, though in some areas, Member States are allowed to adopt further specific laws on certain topics, for example, in relation to biometric data and employment data.

What is personal data?

Personal data is defined as any information relating to an identified or identifiable living individual. For example, your name, date of birth, home address, personal email address, your tax identification number, fingerprints, phone number, performance data and medical information are all personal data, but it can also be any combination of data that can identify you.

What rights do individuals have?

The GDPR provides the following rights for individuals:

  • The right to be informed
  • The right of access
  • The right to rectification
  • The right to erasure
  • The right to restrict processing
  • The right to data portability
  • The right to object
  • Rights in relation to automated decision making and profiling.

You can find out more on the ICO website. Companies receive the majority of requests in relation to the right to access and right to be forgotten.

What is the Right of Access?

A data subject access request is when an individual requests to have access to their personal data stored by the company. The purpose of the right to access personal data is to enable individuals to be in control of their own personal data (e.g. understand what personal data is processed and verify the lawfulness of processing).

All personal data which is being processed will need to be provided to the data subject, with a few exceptions to protect the data rights of other individuals and commercial secrets. In some cases, where the relevant systems provide for this, the right of access can be complied with by self-service by the data subject.

What is the Right to be Forgotten?

A data subject may make a request for the right to erasure, also known as the right to be forgotten. The right to be forgotten applies when: the individual has withdrawn consent, the data was processed unlawfully, or the data must be erased to comply with legal obligation. Only data items are forgotten for which the company does not have a legal basis (e.g. tax, accounting, employment, legal, etc.) or business purpose to retain.

The extent to which data can be erased depends on the nature of the personal data. For example, an employee cannot request that the fact that he or she worked at the company be deleted. When a data subject enacts their right to be forgotten, their personal data needs to be either deleted or anonymised such that it can no longer be linked back to the individual.

How to automate responding to data subject requests

Below is a high-level diagram of the solution that automates the processes that need to be carried out to comply with the regulation.

Tool

This includes collecting data from different systems in order to fulfill a Subject Access Request and instructing systems to delete/anonymise data as part of a Right to be Forgotten request.

Process automation requires that asset inventories and data flows are first documented and personal data processing systems are identified.

The solution then integrates with system APIs and orchestrates data subject requests. It allows the operator (data privacy team) to generate a consumable report and carry out necessary identity verification checks before responding to the request. It also enables the operator to customise the report if needed.

This approach ensures personal data is collected or removed from all the systems in scope and accelerates the process of responding to the requestor within the 30-day period.

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.

Governance Models – Cloud

Your company has decided to adopt the cloud – or maybe it was among the first ones that decided to rely on virtualised environments before it was even a thing. In either case, cloud security has to be managed. How do you go about that?

Before checking out vendor marketing materials in search of the perfect technology solution, let’s step back and think of it from a governance perspective. In an enterprise like yours, there are a number of business functions and departments with various level of autonomy.

Do you trust them to manage business process-specific risk or choose to relieve them from this burden by setting security control objectives and standards centrally? Or maybe something in-between?

Centralised model

1

Managing security centrally allows you to uniformly project your security strategy and guiding policy across all departments. This is especially useful when aiming to achieve alignment across business functions. It helps when your customers, products or services are similar across the company, but even if not, centralised governance and clear accountability may reduce duplication of work through streamlining the processes and cost-effective use of people and technology (if organised in a central pool).

If one of the departments is struggling financially or is less profitable, the centralised approach ensures that overall risk is still managed appropriately and security is not neglected. This point is especially important when considering a security incident (e.g. due to misconfigured access permissions) that may affect the whole company.

Responding to incidents, in general, may be simplified not only from the reporting perspective but also by making sure due process is followed with appropriate oversight.

There are, of course, some drawbacks. In an effort to come up with a uniform policy, you may end up in a situation where it loses its appeal. It’s now perceived as too high-level and out of touch with real business unit needs. The buy-in from the business stakeholders, therefore, might be challenging to achieve.

Let’s explore the alternative; the decentralised model.

Decentralised model

2

This approach is best applied when your company’s departments have different customers, varied needs and business models. This situation naturally calls for more granular security requirements preferably set at the business unit level.

In this scenario, every department is empowered to develop their own set of policies and controls. These policies should be aligned with the specific business need relevant to that team. This allows for local adjustments and increased levels of autonomy. For example, upstream and downstream operations of an oil company have vastly different needs due to the nature of activities they are involved in. Drilling and extracting raw materials from the ground is not the same as operating a petrol station, which can feel more like a retail business rather than one dominated by industrial control systems.

Another example might be a company that grew through a series of mergers and acquisitions where acquired companies retained a level of individuality and operate as an enterprise under the umbrella of a parent corporation.

With this degree of decentralisation, resource allocation is no longer managed centrally and, combined with increased buy-in, allows for greater ownership of the security program.

This model naturally has limitations. These have been highlighted when identifying the benefits of the centralised approach: potential duplication of effort, inconsistent policy framework, challenges while responding to the enterprise-wide incident, etc. But is there a way to combine the best of both worlds? Let’s explore what a hybrid model might look like.

Hybrid model

3

The middle ground can be achieved through establishing a governance body that sets goals and objectives for the company overall and allows departments to choose the ways to achieve these targets. What are the examples of such centrally defined security outcomes? Maintaining compliance with relevant laws and regulations is an obvious one, but this point is more subtle.

The aim here is to make sure security is supporting the business objectives and strategy. Every department in the hybrid model, in turn, decides how their security efforts contribute to the overall risk reduction and better security posture.

This means setting a baseline of security controls and communicating it to all business units and then gradually rolling out training, updating policies and setting risk, assurance and audit processes to match. While developing this baseline, however, input from various departments should be considered, as it is essential to ensure adoption.

When an overall control framework is developed, departments are asked to come up with a specific set of controls that meet their business requirements and take distinctive business unit characteristics into account. This should be followed up by gap assessment, understanding potential inconsistencies with the baseline framework.

In the context of the cloud, decentralised and hybrid models might allow different business units to choose different cloud providers based on individual needs and cost-benefit analysis. They can go further and focus on different solution types such as SaaS over IaaS.

As mentioned above, business units are free to decide on implementation methods of security controls providing they align with the overall policy. Compliance monitoring responsibilities, however, are best shared. Business units can manage the implemented controls but link in with the central function for reporting to agree on consistent metrics and remove potential bias. This approach is similar to the Three Lines of Defence employed in many organisations to effectively manage risk. This model suggests that departments themselves own and manage risk in the first instance, with security and audit and assurance functions forming second and third lines of defence, respectively.

What next?

We’ve looked at three different governance models and discussed their pros and cons in relation to the cloud. Depending on the organisation, the choice can be fairly obvious. It might be emerging naturally from the way the company is running its operations. All you need to do is fit in the organisational culture and adopt the approach to cloud governance accordingly.

The point of this article, however, is to encourage you to consider security in the business context. Don’t just select a governance model based on what “sounds good” or what you’ve done in the past. Instead, analyse the company, talk to people, see what works and be ready to adjust the course of action.

If the governance structure chosen is wrong or, worse still, undefined, this can stifle the business instead of enabling it. And believe me, that’s the last thing you want to do.

Be prepared to listen: the decision to choose one of the above models doesn’t have to be final. It can be adjusted as part of the continuous improvement and feedback cycle. It always, however, has to be aligned with business needs.

Summary

Centralised model Decentralised model Hybrid model
A single function responsible for all aspects of a Cloud security: people, process, technology, governance, operations, etc. Strategic direction is set centrally, while all other capabilities are left up to existing teams to define. Strategy, policy, governance and vendors are managed by the Cloud security team; other capabilities remain outside the Cloud security initiative.
Advantages Advantages Advantages
  • Central insight and visibility across entire cloud security initiative
  • High degree of consistency in process execution
  • More streamlined with a single body for accountability
  • Quick results due to reduced dependencies on other teams

 

  • High level of independence amongst departments for decision-making and implementation
  • Easier to obtain stakeholder buy-in
  • Less impact on existing organisation structures and teams
  • Increased adoption due to incremental change
  • High degree of alignment to existing functions
  • High-priority Cloud security capabilities addressed first
  • Maintains centralised management for core Cloud security requirements
  • Allows decentralised decision-making and flexibility for some capabilities

 

Disadvantages Disadvantages Disadvantages
  • Requires dedicated and additional financial support from leadership
  • Makes customisation more time consuming
  • Getting buy-in from all departments is problematic
  • Might be perceived as not relevant and slow in adoption

 

  • Less control to enforce Cloud security requirements
  • Potential duplicate solutions, higher cost, and less effective control operations
  • Delayed results due to conflicting priorities
  • Potential for slower, less coordinated development of required capabilities
  • Lack of insight across non-integrated cloud infrastructure and services
  • Gives up some control of Cloud security capability implementation and operations to existing functions
  • Some organisation change is still required (impacting existing functions)