19 May 2009

Crossing boundaries

By Andrew Clifford

I have recently been applying development methods and tools to InfoSec work. The experience has made me realise just how much we can learn by sharing our skills more widely.

My background is in IT architecture, design and development. My company provides methods and tools to help with the long-term management of IT. Because of our background, the methods and tools we have developed are reasonably well architected and designed. The methods we use draw from our background in logical modelling. We have done a reasonable job selecting and integrating the components of the tools that we provide.

Although the methods and tools have been well received for their intended use, we have also had a lot of interest in them for information security (InfoSec) assessments. This wasn't our originally intended market, and it is interesting to see how methods and tools developed for one IT area are received in another area.

In some aspects, such as basic data gathering and presentation, our tools are similar to InfoSec tools. In other aspects, our methods and tools are different, and these differences reflect the differences of background.

To support our general IT focus, we have to bring multiple strands of IT into a single framework. Because of our background in architecture and logical modelling, it seemed obvious to combine everything around a simplified logical model of IT. This is unusual in InfoSec, which tends to work in more detail at individual devices and procedures. Our approach has some advantages for InfoSec, particularly for management-level assessments, and partner consultancy has successfully used our approach to create a very well received multi-standards InfoSec assessment tool.

Similarly, we have to identify policy issues across multiple IT areas. This is complicated and difficult to standardise. Because of our background with development tools, it seemed obvious to us to integrate a specialised programming language for this, and chose a rule-based expert system. This is unusual in the InfoSec market which very much relies on expert opinion. We have had a good reception for our product because it can capture and reuse this expertise, freeing the experts from more repetitive tasks and allowing them to focus on more challenging areas.

I would not claim that our methods and tools totally revolutionise InfoSec, but they do demonstrate that methods and tools that might seem obvious in one part of IT can be innovative and useful when applied to another part.

I am sure there are many similar opportunities. Could the disciplines of object orientation be applied to systems programming, so that servers can be configured more easily by non-experts? Could the standardised, layered model used for networks be applied to development technologies, to get away from the problems with rapid obsolescence?

We talk a lot about breaking down silos in business. But the truth is that in IT we have become so specialised that we suffer from silos too. Skills, methods and tools that are obvious in one part of IT can be a breakthrough in another. We can learn a lot by sharing our skills and breaking down the silos within IT.