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.
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?
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?
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.
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.
— Arun Gupta (@arungupta) November 28, 2018
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.
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.
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 →
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 →
Amazon Simple Storage Service (S3) is one of the most widely-used cloud services. Most users of the service know it’s wise to encrypt sensitive data before storing it in S3. In this post we’ll look at how to do that securely using the AWS Java SDK, and how Cryptosense Analyzer will help you spot if you’ve done it wrong.
Note that in this post we’re talking about client-side encryption where the sensitive data must be encrypted locally before it’s sent to AWS S3 servers. There are also options for server-side encryption managed via the S3 console. These only treat the data while at rest, it will still be in clear inside AWS servers (at least briefly) each time it’s accessed.
There are several different client-side encryption modes for S3 offered by the Java S3 SDK. First you need to decide whether you want to manage your master keys yourself, or have AWS manage your master keys in their key management service (KMS).