Secure Deployment Part 1

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

Already have an account? Sign In »

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