Matt Bishop's book contains an excellent overview with examples of Saltzer and Schroeder's Design Principles. This series of posts will examine the security considerations and implications of these principles in the context of Service Oriented Architecture. We will use the Service Oriented Security (SOS) Architecture Model that defines five main architectural viewpoints for looking at security in SOA.
Design Principles are an important part of security architecture, because they help to take security out of the negative space of "don't do that" type of reactivity and towards a proactive patterns based approach. To review the views in SOS are defined as:
* Identity View: deals with the claims made about an identity, the identity itself, federated identity, and identity management
* Service View: deals with the service's logical oragnization and component parts
* Message View: deals with persistent data/service's message payload
* Transaction Use Case Lifecycle View: deals with the behavioral flow of the application and its actor from an end to end perspective
Examining the Principle of Least Privilege
Matt Bishop's work defines the Principle of Least Privilege this way:
"The principle of least privilege states that a subject should be given only those privileges that it needs in order to complete its task."
One effect of the principle of least privilege is intended to ensure that a process is constrained to only those privileges it needs for the task at hand, if the process or objects it interacts with has an error, exception or other unintended event then the subject should still not be able to operate on the object. Let's examine the design considerations for each SOS view with regard to this principle.
Identity View
The Identity View is logically correlated with the principle of least privilege in that it is the identity that typically sources the set of claims that are mapped to the principal. The granularity of both the identity and authorization structures (such as roles and groups) has a direct bearing on the service's ability to constrain access and make security decisions. The identity View is responsible for providing information that is used to construct the principal, the principal is used by the Service, Message, and Deployment views to inform their security decisions. It is worth noting that the use of anonymous or "system-type" accounts can have unintended side effects on the ability to constrain privileges for a subject.
Service View
The Service View should be constrained to allow access only to those services that it can verify that the subject should be allowed for. The Service View can use principals and other security information to determine what level of access is appropriate. The Service can use Access Control Matrices to document what subjects have specific privileges for objects. Additionally, the Service should implement services, such as a Service Pipeline Interface where requests can be filtered before allowed access to business logic and information.
Message View
The Message View handles, among other things, security for persistent message that is produced by the service. Since the message's state persists in memory, disk, tape, and network space beyond the span of control of the service, security mechanisms like encryption are used to ensure that the object is only accessible in an understandable format by authorized parties where the cryptographic key and other security mechansisms such as those used in WS-Security provide the assurance that subject is authorized.
Deployment View
The Deployment View is responsible for showing the design of the principle of least privilege as it is applied to the deployment environment, its servers, network, hardware and other components. In this view, the principle of least privilege is concerned with such issues as ensuring that the service's server adminstrators have configured the server to have only the rights it is required to have in the rest of the environment and no more. Network administrators use least privilege to assign responsibilities to certain parts of their networks.
Transaction Use Case Lifecycle View
The Transaction Use Case Lifecycle view has a unique role to play in applying the principle of least privilege. The Transaction Use Case Lifecycle View is responsible for articulating the required set of behaviors and the systems' actors. These elements form the basis of a specification for the privileges the subject is required to have. Further the Use Case format specifies what the post-conditions are in the case of expected, unexpected, and exceptional cases. These post-conditions illustrate some of the issues that canbe tested as to the effectiveness of the granularity and assignment of privilege since they show what the end state of the transaction flow is.
Comments