I am trying to figure out how the above concepts fit in together. As i understood it Security Requirements Engineering (SRE), Risk Analysis (RA) and Threat Modeling (TM) are methods that ultimately allow an Information System to come closer to the desired security goals (CIA Triad, IAS Octave or whatever).

My question is, are they disjoint concepts that can be performed independently one from another, or is there a sort of hierarchy?

Would i be wrong to say, that SRE is the encompassing procedure, which can than contain RA, which in turn can use TM to determine threats?

Does anybody have good sources regarding the fundamentals of SRE and the concepts it includes?

2 Answers 2


A lot of confusing terms and language here. For correct information risk language, please consider FAIR, or Factor Analysis of Information Risk

The terminology "Threat modeling" was correctly replaced by Cigital with the term "Architectural Risk Analysis". Using `threat' here is especially incorrect.

Risk assessment (e.g., OCTAVE, OCTAVE Allegro) is also very different from Risk analysis. A risk assessment is a documented, point-in-time questionnaire at best. A risk analysis can be much more useful when the input variables are selected and formulated correctly. By "useful", I mean that they reflect reality closer to what a human can correlate and fit to normalized patterns.

Without invoking the book, "Software Security Engineering: A Guide for Project Managers", I can tell you that security requirements engineering, as you request, is not a clearly-defined problem to solve in cyber risk. Many document-heavy projects based on Waterfall or other lifecycle prescriptions were abandoned in Information Technology and Application Development circles in the late 1990s. Today, our practices and value chains are aligned towards Scrumban, the most-modern evolution of xp.

If you can follow the FAIR model, then you'll understand how information risk will fit into your organization. This exists outside of your business processes -- it's a standard language to communicate with the multitude of players who could show up to the cyber risk conversation. Threats, as in TCom and TCaps, are an important piece of the FAIR model, so you must quantify threats in order to quantify risk. You must also understand the business. If you identify a vulnerability, or a control-set issue, then you will want to elicit root cause. Root cause is never a patch -- it's always back to the business process, typically consequence management or even crisis management.

If you want to see how you can truly fit these pieces together, I suggest you do check out FAIR, but integration is key -- and OpenSAMM makes that integration cleaner than anything else I've seen. If you need a strategic map to forecast your future outputs (or collect the right input variables in the first place), then OWASP OpenSAMM can be fit to any cyber risk need. You'll see the correct language around "security requirements engineering", "threat assessment" (your risk analysis), "design review" (your threat modeling), and much more explicitly defined and explained within.

  • 1
    I consider the CARVER method more useful in terms of RA's given its industry standard implementations along with the proven track record. In any case, all RA's are a function of "Threat" and "Vulnerability" That said, I feel you've muddied the water with your use of "root," also you haven't described what you mean by "business process" which seems overly vague. Can you explain what business process you are referring to? Also a threat assessment is not necessarily a risk assessment, but the two can be combined.
    – user67862
    Aug 22, 2015 at 16:51

There is a new concept called "Active Cyber Defense Cycle" which utilizes all three in a cycle rather than hierarchy.

What this means is that Threat Intelligence particular to your environment is always analyzed and fed to Incident Response. Responses are informed by knowledge of the internal network and empowered to make fast changes to network structures. RA's help determine if threats are specific to your systems, while the "baseline" is a combination of Network Security Monitoring and strong, secure architectural changes and foundations in the network.

This was developed by Robert Lee of SANS and Utica College.

SRE is incorporated via knowledge of network, which is essential to defense in that you should already know your network while an attacker has to gather recon.

To summarize and answer, they can be done independently but shouldn't be. No team in INFOSEC at an organization should be isolated. There is no reason for Incident Response teams not to talk to Net Admins and Threat Intel teams.


  • Do you also have thoughts on the NIST CSF or OpenSAMM as they apply to the original question, or even as they apply with integration towards or from active defense?
    – atdre
    Aug 15, 2015 at 16:20
  • The CIA triad and related NIST guidelines are best summarized, to me, by the 20 Critical Security Controls from SANS. SANS has taken NIST and other standards (US national and International) and mapped them into 20 "controls" to operate within the CIA triad. ["sans.org/critical-security-controls 20 CSC's]
    – user67862
    Aug 22, 2015 at 16:44
  • Here is a poster they sent out last year that illustrates the mapping I've mentioned. sans.org/media/critical-security-controls/fall-2014-poster.pdf
    – user67862
    Aug 22, 2015 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.