Side-channel attack is an indirect attack, and here you're looking at some aspect of the system's operation. It's exploiting some weakness. For some web transactions, however implausible it sounds, you can measure the time it takes for an operation to complete when processing a key, and that can tell you some information about the key itself. With some smart card readers, low-voltage readers, those low-voltage readers will transmit zeros and ones across a cable like a USB cable. By measuring the electrical impulses going across the cable, we can gain information about the traffic being passed backwards and forwards. For example, authentication codes from card readers and so on. How do we identify threats? There's a broad range of things. Well, we can rely on signature or pattern-based systems. If there is a known threat, some pattern that we can identify, we can use that. Protocol anomaly, looking at something which is misusing a protocol. If something doesn't look right, doesn't conform to the right standards, let's drop it. Let's not process it. Let's not even try. Then we get heuristic or learning devices. They form a baseline, and from that baseline, if something deviates too far from it, they can flag either an alert or they can try and block it. We get some intelligence services as well. Pretty much every nation-state now offers some threat reporting service that you can subscribe to. Some international services, some companies, some corporations provide these as well. Most big technology companies will provide relevant threat intelligence services. This should form part of our ongoing risk management, assessing risks and managing risks. Understanding that the threat landscape is not static. Ten years ago, we did not see ransomware. If you don't modify your control set, your technical controls to respond to the changing threat environment, you'll struggle to maintain a secure state. We need to link threats, vulnerabilities to our capabilities to modify our knowledge. We have some host-based systems that sit on one device and some that sit on a network. Commonly, we use both. For the next four slides, what we'll see is each of the different acronyms we look at start with an N for network or H for host. First, let's look at intrusion detection systems, IDSs. We start by looking at network-based IDSs and network-based intrusion detection system. These detect an alert rather than prevent. They will alert you if they detect something. Again, they work in the same three ways. Just look back at this slide. They can look at signatures, protocol anomalies. They can learn something that looks unusual. Network intrusion detection systems then typically what they will do is get a copy of data going across a network path. Data going across a switch to another switch via an uplink, so two switches connected to each other, intrusion detection system will get a copy of that data. It sits aside listening, snooping on the network traffic but for a good reason. If it detects a threat, well, it can then alert you it's detected, so it can alert. The alert can be configurable. It can email you. It can flush a message on the screen. It can send you a text message. Most systems are pretty configurable as to how you are alerted, but bear in mind this is reactive. If it detects a threat is taking place and you get an email that you pick up 10 minutes later, you are 10 minutes behind schedule. This could have happened 10 minutes ago. What could have happened in that 10 minutes? Well, still maybe you pick it up the next day. What then? Typically, we see these IDSs in high-risk zones, high-security zones, or boundaries between different security zones, maybe between a perimeter between the demilitarized zone facing externally and our internal network or maybe between our main network for our client estate and our data center. The problem with these network intrusion detection systems is that they are on a network. What if you're not on that network anymore? What if you move networks? What if you take your laptop to a hotel network? Well, then we need something that sits on the host. These work in the same way. Only now, the configuration is different. They're not protecting a network segment. Now they're protecting your device. Now they sit between your device and the external network. Again, they work in exactly the same way they detect rather than prevent. These are usually now built into either your operating system or into your EDR software, your endpoint detection response suite, your antivirus product, whatever you want to call it, but they protect a single device. I would argue these are commonly not as effective as network intrusion detection systems, but it doesn't mean we don't use them. It means they complement our network system. Network system is one very big capable network-based device. These are smaller pieces of software on individual clients but the important thing is that they confer a benefit when you are not on that big corporate network. To complement the idea of an intrusion detection system, we have intrusion prevention systems. These prevent rather than detect. These protect. These can still alert but they will actively prevent traffic from going further. They will do something. Here we see on a network, it looks very different. Let's just remind ourselves of what the network intrusion detection system looked like. It was getting a copy of traffic. Because it's getting a copy, it can't stop things flowing through. With a network intrusion prevention system, the traffic is typically flowing through the device. Now, what it can do is almost like a guard at the gate. It can stop traffic that it doesn't think should progress. It can actually do something. Then this is the highest security posture in that you can actually prevent traffic that doesn't conform to protocols that has a known poor signature or that deviates from our baseline. We've learned it looks suspicious maybe. But there is a trade-off here and the trade-off is false positives. If you do something unusual, let's say your company does for the first time a large streaming event. An IPS might block it because it's unusual. It hasn't seen that before. That's deviating from your normal baseline. We need to be careful around false positives. Typically with a network-based intrusion prevention system, we would run them in some monitoring mode. We would try to build a profile of acceptable traffic before running them live, before enabling the prevention capabilities. I've seen a lot of network outages caused by intrusion prevention systems blocking traffic. Things mysteriously go wrong on a network. It doesn't mean we don't use them. It means we need to tune them and support them and maintain them. It's just more of a note that we need to be cautious in how we manage them. It isn't just a box that you insert into a network and forget about. It's something that requires active management.
