CompTIA CYSA+ CS0-002 – Incident Response Preparation Part 3

6. Reporting Requirements (OBJ 4.1)

Reporting requirements. In this lesson, we are going to talk about the different reporting requirements that you may have to face as an incident responder. Now, again, this is something we have to think about all the way back in our preparation phase to ensure we’re ready to do our reporting as required by law or regulation. Now, when we talk about reporting requirements, these are notifications that must be made to the affected parties in the event of a data breach as required by legislation or regulation. Now, there are five different types of breaches that exist and depending on the breach, there are different reporting requirements. The first one is data exfiltration.

This occurs when an attacker breaks into a system and transfers data to another system. So if an attacker has been able to get into your credit card database and take those numbers out, that would be considered a data exfiltration attempt. Now, in addition to that, we might have another type of breach which is known as insider data exfiltration. This occurs when an employee or an ex employee with privileges on the system transfers data to another system. So for example, if somebody at my office goes in and downloads files from our shared drive onto a USB thumb drive and takes it home with them and then uploads it to WikiLeaks, that would be considered an insider data exfiltration because one of our employees is doing it with their normal permissions and rights.

The third type of breach we might have can occur when we have a device theft or loss. This is when a device containing data is lost or stolen. So one of the typical examples is a smartphone. You have a smartphone that has a lot of corporate data on it, and if you leave it in the back of a taxi cab, for instance, that would be device loss. Another thing would be if you had a laptop in the back of your car and somebody broke into your car and stole that laptop. Now, this has happened numerous times to many organizations around the world and it does put your data at risk. The fourth type we have is known as an accidental data breach. Now, this occurs when there’s public disclosure of information or unauthorized transfer that’s caused by human error or a misconfiguration. Essentially, this happened because somebody made a mistake.

It wasn’t intentional. And as you can see here, as we’re moving down the scale, we’re getting less and less severe. And then finally we have integrity or availability breaches. This occurs when there’s corruption of the data or destruction of a system that processes that data. So if I had somebody who is able to modify data in a database, that would be an integrity breach. If I do a denial of service attack against your web server, that would be an availability breach. And again, as we go forward, starting with data exfiltration and then insider data exfiltration, and then device theft or loss and then accidental data breach. And finally, integrity and availability breach. We go from the most significant being data exfiltration because an attacker broke into our systems all the way down to the least, which is integrity or availability breaches that usually occurs when something other than confidentiality is being breached, which means it’s data integrity or availability that’s being affected.

Now, depending on the type of breach you have, there’s going to be different laws and regulations that govern your requirements for reporting. These requirements are going to tell you what you have to report and in what time frame you have to report and to who you have to report these things to. For example, if you have a HIPAA issue, which would be something that has to deal with Phi or protected health information, you would have to actually report that.Now, HIPAA is a law inside the United States, and so if you have a data breach affecting this type of data, you are going to be required to notify the affected individuals, the Secretary of Health and Human Services, and the media if there’s over 500 people affected by that data breach.

Now, another example of a regulatory requirement for reporting would be under GDPR, which is the General Data Protection Regulation. This applies inside the European Union. Now, with GDPR, this is going to require notification within 72 hours of becoming aware of the breach of personal data. You need to notify the person as well as the GDPR regulators, which is the European Union. Now, the final thing we want to talk about is disclosure, and this is something that has to do with how are you going to tell the person affected. If we think back to Yahoo. Yahoo. Has had a number of data breaches over the last decade. Now, if you’re like most people, you’ve probably received at some point in your life one of these notices from Yahoo.

This is because yahoo. Has had the information of over 1 billion people breached over the last decade. Now, disclosure here would be when they tell you that this has happened, they’re going to say, Dear User, we want to let you know about the security issue. We had some bad things happen. Here’s what they were, and here’s what we’re doing about it. Essentially, the disclosure is going to have key information, like a description of what information was breached, the details of who the main point of contact is, if you have any questions, and any likely consequences arising from that breach, as well as measures that were taken to mitigate that breach. All of this is the information that would be disclosed to the person who was affected and had their data lost or data stolen.

7. Response Coordination (OBJ 4.1)

Response coordination. Now in preparation. One of the other things we have to think about is how we’re going to coordinate our response, because an instant response is going to require coordination between different internal departments and external agencies. Let me give you a quick example of this. Just recently, in the last couple of weeks, twitter had a massive breach to their security. Now, due to the massive breach, lots of high profile accounts started tweeting out messages asking for bitcoin. We started seeing this from companies like Apple, and we saw it from Jeff Bezos, which is one of the richest people in the world. We saw it from Barack Obama, the former President of the United States. We also saw it from Kanye West, one of the big music stars. And we saw it from Joe Biden, a presidential candidate, as well as Warren Buffett, another large investor in the world, and even Elon Musk. And all of these were high profile accounts that were hacked as part of this breach.

Now, when this happened, Twitter immediately locked down those accounts so the attackers couldn’t use them anymore. And then they started working with external agencies such as the FBI to come help them figure out what was going on. And within two weeks, they had the suspect in custody at the FBI and started to figure out exactly what happened as part of this instant response. Now, in this case, this was a big event and it became very newsworthy. But this kind of thing does happen a lot in the industry, where you’re going to be working with both internal and external players to work on your instant response. And when you do that, you have to coordinate that. Now, one of the questions you have to ask yourself is who are the affected stakeholders? In the case of Twitter, the FBI got involved because this was a major attack against all these high profile accounts.

Two of those accounts I just showed you were President Barack Obama and presidential candidate Joe Biden. And that’s a real good reason for the FBI to get involved pretty quickly here. But when you have an incident, you need to start thinking about who are the effective stakeholders. There are lots of them out there, inside and outside your organization. For instance, you might have senior leadership that gets involved. You might have regulatory bodies. You might have your internal legal counsel or external law enforcement. It might be your internal human resources or your internal public relations. And externally with the media, all of these are people who are valid stakeholders when you have an incident and you have to consider how does this incident affect them and how are you going to coordinate your response? Let’s go ahead and look at each of these.

First, we have senior leadership. When we talk about senior leadership, this is the executives and managers who are responsible for business operations and various functional areas within your company. Now, the reason this is important is because a lot of our incident responders tend to be technical people. And so we might, as technical people, say the quickest way to solve this incident is to shut down that server. But if we’re not understanding the business impact of those actions, that could have second and third order effects that would be very bad for our organization. So we’re going to have to get senior leadership involved to understand if I do this, it’s going to have this and that and the other effect, and we have to mitigate those.

For example, if your credit card processing system has been compromised, if you immediately shut it down, you are cutting off your ability to process new transactions. Now that might be the right answer technically, but from a business standpoint, that could actually hurt you even worse. And so you have to start weighing these factors and working across the organization to make sure you have another way to accept payments before shutting down that credit card system. Or maybe you’re going to make the decision that it’s okay to shut down that system, but you understand you’re going to be giving up the ability to process credit cards. Right now that is a business decision, not a technical decision. And so it is one that you have to have senior leadership’s buy in on.

The next key stakeholder we have to consider is regulatory bodies. These are governmental organizations that oversee the compliance with specific regulations and laws. For example, if we’re talking about HIPAA, which has to do with health care, you’re going to have to be overseen by Health and Human Services because they are the ones who run the HIPAA program. If you’re dealing with something like the California Consumer Privacy Act or CCPA, you’re going to be dealing with the state of California. If you’re dealing with something like credit card data, you’re going to be dealing with PCI DSS and those people who run that program, again, these are the different regulatory bodies you’re going to have to consider.

Now a quick note. When you’re dealing with PCI DSS, they’re not technically a regulatory body from a legal standpoint, but they do oversee all of the payment card systems. Now generally when we talk about the term regulatory, we are talking about legal. And with PCI DSS, it is not a legal requirement. It is a contractual requirement between you and your payment processor. The next stakeholder we have to consider is legal. Now legal is the business or organization’s legal counsel and they’re going to be responsible for mitigating risk from civil lawsuits. For example, as you’re planning out your response of what you’re going to do to stop the breach of data, you want to make sure legal is in the room because your actions could come up later on if your company is sued for its response.

And so you want to make sure they’re in the room and they understand what you’re doing and they have input into it. On the other side of the coin, we have law enforcement. And law enforcement is an external stakeholder. They may provide services to assisting your incident handling efforts or to prepare for legal action against the attacker in the future. Just like I was talking about earlier with Twitter, they brought the FBI in because they wanted to pursue legal action against that attacker. And the FBI was able to bring in additional services to help them in that incident response to be able to deal with it much quicker. Now, one quick thing to note. Your decision to involve law enforcement has to be made by senior executives with guidance from your internal legal counsel.

You as an incident responder should not immediately pick up the phone and call the FBI or the local police. This is something your business has to decide. Now, there are cases where it is legally required to bring in law enforcement, but in a lot of cases, it is more of a civil issue and you have the determination and the right to decide if you want to press charges and bring in law enforcement. So keep that in mind, and remember, your senior executives get to make that decision. Our next stakeholder is human Resources, and this is an internal stakeholder. They’re going to be used to ensure there’s no breaches of employment law or employee contracts during the incident response.

For example, if you’re suspecting that there’s an internal threat and you want to start questioning employees or you want to start going through employee files, you’re going to have to consult human resources because you could be breaching employment law or employee contracts. So make sure you involve human resources. And our final stakeholder we want to consult is Public Relations or PR. Public relations is used to manage the negative publicity from a serious incident. Now, this is important because you want to make sure as the technical lead, as an incident responder, you’re not the one answering questions to the media. You don’t want to be the one up there behind all those microphones with a sea of reporters asking you questions.

You have people in your organization whose job it is to handle that, and they are going to come up with a clear, concise message that can be said over and over again to all the inquiries reporters have. This way, you’re on brand and on message across the organization. Remember, public relations needs to be involved, especially with larger breaches that may get the interest of media and the press. Now, as part of the CSIRC team, it’s going to be your role to help provide information to the stakeholders. As part of the C cert, you’re going to be asked for information regarding the estimated downtime, the scope of the systems and data affected, and other relevant details. And by having that information and providing that up to the appropriate senior leadership, human resources, legal public relations and others. It’s going to make sure that we all are providing a consistent message and that we are coordinating our response efforts.

8. Training and Testing (OBJ 4.2)

Training and testing. The last thing we have to focus on in our preparation is training and testing. And there is a difference between those two things. First, let’s talk about training. Training is education to ensure employees and staff understand your processes, procedures and priorities during an instant response. By conducting training, you’re going to make sure that your people are ready to respond when something bad happens. Training should be provided to all employees with a relevant perspective and focus based on their needs because not everyone is going to get the same training. For example, if you’re a responder, you need training in a technical capacity.

What are the procedures you’re going to follow? How do you reimage a machine? How do you remove malware? How do you change configuration settings? All of that stuff is part of your responding training. Now, if you’re a manager or an executive, you’re going to have different training requirements. You’re going to be focused more on risk versus reward. You’re going to be focused more on managerial decision making and communication across the organization and outside the organization, with law enforcement and the media as well. And finally, we have our end users. And our end users need to be trained as well. They need to be trained on the way to report if they suspect an incident is occurring.

For instance, as an end user, if I open up my email and I see a phishing campaign, how do I report that to the service desk? If I went and clicked on one of those links, I’m going to need remedial training to know how to identify that in the future and make sure I don’t fall for that. Again, this is the idea of your end user training. They need training on how to be a better user and how to prevent incidents from occurring in the first place. Now, when you’re providing training, one of the things you want to make sure you’re capturing is lessons learned from previous incidents. And you want to bring those back up during training because when you have a lessons learned, that means it’s something that went wrong in the past.

And how we can do it better in the future is by training people on those lessons learned. If we just write down those lessons learned and nobody reads it again and nobody gets training on it, then we’re going to be doomed to repeat those things. And so we want to make sure we’re preventing that. Remember, when you’re doing training, it’s not just about technical skill here. You also need to include soft skills and relationship building within your teams because that is important as well if you want a high functioning C cert. Next, let’s talk about testing. Now, testing is the practical exercising of incident response procedures. With training, we’re going to teach you what to do in testing.

We’re going to make sure you know how to do it. Now, when we’re dealing with testing, we’ll often conduct a test to simulate a significant incident. Now, the challenge with this is doing this is very costly and it can be a complex event. For example, I’ve been involved with a lot of testing over the years. One such test was a full scale exercise that showed exactly what we would do in the event that we had a large scale data breach. Now, this went across multiple sites around the world, and it cost us hundreds of thousands of dollars to do, but it made sure everyone knew what they were doing and that we could actually go through those actions and get a bad guy out of our systems. Now, when you’re designing your test, you can do it in one of two major ways. The first is a tabletop and the second is a penetration test. Let’s talk about both of these.

When we’re dealing with a tabletop exercise or a TTX, this is an exercise that uses an instant response scenario against a framework of controls or a red team. Now, the reason we call it a tabletop exercise is because we’re doing it on a tabletop and we’re not physically doing it in our networks. In a tabletop, we might gather experts around the table and we’ll start presenting scenarios. For instance, if I was leading the tabletop, we could say, you have an indication of a data breach. It’s occurring on this database server. What do you do? And then the defenders would start saying what they’re going to do, and they would each take turns, almost like they’re role playing what they would do in the case of this particular scenario as they work through that event.

Now, the benefit of doing a tabletop is it’s a lot less expensive than a full blown exercise, but there are some negatives to it in the fact that you can’t get this handson experience because you’re not physically doing the things on the keyboard and making actions happen on the network. So it’s really more of a theoretical exercise here. Now, another way you can do this is you can break people up into red teams and blue teams. Now the red teams are the attackers and the blue teams are the defenders. And so you can actually take turn and say, okay, here’s the scenario. Blue team, this is what you detect. What do you do? And then based on what they say, the red team then says, okay, we would then do X, Y and Z. And then the blue team would say, well, then we would see this and respond in A, B and C.

And they’ll go back and forth through several rounds to hit and attack and defend and go back and forth until we can see what the effects are. The benefits of doing it as a red team versus blue team type scenario is that you’re going to get live people thinking through both the attacker side and the defender side to help you come up with a better solution and how you can figure out better controls to protect your network. Now another way you can do this is by actually getting people on the network and this is done through a penetration test. Now a penetration test occurs when a red team attempts to conduct an intrusion onto the network using a specific scenario based on threat modeling. Now, this is an important concept here when we’re talking about penetration testing because we’re not just doing something against the network to see what we can do to get in.

We have a specific goal in mind. So if my goal is to go after the database server, I’m not going to throw a distributed denial of service attack at you. That wouldn’t be a valid pen test. So instead we have a specific scenario based on threat modeling, meaning we know what a regular adversary would do and we’re going to base our actions on that. Now, when you’re dealing with a penetration test, you always have to agree on a clear methodology and rules of engagement before that penetration test is performed. This is critically important because there are rules to these things. Like I said, I’m not just going to throw a distributed denial of service attack at you because that would probably be against the rules of engagement. Now, if they’re in my rules of engagement then that would be fair game.

But in most cases that’s not going to be in there. Now, penetration testing is covered in much more depth if you take the CompTIA pen test plus exam. The reason for this is that certification is all about red teaming. It is all about being a penetration tester. Whereas here in CISA we are more focused on defense. But as a defender you should be familiar with at least a couple of tools that are used by pen testers. Some of the most common ones you’re going to see are things like Metasploit, Cobalt, Strike, Kali, Linux, parrot OS and Commando OS. As the defender. If you ever see these tools or operating systems on your network, you should be thinking about the fact that they are penetration testing tools which could be used as part of a penetration test or even worse by an attacker because most of these are open source tools that anyone can download and use.