CCT 354: Data Security Controls and Compliance Requirements for the CISSP (Domain 2.3) - REPLAY

Your firewall can be patched tomorrow, but what about the place your system hides its real secrets today? We start with a timely warning about a serious Fortinet FortiGate vulnerability and why perimeter devices are still a make-or-break control, then we pivot into the deeper layer most people ignore until it’s too late: memory.

We walk through CISSP Domain 3.4 by focusing on what memory protection is actually trying to achieve: confidentiality, integrity, and process isolation. From there, we unpack how modern operating systems enforce separation with paging, segmentation, and strict read, write, execute controls. You’ll hear why Meltdown and Spectre were such a big deal, how speculative execution can leak passwords and encryption keys from privileged memory, and why patching decisions are never just “apply everything” but a risk-based vulnerability management call that depends on visibility into what you run.

Next, we connect memory protection to virtualization security. We break down hypervisors, guest and host isolation, Type 1 versus Type 2 designs, and the threats that keep security teams up at night: VM escape, side-channel leakage through shared CPU resources, and the operational hazards of memory overcommitment. Then we bring in hardware roots of trust through TPMs: secure boot, measured boot, key storage for full disk encryption, TPM 2.0 types, and how HSM-style key management shows up in cloud environments. We close with practical best practices, from firmware and microcode updates to choosing encryption controls that fit your actual risk.

If you’re studying for the CISSP or building a real-world security strategy, subscribe, share this with a teammate, and leave a review so more security pros can find it.

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!

Transcript

Welcome And What To Expect

SPEAKER_00 0: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 Sean Gerber, and I'm your host for this action-packed informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. Alright, let's get started.

SPEAKER_01 0:26

Hey everybody, it's Sean Gerber with CISSP Cyber Training, and hope you all are having a beautifully blessed day today. Today we're going to be getting into domain 3.4, and we're going to be getting into understanding security capabilities of information systems, uh, getting into TPMs and also a little bit of tied to encryption and decryption related to that. But I hope everybody is doing all right and staying warm during this very cold time. And also wanted to give a shout out to the folks in LA and all the stuff that they're going through. It's just it's mind-boggling to see what they're having to deal with and big chunks of Los Angeles just being leveled. It looks like a war zone. It is terrible. It's absolutely terrible. But yeah, we just hope and pray that everybody there is safe that's listening to this. Um, yeah, I know unfortunately that it's not going to be the case for everybody. So it's just a sad, sad state of affairs.

Fortinet Zero Day Patch Warning

SPEAKER_01 1:15

Uh, so today we're gonna get into 3.4 and we're gonna go into some of the aspects, but before we do, we're going to get into some of uh just uh something that came up around Fortigate firewalls and a vulnerability associated with it. All right, this is again with uh InfoSec magazine, and they had affirmed the fact that Fortinet has confirmed that there's a zero-day vulnerability against their firewalls, and they highly recommend that you patch. I know I don't know if any of you out here, out there listening have Fortinet firewalls. I know I've worked with them in the past. Uh works really well. They're a good good uh firewall for an organization, but they have they've considered it a 9.6 on the vulnerability scale, and it's pretty substantial. So if you do have Fortinet firewalls, I would highly recommend you go take a look at it and see if yours might be affected by this. Uh but what it is, it's an authentication bypass vulnerability affecting the Fort Fort OS and the their proxy, 40 proxy. Um, and it can be basically exploited to hack various other Fortigate devices within the ecosystem itself. Uh, if this was discovered by Arctic Wolf, I've worked with them in the past as well. They're uh they discovered a massive exploitation campaign going on against these devices, and it was happened in December of 24. So obviously they did the responsible thing for disclosure and they waited a while to get the patch and everything ready to go before they actually disclosed it. But that being said, it was in December and it was been probably manipulated for some time. Uh they say that the threat actors are alternating, or all alternating, they're altering the firewall configurations and extracting credentials using DC Sync. So um, I would highly recommend that if you do have Fortinet firewalls within your organization, you take a look at it immediately because uh yeah, it would be bad. We just we don't want anything to happen. And the firewalls are a key linchpin in your overall network security, please, or place, I should say, not police, place. Okay, so let's go and let's get into what we're gonna be talking about

Memory Protection Goals And Basics

SPEAKER_01 3:10

today. So today's 3.4, understanding security capabilities, and let's get into what we're gonna chat about. Well, what we're the overall goal in this uh domain is around memory protection and protecting the overall attitude and memory, whether it's in virtualization, whether it's in the TPM, whether it's just in the devices itself. So we're gonna kind of go over some of those aspects of it. And memory protection is a very important part of your overall security schema, and it really must be enforced. Uh many times people will think, well, it's it's in the bowels of this system, and you know, for someone to get access to the memory is gonna be really challenging. And in some respects, that is true, but the you also have to take into account that you have a much more mobile uh infrastructure now than you had in the past. And also the fact is that if these hackers get into your network, they do they will have access to the memory as well. So it's important that you have a good plan and that you are articulate that plan and you plan for it. Uh manipulation of the memory will result in instability and loss of integrity, obviously, of the system itself. And it, if you do have issues, it can read or can come result in the corruption of the kernel, which is some very uh relecent or not necessarily recent, but some issues, I think it was like 2015, 2017, where there were issues related to meltdown and specter. We'll kind of go into both of those here in just a little bit. So, what is memory protection? Uh, it involves a set of mechanisms to safeguard the memory from unauthorized access. And then obviously, because of doing that, it'll ensure the stability of the system so that you you are able to do what you need to do, right? This includes techniques in both hardware and software. So you're gonna have memory protection that's gonna be required in a hardware environment, because I know you not everybody here is in the cloud and you have some level of hardware devices within your data centers. Many people are trying to migrate to the cloud, but that isn't everyone. And you may not be the right choice for you depending upon your architecture and your overall business situation. But the goal of this memory protection is around data confidentiality, and this produce this protects sensitive data from being accessed by unauthorized people and other unauthorized devices. And so you want to ensure that the confidentiality of this data as it's sitting on these systems. The data integrity is where it prevents the corruption or unauthorized modification to the memory. And that's the so you have the confidentiality to keep it protected, you have the integrity that helps prevent from corruption, and then you have the isolation, the process isolation, which means that it's operating by itself independently and it's not operating in a way that it could be uh interfered with with any of the other memory spaces. So you have confidentiality, integrity, and process isolation. Those are the overall goals of what you're trying to do when it relates to memory protection. Some examples of memory protection techniques would be memory segment segmentation and paging. Uh, this is where it's used in modern operating systems and it divides the memory into manageable blocks. So they're separated, they are operating independently, and they're not one big giant blob. The other one obviously is access control mechanisms where they have read, write, and execute permissions on these memory environments. Those you want to make sure that are in place. Now, in the past, we the I will say that I've dealt with hardware where you could put some level of uh access controls on the memory, but they didn't do it because of the fact that it was system other systems were taking access of this hardware and adding more restrictions such as access controls on memory potentially could give you issues. And so that folks just didn't do it, they didn't turn it on. Now, with these new systems, I again I will tell you I have not dealt with that, but I would assume that it's probably an easier process than it was in the past. So there are abilities to add access control mechanisms to your overall memory schema. So here's the we're gonna talk about meltdown inspector

Meltdown Spectre And Patch Risk

SPEAKER_01 7:04

just a little bit. Now, the reason for meltdown, this was a flaw of in a speculative execution, which allowed basically user-level applications to read the privileged kernel memory. And as we all know, the kernel memory sits in the bowels of the beast of your computer and it allowed applications to read it. It should not be the kernel should not be allowed to be accessed by any sort of application. Uh it is a standalone system, or not system, but it's standalone memory that is set aside specifically for running operations. Now, the meltdown, it did cause out-of-order executions to bypass memory isolation mechanisms that were already in place. And then what it did is it gave exposed potentially sensitive data such as passwords and encryption keys to individuals or applications. So that was the meltdown uh vulnerability. And again, I think it was right around 2015, maybe. Yeah, somewhere in that range. It's been a while since it occurred, but it was a pretty big deal because of the fact that it did a lot of times the met the passwords and the encryption keys are kept in memory, right? And that's where they're kept so that they can decrypt and encrypt the data. Uh and therefore now allowed access to it. The specter vulnerability, this tricks the processor into executing incorrect speculative instructions, right? That leaks potentially sensitive data. And again, that's getting more data out of the system. Now, let's be realistic here as well. So if you're looking at it from an overall risk standpoint, one, you want to patch it if it's available. Two, you have to understand if there is a risk to your memory, uh, is it worth dealing with the patching? Now, in many cases, it's it may not be something you want to actually go do. You may be in a situation where it's like, you know what, my systems are so protected because I'm behind firewalls, behind this, behind that, that they don't necessarily need a an update to the operating system, or in this case, maybe the device itself. But you need to kind of weigh all that out. Now, if your computers that are going to be dealing with potentially memory challenges are running highly sensitive and highly secure environments, then most definitely you'd want to address that. So you have to really kind of weigh the risk and also understand how many of systems might be affected by this potential vulnerability. If it's all if it's only a couple, then they're much easier to fix. If it's an entire enterprise, you may want to just determine which ones will you address and which ones will you not. So again, when we talk about vulnerability management, it's an important thing to remember. You may not patch everything. It may not be in the best interest of the organization or the company to do that. You may decide that this, we're just going to let some of this live for a while until we come back and address it either with potentially new hardware or other mechanisms in place to protect that information. In this case here with Spectre, it impacts the CPUs across multiple vendors and architectures. So there it would be something you'd probably want to go and address because it's affecting multiple vendors and it could affect multiple systems in a more or less kind of a fragicide kind of aspect. One of the mitigations around it was the merit code updates and then all as well as compiler changes to introduce fences and disabling certain CPU features. So again, that's not a simple thing as going, hey, I'm just gonna go add a little button here and it's gonna go work. No, it's that would be a pretty intense update that you'd have to do. So you'd want to make sure that it is going to meet your needs as well as a good plan on when you would resolve this issue. And

Virtualization Memory Isolation Explained

SPEAKER_01 10:23

when we're dealing with virtualization, uh, that's the next topic. One or more operating systems are operating within a single host. And this is where you it's the simple idea is you have one PC within a very large server farm. And they are virtualized within this environment. And I know you all have probably dealt with virtualization at some point in your careers, especially those that listen to this podcast, because many of the folks that listen to this, you guys are well seasoned and you've at least heard of it and maybe understand the concepts around it. Now, some of the common types around virtualization are Hyper-V and then VMware sphere as well. And there's many others that are out there, but those I've dealt with Hyper-V and VMware specifically. Uh button bottom line is that all it does is it's it's creating multiple little computers inside a uh virtualized environment that, and so they have just multiple multiplicity versions of it. Um, it can it's extremely useful, right? It has multiple instances of the same or different OSs. You can have Windows working with Linux, you can have all that stuff kind of in the same visor, hypervisor, and it just really kind of comes down to what you're trying to accomplish. These are optimized for computing power, and it helps to reduce the overall cost within your organization. So you'll pay for a very big expensive server, you'll pay for the hypervisor that will then run all these virtual machines, and then you'll have licensing that it's tied to each of these machines. But overall, you're not paying for uh all these different hardware devices that all cost money, and on the other side is you have to then turn around and dispose of them over periods of time. So there it there's a lot of really good value in virtualization. And hence the cloud, AWS is an example in Azure, would not be where they're at today without some form of virtualization. I mean, down to the point where they're running scripts that are that are running pieces, just parts of a of a computer. So you don't even have a full operating system running, it's just running specific scripts that are then you're getting charged for, but now you don't have to dedicate an entire system to run some small little thing that's occurring. So that's an important part as well. So the virtualization piece has really changed a lot over the past 10 years to the point where it's extremely profitable to use it. But like we mentioned in the previous podcast, you also have to run the risk of having too much virtualization, and then it ends up costing you a lot more money that maybe you didn't necessarily need. So it does virtualization will allow multiple machines to run on a single physical host with the hypervisor managing all the resources. That's the purpose of it. Now you have a memory protection in virtualization, and this deals with virtual memory management and then guest and host memory isolation. The virtual memory management, this maps the virtual addresses to the physical memory using page tables, and it's managed all by the hypervisor. One of the things you want to avoid, and one of the concerns, is that when you have a hypervisor that is basically acting as the intermediary between all of these virtual addresses, could someone who gains access to one virtual machine then turn around and pivot to multiple virtual machines just because they gain access to the hypervisor? And that has been a real concern. And it's there's been various vulnerabilities that have come out there around that that have to be addressed. So when you're dealing with hypervisors, be very cognizant of the fact that if there's something that affects that, you'd probably want to address it relatively quickly because you you own one, you own them all. So it's an important part that you just need to be aware of. Now the guest and host memory isolation, this prevents guest OS from accessing other guests or host memory directly. Again, same concept. And this is where if you have a tenant that is specifically set up for you, but it's all under the same hypervisor, and then there's somebody else that has a little tenant that's set up for them. Could you go and blend between the two different hosts that are there? And that's that's something that could be done. Now, this could be done through the hypervisor or it could be done through the operating systems themselves. So it's just something to consider when you're dealing with memory protection on virtualization. Now, some key concepts around this is you get the hyper hypervisor types. You have a type one and a type two. Type one is your bare metal hypervisor, and we'll get into those just a little bit here in just a second. And then your type two is your hosted hypervisor. Now there's some various threats that can attack hypervisors. These are side side channel attacks, which is we'll get into this a little bit too, L1 terminal faults, and then then breakouts where a compromised VM can attack a specific hypervisor. And this kind of comes into is that you have a VM that may specifically be compromised and it can go after the host hypervisor specifically and try to run exploits against it. If they are vulnerable, that could be a problem. There's mitigation techniques around this using hardware-assisted virtualization, such as your Intel F VT and AMD-V, and then implement strong isolation and patch hypervisors or uh vulnerability against their vulnerabilities. Again, that's the key question here. You need to understand the systems that are within your network and understand the virtual systems within your network so that you can properly protect them. Again, even the virtual or hardware doesn't matter. And therefore you have a good plan in the play in place when a vulnerability pops up. Such as what we talked about just a little while ago is the fact that the Fortinet firewalls, uh, when we recorded this, is that there's a big vulnerability with them. If you know that you have Fortinet firewalls and you know you have a specific OS and the proxy versions, then you would be one that would go and go, hey, we need to patch this immediately. Whereas if you don't have a good clue of what's in your environment, it's really hard to patch something you don't know exists. So that's just kind of a little tidbit.

Type 1 Vs Type 2 Hypervisors

SPEAKER_01 15:49

So a type one hypervisor, we talk about bare metal. This direct this runs directly on the hardware without needing the host operating system. So an example of that would be uh VMware ESX uh and higher Microsoft Hyper-V. Those are ones that I've I've worked, like I said, I worked with before. The strengths of these is that they're higher performance and they have better resource management and they're used in enterprise environments, such as data centers and server consolidation areas as well. So this is your bare metal type 1 Hyper-V. Now, the the protections around memories is it's strong process isolation between the guest VMs that are there, so it does keep them well separated. And then there's direct hardware level access controls with the CPUs, which means you have to have directly connections to it to be able to mess with the CPU and so forth. So if it's in your data center, you actually have to connect to it through an ILO port or something like that. You're not allowed to just go in and get access to it directly through potentially one of the VMs that is there. Type 2 hypervisor, this is a hosted hypervisor. Now, this runs on top of a host operating system acting as an application. So the first one is a dedicated hypervisor. This the second one is more or less kind of an application that's running uh on a system itself, a hope, a host operating system. Examples of this would be Oracle VirtualBox, VMworkstations. I mean, and I know VMworkstations are really easy to get access to. Uh, Microsoft Workstations is another one. These are real easy to install and they're very good for desktop environments. And they're a really good way that companies have migrated away from, like even Citrix, to something like this as well. Uh the weakness is though it does rely on the security of the host operating system. So if that thing has been compromised, well, now it could potentially compromise all of the entire host as well. So it's important for you to have a really good understanding of which ones are running within your organization. Small medium businesses may use more of a hypervisor hosted model versus, like we mentioned above, with the hypervisor bare metal, the type one is more of an enterprise. And the reason is is I mean, the the type ones are very expensive. You have to put them in a server farm and they are not cheap at all in tens of thousands of dollars. So, in a case of a small medium business, that might be overkill for what they need. But again, those are the different options you have. Now, when you're dealing with considerations around protection, the host OS vulnerabilities again can affect the VM's memory isolation. So it's important that you do keep those updated. Now, the nice part about VMs is that you can set this on auto update and you are good to go. Now, the the question you may run into is if you're virtualizing applications, you'll want to make sure that you have obviously good backups for those and you have the ability to reinstall those if something were to go bad with the host OS. Now there's various threats to virtualization and memory.

VM Escape Side Channels Overcommitment

SPEAKER_01 18:30

You have the VM escape, and what this is, is this is where an attacker will compromise a guest VM to gain control of the hypervisor or other VMs. Uh some examples that came out, the Venom, this was in 2015. This exploded flaws in a virtual, okay, because these don't exist really. The virtual floppy drive in certain hypervisors. There are some places that still need a floppy drive. Yeah, go figure. But they do. Um, so some applications, I should say. So if that's the case, this is where this came out. Now, again, this is nine years old, so if it's been a while since this occurred, but it's just trying to give you an example where the VM escape could occur. Side channel attacks, this is where they uh exploit shared resources such as your CPU cache that may be utilized by multiple systems, and this is where it would infer potentially sensitive data from other VMs. So you're basically sharing in the everybody's in the pool, and you are now sharing data between each other in the pool. That can be really disgusting, but it is possible. Uh memory overcommitment risks. Uh, this is where you allocate more virtual memory than the physically available that can lead to performance degradation. And that I've seen this happen specifically. Yeah, you you run this in this runs into a big issue sometimes when you're dealing with VMs and they are almost maxed out, you will run into a lot more memory, virtual memory issues uh than what's physically available. So keep that in mind. And then malicious software installs on operating systems that such as malware and root kits, those can happen directly. Again, if your compromise OS has access to the internet and they're able to get root kits to those or some sort of malware, it potentially could get pushed to the hypervisor as well.

TPM Fundamentals Key Storage Secure Boot

SPEAKER_01 20:05

Now we're gonna get into a trusted platform module or TPM. Now the TPM is a specification for a crypto processor chip. Now this stores what happens on these the crypto keys on this TPM. Now it's typically a hardware supported versus hardware versus software. TPMs will be a like a hardware chip that's sitting within a computer. And because of such, it's much faster. It's also harder to dink with, it's harder for some people to mess with. Uh, one of the aspects around this would be full disk encryption. Uh, BitLocker and DMcrypt, they do uh use the TPM for encryption. Now, if you're dealing with places such as China, there are some restrictions around TPM. I ran into this when I was working for my multinational, uh, that they would not allow TPM version chips into the country. And the reason is is because they wanted to make control of the keys. If they deploy their own TPM version, like the China TPM, then what can happen is ideally, if they need to get access to the crypto keys, they can gain access to them because they have access to all the TPMs. In the United States, the TPMs are very separate, I should say the United States, Western countries, and as far as we know, those TPMs are not controlled by any other foreign government. So the keys would be safe and static within that TPM module within the system. Again, I say that, but I don't really know. Who knows? Maybe the NSA has got their fingers knee deep or their knee deep into all that. I don't know. Uh, random number generator is also incorporated into the TPM as well. So you typically have a random number generator within your computer, and it would be incorporated within your TPM chip that's sitting in your system. Uh again, the TPM it provides cryptographic functions to enhance security. There's a secure boot and measured boot. This prevents tampering with the bitloader and the kernel by verifying your cryptographic signatures. That's how you can protect your memory that's in the TPM. It does provide proof that the system's hardware and firmware have not been altered. So it does have an attestation comment to that or com compatibility or whatever. I'm trying to figure out the word, but it does have the attest. Yeah, it can verify. Forget the I can't speak. And on top of that, that's a big $10 word. Key storage, it does store the keys for disk encryption and protects data in the memory as well. So it will keep all of that within your TPM module. Microsoft, we talked about, use a TPM, and then your trusted computing and cloud environments do use a TPM as well. I think we're on TPM 2.0, if I'm not mistaken. It could be higher than that right now. I haven't dealt with it in probably in about a year. But that being said, the trusted platform module is something that you really truly want to be concerned about. And you do it, this is why buying equipment from other places other than Western countries can be problematic. You just don't know what you're going to get. And I would assume that the system potentially has been compromised. Other concepts, computers can use TPMs to authenticate hardware devices. That's part of that there. The TPM chip has unique and secret RSA key burned specifically into it at production. Again, talking Western. I'm not talking anybody else outside of that. And I've just kind of a little side note. I know when you're manufacturing hard, or I should say, motherboards within other countries, many times the TPM chip would come from outside and then be soldered in. This kind of comes back to what we dealt with China. China would actually request the TPM not be installed so that it would be installed in country. So yeah, is the TPM Chinese-based or is it US-based? Hard to say. So again, I hope you understand what the TPM is. We've kind of burned this thing to death, right? One other thing that's an aspect around this is not necessarily a TPM, but it's the hardware security module. And we've talked about this in the cloud space. Um, this does act like a TPM in some respects, it did, but it does store your crypto keys, it manages and stores those within cloud environments. Uh, it does accelerate crypto processing as well, and a TPM is an example of an HSM. But the an HSM necessarily isn't a TPM. I know, and I'm being I'm splitting hairs there because the TPM was first, the HSM was second, and uh it is used quite extensively though. So I would highly recommend in your security world because you're dealing with keys and crypto keys, I would dig a little bit deeper into TPM and then understand HSM as well. That would be an important part of your overall security strategy. Now TPM 2.0, um TPM 1.2 is currently deployed in large numbers, but 2P 2.0 will be required. That's what it was. I couldn't remember. But uh, and I believe probably at the time when I did this first slide, I think 2.0 was just coming out. I think it's pretty much deployed now. All manufacturers are deploying uh 2.0. Now there's five different types of TPM 2.0. There's discrete and integrated firmware, software, and virtual. So your discrete TPM, this has got dedicated chips that implement TPM functions on their own tamper resistant semiconductor package. So that's the discrete ones. The integrated TPMs, these reside within another chip. So your discrete is it's specifically by itself. Integrated is it's embedded within another chip and therefore are not tamper resistant because they're inside another chip. Then you have your firmware TPM, this is hardware-only solutions which will run in the CPU's trusted environment. So it's specifically a firmware TPM that's just for the firmware, not for anything else. It's not for any crypto keys, it's not for anything that's outside of the specific firmware. Then you have your software TPM, this is where you have software emulators of TPMs, which run with no more production or protection than a regular program. So they're just they're out there in the wild, they act as a trusted platform, but they're not designed as the main storage of crypto keys. I mean, they they are, but you have to assume with the use of a software TPM that it could be compromised. So again, you just think about all of these things when you're deploying your cybersecurity strategy. The virtual TPM, this is produced or provided by virtual hypervisors and requires isolated execution environment within the virtual machine itself. But again, it's it's a virtual TPM and it is sitting in within the hypervisor. So there there are some challenges with that as well. And I tell you all of that saying that none of this is bad. It's just do you have to determine in your security strategy what are you trying to protect? And if the data you're trying to protect requires extreme levels of security, then some of these systems, such as a software TPM, may not be something you want to use. You want to be very dedicated on what kind of platform or TPM you're going to be using for your organization. So just kind of keep that in the back of your cranium.

Memory Buses DMA Attacks Bus Snooping

SPEAKER_01 26:41

Memory interfaces. Now, these interfaces manage communication between the memory and the CPU or potentially other components that are within this computer system itself. So you have DDR and SD RAM. This is the double data rate and SDRAM is what it is. It's just one word, sorry. Uh there sd RAM is something separate. You they're used in modern PCs for high-speed volatile memory, right? So you're just basically your SDRAM is there, it's used for high-speed access of memory, and it's super fast, right? It's really good. You have your MVRAM, which is a non-volatile RAM. This retains data even without power, and it's commonly used for servers. So power goes down, the memory is still there. Most other types of RAM will lose, and there might be ghost RAM. We I tried when I was on the red teams, we would try to uh exfiltrate some of that ghost RAM. Uh it didn't, it worked a little, but it was it was very problematic. So it would be more on those systems that are really super highly sensitive that you would be most concerned about. Security risks, you have a direct memory access attack. This is a DMA attack. Now, this exploits the memory bus for unauthorized access. And then you have bus snooping. This is what captures data being transferred on the data bus itself. So there's some different aspects that could happen between the memories. So if you have memory that's going on back and forth, your DMA attack again exploits memory buses, and then you have bus snooping, which is actually capturing data that's being transferred across the overall bus of your system. Now the mitigation strategies obviously is your uh input-output memory management unit or IOMMU. Yeah, that just sounds like something out of a I don't know, some TV show, IOMMU, uh, to restrict your access to your memory. So to restrict direct memory access. So you want to make sure that you would put something in place to limit that. Now, again, I've never I've heard of them. I've kind of dabbled with them a little bit, but I've never really seen them work within the systems themselves. So I can't give you a whole lot of knowledge around that, other than to say that you would, if if memory potentially snooping is a big deal to you, you're gonna want to make sure that you at least put something in place to mitigate a little of that. Fault

Fault Tolerance ECC And Scrubbing

SPEAKER_01 28:47

tolerance and memory protections. This is again, fault tolerance ensures continuous operations despite the hardware faults. Uh, we have error correcting code, ECC memory. This detects and corrects single bit errors. We have redundant memory modules, these provide backups in case of memory failure as well. And then you have memory scrubbering. This is where you have periodic checks and corrections to the memory errors themselves. So there's a different things you can put in place for fault tolerance around this, and this was well to help and basically ensure that you have continuous operations in the event that there's hardware faults or potentially power outages. And so you want to have some level of now, a lot of this is all baked into what the systems you're already buying. This wouldn't be something you would actually have to go do. But it's important for you as a security professional to understand what are some of the controls in place. Again, if you're dealing with the super secret sauce, you're gonna want to, you're gonna be part of the procurement chain and you're they're gonna ask you very specific questions. You're gonna want to know these key concepts and understand it. Now, if you don't know, that's fine too, but you're gonna want to be able to talk logically to some of your architects or your engineers around this information. Because your architects may not know specifically what you need from a requirement standpoint. And if you come to them and say, hey, I need X, Y, and Z, I need two-point, because I did this, this happened. I needed TPM 2.0, I need it on the devices. It cannot be Chinese made, uh, it has to be US-based. And if I have to ship uh equipment into that lab, then it's what's gonna have to happen. And then I had to work through the Chinese government to make that happen. So the point of it is you as a security professional are gonna have to know those things, at least to be able to talk logically to the people that are much smarter than you. And and that's good. You you need to be able to do that. So those, and that's also your senior leaders are gonna expect you to do that. That's a key factor when you get in the C ISSP. Yeah, taking the test, yeah, that's great, you pass it. But there's a lot of stuff that you're gonna have to remember uh besides just passing the CISSP exam. Again, that's why we're here. Pass it, but you it's there's some great, great information that you can use to help you with your overall security strategy. Now, the security implications around this, it does prevent memory corruption, which again could lead to system crashes or exploitable conditions. So again, you you want to make sure that you put things in place to help immediate or remediate that.

Memory Encryption SGX SEV Tradeoffs

SPEAKER_01 31:05

Now, encryption and decryption for memory protection. What is this? Now, this is where encryption transforms data into a ciphertext to prevent unauthorized access, right? So it basically encrypts it. You can't see it, can't do anything with it. Decryption reverses the process, the overall thing, right? We all have dealt with encryption and decryption a lot, especially in the CISSP. So there's types of memory encryption. You have data at rest and you have data in use. We've talked about this extensively around data at rest, and this is where the data is stored on the disks. Data is very rarely ever at rest, but when it is, you want it encrypted. Data in use is where it protects it actively being used in memory, right? So if it's in memory being transmitted, you want it to be protected and encrypted. The problem with all this encryption is it adds additional drama to the overall plan, with the fact that it takes a lot more stuff to make it happen. Hardware implementations, you use the Intel SGX, which is their software guard extension. This protects enclaved memory from external access. And then you have the AMD SEV, which is their secure encrypted virtualization chip, uh, and this encrypts the entire VM memory. So lots of great tools out there. Again, as we've talked about though, adding encryption does have drama in the fact that it will slow down the system, it adds latency, um, you you just end up, and I will say, Pete, the operations folks will complain because their system is slow. So you're just gonna have to work through all of that, right? I'm talking kind of like a I guess like a whiny little 10-year-old. But it's true, they will. They'll complain. They will not be happy. Benefits, uh, defense against cold booger attacks, which again, uh, this allows the attacker to extract encryption keys and other data from the computer memory after it's been powered off. So again, this is where the memory the keys are kept within the memory itself. Uh yeah, I've I've I've heard of it happening. I know it can happen. I know people have done it. I've never seen it myself, never witnessed it. Enhances protection in multi-tenant environments as well. So those are the benefits of having encryption. So again, it's an important part. You want to figure out how you can use it within your environment.

Best Practices And Security Leadership

SPEAKER_01 33:03

So these are some of the best practices for, again, for memory protection. You want to regularly update firmware and microcode to address any new vulnerabilities that come out. This, therefore, you need to be aware of these vulnerabilities. Just because you become the large organization does not mean that you sit in your ivory tower and wait for people to feed you grapes and wine. No, you have to be involved and you need to understand the vulnerabilities. I had a goal. My goal was to set uh to let my security architects know before they knew if there was a vulnerability. Now, granted, we didn't play, you know, catch, catch the mouse or whack-a-mole or anything like that. But if I saw stuff, I sent it to them. And what it did is it created a culture where if they saw stuff, they sent it to me. And it's very good. It was very, very important. Because one, at a minimum, I didn't always get a chance to look at some of the stuff they sent me, but I knew they were on top of it. And then when I did, and then when the CIO comes and taps me on the shoulder and says, hey, do you know anything about this? I'm gonna go, yep, covered. Good. We're under, I got it under control. That is a big factor. It's a big thing to actually add some trust and influence within your organization. And again, we talk about this with security. It's not about how smart you are, it's about how you can find smart people that will help you make the right choices. And it's about influence. The more you can influence the decision makers that you want, you know what you're doing, you have your ducks in a in a row, which they're never in a row, but if you have them in a row, then it may give them confidence that you actually know what you're doing. So important for you to be involved and engaged with everything that goes on within your company. And even this can start off just even as an architect. It doesn't have to be where you have to wait until you're a security leader within an organization for this to occur. You can do it as at any point within your organization. And if you do that, I will tell you right now, if you take this aggressive approach, they will look to you as the leader in many ways. So just a little piece of advice there. Use TPM-enabled devices for better key management. Again, use that as much as possible and be aware of what you have for TPM within your environment. Implement error code, error correcting code. Again, this is going to help with scrubbing the memory for fault tolerances. Again, it's a lot of this is baked in, but you at least you need to understand it. Where the ECC can help identify and fix errors within the data that's stored there. And then enable full disk and memory encryption wherever and whenever possible, but I will caveat that with based on risk. You need to understand the overall risk to your organization and then implement these tools. It does not mean, hey, Sean said implement full disk encryption everywhere. No, no, no, no. That may not be the best thing for you and your company. Your risk may not warrant that. Now, parts of your company may warrant that, but this is where you need to know data flows. This is where you need to understand where the data's at, and then understand who's the owner. So lots of little things in there. That little nugget there has got chop full of all kinds of good stuff. Okay, that is all I have for

Resources Blueprint Consulting And Wrap Up

SPEAKER_01 35:55

you today. Head on over to CISSP Cyber Training and check out. Well, we've got a lot of great free stuff. We also have some stuff that you can purchase that will get you all this the content you need to pass the CISSP exam the first time. I have a blueprint that will walk you through the book step by step by step. It has it is broken out to the point where if you just follow the blueprint, you will pass the test. I guarantee you. The part where it gets into goofiness is when you go, I already know that stuff and you move on, uh, then it gets a little squirrely. So you need to take the if you get in there, follow the blueprint, go through the blueprint step by step by step, and it will it will pay off for you. Also, if you are interested in consulting aspects, go to reduce cyberrisk.com. And I'm gonna have up my podcast. I just released an episode of that. There'll be some more coming out for reducesyberrisk.com here in the coming months. Uh, but go there if you need consulting work, if you need virtual CISO work or just like a security uh like upfit, a security look at your program, just let me know. Reach out to me. I've got some stuff out there, as well as I have a security assessment checklist that you can go through. And again, this is one that you can take and run with and look to your organization and see if how you're doing. What are you doing? Is everything good? Am I not good? These are some of the key questions that I would ask within a security assessment that will probably give you some guidance around what you should ask your senior leaders if you're trying to figure all this out. So, again, that's at reducesyberisk.com. Okay, that is all I have, guys. Have a wonderful, wonderful day, and we will catch you all on the flip side. See ya.