I came across an interesting blog about application risk assessment today, so I wanted to highlight some of the different approaches in response.
In the blog Chris’s approach seems somewhat like threat modeling, which is typically used for code reviews. In general he covers a large part of the important content but doesn’t address the real issues of risk – Cost vs Risk. Anyway I hope to address that here and explain the two major methods used extensively. These are threat modeling and the NIST/OCTAVE asset based approach.
Threat Modeling Approach
Threat Modeling is basically the ongoing risk assessment process which covers the entire Software Development Lifecycle.
From a managerial risk assessment approach I would take a different view using a strategic NIST/OCTAVE approach.
What are the assets? (i.e. information, applications, hardware, etc.)
What are the threats? (i.e. data contamination, malicious code, equipment failure, etc.)
What are the vulnerabilities (i.e. no security training for developers, lack of formal SDLC, no development standards, no security requirements, no security testing, etc.)
Within the vulnerabilities I would roll up any identified tactical findings into strategic issues. For example, software code with clear text passwords may result in a poor encryption policy, lack of standard, or a lack of proper classification policy and controls around passwords.
Overall using this strategic approach helps us to determine what assets in the entire application architecture/environment have the highest risk and we can mitigate accordingly. In the long run this approach should save cost. We really wouldn’t want to spend $40,000 dollars on a code review for each application when I know that none of the developers have security training nor do we have secure development standards. This money can be strategically better spent on training since we might have 30 applications across the enterprise. At that point we can then decide to perform a sample checkup and measure the progress to see how we perform both before and after the training. This will be the most cost effective approach and produce metrics that can be delivered to executive management.
Hi Jason. The application security post you are referencing is more of a methodology to assess applications. Towards the bottom of my post I state “Of course, once you flush out some risk issues, you can assess them for risk using your favorite risk assessment methodology.” In this case, the ‘favorite risk assessment methodology’ would be where the Cost vs. Risk answer would be questioned. Thanks for the pingback!
Hey this is a great post man actually risk assessment is the thing that matters a lot and mainly we do not focus on that actually i m a student i have completed my studies from CISSP at that time i use to read some blog for my assignments on risk assessment there are different kinds of risk assessment skills and types man………….do post some new information!!!!!!!!!
Is there anything you are specifically interested? I do a great deal of risk assessment work and have built most of the strategic service lines in my past two companies. The problem I have is lack of time, but if there is something you are interested in I can possibly put together a post.
Also ,although I pointed out the two risk assessment methods there really are many different options.
Usually you will see the:
1. Enterprise RA (NIST/OCTAVE)
2. Light weight or Accelerated RA (Project/Process based)
3. Threat Model (Application based)
Sometimes there are home grown solutions too but usually those will fall into option 2 above.
thanks for sharing this information! it’s very useful for a lot people try to understand how we can use this product.
Hey, that post leaves me feeling folsoih. Kudos to you!
Risk assessment is the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized threat. Quantitative risk assessment requires calculations of two components of risk. Risk assessment consists of an objective evaluation of risk in which assumptions and uncertainties are clearly considered and present.
Thanks for the CISSP text book reply. I’d be more interested in how you use your quantitative or qualitative approach for application security.