It’s standard practice during the M&A due diligence process for the financial and legal teams to perform an onsite visit of the acquisition target. In some deals, IT due diligence is limited to an expert reviewing the source code and discussing, via phone or email, the current system environment with an IT contact at the target. This can be tempting, given the fact that many smaller companies are utilizing a cloud-based architecture, and there may be no local data center to visit. This approach is a mistake, however, and should be avoided.

There are numerous benefits to including an onsite visit as part of due diligence.

• To the extent that there are local IT resources such as servers, laptops, PCs, printers, etc., it’s important to compare the real world to the inventory list provided by the target, to be sure equipment is in good working condition and that it exists in the first place.
• In my experience, an IT professional can learn a lot about the target by simply walking around. I’ve seen things like tarps draped over server racks (“because it’s supposed to rain”) and sensitive files left in a room with a door wide open to the parking lot. While these are issues that are easy to address, they might give you additional information about the expertise and priorities of the target – before the transaction closes.
• By spending time onsite at the target, there’s an opportunity for the staff to develop a comfort level with you that you can’t get over the phone or via email. You may find when you get to know the IT staff even a little, that they can be very forthcoming with information, both good and bad. You might hear about a new product idea that’s under development, or a part of the target’s infrastructure that you can leverage in a way you hadn’t thought of before. On the other hand, you might find out that many on the staff are unhappy and looking for work, or that the product you’re buying has major scalability problems that you might not have detected via a source code review.
• Even brief interviews with the IT staff at the target can alert you to strengths and weaknesses, in terms of both technical skills and personality, that are not discernable from a resume. This can allow the acquirer to start thinking sooner about how the IT teams might be integrated.
• Finally, if the person leading the onsite visit during IT due diligence is a member of the acquiring company’s IT team, this provides an opportunity to start to develop a personal relationship with the target’s IT staff. The announcement of a merger or acquisition inevitably makes the staff at the target nervous. If the people they met from the acquiring company during due diligence made a good impression, it can help to reduce that concern and the possibility of losing key staff.

The onsite visit during IT due diligence can confirm assumptions, identify additional risks and opportunities and help the acquiring company get a head start on integration. All of these benefits make an onsite visit well worth the effort.

Open source software (OSS) has gone from something used mainly by startups and hobbyists to a resource that at this point is very much mainstream.  This article examines OSS and how it impacts IT due diligence.

What is Open Source?

Generally speaking, “open source software” refers to programs and projects that are developed by a company or an organized group of online programmers, and are made available with source code for free.  The software may be modified or redistributed by those who download it, subject to various open source license terms.

There is nothing inherently wrong with OSS or its use in commercial environments.  In a 2014 survey, Forrester research determined that approximately 80% of software developers utilize OSS.

Well-known examples of OSS include:

• Apache (web server)
• Linux (Unix-like operating system)
• MySQL (database software)
• PHP (website scripting language)
• WordPress (blogging software)

Today, OSS is used by companies of all sizes.  While it’s often favored by startups due to its low cost, companies like Google and Amazon run significant portions of their operations with open source tools.

While OSS is available at no cost, it is not always “free.”  There are often optional packaging and support costs. However, in almost all areas of technology, including operating systems, databases, web servers and software development tools, very capable open source alternatives to commercial software are thriving.

Open Source Security

Traditionally, one major concern regarding OSS has been security.  There are some valid points on each side of the argument.

Those who believe OSS to be less secure focus on the fact that, since the source code is available for anyone to see, a skilled hacker might be able to identify a vulnerability and exploit it.

Those who feel OSS is more secure than commercial products also point to the availability of source code, but their argument is that since many eyes are viewing the code, any security weaknesses introduced should be quickly identified. Large, well organized open source efforts can sometimes issue security updates more quickly than a commercial software company.

Open Source Licensing

OSS is made available under many standard licenses.   A list of common open source licenses and their terms can be found here:

http://opensource.org/licenses

Some licenses are very liberal, allowing the open source tool to be used in any way desired by an end user, including modification, redistribution and even resale.  At the other end of the spectrum, some licenses require that any redistribution includes the release of any supplemental or modified source code.

Some companies have completed an acquisition only to later find that certain software assets just purchased were based on open source projects with a very restrictive license.  In that case, the options are to release the source code, redesign an application to eliminate the open source component or to pull the product from the market.  Obviously, none of these are good outcomes.

Practical Due Diligence for Open Source

Given the concerns around security and licensing, there are a number of areas to explore during IT due diligence.

First, a list of open source projects utilized by the target company should be requested.  This should include the name and version of the project, the license under which the project is distributed and whether the open source component is used for internal or external purposes.

If open source is utilized only for an internal development or administrative utility, there is usually little if any concern, as it’s normally the external distribution of any enhancements that may trigger some of the more restrictive license terms.

The target’s response to this request should be examined to understand the requirements of the relevant licenses in conjunction with a detailed review of how the open source component is used.  This will allow the acquiring company to begin to understand whether there are any concerns.

Due diligence should determine the target’s process for deciding whether to use OSS.  Is a formal review of the open source license performed before a component is accepted for use?  Who makes the final decision?  Is this a senior staff member, with a thorough understanding of the related risks, or can an individual programmer make the decision in a vacuum?

The security concerns outlined earlier can be mitigated by the size of the open source community for a component and how active it is.  Large open source developer communities ensure that a project continues to be enhanced and supported.

Due diligence should examine, for key open source components used by the target, the process used by that open source project for reporting and responding to bug reports, especially as related to security issues.  Some of the largest open source projects have dedicated security response teams and a specific infrastructure related to security issues, but not all do.

Does the target closely track the updates to any open source components utilized?  Too often, companies bundle an open source component with a proprietary product, but don’t update the open source portion as that component is enhanced.  This can lead to the inclusion of outdated and potentially insecure OSS in the target’s own product.

Unfortunately, as the use of open source has increased in corporate environments, proper security practices have not kept pace. In its 10th Annual Future of Open Source Survey, Black Duck Software found that "50 percent of companies have no formal policy for selecting and approving open source code."

Audits

The terms and requirements in some restrictive open source licenses cascade to downstream use.  For example, it’s possible that the acquisition target uses a commercial software component in its product or service that in turn utilizes an open source component.  The target may not have any idea that the open source component is indirectly included in its own software.

Audit tools and services exist to identify open source components and their related dependencies in software.  Audit firms track the source code from thousands of projects and versions and can automatically identify this code in the target’s own source code or object code.

Black Duck Software is a leader in this space, and has even released a free tool that identifies known open source security vulnerabilities in an uploaded code archive file.

Reference

Everything you’d ever want to know about the history of the open source movement, license terms, etc. can be found here:

http://opensource.org/

Conclusion

There is nothing fundamentally wrong with the use of open source software by startups and other commercial enterprises.  However, during IT due diligence it’s important to determine whether the target is using any open source components intelligently and responsibly.

I’m happy to report that the 2016 Edition of the IT Due Diligence Guide has been released.

The need to include an IT review during M&A due diligence is greater than ever. Identifying IT shortcomings that can put a company’s (and a deal’s) future at risk is critical. Other issues that are uncovered that may not rise to the level of cancelling a transaction can still carry a high price tag to address, and it’s important to find these problems prior to the deal closing.

2015 and early 2016 saw the trends of substantial data breaches and related public relations disasters continue. Examples included Costco, CVS and a giant breach (as in 78 million+ records) at the American health insurer Anthem. And who can forget the fallout from the Ashley Madison debacle? Smaller companies are by no means immune to the same types of attacks.

The year also saw the expansion of underground hacker markets, where one can purchase stolen credit card data, online banking credentials, passports and hacking software, complete with 24/7 customer service, free trials and money-back guarantees. Or perhaps you’re looking for a million stolen frequent flyer miles, a hacking tutorial or the login and password for a Gmail account? All are available.

This means the threats to all companies and the related risks in M&A transactions are increasing. A 2015 UBM Tech survey of 185 IT professionals at medium and large companies revealed that 76% of those surveyed were only “somewhat” or “not very” confident that they can prevent a cyberattack, and that’s probably an optimistic number. Three percent of the survey respondents felt that they were “almost certain to get breached.” A 2015 KPMG survey showed that only 53% of healthcare systems (i.e. hospital chains) in the US consider themselves ready to defend against a cyberattack.

In fact, many security experts now see hacking as something that can’t be prevented, accepting the fact that it’s almost inevitable when a skilled and determined criminal is involved, and more as something to be quickly detected and mitigated.

These developments have led to a new way of thinking during IT due diligence. Not that many years ago, a hacking incident would have probably been difficult to get past when evaluating a company. With so many large company data breaches demonstrating how hard it is for even organizations with supposedly sophisticated IT resources to protect against determined hackers, it seems unfair and unrealistic to look at past IT security shortcomings at a smaller target company as a deal killer. The focus now must be on lessons learned, process improvements and the current level of vigilance at the target.

For 2016, the IT Due Diligence Guide has been expanded and updated to address the latest IT security concerns and technology practices. Questions have been added, explanations have been revised and there is a new appendix listing helpful resources. Recognizing the need for specialized expertise in certain situations, a new section discusses additional audits and reviews to consider including during an IT due diligence project. Finally, a post-transaction IT integration plan template is now part of the book package.

We’ve just published a new white paper: How the HIPAA Security Rule Impacts IT Due Diligence in Healthcare.

A recent survey of US healthcare executives by Capital One found that more than 40% of the respondents see M&A as a significant growth driver in 2016. This is no surprise – healthcare has been one of the most active M&A sectors for the past several years.

In the United States, IT due diligence in healthcare involves special considerations related to the security and privacy of patient data. The HIPAA Security Rule, which establishes standards and requirements related to the storage and transmission of electronic protected health information, increases the risks and costs of working with this data.

Proper IT due diligence of healthcare providers and vendors requires a solid understanding of the HIPAA Security Rule, and must include a deeper dive into the technology issues related to the Rule.

Download the white paper today to learn more about the unique aspects of performing IT due diligence on a healthcare organization.

Only a few years ago, if a technology company had suffered a hack or data breach, my recommendation probably would have been to not touch it with the proverbial ten-foot pole. These days, given the recent well-publicized hacks of companies like Target, Home Depot and Anthem (companies which have huge IT security budgets), that advice seems too simplistic.

If even the largest companies are vulnerable, you probably shouldn’t automatically refuse to acquire a company that has been victimized. In this article, I’ll discuss a framework to determine how heavily to weigh a previous hack or a data breach during M&A IT due diligence.

There are four major areas of investigation that I believe can lead to a reasonable decision.

What happened?

First, you need to understand exactly what occurred. A standard IT due diligence request list should start the process by asking if the company has ever suffered a hack, data breach or other system intrusion. If the answer comes back in the affirmative, you’ll have many more questions to ask.

You’ll have to determine how critical the compromised IT function is to the operation of the business. While a hack is an important concern for all businesses, it’s even more so for others.

The unfortunate reality is that credit card data breaches are occurring on a regular basis. There’s so much mass media publicity around this issue that, in my opinion, the general public has become fairly immune to them. Yes, a hacked company’s customers must endure the inconvenience of changing credit cards and monitoring their credit reports for identity theft attempts, but they largely give the hacked company a pass. Over the long term, there may not be a significant impact on the business.

On the other hand, consider the recent Ashley Madison episode. Obviously, in that company’s line of business, privacy of customer information is the top priority, and it remains to be seen how well the company will be able to recover.

You’ll need to consider for your target company whether the fact that a hack occurred at all is a deal killer.

Why did it happen?

If you get past the first question and are still considering the acquisition, the next step is to determine why the hack occurred.

You’ll want to determine if IT best practices were in place. Did the target company have a proper multi-layer security infrastructure, including firewalls, antivirus software and intrusion detection systems? Were those components maintained properly, including prompt application of software patches and operating system updates? Were company systems being monitored for security vulnerabilities by a competent third party on a regular basis (ideally at least daily)? Had any other security audits examined the infrastructure?

Even if all of the right things were being done, there are still reasons a hack could occur.

A company could be the victim of a "zero day" vulnerability. Once a security-related software defect becomes widely known, there is still a window during which a hacker can exploit the defect before an operating system or other software can be patched by the manufacturer. This also applies to new computer viruses that don’t match an existing signature or a general profile of operation, and require a fix to be developed, tested and deployed by an antivirus company.

If the company was the victim of a social engineering attack, the fault may not lie with IT at all.

The target could also have been the victim of an "inside job." For example, if a system administrator simply provided login credentials to an accomplice, the company could be remotely compromised without it necessarily being detected, although monitoring should still be able to identify unusual volumes or patterns of activity.

If you’re comfortable that the company had a competent and comprehensive IT security plan in place, you can move on to the next question.

How was it addressed?

Recent security lapses demonstrate that hacks and data breaches will be an ongoing threat. This means that any well-prepared company should have a response plan in place.

How did the target company identify that a hack had occurred? Some hacks are obvious – the website is defaced or no longer operates. Others are more insidious. The Anthem hack earlier this year was only discovered when a system administrator noticed his account actively downloading data when he knew it shouldn’t be. A company with a good IT security plan in place shouldn’t be the victim of a long-term data breach.

A good data breach response plan should include the following features:

• A list of people on the response team
• A requirement to keep detailed records of every remediation step taken
• Immediately disconnecting / shutting down affected systems
• High level steps to identify causes of the attack, including contact information for related vendors and consultants
• Contingency plans for notifying customers and law enforcement, as appropriate

How did your target company react when the hack occurred? Did the response follow a plan or was it improvised?

The most important step is ensuring that the vulnerability that was exploited is eliminated. Some hackers leave themselves a back door that can be used even after the original security hole is patched. Sometimes the only way to be sure that all traces of an attack have been removed is to acquire new systems and rebuild everything from the ground up.

A good practice for the reaction plan is to include an outside expert. They may have seen the problem before, and in any case will be less emotionally involved – the people who allowed the hack to occur may not be the best ones to determine that it’s resolved.

Did the target have cybersecurity insurance in place? This can pay for the costs of addressing the hack, notifying customers of the breach, providing customers with credit monitoring, etc.

How will it be prevented in the future?

If after further investigation you’re comfortable that the company did everything reasonably possible to prevent a hack and responded to it appropriately, then the final area you’ll want to be comfortable with is how future hacks will be prevented.

Are there any additional procedures or security levels that can be put in place?

Is someone responsible for monitoring the cybersecurity industry for new developments and techniques?

If the company previously had an annual detailed security assessment, maybe quarterly would make sense going forward. "White hat" hackers can be hired to proactively probe the company’s IT security in a more thorough manner than automated monitoring can provide.

If the company doesn’t provide regular training to its employees on IT security issues and social engineering, it’s relatively inexpensive to implement and can be a wise investment.

Dedicated IT security personnel may be necessary. Many companies have recently introduced a role along the lines of "Director of IT Security." In any case, you’ll want to take an objective look at the competence of the IT staff and be sure you have the right team in place going forward. If the target company has already made the decision on their own to invest in more expertise, that’s a positive sign.

Conclusion

A previous hack or data breach at a target company is no longer an automatic deal breaker in IT due diligence. A thorough investigation of the incident, along with a review of the underlying causes and the company’s response, can help you make a reasoned determination as to whether the issue should prevent the deal from closing.