Cryptographic Vulnerabilities, News & Research

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 →

March 22, 2019

Crypto Cartography: Mapping the Crypto in Applications

A first step of many cryptography projects, be it preparation for Cloud migration, crypto agility, or improving application security, is to map out the cryptography actually in use in an application.

A naive approach would be to just review the source code and search for cryptographic calls. However, this is both time-consuming and error-prone: what will the parameters be when this function is actually called? Which provider will respond to the call? Are we sure this isn’t dead code or an unused part of a library? On top of this, a lot of crypto in large applications is called by third party intermediate libraries and components of application frameworks for which source code might not even be available.

Continue reading →

February 28, 2019

New Cloud Crypto Service: Oracle Cloud Infrastructure KMS

We often talk about the “big three” cloud providers: AWS, Azure and GCP. Reliable market share data is hard to come by, but common thinking is that GCP are a little way behind the “big two”. Meanwhile, Oracle’s IaaS offering OCI (Oracle Cloud Infrastructure) is a long way behind the “big three”, and figures only as a thin Larry Ellison tie on AWS’ own market share presentations.

However, Oracle are now putting some very serious investment into their cloud in an effort to capitalise on their enterprise customer base. Several of our own large customers are looking at OCI as a possible alternative or complement to other CSPs.

OCI recently launched a cloud crypto service, so how does it measure up to the others in our cloud crypto comparison?

Continue reading →

January 21, 2019

Achieving Crypto Agility

A recent NIST paper recommending which steps to take to prepare for the advent of quantum computers proposes that users of cryptography look to achieve ‘crypto agility’ as soon as possible. The idea was further expanded by Gartner in a recent research note, and now crops up regularly. It’s sometimes described as ‘crypto-agnosticism’, but what does it mean, and how does one achieve it?

Designers of cryptographic protocols have talked for a long time about the idea of algorithm agility. The principle is simple: that a protocol will be designed in such a way that its function is, to some extent, independent of the choice of cryptographic algorithm used, therefore allowing you to switch algorithm. You might even have a set of recommended cipher suites that can be negotiated in each protocol exchange – this is how TLS works for example. There are now whole RFCs dedicated to the topic.

Crypto agility extends this idea from network protocols to all of the cryptography in use in an organisation. This means that an organisation can only become crypto-agile when the security team knows all of the algorithms, keylengths, crypto libraries and protocols in use in their applications and infrastructure, and has a plan that would allow them to change if necessary.

Continue reading →

January 8, 2019

Ensuring code coverage in IAST

Interactive Application Security Testing (or as we recently argued it should be known, Instrumented Application Security Testing) works by adding hooks into a running application and analyzing its behaviour to look for security flaws. It has many advantages and it’s the technique we use to test crypto security in our Analyzer tool. 

Modern versions of IAST (like ours) can detect flaws even when the application is executing standard functional tests – there is no need to simulate attacks. This enables these tools to be deployed early in the development lifecycle and integrated into CI toolchains. However, there’s one key feature that doesn’t figure on most IAST checklists: coverage checking.

Suppose I get a nice green report from my IAST tool saying there are no vulnerabilities in my app – how do I know that all the parts of my code where there might be issues were actually exercised during testing?

Continue reading →
December 17, 2018

Why IAST should mean Instrumented Application Security Testing

Interactive Application Security testing (IAST) first emerged as a concept in the early 2010s as application security companies looked to improve on static (SAST) and dynamic (DAST) testing by either combining results together, or looking for some kind of best-of-both-worlds approach.

Since that time, IAST has grown to about 20% of the AST market and is predicted to gain a larger share of this rapidly growing market in the coming years. However, in my opinion, the way IAST is understood and deployed today means that the acronym needs a tweak.

Continue reading →