- In 14, six, we're gonna be talking
about application security.
And then in 14 seven we'll continue the discussion,
and talk about secure coding.
Application security is the process of developing, adding,
and testing security features within applications,
to minimize the risk of unauthorized access.
Confidentiality modification, there's our integrity,
and downtime on availability,
or think of it as availability.
Application security categories include,
secure development and coding,
code security testing,
security and privacy controls and logging.
So when we're thinking about application security,
we need to think about,
where we're developing the application,
where we're testing it, where we are assessing it,
and how we're getting it out into production.
And that whole process of planning, scheduling,
and controlling the movement of developed,
or acquired code is known as secure staging.
Now, environment in this context of secure staging,
really refers to the host device,
which could be physical or virtual, and the network,
including all of the connectivity components.
So let's look at the secure staging environments.
We have dev, test, stage, and prod.
Dev stands for development, test stands for test,
stage stands for stage or staging,
and prod stands for production.
So let's look through each of these,
secure staging environments.
The dev environment is used for code development,
for proof of concept, for experimentation,
for customization of acquired software,
and for very early stage testing.
A couple things about the dev environment,
from a security standpoint.
One, it's not trustworthy at all,
so you wanna make sure that it is not connected at all,
to the actual production or enterprise network.
Two, it's not trustworthy.
Same thing, right?
In this case,
you don't ever wanna be using any kind of data, right,
that you need to be protecting or if if it was exposed,
would have any problem or any issue at all.
So in a dev environment, we always wanna use dummy,
or de-identified or anonymized data.
So that's what's happening in dev.
Then our next phase is going to be test.
Now the testing environment is used to merge code,
ensure quality, isolate bugs,
and measure performance and functionality.
And in the test environment is where we usually
have our UAT or user acceptance testing.
That would be our alpha and beta testing.
Alpha testing is usually testing both features,
and functionality, where beta testing is looking at
functionality of all of the features.
The dev and test can be very iterative,
and it can be in development and go into test.
And then maybe there's a lot of bad code,
maybe there's a problem, something missing,
it could easily go right back into dev.
So dev and test, very iterative environments.
Then we get to the staging environment.
The staging environment is used to ensure that applications
are going to behave as expected and confirm,
that they don't adversely impact any existing applications.
So as much as possible, our staging environment,
should mimic our production environment.
This is also where we can do things like risk assessments,
penetration testing, vulnerability assessments,
because we're going to be putting those applications,
on the type of systems that we're actually using,
out in the field or out in production.
Then lastly, we get to prod or production environment.
And that's really the live environment that hosts
the application and it's the endpoint in the release
management process, but it's not really the endpoint,
of taking care of that application.
You know, we have ongoing maintenance and ongoing support.
So just a couple of other notes about prod,
that our prod planning should include deployment,
maintenance, backup, and our disaster recovery strategies.
Our developers should never have rights,
to the prod environment.
We want a segregation of duties.
And all new functionality and bug fixes,
should go through the release management cycle,
before being deployed to prod.
So meaning going through dev and test and stage,
if there is an emergency change, sometimes there might be,
if there is an emergency change,
it should be subject to change management procedures,
and vulnerability identification,
and management is an ongoing process.
So when something's in prod, even though we've developed it,
or customized that application,
we've always gotta be looking for those new vulnerabilities
and you know, any type of updates or patches,
that need to be released.
So historically, there used to be this real segregation,
of developers and operations people and security people,
but we found that doesn't work really well, right?
That the best thing we can do in an organization,
is to have collaboration.
And that's where SecDevOps comes in.
That SecDevOps is short for,
security, development, and operations,
and the idea is that we're promoting collaboration,
between the development team, the operations teams,
and the security teams.
The SecDevOps really emphasizes the shared responsibility,
of integrating security practices,
throughout the full development lifecycle,
ensuring that we're talking about security,
right from the very beginning.
So security considerations are incorporated early,
and continuously through the cycle.
Now for a developer, this is pretty cool because,
the SecDevOps approach enables developers to learn more
about what they're developing and how it could be exploited.
SecDevOps proactively focuses on survivability,
by providing this reliable software,
with a reduced attack surface.
And that's one of the most concise ways of saying this.
I love this, focuses on survivability,
by providing reliable software with reduced attack surface.
That's pretty awesome.
So let's talk through some SecDevOps automation concepts.
Security automation, continuous integration,
baseline and immutability.
Have you heard immutability before?
I think so.
Security automation is automating attacks,
against pre-production code,
and then continuous vulnerability testing,
against production code.
So we're automating attacks all the way through.
And then we continue with vulnerability attacks,
or excuse me, vulnerability testing,
even once we're into production.
Continuous integration is the continuous merging
of source code by all of the developers.
And if a failure or a fault or a bug is seen,
the team is expected to stop, refocus,
and fix the build before making any additional code changes.
So they can't say, oh yeah, we know that's there.
We'll get back to it.
It's like, nope, everybody stops, fix it before we go on.
Baseline is just a consistent agreed upon version,
of the software that serves
as the basis for future development.
And immutability, again, is the image of a system,
pre-configured to a desired known good state, right?
Succinctly using automation to replace rather than fix.
So we start testing early in the cycle, right?
And right at the very beginning at the source code, right?
We can start doing what's known as,
static application security testing or SAST.
Now, SAST is a testing methodology,
that analyzes source code to find security vulnerabilities.
Now it takes place very, very early,
in the software development lifecycle,
because it doesn't require a working application,
and it can take place without the code being executed.
It can scan the application,
before the code is even compiled.
Now, SAST tools give de developers real-time feedback,
as they code helping them fix issues,
before they pass the code,
onto the next phase of development.
Now, DAST, which is dynamic application security testing,
is a method of application security testing,
that examines a running application.
The DAST works by simulating automated attacks,
on the application, really behaving like,
they're the malicious attacker.
And the goal is to find outcome,
or results that were not expected.
It's like, oh, we didn't think that would happen.
And that could be used by attackers to compromise
an application like maybe a race condition.
The DAST tools include web and API scanning,
pen testing, fuzzing,
and interactive application security testing.
Now let's talk about fuzzing,
'cause it always seems to come up on the exam.
Fuzz testing or fuzzing is an automated testing
technique used to discover coding errors,
and security loopholes by inputting well,
what's known as fuzz, which is invalid,
unexpected, or semi-random data.
And then monitoring the application response.
So lots of testing going on, really incumbent,
kind of understand whether we're developing software,
or we've acquired software and we're customizing it.
We always wanna make sure that we have good, solid,
secure software in our environment.
That my friends, brings us to a three second challenge.
Five challenge questions, three seconds each.
You know how to do this, let's go.
The environment used for experimentation,
proof of concept and code development.
1, 2, 3.
This is the one I said was really pretty dangerous.
1, 2, 3,
that's dev.
Maybe I didn't say it was dangerous.
I think I just said it was untrustworthy.
This environment should mirror the production environment.
So what's this environment gonna be?
1, 2, 3.
And that's gonna be stage.
The principle of using automation,
to replace rather than fix.
1, 2, 3.
Everybody's gonna get this one right.
Immutability.
Number four, testing method that analyzes source code,
to find security vulnerabilities.
1, 2, 3.
That's gonna be SAST,
or static application security testing.
And then here's the one with the silly name.
Automated testing technique used to discover coding errors,
and security loopholes by inputting invalid,
unexpected or semi-random data.
1, 2, 3.
Fuzzing.
All right, that brings us to a security and action,
about secure staging.
Your organization is under immense pressure,
to launch an online retail store.
The marketing team has been advertising the launch date.
In-house developers have been working day and night,
to write and test the code, and they're reasonably confident
that everything is set to go.
So given the time crunch, it's been suggested,
that the site go right into production,
from the testing environment.
All right, as a security practitioner,
would you support such a move?
Okay, so, or under just this incredible pressure, right?
To get this online retail store out.
So this online retail store, right?
We're gonna have products,
it's gonna have our reputation right out there.
We're probably gonna take credit cards, right,
'cause we're gonna have to have payment.
You know, we've been advertising, the marketing department
has been advertising the launch date.
So everybody knows when it's coming,
the in-house developers are exhausted.
They've been working day and night to write,
and test the code and they say, well, you know what?
That we like our code.
You know, we're reasonably confident,
that everything is set to go.
So given the time crunch,
suggest to the site go right into production,
meaning going right from test to prod, what are we skipping?
We're skipping stage.
Are you gonna support such a move?
Put me on pause for a moment,
jot down your response and come on back.
No, no and no, this is a really bad idea, right,
to go right from test to production,
is a really, really, really bad idea.
A transition from test to prod is risky.
It could result in a negative launch,
might be reputation damage, might be financial damage,
might even be credit card compromise.
You know, if the site isn't functional or exposes customers,
to security faults and or has performance issues,
you're really much better off waiting,
than having all that happen.
The test environment does not,
does not, mirror the prod environment.
The stage environment is where our kind of real world,
security testing should always take place.
That's where we can do our dynamic application,
security testing, our penetration testing,
our vulnerability assessment,
as well as testing any rollback procedures.
So the answer, really succinctly,
was, should you support such a move?
No. (laughs)
And being able to really stand up and fight the trend,
you know that's tough to do,
and you're gonna find yourself in this situation,
at some point where from a business perspective,
they just wanna get something done,
and you're the one to say, no.
But what's really important there is,
that you can explain the why,
not just say no, but explain why,
and why your reasoning is strategically aligned,
with the good of the organization.
That my friends, is security in action, right?
There is your word cloud.
You know what to do.
I'll see you the next lesson.