Our host intrusion prevention systems, just like our host intrusion detection system, this runs on a client device that provides a benefit when it's not on network. Again, the difference being now that it can prevent rather than just detect. We have the idea of a SIEM system, and these are still relatively new. I'm a big advocate for SIEM systems. We have lots of log files that are being generated. Ideally, we should review monitor, we said earlier in the course that logs are made consequential only with their review. Well, here we want to be able to review these log files. A human being will struggle to review all of the log files, and also to do it quickly enough to provide any early protection. SIEM systems can collect centralized log files from different systems, they can standardize them, normalize them, and they can produce reporting against them. But that reporting can be near real time. For example, if somebody creates a new administrative user on your network, it can send you a text message or an e-mail alerting you to that fact pretty much immediately within minutes. You can configure pretty much any combination of events between different devices as well. Maybe if you have a high number of attacks on your firewall, combined with some unusual log activity in your demilitarized zone. If those two things occur, then you can do something else. You have this idea of branching logic. If this, then that or if this and that then do something. You can configure alerts. Very flexible in terms of what they report on. The trick really is choosing which logs to centralize, which ones to protect, and what events to create alerts around. We have the idea of a honeypot. A honeypot is a device that doesn't actually provide a useful service to clients. But if you're an attacker and you scan it, it might look like a web server or a mail server. Now we put these typically in areas where users shouldn't be connected. Very commonly we see these in-between the external network and the internal network in the area we call the demilitarized zone. There shouldn't really be anybody there. If we put one of these honeypots there as a service, it can act as a trip wire. It can occupy the attackers time because it looks like a valid thing to attack. But also because nobody should be connecting to this device, if somebody does connect to it, It's a really good trip wire showing that there is an attack taking place. These are usually virtualized, you can download honeypots. But as with any security device, do just make sure that they're updated because if not, these defensive platforms can become a vulnerability in their own right. We have the idea of a vulnerability scanner, and we've referenced these earlier in the course. But these scanners are looking for known vulnerabilities, something like The National Vulnerability Database and looking for known threats, known weaknesses that are present on a network's known poor configurations. They are automated so they're not perfect. Like any automated system, they need a human being to help review the output. One of the key tricks here is to make sure you do something with the outputs. Seen a number of organizations that automates the running of a vulnerability scanner, which is great. They run it monthly and the output is then emailed to some technical staff, to security staff that there might be a list of 1,000 vulnerabilities or 100 vulnerabilities. Because these aren't creating internal pressure from customers, these might just get archived or nobody reads them. The reports are coming in showing you've got vulnerabilities, but nobody does anything with them. What I found is good practice is actually assigning the output of these, maybe doing them less often, but doing something with the output, assigning a project manager or assigning somebody to be accountable for the output. These are commonly used to measure compliance. Not unusual to see standards requiring the outcome of a vulnerability scan to be shared with either an auditor or the third party. I'm helping to prevent threats then patching. Can we patch all vulnerabilities? Well, not always. Might be difficult to do operationally. Just think about a system you have and has interdependencies. Maybe we have a line of business system that needs a vulnerable version or vulnerable version of a web server to operate. At that point, if you have, let's say version 5 of the web server is vulnerable version 6 has been patched, what if your application only works with version 5? At that point, there is a risk-based decision to make about whether or not you turn that application off. It can become really complex. Is there any other way you can remediate that threat? Can you manage the threat? Can you move your vulnerable web server into a high-security network? Can you add other mitigating controls? Can you reduce the risk in any way? We need to be sure that we are very carefully managing any change around things like patching with change management. Again, I'm a big advocate for change management. Typically it's unpopular with customers and technologists, at least in my experience, because it adds an overhead. Instead of being able to do something, install a patch, you now have to make a request. The request has to be reviewed, tracked. There is a degree of bureaucracy, but the huge benefits it brings or if something goes wrong, you might have planned your rollback. What you can do to undo the work that you've just done? But more importantly, you're better placed to identify what has caused a problem. If a problem occurs and you've just made a change, you can trackback more easily what has made the system change. Some patching can cause problems. In 2021, there were three client operating system patches that I applied to devices that cause outages. The things fixing the problem can have their own problems. Commonly called antivirus, it's not the best name for this, these days. More commonly we will see the term EDR, endpoint detection response, or endpoint protection, those kinds of terms and then they'll get better terms, because in fact all of these platforms they're not just dealing with viruses. We talked about viruses, worms, IDSs, firewalls. A lot of these platforms cover that range of services. They don't just do one thing, they will help filter email, web traffic, and so on. They're looking to identify malicious software, and most commonly, they're looking for known signatures or patterns. Because of this, we need to constantly update them. These platforms become out of date very quickly. It's a constant updating is needed. Just be aware that these devices, because they're now doing so much, actually have an overhead. I've seen endpoint detection response or endpoint protection or antivirus, wherever you want to call the platform or the product, take a 1/3 of the overall resources of the device that running on. Because they're constantly scanning your files, your processes, your memory, your network traffic, your emails. That's quite a lot of work to undertake. Firewalls, these are perimeter devices. We talked about the basic firewalls which operate at layer 3, and 4, looking at IP addresses and ports, and we have the idea that we talked about of an implicit deny, denying by default. Firewalls also have some additional capabilities, not just filtering based on IP addresses and ports, those access control lists that we talked about in Chapter 2. They can also perform traffic inspection. We have some advanced firewalls that we'll look at the content of the traffic. Not quite the same as layer 7 firewalls, which are much more tuned to a particular services, but they can look at things like the state of TCP connections, people trying to impersonate, and so on. These next-generation firewalls almost acts like antivirus in your firewall. That's the easy way to think about it conceptually. Typically, can we have firewalls, the demarcation of different security zones between an external Internet network and your internal network, for example? We may have lots of different security zones. We may have one security demarcation to the Internet. We may have internal demarcation between the client-state and high-security set of clients, or between both of those and the data center. We may have partners that we connect to. Again, very common to see both partners, each with their own firewall connecting together with two firewalls, each protecting their own network. Let's take a look at security infrastructure then. Again, we'll look at some more controls we have, but just a slightly different tangent. We will look at the physical environment to start with it, things like the data center.
