As much as we'd like to think otherwise, code does not magically appear on its own. Nor does code appear if we just throw some ideas to a bunch of programmers and let them come up with something. So what we need is some type of framework, some type of organizational process that allows us to do development to get that code out the door. Now, if you want to go old school, there is a development model known as waterfall. So let me put up an example of waterfall for you here. Now, as you look at this, you're going to see that we have little boxes with discrete steps.
And we'll even put it in a step pattern like that. So water could come dripping down from one box to the next. What we're looking at here, like for example, the first thing on this example is requirements. What are the requirements for this particular application, and then design as we're designing how this is going to work, implementation, whatever it might be, waterfall processes and these are very old school have been For a long time, so you're you're very locked in to. Additionally, whatever the requirements are, even if the requirements might need to change. You're very phased driven.
Everything is so rigid as we go from one step to the next. A number of years ago, a bunch of software developers got together and said, this is not a good philosophy. We need to think about an alternative way to do development outside of this waterfall, and they came up with a philosophy called agile. Now, there are entire courses on agile that can go into great detail. But for the exam, what I want us to understand is that agile by itself is a philosophy that says waterfall is not the way to do it. Agile says things like individuals and interactions are more important than processes and tools.
Agile says things like working software is more important than comprehensive documentation. Agile is going to say things that would include customer class. over just a contract negotiation, it would say things like responding to change over just following a plan. The word about agile is flexibility and being able to move and be able to move quickly with adjustments and needs to get that software out the door. So how do we do this? Well, there's hundreds of different tool sets within the Agile philosophy.
But a couple that I might want to bring to mind is, for example, the sprint, the sprint is okay. We have a very short amount of time, a week, a day, whatever it might be, where we have a certain number of things that we want to get fulfilled. Let's get that deadline and within that sprint time period, let's achieve what we can achieve. Another thing might be the scrum. A Scrum is a quick meeting, a very short meeting, often standing up there where you basically talk about, you know, what have I achieved what is my goal to achieve within this certain time period? Are there things like blockers what might be preventing me from being able to achieve those goals very quick meeting that allow us to get together, move quickly and move on to the next step of a project.
Again, there's a lot more to agile folks, I just want to make sure that we understand that waterfall is kind of old fashioned, whereas agile is very, very common today. But the big thing I want to talk about here is twofold. Number one, I want to talk about the idea of DevOps. DevOps is basically the methodologies and tools that we allow for not only development, but also operations Ergo DevOps, to work together to get product out the door. And then after this, we'll talk about secure DevOps, which means to add some security. So let's start with DevOps.
Now, if you take a look in front of you, here is a great idea of what a DevOps plan would look like. The important thing is that we include development and operations, just because the products been delivered, that doesn't necessarily mean that its lifespan is over with, we're constantly working on them. And here's one example of one way to look at DevOps. So I'm going to start Starting kind of here in the middle going to the upper left. So first of all, we're going to have a plan. This plan is where we really develop the requirements, what are we going to need this particular application or tool to do.
Second is create. And here's where we actually do the development. Here's where we're going to write the code and start putting it all together. Third is verify, verify is just simply saying, Let's test this thing. And we can test it all kinds of different levels, sandbox, whatever you might want to do. Fourth is package just because we think the products done we always need to have some type of managerial approval.
And that's what package is all about. Next is release. Now, once we have it, how are we going to get it out there? So here we're going to be talking about provisioning? Are we putting it in a box and burning optical media? Are we just uploading it to a cloud, whatever it might be, and then also schedules what is the timeframe for the release of this product.
Next is configure This case, what we're talking about is that the application is up, what forms of configurations Do we need to deal with? And more importantly, what type of configurations do users need to deal with in terms of configuring this particular application? And last is monitor Now that everything's up and running and configured, let's watch this thing, are we having any problems with security? Are we having any problems with memory tools, whatever it might be, monitoring is how we watch to make sure everything's okay. And as a result of changes don't just by monitoring, we go right back to plan. So the power of DevOps is that it's a cycle.
And it makes sure that we always stay within the lifecycle of a particular application. So it's always running the best that we possibly can. And we always have good security. Now speaking of security, there are a few issues that come into play within the DevOps cycle that I'm going to call secure DevOps. So really, all I want to do is make mention of a few important points and what they mean and why we should be thinking about them. These in a DevOps environment.
Number one, run security automation tools. We are constantly running all forms of security automation tools. So what I'm talking about security automation, it can be anything from fuzzer tools to static testers, to intrusion detection, anything within that cycle, we need to be running. So it's not just in the monitor part. It's a continuous process of running security automation tools to make sure we haven't missed a vulnerability or a malware door, whatever it might be. The other thing I want you to think about is adding strict change management and version controls.
If people make changes, and within applications changes are going to happen, and that's a good thing because that's how we get paid. We must have very, very strict controls on that. We must have very clear paths, very clear approvals of these changes, and making sure everything's well documented. A big part of this is what we call continuous integration. You've got Five or six different people working on one particular application, we always want to put them all together at the end of the day, as each person adds their one little piece to the main code itself, continuous integration on a daily basis is critical. Next is baselining.
And when I'm talking about baselining, I'm talking about baselining. Security objectives. What are the absolute critical things that we want in terms of security, we must make sure that we have good encryption for all exposed database, we must make sure that we have powerful input validation for any dialog box, whatever you choose. Those are your baselines, and you have to make sure that you're sticking up with these and making sure you're doing what the baselines define. And the last one is actually kind of interesting, and that is recognize immutable systems. When I'm saying an immutable system, I'm saying about any type of system that once you're done with it, it goes out the door and immutable stuff.
Does not have the same ability as a regular system to be within a development cycle. You might have some type of embedded firmware device, or you might even have and this is interesting, a virtual machine. In most cases, a VM isn't edited or changed. A VM is usually just thrown away and we add a new VM into it. So when we're thinking about immutable devices, we have a whole level of security simply because they can't really be a part of the cycle. They're thrown away, and a new immutable device is added.
Did I say that was the last one, I got one more for you. I want you to think about the concept of infrastructures code. What we're talking about here is that if I have a virtual machine, for example, or what if I have 200 virtual machines, there's a real temptation for text to want to go and manually make configurations on individual machines, setting up memory sizes, setting up screen size and setting up whatever it Might be DHCP versus static addresses, setting up how the patch updates take place. We want to avoid that whenever possible. So what we do instead, we use infrastructures code. So what we'll create our preset definition files and every platform does this there is no exception.
Sometimes it's interesting to figure out how do we plug a piece of configuration code in for a boon to Linux VM, but it can be done. And the whole idea behind this is that we avoid the whole manual configuration disaster. Who, alright, so when we're talking about DevOps and development, make sure you're comfortable with two big things. Number one, make sure you're comfortable with the idea of waterfall versus agile. And also make sure when we're talking about DevOps that we understand the DevOps cycle, versus what are the things we have to do to make that DevOps secure.