he security posture of a software product is driven by how well it preserves the confidentiality, integrity, and availability of the system. The more ways that these three pillars can be negatively impacted, the weaker the overall security posture of the system. Each individual way in which one of the pillars can be negatively impacted by weaknesses in the application. There are typically two types of weaknesses: architecture flaws and coding defects.
Architecture flaws stem from design decisions or lack of coding standards. An example from the educational software would be if the system authorized students based on class or school identification codes entered in by the student rather than using student data to verify what school and class the student belong to. In this case, it would be possible for the students to guess these codes and potentially access information or work from other students in other classes or even other schools. An example of a coding standard flaw is the application not requiring specific programming calls be made before saving data to a file or database.
A defect refers to an error in code which leads to a security vulnerability. These defects, also called bugs, can happen due to developer mistakes or not enough details known about how the system will be used preventing from accurate requirements. Let’s look at the educational software and a possible situation. If the software supports group projects and each group is assigned a leader, there could be a bug where the leader can possibly remove a member of the group. This could be because of a missed authorization check or because of inaccurately assigning a role to the leader.
Each individual weakness may or may not lead to a vulnerability. A vulnerability is a specific instance of where the security of an application can be taken advantage of. For example, if the educational software allows for files to be saved, a weakness could be in a lack of virus scanning of the uploaded files. This doesn’t necessarily mean a vulnerability exists however. It maybe that those files are only accessed in certain ways or that those who do access the files scan the files before they are read. This doesn’t change that the weakness exists. The current implementation is just not negatively impacted by this weakness.
On the other hand, if the educational software does not have controls around how those files are named and there is a bug which allows for users to save files to a shared location, then the weakness does become a vulnerability in and of itself.
Once a vulnerability has been identified, threats start to emerge. A threat is how a vulnerability can be taken advantage of. A threat comprises of two parts. The threat actor and the exploit. The threat actor the person or system that executes the threat. The exploit is the actual action which degrades the security of the system.
Although, the term “threat” sounds malicious, as if the intent is to harm the system, a threat does not have to be. A threat can be someone uploading the wrong file and causing a denial of service, a user trying to get something done which is more difficult than it should be, or it can be someone trying to steal data. All of these are threats.
Understanding weaknesses, vulnerabilities, and threats, allows system owners to evaluate the risk that each of these threats have to the system. That evaluation will take into consideration what happens to the system if the threat occurs (this is called the impact, often expressed in terms of dollars or in some form of categories such as high, medium, low) and what are the chances that the threat will occur (this is called the likelihood, often expressed in a percent or a category like high, medium, or low). This risk assessment will help the team make the next decision, what to do with these threats.
Just as the risk impacts the system in a negative cost, there will be a cost to attempting to respond to the risk. A system owner can attempt to fix the underlying issue which exposes the risk (“remediate”). The owner can try to implement additional mechanisms to protect against the risk (“mitigate”). The system owner can also get someone else to take on the risk (“transfer”). Or, if those options are too costly in comparison to the cost of the risk, they system owner may just leave things alone (“accept”).
The decision on how to best handle the risk is typically based on evaluating the cost of the solution versus the cost of the threat occurring.