Risk analysis is the process of identifying and analyzing potential design, implementation and development state of a software component, that could negatively impact key business processes, the organization itself, functionality of a software component or some other critical infrastructure service.
Executing a risk analysis is a process which involves many facets within an organization. The more comprehensive the analysis is, the more aspects it has to cover and view the influence on the business itself.
The above cold definition doesn`t cover the entire process of the Pen Testing process, as it`s much more complex and focuses on a lot more areas to find and exploit system weaknesses. The actual generic process may involve at least the following phases:
The benefits of a Risk Analysis process are many, but to name a few:
- identify, rate and compare the overall impact of risks to the organization, in terms of both financial and organizational impacts;
- identify gaps in security and determine the next steps to eliminate the weaknesses and strengthen security;
- enhance communication and decision-making processes as they relate to information security;
- improve security policies and procedures and develop cost-effective methods for implementing these information security policies and procedures;
- put security controls in place to mitigate the most important risks;
- increase employee awareness about security measures and risks by highlighting best practices during the risk analysis process; and
- understand the financial impacts of potential security risks.
Important criteria that can be followed during a ITSEC risk analysis, are (but not limited to):
financial loss methodologies that seek to provide a loss figure to balance against the cost of implementing various controls;
mathematically derived “risk ratings” that equate risk with arbitrary ratings for threat, probability, and impact; and
qualitative assessment techniques that base risk assessment on anecdotal or knowledge-driven factors.
Each basic approach has its distinctly different merits, but they almost all share some valuable concepts that should be considered in any risk analysis. We can capture these commonalities in a set of basic definitions:
- The asset, or object of the protection efforts, can be a system component, data, or even a complete system.
- Risk, the probability that an asset will suffer an event of a given negative impact, is determined from various factors: the ease of executing an attack, the attacker’s motivation and resources, a system’s existing vulnerabilities, and the cost or impact in a particular business context.
- The threat, or danger source, is invariably the danger a malicious agent poses and that agent’s motivations (financial gain, prestige, and so on). Threats manifest themselves as direct attacks on system security.
- The impact on the organization, were the risk to be realized, can be monetary or tied to reputation, or it might result in the breach of a law, regulation, or contract. Without a quantification of impact, technical vulnerability is hard to handle—especially when it comes to mitigation activities.
- Probability is the likelihood that a given event will be triggered. It is often expressed as a percentile, although in most cases, probability calculation is extremely rough.
- A vulnerability is a defect or weakness in system security procedure, design, implementation, or internal control that an attacker can compromise. It can exist in one or more of the components making up a system, even if those components aren’t necessarily involved with security functionality. A given system’s vulnerability data are usually compiled from a combination of OS- and application-level vulnerability test results, code reviews, and higher-level architectural reviews. Software vulnerabilities come in two basic flavors: flaws (design-level problems) or bugs (implementation-level problems). Automated scanners tend to focus on bugs, since human expertise is required for uncovering flaws.
- Countermeasures or safeguards are the management, operational, and technical controls prescribed for an information system that, taken together, adequately protect the system’s confidentiality, integrity, and availability as well as its information. For every risk, a designer can put controls in place that either prevent or (at a minimum) detect the risk when it triggers.