The traditional role of requirements engineering is to determine what asystem needs to do. However; security is often about getting thesoftware to avoid what it is not supposed to do. We know how to writefunctional. specs to say what the code is supposed to do, but we don'tknow as much about expressing security constraints regarding what asystem is not supposed to do.
When security requirements are not effectively defined, theresulting system cannot be effectively evaluated for success or failurebefore implementation. Security requirements are often missing in therequirements elicitation process. The lack of validated methods isconsidered one of the factors.
A recent study found that the return on investment when securityanalysis and secure engineering practices are introduced early in thedevelopment cycle ranges from 12 to 21 percent
NISTreports that software that is faulty in security and reliability coststhe economy $59.5 billion annually in breakdowns and repairs
Getting SQUARE with security
A systems quality requirements engineering process (SQUARE) foreliciting and analyzing security requirements was developed by the SEIand applied in a series of client case studies
For example, a stakeholder in human resources may be concerned aboutmaintaining the confidentiality of personnel records, whereas astakeholder in a financial area may be concerned with ensuring thatfinancial data is not accessed or modified without authorization.
To create secure software, it is necessary to anticipate the threats towhich the software will be subjected. Understanding these threatsallows resources to be allocated appropriately.
Threat models consist of a definition of the architecture of yourapplication and a list of threats for your application scenario. Threatmodeling involves identifying key assets, decomposing the application,identifying andcategorizing the threats to each asset or component, rating the threatsbased on a risk ranking, and then developing threat mitigationstrategies that are. implemented in designs, code, and test cases.
These threat models should be reviewed as the requirements anddesign of the software evolve. Inaccurate models can lead to inadequate(or excessive) levels of effort to secure the system under development.
Microsoft has defined a structured approach to threat modeling [Meier 03, Swiderski 04] that beginsin the early phases of application development and continues throughoutthe application life cycle. As used by Microsoft, the threat modelingprocess consists of six steps:
1. Identify assets. Identify the assets that your systems inust protect.
2. Create an architectureoverview. Document the architecture of your application,including subsystems, trust boundaries, and data flow.
3. Decompose theapplication . Decompose the architecture of your application,including the underlying network and host infrastructure design, tocreate a security profile for the application. The aim of the securityprofile is to uncover vulnerabilities in the design, implementation, ordeployment configuration of your application.
4. Identify the threats. Identify the threats that could affect the application considering thegoals of an attacker and the architecture and potential vulnerabilitiesof your application.
5. Document the threats .Document each threat using a template that defines a common set ofattributes to capture for each threat.
6. Rate the threats. Prioritize the threats that present the biggest risk based on theprobability of an attack and the resulting damage. Soave threats maynot warrant any action, based on comparing the risk posed by the threatwith the resulting mitigation costs.
The output from the threat modeling process can be used by projectteam members to understand the threats that need to be addressed andhow to address them.
|Table8-1 Differences between misuse and security use cases|
A security misuse case [Alexander 03,Sindre 00, Sindre 02] , a variation on a use case, is used todescribe a scenario from the point of view of the attacker.
In the same way use cases have proven effective in documentingnormal use scenarios, misuse cases are effective in documentingintruder usage scenarios and ultimately in identifying securityrequirements [Firesmith 03].
A similar concept has been described as an abuse case [McDermott 99, McDermott 01] . Table 8-1 above shows thedifferences between security use cases and misuse cases [Firesmith 03].
Table 8-2 below shows anexample of an application-specific misuse case for an automated tellermachine (ATM) [Sindre 03].
|Table8-2. Application-specific misuse case|
As with use cases, misuse cases can be an effective tool incommunicating possible threats to a customer or end user of asystem-allowing them to make informed decisions regarding costs andquality attribute trade-offs.
Misuse cases can also be used to identify potential threats and toelicit security requirements.
Next in Part 3: “Architecture andDesign”
To read Part 1, go to “Secure softwaredevelopment principles.“
Thisarticle is excerpted with permission from the book titled “SecureCoding in C and C++“, by Robert C. Seacord, published and allcopyrights held by Addison Wesley/Pearson Education. It can bepurchased on line.
Robert Seacord is senior vulnerability analyst with the CERT/Corrdination Center of theSoftware Engineering Institute. Noopor Davis is a visiting scientistwith the SEI Software Engineering Management Program. Chad Dougherty isa member of the technical staff for the SEI Networked SystemsSurvivability Program. Nancy Mead is a senior member of the technicalstaff for the SEI Networked Systems Survivability Program. Robert Meadis a member of the technical staff for the SEI Networked SystemsSurvivability Program.
[Alexander 03] Alexander, I.,Misuse cases: “Usecases with hostile intent.” IEEE Software, January/February, 2003.
[Bourque 05] Bourque, P. andR. Deupuis.”Guide to the SoftwareEngineering Body of Knowledge.” IEEE Computer Society.
[Chen 04, Xie 04] Chen, P., N.Xie, et.al. “SystemsQuality Requirements Engineering (SQUARE): Case study on AssetManagement System.” Software Engineering Institute. 2004.
[Firesmith 03] Firesmith, D. ” Security usecases.” Journal of Object Technology.” May/June, 2003.
[Internet Society 00] TheInternet Society (2000). Internet SecurityGlossary. (RFC2828)
[McDermott 99] McDermott, J.and C. Fox. “UsingAbuse case models for security requirements analysis.” Proceedingsof the Fifteenth annual Computer Applications Conference,” Dec. 6-10,1999. IEEE Computer Society.
[McDermott 01] McDermott, J. “Abuse-casebase assurance Arguments.” Proceedings of the Seventeenth annualComputer Applications Conference.” Dec. 10-14, 2001. IEEE ComputerSociety.
[Meier 03] Meier, J.D. et. al.” ImprovingWeb application security threats and countermeasures.” (2003)
[Sindre 00] Sindre, G and A. Opdahl. “Elicitingsecurity requirements by misuse cases.” Proceedings of TOOLSPacific 2000. Syndney, Austrailia.
[Sindre 02] Sindre, G. A.Opdahl and B. Brevik. “Generalization/Speciailzationas a structuring mechanism for misuse cases.” Proceedings of thesecond annual symposium in requirements engineering for informationsecurity. (SREIS 2002).
[Sindre 03] Sindre, G.,Firesmith, D., and A. Opdahl. “Areuse-based approach to determining security requirements.”[REFSQ'03]
[Soo Hoo 01] Soo Hoo, K.,et.al. “Tangible ROI through secure software engineering.” SecureBusiness Quarterly, Fourth Quarter, 2001)
[Swiderski 04] Swiderski, F.,and W. Snyder. “ThreatModeling.” Microsoft Press, 2004.
Recent articles on security onEmbedded.com:
Securingwireless MCUs is changing embedded systems design
Stateof security technology: embedded to enterprise
Securiingmobile and embedded devices: encryptioon is not security
Guidelinesfor designing secure PCI PED EFT terminals
Overcomingsecurity issues in embedded systems
Buildingmiddleware for security and safety-critical applications
Securityconsiderations for embedded operating systems
Diversityprotects embedded systems
Aproactive strategy for eliminating embedded software vulnerabilities
Understandingelliptic curve cryptography
Securingad hoc embedded wireless networks with public key cryptography
Securingembedded systems for networks
Implementingsolid security on a Bluetooth product
Smartsecurity improves battery life
Howto establish mobile security
Ensuringstrong security for mobile transactions
Securingan 802.11 network