Cryptographic Vulnerabilities, News & Research

November 8, 2019

Automated Attack Trees for TLS Vulnerabilities: Improving Cryptosense Discovery

What’s new?

Cryptosense Discovery is our free tool to test a host’s usage of cryptography for common configuration mistakes and vulnerabilities. Discovery’s new version discovers more hosts and more vulnerabilities, and improves the visual representation of attacks. We achieve this by using a well-known visualization method called attack trees. Attack trees do not simply report scores: they explain why a host is vulnerable and what the user must fix first. This greatly eases the hard job of correctly configuring TLS servers — especially at scale, when prioritizing tasks is not always trivial.
Continue reading →

November 5, 2019

Partnership with Unbound Tech

We’re delighted to announce a new partnership with Unbound Tech. Their Distributed Trust Platform is the first pure-software solution that protects secrets such as cryptographic keys, credentials or other private data by ensuring they never exist anywhere in complete form. As such it’s an interesting target for our customers using Cryptosense Analyzer Platform to migrate their applications to cloud crypto services.
Continue reading →

September 20, 2019

Using Cryptosense Analyzer in Containerized Applications

Containers are often designed to be stateless. That means all state changes made by the application happen in the database, or some external storage. They don’t happen on the container filesystem.

Previously, this made using Cryptosense Analyzer difficult. That’s because our IAST cryptography analysis tool works by tracing the calls an application makes to its cryptography libraries, and writing them to a trace file for later upload to Analyzer.
Continue reading →

August 26, 2019

What is Cryptographic Inventory?

Companies that handle sensitive data are frequently required to demonstrate to internal or external auditors that they use cryptography appropriately as part of their data protection strategy. This requires them to use a definition of acceptable cryptography (that often comes directly from a standards body like NIST/FIPS or PCI-DSS), and evidence that this policy is enforced throughout their infrastructure.

An automated, up-to-date Cryptographic Inventory provides this evidence. It can also be leveraged to develop “crypto agility” (the ability to change cryptographic libraries and algorithms rapidly when required). But what exactly should you put in a “crypto inventory”, and how do you make one efficiently?

Continue reading →

June 20, 2019

Cryptosense Automates PCI-DSS Cryptography Audit for a World-Leading Financial Services Firm

A recent success story for Cryptosense is our roll-out with a large global player in the ATM (cash machine) network.

Since this firm is considered a Service Provider in the PCI regulations, they have regular audits to pass which contain a lot of requirements on cryptography: full cartography of applications, compliance with NIST standards etc.

This used to take our customer a lot of time and resources, but since our Analyzer platform doesn’t just report cryptographic issues but correct, compliant use of cryptography, it’s the ideal tool to take over this job and free up resources for more productive tasks. The reports produced by the Analyzer are produced automatically thanks to our integration with Maven in CI, and contain coverage information to validate the testing. We worked with 3key Company to deliver the install.

Read more about this case study here (1 page PDF).

June 20, 2019

Improving PKCS#11 Vulnerability Analysis

As well as treating applications in Java and .NET, Cryptosense Analyzer can also check the cryptographic security of PKCS#11 implementations in HSMs and elsewhere. We recently added a few of improvements requested by our users.

Detecting Multiple-Step Vulnerabilities

Continue reading →

April 23, 2019

Detecting hard-coded cryptographic keys, passwords and credentials

Including passwords or cryptographic key material in source code is a major security risk for a number of reasons. In the worst case, if the code is public, everyone can read the key. Even if not, access to the code is often easier for an attacker to achieve than direct compromise of the application – the entire development team becomes part of the attack surface. Having obtained the keys, the attacker may no longer need to compromise the application at all, and the breach can go completely undetected since there is nothing in the logs when encrypted data is decrypted offline.

Hardcoding the keys is also a problem for key rollover, and for cryptographic agility. So, we’re convinced we need to get rid of them, but how can we check for them at scale across hundreds or thousands of applications?

Continue reading →

April 23, 2019

How common is insecure cryptography?

Application security teams have limited resources for improving security. Deciding where to deploy them is not easy, and the right answer will vary for different organisations. However, one question we’re often asked by teams considering our Analyzer software is, how common are the kind of “rubber hits the road” deployment of crypto flaws that it detects?

Continue reading →