Threat Risk Assessment

suporting docs:

• https://www.sans.org/reading-room/whitepapers/auditing/overview-threat-risk-assessment-76
• https://www.cse-cst.gc.ca/en/system/files/pdf_documents/tra-emr-1-e.pdf

Differentiators:

• Utility of reporting to client:
  • We always provide context to the client organization in our reporting, and in our testing approach. What does this mean for your environment?
  • Executive summaries available as a condensed document or presentation, to ensure results are meaningful to a non-technical audience. E.g. this could include an auditor or executive. Ensure attention is drawn to the right risks.
  • Consultant narrative is provided for every vulnerability, providing context and guidance.
  • Simple, useful classification of vulnerabilities is used. Easier to digest for the report audience.
  • Appendices: Succinct visual examples provide: e.g. Results of intelligence gathering, scripts/letters used in social engineering attempts, results of goal-based pen tests.

• Standards-based:
  • We test against a standard, not just something we came up with. We use Pen Test Execution Standard for general methodology. OWASP testing guide. NIST SP800-115. Web app, network, social engineering, etc, will have different standards.

• Application of human expertise and analysis:
  • We don’t just emphasize tools. Use more manual searches and are generally more thorough than our competitors.
  • We leverage the intelligence we are able to gather in preliminary phases, OSINT (e.g. process documentation), when social engineering is conducted.
  • Threat modeling isn’t always done by competitors, identifying likely attackers and their current techniques.
  • Heavy emphasis on manual testing in vulnerability analysis (e.g. use of nmap, Sparta), especially compared to an individual contractor. A lot of time guiding the tools against likely vulnerabilities and conducting analysis of findings to find other potential vulnerabilities. E.g. brute forcing admin consoles we discover, where a Nessus scan will return nothing. We don’t just validate scanner results, we analyze and re-test based on our knowledge.
  • For web application testing, manual testing is even more important. Manual tests are required to test the most basic business logic exploits.
  • Sometimes it is worth asking how much time our competition has allotted to specific activities. A lot of the times it doesn’t add up… you can’t test and report on a complex web application in a day.
  • Emphasize talent. The bios the customer has provided, are they the ones doing the testing? Or are they business owners?
  • Vulnerability details are not limited to what Nessus provides. Web application vulnerabilities are written by the Risk Advisory team. (edited)

Threat, vulnerability, risk – commonly mixed up terms

source: http://www.threatanalysis.com/2010/05/03/threat-vulnerability-risk-commonly-mixed-up-terms/

What are the most commonly mixed up security terms? Threat, vulnerability, and risk. While it might be unreasonable to expect those outside the security industry to understand the differences, more often than not, many in the business use these terms incorrectly or interchangeably. Maybe some definitions (from Strategic Security Management) might help….

Asset – People, property, and information. People may include employees and customers along with other invited persons such as contractors or guests. Property assets consist of both tangible and intangible items that can be assigned a value. Intangible assets include reputation and proprietary information. Information may include databases, software code, critical company records, and many other intangible items.

An asset is what we’re trying to protect.

Threat – Anything that can exploit a vulnerability, intentionally or accidentally, and obtain, damage, or destroy an asset.

A threat is what we’re trying to protect against.

Vulnerability – Weaknesses or gaps in a security program that can be exploited by threats to gain unauthorized access to an asset.

A vulnerability is a weakness or gap in our protection efforts.

Risk – The potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability.

Risk is the intersection of assets, threats, and vulnerabilities.

Why is it important to understand the difference between these terms? If you don’t understand the difference, you’ll never understand the true risk to assets. You see, when conducting a risk assessment, the formula used to determine risk is….

A + T + V = R

That is, Asset + Threat + Vulnerability = Risk.

Risk is a function of threats exploiting vulnerabilities to obtain, damage or destroy assets. Thus, threats (actual, conceptual, or inherent) may exist, but if there are no vulnerabilities then there is little/no risk. Similarly, you can have a vulnerability, but if you have no threat, then you have little/no risk.

Accurately assessing threats and identifying vulnerabilities is critical to understanding the risk to assets. Understanding the difference between threats, vulnerabilities, and risk is the first step.