WEBVTT 00:07.160 --> 00:11.480 In this episode, we're going to talk about software vulnerabilities and what constitutes a software 00:11.510 --> 00:12.290 vulnerability. 00:12.320 --> 00:16.640 We're also going to talk about static versus dynamic analysis, and why it's important that you understand 00:16.640 --> 00:18.050 the differences between them. 00:18.080 --> 00:23.840 Then we're going to go into reverse engineering and how static and dynamic analysis play a role in that 00:23.840 --> 00:27.500 reverse engineering of different malware and software that you may see. 00:27.530 --> 00:30.560 Finally, we're going to talk about fuzzing and what that constitutes. 00:30.560 --> 00:36.170 In order to test for software vulnerabilities throughout your Cisa exam process, you need to be aware 00:36.170 --> 00:37.310 of these different terms. 00:37.310 --> 00:41.360 But don't worry, you don't actually have to know coding to pass this part of the course. 00:41.390 --> 00:46.850 Cisa isn't actually going to make you go through and dissect a piece of code or a malware to figure 00:46.850 --> 00:47.660 out what's going on. 00:47.660 --> 00:52.130 You just need to know the high level overview of what we're talking about today, and you should be 00:52.130 --> 00:54.440 good to go when it comes to your Cisa exam. 00:54.440 --> 01:00.180 When we look at software, you must understand as an analyst that every software has the potential for 01:00.180 --> 01:01.080 vulnerabilities. 01:01.110 --> 01:06.090 Software is created by people, and human error usually makes up a majority of the problems that we 01:06.090 --> 01:10.680 see, not just within our enterprise environment, but within developers as well. 01:10.710 --> 01:16.290 Codes can sometimes be as little as 10,000 lines long, sometimes a little bit less, up to hundreds 01:16.290 --> 01:19.230 upon hundreds of thousands of code lines. 01:19.230 --> 01:24.120 When you think of different software programs, realize that something like a calculator may only have 01:24.120 --> 01:29.070 100 lines of code, but a video game can literally have millions of lines of code. 01:29.100 --> 01:34.440 This puts a major detriment to software vulnerability on the line, and you, as an analyst, need to 01:34.440 --> 01:38.310 be able to understand how do we discover those different vulnerabilities. 01:38.340 --> 01:40.950 We're going to talk about discovery as our first phase. 01:40.950 --> 01:43.950 Where do we go through and how did we discover those different vulnerabilities? 01:43.980 --> 01:46.560 This is usually done via a scanning process. 01:46.590 --> 01:48.810 Now we're going to go into detail in the next slide. 01:48.810 --> 01:51.270 Exactly the different types of scanning that we can do. 01:51.270 --> 01:57.910 But just understand in order to identify and discover vulnerabilities we must conduct a scan After the 01:57.910 --> 02:04.600 scan has been completed, we may identify and analyze that scan process to discover those vulnerabilities. 02:04.630 --> 02:09.580 Once we've identified and analyzed that vulnerability, we've decided where it needs to go from there. 02:09.580 --> 02:11.620 We need to remediate that vulnerability. 02:11.650 --> 02:15.850 Sometimes we need to throw a bandaid over it to provide a short term solution. 02:15.880 --> 02:18.310 This is usually done in a variety of different ways. 02:18.310 --> 02:19.690 This is a web application. 02:19.690 --> 02:25.180 Maybe we'll throw a web application firewall on there to provide a temporary aid to that vulnerability. 02:25.210 --> 02:31.090 However, true remediation for software comes into play that we have to rewrite the code in such a way 02:31.090 --> 02:32.350 that it is secure. 02:32.380 --> 02:34.090 Next, we need to validate it. 02:34.120 --> 02:37.690 When we validate that code, we're going through the process and rescanning it. 02:37.720 --> 02:40.780 We're validating that that vulnerability is no longer there. 02:40.780 --> 02:42.700 And finally we need to document it. 02:42.700 --> 02:47.800 I've pounded on this before, but documentation, documentation, documentation you're never going to 02:47.800 --> 02:53.080 have too much documentation when it comes to identifying and remediating a vulnerability or any process 02:53.080 --> 02:54.400 within cybersecurity. 02:54.430 --> 02:59.940 Annotating our vulnerabilities and documenting the process is the number one thing that you can do as 02:59.940 --> 03:03.150 a cybersecurity analyst, especially if you're an expert in the field. 03:03.150 --> 03:08.220 When we conduct an analysis of our code, we're usually either doing a static analysis or a dynamic 03:08.220 --> 03:08.790 analysis. 03:08.820 --> 03:12.570 A static analysis is examining the code without actually executing it. 03:12.570 --> 03:18.150 This goes through an automated process of looking at the code from a line by line perspective, to automatically 03:18.150 --> 03:21.810 look for different vulnerabilities associated with how the code is run. 03:21.810 --> 03:24.300 Now, this is different from a code review. 03:24.330 --> 03:29.250 A code review is where we go through, and you actually have a human being looking at line by line of 03:29.250 --> 03:29.820 code. 03:29.820 --> 03:35.880 One line after another usually require an expert developer or coder to go through the process, and 03:35.880 --> 03:38.160 a static examination or analysis. 03:38.190 --> 03:44.280 We're not really using a coder, but we're using a series of automated processes to look for different 03:44.280 --> 03:48.030 vulnerabilities associated with that code without actually running the program. 03:48.030 --> 03:52.050 This is different from a dynamic analysis and a dynamic analysis. 03:52.080 --> 03:53.130 We're running the program. 03:53.130 --> 03:56.470 We're seeing what happens as the program runs through its features. 03:56.470 --> 03:58.270 We're examining the task process. 03:58.270 --> 04:03.670 We're seeing how it intersects with the different processes, both on the operating system and the other 04:03.670 --> 04:06.310 programs or applications on the machine. 04:06.340 --> 04:11.350 Static analysis is usually more effective because it's going through the code without actually running 04:11.350 --> 04:12.100 the program. 04:12.100 --> 04:17.050 With this sense, we're actually able to see the coding as it's going through, and we're able to create 04:17.050 --> 04:21.550 automated processes to identify different vulnerabilities on a line by line basis. 04:21.580 --> 04:26.980 This provides us an early identification of how the code is going to interact with the operating system, 04:26.980 --> 04:30.130 as well as the other applications that the code resides on. 04:30.160 --> 04:34.630 Dynamic analysis and comparison is less effective, but it's a lot quicker. 04:34.630 --> 04:40.210 We get to identify how the code interacts through the other applications and through the operating system 04:40.210 --> 04:46.210 by examining that code or that program while it's being initiated, and while it's executing through 04:46.210 --> 04:47.110 its program. 04:47.140 --> 04:52.660 Imagine, if you will, if I start up a calculator and I plug in the buttons of one plus one, we expect 04:52.670 --> 04:53.720 an output of two. 04:53.750 --> 04:58.940 But if I'm going through that process, through a dynamic analysis and it's intersecting with a different 04:58.940 --> 05:04.460 program for no reason, that would be dynamic analysis, where we're looking for different tidbits as 05:04.490 --> 05:05.930 we're using the program. 05:05.930 --> 05:10.910 Static analysis, on the other hand, is where I don't use the calculator, but I look at the functions 05:10.910 --> 05:16.220 that the code provides, showing me that two plus two would then output an identifier of four. 05:16.250 --> 05:21.200 This is the major differences between a static analysis versus a dynamic analysis. 05:21.230 --> 05:27.200 Reverse engineering is a subset of the static analysis process we've gone through, and we've analyzed 05:27.200 --> 05:32.960 the code on a line by line basis, based on an automated process that allows us to identify different 05:32.960 --> 05:38.750 perspectives of the code and how it affects both the operating system and other applications that reside 05:38.750 --> 05:40.040 on that operating system. 05:40.040 --> 05:45.980 We can then reverse engineer the process to see exactly where it comes into play, to see where it's 05:45.980 --> 05:50.990 going wrong and where it's intersecting with those other applications, or where it's going on with 05:51.030 --> 05:56.700 the process of acting in a form or function that we didn't anticipate or that we don't want. 05:56.730 --> 06:02.940 Reverse engineering entails meticulous examination of the product in order to understand the functionality 06:02.940 --> 06:06.390 and the operating mechanisms that reside on the program. 06:06.390 --> 06:10.290 We're literally going through the code to reverse engineer what it did. 06:10.320 --> 06:12.780 This is much like filling a glass of milk. 06:12.810 --> 06:16.290 The program fills the glass of milk up with milk, right? 06:16.320 --> 06:17.790 We're literally pouring the glass. 06:17.790 --> 06:22.470 How would you pour the glass of milk out and understand how it actually got in there? 06:22.500 --> 06:23.700 Did it come from a jug? 06:23.700 --> 06:25.110 Did it come from another glass? 06:25.110 --> 06:27.360 Did it come from another container? 06:27.390 --> 06:31.110 Did it not come from a container at all and just suddenly start dripping in there? 06:31.110 --> 06:35.580 This is reverse engineering really comes into play and why it's so difficult to achieve. 06:35.610 --> 06:42.120 This reverse functionality reveals to us different aspects of the program, and how it really pulls 06:42.120 --> 06:47.400 off the different malicious activities that it intersects with the regular programs on a case by case 06:47.400 --> 06:48.090 basis. 06:48.090 --> 06:53.560 This allows us to have a deeper understanding of how the code interacts, not just with our applications, 06:53.560 --> 06:55.480 but with our operating system as well. 06:55.510 --> 07:00.880 This is the only true level that we can understand malware and how it intersects with different systems. 07:00.880 --> 07:03.610 You have to remember that through dynamic analysis. 07:03.640 --> 07:06.730 We're going through and we're seeing the processes that come into play. 07:06.730 --> 07:10.210 But in some cases there may be a timer on that process. 07:10.210 --> 07:13.210 We could start the program and then shut it off an hour later. 07:13.210 --> 07:16.330 That didn't really show us that there was another layer to that. 07:16.330 --> 07:22.390 And in three days time, that same program would have released a more malicious ransomware onto our 07:22.390 --> 07:22.990 systems. 07:22.990 --> 07:28.270 This is why static analysis and reverse engineering are so prized in cyber security. 07:28.300 --> 07:30.100 Finally, there's something called fuzzing. 07:30.130 --> 07:35.380 Fuzzing is a method that we employ to uncover software flaws through normal means. 07:35.380 --> 07:38.530 I want you to imagine that you have this brand new piece of software. 07:38.530 --> 07:42.670 Let's say that you created this calculator, and this calculator is working great. 07:42.670 --> 07:44.770 It does all the pluses and the minuses. 07:44.770 --> 07:49.530 We can subtract, we can add, we can do everything that a calculator is supposed to do, and we can 07:49.530 --> 07:50.970 even do some algebra. 07:51.000 --> 07:56.520 That algebra function is a major initiative to increase our calculator standing. 07:56.550 --> 07:58.530 However, how do we truly test that? 07:58.530 --> 08:03.960 We can throw in basic algorithms that test the algebraic function of our new calculator. 08:03.960 --> 08:07.020 But how does it intersect with data that we're not expecting? 08:07.050 --> 08:12.090 After all, we're expecting a calculator function and an algebraic function within that calculator to 08:12.120 --> 08:13.260 produce an output. 08:13.290 --> 08:16.260 What happens, however, if I just throw a bunch of letters at it? 08:16.290 --> 08:19.380 Let's say we throw in a bunch of keyboard trash. 08:19.410 --> 08:23.940 I want you to imagine having your cat dance on the keyboard, and then we submit it to that calculator 08:23.940 --> 08:24.570 program. 08:24.570 --> 08:26.430 That's where fuzzing comes into play. 08:26.460 --> 08:31.590 We're literally just throwing garbage at it to see how the system interacts with this random assortment 08:31.590 --> 08:33.600 of information that we throw at it. 08:33.630 --> 08:38.580 Now there's different fuzzing tools that we can utilize, but what the fuzzing process really does for 08:38.580 --> 08:44.730 us is it validates if we have a flaw, or if that the program is capable of causing a software freeze, 08:44.730 --> 08:47.290 crash, or exhibits unexpected errors. 08:47.320 --> 08:53.470 It also lets us know if there's an output that, through that fuzzing process, allows us, as an attacker, 08:53.470 --> 08:56.920 to gain rudimentary or root access into that system. 08:56.950 --> 09:03.010 Fuzzing is a great way of throwing garbage and subsets of coding into the system to see what the output 09:03.010 --> 09:03.550 is. 09:03.580 --> 09:07.840 Imagine if you will, just throwing a bunch of garbage, and all of a sudden you have root access into 09:07.840 --> 09:08.500 the system. 09:08.500 --> 09:12.910 This would be a major vulnerability and we need to test for that vulnerability. 09:12.940 --> 09:15.700 In this episode, we talked about software vulnerabilities. 09:15.700 --> 09:19.870 We also talked about how to test for vulnerabilities through a static and dynamic analysis. 09:19.870 --> 09:24.910 We talked about the differences in how dynamic analysis, while more efficient, isn't as accurate or 09:24.910 --> 09:25.540 in depth. 09:25.540 --> 09:31.120 We talked about reverse engineering and how it's a subset of static analysis where we're actually reversing 09:31.120 --> 09:32.470 the process of the program. 09:32.500 --> 09:37.420 Finally, we talked about fuzzing and how fuzzing interacts and throwing garbage at the system in order 09:37.420 --> 09:42.670 to see the output and how that output interacts with the program in which we're testing, always come 09:42.670 --> 09:47.010 into play when we're talking about software vulnerabilities and how to test for them. 09:47.010 --> 09:53.130 In the Cisa exam, you can expect to see scenario based questions relating back to the fuzzing process, 09:53.130 --> 09:56.550 as well as reverse engineering and static versus dynamic analysis. 09:56.580 --> 10:01.320 You should understand the differences between them, and be prepared to answer scenario based questions 10:01.320 --> 10:03.000 that relate to each one. 10:03.000 --> 10:08.580 You might see a question that talks about software vulnerability testing and fuzzing is one of the answers. 10:08.580 --> 10:12.270 I want to caution you from jumping straight into that vulnerability of fuzzing. 10:12.270 --> 10:17.940 Sometimes the question is related back to a normal standard or in different type of testing that we're 10:17.940 --> 10:18.690 conducting. 10:18.690 --> 10:22.560 You should know what fuzzing is and how it interplays with software vulnerabilities. 10:22.560 --> 10:26.460 But you should also know the difference between static and dynamic analysis. 10:26.460 --> 10:28.830 I'd caution you from jumping straight to the right answer. 10:28.830 --> 10:34.500 Remember, when you're reading any type of exam question on Cisa, to read the question, read the answers, 10:34.500 --> 10:37.680 and then reread what the question is actually asking for. 10:37.680 --> 10:42.300 If you can do that, you should be successful on this as well as the other episodes that we've talked 10:42.300 --> 10:42.930 about.