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 →
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?
A large part of the .NET APIs are common to both .NET Core and .NET Framework. Microsoft even released the .NET Standard, a subset of .NET APIs provided by all .NET implementations, to simplify things for cross-implementation developers. However, there are still significant differences between Core and Framework, and cryptography is one of them.
Continue reading →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).
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.
The announcement yesterday of this talk about HSM hacking on the BlackHat 2019 program has caused a stir, and for good reason: the authors claim to have discovered remote unauthenticated attacks giving full control of an HSM and complete access to keys and secrets stored on it.
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 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.
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.
State of the cloud at #reInvent pic.twitter.com/QBiIMkiC06
— 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.
OCI recently launched a cloud crypto service, so how does it measure up to the others in our cloud crypto comparison?
