CISSP Cyber Training Podcast - CISSP Training Program

CCT 319: Ransomware’s New Playbook - CISSP Practice Exam Questions (Domain 4)

• Shon Gerber, vCISO, CISSP, Cybersecurity Consultant and Entrepreneur • Season 3 • Episode 319

Share episode

Send us a text

Ransomware isn’t always after your data anymore—sometimes the goal is to burn your operations down. We open with a hard look at the Stoli bankruptcy and what it teaches about ERP paralysis, regulatory deadlines, and why “we’ll restore soon” is not a resilience plan. From there, we shift into a high-impact CISSP Domain 4 walkthrough that connects real-world failures to the protocols and controls that actually reduce risk.

We break down HTTPS beyond the lock icon—what it secures, what metadata remains exposed, and how certificate trust can be subverted. You’ll get a clear mental model for DNS defenses: why DNSSEC protects integrity but not confidentiality, and how DoH and DoT encrypt queries while complicating DNS filtering. We compare SFTP over SSH with FTPS, clarify LDAP StartTLS on port 389 vs LDAPS on 636, and explain the practical differences between IPsec transport and tunnel modes, including when ESP’s symmetric encryption is the right fit.

We also zoom in on TLS hygiene: why enabling TLS 1.0 or 1.1 invites downgrade and deprecated cipher risks, what HSTS really does (and doesn’t do), and why Perfect Forward Secrecy matters when adversaries stockpile encrypted traffic. And we call out a critical truth for both practitioners and exam-takers: HTTPS can’t stop phishing, so user trust and certificate validation remain frontline defenses.

If you’re preparing for the CISSP or leading security strategy, this episode gives you crisp explanations, memorable heuristics, and business-first context to improve your decisions. Subscribe, share with a teammate who handles compliance filings, and leave a review with the toughest crypto or network security question you want us to unpack next.

Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox! Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

Join now and start your journey toward CISSP mastery today!

SPEAKER_00:

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Chung Gerbert. I'm your host for this Action Pack Informative Podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. Alright.

SPEAKER_01:

Hey, I'll Chunk Gerbert with CISSP Cyber Training, and hope you all are having a beautifully blessed day today. Today is an amazing day. Yes, today is CISSP question Thursday. So we are going to be getting into some questions as it relates to domain 4.1.2. And we're going to be going into those questions as it related to the podcast that occurred on Monday. So as we talk about before, the we have the podcast on Monday followed by questions over the topics that were occurred on Monday. So that's what we're going to get into. But before we do, yes, before we do, we have a news article that we want to kind of quickly go over. And I want to bring this up just because of the fact that we've I saw an article, and I think it was in Drudge, they had mentioned that the ransomware attackers are no longer necessarily going after your data, they're more or less going after to burn it down. And we've we've been seeing to the point of there's a lot of criminals that are going after corporations that just want to burn it to the ground rather than actually steal the money or get data out of it. If they can get ransomware, but the the money out of those things, they will, but in reality, the ultimate goal is just to kind of cover their tracks and burn everything down. Well, I say all that because there was a vodka. This is in InfoSec uh security magazine or infosecurity magazine. There is a vodka giant, air quotes. I I don't know what that actually means, but I assume that if they're having the kind of money we're talking about, they're relatively large in size. But the giant Stoley files for bankruptcy after a ransomware attack. Now, there is a little bit of story behind all this. Stole is a Russian company that is now in the United States. So you when you have a former Russian company, especially in vodka, and you have left Russia and you're now working in the United States, you become a target for the Russian government. And it has been known, and they kind of bring this up in the article a little bit, that the Russian government will turn a blind eye for if their attackers are going after Russian assets on foreign soil. So that part, that little bit of the drama is there. But in reality, I mean, I don't think it just demonstrates the overall capabilities of this. So the Stoly Group and their CEO, Chris Caldwell, they revealed that they had a filing around a$78 million debt. So they're going into bankruptcy because they have this debt that they cannot basically take care of. And they had a severe disruption, is what they call it, to their firm's IT infrastructure due to the ransomware attack. And one of the things I think is an important part to kind of think about with this is the fact that it went after their ERP system was disabled and most of their internal processes, including accounting functions, were forced into a manual entry mode, which basically means they were not able to get those restored before the first quarter of 2025. And why is this important? Well, because they have to file a paperwork with the United States government around the uh the overall, I don't know how to say it, their financial aspects of their company. This is an important part because now it comes down to is okay, let's say you're able to recover and get your systems back, but it isn't meet the filing deadlines of the regulatory requirements that you may have. So it adds a whole level of complexity into this issue. So one thing to kind of think about is as you are security professionals talking to your senior leaders within your companies, there is the risk, right? So of going, well, IT will bring it back. It'll come back. But if it doesn't come back in a period of, let's just say three, four, maybe even six months, how does that impact your regulatory requirements around this? So what many people think that, well, okay, it just got nuked. Let's just bring it right back from where it began within a couple of minutes or within maybe even a couple days, and that's okay. But let's just say it takes a couple months to get that information back. How will that impact you, especially if you are having some sort of regulatory requirements around your paperwork that has to be filed? Will that cause you issues? So in this case here, I think there's a couple different things. One, they are the target of the Russian government, so that obviously makes things very challenging because they have some really good hackers are going after you. Two, is they don't have the money to pay up all the expenses that it became incorporated because of this ransomware attack. And then three, they have regulatory requirements that they have to go out and file. So it's a pretty big deal for them, and obviously they filed bankruptcy, but it's a big deal for all of us to be aware of, just especially as it this goes into this new phase, that I think we're going to continue seeing it happen. And you're, as a security professional, going to be one, relied upon to give good advice and expertise. But two, this is the other part that you could become the scapegoat of going, well, it's your fault while I got hacked, which it still doesn't solve the fact that the they're allowed$78 million and the CEO will be out of a job. But if they had a security person, I'm sure he or she is probably looking for new employment as well. But that's all on that. But again, comes right back down to ransomware attacks. You want to avoid those at all costs, and therefore you must have in place a business resiliency plan because you can't avoid them. They're gonna happen, it's gonna happen to you. Uh, you need to make sure that you have briefed up your senior leaders and you have a resiliency plan to address the problem. Okay, let's get into today's questions. Okay, this is group eight of domain four. If you go to CISSP Cyber Training, you can gain access to this and go and purchase the products that are out there and available to you. Um, yeah, I didn't get my Black Friday stuff going in time. Life has been extremely busy. So, all of you, just so you know, I will probably have a mini Black Friday thing happening sometime, probably before Christmas, just uh to be fun and enjoying, right? So just because everybody else is doing Black Friday doesn't mean I have to do it at that time. I can do it at any time. We can do it at any time. So, group eight, let's go ahead and get into that. Domain four. Question one: which protocol ensures confidentiality, integrity, and authenticity for web traffic, but may still allow certain metadata to be visible. Okay, key term metadata. A HTTPS, B, IPsec, C, TLS, or D SSH. Okay, so what confidentiality, integrity, and authentication of web traffic, another key term, web traffic, what is that? And the answer is A. HTTPS. Now, HTTPS encrypts web traffic, right? You all know that. But it also ensures that its integrity and authenticity is available using the TLS aspects. Now, metadata such as IP addresses, DNS queries, and sometimes the server name indicators will remain visible in HTTPS headers. Uh, TLS and SSH are frameworks for broader use, and IPsec does not specifically focus on web traffic. So the main thing is that out of the key term there is web traffic and it allows for certain metadata. Yeah, that's it. HTTPS. Okay, question two. Which protocol protects DNS queries but does not ensure the confidentiality of the query data? So it protects DNS queries but does not ensure the confidentiality of the query data. A DNS SEG. B DOH. C DOT or D SFTP. Now DOH and DOT, if you're not familiar with it, is DNS over HTTPS and DOT is DNS over TLS. So which one is it? Okay, again, does not ensure confidentiality of the query data. And the answer is A, DNS sec. Now it ensures integrity and authenticity through digital signatures, but does not encrypt the data. In contrast, obviously, DOS and or DOS, DO DO H and DOT do provide encryption securing the query confidentiality, so whether you're dealing with HTTPS or TLS. During a TLS handshake, which of the following steps does not occur? A server certificate validation by the client. B negotiation of cryptographic algorithms. C. Asymmetric encryption of application data, or D generation of a shared session key. So again, during the TLS handshake, which of the following steps does not occur? And the answer is C. Asymmetric encryption and application of application data. So the application data is encrypted using symmetric encryption for efficiency after the session key is established. Asymmetric encryption is only used during the handshake for the key exchange. So I hope that makes sense. Asymmetric encryption of the application data. Question four. Which secure file transfer protocol inherently requires no additional ports beyond those used for SSH? So again, which file secure file transfer protocol inherently requires no additional ports beyond those used for SSH? A F FTPS. B SFTP. C S C as in Charlie, P. And D FTP. So which file transfer protocol inherently has no additional ports beyond those for SSH? And the answer is B, SFTP. Now secure file transfer protocol operates entirely within the SSH protocol. So you don't need anything other than TCP22. F FTPS, oh my goodness, it's craziness, uh, requires a separate port, obviously, and you're gonna have for control and data channels. And you've seen that if you've worked in any sort of the um, oh what do they call it? I'm drawing a blank with this. Now if you're dealing with any sort of command line guidance, you'll know that you have to have two ports, an additional port if you're using FTPS. But again, SFTP does not. All it requires is TCP port 22. Question five. Why might HTTPS fail to protect against man-in-the-middle attacks in some scenarios? Again, why might HTTPS fail to protect against man-in-the-middle attacks in some scenarios? A. Weak encryption algorithms. B incorrect DNS configurations. C, certificate trust bypass, or D lack of public key infrastructure. Okay, so HTTPS, right? So we know it's a it's using the certificates, hmm, and it's HTTPS, so it's web traffic. So what is that? It is C, certificate trust bypass. So if you're dealing, if an attacker can trick you, an individual or a system potentially into trusting an invalid or malicious certificate, right, compromised by the CA, then the HTTP protections can potentially be bypassed, right? So the other options are less relevant to HTTPS, obviously. So the main purpose would be the certificate trust bypass. So you gotta kind of break it down. Question six, which protocol encrypts authentication data but leaves the rest of the session unencrypted by default? So which protocol encrypts authentication data? So the data going back and forth that it authenticates you, but leaves the rest of the session unencrypted by default. A SSH, B, IPsec, C Telnet, or D Radius. Okay, what encrypts authentication data? It is D. Radius encrypts only the user authentication credentials, i.e. passwords, by default leaving the other data as usernames and uh any sort of other information unencrypted. IPsec and SSH encrypt the entire session, while telnet offers no such encryption whatsoever. So you have to kind of break it down. It'd be easy to grab byte off on the telnet. I could see that happening potentially. Somebody go, oh, telnet doesn't have it, and they grab it. Uh, but it is radius, because radius does have encryption within the authentication methods, but does not uh it does not have it for the data. Question seven, which port does the LDAP, your Active Directory protocol, use when securing traffic with Start TLS? Okay, all caps start TLS. So which port of the L LDAP protocol use uh the when securing traffic with start TLS? Okay, port 389, port 636, A, port 389, B, port 3636, C, port 443, or D port 22. So LDAP protocol when using secure traffic with start TLS. If you don't know, you're going, okay, well, it'd be easy to go, I'll glob onto 443. Well, don't do that. Uh you might grow out glob onto one of the easier ports, and then you can break it down and go, well, okay, because if you don't know, is it 389 or is it 636? So start TLS upgrades plain text LDAP traffic. So basically your your active directory traffic on port 389 to an encrypted traffic. Port 636 is used for LDAP over SSL. So that would be something you which is called LDAP LDAP with an S at the end of it. So you're gonna have to kind of understand which is the difference. This might be a question that if you don't know, you're gonna end up having to guess. Uh so think about that. If but it was good to kind of get more as much exposure as you can around this piece of information. But again, port 389 is encrypted traffic on Start TLS, whereas port 636 is for LDAP over SSL, which is LDAP S, not Start TLS. Question eight, which of the following is a true regarding IPsec transport and tunnel modes? Okay, IP which is true regarding IPsec tunnel and transport and tunnel modes. A tunnel mode encrypts the entire IP packet while transfer mode encrypts only the payload. B transport mode encrypts the entire IP packet while tunnel mode only encrypts the payload. B or C, both modes encrypt only the payload but use different key exchange mechanisms. Or D, neither made pre neither mode provides encryption but only authentication data. Okay, so you're gonna break all this down. Which is the following is true regarding IPsec transport and tunnel modes? And the answer is A. Tunnel mode encrypts the entire IP packet, while transport encrypts only the payload. So if you kind of break it down, you think about it, it would make sense, right? A tunnel, you're going inside a tunnel, you think everything would be encrypted. If you're in a transport, you're like on the back of a flatbed truck and you're just doing the only part of it. So kind of think of it that way. Uh try to break down the question as much as you possibly can. So in tunnel mode, the original IP packet is encapsulated and encrypted entirely. In transport mode, only the payload of the original IP packet is encrypted and then leaving the rest of the header intact. So just kind of that's the differences between the two. Question nine. Why might enabling TLS 1.0 or 11.1 on a web server create a security risk? So again, you have TLS 1.1 and 1.11. 11, yeah, just 1.1, not 1.1.1, just 1.1. If I haven't confused you yet, I've confused myself. So again, why would you enable what would happen if you did that? A lack of certificate validation. B use of deprecated ciphers that are vulnerable to attack. C, no support for server-side encryption or D incompatibility of modern browsers. Okay, so modern browsers obviously can handle 1.1 and 1.0. However, the answer is B. Use of deprecated ciphers make them vulnerable to attack. Obviously, right now we're talking in 1.2 and 1.3 are the most current TLS ciphers out there. Uh, they are 1.0 and 1.1, are vulnerable to the beast attack and lack support from modern encryption algorithms. So they have been deprecated. Do not use them. Question 10. Which of the s which statement about HSTS is incorrect? Which statement about HSTS is incorrect? Okay, so HSTS enforces HTTPS connections to prevent downgrade attacks. B, HSTS requires client support to be effective. C HSTS policies are delivered in HTTP headers or D HSTS encrypts all HTTP headers by default. So which statement about HTTP? HSTS is correct. Oh my gosh, too many acronyms. So HTTPS does not encrypt HTTP headers. So that's what's incorrect about it. Instead, it enforces the use of HTTPS and prevents insecure HTTP connections. Encryption is handled by TL TLS. So again, the most incorrect one of HSTS is it encrypts all HTTP headers by default. That's the all part. Think of that. If you don't know, focus on all might kind of help guide you down the direction. What is a key limitation on using DOH or DOT for securing DNS queries? Okay, so we're talking about again uh DNS over HTTPS and DNS over TLS. So what is the limitation for doing so? A DOH does not encrypt DNS queries. B DOH requires on additional ports beyond HTTPS. C, DOH can obscure DNS filtering mechanisms or D DOH requires certificates issued by a trusted CA. So what is the key limitation of DOH over DOT for securing a DNS query? So again, HTTPS over TLS. What's the difference? And the answer is C. It can obscure DNS filtering mechanisms. So it encrypts DNS queries over HTTPS, which can bypass traditional DNS filtering solutions because the queries appear as regular HTTPS traffic. So that's why the filtering may not work, is because it's looking like a traditional web traffic that is encrypted. Question 12, which of the following uses symmetric encryption in IPsec? A ESP encapsulating security payload. B A H, which is your authentication header. C IKE, India Kilo Echo, which is your internet key exchange, phase one, and then D digital signatures. So which of the following symmetric encryption in IPsec? It uses symmetric encryption, I should say. And the answer is ESP, A encapsulation security protocol. Okay, so this is where it is a IPsec provides confidentiality through symmetric encryption and also supports integrity and authentication. AH only provides authentication and integrity. So your following of symmetric encryption for IPsec is ESP encryption encapsulation security protocol. And again, if you're not real sure, then kind of think about the whole part of this of going, well, if you don't know the key exchange, that really doesn't deal with the overall IPsec aspects. Authentication headers doesn't really have security in the name, as far as you would think. Digital signatures, you could potentially bite off on that, maybe if you didn't know. But then when it comes right down to ESP, the encapsulation security payload, uh, you again IPsec and IPsec tunnel. You might want to consider that when you're trying to filter it out if you don't truly know. Which attack can HTTPS not directly prevent? So which attack can HTTPS not again, not directly prevent? A replay attacks. B phishing attacks. C, eavesdropping attacks, or D traffic traffic tampering. And the answer is B. HTTPS secures data in transit and prevents eavesdropping or tampering, but does not protect users from phishing attacks, obviously. So it it doesn't really help you. Now they could make it look like, oh, look, it's HTTPS. I should be safe. Yeah, well, yeah, don't do that. But when it comes right down to it, a phishing attack, that's a social engineering thing. And yeah, the HTTPS will not perfect will not save you from that. Question 14 What primary reason to use PFS, perfect forward secrecy in TLS? And we've talked about PFS a couple times or a few many times on this podcast, but what the primary reason to use PF PFS in TLS? What would you do that for? A to prevent session hijacking. B to ensure encrypted traffic cannot be decrypted retroactively. C to increase the speed of TLS handshake, or D to validate server identity. So again, what's the primary reason for use of PFS? It is B to ensure encrypted traffic cannot be decrypted retroactively. Now we deal with this, we talk about the keys being stolen by unnamed individuals or unnamed countries, keeping this for the future of basically they're hijacking all the data they can so that when eventually when uh the data can be encrypted or can be deciphered using various new techniques, then what'll happen is they'll just pull it out of the shelf and they'll try to decrypt it and they'll hey, haha, we have all this information. Uh but this is where perfect forward security will help deliminate that as far as the intercepted session. So they can't be decrypted anymore. So anyway, that is their question 15, the final melon. What is it? What does the air quotes secure in HTTP guarantee? HTTPS guarantee. A the site is free from malware. B, the server is legitimate and connection is encrypted. C, the wipe site's content is accurate and trustworthy. Or D, the server is always the server will always use the latest encryption algorithms. Okay, so you know all the those three of the four are like, yeah, no, yeah, no, yeah, no. But the answer is B, the server is legitimate and the connection is encrypted. So again, that's a secure HTTPS guarantee, is it is legitimate. It actually exists and the connection is encrypted. That being said, if you go to a bad site that has HTTPS, that doesn't mean that the content on the site isn't bad. So, but that's one thing to think about. All right, thanks so much for joining today, and we're so excited that you're part of CISSP Cyber Training. Uh, we are just if you have any questions at all, please head on out to CISSP Cybertraining.com. Go check it out. All this stuff is out there and available to you. You've got the content, all the questions, they are available, and it's just again small frat fee for a lot of the stuff. But if you want the free stuff, the free stuff's on my site and on YouTube as well. So you can get free stuff if you want. You don't need to go with the site and purchase it, but if you want more content, yes, that's where you would need to go. Uh, also go to reduce cyberrisk.com. Yes, reduce cyberrisk.com is obviously my uh consulting website. And if you are interested or need a consultant uh for cybersecurity aspects within your company, uh, from insider risk to virtual SISOs, you name it, you can get a hold of me, and I am happy to look at what you got and we'll have a little chat. So, again, reduce cyberrisk.com. Okay, have a wonderful day, and we will catch you all on the flip side. See ya.

Contributor

Shon Gerber

Host