Architectural Services | Resources | Views | Contact Arctec Group

Top Ten Information Security Considerations in Use Case Modeling

By Gunnar Peterson, CTO, Arctec Group

Considering the overall lack of software security in the industry, many efforts are being made to integrate security into software and software development. While many agree that this is a worthy goal there is an overall lack of specific methods to integrate security into the software development process. Partially this is due to the fact that most software development methodologies do not focus on security, but rather treat security as a generic non-functional requirement not supported by security-centric artifacts. This paper discusses ten specific ways to inform the Use Case Modeling discipline with information security.

Functional and Non-functional requirements

Software requirements are typically divided into two categories: functional and non-functional. Functional requirements deal with what the system is supposed to do, for example deposit money into a bank account. Non-functional requirements deal with everything else including performance, security, availability, usability, and scalability. Functional requirements are generally written out indicating what business features are required of the software system, decomposing high level business feature sets down into a finite set of requirements. Non-functional requirements tend to be more nebulous. Often there is a lack of precise metrics. In the case of security requirements, the process can seem counter-intuitive. Most requirements stipulate that the system must do something, while security requirements are frequently focused on ensuring something does not happen. This difference is at the root of many security gaps in software.

Towards Use Cases

Use Case pioneer Ivar Jacobson points out that as a whole, all Use Cases describe all possible ways of using a system. Use Cases answer the question: what is the system supposed to do for each user? [1] Use Cases differ from requirements in two main ways. First Use Cases are used to generate a shared understanding of the problem to be solved, the key relationships and actors in a system. Bittner and Spence [2] refer to this as building up a shared understanding as opposed to decomposing features. The result of this is the second difference, which is that a Use Case model places requirements in a certain context. Context is critical in security in that the context can show how the Use Cases are related to the assets which the security mechanisms must protect, and the overall flows, dependencies and assumptions that the system makes.

Top Ten Information Security Considerations in Use Case Modeling

Lets examine ten ways that Use Case models can be developed in a more security-focused way.

1. Synthesis
Use cases provide a synthetic model that correlates requirements from different domains' concerns into a coherent model and flow. Use Case models provide a format to conduct architectural tradeoff analysis of security mechanisms at different points in the system and establish a document for the tradeoff decisions.

2. Stakeholders
In Information Security, it pays to find allies. Stakeholders who may be concerned about security implications in the system that is being built include not just the core development staff, but also the legal staff, business owners, domain experts, operational staff, customers, shareholders, and users. The Use Case model captures and documents stakeholders that have some stake in the outcome of the development project. The Information Security team should document these stakeholders unique concerns and viewpoints with regard to security.

3. Pre and Post Conditions
Pre and post conditions describe the set conditions that must be satisfied for the Use Case to execute (Pre-conditions) and the set of states that the system can be in after it has completed (Post-conditions). Pre-conditions allow the Information Security team to articulate the security conditions, such as authentication and authorization processes that must be completed before accessing the Use Case functionality.

Information Security policies defines acceptable states for the system to be in to be in accord with the policy. There are typically many different possible states a system can be in at the end of a Use Case. Use Cases describe basic or expected flows, and also exceptional and alternate flows. Each flow may result in one or more states. The Post-conditions document the set of states possible at the end of the Use Case. The Post-conditions illustrate what must be done to tear down a system at the completion of Use Case which could include disabling a user's session, locking accounts, deleting temp files or cache, and closing accesses to resources such as databases. By stipulating, security concerns in the Use Cases' Pre and Post Conditions, early in the development lifecycle the developers are empowered to write more secure code.

4. Exceptional and Alternate Flows
A fundamental principle in security design is to plan for failure. Development projects are mainly focused on base flows of the system since these implement business valuable features. However from a security standpoint, exceptional and alternate flows highlight paths that often become attack vectors once the system is deployed. These flows are worth examination by Information Security to ensure that the system is not likely to enter an insecure state and to identify areas to deploy security mechanisms such as audit logs and IDS tools to catch security exceptions when they occur.

5. Actors
Use Cases scenarios are triggered by an Actor. Actors can include computer systems, users, and other resources like job schedulers. By analyzing the actors involved in the Use Case model, the Information Security team can begin to build a picture of the authorization structures such as roles and groups that may be required for design as the system is built. When delegation or impersonation is used, actors can identify where this is accomplished and what actors are mapped onto other actors at runtime.

6. Modeling Identity
Identity has historically been thought of as a passive entity, but in reality a digital identity is the result of a set of processes, for example authentication events that get mapped onto some principal(s) and are evaluated. Identity is a foundation level element to most systems and particularly security systems. Use Case modeling can help to drive the precise usage and rulesets for building, validating, and exchanging identities in a system. Since both the software and Information Security world suffer from a host of over loaded terms that mean different things to different people, additional precision on foundation level elements makes a more resilient system

7. Relationships
Much of the power in the Use Case model comes from its simplicity. Use Case models feature two types of relationships: includes and extends. These have direct security implications, the includes relationship out come changes the base flow of the use case. In the case of including an access control Use Case like Authenticate User or Authorize User, the outcome of this (usually pass/fail) directly changes the behaviors of the related use case. The extends relationship does not alter behavior of the preceding use case, so if a use case extends to a monitor event use case and that monitor server is down, it may not make sense to alter the flow of the preceding Use Case.

8. Mapping Use Cases to Threat Models
Security is focused not solely on what is supposed to happen, but also what may go wrong. Threat modeling is used in the development lifecycle to map possible threats and impacts onto the system so that appropriate security controls can be built into the system. The Use Case model allows the Threat Model to refer to both the end to end as well as componentized view of the system. Threat Modeling is gaining momentum, Microsoft offers free Threat Modeling tools and resources and a new portal "Threats and Countermeasures" has just launched.

9. Architectural Decision Support
Software security consists of numerous design tradeoffs, however these design tradeoffs do not exist in isolation. The Use Case model's end to end view of the system shows the impact of choosing to deploy or not deploy security mechanisms, such as IDS, at different points in the system.

10. Drive Test Case Development
Use Case modeling results in artifacts that drive not just coding activities, but also testing activities, the security-centric Use Case elements should be associated with a set of Test Cases to demonstrate the systembs ability to deliver on the security policy.

Next Steps

It behooves Information Security to be involved in the software development lifecycle as early as possible as a proactive collaborator so that the software is built with security in mind. To maximize effectiveness, Information Security must learn to speak the language of the tribe in software development. Use Case modeling is a skill that does not require deep programming experience so security analysts with a variety of backgrounds can make a positive contribution to the development process.

Resources from Arctec Group

Collaboration in Secure Development Process: three part series on developing secure software, originally published in Information Security Bulletin.
Download

Artcec Security Briefings
http://www.arctecgroup.net/briefings.htm

References

[1] "Aspect-Oriented software Development With Use Cases," Ivar Jacobson and Pan-Wei Ng, Pearson Education, 2004

[2] "Use Case Modeling," Kurt Bittner and Ian Spence, Pearson Education, 2003


Copyright © 2003, 2004, 2005 Arctec Group, LLC All Rights Reserved