The fifth domain in the SSCP CBK is Cryptography. This domain accounts for 9% of the SSCP exam.
The Cryptography domain defines four (4) tasks that a certified SSCP should be able to perform:
- Understand and Apply Fundamental Concepts of Cryptography
- Understand Requirements for Cryptography
- Understand and Support Secure Protocols
- Operate and Implement Cryptographic Systems
This is part 5 in a 7-part series on the (ISC)2 SSCP Common Body of Knowledge (CBK).
Remember: An SSCP who can recall this information will likely pass the exam, but the SSCP who can explain how these concepts are applied in real-world situations is more likely to get hired.
Understand and Apply Fundamental Concepts of Cryptography
When you begin studying cryptography, you’re likely to hear stories about Alice and Bob. If you’ve got 3 minutes, you might find this video helpful.
You’ll find multiple examples online where Alice and Bob are used to explain cryptography. Here, we’ll give you some foundational knowledge that will help cement your understanding of those examples.
Put simply, cryptography is the process of jumbling data so that it’s unreadable to anyone who doesn’t have the right key. Anyone with the right key would be able to turn the jumbled data back to its original (human-readable) form. Jumbling data is known as encryption. Returning it to its original form is known as decryption.
There are two basic encryption methods that SSCP’s need to understand:
- Symmetric Encryption – The key used to encrypt the data is the same key used to decrypt the data.
- Asymmetric Encryption – The encryption key (i.e., public key) is different from the decryption key (i.e., private key).
Symmetric encryption is considered less secure than asymmetric encryption.
Hashing is similar to encryption, with one key difference. If encryption/decryption is like working on a puzzle (taking it apart and putting it back together), then hashing is like dropping a glass on the sidewalk. Just because you know what the glass looked like before it shattered doesn’t mean you can put it back together.
Hashing is often used to prove that a file wasn’t tampered with. If you generate a hash before sending a file to someone, they can run the same hashing function on the file they received, compare it to the hash value that you came up with, and validate that it is indeed the same file. We call that value a digital signature.
Salting is the process of adding a random number (variable) to the hashing function. That extra variable makes it even harder (even impossible) for an attacker to figure out the original value.
Even with all these controls, you might still bump into someone who lies and says that you didn’t send them a particular file. Non-repudiation refers to those controls that ensure that the lie won’t hold up. If you digitally sign a document using trusted cryptographic controls, the evidence of that transaction should be able to stand up in a court of law. (You’ll still need to take your forensics controls into account. Check out Domain 4 – Incident Response and Recovery for more details.)
Understand Requirements for Cryptography
Cryptography sounds great, right? While it does provide tremendous security value, it comes at a cost.
Cryptographic controls can be complex to implement and maintain. You may also need a little more computing power to perform all those encryption and decryption routines. And what would happen if you lost your decryption key? Better hope you have usable backups!
If you’re going to use cryptography, you should make sure the extra costs are worth it.
Data sensitivity is often a key deciding factor for when to use cryptography. Organizations tend to classify data, based on how bad it would be if that data ends up in the wrong hands.
If data is publicly available (e.g., the marketing information on your company website), do you need to encryption? Probably not. It’s already available to EVERYBODY. But what about credit card numbers, social security numbers, and healthcare data? How bad would it be if that data ended up in the wrong hands? Check out Breach Level Index if you’d like to find out.
Over the years, we’ve seen more and more regulatory requirements requiring data encryption. Regulatory requirements are those rules that organizations have to follow because they’re part of a particular industry. Healthcare data? Check the healthcare industry requirements. Retailers processing credit cards? Check the payment card industry requirements.
Once the requirements for cryptography have been identified, make sure you’re providing relevant end-user training for your users on a regular basis. Cryptography controls are useless if no one understands how (and why) they should use them.
Understand and Support Secure Protocols
Another important aspect of cryptography is understanding the differences in implementation and appropriate use.
Telling your developers to encrypt the data is easier said than done.
Encrypting data at rest, or data stored on a disk, can be done in multiple ways:
- You can encrypt data files.
- You can encrypt data fields or columns inside of a database.
- You can encrypt folders (or containers) on the hard drive.
- You can even encrypt the entire hard drive itself.
That doesn’t even begin to cover encrypting data in motion, or data traveling across a network. If you want to see just how many options are available when it comes to configuring encryption on a web server, head on over to Qualys SSL Labs and see what the configuration looks like for this website.
To top it all off, the current list of cryptographic algorithms available to developers and administrators is mind-boggling!
All of this complexity underscores the importance of SSCP’s understanding when encryption is appropriate in the first place. When it is, take time to research the regulatory requirements, technical details, and your backup options before turning on any cryptographic controls.
Operate and Implement Cryptographic Systems
Once you’ve implemented a cryptographic system, you need to keep it up and running. That means that you’ll need to understand some fundamental key management concepts.
- Key rotation – Just like passwords, you should plan on changing encryption keys on a regular basis. And what happens to the data you encrypted with the old key? Do you need to decrypt with the old key and encrypt it with the new key? Or will you keep a copy of the old key handy in case you need to decrypt any old data? It depends on a number of factors that will vary from one system to the next.
- Key composition – Again, just like passwords, encryption keys should be strong. You may have an encryption key that’s 2048 characters long, but if every character is the digit “1” repeated over and over and over… then you’re going to have a bad day.
- Cryptographic attacks – Encryption is not a bulletproof. Sometimes there are weaknesses in the protocol itself. Just read up on Heartbleed, a weakness in SSL that allowed attackers to trick servers into providing access to unencrypted data. Heartbleed is one of dozens of cryptographic attacks.
When users want to use encryption over an insecure network (e.g., the public Internet), they need some way to exchange encryption information. That’s where a Public Key Infrastructure (PKI) comes into play. The components of a PKI include:
- Certificate Authority (CA) – The entity that issues, signs, and stores digital certificates.
- Registration Authority (RA) – The entity that makes sure that the entities requesting digital certificates really are who they say they are.
- Central Directory – Where everything is stored.
- Certificate Management System – Handles access to and delivery of the digital certificates.
- Certificate Policy – The rules for each certificate (e.g., how long is the certificate good for?).
With all of these components in place, you can begin issuing and managing keys. A few administration and validation tasks you should be prepared to perform include:
- Key creation – Generating the actual key.
- Key exchange – This is when multiple parties share/swap keys so they can begin sending and receiving encrypted messages.
- Key revocation – Eventually, an encryption key will be compromised. When that happens, you need to invalidate it so that it can’t be abused.
- Key escrow – This is when a third party holds the decryption keys for two parties, providing another layer of independence and trust.
As with so many areas of cybersecurity, cryptography seeks to establish trust among all parties involved. The concept of a Web of Trust, originally coined by the created of Pretty Good Privacy (PGP), suggests that a decentralized model works best, one where multiple parties serve as the source of truth. If you create a public key, and then share that key with multiple people, your friends should be able to ask any one of those people for a copy of that key. If one of the copies differs from the rest, then you should question whether or not you can trust the source holding that invalid key.
That idea of a decentralized trust model is at the heart of many cryptocurrencies.
Ultimately, an SSCP needs to have a basic understanding of secure protocols that rely on cryptography. What’s more, an SSCP should understand popular implementations of secure protocols.
- IPSec – Short for Internet Protocol Security. Often used to establish virtual private networks (VPN’s).
- SSL/TLS – Secure Sockets Layer, and its successor, Transport Layer Secure. Used to encrypt web traffic. They put the S in HTTPS.
- S/MIME – Secure/Multipurpose Internet Mail Extensions. Used to encrypt email messages.
If there’s a network protocol that enables you to send data from point A to point B, chances are there’s an encrypted alternative. Instead of Telnet, use SSH. Instead of FTP, use SFTP or FTP/S.
If you can’t use the encrypted alternative, you should assume that an attacker will ultimately intercept unencrypted data in transit. With that in mind, you should spend some time exploring compensating controls to help you reduce the risk of compromise.
What Else Should I Know About Cryptography?
This is a high level introduction to the concepts you need to know as an SSCP, based on the (ISC)2 SSCP Certification Exam Outline. It’s not intended to be a deep-dive into everything you need to know in order to pass the exam.
You’ll increase your chances of passing the exam the first time if you read these two (2) books next:
- Start with the SSCP All-in-One Exam Guide (2nd Edition).
- Then read the (ISC)2 SSCP Official Study Guide.
If you prefer videos to books, use our list of recommended online training providers to take advantage of FREE offers to help you prepare for the exam.
Keep at it!
SSCP Domain 4 – Incident Response and Recovery | SSCP Domain 6 – Network and Communications Security
