In today's world cybersecurity is about more than just antivirus software and endpoint security software. Technical due diligence is a given in almost every acquisition or investment involving technology companies. While a tech diligence checklist can be daunting for acquirers and targets alike, a new study published by (ISC)2 confirms that auditing for cybersecurity is—and should be—at the top of the checklist.
In fact, the (ISC)2 survey of 250 US-based M&A professionals showed that 100 percent of the executives and M&A advisors surveyed agreed that cybersecurity audits have become standard practice.
To understand why companies are auditing for cybersecurity, we must first understand the risk. In the same study, (ISC)2 found that security breaches that come to light during the due diligence process can derail a transaction; in fact, almost half (49 percent) of participants said they had seen it happen.
Unsurprisingly, 52 percent of respondents viewed an audit revealing weak security practices as a liability. The same number said a post-acquisition security breach in an acquired company has affected the share value of a publicly traded organization. It’s clear a cybersecurity breach can significantly affect shareholder value. During M&A integration, it’s critical to expose and deal with any potential weakness at a target company.
Fred Bals is a senior technical writer at Synopsys.
Measuring risk
Cyberrisk is measured by comparing a company’s operational processes against some form of standard and reporting the results. How that evaluation is accomplished varies, including the standard chosen, the manpower consumed, and the credibility of the resulting report which rests upon the consulting firm’s reputation for its cybersecurity expertise.
Assessing cybermaturity against a widely recognized standard is the best option for tech due diligence. The Cyber Security Framework (CSF) developed by NIST is by far the most often recommended benchmark, and it should be adopted as the foundation upon which to build a cyber risk assessment. It was developed by experts, is hailed as the gold standard in the US, and is gaining considerable interest outside North America.
The level of manpower consumed during an assessment is another key issue. After signing a letter of intent that defines the planned transaction, the typical due diligence period is 60 to 90 days, and a cyber risk assessment must fit within that period.
Cybersecurity assessments
Traditional one-time cyber assessments involve hiring a large consulting firm with its own proprietary checklists. Large numbers of analysts fan out across the organization to gather information, and in the end, a comprehensive report based on the checklists is delivered.
But this traditional approach is seldom practical for a pending acquisition. It takes too long to fit within the due diligence period, the additional temporary staff introduced are disruptive to operations, and the process can raise suspicion among employees about a pending transaction.
An automated process based upon recognized standards like CSF, HIPAA, and FFIEC is the optimal answer for assessing cyber risk during technical due diligence. Automating with an audit platform based on these standards enables completion of a comprehensive, organization-wide assessment within a much shorter period. The manpower consumed is minimized, and the credibility of the result is maximized.
The need for open source audits
There are many angles to consider when auditing for cybersecurity in an M&A transaction. For example, Is the target using open source components in their applications? Both the target and acquirer might be surprised to discover that there’s better than a 90 percent chance that they are.
Analysts such as Forrester and Gartner note that over 90 percent of IT organizations use open source software for mission-critical workloads and that open source components often comprise the bulk of some application’s code.
Even though it’s likely that their applications include third-party open source components, many companies don’t adequately track their use of open source, relying on spreadsheets and developer self-management if they’re thinking about their open source use at all.
Few of those organizations can produce an accurate, up-to-date inventory (also known as a “Bill of Materials” or BoM) of the open source components used in their applications, as well as those components’ licenses, versions, and patch status. In consequence, they open themselves, their customers, and potential acquirers to risk.
While the number of vulnerabilities in open source is small compared to proprietary software, over 7,000 open source vulnerabilities were discovered in 2018 alone. Over 50,000 have emerged over the past two decades. Of the codebases reviewed by the Synopsys Black Duck Audit Services team in 2018, 60% contained at least one open source vulnerability. Over 40% contained high-risk vulnerabilities, and 68% contained components with license conflicts.
Open source vulnerabilities
Only a handful of open source vulnerabilities—such as those infamously affecting Apache Struts or OpenSSL—are ever likely to be widely exploited. But when such an exploit occurs, the need for open source security becomes front page news—as it did with the Equifax data security breach of 2017.
A major contributing factor to Equifax’s breach was the company’s lack of a comprehensive IT asset inventory. “This made it difficult, if not impossible, for Equifax to know if vulnerabilities existed on its networks,” a report on the incident concludes. “If a vulnerability cannot be found, it cannot be patched.”
Not everyone learns from the mistakes of others. In the year following the Equifax breach, Fortune published a piece under the headline “Thousands of Companies Are Still Downloading the Vulnerability That Wrecked Equifax.”
Tracking open source licensing is another part of open source use that the target organization may not be paying enough attention to.
Do they know whether the licenses of the open source components their applications include are permissive or viral? Are those components using one of the most popular open source licenses or a one-off variant?
Unless an organization is complying with any obligations and restrictions of the licenses for every open source component they use, an acquirer could theoretically lose rights to proprietary code or even have the ownership of IP called into question. If nothing else, questions concerning IP ownership could—and has in the past—derail an M&A transaction.
Other Types of Cybersecurity Audits
Open source audits are one type of audit that companies are performing in M&A due diligence, but it’s not the only one. Acquirers ask questions about many aspects of the security risk of the software they’re acquiring:
- Are there any security weaknesses in the proprietary code?
- Is the architecture sound?
- Do the target’s software development processes take security into account?
- Does the application call any external APIs that expose it to further risk?
At the end of the day, the goal of tech due diligence is to eliminate surprises after the deal closes. According to the (ISC)2 report, 57 percent of respondents had been surprised by an unreported data breach during the audit process. In M&A, uncovering these issues before the deal closes helps the acquirer not only put the proper deal terms in place but also plan for integration costs, priorities, and timelines post-deal.
Fred Bals is a senior technical writer at Synopsys.
- Find the best cloud antivirus here
