Let's move forward then and just remind ourselves of controls and also why asset management is important when we think about controls. During this module, we want to look at some common types of threats, how we identify threats and also at preventing threats. In order to manage our assets appropriately, we need to know what assets we have. Hardware, software and information. Information can be held by people, could be our configurations, could be our intellectual property. Lots of different ideas, types of information that we may not immediately have recorded. Most organizations have a hardware asset inventory. Not so many have an information asset inventory and to manage compliance, as we talked about in Module 1, it's important that we know what we have and what the regulatory requirements around those things are. What should we record? Well, it depends, and this is very much a judgment per organization. We need to decide what it is we're going to record. We want to make sure that we document data about our data. Metadata is data about data. What could be included within metadata? Well, maybe file permissions, maybe some information about the retention schedule, maybe the asset owner, who's going to be managing this asset for us within our organization. Within most companies, you have structured and unstructured data. Structured data is far easier to manage. Databases structured in tables with rows and columns. Document management systems, documents that are checked in with a date with an owner. This structured approach generates metadata for us when it was last used, who changed it? Far easier for us to manage. Unstructured data assets, while these are a little bit more chaotic. You'll see this if you've ever used a shared drive. Some of the documents and the labeling may be unclear. Documents that aren't owned anymore. Somebody leaves an organization there are documents that exists, even though they have left the organization a number of years ago. Data that's not needed anymore, but nobody knows who should delete it or when it should be deleted. Email inboxes, things that contain a mix of maybe retention, things we must protect for a minimum period and the regulatory requirements, things that we must dispose off. If you think of a shared drive or an email inbox containing a mix of those two types, things we must not keep things, we must keep, compliance with an unstructured data set can be very difficult to manage. If you've got one inbox with a huge number of records related to things that must be kept must not be kept, how long do you keep that mailbox for? The correct approach is to do what we do in our homes. Throughout the course, I've referenced what we do in our homes. Let me do it again with unstructured data assets. Just think about you getting some mail. Somebody posts envelopes, through your letterbox, mailbox. You don't leave them there. What I do if it's maybe a bill, I take it, I process it, I do something with it and I could file it for record or I throw it away. I delete it if it has no purpose. Some things, letters from friends or family, I want to keep. I archive them. I don't leave them in the mailbox. Good practice is really not to use the mailbox as a form of archive to actually structure, to put our data where it belongs. Those things that need protecting, putting them in the right place. This links fairly closely. This idea of information and assets generally links to change management. How do we manage changes to our assets? Do we want to manage changes to our assets? Well, tracking change enables us to detect patterns. It also helps to enforce accountability. If in a production environment and operations environments we apply five patches on Monday morning and the system goes down, which one of those patches caused the problem? Change management can help address that question but also who deleted what, who changed what, can help create visibility of some assets. This can really help operational environments. I'm a big advocate of implementing change management correctly. We want to make sure that we track changes to those things that are important, in order to make sure that we understand what changes they've been subject to. We know what's happened to them. Then it might help us correct errors, might help us detect a problem. Change management, very important to maintaining a good firm operational environment and links very well to updates. Very few of our systems never have an update. Software typically isn't bug-free when it's released. We have individual pieces of software that are updated, but also interdependent systems. If you have a web app that is secure, that web app is secure in its own right but to remain secure, the underlying systems need to be secure as well. If your web server hosting the web app is not secure even though the web app itself may be secure the web server may create a vulnerability that could undermine the web app. Same is true for the operating system and the hardware. This interdependence is important conceptually what do we need to be patching and updating what all of those things in the stack. In addition to that, some things that might be outside of our direct control if you are producing an online set of web services as a retailer, what about the services that your clients use? The client web browser is that secure? Because if not, the security of your systems may be compromised. We started to think increasingly about third party systems and supply chain security. There have been a number of issues. Products like solar-winds, which were downloaded by customers and ultimately were found to contain malware. The supply chain compromised customer networks. In December of 2021, we saw the log for j issue. A library, a component used by developers, had a security vulnerability. If you use that library, you inherited the vulnerability. The challenge for a lot of operational environments was finding out which one of your products contain that library, and it's not immediately obvious. That covered things like games, Minecraft, for example, through to a web services, whole range of different things affected by a component that had a security issue. Patching, and updates, we also need to consider visibility. Some things very visible. If you think about your desktops, laptops, servers, those are the obvious things to patch. Most organizations don't update those well enough. Those are the obvious things. What about some of the less obvious systems? Embedded systems, Internet of Things devices. There's a case in Las Vegas of a casino having security compromised because of a thermostat in a fish tank. Again, very low visibility. In order to make our controls practical in terms of being implemented in a way that is useful, we had 5,000 laptops, 500 servers creating a control step for each of those devices might be difficult. By grouping them together into types of device, into groups of classifications, we can actually start to apply controls themselves in groups or patterns. We could say we have a group of controls that we can apply to low security laptops. We can have a different group of controls that we apply to high security laptops. That grouping really helps us manage compliance. Without that controls and managing controls might be difficult practically. This gives us improved ability to comply with requirements and also a better awareness of what we have in place, what we're protecting, and how we're protecting it. These we call baseline. A baseline is a group of controls grouped together based on a classification or an architecture, a type of assets. The baselines themselves, can be based against our classification system. Let's just take a look at what this looks like practically; far easier to see when we have this visualized. Here, we have some information assets. What we're doing is grouping our controls together against a classification system of high, medium, and low. The types of controls we have are listed on the left. We have access based controls, encryption based controls, labeling based controls, and monitoring based controls. For low classification items then. Here for access, the asset owner, the asset owner should always approve access. That's a pretty much a minimum. We say that is the control for low classification assets. Encryption, there is no encryption at rest or in transit for low classification assets. There is no labeling, there is no monitoring. As we move up to medium, now we see for access, we have an additional requirement of passwords being required. Here in transit in transmission, some encryption that's required. Monitoring is timely, that's quite a vague statement. I'd like something more precise there, but you see the idea that there is some requirement. Then for high classification assets, not just passwords but strong passwords, a non-disclosure agreement, encryption now not to drink transmission but during storage, and that labeling is now watermarked. This represents an agreed set of controls grouped together by classification. It is a minimum set of requirements. When implementing this, we could do more, but we cannot do less. We can group these remember, based on different architecture types. We can have a classification baselines for firewalls for pretty much anything. This is what makes the practical elements around controls manageable for us.