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 around for a long time.
So you're you're you're very locked in to additionally whatever the requirements are even if the requirements
might need to change your very phase 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 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 collaboration 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
it 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 OK.
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 that 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 meetings 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 the waterfalls kind of old fashioned whereas agile is very
very common today.
The big thing I want to talk about here is twofold number one I want to talk about the idea of dev ops
dev ops is basically the methodologies and tools that we allow for not only development but also operations
Ergo dev ops to work together to get product out the door.
And then after this we'll talk about security of ops which means to add some security.
So lets start with dev ops.
Now if you take a look in front of you here is a great idea of what a dev ops plan would look like.
The important thing is that we include development and operations just because a product's been delivered.
That doesnt necessarily mean that its life span is over with.
We're constantly working on him.
And here is one example of one way to look at dev ops.
So I'm going to be starting cutting 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 where we might want to do Forth 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 the optical media or are we just uploading it to a cloud whatever
it might be.
And then also schedules What does the timeframe for the release of this product next is configure.
In 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 as monitor.
Now that everything's up and running and configured.
Let's watch this thing.
Are we having any problems with security or are we having any problems with memory tools whatever it
might be.
Monitoring is how we watch to make sure everything's OK.
And as a result of changes Donis by monitoring we go right back to plan.
So the power of dev ops 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 I possibly can.
And we always have good security.
Now speaking of security there are a few issues that come into play within the dev ops cycle that I'm
going to call secure dev ops.
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 these in a dev ops environment.
Number one runs security automation tools.
We are constantly running all forms of security automation tools.
What I'm talking about security automation.
It can be anything from fuzzy 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 malware or 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 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 what 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 system 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 infrastructure's 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 techs 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.
DHC 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 infrastructure's code.
So what we create are 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 Ubuntu
Linux VM.
But it can be done and the whole idea behind this is that we avoid the whole manual configuration disaster.
All right.
So when we're talking about dev ops 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 dev ops that we understand the dev ops cycle versus what are the things we have
to do to make that dev ops secure.