Last updated at Tue, 25 Jul 2017 17:45:53 GMT
In our last newsletter we discussed the severity of the presence of bugs in software, and how these bugs are handled on the software vendor's side. Now let's discuss the customer organization's side.
What can we do about software defects?
Software is buggy. This is a fact (see PCI newsletter #14). Returning to the analogy of protection gear used in our last newsletter, my son is constantly reminding me that wearing pants with rips and holes is actually the fashion and I should accept it. Nevertheless, I find it quite weird that the price of a piece of clothing increases with the number of scratches and holes in it.
Similarly organizations are facing a crucial dilemma:
Either leave holes in software and look like a fashion victim or wear so many patches you look like a clown. Mmmm, not a great choice. The solution is maybe somewhere in between.
The problem is that, as we discussed in our last newsletter, holes equal vulnerabilities, which equal risk for the organization.
The whole process of reducing risks associated with holes in software is called vulnerability management, a strange denomination as a vulnerability could be more than a simple hole in the cloth, I mean in software. Personally I would prefer to call this process "the holes and defects quest."
Vulnerability management plays a major part in the workload of individuals responsible for security. It is highlighted by all best practices and guidance manuals, as well as by all regulations and compliance programs, including the PCI council in the sixth and seventh verses of the Data Security Standard bible:
§6: You will develop and maintain secure systems and applications
§11: You will regularly test security systems and processes.
What is involved in a vulnerability management program?
The medical world follows a specific protocol to cure patients:
Diagnose: Identify the patient's illness based on symptoms and a panel of test results.
Determine the risk: What could the impact be for the patient if the illness is not cured?
Prescribe: Determine what remedy could be applied, if any, and the potential side effects for the patient.
Decide: Based on the above data, the doctors and the patient decide on a treatment plan.
Treatment: The patient applies the prescription.
Control: The doctors perform regular checks to make sure the cure is on working as expected.
Curing software of vendor vulnerabilities (holes, defects) follows the same protocol.
Diagnose: Identify the presence of (known) holes/defects (vulnerabilities) through a set of tests called network/system/application/database scans.
Determine the risks: Assign a risk level to each identified vulnerability accounting for the consequences of security incidents resulting from exploitation of the vulnerability, the existence of scripts (exploits) facilitating the exploitation, the nature/sensitivity of the organization, the presence of compensating controls reducing the exploit intensity, the time elapsed since the the vulnerability exposure, the existence of remedies. Penetration testing is a useful tool to help you quantify the real level of risk associated with the identified vulnerabilities.
Prescribe: List all countermeasures leading to remediation or risk mitigation as well as the additional risks (side effects) induced by the application of these remedies.
Decide: Based on the above information, determine prioritization and the more appropriate action plan, assign responsibilities.
Treatment: Follow action plan.
Control: Verify the effectiveness of the action plan through regular checks (scans).
- Did you find this article useful?
- Is your organization acting as a fashion victim or a clown?
- How do you handle vulnerability management?