In the past year I had a pleasure working with a number of startups on improving their security posture. I would like to share some common pain points here and what to do about them.
Advising startups on security is not easy, as it tends to be a ‘wicked’ problem for a cash-strapped company – we often don’t want to spend money on security but can’t afford not to because of the potential devastating impact of security breaches. Business models of some of them depend on customer trust and the entire value of a company can be wiped out in a single incident.
On a plus side, security can actually increase the value of a startup through elevating trust and amplifying the brand message, which in turn leads to happier customers. It can also increase company valuation through demonstrating a mature attitude towards security and governance, which is especially useful in fundraising and acquisition scenarios.
Security is there to support the business, so start with understanding the product who uses it. Creating personas is quite a useful tool when trying to understand your customers. The same approach can be applied to security. Think through the threat model – who’s after the company and why? At what stage of a customer journey are we likely to get exposed?
Are we trying to protect our intellectual property from competitors or sensitive customer data from organise crime? Develop a prioritised plan and risk management approach to fit the answers. You can’t secure everything – focus on what’s truly important.
A risk based approach is key. Remember that the company is still relatively small and you need to be realistic what threats we are trying to protect against. Blindly picking your favourite NIST Cybersecurity Framework and applying all the controls might prove counterproductive.
Yes, the challenges are different compared to securing a large enterprise, but there some upsides too. In a startup, more often than not, you’re in a privileged position to build in security and privacy by design and deal with much less technical debt. You can embed yourself in the product development and engineering from day one. This will save time and effort trying to retrofit security later – the unfortunate reality of many large corporations.
Be wary, however, of imposing too much security on the business. At the end of the day, the company is here to innovate, albeit securely. Your aim should be to educate the people in the company about security risks and help them make the right decisions. Communicate often, showing that security is not only important to keep the company afloat but that it can also be an enabler. Changing behaviours around security will create a positive security culture and protect the business value.
How do you apply this in practice? Let’s say we established that we need to guard the company’s reputation, customer data and intellectual property all the while avoiding data breaches and regulatory fines. What should we focus on when it comes to countermeasures?
I recommend an approach that combines process and technology and focuses on three main areas: your product, your people and your platform.
Think of your product and your website as a front of your physical store. Thant’s what customers see and interact with. It generates sales, so protecting it is often your top priority. Make sure your developers are aware of OWASP vulnerabilities and secure coding practices. Do it from the start, hire a DevOps security expert if you must. Pentest your product regularly. Perform code reviews, use automated code analysis tools. Make sure you thought through DDoS attack prevention. Look into Web Application Firewalls and encryption. API security is the name of the game here. Monitor your APIs for abuse and unusual activity. Harden them, think though authentication.
I talked about building security culture above, but in a startup you go beyond raising awareness of security risks. You develop processes around reporting incidents, documenting your assets, defining standard builds and encryption mechanisms for endpoints, thinking through 2FA and password managers, locking down admin accounts, securing colleagues’ laptops and phones through mobile device management solutions and generally do anything else that will help people do their job better and more securely.
Some years ago I would’ve talked about network perimeter, firewalls and DMZs here. Today it’s all about the cloud. Know your shared responsibility model. Check out good practices of your cloud service provider. Main areas to consider here are: data governance, logging and monitoring, identity and access management, disaster recovery and business continuity. Separate your development and production environments. Resist the temptation to use sensitive (including customer) data in your test systems, minimise it as much as possible. Architect it well from the beginning and it will save you precious time and money down the road.
Every section above deserves its own blog and I have deliberately kept it high-level. The intention here is to provide a framework for you to think through the challenges most startups I encountered face today.
If the majority of your experience comes from the corporate environment, there are certainly skills you can leverage in the startup world too but be mindful of variances. The risks these companies face are different which leads to the need for a different response. Startups are known to be flexible, nimble and agile, so you should be too.
Governments across Europe recognised that with increased interconnectiveness a cyber incident can affect multiple entities spanning across a number of countries. Moreover, impact and frequency of cyber attacks is at all-time high with recent examples including:
- 2017 WannaCry ransomware attack
- 2016 attacks on US water utilities
- 2015 attack on Ukraine’s electricity network
In order to manage cyber risk, the European Union introduced the Network and Information Systems (NIS) Directive which requires all Member States to protect their critical national infrastructure by implementing cyber security legislation.
Each Member State is required to set their own rules on financial penalties and must take the necessary measures to ensure that they are implemented. For example, in the UK fines, can be up to £17 million.
And yes, in case you are wondering, the UK government has confirmed that the Directive will apply irrespective of Brexit (the NIS Regulations come into effect before the UK leaves the EU).
Who does the NIS Directive apply to?
The law applies to:
- Operators of Essential Services that are established in the EU
- Digital Service Providers that offer services to persons within the EU
The sectors affected by the NIS Directive are:
- Health (hospitals, private clinics)
- Energy (gas, oil, electricity)
- Transport (rail, road, maritime, air)
- Digital infrastructure and service providers (e.g. DNS service providers)
- Financial Services (only in certain Member States e.g. Germany)
NIS Directive objectives
In the UK the NIS Regulations will be implemented in the form of outcome-focused principles rather than prescriptive rules.
National Cyber Security Centre (NCSC) is the UK single point of contact for the legislation. They published top level objectives with underlying security principles.
- A1. Governance
- A2. Risk management
- A3. Asset management
- A4. Supply chain
- B1. Service protection policies and processes
- B2. Identity and access control
- B3. Data security
- B4. System security
- B5. Resilient networks and systems
- B6. Staff awareness
- C1. Security monitoring
- C2. Proactive security event discovery
- D1. Response and recovery planning
- D2. Lessons learned
Table view of principles and related guidance is also available on the NCSC website.
Cyber Assessment Framework
The implementation of the NIS Directive can only be successful if Competent Authorities can adequately assess the cyber security of organisations is scope. To assist with this, NCSC developed the Cyber Assessment Framework (CAF).
The Framework is based on the 14 outcomes-based principles of the NIS Regulations outlined above. Adherence to each principle is determined based on how well associated outcomes are met. See below for an example:
Each outcome is assessed based upon Indicators of Good Practice (IGPs), which are statements that can either be true or false for a particular organisation.
If your organisation is in the scope of the NIS Directive, it is useful to conduct an initial self-assessment using the CAF described above as an starting point of reference. Remember, formal self-assessment will be required by your Competent Authority, so it is better not to delay this crucial step.
Establishing an early dialogue with the Competent Authority is essential as this will not only help you establish the scope of the assessment (critical assets), but also allow you to receive additional guidance from them.
Initial self-assessment will most probably highlight some gaps. It is important to outline a plan to address these gaps and share it with your Competent Authority. Make sure you keep incident response in mind at all times. The process has to be well-defined to allow you report NIS-specific incidents to your Competent Authority within 72 hours.
Remediate the findings in the agreed time frames and monitor on-going compliance and potential changes in requirements, maintaining the dialogue with the Competent Authority.
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.
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:
- Risks that should be addressed before the deal can be signed (red flags)
- Items that should be included in the contract (conditions on signing the deal)
- 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.
The focus of many of my projects is on risks. I’ve observed through multiple assessments in various companies and industries a lack of formalised risk management process. Some of the plans may exist but they are not linked to specific risks and risk reduction levels are not being measured and reported on appropriately.
The security function can be effective in responding to incidents but the strategic risk-driven planning is often missing. The root cause of this state of affairs is often can be generalised as low maturity of the security function. If that’s the case, the team spends most of its time fighting fires and have little capacity to address the challenges that cause these fires in the first place.
To address this, I assess current state of the security function, define the target maturity level and then develop a high-level roadmap to achieve that desired state.
If the company is geographically distributed, noticeable differences usually exist between a number of business units in terms of overall policy framework. The suggestion here is to define a baseline level of security controls across the entire enterprise. The first step in defining these is to understand what we are trying to protect – the assets.
Modern corporations own a wide range of assets that enable them to operate and grow. They broadly include physical and non-physical assets, people and reputation. Engagement from appropriate parts of the business to identify these is important here as potential attacks to these assets might negatively affect the operations.
By understanding the assets we are able to better identify risks, enable effective detection and response, and prioritise controls and remediation efforts better.
It also helps to conduct a bottom-up review of assets to understand what exactly we’ve got there, focusing on the most critical ones and creating and updating asset inventories.
Understanding the asset base and setting standards and guidance for protecting them will focus the efforts and help you prevent and better respond to security issues.
Assets are tightly linked to threat actors, because it’s not enough to know what we need to protect – we also need to know what we are protecting our assets against. Threat actors vary in their motivation and ability and – depending on the company – include nation states, organised crime, insiders, hacktivist, competitors, etc.
A combination of assets and threats helps us to define risks.
Identifying risks and placing them on a heat map helps determine the inherent, residual and target risks. Inherent risks show the level of risk assuming all the controls or remediating measures were absent or failing. Think of it as if security function didn’t exist. It’s not a happy place where we see the majority of risks have high impact and likelihood being in the top right hand side corner of the chart.
Luckily, security function does exist and even if they don’t have a formalised risk management process, they are usually doing a good job in addressing some of these risks.
Current level of risk is taking into account all the controls and remediating measures in place. The initial impact and likelihood is usually reduced and sometimes to an acceptable level agreed by the business. The idea here is although further reduction of impact and likelihood is possible, it might not be cost-effective. In other words, the money might be better spent in addressing other risks.
Target risks is the future state risk level once additional controls and remediation measures are implemented by the security team.
The main takeaway here is that a formalised risk management approach (with accompanying processes and policies) is needed to ensure all risks are identified and tracked over time, and the appropriate resources and efforts are spent on the top priority risks.
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.
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:
- Quantitatively managed and
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.
“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
“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