As we wrap up module 5, we find that we’ve done quite a few things already. We’ve looked at vulnerabilities, performed our scans, penetration testing, found some of the vulnerabilities, exploited those vulnerabilities, and found issues with noncompliance. So, the final step is documentation.
So, we’re going to assess the impact of what we’ve found and then we’ll also suggest corrective actions. The document will be known as the defect report. For each of the defects that we find, there needs to be a demonstration of urgency, severity, and so on because of the critical nature of the time sensitivity. Based on the vulnerability of the software, we can identify the potential for loss and this understanding of loss to lead us to corrective actions. Corrective actions help us with risk management.
There are three to four different actions that can be completed as corrective actions. They include: reduce, avoid, accept or transferring risks. We can reduce the risks, sometimes referred to as mitigating the risk. So, mitigating the risks can reduce or fix the flaws associated. We could avoid the risk by postponing the function where there’s a problem, sort of indefinitely. We basically make the decision to not include the piece of functionality or even not release the entire software until the flaw has been fixed. We could also postpone the function to the next release of our system or application when there’s a bit more time and resources.
So, the postponement transfers the risk to the next project. Then, people can upload the patch or update and the software would have the functionality that was previously a problem. Risk acceptance is the last action step that can be taken when there is a potential for risks. For example, we could figure out that the potential for loss is so low, it really doesn’t justify the expense for the strategy which would fix the vulnerability. Even if it was implemented but done so in such a secure environment, that the vulnerability isn’t such a problem, then it’s possible that the vulnerability isn’t a problem. For example, the software could be installed on a network where there are not any outward accessibilities or external capabilities, and so the vulnerability is extremely low as a risk and therefore, one that can be accepted quite easily.
So, with the assessment we want to figure out how critical or how urgent a flaw is and then what are the corrective action strategies to fix the problem. When we talk about addressing the defects, then, we find defect, we fix the defect in the development environment or in other words, in the writing of the code. The developers are the ones who are going to correct the flaws. Then, we need to double check that the problem is actually fixed. We accomplish this through testing. From the development environment, we move into the testing environment. If it passes all our pen tests, vulnerability scans, then great. However, if not, then back to the original design and decide implementation.
If it does pass the tests, then we’re going to take that software to the user acceptance testing, and allow our users to test it for functionality. User testing acceptability is really one of the last things we do before the official release of the software. If the users accept the software and it meets all of their tests, then the software will go through some of the final finishing stages and it will be very close to being turned over to the customer for their acceptances and implementation.
This is going to wrap up the secure software testing chapter.This section just goes through some of the principles of software testing. In review, at first there was discussions over quality assurances, testing artifacts, test case, test plan, test strategy. Then there was a variety of tests like the scanning types or pen tests. Our action plan is is meant for corrective actions as well as other elements of secure software testing.