If you recognize the terms CBC and CTR from the blog post title already, GREAT job! It means you have been really studying Domain 3: Security Engineering of the CISSP CBK, specifically the part about encryption, and even more specifically about the different block cipher modes of DES. I remember those late nights of painstakingly trying to memorize the DES block modes of cipher block chaining, electronic code book, cipher feedback, output feedback, and counter mode. I thought "Okay, just memorize these for the exam and I can move on from this cryptography chapter." If it helps, below is what I used to briefly memorize some simple associations with each:
Electronic Code Book (ECB): Used for small amounts of data such as ATM PIN numbers, but not large data. Encrypting a large amount of data with ECB will reveal a pattern.
Cipher Block Chaining (CBC): Each block is encrypted using the previous block, and the first block will use an initialization vector (IV) as there is no previous block.
Cipher Feedback (CFB): Most similar to a stream cipher.
Output Feedback (OFB): Also uses a stream process for large data and has a lesser chance of errors and corruption that may occur in CBC.
Counter (CTR): Uses a random IV to generate the keystream.
None of the above helped for the exam, it only gave me some false sense of confidence - just as it was about to happen in real life. Memorizing CISSP subject matter was a mistake. I did pass the exam on the first try, but the CISSP is a humbling experience. Whether you pass or fail the CISSP exam, both types of results leave the test taker walking away with a feeling of "I should have studied more". Either way, after I passed, I never thought about DES modes ever again except for making content for my Members Portal.
But now years later I was in a real security job with real companies with real information security professionals - not in the basement of my house with a CISSP book with tattered and highlighted pages. Instead of reading through the pages of Sybex in order to prepare for an exam, now I had to read CVEs and vendor technical administration guides in order to prepare for conference calls where hundreds of thousands of dollars were involved. Still, I'd rather do this than take the CISSP exam again, that's how frustrating the exam is!
The clients and customers I engaged with range from novice security professionals to those with expert-level knowledge. With either types, it is best to follow the CISSP Code of Ethics and stay professional, honest, courteous, and to do the job with full diligence. Some clients just want an explanation on how to differentiate between an encryption algorithm and a hashing algorithm, while some want to know the purpose of using Diffie-Hellman in Phase 2 of a VPN (Perfect Forward Secrecy), while others want encryption ciphers changed immediately due to some external penetration testing report. They all look to the security professional to be knowledgeable in the subject matter.
But sometimes, as I learned, with clients who have expert-level security knowledge, it is important to stay humble and accept when you're talking to someone who knows more than you, with or without a CISSP. As in, don't try to fake it. During a particular conference call, the client took me completely by surprise in midst of talking about firewall upgrade maintenance windows.
She asked "Did you read the report I emailed you about what our pen testing team discovered? How are you and your team going to handle CVE 5161?".
Well first of all, I thought, I don't have every single CVE number committed to my memory, there are thousands of those. But this client didn't care, as far as she was concerned, we had to know everything about the security of their firewall and loadbalancer. Fair enough, fair enough. After all, when I call up my credit card company, I don't care how many other customers they have, they better be knowledgeable and ready to know everything about my account.
The client was talking about disabling CBC cipher modes in the SSH config per this F5 and NIST article articles:
I did read her email, but hadn't responded since that morning as I needed to do more research on it. The client wanted the remediation of 3 vulnerabilities to the firewall's SSH cipher suites. They wanted all SSH encryption protocols to start using CTR instead of CBC during an SSH session between a client and server.
This is done by logging into the command line of the Checkpoint firewall and changing the ciphers in this directory: /etc/ssh/ssh_config. These were the current ciphers being used:
"Ciphers aes128-cbc,aes192-cbc,aes256-cbc"
According to the vendor support document, all we had to do was go into the Linux VI editor and change where it says "cbc" to "ctr". This would change the SSH encryption algorithms from using cipher block chaining to counter mode. But why change CBC? Because there is a vulnerability with how CBC worked in SSH that allowed "remote attackers to recover certain plaintext data from an arbitrary block of ciphertext in an SSH session via unknown vectors."
Now, I thought CBC was good enough, and definitely stronger over Counter mode because CBC is mostly what I've seen when using symmetric encryption. All I really knew about CTR mode was that it had better performance. I had to actually go back to my CISSP Shon Harris book and look up the different DES modes again. I always stress to the website members not to memorize CISSP topics, but to truly understand, to really know them. Well I didn't take my own advice and was caught in just memorizing the different DES modes instead of trying to understand their true function. Never did I think that after studying all those hours in my CISSP books about cipher block chaining, electronic code book, counter and other DES block cipher modes that I'd have to actually know it for real life client engagements.
And even if I did, I always thought it'd be for some top secret NSA or CIA job involving the most technological and advanced of quantum computing technologies, not as a firewall engineer in a regular corporate gig where I worked from home and had a half-eaten turkey sandwich my wife made me for lunch next to my keyboard.
Coming back to the conference call, I unmuted my Zoom mic "Yes I saw the email. I'll definitely take a closer look at the configs on both devices." I should have muted the line and shut my big fat mouth at this point.
But no, my insecurities wanted me to look smart and competent. I had to add "We should be okay though, all SSH access directly to the firewall and load balancer are restricted just to the engineering team members. Everything else is dropped by the firewall's Stealth Rule."
No response from anyone on the call. One terrible decision after another, I continued, "Plus the article looks to be addressing cipher block chaining, which should be fine since it is random enough and depends on the previous blocks for encryption, given that there is an initialization vector on the first block". I just repeated what I read in the books and did not think in any way that these management level individuals on the call would ask any follow-up questions. This was highly technical stuff, even for my job capacity! But I was wrong.
The client took me completely by surprise. She said matter-of-factly, "I'm not sure how that relates to what we're asking. It's not about how they work by themselves, it's about how they work with SSH. The CBC ciphers have been shown to be vulnerable to an exploit that can retrieve plaintext data in an SSH session. These weak key exchange algorithms have to be removed from the SSH configuration files on the host devices. We need to switch to CTR."
She was right. What I learned in my CISSP books had nothing to do with what we were talking about right now. Knowing the functions of CBC and CTR block ciphers in my Sybex or Shon Harris books did not provide any insight into their vulnerabilities, this was more in the way how the SSH protocol was vulnerable when using those ciphers.
The attack could recover 32 bits of plaintext from a block of ciphertext which was being secured using the SSH protocol. This was allowed if using CBC, in which a block was depdenent on the previous block.
But since CTR used a keystream by encrypting progressive values and using a "counter" function, it would resist this type of attack. So because CTR operated in the way it did versus CBC, my CISSP knowledge in these cipher modes was greatly increased through this real-life experience. Now I would be able to talk about not only their textbook operations, but also how those same operations can be used to compromise or defend an asset.
But I pushed back to the customer "Right, but again, only our engineers have direct SSH access to these devices. Their access is by least privilege using multi-factor authentication and only accessible after connecting to the corporate VPN."
The client's next question "How do I know one of your engineers aren't going to try and take advantage of this vulnerability? Or what if their account has been compromised and their privileges escalated?"
I nervously chuckled a little at the thought, as did a few others on the phone, but it was no laughing matter. We all understood at this point the client was serious, and the only way forward was to just give her what she wants.
"Understood, okay. That's a good point (She didn't need to know that was a good point). We can do that. Let me take a closer look at the information on that email. Once we see the remediation steps and create a change request for it, we'll see about getting it implemented during a weekend maintenance.
I thought about it, and realized that this situation was like picking either the technical answer or the high-level "think like a manager" answer. Thinking like a manager at my job (even though I am not a manager, but have trained myself to think like one since passing the CISSP) had become second nature to me after the CISSP - I knew that not every vulnerability needed to be addressed, it was all about risk prioritization. The client wanted to take the technical solution of immediately choosing to upgrade the firewall or make changes to its configuration in order to avoid a risk. Not a highly important risk, not even a medium score risk, it was a low risk - but a risk nonetheless. I was trying to help my own manager out by reducing our efforts over customer requests which seemed like overkill.
My reasoning was that the SSH CBC ciphers being exploited were a low risk. Direct SSH access to the firewall was limited to a few individuals and it would take an attacker multiples layers of defenses (defense-in-depth) to overcome before reaching an attack vector. Even then, we would receive alerts if someone other than the authorized administrator logged onto a firewall or loadbalancer. So it seemed like a long-shot that the CBC ciphers would be vulnerable in our environment to this CVE.
All this went out the window when the client mentioned the possibility of an insider threat. You don't really think of your fellow co-workers as malicious, but as a security professional we can't afford to think that way. Today's security professional can be tomorrow's disgruntled employee.
For this instance, thinking like a manager was actually choosing the technical answer, to remediate the vulnerabilities as soon as possible. This way the customer is happy, and happy customers mean they stick with our service, which means the company is still generating revenue. After human life, money is awfully close to being the next most important asset.
We did what the customer asked us to do. During a maintenance window, we went into the SSH configuration directory of both the primary and secondary firewall and changed this configuration:
Ciphers aes128-cbc,aes192-cbc,aes256-cbc
To this configuration:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
It's really a simple change. Our initial hesitation to make this change was that I didn't really know what else it may impact in terms of the SSH daemon. And because the criticality of the threat was low, we didn't want to make a simple change which might adversely affect other interdependencies which may be a more critical business process.
I was trying to think like a manager to avoid the technical solution, but in actuality the technical solution was thinking like a manager.
Thanks for reading.
Click here to read more Stories of a CISSP.
CISSP Take-Away Concepts
Domain 1: Security and Risk Management
CISSP Code of Ethics
The Third Canon states "Provide diligent and competent service to principles".
I was not completely incompetent nor was I unable to provide the underlying change request, but I did not know 100% of the requested parameters. I didn't know that there was a vulnerability against CBC, I assumed CBC was fine to use over CTR.
If I didn't know how to implement the SSH configuration firewall change, then as a CISSP I would not have performed the service.
Domain 3: Security Engineering
DES Block Cipher Modes
It took to really understand CBC and CTR block cipher modes. But not only to understand them, but also to know if they had any existing vulnerabilities in their specific usages (in this case: SSH).
Domain 4: Communications and Network Security
Making changes to a firewall and loadbalancer in order to mitigate SSH cipher vulnerabilities
A stateful firewall and a loadbalancer are Layer 3 technologies as they deal with IP addresses
Corporate VPN
A layer of security that encrypts the connection between a client and server in addition to the already encrypted SSH connection
Stealth Rule
A security policy located at the top of the rulebase which drops connections directly to the firewall either via SSH or HTTPS
Domain 5: Identify and Access Management
Multi-factor authentication
Engineers first use multi-factor authentication to logon to their computer and also any other system device. A combination of something you know and something you have. Something you are would be too expensive as it would be a biometric type device.
Domain 7: Security Operations
Insider threat
I forgot about the insider threat, the very engineers who are protecting the systems and have full access to them, may also be the ones to one day compromise it.