How to write secure C/C++ application code for your embedded design: Part 2 - Embedded.com

How to write secure C/C++ application code for your embedded design: Part 2

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 [Soo Hoo 01].

NISTreports that software that is faulty in security and reliability coststhe economy $59.5 billion annually in breakdowns and repairs [NIST 02]. The costs of poorsecurity requirements show that there would be a high value to even asmall improvement in this area.

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 [Xie 04, Chen 04]. The SQUAREmethodology consists of nine steps. Steps 1-4 are required prerequisitesteps.

1. Agree on Definitions. Agreeingon definitions is a prerequisite to security requirements engineering.On a given project, team members tend to have definitions in mind,based on their prior experience, but those definitions won'tnecessarily agree. It is not necessary to invent definitions. Sourcessuch as the Internet Security Glossary (RFC 2828) [Internet Society 00]and the Guide to the Software Engineering Body of Knowledge [Bourque05] provide a range of definitions to select from or tailor.

2. Identify Security Goals.Security goals must be identified and prioritized for the organizationand also for the information system to be developed. Differentstakeholders have different goals.

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.

3. Develop Artifacts.A lack of documentation including a concept of operations, succinctlystated project goals, documented normal usage and threat scenarios,misuse cases, and other documents needed to support requirementsdefinition can lead to confusion and miscommunication.

4. Perform Risk Assessment.There are a number of risk assessment methods to select from based onthe needs of the organization. The artifacts from step 3 provide theinput to the risk assessment process. The outcomes of the riskassessment can help identify high priority security exposures.

5. Select ElicitationTechnique. Selecting an elicitation technique is important whenthere are several classes of stakeholders. A more formal elicitationtechnique, such as structured interviews, can be effective when thereare stakeholders with different cultural backgrounds. In other cases,elicitation may simply consist of sitting down with a primarystakeholder to try to understand his or her security requirements.

6. Elicit SecurityRequirements. In this step, the selected requirementselicitation technique is applied. Most elicitation techniques providedetailed guidance on how to perform elicitation.

7. Categorize Requirements.Categorization allows the requirements engineer to distinguish betweenessential requirements, goals (desired requirements), and architecturalconstraints that may be present. This categorization helps in theprioritization activity that follows.

8. Prioritize Requirements.Prioritization may benefit from a cost/benefit analysis, to determinewhich security requirements have a high payoff relative to their cost.

9. Requirements Inspection.Inspection can be performed at varying levels of formality, from Faganinspections to peer reviews. Once inspection is complete, theorganization should have an initial set of prioritized securityrequirements.

Threat Modeling
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

Use/Misuse 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.

References:
[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

Aframework for considering security in embedded systems
Calculatingthe exploitability of your embedded software
Badassumptions lead to bad security

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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.