Software Systems Architecture

Nick Rozanski and Eoin Woods

[ HOME ] [ BOOK ] [ REVIEWS ] [ EVENTS ] [ RESOURCES ] [ LIBRARY ] [ ABOUT ]

News

Big in Japan

A Japanese translation of our book was published on 2 December 2008 and has already received three five-star reviews on Amazon Japan.
Amazon Japan

Architectural Training

Rebecca Wirfs-Brock has developed a course, based in part on our book, which provides software architects with skills and knowledge that enable them to prepare, present, and explain their architectures to diverse stakeholders.
Wirfs-Brock Associates

Amazon Reviews

We now have fifteen five-star reviews on Amazon.com. Thanks to all who have provided such strong endorsements. We are really pleased that people are finding it so useful.
Reviews Page

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- policies
- threats
- mechanisms
- accountability
- availability
- detection and recovery
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 inf
- ormation 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
- security embedded in the application code
- piecemeal security
- ad hoc security technology

find out more about the Security perspective ...

Reference

Viewpoints

Introduction

Functional

Information

Concurrency

Development

Deployment

Operational

Main Perspectives

Introduction

Security

Performance and Scalability

Availability and Resilience

Evolution

Other Perspectives

Accessibility

Development Resource

Internationalization

Location

Regulation

Usability