Azure Storage is one of the most widely used services in the Microsoft Azure cloud, and is the Azure equivalent of the AWS S3 service. Most users of the service know that it is wise to encrypt sensitive data before storing it in the cloud. In this post, we will look at how that can be done using the Azure Java SDK, and will use the Cryptosense Analyzer Platform to gain insight into how the Azure SDK encrypts your data.
On 29th July 2019 CapitalOne Financial Corp announced a data breach affecting 140 000 of their customer’s social security numbers and 80 000 bank account numbers. CapitalOne is a major user of AWS cloud, and in this case the stolen data was stored in AWS S3 buckets. Since the perpetrator was arrested and left quite a long trail on social media, much more detail about this breach has become public than usual, allowing in-depth analysis of what went wrong.
Continue reading →
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 →
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?
