WEBVTT 00:07.070 --> 00:11.450 In this episode, we're going to talk about secure software development and the framework that needs 00:11.450 --> 00:13.640 to be utilized in the process. 00:13.700 --> 00:17.930 This specific episode deals with the software development life cycle. 00:17.960 --> 00:22.070 You have to remember as you're going through Cisa, you don't need to be an expert at this, but you 00:22.070 --> 00:28.730 can expect questions that detail specifically about and what phase we may involve, security, or at 00:28.730 --> 00:31.820 what phase we may start the maintenance. 00:31.820 --> 00:34.400 These are the type of questions you should be prepared to answer. 00:34.400 --> 00:40.460 You don't need to answer specific questions about programming or how the programming interacts with 00:40.460 --> 00:46.010 other adjacent performance, but you do need to have a basic understanding of the life cycle in general, 00:46.010 --> 00:47.810 and that's what we're addressing today. 00:48.530 --> 00:54.200 The software development life cycle, or SDLC, is a framework that we utilize to go from the inception 00:54.200 --> 00:58.010 of new software, i.e. what kind of software are we going to build? 00:58.010 --> 01:02.920 What are we trying to accomplish with this software all the way to the maintenance and support stage, 01:02.920 --> 01:05.290 which is the software is already being utilized. 01:05.290 --> 01:09.490 It's already being implemented, but we need to be aware of the different flaws and vulnerabilities 01:09.490 --> 01:11.290 that may come with newer technology. 01:11.320 --> 01:15.580 How are we supporting the software as these new technologies evolve? 01:15.610 --> 01:20.860 This is a software development lifecycle that you need to be familiar with within the requirements and 01:20.860 --> 01:21.850 design stage. 01:21.850 --> 01:26.440 We're specifically looking at two very different aspects functional meaning. 01:26.440 --> 01:28.150 Where am I getting my data from? 01:28.150 --> 01:29.590 Am I getting telemetry data? 01:29.620 --> 01:31.450 Am I getting temperature sensor data? 01:31.450 --> 01:34.300 What kind of functional data am I dealing with? 01:34.330 --> 01:36.700 It also has to deal with non-functional data. 01:36.700 --> 01:39.130 What am I doing with that data when I got it? 01:39.160 --> 01:43.900 How is my software interacting with temperatures below two degrees Celsius? 01:43.900 --> 01:48.700 And how am I acting with degrees at, you know, 90°C, which is, you know, basically burning the 01:48.700 --> 01:50.290 world on fire, right? 01:50.320 --> 01:55.450 So what are those two aspects and how are we going to design or how are we going to implement the software 01:55.450 --> 01:58.590 with functional and non-functional Parameters. 01:58.590 --> 02:02.430 We're also going to look at the requirements gathering within the SDL. 02:02.460 --> 02:03.000 Steps. 02:03.000 --> 02:08.100 When we talk about requirements gathering we're talking about how am I utilizing this software. 02:08.130 --> 02:14.310 What are the basic requirements that we need hands down oftentimes within software development. 02:14.340 --> 02:19.140 We'll start out with this general idea of I want to build this program again. 02:19.140 --> 02:20.550 Let's talk about calculator. 02:20.550 --> 02:22.320 My favorite analogy right. 02:22.320 --> 02:29.760 So in a requirement stage we can say I need a program that does multiplication division subtraction 02:29.760 --> 02:30.780 and addition. 02:30.780 --> 02:32.070 No more no less. 02:32.070 --> 02:33.720 That's what I needed to do. 02:33.720 --> 02:36.300 That's the requirements of the program that I'm building. 02:36.300 --> 02:41.010 However, it's not uncommon for later on in the program to add added features. 02:41.010 --> 02:42.600 Now I need to do powers. 02:42.600 --> 02:45.660 I need to be able to go, hey, what's ten to the power of three? 02:45.690 --> 02:50.190 That's an additional step in the software development life cycle that we need to be aware of, but it's 02:50.190 --> 02:55.110 not in the initial requirement stage or the gathering stage, however, not uncommon. 02:55.110 --> 02:59.180 We need to analyze and plan what we're trying to accomplish throughout this entire thing. 02:59.180 --> 03:03.650 What is our plan for the software to encompass? 03:03.680 --> 03:09.020 Am I only using it as a calculator, or is the calculator part of a bigger program that's being developed? 03:09.020 --> 03:15.170 It's not uncommon to work on one part of a project while another team is programming another part. 03:15.200 --> 03:21.470 So in our space with a calculator, maybe that calculator is designed to do more than just basic calculations, 03:21.470 --> 03:25.850 and we need to be able and prepared based on the wider project that we're building. 03:26.030 --> 03:28.610 Finally, security and performance architecture. 03:28.610 --> 03:32.240 We've talked about how security needs to be built in from the onset. 03:32.240 --> 03:35.990 It needs to go through and have security front and center on its mind. 03:35.990 --> 03:40.790 If I don't build security into our program right at the beginning stages, when we're talking about 03:40.790 --> 03:46.850 it, when we're designing it straight from the ground up, my cost could go easily double or even sometimes 03:46.850 --> 03:50.000 triple if we try to implement security after the fact. 03:50.030 --> 03:55.310 Not only that, but doing security after the fact also leads to more vulnerabilities. 03:55.310 --> 03:57.670 You're never going to be 100% secure. 03:57.700 --> 04:03.700 Could you imagine 300,000 lines of coding and having to go through line by line, trying to figure out 04:03.700 --> 04:04.960 where to put security in? 04:04.990 --> 04:09.940 Isn't it better just to do security from the onset and just have it written in write as the get go? 04:09.970 --> 04:14.680 Again, security performance architecture needs to be involved right at the beginning of your planning 04:14.680 --> 04:15.370 stage. 04:16.120 --> 04:20.500 During the deployment stage, we're going to move to develop software into a production environment. 04:20.500 --> 04:23.140 We want to be careful that we don't deploy it all at once. 04:23.140 --> 04:25.930 We want to go step by step, start small. 04:25.930 --> 04:28.090 Let's see how the system interacts. 04:28.090 --> 04:31.360 So the software interacts with a single production environment. 04:31.360 --> 04:32.830 Let's test it again. 04:32.830 --> 04:37.780 Let's further make sure that there's no flaws or vulnerabilities, any errors that may erupt in this 04:37.780 --> 04:42.370 production environment as we fix those different flaws in the in production environment, then we can 04:42.370 --> 04:45.670 roll it out to more production environments and the list goes on. 04:45.670 --> 04:50.200 We're continuing to test the software as it's being deployed throughout our frameworks. 04:50.200 --> 04:56.100 During the maintenance phase, we're going to provide support and life cycle adjustments to our software 04:56.100 --> 04:57.510 in a production environment. 04:57.540 --> 04:59.220 Our salespeople are doing their job. 04:59.220 --> 05:01.290 They're selling the software, they're making it work. 05:01.290 --> 05:02.760 They're making our company money. 05:02.790 --> 05:04.350 Now we need to support it. 05:04.350 --> 05:09.600 There's going to be specific iterations of that software that are going to be independent from one iteration 05:09.600 --> 05:10.380 to another. 05:10.380 --> 05:15.060 That means if I'm in a Lego factory, it's probably going to be different than a couch factory, even 05:15.060 --> 05:17.250 though the software may be utilized in the same manner. 05:17.250 --> 05:21.990 There's probably idiosyncrasies we need to be aware of, and we need to support and manage that software 05:21.990 --> 05:22.800 accordingly. 05:22.800 --> 05:25.860 We need to ensure that the software remains operational. 05:25.890 --> 05:31.290 You'll see companies and organizations like Microsoft that comes out with a patch every other week when 05:31.290 --> 05:37.020 it comes out, identifying different flaws or vulnerabilities associated with their specific software. 05:37.020 --> 05:42.930 In this case, we need to maintain the software and ensure that if a flaw comes out or an error is detected, 05:42.930 --> 05:46.350 that we quickly respond to it and provide patches to it accordingly. 05:46.380 --> 05:52.320 During this phase, we're ensuring the operational, reliable, and efficient use of the software throughout 05:52.320 --> 05:53.490 its life cycle.