Making secure is hard from a technology point of view. As Juval Lowy is saying in this MSDN article:
Security is by far the most intricate area of the Windows® Communication Foundation (WCF). In every WCF operation call on the service side, security is governed by the service contract, the operation contract, the fault contract (if present), the service behavior, the operation behavior, the host configuration, and the method configuration and its code. Each of these items may have as many as a dozen or more security-related properties...
And it's hard from a process point of view, also known as SD3+C. [The New Threat Modeling Process]
You must get executive support [not always that easy], you must create awareness, you must tackle the "not now we must make functionality" problem and some more.
Additional information can be found in these links.
- How Do They Do It? A Look Inside the Security Development Lifecycle at Microsoft
- The Trustworthy Computing Security Development Lifecycle
The The Security Development Lifecycle BLOG is a great place to start reading on this topic.
How to use Team Architect to make your SD3+C process more in control and help developers to build better, quicker secure services.
When you work with Team Architect you are already collecting innumerous information which can be used for threat modeling,
You've got the Logical Datacenter Diagram whit information about zones "Trust Boundaries" and servers which are in those zones. For example the Logical Datacenter Diagram below, We've got an internal legacy system with a broker in front which lives in a secure zone together with an some servers and internal clients, this zone exposes functionality through a DMZ to external clients and consumes information from an external creditcardserver. [forgive me the naming of the servers ;-)]
Probably / hopefully you are making this diagram together with the ITPro.
With the application diagram you start by defining the application design... [image]
...and map the applications to the Logical Datacenter with the Deployment Diagram [image], to do some deployment validation.
I Attended a LiveMeeting a while ago about quality tools and VSTS and one of the slides was this one, where the presenter [Adam Gallant] talked about infrastructure and deployment modeling as a quality tool. I completely agree with him.
anyway, the deployment diagram...
And now it gets interesting..!
We have a view of all or systems / applications and the zones they live in [Deployment Diagram, actually is should be called a Logical Deployement Diagram ;-]. It should be nice when we could model / configure at this level, in this deployment diagram, additional security information.
For example, we've got Internet connections, Intranet connections and Business-To-Business connections in this solution, just as Juval describes in his MSDN article. This isn't possible in Team Architect but, what we can do is create our own "security model"... just on other view point, where you can define security specific settings with the security manager.
So, what I did, I created a DSL with the zones, applications, connections and for each connection/ endpoint you can configure specific security settings.
When you add this model to your solution it takes all the necessary information out-of the Team Architect diagrams and creates the shapes. [still one challenge: layout... it doesn't organize the shapes. So you have to drag around the shapes to get a meaningful model]
This is how the security model looks like [image below, still needs allot of tuning].
It has all the applications, endpoints, connections and the zones. From this point the architect together with the security guy can start defining the specific security settings. By default every line is red and set to "No Security". When defining the type "Intranet - Internet - etc" of the connection the endpoints gets security specific properties like certificate store, certificate name, Impersonate and so on... and in the details window there is the ability to set at operation level detailed information, for example if one operation needs impersonation and another doesn't...
Note: this model is far from finished, actually it's just an implementation of a brainwave, to give it a try if it would work this way and to get some discussion going on about modeling viewpoints/ quality attributes.
Anyway, only the model isn't that interesting.
It gets more useful when the Web Service Software Factory ,attached to the application diagram, take notice of the security model and use it during code generation.
For the implementation I used Juval's "Declarative Security Framework" and tweaked the Service Factory T4 templates a little bit. Using the Framework is a little bit overdone, because we already have an easier way "raise the abstraction level" for security.
Another thing I'm working on, is [and you can see it in the solution explorer] the generation of an Thread and Analysis Model File [TAM].
This file is used by the Thread and Analyses Tool and helps people identify threads with in your solution. There is enough information in all the models to give threat modeling a jump start by providing this file... and not only helping the creation of secure service from a technology point of view but also from a process kind of view.
A nice way to embed Secure Development Lifecycle [SDL / SD3+C] into the Application Lifecycle [ALM]
Still a lot of work to do [I think most of my posts end with this sentence] but a nice start for discussion...