[MUSIC] So jumping straight into our first chapter then incident response. So during this module we will look at some new terminology, but the concept of an incident response team at the life cycle of an incident and our response. And also how important communications are and that mention of communications is absolutely critical to incident response, business continuity and disaster recovery. So a lot of things we look at in this chapter are transferable around the principles of communicating well. And just thinking about communications, who do we need to communicate with? How do we communicate? It may not just be internal communications that we're thinking of. So let's look at what an incident is an occurrence that actually or potentially jeopardizes the confidentiality integrity or availability of an information system. The system itself or the information that the system processes the information it stores or transmits. Or something that constitutes a violation or imminent threat of violation of security policy, security procedures or acceptable use policies. I really like that definition. We can think of this as being something that adversely affects our confidentiality integrity or availability of our assets or our information assets. So let's just look at some terminology, then. The idea of a response, so here we're talking about the fact that we have had, we have potentially prepared. If we have prepared when the incident occurs now is the opportunity for us to realize that investment pays dividends. If we haven't planned. Well then we have a problem very hard to prepare when the adverse event is materializing. And this again as a theme is true of incident response, business continuity and disaster recovery. We have an opportunity to create documentation, a plan, policies, procedures, a team. We can train, we can create control sets, technical controls, physical controls, we can do all of those things before and it's an investment. Sometimes when we're doing this work and this work has a cost, it actually has a cost. If we're doing this preparation we could be doing other things that are productive. It can seem like wasted effort. Have seen some organizations resent the investment in planning for incidents business continuity, disaster recovery because the bad event may never materialize. But I would argue differently. It usually does, incidents usually we think of as being a case of when it happens rather than if it happens. And with that in mind this kind of planning this kind of preparation, this investment makes perfect sense. We have the idea of a zero day threat. Zero day threat is one that isn't registered or recognized. So we have the national vulnerability database and this assigns each threat a unique identify known as the CVE common vulnerability enumeration. It also gives it a threat score a common vulnerability scoring system, CVSS. So it tells you what the threat is, how damaging it is. And based on that information we can start as security professionals can start to plan remediation patches can be developed, anti virus signatures can be developed. With a zero day it may not be zero days old literally, but what we're referring to is the fact that it isn't formally recognized. As such we don't have the tools to detect always that something is malicious or to help remediate or to contain. So this is particularly damaging. This can cause real problems for us because of that lack of awareness. By terminology continuing we've got vulnerability, a vulnerability, some sort of weakness inherent in the system and the threat itself can exploit this weakness. Poor construction might be a vulnerability if the threat is an earthquake. So not meeting construction standards or using poor quality materials that might be a vulnerability, some kind of weakness that can be exploited. It's very easy to think of this as being a technical issue and actually we always think about both the technical world and the physical world. So vulnerability is something that can be exploited. Vulnerabilities usually over time can be remediated in that example we can use better quality construction components materials. We can meet particular standards technically we have anti viruses, patching and so on. The threat then is the thing doing the damage. It's either a threat or a threat actor, somebody with a motive, somebody kind of trying to cause some sort of disruption. We have the phrase word breach and breach is a broad term used for many types of cyber security compromises. We can breach the perimeter a physical perimeter, we can breach the network breach the logical perimeter. Commonly though, breaches we will see in the news reports as being related to a breach of information, a breach of privacy. So a breach of confidentiality but also a breach of privacy, disclosing personally identifiable information for example, PII. Who is involved then in addressing these incidents. Well, typically we would look to create an incident response team, a computer incident response team assert and this doesn't have to just deal with computers. What we're talking about is an incident response team, commonly known as a certain and most incidents as we respond to our computer basically. So it kind of makes sense, who's going to be involved then in our team? Well, let's start by saying this is not a one size fits all. It's not intended to be overly prescriptive organizations are different and so their needs will be different. But a really good starting point for a incident response team is a senior manager. Why do we need a senior manager well, the senior manager makes decisions. We need somebody who is going to be based on the recommendations from the other roles below will be able to make a decision. Has the mandate, has the ability the seniority to make that decision during an incident. We may have to allocate resources, people time to make decisions about what we're starting or stopping or indeed even incur cost, spend money and this means the senior manager is crucial. The other roles support the senior manager. So let's move on to the incident manager almost like a project manager for the incident. Somebody coordinating all of the other involvement in the incident and the incident response managing the impact. A technical lead I would say at least one technical lead. It's common to see different technical disciplines represented in an incident response team. For example, perhaps a networks lead. Somebody from the storage teams. Somebody from the service systems teams, all representing their professional disciplines and working alongside the incident manager and the other members of the team. The security team must be included. What we're talking about typically is, as we said, when we defined the incident something which can adversely affect the CDI or the A to the organization. So it makes perfect sense for the security team to be included. I mentioned the importance of communications and we'll move on to that shortly as a discrete topic as to why it's important. How important it is, this is not just about communicating internally, which is absolutely important, communicating to the board, communicating to employees. Where do they work from? Do they come into the office tomorrow? If there's been physical damage to a building for example, or during the pandemic. And then public relations, public relations slightly different more and more specific strand of communications. Looking at communicating potentially with our customers with the public people external to our organization. Do we need to communicate with our suppliers with regulators with our stockholders, shareholders or people we may want to have communications with. So I think a really important position and then legal HR, HR for the impact on people usually within our organization employees. What's the impact for them? What do we need to talk to them about? Do they need to work differently? Are there any health and safety implications for example, legal, very common to see legal involved nowadays. Because of the increase in the number of regulated industries and also regulated activities as well. Things like privacy as we touched on in our first chapter. And also because companies increasingly are crossing legal jurisdictions with globalization. We're not just operating in one territory. If we're operating in line, often we're operating across different legal boundaries. Understanding the implications of that complexity can require expertise. The incident response lifecycle is partly defined in NIST special publication, NIST special publication 800-61 and it gives us four separate phases. The initial phase is preparation. Now, this is the only opportunity we have to prepare for what's coming. And as I said, right at the start of this of this module and of the chapter can be a tough ask. Can be tough to sell this activity because it has a cost because it has an overhead to the organization can be difficult to promote it. Why are we doing this? Why are we spending all this time and energy preparing? Well, the point at which that materializes a benefit is in the second of those squares the detection and the analysis. So preparation is absolutely critical. Most organizations do not prepare enough and they recognize that only after the incident has occurred. So we prepare, we make sure we've got the team correctly structured. We've got the plan ready to go. We have the procedures. So we've got the what we're doing, how we're going to do it ideally. We test these things periodically as well. So when an incident occurs then we need to detect it in order to respond. We need to know that the incident is actually occurring, that something negative is happening. So this detection, we will look at some controls related to detection in our next chapter. But what we're trying to do is to understand a little bit about what's happening and it may inform how we invoke the plans. Some plans may be structured that there are different tiers that there are different priorities. A major incident that affects the entire organization may be treated differently to an incident that affects significant parts of the organization. So actually understanding what's happening at this stage is really important because it guides the efforts that we undertake in the next phase containment, eradication and recovery. And what we're trying to do is just with containment is to stop things getting any worse, prevent further damage. And then ideally eradicate the threat and recover back to normal operations. Post incident activity is something people frequently forget to do again. I say this from a position of personal experience, post incident activity. What happens is after the incident has been remediated. After we've recovered, everybody breathes a sigh of release relief, goes home and catches up on their sleep and moves on with their lives. What we should do is take time to understand what worked well because some things we would have done really well during the incident. You know, these parts of our plan were very good. Some things will not have gone well. Maybe we could have communicated better. Maybe our plan missed some elements, maybe we could have had better controls either way. And ideally we want to capture both what worked well and what worked less well. So we take that information and we feed it into the cycle for the next, for the next updates to our documentation, to the next cycle of preparation. So when we face another incident, we will be better prepared in terms of communications then we want somebody to represent a single voice, a single message clarity and we may need to differentiate our communications. Internal communications maybe very differently phrased to those facing externally. Internal communications can use company language that may be less understood externally can be a little bit more direct as well. External communications we may want to think more about that public relations type message, how we talk to our customers, explaining what we know the impact on them. Any supply chain and logistics issues. There's been physical damage to your site. Do you want your supplier not to deliver supplies? There's no point in delivering components if you then can't use them. Perhaps. What about your shareholders or your stockholders? Many industries are now regulated as we touched on in our first chapter. If you're in a regulated industry or you deal with regulated information for example, personally identifiable information, then you may have to talk to the regulator and there may be specific timings and forms of content required. I'm a big fan of ensuring we have regular communication. Even if there's nothing new to update. Why? Why is that? Why is that important? Well if you ever fail to communicate effectively, you create a vacuum and what happens is something typically fills the vacuum. People stop calling each other asking for updates, which creates failure demand demand. That doesn't need to exist. If you communicate effectively, People may not contact your service desk, the security team and so on. People won't fill those gaps with what they think is happening. And that sometimes happens and can be very disruptive. There's no communication. People will start to communicate independently to try and fill the void. So regular communications something like an Internet message assuming the Internet is working during the incident. An internet message every 15 minutes. Even if that message states, we still don't know anything else. We're still working on the incident. It just avoids so many problems. Communications, as I said frequently an area that we don't do well during incidents, business continuity and disaster recovery. And conceptually this is easy to get right. An incident incident response plan who is involved. Well, anybody that is needed to be involved, we want relevant equipment policies and procedures and we want training in them. And this links very clearly as we've said to business continuity and disaster recovery, we want to know when to invoke and to escalate our incident response plan. And this is typically structured in our documentation advising a really good example. Really simple example is based on impact. Something affects one team. It may be treated differently too. If it, if it impacts one department, if it affects the entire company again, it will be treated differently. It will have more of a priority. So this invocation should be documented for whoever is on call or whoever's picking this up as an issue. Bearing in mind this could be a call at three a.m. Whoever has discovered the issue needs a route to to escalate. Ultimately, though, the decisions on whether this is formally an incident are made by that senior manager and just thinking back to our team. The decision is made by the senior manager in that team. How do we get hold of them? Do we need a senior manager? Do we need a rotor for people made available out of hours? And that's a question. That's not a statement. It's a question. It depends on your organization what your organization needs. Different organizations will have different requirements. Some will need that three a.m. Response. Some will not.
