WEBVTT 1 00:00.000 --> 00:04.000 The software development lifecycle is imperative regardless of whether we're 2 00:04.000 --> 00:05.280 working inside of just 3 00:05.280 --> 00:10.650 programming, doing a maintenance on a particular system, or if we're actually 4 00:10.650 --> 00:11.760 developing something 5 00:11.760 --> 00:16.180 that's going to go inside of our cloud infrastructure. Now, I know that 6 00:16.180 --> 00:17.600 software as a service doesn't 7 00:17.600 --> 00:22.020 really allow us a lot of access to the actual programs that are being ran 8 00:22.020 --> 00:23.520 inside of our provider's 9 00:23.520 --> 00:27.870 responsibility of the cloud infrastructure. But that's okay because as you'll 10 00:27.870 --> 00:28.640 see as we go out 11 00:28.640 --> 00:33.460 through this portion of the skill, that SDLC can be implemented from our WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:28.640 --> 00:33.460 through this portion of the skill, that SDLC can be implemented from our 12 00:33.460 --> 00:34.880 vantage point or our 13 00:34.880 --> 00:39.530 foxhole to make sure that the programs being implemented or the applications 14 00:39.530 --> 00:41.200 meet a certain standard 15 00:41.200 --> 00:45.520 mostly to do with security. But as we start going into platform as a service 16 00:45.520 --> 00:46.400 and infrastructure as 17 00:46.400 --> 00:51.480 a service, we have definitely have more control over the application, the 18 00:51.480 --> 00:52.720 runtime, and the operating 19 00:52.720 --> 00:58.530 systems depending on which model we're utilizing for our organization. Now, if 20 00:58.530 --> 01:00.000 you've seen this before, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 01:00.000 --> 01:05.570 this should look pretty familiar as this is the software development lifecycle 22 01:05.570 --> 01:05.680 from a 23 01:05.680 --> 01:10.200 other course here on CBT Nuggets. I had the link for below as I did this skill 24 01:10.200 --> 01:11.840 also. The reason I 25 01:11.840 --> 01:17.310 bring this up is because this software development lifecycle process is the 26 01:17.310 --> 01:19.120 general idea of how we do 27 01:19.120 --> 01:25.240 software development life cycles. It's not rated to just one particular method 28 01:25.240 --> 01:27.120 or program or vendor. 29 01:27.120 --> 01:31.580 It's the overall idea of software development life cycle. Now, there are a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 01:27.120 --> 01:31.580 It's the overall idea of software development life cycle. Now, there are a 30 01:31.580 --> 01:33.520 little bit of changes 31 01:33.520 --> 01:38.460 inside the Cisco modeling. And I'm going to show that on the screen here. And 32 01:38.460 --> 01:39.600 this is the one that I 33 01:39.600 --> 01:43.290 really want to go through because you'll notice that even though it is similar 34 01:43.290 --> 01:45.200 to what's actually in the 35 01:45.200 --> 01:49.230 overall generic software development life cycle, we rename a couple of things 36 01:49.230 --> 01:50.080 when we're taking a 37 01:50.080 --> 01:54.630 look at the Cisco one. And the reason for that is is because it's tailored for 38 01:54.630 --> 01:56.080 our cloud infrastructure 39 01:56.080 --> 02:00.950 environment. Now, stay in the same. We always deal with planning because we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 01:56.080 --> 02:00.950 environment. Now, stay in the same. We always deal with planning because we 40 02:00.950 --> 02:02.000 have to know what's 41 02:02.000 --> 02:06.880 being implemented, even the simplistic task of identifying systems to restart 42 02:06.880 --> 02:08.160 in their cycle times 43 02:08.160 --> 02:12.480 needs to be planned out. Users are going to be working all hours if we're in a 44 02:12.480 --> 02:14.400 large organization 45 02:14.400 --> 02:18.420 that has employees or users in different time zones. So we don't want to just 46 02:18.420 --> 02:19.200 restart everything 47 02:19.200 --> 02:25.360 all at once. Something that has to be planned out. Now, when our development 48 02:25.360 --> 02:27.040 team is coming up with 49 02:27.040 --> 02:31.600 new implementations, these have to be designed out with the idea that therefore WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 49 02:27.040 --> 02:31.600 new implementations, these have to be designed out with the idea that therefore 50 02:31.600 --> 02:32.480 our organization and 51 02:32.480 --> 02:37.830 for the particular environment of cloud infrastructure that we're utilizing, 52 02:37.830 --> 02:39.280 whether it be software, 53 02:39.280 --> 02:44.640 platform or infrastructure as a service. The design portion of this software 54 02:44.640 --> 02:46.160 development life cycle 55 02:46.160 --> 02:50.840 is really important because what if we're developing an application for 56 02:50.840 --> 02:52.320 platform as a service 57 02:52.320 --> 02:58.820 and we don't have total access to the runtime. Well, that alters our design, 58 02:58.820 --> 02:59.360 whereas an 59 02:59.360 --> 03:03.910 infrastructure as a service, we definitely have to go take a look at how we're WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 02:59.360 --> 03:03.910 infrastructure as a service, we definitely have to go take a look at how we're 60 03:03.910 --> 03:05.200 implementing all of 61 03:05.200 --> 03:09.750 our programming and coding and development. And that leads us into the actual 62 03:09.750 --> 03:10.960 development portion 63 03:10.960 --> 03:15.270 of this because depending on the actual model that we're using for our 64 03:15.270 --> 03:17.360 organization, depends on 65 03:17.360 --> 03:22.980 what systems and what capabilities are going to be developed for this actual 66 03:22.980 --> 03:24.400 piece of software. 67 03:24.400 --> 03:28.030 Is it something that affects networking devices directly? Is it something that 68 03:28.030 --> 03:29.120 affects the people 69 03:29.120 --> 03:34.490 in data that's the same plant responsibility in all three of our models? There WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 03:29.120 --> 03:34.490 in data that's the same plant responsibility in all three of our models? There 70 03:34.490 --> 03:35.200 's a lot of different 71 03:35.200 --> 03:39.560 questions here in terms of development of the software. Who's it supposed to 72 03:39.560 --> 03:40.720 affect? Why is it 73 03:40.720 --> 03:45.610 supposed to affect? Basically, the five W's be an implemented here. Now, once 74 03:45.610 --> 03:47.200 we do have it developed 75 03:47.200 --> 03:51.730 and this is basically the design and coding portion, making sure that it's 76 03:51.730 --> 03:52.880 working well with the 77 03:52.880 --> 03:57.680 different systems throughout our organization, whether they be computer systems 78 03:57.680 --> 03:59.040 such as this or 79 03:59.040 --> 04:03.950 networking devices across the actual network infrastructure for communication, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 03:59.040 --> 04:03.950 networking devices across the actual network infrastructure for communication, 80 04:03.950 --> 04:04.480 we have to be able 81 04:04.480 --> 04:08.680 to test them. And this is where we go inside of a sandbox environment, probably 82 04:08.680 --> 04:09.840 . Sometimes I know 83 04:09.840 --> 04:15.340 that doesn't exist based on budget measures, but we try to test as much as we 84 04:15.340 --> 04:16.160 can outside of 85 04:16.160 --> 04:21.040 live production environments. That way, if something that we've designed and 86 04:21.040 --> 04:22.400 developed goes into 87 04:22.400 --> 04:26.070 the live environment, we don't want it to cripple it if there's a vulnerability 88 04:26.070 --> 04:27.360 or a flaw in the actual 89 04:27.360 --> 04:33.110 code. Testing is always imperative. Anytime there's a patch update or a pick on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 04:27.360 --> 04:33.110 code. Testing is always imperative. Anytime there's a patch update or a pick on 90 04:33.110 --> 04:34.400 Windows here for a 91 04:34.400 --> 04:38.890 second, anytime there's a service update to actual Windows, it's tested before 92 04:38.890 --> 04:40.000 it's actually delivered 93 04:40.000 --> 04:44.440 to the actual clients in the real world. That doesn't take out all the flaws in 94 04:44.440 --> 04:46.000 it, but what it does do 95 04:46.000 --> 04:51.060 is take out the majority of them to where basically the only thing left are 96 04:51.060 --> 04:53.040 zero-day vulnerabilities, 97 04:53.040 --> 04:58.120 things we don't know about until it actually happens, or vulnerabilities that 98 04:58.120 --> 04:59.360 we overlooked. 99 04:59.360 --> 05:06.860 Now, this takes us into the next step of SDLC for Cisco into deploying. Deploy WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 04:59.360 --> 05:06.860 Now, this takes us into the next step of SDLC for Cisco into deploying. Deploy 100 05:06.860 --> 05:07.520 ing the actual 101 05:07.520 --> 05:13.860 software in our live environment, whether it be on an application or an actual 102 05:13.860 --> 05:15.200 server within our 103 05:15.760 --> 05:21.760 cloud infrastructure model, when we deploy, we're going to be making sure that 104 05:21.760 --> 05:22.800 the software that we 105 05:22.800 --> 05:29.220 developed is suitable for working with the actual platform or versioning or 106 05:29.220 --> 05:30.080 different device that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 106 05:29.220 --> 05:30.080 different device that 107 05:30.080 --> 05:34.900 we've actually made it for. The testing that we did previously is going to try 108 05:34.900 --> 05:36.160 and reduce all the 109 05:36.160 --> 05:40.660 vulnerabilities down to zero. Now, it's not always going to be that way, but 110 05:40.660 --> 05:42.480 when we deploy, if we find 111 05:42.480 --> 05:47.120 something along the way, we can create something like an access control list 112 05:47.120 --> 05:48.320 and making sure that we 113 05:48.320 --> 05:53.630 deploy it out on a proper schedule to make sure that it doesn't affect the 114 05:53.630 --> 05:56.000 actual usability of our 115 05:56.000 --> 06:01.560 systems within the organization. Then, we start going into review and making WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 115 05:56.000 --> 06:01.560 systems within the organization. Then, we start going into review and making 116 06:01.560 --> 06:02.960 sure that everything is 117 06:02.960 --> 06:08.550 working as intended. Now, if it passes all the smell tests for everything that 118 06:08.550 --> 06:09.920 we've done inside of 119 06:09.920 --> 06:14.180 our circle here, it goes to actual launch into full production. But what I want 120 06:14.180 --> 06:15.680 to point out is, 121 06:15.680 --> 06:22.170 is that design, development, testing, deploying, reviewing are all continuous. 122 06:22.170 --> 06:24.800 From planning to launch, 123 06:24.800 --> 06:28.310 those are only two statiquents because there's going to be a plan phase and it 124 06:28.310 --> 06:29.200 's going to happen. 125 06:29.200 --> 06:34.260 And then, once it goes in between and we're doing the actual development of the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 125 06:29.200 --> 06:34.260 And then, once it goes in between and we're doing the actual development of the 126 06:34.260 --> 06:35.600 software itself, 127 06:36.400 --> 06:40.560 we're going through and making sure that all these cycles are continuously 128 06:40.560 --> 06:42.080 working with each other 129 06:42.080 --> 06:46.640 because you heard me in design, we'll talk about different aspects of different 130 06:46.640 --> 06:47.920 portions of what's 131 06:47.920 --> 06:52.980 in the software development lifecycle. The reason for that is because it's not 132 06:52.980 --> 06:54.480 just static as far 133 06:54.480 --> 07:00.050 as the steps that we have to flow through. There's always a developed test and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 133 06:54.480 --> 07:00.050 as the steps that we have to flow through. There's always a developed test and 134 07:00.050 --> 07:01.520 proceed in making sure 135 07:01.520 --> 07:06.510 that we have everything accounted for or as much as humanly possible. In 136 07:06.510 --> 07:07.280 addition to that, 137 07:07.280 --> 07:11.220 we want to try to involve our security team as well to make sure that all the 138 07:11.220 --> 07:12.240 vulnerabilities, 139 07:12.240 --> 07:17.600 like we said, are as minimal as possible before we do our actual launch. Now, 140 07:17.600 --> 07:18.400 as I said at the 141 07:18.400 --> 07:22.260 beginning of this portion of the skill, when we look at software development 142 07:22.260 --> 07:23.520 lifecycle, it's important 143 07:23.520 --> 07:29.820 to remember that this is modified from a very generic baseline SDLC platform. 144 07:29.820 --> 07:30.800 This is tailored to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 144 07:29.820 --> 07:30.800 This is tailored to 145 07:30.800 --> 07:36.200 be within Cisco and how we should approach in a modified view. Remember, we're 146 07:36.200 --> 07:37.360 adding to and not 147 07:37.360 --> 07:42.540 taking away from, make sure that everything that we develop and implement 148 07:42.540 --> 07:44.320 follows the SDLC model 149 07:44.320 --> 07:47.690 to make sure that we're making this as easy on the organization and more 150 07:47.690 --> 07:48.240 importantly, 151 07:48.240 --> 07:51.360 the actual users that are processing that data for us.