9 hours 59 minutes
this video is all about the secure design and development meta phase.
We're gonna take a deep dive into the different phases that that meta phases composed off Looking at each and every one of the secure design and development phases.
Here we have an overview of the five different phases within this meta phase training definition designed, developed and tests. So let's take a look at each one of these phases. Independently. All employers have some sort of training. It could be a simple is understanding acceptable use policies for company assets. It could be how to deal with clients and to converse
many different ways.
But when we're talking about a world where we're developing cloud based applications and we want to look at what are the specific security elements that we want to endure incorporate into that kind of training,
we break it down into three different roles. You have developers, operations and security people, and there's some additional training above and beyond what would normally be included for application development and operations teams that you want to add just to make sure that they have that grasp of the cloud. It would start with just provider agnostic cloud security fundamentals.
And so you'll notice that while I've given some examples of specific cloud provider things,
generally, this entire ccs que is about the fundamental securities in looking at it through a cloud agnostic lens.
And while you're developers, operations and security people don't mean to pass the CCS K exam, general training would have you taking a lot of material and content so that they have the basic fundamentals and perspective that cloud brings. Then you're gonna want to extend that and provide training that are specific to the cloud provider or cloud providers that you're using.
Additionally, the developer in operation rules are going to need to learn a bit more about the specific tools that are being used to implement security.
We talked a lot about things changing in the cloud world. Later in this module will talk about the build automation pipelines, but what you'll find is there's a lot of automation and tooling you want to put in place. And it's important that the developers and operations teams understand how this tooling works so they could be effective and using it
as we've seen so far. Application architectures, air highly influenced by compliance and regulatory standards.
So in addition to defining your application itself and how it's going to be architected,
this is a great opportunity to lay out additional non functional capabilities and guidelines that your team needs to follow. For example, it could include certain secure coding standards, such as those defined by the Software Engineering Institute or a WASP. Additionally, you may incorporate security requirements, levels of encryption required
for communication in transit or data at rest.
The need to include M F A or hardware storage modules for managing encryption keys. These are all things that are often driven by compliance. They're not functional capabilities of your application, but your application architecture needs to take these into account, so it's designed in a way that it can meet those compliance requirements.
Once you've defined the security standards and discuss the high level architecture, it's time to get into the more detailed design aspects of your application. During this phase, you want to be focused on integrating security into the architecture, leveraging cloud provider capabilities and features as much as possible. There are back platform as a service and so forth
automating security in the deployment and operations.
We'll talk further about secure deployment in coming videos, and during this phase, you'll also want to do threat modelling. On the right side, you see a simple data flow diagram, different entities, communicating with each other and sending information.
Then you have these little dashed red lines is called trust boundaries, in this case the trust boundaries defined by network segmentation and a lot of different ways to go about threat modelling. We could do a whole class on threat modelling, creating the data flow diagrams defining trust boundaries,
but just to give you a taste. So you'll examine this data flow diagram in the interdependencies between the different parts
and you'll go through a structure process asking several questions. What can happen in this flow of communication with regards to spoofing, tampering, repudiation, information, disclosure, design, I'll of service or elevation of privilege? This question set forms an acronym. Stride and Strike is one of several different methods for
performing threat. Modelling
is the one I'm personally most familiar with. I never feel like it's really gaining prevalence in the marketplace as a major method to perform threat modelling
after we've done the design ever, for we've done whiteboard hacking. Using the threat modelling technique,
we need to make sure to create the application itself.
Developers need their own environment to perform these activities. They need administrative rights in that environment, and the environment should be fully isolated from production. This restricts developers from directly altering production or getting a copy of production data. Sometimes accidents happen. Sometimes it's malicious. Sometimes the developers account could be compromised. Keep in mind the
principle of least privileges
you're gonna leverage. See, I see the pipelines to then promote application updates through the different environments the developers air working in death. They get happy with making a small inveterate of release that then gets promoted to the Q environment and subsequently will go to the production environment.
This pipeline, and especially the code going into the pipeline needs to be secured later in this module will be talking further about secure deployment.
When it comes to the test phase, automation is key.
This is where you're running functional tests. This is where you could be performing vulnerability assessments and even more advanced automation, such as dynamic application security testing.
In this video, we reviewed the five phases of secure design and development
Introduction to IT & Cybersecurity
Are you new to IT & cybersecurity and wondering which role might suit you best? ...
2 CEU/CPE Hours Available
Certificate of Completion Offered
AZ-500: Microsoft Azure Security Technologies
Azure Security Engineers are responsible for protecting against vulnerabiltieis, implementing threat protection, and responding to ...
9 CEU/CPE Hours Available
Certificate of Completion Offered