In today’s age, cybersecurity is a key element of any technical due diligence effort. Cyber-attacks are on the rise and everyone is affected (Don’t believe me? Check your home router logs if you have the know-how and you will likely see attempts to gain access to your personal systems). An estimated 67% of small and medium-sized businesses experienced a cyber-attack in the past 12 months, with 58% experiencing a data breach (reference) causing significant harm to companies and their reputations. Since many investment targets today store personal data, such as personally identifiable information (PII), protected health information (PHI), and even credit card numbers, keeping that data secure is paramount to a successful business. For an SMB, one breach could mean disaster. As a result, it is important to validate security practices and technology during diligence.
Failing to uncover security issues prior to close could increase the investment risk significantly, or substantially increase remediation costs to fix any found issues. This cost figure may affect valuation, so it is preferable to know the issues upfront. In one recent diligence, the cost to remediate the issues, which mostly centered around security, was estimated to be as much as the company’s purchase price! Needless to say, the investor walked away after technical due diligence uncovered all the issues.
Although not an exhaustive list, listed below are some key questions to ask during technical due diligence about cybersecurity. Many of these should be asked as early as possible during the investment process. This does not replace having an experienced advisor help uncover the issues but may help expose some red flags early on.
- Have you ever been the target of a cyberattack and particularly a successful one? If so, what did you do about it?
- If the answer is “no”, the team may be naïve when it comes to cybersecurity. Some companies may not be aware that they have been breached. “Are you sure?” is an appropriate follow-up question to ensure they take security and monitoring seriously. Are they capable of detecting an intrusion? If they have been the subject of an attack, it is important to know how they responded and that the appropriate controls were implemented to prevent future attacks of this nature.
- What customer data are you storing and how do you protect it?
- If sensitive data such as a US social security number/Canadian social insurance number or information about minors is stored in the database, the data must be robustly encrypted along with very limited access to the production system and minimal/no copies of the database made internally without data masking/sanitization. Just encrypting the data in transit (e.g. using TLS v1.3 between servers) is not enough – the data must be encrypted at rest, and ideally not just at the storage level (the disk) but also field level.
- How do you manage and protect cryptographic keys for encrypting data?
- It seems like a detailed question to ask early in diligence, right? Here are two recent stories. One company included their Amazon Web Services keys as part of their source control history. When they open-sourced a component along with source history, hackers picked up the keys from GitHub within minutes and ran up tens of thousands of dollars in computing bills. In another case, an employee at the target company managed the keys himself and demanded a ransom post-close. You can’t make this stuff up. A robust key management system helps generate, store, and manage security keys.
- If an incident does occur, how do you respond? Are systems and processes in place to immediately contain the incident and respond in a timely fashion?
- A robust incident response plan and disaster recovery plan are paramount to rapid recovery in the event of a significant attack. If a hacker gains access to internal systems and data and demands a ransom, robustly tested backups can help bail out the company. A tested plan should exist to ensure roles are assigned with timely responses for business continuity. A root cause analysis (RCA) process on any successful attack helps to implement controls to prevent future attacks of the same nature.
- Are you subject to any compliance/regulations and when is the last time you validated that compliance?
- A couple of reasons behind this question: (1) helps to inform the types of questions to ask during more detailed diligence (e.g. we suspected that the company should be PCI compliant, but they are not??) (2) determine how stringently they are meeting compliance requirements, particularly if they have not had a recent audit (e.g. are they following all 12 PCI compliance requirements, and should we validate that during diligence?). If the last audit was more than 1 year ago, it may be a restriction on close that the audit be done first. Also, look for voluntary adherence to a cybersecurity framework such as the NIST Cybersecurity Framework.
- Have you ever done a penetration test? What were the results?
- More often than not, a company has not done a penetration test to find vulnerabilities in the company’s network, infrastructure, and application. Not having penetration testing results is a significant opportunity lost to find cybersecurity issues before a black hat hacker does. A penetration test should be commissioned shortly after close (or ideally pre-close) to validate defenses. If a penetration test was done, review the results and validate that the identified issues were remediated.
- How much Open Source Software (OSS) is used within the product?
- The use of OSS brings investment risk from two primary perspectives – license risk in the case of components that have reciprocal/copyleft licenses, and security risk to evaluate how large an exploitable attack surface is for black hat hackers. An OSS component inventory provided early in technical due diligence may encourage a comprehensive OSS scan using a commercial tool like Sonatype to validate license and security risk.
- How are authentication, authorization, and encryption methods implemented internally?
- Look for the use of industry-standard algorithms (e.g. OAuth2, or a service like Auth0) and libraries for security. A “roll your own” implementation is destined to have significant holes. A deeper dive into security at the code level may be needed depending on the answer, which should be verified regardless. In one recent example, the evaluation of a target yielded a home-grown authentication mechanism for user login that was easily hacked. That put all of the product data at risk, which contained some sensitive personally identifiable information.
- Provide some examples of how security is embedded into the R&D team culture.
- Look for an answer that provides evidence of physical security (e.g. screen locks, anonymous physical key cards), infrastructure security (e.g. policies and procedures for firewall configuration), and application/data security (e.g. security-oriented code reviews, use of a security static code scanner like Veracode, and QA testing with a security mindset). Phrases to look for include “defense in depth”, “encrypt”, “multi-factor authentication”, “phishing”, and “patch management”. Weak examples or lack of response informs deeper probing into security and team culture during technical due diligence.
- Who is responsible for security at the company?
- This is a trick question – the right answer is “everybody”. However, larger organizations should have a Chief Information Security Officer, and even smaller business should have someone that plays the role of security lead and can be a gatekeeper when making significant changes to a system that may affect security. Using Security Information and Event Management software or managed services is a best practice. Outlining roles and responsibilities as related to cybersecurity (e.g. accountable/responsible for various parts of an incident response plan) is very important to ensure a robust corporate security program.
Fully evaluating cybersecurity is an effort-intensive task. These questions, however, should get you started when undertaking due diligence of a software or technology-enabled company to surface any initial red flags. Note that diligence does not typically leave enough time for a deep dive in cybersecurity, so consider having a third-party (like Cyligent) come in post-close for a cybersecurity evaluation. Make sure your investment is not compromised!