WEBVTT 00:00.300 --> 00:05.570 As much as we'd like to think otherwise code does not magically appear on its own. 00:05.850 --> 00:11.460 Nor does code appear if we just throw some ideas to a bunch of programmers and let them come up with 00:11.460 --> 00:12.020 something. 00:12.120 --> 00:19.770 So what we need is some type of framework some type of organizational process that allows us to do development 00:20.040 --> 00:21.840 to get that code out the door. 00:22.030 --> 00:27.240 Now if you want to go old school there is a development model known as waterfall. 00:27.240 --> 00:30.750 So let me put up an example of waterfall for you here. 00:30.750 --> 00:36.030 Now as you look at this you're going to see that we have little boxes with discrete steps and we'll 00:36.030 --> 00:42.690 even put it in a step pattern like that so water could come dripping down from one box to the next what 00:42.690 --> 00:43.540 we're looking at here. 00:43.560 --> 00:48.390 Like for example the first thing on this example is requirements what are the requirements for this 00:48.390 --> 00:50.110 particular application. 00:50.280 --> 00:57.060 And then design as we're designing how this is going to work implementation whatever it might be waterfall 00:57.060 --> 01:01.050 processes and these are very old school have been around for a long time. 01:01.050 --> 01:07.710 So you're you're you're very locked in to additionally whatever the requirements are even if the requirements 01:07.710 --> 01:14.880 might need to change your very phase driven everything is so rigid as we go from one step to the next. 01:14.880 --> 01:20.800 A number of years ago a bunch of software developers got together and said This is not a good philosophy. 01:21.000 --> 01:28.950 We need to think about an alternative way to do development outside of this waterfall and they came 01:28.950 --> 01:31.230 up with a philosophy called agile. 01:31.230 --> 01:37.590 Now there are entire courses on agile that can go into great detail but for the exam what I want to 01:37.710 --> 01:44.670 understand is that agile by itself is a philosophy that says waterfall is not the way to do it agile 01:44.670 --> 01:51.030 says things like individuals and interactions are more important than processes and tools agile says 01:51.030 --> 01:56.040 things like working software is more important than comprehensive documentation. 01:56.310 --> 02:03.090 Agile is going to say things that would include customer collaboration over just a contract negotiation. 02:03.090 --> 02:07.150 It would say things like responding to change over just following a plan. 02:07.170 --> 02:13.820 The word about Agile is flexibility and being able to move and be able to move quickly with adjustments 02:13.830 --> 02:16.590 it needs to get that software out the door. 02:16.800 --> 02:18.130 So how do we do this. 02:18.130 --> 02:24.600 Well there's hundreds of different tool sets within the agile philosophy but a couple that I might want 02:24.600 --> 02:28.580 to bring to mind is for example the sprint the Sprint is OK. 02:28.680 --> 02:34.110 We have a very short amount of time a week a day whatever it might be where we have a certain number 02:34.110 --> 02:36.020 of things that we want to get fulfilled. 02:36.120 --> 02:41.160 Let's get that deadline and within that Sprint time period let's achieve what we can achieve. 02:41.170 --> 02:44.990 Another thing might be the scrum a scrum is a quick meeting. 02:45.030 --> 02:50.490 A very short meeting often standing up that where you basically talk about you know what have I achieved 02:50.490 --> 02:53.960 what is my goal to achieve within this certain time period. 02:53.970 --> 02:59.000 Are there things like blockers what might be preventing me from being able to achieve those goals. 02:59.130 --> 03:04.740 Very quick meetings that allow us to get together move quickly and move on to the next step of a project 03:05.040 --> 03:05.720 again. 03:05.780 --> 03:07.590 There's a lot more to Agile folks. 03:07.590 --> 03:12.660 I just want to make sure that we understand the waterfalls kind of old fashioned whereas agile is very 03:12.660 --> 03:14.150 very common today. 03:14.520 --> 03:21.090 The big thing I want to talk about here is twofold number one I want to talk about the idea of dev ops 03:21.450 --> 03:28.320 dev ops is basically the methodologies and tools that we allow for not only development but also operations 03:28.380 --> 03:32.760 Ergo dev ops to work together to get product out the door. 03:32.760 --> 03:36.680 And then after this we'll talk about security of ops which means to add some security. 03:36.690 --> 03:38.610 So lets start with dev ops. 03:38.610 --> 03:44.490 Now if you take a look in front of you here is a great idea of what a dev ops plan would look like. 03:44.490 --> 03:50.580 The important thing is that we include development and operations just because a product's been delivered. 03:50.580 --> 03:54.510 That doesnt necessarily mean that its life span is over with. 03:54.510 --> 03:56.090 We're constantly working on him. 03:56.130 --> 03:59.450 And here is one example of one way to look at dev ops. 03:59.490 --> 04:03.800 So I'm going to be starting cutting here in the middle going to the upper left. 04:03.810 --> 04:05.820 So first of all we're going to have a plan. 04:05.910 --> 04:08.700 This plan is where we really develop the requirements. 04:08.700 --> 04:12.840 What are we going to need this particular application or tool to do. 04:12.840 --> 04:16.260 Second is create And here's where we actually do the development. 04:16.290 --> 04:19.150 Here's where we're going to write the code and start putting it all together. 04:19.960 --> 04:25.810 Third is verify verify is just simply saying let's test this thing and we can test it all kinds of different 04:25.810 --> 04:32.920 levels sandbox where we might want to do Forth is package just because we think the products done we 04:32.920 --> 04:36.040 always need to have some type of managerial approval. 04:36.040 --> 04:37.810 And that's what package is all about. 04:38.750 --> 04:40.570 Next is release. 04:40.700 --> 04:43.640 Now once we have it how are we going to get it out there. 04:43.640 --> 04:45.880 So here we're going to be talking about provisioning. 04:45.920 --> 04:51.530 Are we putting it in a box and burning the optical media or are we just uploading it to a cloud whatever 04:51.530 --> 04:52.550 it might be. 04:52.610 --> 04:59.720 And then also schedules What does the timeframe for the release of this product next is configure. 04:59.910 --> 05:03.230 In this case what we're talking about is that the application is up. 05:03.300 --> 05:08.250 What forms of configurations do we need to deal with and more importantly what type of configurations 05:08.250 --> 05:12.890 do users need to deal with in terms of configuring this particular application. 05:13.230 --> 05:14.520 And last as monitor. 05:14.580 --> 05:16.860 Now that everything's up and running and configured. 05:16.920 --> 05:18.240 Let's watch this thing. 05:18.240 --> 05:23.280 Are we having any problems with security or are we having any problems with memory tools whatever it 05:23.280 --> 05:24.070 might be. 05:24.180 --> 05:27.630 Monitoring is how we watch to make sure everything's OK. 05:27.870 --> 05:33.930 And as a result of changes Donis by monitoring we go right back to plan. 05:33.980 --> 05:36.700 So the power of dev ops is that it's a cycle. 05:36.770 --> 05:41.930 And it makes sure that we always stay within the lifecycle of a particular application. 05:41.930 --> 05:44.450 So it's always running the best that I possibly can. 05:44.450 --> 05:46.220 And we always have good security. 05:46.220 --> 05:51.950 Now speaking of security there are a few issues that come into play within the dev ops cycle that I'm 05:51.950 --> 05:54.030 going to call secure dev ops. 05:54.050 --> 05:59.360 So really all I want to do is make mention of a few important points and what they mean and why we should 05:59.360 --> 06:02.800 be thinking about these in a dev ops environment. 06:02.810 --> 06:06.200 Number one runs security automation tools. 06:06.350 --> 06:10.800 We are constantly running all forms of security automation tools. 06:10.790 --> 06:12.620 What I'm talking about security automation. 06:12.710 --> 06:18.760 It can be anything from fuzzy tools to static testers to intrusion detection. 06:18.770 --> 06:21.500 Anything within that cycle we need to be running. 06:21.500 --> 06:23.280 So it's not just in the monitor part. 06:23.300 --> 06:31.040 It's a continuous process of running security automation tools to make sure we haven't missed a vulnerability 06:31.040 --> 06:33.880 or malware or whatever it might be. 06:33.890 --> 06:39.680 The other thing I want you to think about is adding strict change management and version controls. 06:39.900 --> 06:45.900 If people make changes within applications changes are going to happen and that's a good thing because 06:45.900 --> 06:47.460 that's how we get paid. 06:47.490 --> 06:50.050 We must have very very strict controls on that. 06:50.070 --> 06:55.330 We must have very clear paths very clear approvals of these changes and making sure everything's well 06:55.330 --> 06:56.360 documented. 06:56.370 --> 06:59.710 A big part of this is what we call continuous integration. 06:59.730 --> 07:04.330 You've got five or six different people working on one particular application. 07:04.380 --> 07:10.050 We always want to put them all together at the end of the day as each person adds their one little piece 07:10.410 --> 07:12.060 to the main code itself. 07:12.060 --> 07:15.220 Continuous integration on a daily basis is critical. 07:16.010 --> 07:22.190 Next is baselining And what I'm talking about baselining I'm talking about baselining security objectives 07:22.670 --> 07:26.560 what are the absolute critical things that we want in terms of security. 07:26.600 --> 07:32.090 We must make sure that we have good encryption for all exposed database. 07:32.090 --> 07:39.300 We must make sure that we have powerful input validation for any dialog box whatever you choose. 07:39.350 --> 07:44.060 Those are your baselines and you have to make sure that you're sticking up with these and making sure 07:44.060 --> 07:49.500 you're doing what the baselines define and the last one is actually kind of interesting and that is 07:49.700 --> 07:55.980 recognize immutable systems when I'm saying an immutable system I'm saying about any type of system 07:56.010 --> 08:02.820 that once you're done with it it goes out the door and immutable system does not have the same ability 08:03.030 --> 08:06.820 as a regular system to be within a development cycle. 08:07.200 --> 08:12.670 You might have some type of embedded firmware device or you might even have and this is interesting. 08:12.710 --> 08:14.040 A virtual machine. 08:14.040 --> 08:21.390 In most cases a VM isn't edited or changed a VM is usually just thrown away and we add a new VM into 08:21.390 --> 08:21.840 it. 08:21.990 --> 08:27.750 So when we're thinking about immutable devices we have a whole level of security simply because they 08:27.750 --> 08:30.170 can't really be a part of the cycle. 08:30.210 --> 08:33.870 They're thrown away and a new immutable device is added. 08:33.900 --> 08:35.390 Did I say that was the last one. 08:35.400 --> 08:37.210 I got one more for you. 08:37.410 --> 08:42.990 I want you to think about the concept of infrastructure's code what we're talking about here is that 08:43.260 --> 08:49.650 if I have a virtual machine for example or what if I have 200 virtual machines there's a real temptation 08:49.650 --> 08:56.370 for techs to want to go and manually make configurations on individual machines setting up memory sizes 08:56.370 --> 09:01.080 setting up screen size and setting up whatever it might be. 09:01.230 --> 09:07.500 DHC versus static addresses setting up how the patch updates take place. 09:07.990 --> 09:10.660 We want to avoid that whenever possible. 09:10.690 --> 09:14.480 So what we do instead we use infrastructure's code. 09:14.530 --> 09:19.990 So what we create are preset definition files and every platform does this. 09:19.990 --> 09:21.210 There is no exception. 09:21.310 --> 09:27.070 Sometimes it's interesting to figure out how do we plug a piece of configuration code in for a Ubuntu 09:27.100 --> 09:28.190 Linux VM. 09:28.210 --> 09:36.630 But it can be done and the whole idea behind this is that we avoid the whole manual configuration disaster. 09:37.030 --> 09:37.930 All right. 09:37.930 --> 09:43.240 So when we're talking about dev ops and development make sure you're comfortable with two big things. 09:43.240 --> 09:48.760 Number one make sure you're comfortable with the idea of waterfall versus agile and also make sure when 09:48.760 --> 09:54.160 we're talking about dev ops that we understand the dev ops cycle versus what are the things we have 09:54.160 --> 09:56.920 to do to make that dev ops secure.