Cyber Due Diligence: Why is this so important for M&A?

5 min read

4 people holding up signs. The first two have a sign with a tick covering their face. The third has a sign with an X showing her face. The last with a tick sign covering their face.
https://www.pexels.com/photo/four-people-holding-signage-1656594/

Cyber due diligence is increasingly taking the spotlight when considering M&A transactions. With the rise of cyber attacks across organizations, acquirers are now having to address the impact of a target company’s incidents to determine the deals they make. According to EY Global Information Security Survey 2018-19, 77% of organizations have limited cybersecurity. Cyber due diligence is important to avoid the devaluation of your organization!

What is cyber due diligence?

The official definition of cyber due diligence is ‘the review of governance, processes and controls that are used to secure information assets’. Essentially, cyber due diligence teams will gather a target’s risk profile and make recommendations to the purchaser.  

Would you buy a home without having it inspected by a surveyor? Many people wouldn’t. In the past, the lack of inspection has proven to cause traumatic consequences. Take the Grenfell Tower fire of 2017. The lack of inspection in the build, design, and maintenance of this residential building (and many others discovered after the tragedy) has made building due diligence a crucial aspect to many organizations. The same can be said when applying cyber due diligence. Proper attention to issues within a target company will allow more informed decisions and safer outcomes.

A picture of an architectural map with a hand holding a pen over it.
https://www.pexels.com/photo/adult-architect-blueprint-business-416405/

The importance of cyber due diligence is seen through the example of Yahoo! In late 2004, senior offices and legal staff learned that unauthorized access to its computer network had been gained by what Yahoo! had identified as ‘state-sponsored actor’. However, the board had not received a report. In 2016, Yahoo! and Verizon Communications entered a stock purchase agreement. Yet, around the same time, a hacker claimed to have obtained Yahoo! user data. Shockingly, after doing checks they found that up to 500 million user accounts had been stolen from Yahoo!’s network in 2014. Not surprisingly, this meant Yahoo! had to modify their terms with Verizon.

This proves how cyber due diligence is essential when making M&A transactions as it strongly influences the decision of the acquirer in regards to their target company. 

Financial, Legal and Technical Due Diligence

Although cyber due diligence does not provide an accurate picture, it still allows the acquirer to have a good approximation of the condition of a target’s digital assets. An acquirer will have a process in their assessment of a target company and will examine:

  • How much money does the company have, spend and earn? 
  • What are the margins of the target’s competitors?
  • Is the company in any debt?

This is financial due diligence. Every investment has a level of risk. There needs to be in-depth research to understand the risk well, and to avoid any harm to either party in the transaction. Avoiding financial due diligence can result in misunderstandings from the investor and cause them to be responsible for financial loss after the deal is closed.  If you’re a business owner, ask yourself:

  • Does your company own the software?
  • What is the IP ownership of the software your company has created?
  • Is your company in compliance with its legal obligations with respect to software licences, software updates, data protection and processing laws?
  • What are the risks if compliance fails?

Here we have legal due diligence. This helps both entities work together to push forward a deal by addressing any legal problems that might be obstructing a decision. So this is when an M&A document will be produced. Legal due diligence is very important: the general law does not, in the absence of fraud or misrepresentation, protect the acquirer if they later see the business is not what they understood it to be. So buyer beware! Understanding the target’s liabilities is crucial. Make sure your legal team knows what they are doing, as they have the important role of communicating to external advisers.

A picture of a skyscraper.
https://www.pexels.com/photo/apartment-apartment-building-architecture-building-323705/
  • Assess the infrastructure of the company 
  • Assess and network of the company
  • Assess the security and intellectual property risks of a company’s software products by reviewing its software bill of materials (SBoM).  Are all the software’s dependent components used according to their respective licences and rightfully owned?  Are the third party and open source software free of security vulnerabilities?
  • Evaluate the cybersecurity program protecting the high-value digital assets: is it appropriate?
  • Look at the target company’s previous breaches and how they responded to the incident?
  • Assess the target’s resilience and ability to resist cyber attacks on their digital assets in the future

Be a technical due diligence wiz and know what your technical assets are. Technical due diligence allows to identify any vulnerabilities within the software or network of the target company. Look at the product, the infrastructure and its processes. Many software applications rely on open-source software components. If left unsecured (or used at whim without due diligence assessing its risk to the business), this creates a potential weakness for organisations from two aspects. Firstly, vulnerable open source components are popular attack vectors for cyber attackers. Secondly, having components with a licence that’s not compatible with your company’s policy could harm your business. Companies should make sure their software is being used in compliance with its licence so they can avoid being sued for improper use of intellectual property.

As seen with the example of Yahoo!, the lack of technical due diligence allowed Verizon to make an uninformed decision. Although this was also a problem with Yahoo! not disclosing the issue, it shows how legally the deal had to be adapted and both companies suffered financial loss. This shows the integrated importance of financial, legal and technical due diligence, and the areas that need to be addressed by the acquirer during M&A transactions and considerations. 

How can Meterian help with due diligence process?

With Meterian, you can automate the due diligence of identifying and patching open source risks in minutes. Immediately see if open source components used in your team’s project code bases are free of security, stability and licensing risks. So that you don’t run into any surprises down the line in your code’s software supply chain. 

Although open source applications are built to a very high standard, open source software does not come with any guarantees of quality.  It is the user of the open source software that is responsible for assuring its quality (and therefore data processing security). There are still licence agreements one must comply with.  Since anyone can download and use open source software, without payment, it’s difficult for organisations to know what’s used in their code bases. Meterian helps companies ensure their software is audit ready and all open source licences are compliant and business friendly. Our software scanner runs and checks as developers build the software, so why not put your mind at rest and strengthen your business? See sample reports and analyse 1 free codebase by signing up on our website today.

Cyber Due Diligence: Why is this so important for M&A?

New Java Vulnerabilities!

4min read

Attention to all Java users! Yes, we are back with a brand new set of Java vulnerabilities that I know you would like to get some juicy info on. During September 2019, two Java vulnerabilities have been discovered within the Apereo CAS versions before 6.1.0-RC5 and the Apache Tapestry versions between 5.4.0 to 5.4.3. The former open source vulnerability has been given a score of 8.1 whilst the later a higher score of 9.8 in regards to severity. So hurry, read up and don’t waste any time. You could be affected!

  • CVE-2019-10754 Apereo CAS (org.apereo.cas:*) components could allow a remote authenticated malicious user to obtain sensitive information, caused by the use of weak RandomStringUtils PRNG algorithm. 
  • CVE-2019-0195 Manipulating classpath asset file URLs, an attacker could guess the path to a known file in the classpath and have it downloaded.

CVE-2019-10754 

Vulnerability Score: 8.1 / HIGH

Platform: Java

Component: org.apereo.cas (Apereo CAS) 

Affected Versions: versions before 6.1.0-RC5

That’s right folks! Java has another vulnerability. Due to multiple classes using Apereo CAS (before the release of 6.1.0-RC5) and making use of apache commons-lang3 RandomStringUtils for token and ID generation, this has made them predictable and resulted in a cryptography weakness.

Apereo CAS is an open well-documented protocol, as well as an open-source Java server component. It provides support for multiple protocols (CAS, SAML, OAuth, OpenID) and is a library for clients such as Java, .NET, PHP, Perl, Apache, uPortal and more! Apereo’s mission is to help educational organizations ‘collaborate to foster, develop, and sustain open technologies and innovation to support learning, teaching and research’.

For example, org.apereo.cas:cas-server-support-simple-mfa is a package that allows Apereo CAS to act as a multifactor authentication provider by itself. This generates tokens and allows them to be sent to end-users via pre-defined communication channels such as email or text message. Please also note that this vulnerability affects multiple components of the Apereo CAS framework. 

So what is the threat? Well, the affected versions of this package are vulnerable to Insecure Randomness, as it relies on apache commons-lang3 RandomStringUtil  which can produce predictable results. So, this could allow an attacker to generate their own unique Ticket ID due to insufficient randomness. In other words, the attacker could guess the encryptionSecret used within GenerateJwtCommand and allow them to impersonate a user. This also means the attacker will have access to sensitive information caused by the use of the weak RandomStringUtils PRNG algorithm. 

Image showing user communicating with the server, and the hacker impersonating the user.

But don’t fret. There is a solution. It has been recommended to upgrade org.apereo.cas to version 6.1.0-RC5 or higher.

Java users, don’t give cyber criminals the chance to access your data. Act fast and upgrade org.apereo.cas! 

CVE-2019-0195

Vulnerability Score: 9.8 / CRITICAL

Platform: Java

Component: org.apache.tapestry (Apache Tapestry)

Affected Versions: versions 5.4.0 to 5.4.3.

We are not done yet folks! We have one more Java vulnerability to inform you guys on. Within the Apache Tapestry versions 5.4.0 to 5.4.3, the manipulating classpath asset file URLs allow an attacker to guess the path of a known file in the classpath and, as a result, download it. This was discovered on the 16/09/19 by Thiago H. de Paula Figueiredo.

The Apache Tapestry is an open-source framework for creating web applications in Java or other JVM languages. It also complements and builds upon standard Java Servlet API and works in any application server. Apache Tapestry has a long history. It has the oldest code, dating all the way back to 2000. This has resulted in many releases; developers now concentrate on Tapestry 5 as opposed to 3 and 4. 

What is tapestry.hmac-passphrase you say? This symbol is used to configure hash-based message authentication of Tapestry data stored in forms, or in the URL. In other words, your application is less secure and therefore more vulnerable to denial-of-service attacks. Especially when this symbol is not configured.

With various techniques, an attacker could guess the path to a known file in the classpath and have it downloaded. If the attacker found the file with the value of the  tapestry.hmac-passphrase configuration symbol, then they could use it to craft a Java deserialization attack, thus running a malicious injected Java code. 

Image showing a hacker guessing a file location, downloading the pass phrase and a computer showing it is has been hacked.

The recommended mitigation for this vulnerability has been suggested to upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x version. 

That is it from us…for now! Make sure to spread the word on these critically-rated Java vulnerabilities in order to help the app sec community defend against unwanted exploits. But as you all know, open-source vulnerabilities are discovered daily, so we recommend you regularly scan your code repositories for new known vulnerabilities. Don’t get caught off guard!

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously.  Sign up here to download the Meterian client today.  You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

New Java Vulnerabilities!

Why do I need Meterian? My code is secure.

This is really a good question, that many potential prospects are asking us. For most of the time the answer is easy: we can point them to hacks to the likes of Equifax, British Airways, Carphone Warehouse and so on. But what if someone believes they’re already protected?

We are already checking our code!

Yes, some of us already have a SAST solution in place, like SonarCube or Fortify, and we think we are fully protected. Some of us instead use opensource alternatives, like Spotbugs or PMD, and we also feel okay. These tools will continuously scan your developers’ source code and make sure that it’s not including any pattern that could be exploited by a malicious hacker.

On top of that, we have already secure coding in place: we use peer reviews and pair programming, so that all our code is severely scrutinized. We use a set of agreed secure coding practices, we follow detailed checklists, and we have developers trained continuously on these matters. And yes, that’s good!

But not everything is written from scratch…

When developers code, they do not write everything from scratch. Have you ever been surprised at how little time it took a piece to be delivered? Maybe, just once. And you ask how did that happen? Your developers, rightly so, dipped into the big pool of opensource and pulled a component that was able to accelerate their development, providing ready to use building blocks so that they could concentrate only on the business logic.

Those opensource components are so widely used, that in your final packaged product, up to 80% of the code is made of those components. Only a mere 20% is the carefully crafted code by your developers, where your internal practices and existing tools make a difference. But who’s checking the security of those opensource components? Well, it so happens that many people across the world checks them. This allows the components to evolve quickly. When a problem is found, either a bug or a security problem, it’s rapidly fixed and a new version of the component is released. When this becomes a security problem, often the issue is publicly reported in specific mailing lists or newsrooms dedicated to security.

How do you know an opensource component needs to be updated?

The core problem is, how do you know about all this? How does your team become aware that a certain component they use is now vulnerable, and that they need to update to a new version? How do they make sure that the code they do not write, which could account for 80% of your product, is also secure? Do you maintain a team the does these things? A team that painfully scrutinises multiple news sources, makes sure that your application does not contain a vulnerable or out of date component, alerting your developers accordingly?

This is where SCA (Software Composition Analysis) like Meterian enters the scene. These products are a natural complement to tools like SonarQube or PMD, as they check the code your team did not write. Typically running along with your build system, they will prevent your product to go live if a vulnerable component is discovered and will provide your developers the information they need to fix the problem immediately (and, in some occasions automatically). You will be able to secure 80% of the code your development teams produce without investing a fortune, without further head count, and with a minimal integration effort.

So, if you do not have a solution for your opensource components in place, it won’t hurt taking a look at Meterian: it’s an all round affordable system that will give you peace of mind about the code that developers do not write. And, by the way, it also checks component licences, but this is for another blog post 🙂

Why do I need Meterian? My code is secure.