5 hours 54 minutes

Video Description

This lesson focuses on assessment and corrective actions. Corrective actions include the following: • Mitigation risk • Transfer risk • Avoid risk This lesson also discusses addressing defects; which focuses on correcting any defects that come up in the developmental stages as well as secure software testing.

Video Transcription

So we've looked at the vulnerabilities. We've done our stands. We've done our penetration test. We found some vulnerabilities. We were able to exploit them. We found issues of noncompliance with policy. What next? And the final step here really is documentation.
So we're going to assess the impact of what we found.
And then we'll also suggested a sort of corrective actions. So we're gonna produce a document called the Defect Report.
And for each of the defects that we find, we're gonna indicate how urgent and how severe the vulnerability is. When we talk about urgency, What we're talking about is criticality. We're talking about time sensitivity. How quickly is this that need? Is this something that needs to be,
modified or mitigated and then severity? What is the potential for loss based on the level of vulnerability that's discovered?
So this information is gonna submit it or is going to lead us to the corrective actions and the corrective actions go right back to risk management. What are we doing? We look to reduce except transfer risks. We can reduce the risks sometimes referred to as mitigating.
So if we determine the flaw, we can fix that flaw
and that will mitigate the risk associated with the flaw.
We could transfer the risk, and the idea of a high risk transference is, let's say that in our software we find a specific piece of function that has a vulnerability.
We don't have time to fix this problem, So what we could do is not include that specific piece of functionality. We could postpone that function until the next release of our system. Our of our application,
where we have the time in the effort in the resource is to fix that. So we're transferring the risk to our next project, and we'll feel will essentially deal with it. Then
we can avoid risk by not using the software at all. We're replacing the software or replacing the function or not even using the function at all would be risk avoidance. And at some point in time, we do risk acceptance. Remember, if we determine that the potential for loss is so low
that it doesn't justify the expense of mitigation and we'll just accept the risk.
And that's also Ah ah, very valid response. As a matter of fact, we accept many risks because when we look at the environment in which this system or the software's gonna be placed. We decide that even though there may be a an inherent vulnerability of the software, it may
be implemented in such a secure environment that that vulnerability really isn't a problem.
For instance, that this software is gonna be installed on a sub net that has no network access, no outsider external capabilities. Then we may go ahead and accept whatever risk is associated with the production of the code. So with the assessment, we want to figure out how critical or how urgent the flaw is,
and then water the corrective action strategies
fix the problem
when we talk about addressing the defects. The idea is, when we do find a defect, we want to fix the defect in the development environment or were writing the code. Let's find our problems and let's give it to the developers. The developers are gonna be the ones that are gonna want to correct the flaws.
Then we want to find out if the solution actually fixed the problem through testing. So we move on to the testing environment, and if things work now, it passes are penetration test our vulnerability stands, then we're good.
If not, we go right back to the drawing board and go right back to implementation.
Um, if it does pass the tests, then we're gonna take that software to use her acceptance testing and allow our users to test it for functionality.
User acceptance testing is really one of the last things that we do before the official release of the software. If the user's except the software and it meets all of their tests and all of their requirements, then we'll go through some of the final finishing stages. And we're very close to turning that software
over to the customer for their acceptance
and then implementing the software.
All right, this is gonna wrap up the secure software testing factor like I mentioned is not a very long chapter. Just go some of the through some of the principles off software testing. So we talk about quality. Assurance is roll. We talked about the testing artifacts like test case tests, planned test strategy,
and then we go through the various types of testing, whether it's scanning or penetration testing
and then our corrective action plan. So all of these elements describe the process of secure software testing

Up Next

ISC2 Certified Secure Software Life-cycle Professional (CSSLP)

This course helps professionals in the industry build their credentials to advance within their organization, allowing them to learn valuable managerial skills as well as how to apply the best practices to keep organizations systems running well.

Instructed By

Instructor Profile Image
Kelly Handerhan
Senior Instructor