Authorization Requirements

Definition

A authorization requirement is a access control requirement that specifies a required amount of the security quality subfactor authorization.

Objectives

The typical objectives of an authorization requirement are to:

• Ensure that one or more persons (who have been properly appointed on behalf of the organization that owns and controls the application or component) are able to authorize specific authenticated externals (e.g., users, client applications, senders of messages) to access specific specific services or information.
• Ensure that specific authenticated externals can access specific services or information if and only if they have been explicitly authorized to do so by a properly appointed person(s).
• Thereby prevent unauthorized externals from:
  • Obtaining access to inappropriate or confidential data.
  • Requesting the performance of inappropriate or restricted services.

Measurements

Authorization requirements are typically specified in terms of the following measurements:

• Minimum percentage of authenticated externals authorized [by role, by task].
• Maximum percentage of non-authenticated externals authorized [by role, by task] (false positive).
• Mean time for an attacker to gain unauthorized access [manually, using a computer of given processing power]

Examples

General Examples

The following are typical examples of authorization requirements:

• “The application shall allow each customer to obtain access to all of his or her own personal account information.”
• “The application shall not allow any customer to access any account information of any other customer.”
• “The application shall not allow customer service agents to access the credit card information of customers.”
• “The application shall allow customer service agents to automatically email a new customer password to that customer’s email address.”
  (Note that this authorization requirement is questionable because it contains an implied authentication constraint — the use of passwords as opposed other authentication mechanisms such as digital signatures).
• “The application shall not allow customer service agents to access either the original or new customer password when emailing the new customer password to the customer’s email address.”
• “The application shall limit remote users to the following services:
  • TBD.”
• “The application shall not allow one or more users to successfully use a denial of service (DoS) attack to flood it with legitimate requests of service.”

Specific Examples

The following are examples of authorization requirements from the Global Personal Marketplace (GPM) system, a global Web-based marketplace bringing together private individuals and small companies to buy and sell all manner of items:

• Accountant— “A minimum of 99.999% of the time, the GPM shall restrict the performance of all accountant use cases to persons who a security officer has currently designated as accountants.
• Buyer— “A minimum of 99.99% of the time, the GPM shall restrict the performance of the following buyer use cases to persons who have successfully registered as a user, who are not currently suspended, and who are not permanently banned:
  • Buyer Reviews Personal History
  • Buyer Registers for Notification of Future Sales
  • Buyer Places Bid On Item
  • Buyer Modifies Bid On Item
  • Buyer Buys Item At Direct Sale
  • Buyer Places Sealed Offer At Decreasing Price Sale
  • Buyer Modifies Sealed Offer”
• Buyer— “A minimum of 99.99% of the time, the GPM shall restrict the performance of the following buyer use cases to persons who have successfully registered as a user, who are not currently suspended, who are not permanently banned, and who have successfully bought from the seller:
  • Buyer Registers Feedback About Seller

Guidelines

The following guidelines have been found to be useful when producing authorization requirements:

• The scope of an authorization requirement can be:
  • A business enterprise
  • An application
  • A component
  • A center
• Authorization requirements can be identified and specified in term of the following:
  
  

  Component of Requirement	Possibile Values
  External Authenticated	Various Types of Users Various Types of External Systems Various Senders of Messages
  State	Normal Processing Degraded Mode Under Attack
  Authorization Type	Repeated Sign-on Single Sign-on
  Prior to Execution of	User Task Use Case Transaction Interaction
  Measurement	Percent of authenticated users authorized Percent of non-authenticated users authorized

  
  
• Authorization depends on both identification and authentication.
• Authorization can be granted to:
  • Individual persons or applications.
  • Groups of related persons or applications.
• Authorization should be granted on the basis of user analysis and the associated operational requirements.
• Only a limited number of people (or roles) should be appointed to grant or change authorizations.
• A common threat to the security of an application is a denial of service (DoS) attack in which an application is flooded with legitimate requests for service. Whereas functional, operational availability, and reliability requirements cover ordinary requests for service, an additional authorization requirement may be useful because no one is authorized to flood an application with legitimate requests. Note that stress and load testing are useful for validating anti-DoS authorization requirements.
• Authorization requirements should not be specified in terms of the types of security architecture mechanisms that are typically used to implement them.