software development modules.
Security system development lifecycle S. S D L C R. Security Development Lifecycle S. D. L. Um
that is defined as certification and accreditation by the federal government's
validating that implemented systems are configured and operating as inspected. So there is a whole risk management framework process out there that the federal government goes through a CZ part of their validation. Their certification and accreditation process, also known as the assessment and authorization process
a robust set of security controls on how they're implemented and how their excess, making sure that they're implemented correctly, operating as intended and producing the desired outcome
that is required for those security controls. So that's the whole part of the validation testing
when you go there for compliance purposes. So during the system development lifecycle, these places need to be making sure that they're going through that same accreditation process that the federal government is going through to maintain.
You know, the ease of transition when you're going through these processes, because if they're developing, you know, unsecure components that are not going through these the rigorous testing that the federal government goes through, it's going to be harder to sell and get their products implemented in the federal government system. So
that's the whole part of this validation testing that you see out there
is that they're requiring during the system development life cycle that they're using. The same process is that you know, the D. O. D. And the federal government uses for their acceptance criteria to bring those systems in acceptance. Testing. You have two types of assistant acceptance testing.
One is black box, and that's testing under the assumption that the inner logic is not
So you must examine the inputs and outputs. So that's where there you have no knowledge of the software. You're testing it from a
adversarial perspective. You know, trying to run sequel commands are injection techniques into, you know, the Web application, the test to see what kind of inputs and outputs that you received from the system. That, of course, you have the white box texting, which you use when the code or the inner workings of the application are known,
s so that's when you're testing it, where you you know what the code is built. You know what's deliverable when you're just testing it for the functionality that make sure that it is delivering what you say and what you have programmed to. D'oh!
So there are a couple different security
Impala implications. During the development process,
you have three different processes that are used out there for development. She have the agile, the waterfall and the spiral agile. You know, each
person early in a product is coded individually and then brought together. Waterfall is where one step is done and continually flows down the process to give you your delivery ble
agile with a lower case,
uh, to emphasize that this word is not a proper now
eyes a collection of related ideas all premised on a single essential observation.
The requirement for most software are not known ahead of time and cannot be known ahead of time. It will change before you're finished. So it is basically been around for a long time.
Part of the manifesto for agile software developments. So for the requirements, you don't know you're just working on a small piece
of that requirements. So you don't know what the end outcome is going to be, and it's just gonna be put together. They're the end before you're finished and it's going to change over time. That's the whole part of being the agile software development.
so individuals and interactions over processes and Tools, the working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change following a plan.
So you're looking at those individuals and interactions over the processes of tools being used. Comprehensive documentation, the working software, how it works,
the collaboration from the contracts from the customers,
making sure that you know during the negotiation, you know, this is what they want. These air deliver bols that are met and then, of course, responding the changes following a plan. You know, customer's change your mind. It's going to change over time, deliver balls or pushed back yester Customer wants this instead of this. You know it's during the development process. Things change.
How do you respond to those changes?
You know, Do you have a plan for those changes effect. You know what you're doing within the system,
The goal of agile is to embrace uncertain requirements, focus on an incremental improvements,
release early and often get feedback as soon as possible,
and to reiterate Google Comb releases a new version every six weeks.
They're going to release. They're going a bit Crume every six weeks.
Why? Because they want to get it out there. They want to do small changes, small, incremental improvements over time. Instead of doing and waiting to do a quarterly rollout where they might have 60 or 70 security features that have been improved. They might do it in every six weeks where they doing little bits and pieces at a time.
So in case something happens or something changes
down the road, they could make those changes pretty quickly.
So you have your deliverables.
For that, you have your requirements that are defined in the
the very first stages. You know that's implemented here by the blue section.
Then you have your design phase
portrayed there in yellow,
then the implementation quality assurance and and finally, the acceptance test. When you deliver it so you can see all those little bits and pieces,
you know, go back and forth, you know they go implementation, do some quality assurance testing from the customer, go back to mawr implementation and design features back to the customer, you know, for the implementation of quality assurance and you see it's an ever changing
you know realm when you meet the delivery bols.
The waterfall model is the classic enterprise development model.
All high level activities, requirements planning que es
proceed in basically a lockstep no design documents, for example, until the requirement phase is completely done. Projects are typically one or more years in duration where you're meeting that one requirements before you're locked into the to the next step.
So they define all the requirements before they can even remove
move to the high level design.
So once the high level design is done and they transition into their detailed design. So, as I said, it's not a changing process when it gets delivered. So it's This is what we do. This is what the customer wants. This is what they decided on. This is our design documentation,
our implementation quality assurance than final acceptance. There's no change that goes back and forth between into what you get at the delivery. Ble is what you get.
Spiral is great for large products.
Each face has a design goal and ends with a client. Review.
Analysis and engineering are applied in each project. Phase risk assessment is conducted in each phase very slow and link Lee to complete.
So when you're looking at the spiral making sure that you, you know, handle that, yes, it is very thorough. Risk assessments are done, but it's very complete.
They're delivered, you know, with what the customer wants,
the secure development life cycle and many discussions of software development. Life cycles security isn't mentioned.
So now we're wanting them to provide US security delivered
in the life cycle. When it in the planning face, we want people thinking about We want developers thinking about security up front instead of delivering us a piece of equipment that's wide open and has a lot of security vulnerabilities that we now, as security engineers and security practitioners, have to lock down and harden
to our regulatory requirements. We want to make our threats.
They call it the attack surface from being the size of a 16 inch pizza down to maybe a small nine inch pizza. You know, helping that security come down to a smaller level that's more manageable from the organization side
Too often, security is treated as an afterthought.
accreditation is usually started only after a system is completely finished. So during the r M F process in the
federal government and the d o d ah, the accreditation process is once the system is completely finishing and installed, it starts its accreditation process. It starts looking at security were wanting to change that. So when the R. M F was updated this you know, in the last couple of years
they're requiring these organizations to look at Service's and acquisitions
in the forefront and put information security as a discreet line item budget. You know, we want security upfront in that contract. Written that what? Making sure that what we get the deliver to us is as secure as possible. So it makes our job easier A security professionals to lock down those systems.
So how security works in most organizations,
so organizations they look at Okay, we look at our business requirements.
We gather all the business requirements. What are they required to do?
You know, high level design, sketch something out. You know, this is where our design would go into a detailed design, implementation quality assurance, and then we start our security accreditation at the organization level.
That's the way it's working. We don't want to be there. We want to have security controls and security accreditation moved to the earlier phases of the system development lifecycle to incorporate security upfront versus there at the end.
So this is how security ought to work. So, you know, we gather the business requirements, right?
We look at that high level design,
what? Security requirements are gonna be required for delivery. You know, the customer requires this That requires this type of security, you know, making sure of it's a web application. And, uh, here's to all the old WASP security stuff for the Web applications security protocols. You know, we want to make sure that they handle all that stuff in that design process.
Then it goes down into detail design
documentation. This is where they're designing the software that coating the software. So we want to do that. Secure Design review. Secure Design Review can be done in a couple ways. It could be a peer to peer review where you hand off your code to another Pierre.
They review the code for Ares security flaws
and other type of flows that might be associated with,
you know, that system are you can use, like a program like fortify or something that runs and you put your code through. And it spits out a report of any open calls or any vulnerabilities that finds within the code itself So it could be done manually or automated, you know, for the code reviews.
But that's what we're requiring them to do. That, of course, during the implementation,
we're gonna make sure we do another code review and testing, doing an actual penetration test on the code, running it against some vulnerabilities to see if we can exploit it
and, of course, the quality assurance. And then we start our
accreditation or authorization process
because we know we have a delivered
product that is remotely secured, so that's the way it should work.