CCT 199: Practice CISSP Questions - DNSSEC, IPSec, DoH, DoT and other Networking Security (Domain 4)

All right , let's get started . Let's go .

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 talked about before , 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 I saw , 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 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 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 was in InfoSecurity Magazine or InfoSecurity Magazine . There is a vodka giant . Air quotes .

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 , stoli files for bankruptcy after a ransomware attack . Now there is a little bit of story behind all this . Stoli is a Russian company that is now in the United States .

So 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 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 Stolle 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 process , 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 .

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 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 doesn'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 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 many people think that well , okay , 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 of days , and that's okay .

But let's just say it takes a couple of 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 going after you . Two is they didn't have the money to pay up all the expenses that became incorporated because of this ransomware attack . And then three , filed bankruptcy .

But it's a big deal for all of us to be aware of , just especially as 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 you could become the scapegoat of going well , it's your fault , while I got hacked . 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 , it 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 going to happen . It's going to happen to you .

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 .

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 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 8 , 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 . The TLS and SSH are frameworks for broader use and IPSec does not specifically focus on web traffic . So , the main thing 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 DNSSEC , 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 DNSSEC . Now , it ensures integrity and authenticity through digital signatures but does not encrypt the data . In contrast , obviously DOS and or DOS , doh and DOT do provide encryption , securing the query confidentialities , 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 secure file transfer protocol inherently requires no additional ports beyond those used for SSH A FTP-S , b , sftp , c SCSC 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 TCP 22 . Ftps oh my goodness , this craziness requires a separate port , obviously , and you're going to have to control the data channels , and you've seen that . If you've worked in any sort of the what do they call it ?

I'm drawing a blank with this . Now , if you're dealing with 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 using the certificates 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 HTTPS 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 . You got to 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 but leaves the rest of the session unencrypted by default ?

So which protocol encrypts authentication data , so the data going back and forth that 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 . What encrypts authentication data ? It is D .

Radius encrypts only the user authentication credentials , ie passwords , by default , leaving the other data as usernames and 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 bite off on the Telnet .

I could see that happening , potentially Somebody going oh Telnet doesn't have it and they grab it , but it is RADIUS , because RADIUS does have encryption within the authentication methods but 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 ldap protocol use , uh , the when securing traffic with start tls ? Okay , port 389 , port 636 a , port 389 , b3 . Or D , port 22 . So LDAP protocol when using secure traffic with StartTLS ? You don't know , you're going okay . Well , it'd be easy to go . I'll glob onto 443 . Well , I don't do that .

Yeah , you might 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 active directory traffic on port 389 to an encrypted traffic . Port 636 is used for LDAP over SSL .

So that would be something which is called LDAP with an S at the end of it . So you're going to have to kind of understand which is the difference . This might be a question that , if you don't know , you're going to end up having to guess . So think about that .

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 8 . Which of the following is true regarding IPsec transport and tunnel modes ?

Okay , which is true regarding IPsec 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 mode provides encryption but only authentication data . Okay , so you're going to 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 .

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 1.1 on a web server create a security risk ? So again , you have TLS 1.1 and 1.11 . 1.1 , 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 phone with that are vulnerable to attack . See 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 . 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 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 HSTS is correct ? Oh my gosh , too many acronyms . So HSTS 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 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 that direction .

What is a key limitation on using DOH or DOT for securing DNS queries ? Okay , so we're talking about again , 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 . 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 AH , 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 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 and 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 , you get 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 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 doesn't really help you . Now they could make it look like oh look , it's HTTPS , I should be safe . Yeah , well , don't do that .

But when it comes right down to it , a phishing attack , that's a social engineering thing . And , yeah , https will not save you from that . Question 14 . What primary DPS 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 many times on this podcast .

But the primary reason to use 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 would eventually , when the data can be encrypted or can be deciphered using various new techniques , then what will happen is they'll just pull it out of the shelf and they'll try to decrypt it and they'll say haha , we have all this information , but this is where perfect forward security will help eliminate that as far as the intercepted session , so they

can't be decrypted anymore . So , anyway , that is it . 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 website's content is accurate and trustworthy .

Or , d the server will always use the latest encryption algorithms . Okay , so you know , all 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 . If you have any questions at all , please head on out to CISSPCyberTrainingcom .

Go check it out . All this stuff is out there and available to you . Got the content , all the questions , they are available and it's just , again , small 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 to the site and purchase it . But if you want more content , yes , that's where you would need to go . Also , go to ReduceCyberRiskcom .

Yes , reducecyberriskcom is obviously my consulting website and if you are interested or need a consultant for cybersecurity aspects within your company from insider risk to virtual CISOs , 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 , reducecyberriskcom .

Okay , have a wonderful day and we will catch you all on the flip side , see ya .