I’ve been an IEEE and Computer Society member for a couple of years now. Trying to keep up with the IEEE publications along with my RSS Reader and tech news has been a challenge – so I’m sure I’ve missed some good stuff along the way.

However, an article in the September 2009 edition of ‘Computer’ caught my eye: “Formal Versus Agile: Survival of the Fittest” by Sue Black, Paul P. Boca, Jonathan P. Bowan, Jason Gorman and Mike Hinchey.

It’s a great article with good history and an insightful assessment of the current ‘methodologies’ landscape. Unfortunately the article is only available to subscribers of ‘Computer’ at the moment. I hope it will be published more widely in the near future since I think it has a wide appeal.

The author’s comparison of RAD and Agile was particularly interesting – and the following statement about Agile practises is worth quoting…

Most teams purporting to be doing agile software development are not applying the level of technical rigor necessary to succeed at it. Most ‘agile’ teams have actually only adopted Scrum’s project-management practise and have failed to effectively adopt ‘the hard disciplines’ like test-driven development, refactoring, pair programming, simple design (writing the simplest code possible to satisfy the customer’s requirements), and continuous integration.

Their description of the major misconception that ‘Agile = Fast’ was also insightful (when it should be about being responsive to ‘change’).

A great read if you can get hold of it.

Yet another great feature of IIS7  - declarative static content cache settings. It took a little detective work to find the settings for this feature – including a helpful post from Jörg Jooss.

I wanted to be able to set the client cache settings for the static content of a site I host at ORCS Web. In the past – unless offered by the control panel of your shared hosting provider – this would have meant emailing support and asking them to set the client cache header settings for the required directory in IIS6. In IIS7 this can be set now in the <system.webserver> section.

Note: If you’re going to try this on your local machine first, you will need to unlock the staticContent section in IIS7 (from the machine level) using the following appcmd…

appcmd unlock config /section:staticContent

You can also use appcmd to create the static content cache settings as shown in Jörg’s post above, which will add the correct section to your web.config – or you can directly edit/create the web.config file for the required directory.

I chose to hand edit the web.config – creating a new web.config located in the directory with the static content (i.e. images, style sheets, script files – all under the ‘assets’ directory in my case)

<?xml version="1.0"?>
<configuration>
  <system.webServer>
    <staticContent>
      <clientCache cacheControlCustom="private" cacheControlMode="UseMaxAge" cacheControlMaxAge="3.00:00:00" />
    </staticContent>
  </system.webServer>
</configuration>

A couple of things to note about these settings. Firstly – you can add any custom cache control header setting using the cacheControlCustom attribute (e.g. no-store, must-revalidate, private, public etc). Secondly using the http 1.1 max-age setting – you can specify days – by using the 1.00 notation for the hours portion of the hh:mm:ss timespan value. So the setting above will set the max-age value to 3 days – or 259200 seconds when you see it in the response header.

Update: 28-11-2008 - Microsoft have released an update - v3 of the SDL Threat Modelling Tool - which is DFD based as opposed to use case driven. Check it out at The Microsoft SDL Threat Modeling Tool v3

Original post....

In my first year on the MSc programme at RHUL ISG,  I completed a course on security management, and while that hardly makes me an expert (since I'm still new to the world of information security), the course was excellent, and I learned a lot about the fundamentals of building an information security management system.

At its most basic level, information security management is about attempting to estimate the probability and impact of unwanted events; events that may effect the confidentiality, availability or integrity of information assets. Estimates about the risks associated with these events can then be used to make decisions about what measures (if any) an organisation will choose to implement as part of its overall information security management strategy.

The process of estimating and assessing risk should be guided by an information security policy that, among other things, will state the aims, values and objectives of an organization with regards to risk. The policy, when combined with legal, businesses and moral responsibilities will (or at least should) influence the choices that are made in managing risk within an organization (the ISO 27000 series of documents is the place to start if you'd like to know more about building an information security management system (ISMS)).

The process of producing risk estimates is called risk assessment, and while there are different techniques for performing a risk assessment, the  common goal of each is to produce a metric that allows risks to be weighed. Weighting risks allows an organization to make appropriate decisions about how to prioritise and manage risk.

One formula that is often used to describe the calculation of risk is: risk = threat x vulnerability x impact,  which translates to: What is the level of an identified threat (how common is it, how relevant is it to the industry or asset in question), how vulnerable is the asset or system to the threat, and what is the impact if the vulnerability to a specific threat for a specific asset is realized. If any of the factors are zero - then risk is is also zero.

Acceptable choices in managing risk include: 1) accept the risk, 2) mitigate the risk, 3) transfer the risk or 4) avoid the risk.

The first task then is to work out what the threats are, creating an applicable threat model (well actually the first task is to work out what your assets are - how much they're worth to you, and what a total loss of that asset would cost you in both tangible and intangible terms - but let's assume we're at the threat identification stage).

So how are threats identified? Well I think for the most part they come from a body of knowledge and experience that exists for a given industry and its assets. For example - a jewellery shop is likely to consider the threat of theft to be relevant since it has stuff of value, and jewellers have learned, through experience, that a small percentage of the population will attempt to steal things of value, ergo.. theft is a threat. How vulnerable the jewellery shop is to theft depends on where it's located, how valuable the jewels are, and whether or not the shop has implemented any measures designed to prevent theft- like locks on cabinets, security cameras, security cards etc.

Threats against computer systems and networks also require a body of knowledge in terms of historical and current threats. One approach in helping to identify threats as part of risk assessment is to use a threat library, or database of known threats. There are a few systems out there that take this approach - like a software tool called CRAMM Expert (based on the the CRAMM methodology) which includes a database of threats that you can use to create a threat model for your organisation.

This evening, during another one of those serendipitous link journeys, combined with some reading I've been doing on application lifecycle and security, led me to discover a link to the Threat Modeling Tool tool from Microsoft. While other methodologies in risk assessment cover a wide range of threats and security management issues, Microsoft's tool is geared specifically towards managing risk in software (not surprisingly) and is part of Microsoft's Security Development Lifecycle (SDL) methodology.

I think this tool (and the methodology) is pretty interesting. For starters it's free, which shows how committed Microsoft is to not only producing secure software, but to helping the community at large incorporate secure software development practices into their overall software development process.

In fact it was this post by Adam Shostack, Experiences in Threat Modeling At Microsoft (an excellent article) which led me to the SDL portal, and it was a reference in Bruce Schneier's - Crypto-Gram monthly newsletter that led me to Adam Shostack's post.

I can't claim to be an expert in using this tool after just 30 minutes of experimenting... but I was impressed. Using the the "New with wizard" option - I was able to create a rudimentary threat model in just a few minutes.

The process involved defining user roles (UR), components, service roles (SR) and data. The tool and the process is 'data centric' and as Adam Shostack points out in his article,

"... a great many software attacks involve the flow of data through the system in some way...."

Components used in service roles are also assigned relevancies (or features) like whether the component utilizes HTTP, or builds SQL queries.

Access control rules are created for the defined data entities - both for users and components.

Application Use Cases are then created which in turn are composed of application calls. The caller for each call in a use case can be a user role (UR) or a service (SR).

Threats can then be automatically generated and the tool will attempt to match a list of attacks in the attack library with the calls in a use case, creating a threat list for the given use case. The terminology here is slightly different from what I was taught - since I would have classified the threats that were produced as vulnerabilities, and the attack library as a threat library or database.

Here's an example call graph from a simple use case.

And here's a full screen-shot of the application with an automatically generated threat (vulnerability) that was created for the "Create User" use case.  I'm about to choose 'Reduce' as my Risk Response (remember I can choose to avoid, reduce, transfer or accept a risk). I've also chosen three counter-measures as the mechanisms I will use to reduce risk (click on the image for a larger version).

There is a lot in here, including being able to specify authentication mechanisms for roles (which I'm assuming is used to weight and select attacks) as well as analytics including data access matrix, component access matrix and subject object matrix reports as well as visualizations for call, data and trust flows. Other reports are divided into risk owner reports, design team reports, development team reports and test team reports. Development team reports even include code examples on how to implement selected countermeasures.

To be honest I'm not sure entirely where the Threat Analysis and Modelling tool fits into the data flow diagram (DFD) and "STRIDE per element" approach described in Adam Shostack's paper. The tool appears to be use case driven as opposed to data flow diagram driven.

Also wondering how this application might be integrated with other application design components, like logical or physical design models. There are options for importing Visual Studio Team System Deployment reports as well as exporting Team System Work Items.

I guess the ultimate test in value will be in how much effort is required to build and maintain a threat model using this application when compared to other methods. Large models in particular might be difficult to maintain, although I guess there is no reason why you couldn't use this application to create several smaller threat models with only the user/service roles, data and use cases that are specific to a given feature or iteration of development.

I think it's also worth pointing out that the Threat Analysis and Modelling tool is just one (albeit important) part of a larger process designed to create secure software. It is not a replacement for functional, performance, vulnerability (penetration) and regression testing, nor does it appear to have any risk modelling functions for assessing application deployment, configuration and change management risks.

My limited experience with both this application and a formal software security development process means that I'm not able to say how successful this application might be at helping to 'connect' the security process with application development. But it is a very interesting product, feature rich and easy to use - with zero financial risk to boot.

Managing the risks associated with software, whether developed in-house or acquired is a core component any information security management process and so any tool that helps to increase awareness and manage risk in this respect is a good thing.

UPDATE: 01/09/2008 - Met some people from Reuters at BarCamp Bangkok over the weekend. They were describing their frustration at having been forced to use SharePoint to build an external community and social networking site for financial analysts. I think I can see why they'd be frustrated with the choice. Although I'm NOT a SharePoint guru - SharePoint appears to me to be to ideally suited to internal corporate intranet activity - offering a really fast way to get a feature rich intranet up and running without any design or development costs. However for a highly customized public (or even private community - but external to the hosting organization) community - there are a  LOT of possible choices - and probably better choices too that will give the site the flexibility it needs in terms of design as well as architecture.

Original post...

Today I decided to go for it, and promote my Windows Server 2008 64 bit test box to a domain controller (using dcpromo). I then created two Hyper-V virtual Windows Server 2008 servers (joined to the domain); the first as a dedicated SQL Server 2005 database server, and the second as a SharePoint server. I've dabbled with WSS a little previously and had all the docs ready. Configuring the Windows Server 2008 domain and the SharePoint server all went surprisingly well.

Windows Server 2008 in particular has a very slick install, role management and feature configuration system - all run via Server Manager. The main and 'real' server has the Active Directory, DNS and Hyper-V roles installed. The two virtual machines have the application server and web server roles installed (the main box is a fairly decent spec Core2Duo with 8GB of RAM).

Configuring WSS correctly takes a little preparation and planning - but for a sandboxed lab installation - it's pretty straightforward. Here's a great five part tutorial on installing SharePoint, and here's a link to a SharePoint deployment book that you can download from Technet.

The first thing you need to know about any WSS deployment is that if you want to use a separate SQL Server 2005 server as your SharePoint configuration and content database - then you MUST install WSS as a server farm - even if you only have a single SharePoint web application server (also the account that it used to connect from the SharePoint server to the database server MUST be a domain account - hence the creation of the server domain first). If you choose a single server installation (as opposed to the server farm installation) then SharePoint will install the Windows Internal Database (SQL Server runtime) and everything will run from a single server without any options (as far as I can tell) to move content to a separate and dedicated database server in the future.

Now that I'm up an running - I'm really curious to take a look at the 'out of the box' features for WSS. WSS is free  - and at first glance I'm impressed with what's there - including content creation, document management, collaboration, calendars, tasks, wikis, and blogs. And this is all before a full Microsoft Office SharePoint Server installation. Here's a link to a comparison of the two. From the docs and feature comparisons you can see that WSS alone offers a lot of intranet and collaboration functionality; ideal for small to medium size organizations that have already made an investment in Windows desktop and server technology.

Although I've not spent a lot of time looking at intranet or content management systems (CMS), I have been following the blogosphere activity around Drupal, Joomla and other 'free' CMS applications. I've also watched the Telligent products mature - like Community Server and Graffiti CMS (Graffiti in particular is a very slick and easy to configure CMS and blogging platform for ASP.Net- perfect for small organizations and individual bloggers). I'll be looking at the Windows SharePoint Services Development Center as well, and if I can find the time - will take a shot at writing an experimental Web Part.

So if it all went so well, then why is the 'Missing SMTP Server' in the title of this post? Well I was 95% there - starting to get that warm and fuzzy feeling you get when a whole bunch of things just work - first time. I then tried to configure the SMTP server for SharePoint's outgoing email messages, and discovered that the SMTP server is no longer under the IIS snap-in - at least not for IIS7. It took a while for me to discover that it's now part of the Features node in Server Manager.

Select the Features node - and then Add Features (in right hand panel) and you'll see an option for SMTP Server. When selected you're also prompted to install the Remote Server Administration Tools and something called the Feature Administration Tools beneath which you see listed the SMTP Server Tools. I said ok to all of that... but could I find a snap-in or configuration option for the SMPT Server Tools anywhere? Well nope - not even after an hour of Googling and searching the docs for the SMTP Server Tools. Amazingly - the SMTP server re-appears under the IIS6 snap-in (as long as you've installed the IIS6 compatibility components) however after being prompted to look for the something called Feature Administration Tools and SMTP Server Tools - I figured I could be forgiven for looking just about everywhere BUT the original IIS6 snap-in. Argh...

Ok - well pain over - I'm still looking for a way to configure a local SMTP server with a smart host entry that also requires server credentials - since neither the WSS SMTP outgoing email server options, or the SMTP server (under IIS6) offer a way to relay mail to a server that requires authentication for outbound mail. I'd like to be able to use the SMTP servers at my external Webhosting service (WH4L) but they both require authentication for SMTP outbound email. Ah well - not a big deal compared to the rest - but it would be a nice way to finish things off.

SMTP server hiccups aside...WSS looks pretty darn good and it'll be fun experimenting with additional sites and features on my test installation.

I learn something new nearly every time I write code - whether in a small project or large.

I recently updated my online gallery component at http://www.58bits.com/otherblog/photos/home.aspx. One of my TODO: items was a rewrite of a VCR style pager I've used previously. What I wanted was a style like the one shown in the screen shot... similar to that used on many sites. I also wanted user friendly(ish), hackable URLs, with each URL truly representing a resource; resources that may have more than one representation. For example, what you see visually as a user visiting the site - is a page with either thumbnails or a preview on it. However if you're an RSS reader, or a slide-show plug-in, you'll be given an RSS/XML representation of the same resource.

So what did I inadvertently create by moving to the new pager style? A  RESTFul pager. By asking for pages using the HTTP GET verb (as opposed to my old VCR pager that relied on forms and POST - ok a bad move I know) - I now have URLs that look like this...

http://www.58bits.com/otherblog/photos/5cgg96ab3e6g/thumbnails/2/2x3/view.aspx

And I now have a good separation from the server implementation, and the client's perception of a resource via a cool URL, and one that won't change.

As an aside, I can also now do something intelligent with caching, telling the client whether the resource has been updated or not via ETags, last modified dates and HTTP 304 response codes, saving a ton of bandwidth while at the same time ensure that changes propagate.

I'm a newbie to REST as an architectural style and am currently reading a lot on the topic - but what I've found from my initial exploration is that if you've been programming the Web for a little while, you've been close to REST by default. Embracing the style to include other verbs (other than the ubiquitous GET) is not such a big step, and I'm looking forward to experimenting further.

Here's a link to an author that's produced a great presentation on RESTFul Web Services

A colleague just sent me a link to the MIX07 presentation of ASP.Net Dynamic Data Controls. I'd actually seen this demo before - but something about taking a quick second look made me want to blog about it.

Is it just me, or are there other people out there that kind of wince when they see these sort of presentations? (ignoring the obvious 'prop and holding' behavior of Mahesh Prakriya and his bottle of water).

The tools are definitely cool and I can see how these controls would be useful for knocking together a quick admin UI, or proof of concept app.  But the thing that kind of depresses me when I watch a video like this (with more powerful controls that let you build apps more quickly!) is the thought that there are 'developers' out there that will use this stuff and call themselves programmers - without knowing a whole lot about software development (principles - like searching, sorting, comparing, or how to build applications that are secure, transactional, and scale).

I sometimes wonder if we're headed back the good ol'days of VB6 where whole departments grew up without really knowing much about software development at all.

MS has an evangelical team, but frankly I'd like to see less proselytizing of how technology is going to make our software development lives so much better - and more holistic presentations that combine neat tools like this - with careful qualifiers that put the tools into the wider context of software design, quality and production issues.

I wrote earlier about my experiences using the Application Block Software Factory to create a new Application Block and Provider - it started well - and creating my first provider went fine.

Putting things into production was a slightly different matter.

Again the docs are thin - and it took a brief email exchange between myself, Tom Hollander and Fernando Simonazzi of Clarius Consulting to solve one problem I came unstuck with (no doubt attributed mainly to my first crack at ObjectBuilder and ABSF).

The problem I ran into relates to the ProviderData classes that are created by the ABSF. ProviderData classes are created for each of your providers and contain the configuration information required for your provider (read from the .config file). ABSF will also create another class in the source file for your ProviderData class - an Assembler class - ProviderAssembler. ProviderAssembler implements Object Builder's IAssembler interface and is responsible for handing back an instance of your provider, along with feeding any strongly typed settings to the constructor of your provider as required.

In broad terms - there are two ways to build classes from your application block using ObjectBuilder: IAssembler or using ObjectBuilder's generic CustomProviderAssembler method.

It's not immediately obvious that there are two provider creation strategies here or that there can be issues if you mix the two.

One is strongly typed - using your own Provider Assembler class. In this case any attributes you declare in your settings file....

<add name="Provider1" type="MyProvider, ProviderProject.Providers" databaseName="Test" specialProperty="Test" />

(databaseName and specialProperty) will be referred to in your ProviderData class as properties like the following...(just the databaseName attribute here)

private const string DATABASE_NAME = "databaseName";
[ConfigurationProperty(DATABASE_NAME)]
public string DatabaseName
{
    get { return (string)this[DATABASE_NAME]; }
    set { this[DATABASE_NAME] = value; }
}

During the call to your assembler's Assemble method - you can pass the values of these convenient and strongly typed properties into your provider's constructor.

However here's were I came unstuck.

For each of your ProviderData classes - there is also a BaseProviderData class - and at first glance this seems like correct place to place any provider properties that may be common to all your providers - with one very important exception.

The ABSF also creates a CustomProviderData class - which ALSO derives from the BaseProviderData.

CustomProviderData doesn't implement properties for configuration - it simply reads all the attributes in your settings and places them into a property bag (a name value pair collection) which will get passed into the constructor of your implemented CustomProvider. You then retrieve the settings from the NVC as you need them in your provider (casting into the required types for each attribute).

So...

<add name="Provider2" type="MyCustomProvider, ProviderProject.Providers" databaseName="Test" setting1="Test" setting2="Test" />

In this case setting1, and setting2 will appear in the NVC when received by MyCustomProvider's constructor - BUT - if the databaseName property was defined in the BaseProviderData class - it will NOT be included in the NVC. The NVC is built for 'unknown' attributes only and in the pattern of assembly provided in the ABSF - databaseName is now a 'known' configuration property (known by the BaseProviderData class) and so won't be included.

So - if you are considering offering the client the option to create their own custom providers (as opposed to pre-defined strongly typed providers in the block) - be very careful about placing common property settings in the BaseProviderData class - because if a custom provider needs an attribute of the same name - it will never see it since it won't be included in the NVC of settings during construction.

NOTE - see Part Two of this article here...

I've recently been working on a component for a client that requires several implementations of a base class and interface including internal class dependencies.

I'd also been lurking over a couple of blog entries on the topic of Inversion of Control Containers and the Dependency Injection pattern and trying to work out the best strategy for configuring the base provider class as well as the dependencies, and so for the first time I was thinking - hmmm.. a case for DI and a pluggable architecture.

I'm by no means an 'Alpha Geek' where DI, IoC and pluggable frameworks go, however I've been using EntLib and various providers in .Net for a while now and my curiosity was peeked when Enterprise Library 3.0 shipped with its very own Application Block Software Factory.

A brilliant blog writer by the name of Jeremy D. Miller has posted a series on DI and IoC - such as The Dependency Injection Pattern – What is it and why do I care? and Thoughts on Building Pluggable Frameworks.  I'd been looking at StructureMap and Castle Windsor as possible starting points.

I've also been following the evolution of the Guidance Automation Toolkit and the Guidance Automation Extensions. There's some cool stuff going on here with the software factories released so far.

So... while StrctureMap looks like an excellent choice (although I should stress I'm really not qualified at this stage to compare the two) - I decided to try it the Microsoft way first using GAX and the Application Block Software Factory ... and here are the results - a Foo Application Block sample app (Zip). 

There aren't any QuickStart sample apps for an Application Block using the software factory (at least not yet) and the docs supplied are clear but very brief and so a little digging was required. Tom Hollander has posted three video tutorials on getting started with this software factory - Enterprise Library: The Videos. The first two demonstrate the creation of providers for existing application blocks. The third one takes you through the creation of a custom application block. As an aside - the Configuration namespace in .Net 2.0 is large and daunting at first - but there's some powerful stuff in there. It helps a lot if you're familiar with the most common classes in the configuration namespace, ideally having created at least one configuration section using the ConfigurationSection base class.

I also wanted a simple App.config ready to go with my new block and configuration settings including custom settings for a provider. While Tom's video demonstrates this - the screen width was too narrow to see some of the settings he'd used including the most important reference to the section handler type.

After watching the videos and trying it out - a couple of hours later I'd got the hang of it and can now produce a custom application block, base provider and configuration classes in about five minutes; not a bad return.

The only dependencies in the new custom block are the Microsoft.Practices.EnterpriseLibrary.Common and Microsoft.Practices.ObjectBuilder namespaces - so if you're already using Entlib - these shouldn't worry you - and if you're nervous about getting into bed with GAX and GAT too soon - then with one custom application block in the bag - you can use this as a template for other projects without GAX. Creating new providers within the project is very straightforward.

One mistake I made that caused me to get hung-up for a few minutes - was a typo in the type declaration in the App.config settings file for my first concrete provider (CoolFooProvider) - if you make this mistake you'll get the following exception at runtime - "The [Assembler] attribute is not set in the configuration object type Foo.Configuration.FooProviderData." (for your base provider data class). Since this is the base type for concrete provider data class it's not decorated with the [Assembler] attribute; it's never meant to be 'assembled'. The application block couldn't find my concrete implementation (because of the config typo) and so fell back to trying to assemble the base class. Check your config file carefully if you see this message.

I also didn't like the default name of the ApplicationBlockSettings class that was created by the software factory - but this is a simple search and replace in files from VS - in this case renaming ApplicationBlockSettings to FooSettings. This is important though since this is the class that handles the section - and the one that you'll need to reference in your App.config section definition.

And very lastly - I prefer my section definition names to be camel cased (and so do the authors of the main EntLib blocks) and so a quick change to...

"public const string SectionName = "foo"" in FooSettings was in order.

My objective in the exercise was to see how quickly I could create configurable providers for the base and interface definitions for the component - including the correct settings for App.config since I did not want to depend on the designer for configuration setting creation. Like most things - it's quick and easy once you know how. Here's the link again to a working demo of a custom application block - Foo application block (Zip).

The next step in the project will be to create two new provider bases and interfaces for the nested dependencies (this is the main design goal of the block - otherwise I'd be using a simple FactoryClass to create the component). The constructor for the parent provider will simply call ProviderFactory for the nested providers based on one of the string settings in the parent provider, and of course the App.config will contain another list of possible provider entries for the child providers. If you've made it to your first custom Application Block then this next step is a breeze.

If I were more knowledgeable about StructureMap and the Castle Windows Container - I'd make some comparison comments - but I'm not (yet) so I wont. I've read enough so far to know that I'm in good shape for the first step in the process which is a good object configuration and creation strategy.

Containers are next....