Secure Deployment Part 1

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
or

Already have an account? Sign In »

Time
9 hours 59 minutes
Difficulty
Intermediate
CEU/CPE
10
Video Transcription
00:01
>> Objectives for this video include,
00:01
going over automated deployments and discussing how
00:01
application security tests can be
00:01
integrated into your automated deployment pipeline.
00:01
In the top diagram, I've laid out steps of
00:01
secure design and development metaphase.
00:01
You may recall we saw that in
00:01
a circular type fashion previously.
00:01
That circular form more accurately represents
00:01
the reality of iterations and
00:01
constant change in technology work.
00:01
But since we are talking about deployment pipelines,
00:01
my focus shifts a little bit to
00:01
the development and test phases.
00:01
Deployment is the process of promoting
00:01
application codes between environments.
00:01
I have a simple example of three environments,
00:01
Dev, QA, and Production.
00:01
But it's very common to have
00:01
a layout with more environments.
00:01
As updates progress from each environment,
00:01
quality checks are performed.
00:01
This mitigates the risk of the update introducing
00:01
application defects or security vulnerabilities.
00:01
Deployment pipelines are becoming
00:01
more and more automated in the sense of
00:01
both promoting the app updates
00:01
themselves to the different environments,
00:01
and also building the environment
00:01
itself, leveraging infrastructures code.
00:01
This automation offloads work
00:01
for individuals that would have
00:01
historically performed these tasks and in many cases,
00:01
it introduces new activities that would have not
00:01
been reasonably achievable by a person.
00:01
We're going to discuss the quality gates in
00:01
a deployment pipeline to help ensure security.
00:01
It's ironic that I tell you all
00:01
about automating the pipeline,
00:01
but the first most common step is a manual gate.
00:01
Code reviews are the modern day equivalent
00:01
to a desk check.
00:01
This is where one engineer would
00:01
review the work of another engineer.
00:01
Typically this was done with
00:01
two individuals standing next to each other at a desk,
00:01
writing comments on blueprints
00:01
or other mechanical designs.
00:01
Same concept in the academic world.
00:01
In that world you have researchers provide
00:01
copies of materials to peers for feedback.
00:01
This is done before publication
00:01
and often the author's credentials will be
00:01
completely removed from the paper to reduce reader bias.
00:01
Each piece of work has to stand on its own merit
00:01
regardless of the writer previously
00:01
received a Nobel Prize or not.
00:01
In a code review, one or more peer developers
00:01
review the code changes of another.
00:01
This process relies heavily on using
00:01
source control systems such
00:01
as the current market leader get,
00:01
to provide a red line view of
00:01
which content of which files was changed.
00:01
These reviews often rely on
00:01
checklists and criteria so the reviewer
00:01
keeps in mind areas of focus
00:01
such as architectural guidelines,
00:01
calculation algorithms and their performance
00:01
of executing those,
00:01
maintainability of the code,
00:01
testability of the code.
00:01
There are some other points you'll want to keep an eye
00:01
out when looking at code that will run in the Cloud.
00:01
Calls to the management plane.
00:01
For example, is the application itself
00:01
telling the Cloud to create a new virtual machine?
00:01
Authentication and encryption.
00:01
Applications run with least privileged entitlements.
00:01
Regardless if an application
00:01
interacts with the management plane,
00:01
it may be communicating between different paths services.
00:01
This communication can bring with
00:01
it a Cloud-based identity.
00:01
For example, serverless application wants to write files
00:01
to a storage location or
00:01
place messages in a message queue.
00:01
That serverless app needs to
00:01
somehow authenticate with those services.
00:01
There are many ways to do this,
00:01
but a powerful one is to control
00:01
those interactions at the Cloud plane.
00:01
You create an identity for
00:01
the serverless application and
00:01
give it a minimal set of privileges,
00:01
just enough that it can write to
00:01
storage and queue a message, but nothing more.
00:01
This way, if the serverless app itself gets compromised,
00:01
the Cloud plane is restricting.
00:01
If you've heard of defense in depth,
00:01
this is a great example.
00:01
Testing cubed, testing to the third power,
00:01
whatever you want to call it.
00:01
Unit testing is where you ensure discrete parts
00:01
of the application code are working as expected.
00:01
Developers themselves often create the unit tests.
00:01
Regression testing is when you make sure that what
00:01
used to work still works.
00:01
Functional testing is where you verify
00:01
expected capabilities and behaviors of the application.
00:01
In testing paradigm you want to
00:01
automate as much as possible.
00:01
There are many software frameworks and products both
00:01
commercial and open stores that help accomplish this.
00:01
Effectively, you end up writing
00:01
lots of miniature programs that
00:01
themselves end up ensuring
00:01
quality in the software product that's being produced.
00:01
Static application security testing
00:01
is focused on the code.
00:01
It's like a computer conducting a code review,
00:01
but it can't detect if there are
00:01
any errors in the business logic.
00:01
However, it's very good at detecting errors and
00:01
vulnerability in the code constructs themselves,
00:01
such as poor memory management or memory access controls,
00:01
which can lead to buffer overruns, input validation,
00:01
preventing problems such as SQL injection,
00:01
hard-coded credentials,
00:01
another very bad practice to do in your software code.
00:01
There are many different security standards
00:01
that can be enforced by different SAST products,
00:01
such as the OWAP Top 10 or the MISRA C.
00:01
Dynamic application security testing builds
00:01
on top of static application security testing.
00:01
But in this paradigm,
00:01
the application itself is running.
00:01
This is great for web vulnerability
00:01
testing such as port scanning or cookie manipulation,
00:01
as well as fuzz testing.
00:01
This is where it's sending in validly formatted messages,
00:01
throwing everything at the wall,
00:01
and seeing what sticks and
00:01
seeing as the application responds.
00:01
These activities may require provider permission
00:01
especially when you're doing them
00:01
against the past service.
00:01
More extensive assessments do take more time.
00:01
While all of this stuff is automated,
00:01
there are still performance constraints
00:01
when you perform thousands,
00:01
tens of thousands, and
00:01
hundreds of thousands of operations.
00:01
To summarize, we were focused on
00:01
the automated deployment pipeline.
00:01
In particular, the application
00:01
security testing you want to
00:01
incorporate into your deployment pipeline
00:01
, specifically,
00:01
manual code reviews,
00:01
the various methods of automated testing,
00:01
static application security testing,
00:01
and dynamic application security testing.
00:01
This is a very evolving space
00:01
and there are many different types
00:01
of tests and it's constantly
00:01
growing and there are products out there.
00:01
If you are involved in application development,
00:01
you'll definitely want to invest some time
00:01
understanding what exists and what's out there.
00:01
But for the CCSK exam,
00:01
you won't need to know the specific vendors that
00:01
provide these different tooling solutions.
Up Next