1 Raindrop

Security Development Lifecycle at MS

Microsoft continues to add value to developers from all programming camps. SilverStr and Emergent Chaos both have pointed to Microsoft's release of their practices in the security development lifecycle. This effort, pulled together by Steve Lipner and Michael Howard, is to be applauded. The end to end view provided in the paper is important to show teams thinking about ways to increase security in their applications.

One of the major issues to be solved here is that the development teams continually are paring down the artifacts and activities in the development lifecycle in favor of a more "lightweight" approach. The path that the security team must navigate is to identify the critical set of deliverables that increase security in a cost effective way without bogging down the developer's progress. In my own work in this area, I have tended to take an approach of laying out the elements that can be used in various phases, then in a UP-like way let the projects decide which artifacts apply to their domain.

SOS: Using the Service Oriented Security Views

The SOS viewpoints are intended to decompose the security issues into separate groupings so that threat analysis and countermeasures can be assessed independent of the other views. This is a requirement in a SOA world where the client and server are decoupled and the data payload is decoupled from the services that use it with no way for the server to  know exactly what the client will do with the result of the call.

The separation of security concerns generated by the views is useful to analyze threats and design and apply countermeasures, but of course at runtime, many elements that partitioned in the views become bound together. This is the primary reason for the Transaction Use Case Lifecycle view that shows the order of execution, boundaries, and other relevant actions that demonstrate what types of binding occurs. There is an additional recursive element that cuts across the views in that many elements from the views overlap directly with other views'. For example, identity can be treated as a service. This overlap speaks to an iterative approach through analysis and design across the viewpoints held together by the Transaction Use Case Lifecycle view.

The Identity View in Service Oriented Security

Identity effectively amounts to (at runtime) a principal that is defined by a set of claims.

Let's look at a couple of definitions of how identity is defined and used:

"Authentication binds a principal to a representation of identity internal to the computer. ..all decisions of access and resource allocation assume that the binding is correct," Matt Bishop

and

Kim Cameron's working definition and related discussion:

"A digital identity is a set of claims made by one digital subject about itself or another digital subject."

In a SOA world there are two compelling elements in Kim's working definition that augment Bishop's definition of how an identity is used. First, is that the identity (like other security assertions) must be made portable across domains and not tied to one computer. Secondly, the notion of claims is critical. A claim is subjective and can be evaluated based on criteria which evolves over time even in the span of a given transaction.

In the SOS architecture views we are concerned with identity from two perspectives. Internal to the Identity view, we have concerns such as how are we defining identity? By what mechanisms, use cases, and processes do we achieve identity, what processes are in place to verify trust in the claims that have been made, to what extent is the identity portable across domains, and finally how are applying protection, detection, and response mechanisms to ensure the desired state of confidentiality, integrity, and availability of identity?

External to the Identity view the relationships with other views the concerns center around what identity properties are consumable, verifiable or queryable by the other views, and to what level; what level of trust can or should the other views have on the identity (or principal), how can the other views use identity in their protection, detection, and response mechanisms? What effect do eternally visible changes in the other views have on the identity view?

The Message, Service, Deployment, and Transaction lifecycle viewpoint each use and supply specific elements and constrains to the Identity view. The next blog entries will explore these in more detail.

(Note: This work on Service Oriented Security views comes from a book that I am working on, if you are interested in reviewing sample chapters, drop me a note)

SOS: Service Oriented Security

On one level, the services in a SOA and their related infrastructure can be seen only to serve the purpose of mediating and faciliating the activity among the identity and the information payload. In today's technologies this usually means a security principal (as rendedred by .Net, J2EE or other system) and an XML document. Everything else (including the service) exists to join these two in the proper way as defined by policy.

In a Service Oriented Security (SOS) Architecture, we are concerned with securing the following elements:

* Identity
* Message
* Service
* Deployment environment
* Transaction Use Case Lifecycle

These elements suggest four separate security models to consider tied together by the Transaction Use Case Lifecycle. Each element, expressed as a  viewpoint, contains its own unique set of threats and vulnerabilities; and protection, detection, and response countermeasure layers. When security for a SOA is looked at from only one of these angles, e.g. only from the service perspective, then the system is likely to contain unmitigated threats in the other areas. By looking at each viewpoint on its own and then understanding the relationships and dependencies on other views are cohesive security deisgn can be achieved.

As Kruchten observes, the use of multiple views enables the architect to separate  concerns in a complex system. The use of multiple views in understanding SOA is also critical since the elements are decoupled both in a logical sense and at runtime. There are dependencies between the views and security tradeoffs to be analyzed that drive design.

At a high level the views are concerned with the following:

* 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

* Deployment View: deals with the logical and physical administrative and runtime deployment environment and trust zones

* Transaction Use Case Lifecycle View: deals with the behavioral flow of the application and its actor from an end to end perspective

Future entries will explore the SOS views in more detail.

(Note: This work on Service Oriented Security comes from a book that I am working on, if you are interested in reviewing sample chapters, drop me a note)

Blink, Rapid Cognition, and Requirements

One of the threads that runs through Blink is that preferences are inherently unstable, and that when asked about they like or choose something people won't know or they will make up stories. Given that what people tell us they want and like is not reliable, particularly about new things and ideas, what does this say about requirements gathering and definition process? Is/was this part of the dot com bubble problem due to developers writing code for what people said they wanted, when they themselves did not know on a conscious level?

On a practical note, I think this speaks to iteration and prototyping as an answer to the unstable preference problem.

Web Services Security in ISB

Mark O'Neill has published an article on Web Services security in the recent Information Security Bulletin. As with Mark's other work, he methodically cuts through the hype and gets to the realities in web services security. Not sure if/when it is available online, but if you are an ISB subscriber check it out. Also, Mark's blog contains links to a number of other insightful pieces he has written on related topics.

Web Services Security @ OWASP Europe

Next month I will do a presentation on Web Services Security at OWASP Europe. I am looking forward to the other presentations which cover a wide range of web security issues.

Security Design Patterns

The simplistic thinking that limits web application security to focusing mainly on firewalls and related entities has many negative implications ont he security of web applications today, however the DMZ pattern has introduced the security world to patterns. App developers, architects, security personnel, and BAs know what you mean when you say "DMZ". This demonstrates the power of patterns, they understand the problem that DMZs deal with, the context in which DMZs are useful, and what the solution elements are. Of course, the problem in security is that a DMZ is only one link in a chain nowhere near a complete solution. What the security world needs is a pattern language to conduct tradeoff analysis, design discussions, and integrate solutions. We need security patterns that focus on structural, creational, and behavioral issues in security.

Luckily, some work is being done here, but it is not yet widely distributed/understood in the development and security communities. Ed Fernandez has a site dedicated to security patterns and the Open Group has published a Security Design Patterns guide.

Abstracting the communication level on security up to another level will help greatly in building more secure distributed systems, the same way that when a development team is formed and by looking at designs of facades, cor, and singletons enable a far higher density design communication. Due to abstraction and familiarity, patterns increase the resolution of the architecture, and since they may be used together there is the possibility to form meta level or domain specific patterns out of other patterns. Once these are established, embedding and using the security patterns in software analysis and design for secure code becomes a more powerful tool relating each element into a cohesive whole.

Security in Software Development - What's the brief?

What is the brief of the software security architect or engineer as they engage with a development team? Organizations have different names for the role, some call it Application Security Architect others call it Software Security Engineer, each organization seems to have its own taxonomy, but it is a new role and there is not widespread agreement on how these individuals should engage to be maximally effective.

Problem number one is that the software security role is usually dealing with hundreds or even thousands of developers so that speaks to the concern that the individual should focus at a strategic level on things like frameworks, components, and patterns that can be reused
across teams and technologies. The next area that the software security person can focus is on education of developers and architects, aiming for co-evolution among them. The top level developers and architects are always looking for ways to make their code more bulletproof so
giving them tools and techniques is essential to a successful software security program.

My sense is that the software security role will evolve into something more or less analogous to the DBA/Data achitect role where a DBA has an association with multiple development teams, direct input on design, and some support roles as well.

* Supporting multiple teams
Currently, in most organizations, the software security role spread out against the entire development landscape. Developers will get more security conscious over time, but it is likely there will be a role for a security specialist for awhile.Software security individuals need to be focused on a finite amount of teams so they can dig in, mentor,

and...

* Design
Part of software security is designing the security patterns and frameworks, but placing them in the proper context and choosing the right combination based on risk and other business factors is equally important. To do this effectively, the software security role has to be engaged at the right time. We are now at least 7 years past the point where dropping a few firewalls into a design is an acceptable technique (if it ever was), but the DMZ still dominates. This won't improve until developers and architects are educated, and software security focuses it efforts to show the way.

* Monitor
The DBA monitors the database, space, logs, and the care feeding of the database once it is in production. Security, like database administration, is an active process. The software security
professional has an important role once the system is in production. The software's output logs, exceptions, and reports must be reviewed and managed, there is patching and releases.

What Perimeter?

This piece is a cogent summary of the risks of assuming that the firewall is sufficient to protect your perimeter and goes on to argue that assumptions generated by having a firewall in place may result in a less secure enterprise.