Here's a roundup of best practice tips for getting started with your cryptography inventory project.
The information below is a summary based on our experience of cryptography inventory projects with some of our clients. If you'd like more detail, we have an on-demand webinar series and a whitepaper on this subject.
Cryptography Inventory Tips
Why am I building an Inventory?
This may seem obvious, but in large organizations where the inventory is required by multiple teams for different reasons, conflicts can easily arise. Ease of data collection and usability of the end result are critical factors in the success of the inventory project. Consider the type of queries that different teams will ask of the inventory across the next 3-5 years. Can we predict any changes in the type of information that we will want to record over that time? For example, the driving factor behind your cryptography inventory project today is to become more crypto-agile, yet once it has been built, what happens if the compliance team now want to use it? In our experience there are four main reasons to build an inventory of cryptography:
- Reducing crypto risk - where am I using insecure cryptography, or using strong cryptography in an insecure way?
- Secure use of cloud cryptography - which applications can I easily migrate? Where do I need to make changes to protect sensitive data?
- Becoming more "crypto-agile" - where am I using algorithms that will become obsolete in once large quantum computers are available?
- Simplifying compliance - how can I demonstrate compliance with standards requiring the use of specific cryptographic algorithms and keylengths?
A good inventory should be able to be useful in all of these cases.
What should be Covered?
Whilst everyone is aware of the potential benefits that a very thorough cryptography inventory provides, it can be difficult to know where to start and end your coverage. We also don't want to find ourselves in a situation where we have chosen a very high level of coverage, that proves impossible to keep up to date. We find it helpful to split coverage into these five areas. For each area you'll need to ask yourself some questions about the minimum level of coverage that will achieve the inventory's goals (there's more detail on this in part 2 of our webinar series). Inventory sub-sections:
For example, looking at algorithm coverage, do we include:just the algorithm type e.g. AES?...or the algorithm and keylength e.g. AES-128?...or the algorithm and block mode e.g. AES-128-GCM?...or the algorithm, block mode and padding e.g. AES-128-GCM-PKCS5?The coverage level you choose will depend on your sector, the data being handled by the applications in your inventory, and of course compliance requirements. It will also depend on the level to which the information gathering process required to build your inventory can be automated - more on this below.
Unfortunately no cryptography inventory can be 100% accurate all the time as modern IT infrastructure is constantly evolving. However, integrating application cryptography testing tools into CI/CD can help you ensure that you keep up with any changes to code for in-house applications. Third party applications will require testing at periodic intervals. Asking a vendor to provide an inventory of cryptography use inside their application is helpful, but you will certainly require a secondary control to be certain that their information is accurate.
Automating Data Collection
Probably the most important consideration in building a cryptography inventory is how much of it you can automate. If it's easy for you to gather information for the inventory, there's a much higher chance that it will stay up-to-date and be most useful to those who need it. If your inventory requires a lot of manual code review to be conducted each year, then it is likely that it will only be accurate for a short part of the year, AND will be very costly to maintain. Luckily, there are a few tools on the market that can help automate application cryptography testing (including our very own Cryptosense Analyzer).
Data Models & Usability
So far, there isn't any standard format for a cryptography inventory data model. A simple spreadsheet rapidly reaches its limits. Most people agree that a small set of relational database tables with joins to allow queries is a good place to start. Make sure that the application cryptography testing tools you're using to keep your inventory up to date can output data into a useful formats that can easily integrate into your CI/CD workflows and existing data structures. Cryptosense Analyzer outputs cryptography inventory data in JSON format through its REST and GraphQL APIs. We've found that to work well for all of our customers. As mentioned above, usability is the most important consideration when defining a data model. To validate your model, think about some queries you would like to be able to run on the inventory:
- Do I have any non-compliances to my cryptography policy? If so, where?
- Am I using any compromised or expired certificates?
- Is SHA-1 still being used anywhere?
Hopefully you found this summary useful. For more detailed discussion about building and maintaining an inventory of cryptography, take a look at our whitepaper on the subject.