The 7 Law of Identity

Microsoft has proposed architectural principles ("7 Laws of Identity") to support convergence towards an inter-operable, secure, and privacy-enhancing plurality of identity systems - an "Identity Metasystem". This new concept presupposes that a single monolithic identity system for the Internet is neither practicable nor desirable.

The ability of Internet users to manage identity relationships with diverse organisations is a prerequisite to further development of e-commerce and efficient delivery of government services online. However a rising tide of information security threats, from “phishing” and “spoofing” attacks on the user, to large scale breaches of centralised repositories of identity information, suggests that new approaches are needed which can empower the individual to take more control of how their personal information is used online. For a number of years there has been growing interest in industry and research communities in the concept of "user-centric" identity management systems. Microsoft has proposed architectural principles ("7 Laws of Identity") to support convergence towards an inter-operable, secure, and privacy-enhancing "Identity Metasystem". This new concept presupposes that a single monolithic identity system for the Internet is neither practicable nor desirable. What are the implications for security and privacy of offering individuals greater transparency over how their data is used, and how can this best be achieved?

The 7 Laws of Identity
======================

1. User Control and Consent - Technical identity systems must only reveal information identifying a user with the user’s consent.
2. Minimal Disclosure for a Constrained Use - The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.
3. Justifiable Parties - Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.
4. Directed Identity - A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
5. Pluralism of Operators and Technologies - A universal identity metasystem system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.
6. Human Integration - The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.
7. Consistent Experience Across Contexts - The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.

Links

• Kim Cameron's Identity Blog

Security in SDLC

The software development life cycle

The software development life cycle, or SDLC, encompasses all of the steps that an organization follows when it develops software tools or applications. Organizations that incorporate security in the SDLC benefit from products and applications that are secure by design. Those that fail to involve information security in the life cycle pay the price in the form of costly and disruptive events.

In an organization that's been around for several years or more, the SDLC is well-documented and usually includes the steps that are followed and in what order, the business functions and/or individuals responsible for carrying out the steps and information about where records are kept.

A typical SDLC model contains the following main functions:

• Conceptual definition. This is a basic description of the new product or program being developed, so that anyone reading it can understand the proposed project.
• Functional requirements and specifications. This is a list of requirements and specifications from a business function perspective.
• Technical requirements and specifications. This is a detailed description of technical requirements and specifications in technical terms.
• Design. This is where the formal detailed design of the product or program is developed.
• Coding. The actual development of software.
• Test. This is the formal testing phase.
• Implementation. This is where the software or product is installed in production.

Each major function consists of several tasks, perhaps documented in flowchart notation with inputs, outputs, reports, decisions and approvals. Some companies build workflow applications to support all of this.

Getting the right security information to the right people

Many people in the entire development process need all kinds of information, including security information, in a form that is useful to them. Here is the type of information that is required during each phase of the SDLC.

• Conceptual -- Organization information security principles and strategies
• Functional requirements and specifications -- Information security requirements
• Technical requirements and specifications -- Information security requirements
• Design -- Enterprise security architecture and security product standards
• Coding -- Development standards, practices, libraries and coding examples
• Testing -- Test plans that show how to verify each security requirement
• Implementation -- Procedures for integrating existing authentication, access controls, encryption, backup, etc.

If you are wondering why maintenance is omitted from the life cycle example here, it is because maintenance is just an iteration of the life cycle: when a change is needed, the entire process starts all over again. All of the validations that are present the first time through the life cycle are needed every time thereafter.

Finally, one may say that these changes represent a lot of extra work in a development project. This is not the case – these additions do not present that much extra time. These are but small additions that reap large benefits later on.

Approval: Moving to the next step

Organizations that use a software development life cycle process usually have approval steps at each major function. This takes the form of some kind of an approval meeting with the right stakeholders present: generally you find managers, directors, occasionally a VP – the people who control budgets, resources and business priorities.

Someone who represents information security should be present and have the authority to vote at most, if not all, major steps in the life cycle. If someone representing infosec is not present at a life cycle approval meeting, then there is a risk that a project lacking some key security component will be approved, only to become a problem in the future.

Fix it now or pay the price later

Organizations that fail to involve information security in the life cycle will pay the price in the form of costly and disruptive events. Many bad things can happen to information systems that lack the required security interfaces and characteristics. Some examples include:

• Orphan user accounts (still-active accounts that belong to employees or contractors who have left the organization) that exist because the information system does not integrate with an organization's identity management or single sign-on solution.
• Defaced Web sites as a result of systems that were not built to security standards and, therefore, include easily exploited weaknesses.
• Fraudulent transactions that occur because an application lacked adequate audit trails and/or the processes required to ensure they are examined and issues dealt with.

You should figure that problems like these are all costly to solve – in most cases far more costly than the little bit of extra effort required to build the products or applications correctly in the first place.