Security Principles and Perimeter

0:00In the 1989 movie, Indiana Jones and the Last Crusade, early in the film, there was a character there and his name was Vogel. And he advised Indiana Jones, he said, don't trust anyone, which turned out to be good advice because Vogel himself turned out to be the bad guy he shouldn't have trusted. Okay. Now, if I spoiled the movie for you, all I got to say about that is it's been nearly 40 years. You've had 40 years to watch this film. Some of you aren't even 40 years old. So don't get mad at me. You've had your chance. Anyway, that still applies though to just about everything in IT. We cannot trust anybody or anything or any system.

0:39Now, although it sounds kind of cynical and kind of negative in a certain way, it's also how we keep our jobs. Okay. It is very important. And people that are in IT understand that we have to adopt that principle. And then most people in business would. It does make us feel like we're being kind of grouchy or cynical or something like that. And we're probably that way anyway. But even within IT, we understand that. So I would understand that another administrator has to be validated periodically in a lot of different ways. And to have a zero trust core principle that we're looking at right here, this assumes that we don't trust anybody.

1:18It doesn't matter if they're the best pitcher on our softball league, or if they're the most wonderful person, your best friend in the company. They wouldn't hurt a fly. That kind of stuff doesn't matter. Because even the nicest people will click on spam or something that has malware in it unintentionally. It doesn't mean that they have to have malicious purpose. They're not the ones that are directly trying to attack our company, but they could still be victim to that. And we need to keep kind of a circumspect view of what could happen in this kind of situations.

1:50So the zero trust core principles, there's actually a lot of different ways to teach this, by the way, and a lot of different areas that we could vector off of. But these are kind of the three that Microsoft puts to the forefront. I'll introduce some others as we go. But one of those would be verify explicitly. I'll talk about that next. You cannot make assumptions. That's one of the easiest things to do. And it's kind of lazy, but it's also human nature just to assume that something is okay because it was okay yesterday. We have to verify explicitly and continuously. Again, we'll get into that coming up. Also use least privilege. This is very difficult to do a lot of times for administrators. And not really in a practical sense, but more of in a mental sense. We got a lot to do. We're busy people. Usually there's fires to be put out.

2:37And sometimes the easiest way to tackle that is just to make sure that in one fell swoop, we have the broadest, most complete access that we can possibly have, like a global admin or a domain admin, something like that. But that's not always the best approach. Yes, you could fix the problem, but you could also introduce additional problems and potentially more serious problems, especially in a security situation. Also, we need to assume breach. I'll get into this as well as we come along here and as we discuss some more. But I'll just say right now, another spoiler alert for you besides the Indiana Jones and the last crusade, spoiler that I have already given, you've already been breached. Very good chance of that, no matter the size of your organization.

3:22So this is one of the safest assumptions that you can make in IT and we need to approach it from that perspective. All right. In the next video, we'll get started with taking a look at verify explicitly in more detail.

0:00All right, so let's take a look here at the verify explicitly portion of the Zero Trust model. So when it comes to this, the primary place that we make an entry point into this verification will be the user identity. That's usually the first stage of anything that happens. By the way, that could be a user as in like a human being, or it could also be a service account, or it could be an actual computer account. Because remember, if you've seen my other training, we really a lot of places here at CBT Nuggets, you know that computers also have a username and a password.

0:32And so in that respect, at least it kind of treated like a user because they also have to authenticate. So anyway, any of those kinds of things could be a user, but primarily, of course, we think of human beings with that kind of an identity. Then the other thing we have to address here is what kind of an app is being accessed. Different applications have different kinds of checks and balances. So for example, if I have just a, you know, an SMB share, it's supposed to be an M anyway, an SMB share, a file share on-premises in my Server 2025 server infrastructure somewhere, well, that's great, but it really only has the ability to check a username and a password.

1:13That's it. There's no two-factor authentication. There's no real passwordless authentication, any of that kind of stuff on its own at least. Or if we have, let me think of another example, on-site Microsoft Exchange servers. Again, they're not Exchange Online. Exchange Online has a lot more security features. Just a local version of Exchange Server for people to check their email and all that, there's not really a lot there. Again, we're back to just primarily a username and a password. However, if we do access applications, primarily that are like on the internet, under Microsoft Purview or another well-designed system, you're going to have a lot more security checks that are in place there.

1:55So going back to our Exchange example, if we were to use something like even one of the Microsoft 365 apps, like Outlook to check someone's email, well, that's going to have a lot more checks and balances there in terms of the authentication. That's going to involve very likely multi-factor authentication, probably passwordless authentication, or phishing-resistant authentication, which is really pretty much the highest level we can get to right now. So the application that you're accessing will also matter in this. I will say, and you'll see this as we go, on-premises stuff that we've traditionally had in an Active Directory environment, that's kind of okay, but it's not that secure compared to other methods that we now have at our disposal when we're talking about Cloud resources and Microsoft's whole Azure, Microsoft's whole Entra ID, all of that kind of stuff.

2:43And along with that would be risk. So when it comes to doing something like, again, let's just say accessing a file share that's in a corporate office somewhere or something like that, there's not really any risk detection there. As long as the user's entered in the proper username and a password, it's kind of regarded as, well, everything must be okay then. They knew the username and the password, but there are not any way to, there's not any way for Server 2025 on its own to pick up additional signals. Okay, it has to have other things bolted onto it in order for that kind of thing to happen.

3:15So for example, the corporate version of Microsoft Defender has some additional things that it can leverage to bring into an Active Directory environment, but Active Directory on its own doesn't really have that much. Also, things like behavior. It might be that this person is doing something that's outside of their normal scope of responsibility, and there are various signals that Microsoft can pick up on in order to be able to leverage that. There's also a matter of continuous verification. We don't really see this much of the time.

3:46So for example, when you have an initial log on, you're gonna put in your username and a password probably, and you might add on to that if you're using intra-ID, additional multi-factor authentication methods as well, hopefully passwordless and phishing resistant ones. So once you properly authenticated, you don't usually have to enter in your password again, at least not for a very long time, or to even re-authenticate if you're using your computer and your resources on a regular basis. There are refreshments that take place. There's something called a primary refresh token that actually lasts for 90 days.

4:19Then there's also a refresh token, and there's another type of a token as well that can be renewed in the background, an app token is what that one is, that can be renewed in the background without you having to do anything. So we're not usually even aware of it, but it is continuously checking our identity. And then there's also this device health. There's several different ways to validate that, and depending upon also whether or not you've brought in additional products from Microsoft. So for example, if you've got the right licensing, like maybe an E5 license from Microsoft, then you have the ability to do things like conditional access.

4:56This validates that, number one, your device is compliant, that's actually kind of a separate thing I should point out, your device is compliant, so maybe it has to, in order to be compliant, it has to have the firewall turned on, and it has to have antivirus turned on, or maybe some other criteria that you apply to that. If it is compliant, then it can pass what we call a conditional access, and again, this would be an Entra ID kind of a function there, and then it might be considered healthy and allow the logon to take place or the access to the resource to continue to take place.

5:34Again, just on Server 2025, we don't really have much that really does that same kind of thing. So even though the title of this course and everything is mostly focused on Server 2025, there's not really any escaping Entra ID and Azure and Microsoft's other products, because that's where the whole future is moving towards. There's also the issue of compliance, which I just kind of discussed a moment ago, and even things like location. So normally I log on from Phoenix, Arizona, that's where I live.

6:05I just got back from Europe, I was over there for about a month, and when I first got over there, I remember what country I was in, I think it was in Hungary, when I tried to access a resource that I normally would access every day, I got a prompt to re-log in again using my two-factor authentication, and I had my YubiKey with me, so it was easy enough to do. But very likely, if I had access that same application from Phoenix, it would not have prompted me with that, because that was not an unusual kind of behavior or not an unusual location. But when it suddenly saw that I was logging on from another country, it kind of raised suspicions, forced me to re-authenticate.

6:42And likewise, there have been times when this hadn't happened for a year and a half or two now, but there was time when I was getting MFA requests in Microsoft Authenticator, stating that there was a log on attempting to take place from someplace in China. Well, I've never been to China, and I certainly wasn't there while I was eating pizza with my wife here in Phoenix, when I got that message. So location also matters for that. Again, most of this is forward-moving into Entry ID and other security measures that Microsoft makes available to us in their cloud.

7:16But we still do have plenty of methods on-premises as well, and we'll be covering a lot of that as we go throughout this course.

0:00Now, let's move on here to the next level of zero trust. That would be least privilege. That's another principle we need to apply. The idea here is that users and workloads get only the access that they need for the time that they need it, which is we want to make that the shortest time possible. Again, there are a lot of different ways to do this, especially when you use Entra and Microsoft whole Cloud ecosystem. When it comes to something like Active Directory, we're much more limited in what we can use.

0:30Still important though, and still something that we can implement at least to a certain point. Generally speaking, especially when it comes to Entra, we want to use just-in-time access. This means that I can give someone a level of privilege for a day, or an hour, or whatever somewhat arbitrary length of time I decide is necessary for them to be able to complete that job. For example, I might have a contractor coming in next week to do some kind of a security audit, so I might give them certain security privileges for the week.

1:01But after that week, that expires and they can no longer access it. This helps to control the scope of a potential compromise if something were to happen while they had that access. There's also just-enough access. You don't want someone to be able to access more than they really need to be able to access. This is known as just-enough administration. Just-in-time administration, just-enough administration is the other principle there. There's also a risk-based adaptive policy. This again, really leverages into the strengths of what Microsoft has for identifying risk.

1:38Right now, for example, Microsoft analyzes about 100 trillion signals per day worldwide. These could be just very simple signals that might not really have much meaning, or they might be an indication of a threat actor that's in play. Nevertheless, that's a lot of signals. A hundred trillion signals per day, it's amazing. But they pull that out of various Microsoft Defender products, whether it's on an individual basis or on a corporate basis, and this allows them to use things like machine learning and AI and so forth to refine access, to identify trends that are currently happening in real-time to pick out potential threats there.

2:20Also, standing membership in something like domain admins is the anti-pattern. Admittedly, we've all done that in the past. We've had somebody who's a domain admin, they log on every day as the domain admin, even if they don't really need to. Really, it's better if we have even IT personnel log on with a boring user account that just does the normal daily functions that they need to do, creating Word documents, checking e-mail, contributing to a Teams chat, all of that stuff normally can really be done with just a normal user account.

2:55Then if they need to elevate privilege to do something else that requires a higher level of access, we can either give them another account that's a user administrator or possibly a domain admin, but usually not. But some other kind of a privilege like a backup administrator, if that's in the line with that person's job responsibilities, things like that. We generally don't want to have people logged on as domain admins all the time. Now that having been said, I'll have to admit to a little bit of hypocrisy there, because normally in training, we'll very often log on as a domain admin, a global admin, some other high-privileged account, but that's because we're doing a lot of demos that require that as we go.

3:37A lot of what I demonstrated does require domain admin. But if I were in a corporate environment where I'm just doing day-to-day work, I probably would not log on and keep a logged on domain admin day in and day out.

0:00All right, so if I haven't made you paranoid enough yet, now you're going to be, okay? This last principle of zero trust is to assume that there's already been a breach. Now, I gotta say this, just my opinion. My opinion is that most organizations have literally already been breached, okay? There's already been someone inside your network. At the very least, someone has already probably footprinted your organization. What open ports you have, what public IP addresses you have.

0:30That's kind of easy actually, because if you're on the public internet and you have a public IP address, well, you can get footprinted that way, or at least some initial probes. But I feel that most major organizations already have somebody or a system or malware or an agent of some kind already lurking within your systems. Probably a backdoor or something like that, okay? So what we need to do is to design our security posture as if there's already an attacker inside and we're trying to contain what they're capable of doing or what they're doing, and of course, trying to find them as well.

1:07And a good example of that, by the way, you can look for this if you want to. I don't know if I have the article anymore. If I can find it, I'll put it down below. But I think Wired, Wired.com, had an article on something called the SolarWinds hack that happened just a few years ago. With this hack, what they were able to do, so this is the bad guy right here. Actually, I've already got a bad guy here, don't I? It's right up here. This guy right here was able to get into SolarWinds update process, okay? You know, all software has updates periodically, right? So they were able to sneak into the virtual machines and the sandboxing that SolarWinds uses to develop their updates.

1:45I'm oversimplifying, but it would take a whole course to talk about that whole hack. It was quite fascinating, actually. Anyway, they were able to put malware inside of that. And then when that update was deployed to all of their various customers, okay? And there were thousands of them. Thousands of these customers then had that vulnerability built into it. And the attackers would be able to just at will infiltrate any of those organizations. Now, here's the scary part about that.

2:17What launched all of this? When did it all begin? As I recall from the Wired article, the attackers actually planted some malware on SolarWinds as a backdoor so that they could access it at any time. And that malware sat there for years. It was there for years without being actually triggered. And once they did trigger it, it opened up a whole Pandora's box of vulnerability. Now, I kind of hate to say that about SolarWinds because they're actually a really good organization. Some of the smartest people in IT work there and some of the best people in security work there, it just happened to be them that was lucky enough to get attacked like this.

2:56And to the attacker's credit, I gotta say it was quite ingenious, but there was also a lot to learn from that. Anyway, always assume that there's already an attacker inside. If you want some other somewhat anecdotal examples, another one, I just looked into this again recently. It was in 2021. There's a little town called Old Smar, Florida. It was their water system, their public utility system. Well, they were using TeamViewer to remotely, I guess, control their systems. Well, an attacker got ahold of that and they were able to increase the sodium hydroxide, which is a form of lye, I guess, in the water system.

3:35That's, I guess, used for purification and stuff like that. They increased it to 100 times the intended dose of chemicals that should have been gotten into the water systems. Now, other systems were able to detect that and prevent anything from happening, but there are several water systems. Recently, the time of this recording, it's September of 2026. Between July and August of 2026, there have been at least a dozen United States states that have had compromised water systems.

4:06The thinking here is that they are Iranian-linked actors that have been infiltrating these systems. So a lot of times we think that it's someone that wants to steal millions or billions of dollars, not necessarily. A lot of it is really an act of cyber warfare or an attempt to disrupt a system. So it seems a little bit more boring, right? After all, it's just a water system. Well, try going without water for a few days and see how that works out, okay? So the same thing is true of power plants. They are very, very targeted in this whole kinds of things. All kinds of utilities are very high-profile systems.

4:37And it's not just the United States. Last year in Poland, they had five water treatment plants that were breached. Quebec, Canada also had something like that going on. So do assume that there's somebody already inside and we're trying to control this. Also, we want to segment one stolen credential so it cannot walk the entire forest. Let me give you an example of how you could do that. If we go right back to only a Windows system. So where am I at here? I'm an active director of users and computers. And let's say that we have an administrator.

5:07Who have I got here? Let me go to my user account. So under Phoenix admins, I've got user accounts. And there's Phoenix admin 02 right there. So what is Phoenix admin 02 a member of? Well, nothing, just domain users. So a pretty harmless account, at least on the surface of things. But I need Phoenix admin 02 to have administrative control over our user accounts down here in Phoenix users. So we get a new user in, we need them to be able to create an account. I don't know, set their password, maybe change something about their group memberships, that sort of thing.

5:40What we can do here is to delegate control. So when I do this, it starts this little wizard, but notice that it's only going to apply to that specific organizational unit. So as I set up accounts and set up privileges and things, I want to carefully scope that to only the level that that user is going to be able to manage. So it's a Phoenix admin. They're going to be in control of the Phoenix users organizational unit. They're not going to have any privileges over Tucson or New Mexico or any of the rest of this entire infrastructure.

6:12So as I click on next through this, I'm going to click on add Phoenix admin 02. There they are. I'll add that user in here. And then now I can control exactly what they can do, create, delete and manage user accounts. Or maybe I only want them to be able to modify group membership or to reset users passwords and force a password reset at the next login. So this top one would probably address all of the other ones there, but if I wanted to be even more granular, I could say only that one or only that one.

6:46And that's one of the ways of being able to control the blast radius. So I'm just going to choose that one for our current purposes, click on next and then click on finish. Now, Phoenix admin 02 will now be able to manage all these accounts. They'll be able to create additional accounts, reset passwords, things like that, right? However, can they also change anything up here? Can they control any of these other administrators? No, they can't. Why? Because their delegation was only scoped to Phoenix users.

7:20Therefore, these are the only users they can control in any respect. Likewise, they cannot control anybody in Tucson, these Tucson admins or these Tucson users or anybody in New Mexico or any other part of my organization. Now, another part of that, since we're assuming there's a breach, we want to encrypt any data that is in transit and at rest. So that even if someone is in our network, if they don't have the appropriate certificates necessary to decrypt something, they still won't be able to get to it. At least we can presume as much.

7:51So even though they're in my network, there's data flying across the wire that they will not be able to access or at least interpret and make any sense of because it's all encrypted. So that would be in transit. At rest would be things like using the encrypting file system or other encryption mechanisms to encrypt files. And then they would then have to, again, have the appropriate certificate to be able to decrypt that. Now, could they potentially get a hold of that certificate? Yes, but we don't want to make it easy. We want to at least make sure that things are encrypted so that they have to take that additional step of getting whatever's necessary for that key to be exposed.

8:29Also, you want to collect telemetry. Remember, I was talking earlier about the SolarWinds hack. One of the things that's equally fascinating about the way that the hackers got in was how SolarWinds, as the security employees, were able to chase down and pull the threads necessary to find out exactly where all of this originated. The reason why they were able to do that was they had meticulous logs. And in fact, they also kind of got lucky because one of the virtual machines that handled the updates I was talking about earlier, well, normally those virtual machines get torn down when they're done.

9:04Some reason or another, they actually don't even know why exactly, but one of the virtual machines never got really torn down. As a result, they were able to get into the telemetry of that virtual machine and find out what was going on and find out parts of how the attackers were able to get into that system. So if you don't have logs, you don't have traces, you don't have events that you can refer back to, it's very likely that you're gonna get compromised somehow and number one, either never know it, or number two, not know how they got in so you won't know how to defend against it in the future.

9:38That was a quick tangent as well. That's a lot of records. There could be potentially millions of logs to have to comb through, most of which will have no bearing on what you're trying to chase down. That's where third-party products and the advent of AI-driven third-party products can really help with this. And Microsoft is really good at this as well, by the way. That's part of the signaling, part of the 100 million signals that are able to collect and analyze on a daily basis. So the basic goal here is, we wanna limit that blast radius and detect fast, okay?

10:11This is why we have, like I was showing you earlier with the delegation of permission, we have, if there's one stolen credential, we don't want them to walk the entire forest, okay? We wanna limit that blast radius. Also, another thing is we wanna detect fast. This also is similar to something we have in programming called, what's it called, fail fast, okay? I was just looking at another one of our trainers' content yesterday on this. This is where you have several lines of code, right? Okay, and you know, in lines of code in programming, there can be thousands if not millions of lines of code somewhere, okay?

10:45Let's say that as we're going through the code, this one checks okay, this one checks okay, this one checks okay. This one has a problem, okay? Now it could just be a functional problem which causes the whole thing to fail and blow up and you gotta figure it out, okay? Might not be security related at all, but it could also be security related. Either way, if this fails, we want to stop processing the rest of all of these, right? All the rest of these lines of code, why? Because whatever this problem was right here where the X is, that could cascade down to all the rest of these and cause further problems on down the line or it could open up and expose security vulnerabilities as well in all of the rest of these, okay?

11:28Goes beyond our scope a little bit because we don't do development and programming here directly, but we want to fail fast. So what would happen there ideally then is, okay, if that first level had a failure or a security vulnerability or whatever, we want to prevent the rest of that from failing downwards or cascading downwards. That's what the fail fast part of that is. Now, we don't have a lot of products in mind right now. I don't have a lot of things in mind right now to demonstrate really the main purpose of this whole first skill in this course is to show you the threads, the perspectives that we want to have, such as assume breach, that we carry throughout the rest of this particular course as we try to track down security vulnerabilities and problems.

0:00All right, let's move on to some other security principles here. And this one particularly is called the CIA triad. By the way, I can't really go over all of the various security conventions that are out there, but these are some of the most common ones. Zero trust, CIA, some things like this, okay? So let's take a look at these principles again, because they're going to kind of weave their way into a lot of what we do in Windows Server. That's going to really, again, apply whether we're working with Windows Server on-prem or working with something in the cloud, okay?

0:31So first of all, there's confidentiality. Now, that makes some sense, right? What is this? This means that we want to limit authorized access and disclosure. This means that, of course, you're going to use things like encryption. You might use encryption over the wire, might be using IPsec. That's a technology that can both encrypt and also provide authentication for the transactions, for the network traffic that's taking place. You can use BitLocker for data at rest or the encrypting file system for data at rest.

1:03That would be confidentiality as well. And, of course, you would apply permissions in your NTFS permissions, for example, or your shared permissions, which really work together, to make sure that only the appropriate people gain access to those confidential documents, that confidential data. There's also integrity. This is to make sure that something has not been changed. So we want to prevent improper modification or destruction of any kind of data. One of the things that hackers will sometimes do is they will attempt to modify something.

1:37This could be network traffic as it's being transited across a Wi-Fi or a wired network, doesn't matter, but as network traffic is being sent, they may try to modify various aspects of that data, such as even the source and destination. It could be starting from this location, and it's intended to go to this location. Maybe this is an IP address that is the source and destination. This is the source IP. This is the destination IP. And an attacker, what they could do is they could do things like modify the headers of the IP packets so that it diverts it to a different destination than what was originally intended.

2:16Now, there's other things that has to happen there. We probably would have to do a denial of service on the original, set this up as a new destination, do some things to cover our tracks and so forth. We're not going to get into all those details, but what I'm pointing out there is integrity. So not only is it to make sure that the files don't get corrupt or improperly modified somehow, can also apply to things like network traffic. Then we also have availability. So certainly, you want your data to be secured, and you want the integrity to be there, but you also need to make sure it's available.

2:48So this is going to give you both timely and reliable access to information and systems. So it could be availability to a file share, could be availability to a web app, or some other kind of an application, or to a service, such as maybe to make sure that your DNS service continues to run, that your DHCP servers are continuing to run, any kind of an infrastructure server in that kind of a case, or availability of domain controllers. So I have only a single domain controller now, but when I did the core portion of this course, I had two domain controllers, and that would be a good example of availability.

3:26That way, if one of the servers has to be rebooted because it has some kind of a security patch or something like that, the other domain controllers continues to fill in that role, and so we're not down the availability of a domain controller. Now, I also have to point out, there's some tensions that appear in all of this. For example, for confidentiality, very often we recommend, especially on-premises, very long and complex or difficult passwords, okay? And the more secure we make the passwords, the more difficult it is to make availability available.

4:00Because why? Well, because people need to properly log on to authenticate themselves so that they can see what they're authorized to be able to access. If we've made the passwords so difficult that nobody can remember them or that they have to write them down or something like that, then that produces a lot of friction between confidentiality and availability. They can't access this because now they can't remember that complex password you made me have to memorize, okay? So some of these things work in tension, and you have to kind of find the balance for this sort of thing.

4:33As I was mentioning earlier, with availability, if I have two domain controllers, DC01, and I also used to have a DC, oops, let me try that again, DC02. Well, they were both domain controllers and both highly available. When I brought down DC02 because I don't really, in my case, in my lab, I don't really need it. It's not really a production server or anything like that. However, if DC01 reboots while I'm trying to do a demonstration, then I've lost my availability. Another thing that could happen.

5:04Let's go off of domain controllers and go on to something like file servers. And of course, there are ways to make things more available. You can use things like clustering and other technologies to be able to make things more available. But I'm talking about kind of an elementary level here. If we decide to perform a backup of our file server, maybe it's a weekly full backup or something like that. Well, especially if we're working with magnetic platters on our file server, that's pretty discontentive to back up an entire file server right there.

5:35So if we do that at 2 p.m. and we're performing this very demanding backup of the file server, yes, it's going to make the file server backed up. Yes, it's going to make the backup available, but it makes the availability and the timeliness of that availability of our file server very poor. Performance is going to be bad. Sometimes something like timeout while we're trying to retrieve a file, especially a larger file. So again, there are various parts of IT that kind of fight against all three parts of this triad, keeping with the backup idea there.

6:10Remember, we're talking about a file server backup? That affects integrity as well. Because if we get attacked by a hacker who is able to access our backups, okay, this very often happens with ransomware, they could encrypt the backups that we have. What does that do? That means we don't have our integrity anymore. Because we've lost our control of preventing modification or destruction. Now, there are certain things, again, that can help that, such as what we call immutable backups.

6:42So for example, in Azure, you can back up to Azure resources, and those backups are made immutable so that they can never be changed. Even by the highest-ranking person in your whole IT infrastructure or a global admin or something like that, once the backup's made, nobody can change it, including a hacker, for example.

0:00This is by way of quick demonstrations of this whole CIA concept here. Let's first of all take a look at who I'm logged on as. I'm logged on as phoenixadmin01. We want to confirm some things about the account, what its privileges are. I could do a, who am I all. That'll show my group memberships and you can see, it is quite privileged. It's probably overprivileged in fact. Member of built-in administrators by virtue of the fact that I think I'm also a domain admin in here and an enterprise admin. It's in here somewhere.

0:30There is a domain admins right there and then enterprise admins. This is a very highly privileged account at the moment. And anyway, if I go ahead and create a file share here, let's just go to drive C actually. Yeah, drive C is fine. I'll choose a new folder. I'll call this my CIA demo. Okay. And I'll just drop a file in here. Let's put in a new text document. Let's call it salaries. Okay. And we have CEO of a million dollars and a CFO of a, I don't know, $700,000 and whoever else, hourly employees, $14 an hour.

1:11Okay. So we have some sensitive salary information in here or pay information, I guess. And now we might need to protect that. So first of all, how would it be shared in the first place? We covered this a little bit in our core course for Windows Server here. But I'll just go ahead and share this and I'll go to show more options, give access to specific people. And right now I'm going to kind of make it broad. Okay. Everyone, I'll add that in everyone and give them read, write access. Now, again, that sounds a little bit reckless right at the surface of it, but underneath that top level, you can tighten down the security further as you go.

1:47Okay. So I'm going to click okay there. There now is our share DC01 and then CIA demo. That's our URL there. Or no, not a URL, our share path. Okay. So once I get into that though, I can adjust permissions more specifically on the actual file that's in there. So I'll go to properties here, go to security, see that everyone has pretty much full control right now. So I might want to lock that down more. And of course you would use other things. You would use a folder structure that would allow inheritance to do a lot of the work for you and everything like that.

2:21But since I'm working with just a single file right here, I'm just going to remove everyone. Oops, which I can't because I have to go to advanced permissions for that because of the fact that it's inheriting its permissions. So let me just do that real quick. So I'll disable inheritance, but I'll copy all of the permissions that were there into explicit permissions. I'll click okay here. Okay. Now we're ready to move forward. So there's everyone there. Click on edit. I'll remove everyone. Okay. And apply. And that's now what it should look like. So the operating system itself has access. The admin who created it has full access.

2:53Administrators have full access. And I would kind of expect that. But what about my other users? Let's just add in a specific user here. So phoenixuser09, for lack of thinking of anybody else right now. There we go. phoenixuser09. I'll click okay. And I'm only going to give them read and execute and read permissions. So they don't have full control. They will not be able to modify any of the permissions that we see there. And so here I've logged onto this Windows 11 workstation. I'll go to that URL of DC01. And then what was it?

3:23CIA demo. We do have access to that, right? Cause I'm logged on here. As you can see, like I said, phoenixuser09 down here in the lower left on the start menu. So now if I go into this, yes, I can access it because I was given permission, right? But what if I wanted to change the hourly employee pay to say $25 an hour? Now I've changed it, right? Well, have I? Cause if I click save, I won't be able to. It'll just take me through this loop forever. I'll try to save it, override it. You want to replace it? Yes.

3:54Access denied is what that is telling me, okay? Cause I don't have permissions to make any changes to that file. Okay, so that's just an example of the confidentiality that we would have. Let's take a look at something else here as well. Let me go back to the original. Let's just run a hash on this. So if I go to a file, rather to a terminal here, and I change to that directory to CIA demo and do a dir, we should see that only that one file exists. That's fine. But if I want to see the file hash of this, like in a SHA-256 file hash, I could do a get file hash.

4:28And the name of the file is salaries.txt. And then I would specify, oh, what kind of hash I wanted. So I could do an algorithm of SHA-256. That should be how I do it. I don't think it's case sensitive, but I'll do it anyway. SHA-256, press enter. And this now shows me a unique mathematical hash. So we've talked about this in other parts of the course, but just in brief, a hash is a one-way algorithm. It takes it through some college math and it produces a unique result. So there shouldn't be any other document that can produce the same exact result that we see here.

5:03Now, what happens if I make a simple change to it? So remember, I'm logged on to the domain controller, it's phoenixadmin01. As such, I have full control over this particular file. So if I just make the slightest change and I put like a period after hour right there, just one tiny little period, and I close this and save it, now look what happens to my file hash when I repeat the command. Notice that it changes this completely. And if I zoom in here, you should be able to see that. So just by putting that one little period on the end, notice that this was our original file hash that we have right up here.

5:39I wouldn't ask anybody to memorize that, but just kind of look at the first few characters if you want, and maybe the last few, and then compare that to this one down here. Notice that by adding the little period onto the end, it just didn't change just like the end of the file hash. It has something called the avalanche effect, which means that even the slightest change will change entirely, the entire hash result. So you can see that both of these are drastically different. This is just a demonstration of the fact that integrity has been maintained, and we can at least tell when something has been changed.

6:16You'll also see this when you go to certain download sites because it'll show a hash of a file that you're trying to download. And in order to help guarantee that, you're not downloading an impersonated file or a fake version of that same file or something like that. A lot of times the sources, like for example, on GitHub, they will provide a hash of that original file that you're downloading. And then you can run something like this or some other algorithm against it locally once you've downloaded it and see if it matches, you know you've got the right file.

6:49So anyway, that again takes us into the confidentiality, integrity, and availability CIA triad, which again is a continuing thread that runs throughout pretty much all of security, not just in Windows, but just about any operating system.

0:00All right, now, so what I'm gonna show you here is something called a traditional perimeter known as castle and moat. So the basic idea here is it's really kind of an old idea, but a lot of administrators still maintain this perspective. And so it's pretty important to cut this off or at least to make some corrections to the perception that we have here about the castle and moat. In fact, I've still talked to administrators in recent months that think that, well, we're safe because we're behind our firewall and we're inside of our own networks, everything is well-protected and we've got antivirus turned on and we've got a really good firewall and we don't have malicious users, so everything's fine, right?

0:41No, it isn't. So, but let's take a look here at how this originally was back in the day. And this is going back a couple of decades before the internet became what it is right now. So primarily we had this inside trusted network and you'd have a person at this workstation, you've had IT folks here and there, our little data center and a receptionist over here and he greets people that come in the front door. And so we have all these people and everybody's all friendly.

1:12We have a ping pong table here somewhere, sometimes we have games and stuff like that. We have Mario Kart contests, I don't know, all kinds of stuff going on. Or if it's anything like the CBT Nuggets office, they shoot Nerf darts at each other all the time. Anyway, it's a good way to put an eye out people, we all feel safe in here, right? We're all friends. We can yell across the partitions to the other end of the office and tell everybody that happy hour starts in 30 minutes and we're all out the door and having a great time. But that's a false perception in today's environment of security.

1:44That is not secure, but that's how we've always thought of it in the past. And the other thing that we would think about there was the firewall. So the firewall was the gate that kept out all the bad people, all the malware, all that stuff. And it's what controlled access to our inner network. That's why the large portion of our focus and our attention was on this firewall right here. Because as long as the firewall was protected and well administered, we were safe. And to a degree, that's still true.

2:14We still got firewalls, we still got to protect them, we still got to make sure that they're properly administered. However, because of the fact that there was so much dependency on that firewall to control all of our security, we pretty much had flat network design. So we might have our entire inner network here. Let's just call this a smaller company. Might be on a 10 dot, 10 dot, kind of like my own IP addressing scheme here. 10 dot, 10 dot, 10 dot, zero, 24. So we could have a maximum of probably 254 hosts on the inside, including routers and all that kind of stuff.

2:50And we might have everything on that same network. Yes, I know that sounds a little bit foolish in today's environment, but we could have our data center on that network. We could have our workstations on that network, our printers, everything, our SAN, everything on the same network, and there was no segmentation there. Because again, we had this false feeling of security that as long as we're inside of the network, everything's safe anyway, we're all one big happy family. However, this began to develop some problems.

3:20First of all, the firewall being the gate to the entire thing here, that was kind of viewed as our North-South, okay, North-South protection. That in networking, that's generally viewed as our network versus the internet. Okay, that's kind of how we generally think about that. There's also an East-West, okay, and that's for more lateral movement within our network. So what does all that mean? Well, the firewall controlled the North-South. An intrusion protection system that's sometimes integrated into a firewall, very often, in fact, intrusion prevention system or intrusion detection system, mail gateways, all that sort of thing, generally speaking, North-South traffic.

4:00Again, in an us versus them kind of a perspective. But our East-West traffic, very often, not very restricted. In that, we have things like SMB for server message block, in other words, for file shares, things like that. RDP, so that if you're the administrator over at this workstation here, you can RDP into one of the servers in the data center, that would be East-West traffic. If you wanted to use WMI, well, Windows Management Instrumentation, to administer a server somewhere or a file share or a, what am I trying to say?

4:32A SAN or a NAS would be even a better description of that. Anyway, remote procedure calls, all of that stuff, East-West traffic. Problem is, if something does get in, maybe we get something infecting this particular workstation right here, we don't really have very good East-West protection. And since we're in a flat network, one infection of say ransomware on this one workstation right here can potentially affect every other system we have. There's a printer, I don't know how valuable that would be.

5:03But anyway, every other system we have could be affected by kind of that weak-ish East-West traffic because it's a flat network. We've done nothing to really protect our data center from our workstations, from our laptops, from anything else. So that's it, I'm just presenting some problems here that can kind of come up from really this kind of antiquated thinking. Also, VPNs began to come on the scene more frequently, probably in the late 90s, I guess. This means that my traveling person out here in a hotel room in Pittsburgh has to VPN into the network.

5:39Now, they are on a vulnerable hotel Wi-Fi. And remember, they have to make that connection to that Wi-Fi first in most cases. And then, depending on the VPN product you have, it could turn on automatically, but they may have to manually trigger that VPN. So before that VPN is actually triggered, they could get infected on their laptop, then we're on a VPN, so they're effectively, logically inside the network the same as if they were on this one workstation right here.

6:10Now, if they've got an infection on their laptop, it again could spread to every other host inside of our network. And that kind of turns on its head the fact that, or the perception that attackers are all external and good people are all internal. That's not really true anymore because we don't really have this defined wall around our environment anymore. You see, now we started to move into other things. You might have Exchange Online, SharePoint, maybe you're accessing GitHub resources.

6:42All of those things live outside of our little protected network right here, and it actually opens up other opportunities for a potential exploitation, as useful as all those things are that I just mentioned. A big part of this again is that the users all left the building, especially during COVID. My next door neighbor over here to my right, she used to work for a major credit card company here in the Phoenix area, where they had a huge campus with thousands of employees on it. That campus has been emptied out. And now they're trying to lease out the space and that parking lot is usually empty.

7:13There's very few businesses that are now using that space. My neighbor and along with all the rest of her coworkers, they all work from home now. And that's how it's gone for a lot of folks. Also, when she works from home, well, she's accessing resources over the internet through things like Exchange Online. She uses outlook.com for email. She can use Word Online to create documents, Teams, all that kind of stuff. None of that is located. None of that is located inside of her corporate network.

7:47That's all on the internet. It's all in the cloud. And so a compromise that occurs, again, maybe through a VPN connection or whatever. I mean, we still do have company headquarters and stuff like that. But anything that gets compromised here now, maybe we compromised an admin machine. Well, now they can kind of live off the land. And that living off the land is what we call it when an intruder gains access or some level of control to a system. And now they can just use the tools that are already on that machine in order to probe or exploit the rest of the network.

8:19They could use an NL test. They could RDP. They can use PowerShell remoting, all kinds of other things to vector off of that one machine onto other systems that we have here. By the way, that's called lateral movement where it can move our East-West traffic here laterally throughout the rest of our network. So I guess the basic idea here as well, which is an important concept to grasp, is that we no longer have this physical structure of just headquarters versus the rest of the world protected by our little firewall down here.

8:52It's now really our identity that we're protecting, okay? Because we've got all of our users out on the VPNs. We've got our users at home, all that stuff. Any one of those identities that gets compromised has access into our network somehow through a stolen identity, a cache credential, a reused token, all kinds of things could potentially impersonate or hijack access into our systems. And this whole castle and moat, we might not even have that anymore.

9:23This entire thing could be Azure, okay? We might not even have a physical presence anywhere, at least in terms of like a data center or something like that. Our entire cubicle farm really might just be connected to Azure somehow or Enter ID or whatever else we have for a cloud service. So in short, the way I would say that is this now, the control plane that we used to have, which was just admins working internally and controlling the firewall and stuff like that, the control plane is now identity for everybody, for administrators, for our users, everybody.

9:58That is the control plane. And every action depends upon having an account. So once you have an identity, you can either use it legitimately or hijack if you're a bad actor. Well, once you've gotten ahold of that account, you're now authorized to do various levels of things inside of our resources. This applies to workloads. This applies to devices, users, all kinds of things like this. And the tokens that we have are now the keys to the kingdom.

10:29So if I have a token of some kind, it gives me authorization to access a certain server or something like that, well, I'm in, even if I stole that token somehow or otherwise hijacked. And any conditional access I have or policies that apply to me travel really with my ID. They don't travel with just my laptop or just my desktop computer. They travel with my identity. So our current perimeter now, no longer this castle and moat, our current perimeter now is identity.

11:02And another factor of that, by the way, is that now a lot of times an attacker doesn't even need to know your password because they can steal some kind of a token or reuse some kind of a token, which is not that easy to do, but it's possible while they still have access. There are things that are built in. I'm not going to get into it too much further right now because it's for a different day, but there are methods in place so that even if a stolen token makes it into our resources somewhere, there are other things that can raise suspicions about that, which we've talked about elsewhere.

11:34So for example, maybe the user that normally uses that token sits right here inside of our little cubicle farm attached to a physical desktop computer, but this token is being replayed from Serbia. Well, that immediately raises some level of suspicion, at least if we're using an all Microsoft solutions, such as Microsoft Entra, conditional access, and other tools that are available there. And as a result, that token can either get squashed or we might request or require a reauthentication where this user would get a notification on their phone, for example, a push notification says, are you trying to log on from Serbia?

12:16And then that would obviously be an indicator that something's gone wrong.