2.3. Process: Applying Human Factors Knowledge and User-Centered Approaches to Security Design The process of building a secure system is vital to its effectiveness. The process is the means by which security needs are assessed, policies are elaborated, and countermeasures are designed. As with any software development project, the right mix of participants, expertise, and methodology is vital in ensuring a system that is actually secure. To achieve this, designers of secure systems need to consider that security is not the primary goal of users and organizations. The role of security is a supporting oneto protect assets and activities that users care about or that are part of the production activity of business organizations. 2.3.1. Security Is a Supporting Task Two further concepts that are key to designing successful security applications are goals and tasks. Human behavior is essentially goal driven, so the effective and efficient execution of tasks that help users attain goals is a key principle for designing successful systems. Human factors analysts distinguish between production tasks (those that are required to achieve the goal or produce the desired output) and supporting tasks (those that enable production tasks to be carried out in the long run, or be carried out more efficiently, but are not essential to achieving the goal). Securitylike safetyis a supporting task . Production tasks are the reason why a system exists, and if production tasks cannot be completed effectively and efficiently, the system will cease to exist. Users put production tasks first; organizations, sensibly enough, do the same from a higher-level perspective. This understanding leads us to a number of insights for security design : Security tasks must be designed to support production tasks. Security tasks must not make demands on users that conflict with the demands of their production tasks. The performance requirements for a security task must be derived from the performance requirements for the production task. The current reality is that security mechanisms are often chosen without consideration of the production tasks, and individual users are often left to make a choice between complying with security regulations on the one hand or getting their job done on the otherand the choice they make is predictable. When security needs require a reduction in the efficiency of a production task, the need for the extra effort has to be communicated clearly to users. Tradeoffs between production tasks and security should not be made by security experts, who naturally prioritize security over efficiency. Rather, these decisions should be made in consultation with those in charge of business processes and workflow.[19] [19] Sacha Brostoff and Angela M. Sasse, "Safe and Sound: A Safety-Critical Approach to Security Design," New Security Paradigms Workshop 2001.
Users need to understand and accept the need for security tasks. In an ideal world, we would have systems where security is integrated seamlessly and demands no extra effort. We could, for instance, imagine a gait recognition system that identifies users as they walk up to a door and open it to those who are authorized, remaining shut to those who are not. In reality, however, even a well-chosen and well-configured security mechanism demands extra effortin the gait example, users may need to remember to carry a token that identifies them and to make special arrangements to take visitors into the building. To avoid users' natural inclination to shortcut security, they need to understand and accept the need for the security task, and be motivated to comply with it.
2.3.2. A Process for Designing Usable Secure Systems Zurko and Simon[20] were among the first to point out that current security mechanisms make unreasonable demands on all stakeholders: system administrators and system developers, as well as users, struggle with the increasing amount and complexity of work involved in keeping systems secure. [20] Mary E. Zurko and Richard T. Simon, "User-Centered Security," New Security Paradigms Workshop 1997.
System administrators struggle with the increasing workload involved in securing systems at all possible levels (hardware, operating system, network, applications), keeping up with patches, registering users, and managing accounts. Many developers feel overwhelmed by the complexity involved in securing the systems they develop. Often, security weaknesses are introduced because developers do not realize the security implications of their design decisions. Because security is seen as a nonfunctional requirement in software engineering terms, the need to secure functions is often not considered until the design is completed. Users often compound this problem by asking to see functions working as early as possible. Even when a security analysis has been done at the outset of the project, the implications for design may not be considered because they are kept in a document separate from the system specification. Today, developers are often left with the responsibility for making security decisions in new applications. To address these issues, Flechais, Sasse, and Hailes[21] have proposed an integrated development method for secure systems that does the following: [21] Ivan Flechais, Angela M. Sasse, and Stephen Hailes, "Bringing Security Home: A Process for Developing Secure and Usable Systems," Proceedings of the New Security Paradigms Workshop 2003.
Brings together all stakeholders (system developers, owners, users, administrators, and security experts) to carry out a risk analysis and to consider the practical implications of proposed security mechanisms in the context of use Integrates security into the software engineering documentation that developers refer to throughout the development process
Appropriate and Effective Guidance for Information Security (AEGIS) is a sociotechnical software engineering methodology for creating secure systems based on asset modeling, security requirements identification, risk analysis, and context of use. The purpose is to provide system developers with simple and intuitive tools for producing a secure system that takes end user needs into account and promotes security buy-in. The core processes of AEGIS are shown in Figure 2-1. Figure 2-1. AEGIS activity diagram 
The core AEGIS processes consist of: Gathering participants in the design process. This requires identifying and ensuring the participation of key stakeholders, including users, managers, and system owners. Identifying the system's assets. Assets represent the most fundamental valuables in a system. These include hardware or software components, physical artifacts, employees, etc. Modeling assets in the context of operation. As seen from the HCI design technique known as contextual design,[22] understanding the context in which the system operates is a useful tool for designing a practical and usable system. Modeling the physical and cultural environment of the assets provides greater information about the system that can then inform the security design. [22] Hugh Beyer and Karen Holtzblatt, Contextual Design (San Francisco, Morgan Kaufmann, 1977).
Identifying security requirements on the assets. Getting stakeholders to assign a value to the assets according to certain security properties (such as confidentiality, integrity, and availability) gives a clear insight into which aspects of the system are most important. This also provides greater clarity into which aspects of security deserve the most attentionfor example, providing a high degree of availability requires a different architecture from satisfying a high confidentiality requirement. Figure 2-2 shows an example model in which assets, context, and security requirements have been recorded. Conducting a risk analysis in which vulnerabilities, threats, and risks are identified. Together with the identification of important security requirements, this allows the identification of areas in which the system is at risk and the potential impact to the system is deemed to be high. Designing the security of the system. This design is based on the security requirements identified by the stakeholders and the risk analysis highlighting areas where the system is unacceptably vulnerable. At this point, countermeasures are proposed and evaluated against both their cost and their effectiveness. The contextual information identified previously is important in assessing the cost of the countermeasure to the system as a wholethis includes financial, organizational, and user costs. Identifying the benefit of the countermeasure depends on an assessment of the effectiveness of that measure at preventing, detecting, or reacting to identified risks. Based on a better understanding of the impact of the countermeasure, it can then either be accepted or rejected as a part of the architecture.
By involving stakeholders in the security analysis, AEGIS provides several benefits: It provides increased awareness of security in the participants, allowing them to identify a number of problems and issues with security themselves, and providing a wealth of information about the needs of stakeholders. This information is elicited and recorded in the asset model, which is used throughout the security design. The security aspects of the system become much more accessible and personal. This can be invaluable in combating security apathy, and can be a powerful means of overcoming a lack of security motivation. By providing a simple model through which the security properties of the system can be discussed by stakeholders, communication during the design of security is improvedand that supports better security decision-making.
Figure 2-2. Sample AEGIS asset model 
|
