WEBVTT 00:07.340 --> 00:11.990 There comes a time in every analyst's life where they really go through the process of figuring out 00:11.990 --> 00:14.120 all the malware that's infected their systems. 00:14.120 --> 00:19.130 They've just completed an incident, and they go through the process and they're left with the final 00:19.130 --> 00:19.790 aspect. 00:19.820 --> 00:22.010 That's right, documentation and reporting. 00:22.010 --> 00:23.630 It's our favorite thing in the world to do. 00:23.630 --> 00:25.250 And we're going to discuss it today. 00:25.280 --> 00:28.970 In this episode we're going to talk about different reportings different stakeholders that you need 00:28.970 --> 00:33.890 to be affected by that our after action review and finally the formal reporting process. 00:33.920 --> 00:37.490 Throughout this episode, we're going to go through and really dissect the different issues that may 00:37.520 --> 00:39.770 be affecting you on a reporting side. 00:39.800 --> 00:46.130 Now, Cisa only requires the fact that you understand it from a high level and able to identify stakeholders 00:46.130 --> 00:51.950 and the after action review process, as well as what's inside a formal review or formal reporting process. 00:51.950 --> 00:56.870 They're really not going to go that much into depth with it, but you need to understand the basic foundations 00:56.870 --> 00:57.860 of what's going on. 00:57.860 --> 01:02.190 And that's what we're going to discuss Discussed today, the very first thing that you need to do as 01:02.190 --> 01:03.210 a cybersecurity analyst. 01:03.240 --> 01:08.070 Throughout your reporting process is to understand who your primary and secondary stakeholders are. 01:08.100 --> 01:12.570 Primary stakeholders are directly affected by the incident or by the malware. 01:12.570 --> 01:17.940 In this case, it would be leadership and employees or even specific departments within your organization. 01:17.940 --> 01:22.260 If you've got an incident that's affecting, say, the HR department, then obviously you need to let 01:22.260 --> 01:27.030 the HR department know, because we may be taking their systems or their clients or even file servers 01:27.030 --> 01:27.810 offline. 01:27.810 --> 01:33.000 They may lose access to their internet, they may lose access to their specific servers, and it could 01:33.000 --> 01:36.060 be directly affecting how they are able to approach their work. 01:36.060 --> 01:38.640 In that case, we need to let them know what's going on. 01:38.670 --> 01:41.070 Those would be attributed to our primary stakeholders. 01:41.070 --> 01:43.770 Secondary stakeholders are indirectly affected. 01:43.770 --> 01:49.200 This could be third party vendors, maybe your legal or human resources department, even your operations 01:49.200 --> 01:49.860 department. 01:49.860 --> 01:53.760 They need to be notified, but they're not considered primary stakeholders because they don't need to 01:53.790 --> 01:55.140 be notified immediately. 01:55.140 --> 01:58.790 They're more after the fact, after the fact actions. 01:59.060 --> 02:04.250 Once we've identified those primary stakeholders, we need to identify what the impact of the systems 02:04.250 --> 02:04.850 is. 02:04.880 --> 02:09.590 After all, even though we've identified the stakeholders, we need to have some information in order 02:09.590 --> 02:10.760 to relay back to them. 02:10.790 --> 02:14.720 Otherwise, we're going to get questions like, oh, well, when's it's going to get fixed? 02:14.750 --> 02:16.160 How impactful is it? 02:16.190 --> 02:17.840 What is it doing to my systems? 02:17.870 --> 02:23.510 All of those items need to be addressed when we communicate clearly to those primary and secondary stakeholders, 02:23.510 --> 02:25.520 what's going on with their different systems? 02:25.550 --> 02:31.490 When speaking about impact, we need to identify very clearly what's impacted by the incident and how 02:31.490 --> 02:32.420 it moves forward. 02:32.450 --> 02:34.130 This could be an entire department. 02:34.130 --> 02:35.510 It could be a single machine. 02:35.510 --> 02:36.860 It could be a single server. 02:36.860 --> 02:37.700 It doesn't matter. 02:37.700 --> 02:39.860 But the impact needs to be clearly identified. 02:39.860 --> 02:41.750 Is it a business critical asset? 02:41.780 --> 02:45.440 If so, what other secondary assets is it affecting? 02:45.470 --> 02:51.650 If it's a server, what all is impacted by the server being provided by that incident and that aspect? 02:51.650 --> 02:54.410 We need the information to be both timely and accurate. 02:54.440 --> 02:59.110 The worst thing we can do as a cybersecurity professional professionals say the server is being impacted. 02:59.140 --> 03:00.580 We don't know how. 03:00.640 --> 03:03.580 And we're letting you know 15 minutes after we already found out. 03:03.580 --> 03:06.940 Sometimes timeliness and accuracy don't always mesh up. 03:06.970 --> 03:11.650 And sometimes we have to decide, do I want to let them know now with a little bit of information, 03:11.650 --> 03:13.900 or later with more accurate information? 03:13.900 --> 03:19.210 If you call up to your immediate supervisor and the stakeholders and say, hey, the server is being 03:19.240 --> 03:24.970 affected by a piece of malware or a virus, we don't know the full extent of the impact. 03:24.970 --> 03:26.200 That's perfectly fine. 03:26.200 --> 03:31.150 We have provided timely information and while it may not be accurate, we let them know what's going 03:31.150 --> 03:34.210 on further down the line, maybe 15 20 minutes down. 03:34.210 --> 03:35.860 We've done a little bit of investigation. 03:35.860 --> 03:39.910 While it may not be as timely, we are now providing that more accurate leverage to it. 03:39.940 --> 03:45.400 We're saying, yes, I know it took 15 minutes, but now we know it's affecting this file system structure 03:45.400 --> 03:48.790 or this aspect of our servers, and we need to take the server offline. 03:48.790 --> 03:50.470 We're providing more information. 03:50.470 --> 03:55.990 Remember, our goal is to be timely and accurate with our impact statements when we're addressing incidents 03:55.990 --> 03:57.850 within our environment sometimes. 03:57.880 --> 04:03.850 Again, the timeliness isn't persuaded, and we have that flow of what's timely versus accurate. 04:03.850 --> 04:06.130 The more time it takes, the more accurate it is. 04:06.160 --> 04:07.240 And that's okay. 04:07.240 --> 04:09.910 We just need to be aware of that throughout our monitoring. 04:09.940 --> 04:10.750 Updating status. 04:10.780 --> 04:14.890 We're talking about monitoring what's going on inside of our network and how that applies to updating 04:14.890 --> 04:15.850 our stakeholders. 04:15.850 --> 04:19.390 We also have expected recommendations throughout this process. 04:19.390 --> 04:24.400 We need to have recommendations that we can provide towards our primary stakeholders as well as our 04:24.400 --> 04:25.600 immediate supervisors. 04:25.630 --> 04:27.880 Things like expected time to remediation. 04:27.880 --> 04:30.730 How long is it going to take for me to resolve this issue? 04:30.760 --> 04:36.430 Now, again, it doesn't have to be completely 100% accurate, but we usually know within 10 to 15 minutes 04:36.430 --> 04:41.710 how long an incident is going to take in order to be reconciled. 04:41.710 --> 04:43.570 That could be 15 minutes to an hour. 04:43.570 --> 04:47.950 I recommend going with an hour and a half hour increments as you're going through this, so that you 04:47.950 --> 04:49.840 can tell somebody, yes, we have something. 04:49.840 --> 04:51.490 We know the impact is this server. 04:51.490 --> 04:57.410 We know that it's affecting these clients and our expected time to remediation is an hour to 90 minutes. 04:57.440 --> 05:00.110 That gives us a nice little window to work within. 05:00.110 --> 05:01.820 If we're done before, then awesome. 05:01.820 --> 05:05.720 If it's going to take more time, we need to let them know before the hour mark is up. 05:05.720 --> 05:09.740 If we know that it's not going to be fixed within 90 minutes, we don't want to come back out at the 05:09.740 --> 05:15.200 95 minute mark and tell them, oh well, yeah, we knew it was probably going to be fixed by 90 minutes, 05:15.200 --> 05:16.760 but it's going to take another 90 minutes. 05:16.760 --> 05:18.380 That's the wrong way to go about it. 05:18.380 --> 05:23.810 The better way is to say at the hour mark, when we expected the lower end of our estimation to go through, 05:23.840 --> 05:26.660 we come back and say we took longer than expected. 05:26.690 --> 05:30.110 Our new estimated time to remediation is this time to this time. 05:30.110 --> 05:35.150 Maybe it's 2 hours to 3 hours now, and we're providing specific times that associate to a clock. 05:35.150 --> 05:38.750 We're not saying 90 minutes, we're saying 230 to 3:00 pm. 05:38.780 --> 05:41.120 After that we want to talk about the process. 05:41.120 --> 05:45.560 Now, we don't want to go into our primary stakeholders, say the organization as a whole, and say, 05:45.590 --> 05:51.110 oh, I wanted to go through our process and we're going to investigate the IDs, and then we're going 05:51.110 --> 05:54.440 to go through the IPS, and then we're going to go through the through the router and the switch and 05:54.440 --> 05:55.610 you get the point right. 05:55.610 --> 05:59.090 We don't want to provide that process to somebody that really doesn't know what we're doing. 05:59.090 --> 06:03.860 However, if we're reporting back to our manager or senior managers, maybe that process is important. 06:03.860 --> 06:09.500 We want to go through and say, yes, I have to investigate not only the switch, but I have to investigate 06:09.500 --> 06:10.340 the IDs. 06:10.370 --> 06:14.540 I have to investigate the IPS, and we want to provide them the process as we're going through. 06:14.570 --> 06:16.040 It doesn't need to be detailed. 06:16.040 --> 06:18.530 We don't need to tell them we're diving into the router. 06:18.530 --> 06:20.090 We have to reconfigure the entire thing. 06:20.090 --> 06:21.230 And that's going to take 30 minutes. 06:21.230 --> 06:22.160 And then I have to go through this. 06:22.190 --> 06:23.870 And that's not what we're talking about. 06:23.900 --> 06:27.980 What we're talking about is a very high level overview of the different systems that you're touching 06:27.980 --> 06:31.250 in order to remediate the problem or the incident that's occurring. 06:31.250 --> 06:32.990 It doesn't need to be deep dive. 06:33.020 --> 06:37.190 It just needs to be a 32nd review of what you plan on touching along the way. 06:37.190 --> 06:38.600 This provides two things. 06:38.600 --> 06:40.970 One, it tells the managers what route we're taking. 06:40.970 --> 06:44.420 And so they have a warm fuzzy about how we're proceeding with the investigation. 06:44.450 --> 06:49.250 A lot of times those managers, especially your first line manager, has a technical background and 06:49.250 --> 06:53.160 they may be able to provide an input or maybe even know the network and provide suggestions on how to 06:53.190 --> 06:55.470 investigate the incident further down the road. 06:55.500 --> 07:00.030 This provides you a speedier recovery and it provides some mentorship from higher level management. 07:00.060 --> 07:04.590 The second reason is because as you're going through that process, if you say, hey, I have to go 07:04.590 --> 07:09.060 through the IPS or I have to go through a specific switch, there is a chance that switch could go down. 07:09.060 --> 07:13.650 You're letting your manager know that if something else drops off along the way, that it was expected, 07:13.650 --> 07:18.270 and then they can handle the public relations between the incidents and the different department of 07:18.270 --> 07:19.770 what's going on and what's being affected. 07:19.770 --> 07:21.420 That's their job as a manager. 07:21.420 --> 07:25.620 Your job as an analyst is to remediate the incident as quick as possible. 07:25.650 --> 07:29.790 Now, that doesn't mean you can just start sweeping switches offline and just take the entire network, 07:29.790 --> 07:34.230 but it does provide a little bit of cushion for your manager to be able to report to their senior managers 07:34.260 --> 07:36.660 exactly what's going on and take the heat off of you. 07:36.690 --> 07:42.210 Remember, a good manager is one that separates you from the technician, or from the analyst from the 07:42.210 --> 07:46.680 rest of the managers, and serve as a filter or a roadblock so that people aren't bothering you as you're 07:46.680 --> 07:47.490 doing your work. 07:47.490 --> 07:48.780 That's their job. 07:49.050 --> 07:51.120 Once the remediation has taken effect. 07:51.150 --> 07:52.920 We're looking at after action review. 07:52.950 --> 07:57.510 This usually occurs with everybody that was involved within the actual remediation process. 07:57.540 --> 08:00.870 Obviously we're not bringing HR people into an after action review. 08:00.900 --> 08:02.370 They don't understand the systems. 08:02.370 --> 08:03.750 They don't understand what's going on. 08:03.750 --> 08:07.290 And they're really not going to provide some really valuable input to what's going on. 08:07.290 --> 08:12.030 But maybe you worked with a with a coworker on it, maybe you had different partners and even reached 08:12.030 --> 08:16.080 out to a third party vendor for extra support on the incident and how it was occurring. 08:16.080 --> 08:20.160 And this aspect we would want to provide everybody that talked to those third party vendors and all 08:20.190 --> 08:23.880 of our employees that touched this incident, to get a feeling of what's going on. 08:23.880 --> 08:25.800 Maybe they can provide some valuable insight. 08:25.830 --> 08:30.510 Maybe it started with the IT team, and we provide a leverage for the IT team to come in and provide 08:30.510 --> 08:34.380 their input so that we have a better understanding of how, not only how that incident occurred within 08:34.380 --> 08:37.260 our network, but the remediation process as a whole. 08:37.260 --> 08:42.330 Within this lesson learned process, we're really looking to streamline and provide some effective learning. 08:42.330 --> 08:46.830 And what happened with the incident and how we can move forward to be more effective at our jobs moving 08:46.830 --> 08:47.580 forward. 08:47.670 --> 08:49.640 Once we've identified the lessons learned. 08:49.640 --> 08:52.100 We're going to go through the recommendations for changes now. 08:52.100 --> 08:55.460 Recommendations for changes can come from anybody within the process. 08:55.460 --> 09:00.380 Maybe somebody that's listening in to the process or the lessons learned had a good idea. 09:00.380 --> 09:02.840 And we want to provide that recommendation for change. 09:02.840 --> 09:07.940 This could be something as simple as 5% of our traffic is going through this port, and 85% is going 09:07.940 --> 09:09.740 through this other port or protocol. 09:09.740 --> 09:14.510 Maybe we can move that traffic off of that port, shut that down, and move that port over to this over 09:14.510 --> 09:17.630 protocol so that we can more streamline effective traffic. 09:17.660 --> 09:19.550 Maybe it means updating the IPS. 09:19.550 --> 09:25.070 Maybe it means taking a legacy system offline because it affected the change or the incident from the 09:25.100 --> 09:25.730 get go. 09:25.730 --> 09:28.910 And we want to go through a different system that's more up to date. 09:28.910 --> 09:33.230 Whatever the problem is or whatever the change is, we need to provide that recommendation for change 09:33.230 --> 09:37.760 to our senior managers so that they can move that change forward and hopefully get that process changed 09:37.760 --> 09:38.960 within our own environment. 09:38.960 --> 09:42.170 This is all part of that after action review that we've talked about. 09:42.290 --> 09:47.780 Finally, the formal reporting process comes into play after the after action review, after the process, 09:47.790 --> 09:51.060 After everything that's occurred, we want to go through a formal reporting structure. 09:51.060 --> 09:55.290 Within the formal reporting structure, we're going to provide some key elements or statistics throughout 09:55.290 --> 09:56.010 the report. 09:56.010 --> 09:58.140 The first one we're to provide is alert volume. 09:58.140 --> 10:02.760 The reason that we mention alert volume is because we want to know, or we want senior managers to know 10:02.760 --> 10:05.100 how much we're dealing with on a day to day basis. 10:05.100 --> 10:10.890 If you're seeing 10,000 alerts per day, per hour, that's important thing for senior managers to know 10:10.890 --> 10:13.260 so that they get a taste of where we're coming from. 10:13.260 --> 10:18.240 This could offset the fact that maybe our detection time or response time wasn't exactly what we would 10:18.240 --> 10:19.170 like to see. 10:19.350 --> 10:25.050 In other cases, it could provide additional leverage for our manager to maybe get some more technology 10:25.050 --> 10:28.560 or more budget to hire more personnel into our department. 10:28.560 --> 10:31.140 Whatever the reason, we want to provide that alert volume. 10:31.140 --> 10:34.950 And how many of that specific alert led to that incident from occurring? 10:34.950 --> 10:37.380 This could also point out to our detection time. 10:37.410 --> 10:42.360 Our mean time to detection is how long we put eyes on the alert from occurring from the first point. 10:42.390 --> 10:46.620 Now, sometimes our incident doesn't actually produce an alert, but we found it through other means 10:46.630 --> 10:48.490 that needs to be dictated as well. 10:48.520 --> 10:53.230 Our mean time to detect, literally, is the average time that it takes to detect an incident like this 10:53.230 --> 10:55.180 from occurring within our own network. 10:55.210 --> 11:00.370 We also want to provide the actual time to detect if our mean time to detection is 15 minutes. 11:00.400 --> 11:03.550 That's where somebody puts their eyes on it versus the actual time. 11:03.550 --> 11:05.800 Detection in this case may have been 17 minutes. 11:05.800 --> 11:09.820 There's a little bit of stuff in there and we need to identify why that occurred. 11:09.880 --> 11:12.310 It may be within the average and that's okay. 11:12.340 --> 11:17.200 However, let's talk about maybe our actual time detection was 25 minutes versus a mean time of 15. 11:17.230 --> 11:22.600 We need to provide input and figure out what occurred in our after action review of why it took so long. 11:22.630 --> 11:23.890 It could also be better. 11:23.890 --> 11:25.030 Maybe it's only ten minutes. 11:25.030 --> 11:27.700 This shows improvement to detecting this type of problem. 11:27.700 --> 11:31.240 Maybe we've seen problems in the past and we're actually improving on this course of action. 11:31.270 --> 11:35.320 Regardless, we want to provide both the meantime detection and the actual time detection within our 11:35.320 --> 11:36.190 formal report. 11:36.220 --> 11:37.900 There's also the mean time to respond. 11:37.930 --> 11:41.530 This is how long it took for somebody to actually start working on this now. 11:41.560 --> 11:43.180 Don't confuse this with detection time. 11:43.180 --> 11:48.170 We could have a team that is fully responsible for detecting problems and then shifting those tickets 11:48.170 --> 11:50.480 up to analysts that are actually responding to it. 11:50.480 --> 11:53.360 This can sometimes be as long as two days or even a week. 11:53.360 --> 11:55.100 In some cases it could be five minutes. 11:55.100 --> 11:59.780 Whatever the mean time to respond is we want to annotate that within our report versus the actual time 11:59.780 --> 12:04.940 to respond again, to provide our manager with some leverage for the different needs for our cybersecurity 12:04.940 --> 12:05.570 department. 12:05.570 --> 12:07.700 And then there's mean time to remediation. 12:07.700 --> 12:11.930 We have incidents that are occurring, and there should be a mean time or average time that it takes 12:11.930 --> 12:14.240 to remediate a specific problem like this. 12:14.240 --> 12:16.010 Maybe we're seeing a DDoS attack. 12:16.010 --> 12:19.880 And in the meantime to remediate is 24 hours. 12:19.910 --> 12:22.940 Not a great time, but it is the average for our organization. 12:22.940 --> 12:25.730 In this case, maybe our actual time was 27 hours. 12:25.730 --> 12:27.170 Well, what would it constituted? 12:27.170 --> 12:28.220 That extra three hours? 12:28.220 --> 12:29.630 Maybe it's only ten hours. 12:29.630 --> 12:30.830 And we did a really good job. 12:30.830 --> 12:33.080 So again we need to go through and say yes, this worked. 12:33.080 --> 12:34.610 This worked and this did not work. 12:34.610 --> 12:35.960 Let's not do this again. 12:35.960 --> 12:40.820 Whatever the case, we want to provide that marine time to remediation versus an actual time to remediation. 12:40.820 --> 12:44.650 So we can identify different processes and procedures that worked and didn't work. 12:44.680 --> 12:46.900 Finally, we want to report to our senior managers. 12:46.900 --> 12:51.400 This report is overall going to our manager, which is then going to submit it to senior management. 12:51.430 --> 12:55.780 Senior management isn't always on top of the technical nuances. 12:55.780 --> 13:00.490 So we provide these statistics so that they can see a very big picture wise based on the average time 13:00.490 --> 13:02.350 or statistics that they're well known for. 13:02.380 --> 13:07.510 We want to stay away from words like IDs unless we spell out and provide within that report exactly 13:07.510 --> 13:08.950 what an IDs is. 13:09.190 --> 13:13.300 It needs to be a technical report, but a low level technical report in most cases. 13:13.300 --> 13:16.180 Now this really depends on organization from organization. 13:16.180 --> 13:21.070 If you work for a major technical organization that produces stock reports all the time, your senior 13:21.070 --> 13:24.010 management may look at you and say, I want a highly technical report. 13:24.010 --> 13:29.230 However, you may also work for a retailer, and the retail manager that's associated with this doesn't 13:29.230 --> 13:30.370 need that high technical report. 13:30.370 --> 13:31.750 You're just going to confuse them. 13:31.750 --> 13:34.540 And in that case, we may tone it down from the technical perspective. 13:34.570 --> 13:38.980 This is where really knowing your environment for reporting really comes into play, and your manager 13:38.980 --> 13:42.310 should help you along the way as far as size is concerned. 13:42.340 --> 13:43.910 Our reporting or our senior management. 13:43.940 --> 13:49.010 Can reports really go to that in-between where they have some technical knowledge but not an in-depth 13:49.040 --> 13:49.850 technical knowledge? 13:49.850 --> 13:53.720 You shouldn't see a lot of questions on your exam specifically toward the type of report that you're 13:53.720 --> 13:58.220 doing more on the broad spectrum of what the report actually includes. 13:58.220 --> 14:00.920 And then finally, regulatory compliance reporting. 14:00.920 --> 14:05.060 This usually goes through a manager first, but then we may have a regulatory component to it. 14:05.090 --> 14:09.350 Let's say, for instance, one of our servers that was affected by the incident is holding health information. 14:09.350 --> 14:14.090 We are then bound by HIPAA regulations to provide a compliance report for HIPAA. 14:14.120 --> 14:18.590 This would go through the process, and we may have some extra indicators on that report that we submit 14:18.620 --> 14:19.550 to senior management. 14:19.550 --> 14:22.280 So they then can report that to compliance. 14:22.310 --> 14:27.020 Remember, as an analyst isn't your job to report for compliance natures, but it may be your job to 14:27.050 --> 14:29.060 actually put the compliance report together. 14:29.090 --> 14:32.090 Those are two different tracks when we're putting those components together. 14:32.090 --> 14:36.590 And if it has a compliance element to it, just be aware that those compliance elements need to be properly 14:36.590 --> 14:40.520 filled out to the letter of the regulatory compliance or our contractual agreement. 14:40.550 --> 14:42.390 Your manager should help you along the way. 14:42.390 --> 14:46.950 But if you're responsible for reporting for Sisa, you just need to know that if it's a HIPAA report, 14:46.950 --> 14:48.810 you need to conform to HIPAA regulations. 14:48.810 --> 14:52.590 They don't expect you to know what those regulations are for the compliance reporting, just that you 14:52.590 --> 14:55.470 have to actually follow HIPAA compliance reporting. 14:56.130 --> 14:59.160 Within this episode, we talked about reporting and the reporting structure. 14:59.160 --> 15:02.550 We talked about identifying stakeholders and of course the after action review. 15:02.580 --> 15:05.820 Finally, we talked about formal reporting and everything that comes along with it. 15:05.850 --> 15:10.320 When it comes to Sisa, they really take a high level overview of all of this. 15:10.320 --> 15:13.170 You don't need to dig into the nitty gritty of going well. 15:13.200 --> 15:17.190 Topic 1.3 includes this according to ISO 2701. 15:17.190 --> 15:18.930 That's not what we're talking about here. 15:18.930 --> 15:23.940 What you need to know for Sisa is the difference between a primary stakeholder and a secondary stakeholder, 15:23.940 --> 15:28.470 and why you would include one in your primary reporting structure, but not the other. 15:28.470 --> 15:32.700 Again, we're not looking for anything deep dive here for the reporting structure, but you should know 15:32.700 --> 15:38.070 for your Sisa exam exactly who you're reporting to, i.e. those primary stakeholders and why you're 15:38.070 --> 15:38.820 reporting to them. 15:38.820 --> 15:40.680 If you can do that, you should be good to go.