The Security Perspective

Many factors drive today’s need for information systems security, including the increasing trend to distribute systems, the use of public networks (particularly the Internet) as part of system infrastructure, the rising interest in interorganizational computing (such as that envisaged by Web services), and other less technical reasons such as the increasing interest the media and the public have shown in computer security. All of these factors point to the fact that today your system’s stakeholders are likely to be more interested in the security of the system than they would have been only a couple of years ago.

We define security as the set of processes and technologies that allow the owners of resources in the system to reliably control who can perform what actions on particular resources. The who refers to the people, pieces of software, and so on that form the set of actors in the system who have a security identity; security specialists normally call such actors a principals. The resources are the parts of the system considered sensitive (i.e., those that need controlled access) such as data elements and operations. The actions are the operations that the principals in the system will want to perform on the resources (e.g., read them, change them, execute them, and so on) as shown in Figure 24-1.

The resources, principals, and actions that need to be considered are often very specific to the system. An Internet service provider is likely to have a totally different set of security concerns compared with those of a military intelligence organization, which will be different again from an enterprise implementing an internal information system that allows dialup access to its employees. However, in all these cases, security is still the business of allowing the right levels of access to the right resources to the right people.

It is also important to recognize that security is not a simple process of “being secure” or not. Rather than a binary state, security is really a process of risk management that balances likely security risks against the costs of guarding against them. Bear this in mind to help you set realistic assumptions in the minds of your stakeholders and to make intelligent tradeoffs that address the real security risks your system faces.

Desired Quality	The ability of the system to reliably control, monitor, and audit who can perform what actions on these resources and the ability to detect and recover from failures in security mechanisms
Applicability	Any systems with publicly accessible interfaces, with multiple users where the identity of the user is significant, or where access to operations or information needs to be controlled.
Concerns	resources principals policies threats confidentiality integrity availability accountability detection and recovery security mechanisms
Activities	identify sensitive resources define the security policy identify threats to the system design the security implementation assess the security risks
Tactics	apply recognized security principles authenticate the principals authorize access ensure information secrecy ensure information integrity ensure accountability protect availability integrate security technologies provide security administration use third-party security infrastructure
Pitfalls	complex security policies unproven security technologies system not designed for failure lack of administration facilities technology-driven approach failure to consider time sources overreliance on technology no clear requirements or models security as an afterthought ignoring the insider threat assuming the client is secure security embedded in the application code piecemeal security ad hoc security technology