Ask anyone on the outside of information security what the most important part of the industry is, and you’ll get a lot of different answers, but among them will be cryptography. Using strong encryption to hide information where it can’t be accessed without the proper authorization makes a lot of sense, and the idea of strong cryptography has saturated popular culture.

In reality, of course, security frameworks like ISO 27001 include cryptography, but it’s just one small part of overall information security. A very small part, in fact; it’s just one subsection of one section of the Annex A controls.

It makes sense, right? Cryptographic is, broadly speaking, something you either have or you don’t. You aren’t developing a unique encryption algorithm from base principles, nor are you training every employee how to encrypt and decrypt communications. Most people don’t even know whether the data they’re working with or the communications methods they’re using are encrypted or not.

That’s why so much of ISO 27001 focuses on things like organizational policies, individual training, physical access, and other more variable and flexible mechanisms of security. It’s also why so many threats focus on those vectors. It’s a lot easier to bypass a front desk with a vest and a clipboard than it is to break AES-256.

Nevertheless, ISO 27001 does have specific controls relating to encryption and the use of cryptography that you will need to follow if you want to achieve compliance with the ISO standard.

Is Cryptography Required for ISO 27001?

Yes.

However, ISO 27001 does not specify what encryption you need to have in place. This is a reflection of how ISO 27001 was developed.

ISO 27001 exists as a standard and a set of goals to achieve, rather than a prescriptive list of specifics you need to implement. In fact, the use of the cryptography aspect is a great example.

For a framework like CMMC, you are also required to use cryptography, but they tell you which kinds to use. Specifically, CMMC makes you use “FIPS-Validated Cryptography“, which is a whole escalating set of standards that covers a handful of specific kinds of cryptographic algorithms.

ISO 27001 simply says that you need to use encryption that is suitable according to your needs.

It’s up to you to determine what those needs are and what level of encryption that requires.

In practice, the lists are going to be similar, both because of the high standards in place from regulatory agencies, governments, and legal or statutory requirements. However, the difference in approach allows for more flexibility in the face of developments in the industry.

If a new cryptographic algorithm is released, people complying with something like CMMC have to wait until FIPS can validate the algorithm. People on ISO 27001 can adopt it immediately if it meets their needs.

ISO/IEC does not leave you hanging, though; ISO 27002, the supplemental publication for ISO 27001, offers more specific guidance.

What Does ISO 27001 Say?

ISO 27001 itself does not specifically mention cryptography; that’s left to the Annex A controls list.

Annex A part 8.24 says this:

“Ensure proper and effective use of cryptography to protect the confidentiality, authenticity or integrity of information according to business and information security requirements, and taking into consideration legal, statutory, regulatory and contractual requirements related to cryptography.”

Basically, it tells you to think about when and where cryptography should be used, what regulations and laws enforce certain cryptographic standards, and what mechanisms of cryptography best suit your needs. Using the Absolute Best Possible Cryptographic Algorithm might not be necessary or even appropriate.

What Does ISO 27002 Say?

ISO 27002 is the supplemental document that outlines more specific information and requirements for appropriate ISO 27001 implementation. So, what does it say, specifically? There’s a lot more data here, and you’d be best off buying the document to check yourself, but in summary:

“Control: Rules for the effective use of cryptography, including cryptographic key management, should be defined and implemented.”

It also offers guidance across several sections.

• Consider the topic-specific policy defined by your organization, including general principles for protecting information. Topic-specific policy on the use of cryptography is necessary.
• Consider the type of information and protection necessary to establish the type, strength, and quality of cryptographic algorithms to use.
• Consider the use of cryptography to protect information held on mobile endpoint devices or storage media, and when transmitted to those devices.
• Consider the approach to key management, from generation and protection of keys to the recovery of encrypted information if keys are lost, compromised or damaged.
• Consider the roles and responsibilities involved in implementing these rules and for key management.
• Consider specifics in algorithms and ciphers that may be approved or required for your organization.
• Consider the impact of cryptography on other security mechanisms that require inspecting data, such as malware scanning and content filtering.
• Consider the laws and regulations in your industry and your nation, as well as whether data is transferred across borders.
• Consider the contents of SLAs and other contracts that may increase requirements.

There’s also a whole additional set of information and guidance specifically surrounding key management, with lists of considerations such as generating, issuing, distributing, storing, changing, recovering, revoking, destroying, and logging keys.

The overall section 8.24 on cryptography in ISO 27002 is roughly three pages long, so we’re obviously not reproducing the whole thing here. For the actual text, obtain the full document.

How to Properly Implement Cryptography to Satisfy ISO 27001

There’s no one-size-fits-all solution to cryptography, according to ISO 27001. Instead, the framework challenges you to think about the requirements heaped upon you from various sources, as well as the policies and procedures that you need to maintain appropriate standards.

This is nothing new; all of ISO 27001 is like this, so you should be familiar with thinking about security in this way.

To begin, start by analyzing external requirements.

• Legal requirements. Laws regarding the cryptography you can and can’t use can come from local, state, or national governments, and they can apply to you along various axes, such as because of your location within a country, your ability to do business within a country, your position within a given industry, and similar directions. In general, it’s a good idea to get a legal professional to offer advice, and to keep evidence of that advice in case you’re challenged later.
• Information classification. Part of your overall ISMS development is determining the kinds of information you handle and how they need to be secured. It’s similar in essence to determining impact levels and scoping considerations for other frameworks. ISO 27001 Annex A section 5.12 deals with information classification and is a good place to start.
• Company policy. Part of the ISMS you develop with ISO 27001 is the array of company rules and policies you develop, which serve as your guidelines for more technical implementations. If you haven’t yet developed policies surrounding cryptography, you should do so; if you have, refer to them, make sure they’re valid for the current time, and update them if necessary.

You will also need to consider when and where cryptography will need to be applied.

First is data at rest. Data where it is stored, such as within a company shared network drive, on company servers or individual computers, or in cloud buckets, all need to be properly secured at rest. Many third-party services have encryption at rest already, but for any of your own on-premises solutions, cryptography will need to be applied appropriately.

One of the biggest challenges here is that you may need to effectively retrofit existing systems with modern cryptography. This can cause difficulties with integrations, both of those systems and with other applications that need to access them. Encryption (or more specifically, the acts of encrypting and decrypting information) also consumes resources and can slow down the performance of these systems.

Second is data in transit. When data is moved from point A to point B, whether it’s an employee accessing a drive, sending files back and forth, or otherwise transmitting and working on data, it needs to be encrypted.

A common attack vector is malicious software that stands between point A and point B, simply snooping on and copying data. These “man in the middle” attacks can be stymied by encrypting data in transit, so anything snooped on is unintelligible.

Third is key management. Key management is the requirement that your cryptographic keys are strong and random enough to secure your data, but not so resource-intensive that they’re a significant strain on your resources to implement. Modern cryptographic applications off the shelf are usually balanced to make this all easy, since if a system is too hard to use, people will find a way to bypass it, and that means it’s not secure.

Key storage is also part of this. Keys need to be stored to be of any value, but storing them is itself something that needs to be secured. There are technical solutions to this as well, such as hardware security modules, encrypted key storage, and other means of secure storage. This also ties back into access control, so your keys are restricted from unauthorized access.

Another element of key management is key rotation. Keys generally need to be changed from time to time to prevent compromise and unauthorized use, but you also want to make sure that rotation is minimally disruptive to your organization.

Picking the Right Cryptographic Algorithm

You might notice that, thus far, we haven’t mentioned specific cryptographic products or algorithms to use. That’s because part of the proper implementation of the cryptographic requirements of ISO 27001 is making that determination.

ISO/IEC avoid specifying the exact algorithms you should use, as a means of future-proofing their standard. Cryptography is one of the world’s foremost arms races, with incomprehensible amounts of computing power leveraged both to compromise existing cryptography and to develop new cryptography. Developments in everything from quantum computing to AI research have been weaponized on both sides of this fight, and will continue to do so indefinitely.

What this means is that different types of encryption algorithms (RSA, AES, etc.) and different levels of strength for those algorithms can change over time.

All of this is also guided by other elements of ISO 27001, such as 8.3 Information Security Risk Treatment and 9.1 Monitoring, Measurement, Analysis, and Evaluation.

Basically, pick the best algorithm currently available that satisfies the requirements you’ve determined according to laws and the type of information you’re protecting, and make sure it’s not going to put too much strain on your systems to use it. If you can’t use the bare minimum, you may need to upgrade your systems before you can be properly secured.

Don’t forget to also consider future-proofing; if you’re sitting at the bare minimum and need to update every year, you open yourself up to significantly more risk than pushing for greater levels of security now.

Maintaining Compliance with Evidence

As with any security framework or standard like ISO 27001, a big part of your job after implementation is maintenance. Not only do you need proof of the implementation, you need to perform ongoing maintenance and upgrades, and maintain proof of that maintenance. From there, you also need to perform tests and audits, validate training, maintain policies, and keep the whole ISMS in a state of continual improvement.

The Ignyte Assurance Platform can help with this. We’ve designed the platform as a way to track and maintain your compliance state along many different security frameworks, customizable to your needs. As you develop your ISMS, you will gather artifacts of evidence and proof of implementation, as well as audit logs and records, incident reports, and more. All of this can be tracked in our platform.

To see what the Ignyte Platform can do for you, schedule a call to see it in action. We’ll be more than happy to answer any questions you may have along the way.

*** This is a Security Bloggers Network syndicated blog from Ignyte authored by Dan Page. Read the original post at: https://www.ignyteplatform.com/blog/iso-27001/iso-27001s-cryptographic-controls/