Anyone who knows me will also know I have a bit of a stance against the “point products” nature of some of the IT security industry. It’s all too trite – “there’s a big issue, you need to deal with it, we have the technology, ours is better than the competition” goes the formula. But while I might have described some IT security vendors as “fire extinguisher salesmen”, I have to concede that this is due in no small part to how organisations buy technology in general, and security technology in particular.

Indeed, if one considers a number of organizational factors in parallel, it becomes a tough call  – the difficulties of convincing non-technical superiors about the business benefits of a given technology; the lack of appropriate operational processes to ensure technology is deployed and managed appropriately; the failure of the business to recognize that security risks are, in essence, business risks, and to take appropriate responsibility as a result – all these things conspire to ensure that many organisations can do little practical else than stump up a bit of the hard-won quarterly budget to acquire some portion of a limited solution to what may be a big problem. In some ways, and to paraphrase, we get the IT security industry we deserve.

This was brought into stark relief in one on my meetings at Infosec, when I was discussing SSL VPNs with Juniper Networks. The company has new products which are bigger and better than the last generation, able to support much greater traffic loads. That wasn’t the part of the conversation that interested me however – with Moore’s law and the application of a few creative minds, the latest box will always support more than the last. Far more interesting was when the conversation turned to how policies could be created to link what was permitted to sit at either end of the tunnel – for example, only remote computers whose configurations passed certain threshold security criteria, might be able to access certain specific applications.

That’s clever stuff to be sure, but it begs the question – how many organisations would actually have all the right pieces in place to defined and implement such policy-based configurations? We don’t have specific research on this but other studies suggest that the answer would be, “Not many.” To put this bluntly, the kinds of things today’s products are capable of are quite far-reaching, but today’s organisations aren’t able to take advantage of them. Which may well have been a factor in Juniper leading with the speeds and feeds pitch, rather than anything else.

It’s a familiar picture. I can remember a few years ago talking to one of Symantec’s experts about a policy management tool which, it later transpired, was later dropped due to lack of interest; Cisco has told a similar story about its own policy management tool for its Network Access Control (NAC) functions. Or is it Network Access Protection (NAP – incidentally, it says something that I can remember the specific people and exact places involved in these conversations, but whether Cisco ‘owns’ NAC or NAP still eludes me).

I don’t know what the answer is – but there is a very clear conclusion which emerges. Organisations that are serious about reducing risk will not be able to do so unless they are organized organizationally to do so. This is a pre-requisite, and without it, no amount of clever, fast or otherwise attractive technology is going to deliver on its true potential. It is pointless to prescribe motherhood – “Get the business to take responsibility” helps not a jot if the business doesn’t care for such a thing. However, all sides should at least be cognizant that as long as IT security is treated as a technical challenge, products and indeed the industry as a whole can only ever deliver technical solutions. And as we know, these rarely go far enough to be satisfying.

Given that I’m currently at IBM’s SOA Impact conference in Las Vegas, I though it would be appropriate to post a blog about the security aspects of SOA (Service Oriented Architecture). Judging by the amount of coverage given to security in the keynotes and analyst sessions, one might be led to think that security was not an issue; meanwhile however, one only need to have a cursory understanding of Murphy’s Law to know that security should not be taken for granted, in SOA or elsewhere.

So, what are the risks? There most obvious of these lies in areas such as confidentiality breach and service compromise. At its heart, SOA is about developing and delivering distributed computer systems - that is, software applications and components that communicate across a network. The potential for a confidentiality or service breach is therefore quite high, particularly if communications take place on the wrong side of the corporate firewall.

Risks such as these are well known and frequently documented, so I shall say no more here. Meanwhile, however, there are the risks involved in the development process itself. There has been talk about the “insider threat” in terms of the users of computer systems – people who, through stupidity as much a malice, can cause a security breach. Less consideration has been paid thus far on the developers of said systems. In SOA development environments there are a number of risky areas – not least of course on the code, which needs to be constructed in such a way as to minimise the potential for compromise. There is also the data involved in the development process. SOA requires interface definitions to be published, but such interface data may well contain information that should b kept confidential – for example, specific business rules or even the need for them. And finally we have the security of the development process itself. A number of drivers including the continued reliance on subcontracted development resource requires vetting and monitoring of developers, such that the resulting code has not been written to be compromised.

What’s all this got to do with SOA? Truth be told, some of these aspects are true for all kinds of development, not just SOA projects. What SOA brings is the increased risk due to the distributed nature of the resulting software. In traditional development, the resulting application silos would likely exist behind the firewall, but with SOA there is no such guarantee. As many organisations start to move down the SOA track, they will need to ensure that they have the security bases covered in advance of application delivery. Should security be treated as an afterthought, as it has so often been treated in the past, it may already be too late.

At the end of last week, I found myself in the most pleasant position of being briefed by Kim Cameron, Microsoft’s head honcho for identity management. Kim is generally recognised as quite a catch for Microsoft – a bit like Ray Ozzie, he is a recognised leader in his field and, perhaps most importantly, he doesn’t come with all that Gates-an’-Ballmer-show baggage which almost invariably leads to a question of motives before engaging. Kim comes across as “everybody’s favourite uncle” – with his grey hair and bushy moustache, he exudes common sense and intelligence in equal measure.

But enough about the man. What Kim has advocated (he freely admits he is not alone in this, but he has been instrumental in driving it forward) is to see identity as an aggregation of “claims” – which, given this risk-averse world we live in, require some kind of verification before they can be acted upon. I might claim for example to be a biochemistry student aged over 18, or an existing policy holder, assertions which can both be tested by requesting certain, previously agreed information. The traditional concept of “non-repudiation” (in which public key encryption can be used to verify a sender is who he or she says) can be extended to incorporate claims, so once I have a validated claim, I can continue to act on it.  

It’s a simple enough concept, but its effect can be profound. A claim is essentially “information that knows about itself”, in the words of my old boss Robin Bloor, which means that the other end of the link doesn’t necessarily have to know who I am or any particularly personal information (my date of birth or home address, say). A student information system only needs to know that I am a biochemistry student, for example, to grant me access to restricted research papers on the topic. When we met, Kim explained how with a claims-based approach, ideas like authentication and authorisation become more of a spectrum of possibilities, rather than discrete components of a security architecture, as in authenticating, you are also saying what you are authorised to access.

It’s all great in principle. In practice, while it is being seen as “the preferred approach” by a number of the organisations involved (from Microsoft to the Liberty Alliance), both technology innovation and its general adoption has still to catch up. Microsoft’s own implementation of claims-based identity management, aka CardSpace, has still to support two-factor authentication for example, a weakness when it comes to minimising the risk of social engineering attacks and general stupidity-based threats. All the same, there is no other real alternative being touted. If it’s not yet one to implement, it’s certainly one to keep in mind.

I confess I found some of the recent publicity around USB sticks a little frustrating. A couple of elements got my goat: first was the fact (on the radio at least) that the liberal democrat MP Sarah Teather insisted on linking the loss of such devices with the ability of the UK government to reliably build a pan-country identity database. Now, whatever you think about the latter (I’m pretty dubious, to be sure), it has very little to do with whether specific servants of the state happen to leave USB sticks around.

The second thing that narked me was far simpler - the fact that nobody mentioned just how easy it is to use USB sticks in a more secure way. I’ve made this a bit of a soapbox over the years - indeed, for as long as USB sticks have had security capabilities, which is a fair while. Let’s be clear: not all devices have such things as password protection. But such features are widely available - any device that professes to incorporate SanDisk’s U3 capability will also have password protection, for example. So, the coverage missed a trick: not just to highlight the issue of data loss, but also to take that high profile opportunity to say one simple thing: “Use only password protected devices.”

Now, of course, the level of protection afforded by passwords, and indeed by devices, will vary. However, the existence of a password offers an order of magnitude (if such a thing could be measured) over the lack of one. My tip to the MoD: just buy a bunch of them, and make them easily available - put a stack in the stationery cupboard. Print on them, “only to be used with password protection enabled.” Sure, some may be pilfered but that’s a smaller price to pay than losing national secrets, isn’t it?

Password-protected USB is a start, but there will always be places where a stronger guarantee is required. Right now for example, I’m road testing a fingerprint-enabled USB device from MXI - it’s about as robust as a USB stick could be (metal casing, slide out connector etc) and its got strong encryption built in. Building on the U3 idea, MXI also has a partnership with MojoPac to enable Windows applications to be run straight off the device without leaving a trace on an XP host computer, making it more of a secure, portable application environment than “just” a way of protecting data in the wild.

The point is, while there are questions, there are answers. How unfortunate that such things are not incorporated into common practice, particularly given just how simple they would be to adopt.

Well, no, of course they are not - no more than anybody else of course. I wanted to get that in quickly, before I pulled on my flame-proof suit! But meanwhile, there is a general perception that code is not always developed with security in mind. Why is this? I'd put it down to the following reasons:

• Awareness. Developers are not security experts, and nor necessarily should they be. But this does mean that things that might be obvious to a security guy - "what do you mean, you let the message pass across the Internet in clear???" - may not be so obvious to the programmer. Some base principles such as security by obscurity, and the fundamentals of data protection should be familiar to even the most lowly of coders.
• Timescales. I was presenting at an InfoSecurity Today webinar yesterday when I was asked about what's preventing people from getting security right first time. There was a considerable level of sage nodding around the table when I brought up the point about project milestones getting in the way - particularly if one is asked to squeeze in a few extra features just before the deadline. Its a familiar story.
• Tooling. There are tools that can automatically deal with some of the developer security workload, such as Fortify, or Watchfire from IBM. Such tools can be difficult to budget for early on in the project, and even harder when the money starts to run out later.
• Design. A study we conducted earlier in the year suggested (quite strongly) that there can be an air of "let's hope it works" early in the project, particulalrly when it came to application resilience. Of course this can come down to money - it can be difficult enough to justify a project at all, never mind when all the security bells and whistles are added.
• Visibility. Some of the content of yesterday's event was based on a previous Freeform Dynamics report, which showed how the security of test data was not clearly articulated to the business risk manager. There is a broader point here, around development shops being sufficiently far removed from the business, that they aren't necessarily subject to the same levels of scrutiny as others.

Its all food for thought isn't it? But the bottom line is, however good and diligent are the people involved, factors such as these may well conspire against them to result in a les than secure application. Does this picture equate with your own experiences? I'd be very interested in your feedback.

Whoever invented the term ‘the paperless office’, they should be shot. The world is getting through more paper than it ever has, much of it being printed off laser printers, scanned back into another system and no doubt printed off again at some other point. Its not just a problem with IT itself of course – anyone with a shred of environmental goodwill will no doubt be forlorn at the amount of printouts that sit, gathering static-laden dust in print rooms around the globe. Equally however, there is a fundamental issue with security. So should we just lock away the printers, or is there a better way?

If security is about managing risk, it is worth considering exactly what might go wrong. The starting point is that every printed page may be a source of confidential information – and the time between hitting “print” in an application and actually retrieveing a printout may be just long enough for the information to fall into the wrong hands. For the avoidance of fear, uncertainty and doubt of course, it could be argued that this is a small risk – but then, so is the risk of being hacked. It may not even be ‘bad’ hands, just people who should not see the information for whatever reason.

It would all be so simple if only it wasn’t always so difficut to lay hands on a printout. How many times have you printed something off, walked down the corridor and gone to pick it up, only to find its not there for whatever reason? It could be that there are a number of other jobs in the queue, or indeed, that somebody has walked off with it by accident. Perhaps the maintenance engineer has the whole thing in bits in front of your eyes – but of course, he’ll turn his eyes away when he comes to switch the thing on again...

Local printers have solved the problem to an extent, but they can cause problems of their own. Government establishments have long been tussling with the issue of where a printout might go – if you happen to have several printers set up on your computer, it becomes easier to accidentally print something to a printer far away on the network, where it might never be seen again (or worse, it just might). As it happens, we are seeing organisations move back towards the more centralised model, for operational efficiency reasons – but that brings with it the potential data leakage problems we have seen before.

So, what to do? Perhaps the surprise is that it should be 2008 and printing has pretty much stayed the same for as many decades as I’ve been in this industry – surely such problems should be solved by now? As with many things, the answer is, “It’s not as simple as that.” Companies like Ricoh may be able to offer printers (I think they call the multifunctional devices these days) which require a PIN code or an ID card before they will ‘release’ a printout into the wild, but there has to be the will to integrate such technologies with back-end authentication mechanisms.

Of course once this is done, the rest of the process becomes more straightforward – no PIN, not printout. The advantage is not just with security – it might also spell an end to those recycling bins overflowing with unwanted print jobs. Which might bring us one step closer to the paperless office, after all.

--

This blog post is also available as a podcast.

Earlier this year, we did some work for a hardware vendor to help them determine how IT departments could communicate better, and become more multi-skilled. To summarise, there was one key area of common ground between both network engineers and other operations staff – and that was security.

Meanwhile, and also earlier this year, I was impressed by a presentation from an HSBC senior executive at an outsourcing event. He was talking about how the organisation had merged its IT security unit with its business fraud unit, as ultimately both sides were dealing with the same business risk issues.

It was only in a conversation over the past couple of days that I brought the two occasions together in my mind. So here’s my question – could security be the glue that binds not only the different areas of IT, but also IT with the business? I believe the answer is yes, if it is done in the right way.

There are two pre-requisites for this. The first is a recognition that all risk is business risk, for organisations large and small. Like the tree that falls in a forest when nobody is there to hear it, a breach that causes no business problems (either financial or compliance-related) is probably not worth spending too much time on. So, it is the lines of business that are best able to decide what level of risk they face.

The second is an understanding that security is a quality of IT service delivery. While it is technologically complex enough to be seen as a discipline in its own right, equally, this shouldn’t get in the way of ensuring that the security exists as a horizontal layer across the IT environment as a whole. We’ve all heard the clichés – built-in rather than bolt-on security for example.

Given these two starting points, there is no reason at all way security cannot be central to the dialogues both within IT and with the business. What are your experiences – a re we all business risk and service delivery managers now, or will security forever remain the domain of the nerds? I’d love to hear them.

Let it snow, let it snow... until such time as the kids can't get to school and the rest of us start cancelling meetings, at which point people start to get a bit flummoxed. In Britain, and no doubt in other countries, we treat the arrival of snow with slight surprise, as we find out once again that our transport and heating systems are unable to cope with it all.

From a security perspective of course,the moment of truth is when three-quarters of the workforce find themselves working from home. Too late by then for the SSL VPNs, NACs and NAPs,as execs and staff alike hastily copy the few files they were working on, onto a USB stick which then gets plugged into the kids' PC. It's a test, and a pretty good one at that, given that no exec is going to listen to the IT department saying, "don't do it" if it is the only way they're going to get the job done.

What's the answer? We would suggest education - and fast. If there are ways of working that are more secure than others, then people should know. Not least for example, imposing at the very least a thorough antivirus and spyware check of any computer that will be squatted by the snow-bound employee. There are free packages galore, and if an employee has to use their home computer for work use, they could at least install the minimum of protections on it first (and without breaking the licensing restrictions on said free versions).

No doubt IT support will have its work cut out this week. But a simple email sent now, with some sage advice, could well prevent all kinds of headaches later.

As momentum builds up towards Infosec at the end of this month, I’m reminded of all the previous Infosecs I’ve attended, as a punter, speaker and analyst. It’s quite a bizarre ecosystem if I think about it – in the perfect world of course, we wouldn’t need to see IT security as a separate industry from the rest, but the same argument could be applied to anything to which we say, “Why can’t we all just get along?” No doubt the same principle applies to world peace.

Sadly however, we can’t all just get along, with a number of effects. First there will always be ‘bad guys’ looking to exploit holes in the technologies we deploy, or indeed, looking to take quite innocuous capabilities and use them for undesirable effect. Just as ploughshares can be turned back into swords, so email can be used for spam, unprotected desktop computers can be used to host ‘bots’ for launching denial of service attacks (or indeed, generating spam – do all roads lead to spam?) and so on. The key to all of this would normally be diligence – remembering to lock doors, not take sweets from strangers and so on. But as well as malice, there are other undesirable human traits which make things harder.

First is complacency – that bad things only ever happen to other people. Were we less complacent as a race, no doubt we would raise our expectations on IT, to the extent it would be delivered with less holes in the first place. Second of course, we would more actively look to fill any gaps that remained, and we would allocate appropriate budgets to do so. Squeezing bood out of a stone can be easier than getting budget for security purchases, however great the risks may be.

On the subject of undesirable human traits, to complete the picture we need only to think of stupidity. It was not a bad person who left the laptop in clear view when he popped into the shop, and no doubt Mr Quick did not maliciously wave government secrets in front of press cameras. But stupid we are (I have a whole list of my own examples), and we cannot therefore rely on our own abilities to do the right thing.

It is against this background that the IT security industry has formed, evolved and adapted, as reflected by conferences like Infosec. Sure there will be vendors that ‘big up’ the latest threats – just this morning we took a vendor to task for claiming that insider jobs were in some way new – and there will also be organisations which offer highly appropriate solutions to real problems, but which will never get famous as long as the industry, and indeed the human mindset, remains as it is. Behavioural analysis company Tier-3 springs to mind, pragmatically ploughing their hype-free furrow.

So, what would we recommend anyone attending Infosec? First of all, we would re-emphasise that security products are a means, not an end – and the latter you have to work out for yourself. A good comparison would be with Christmas Shopping – how many of us have gone out in early December, in the hope that an appropriate gift for Aunt Maud would magically reveal itself? In security as well as shopping far better approach is to sit down and write a list beforehand, while can be tough to do but will achieve far more as a result.

As a second point, we would recommend asking the hard questions early. Don’t just accept as read what vendors are saying: ask what exactly one product set has that the competition doesn’t; why exactly a specific differentiator is relevant; what effort will be required to install, operate and manage, and so on. A great deal can be learned in terms of real-time competitive analysis, so don’t be afraid to bounce between the stands to confirm or otherwise what competing vendors are saying.

Then, and this is more a benefit than a recommendation, remember that Infosec brings some of the best people in the industry from the vendor community. Don’t be afraid to really pick the brains of some of the people on the stands or during the sessions, as a better source of free advice you are unlikely to find under a single roof.

Finally, and to summarise all of these points, set yourself a tangible goal. It would not be untoward for example for you to hammer out your security priorities for this year, or determine the realities of cloud-based security, or investigate the strengths and weaknesses of a certain set of products. If nothing else, as you are on your way to the conference list out the ten things you would like it to achieve, both for you and for your organisation.

IT security may be an anomaly in itself, a reflection of the vagaries of human nature and the immaturity of IT as a whole. Conferences like Infosec are a mirror onto this strange ecosystem, both evolving alongside and helping move things forward. We’re not expecting you to understand it all, if anyone could. But with a bit of preparation, and with a clear understanding of your own needs and priorities in your back pocket, the value of conferences such as this can increase tenfold.

What an interesting Infosec! I was asked at the end of this year’s conference, what I’d seen as ‘hot’ topics, and I had to confess that there was nothing that really stood out from a technology perspective. To me it was more of the same – disk encryption, log management, data leakage protection and the like were all interesting, but to be fair they were works in progress as opposed to anything ‘new and improved’.

But bear with me here. This does not mean to say that everything is staying the same. Rather, what marked the conference for me was how its context was changing, from two perspectives: first, the technology landscape within which IT security sits, and second, the way that IT security is evolving in itself and to meet the maturing needs of its customers.

Let’s think first about the technology landscape. Despite the financial turmoil faced by organisations across the world, this is a very exciting time to be in IT. Social networking and collaboration, unified communications and VoIP, software as a service and cloud computing, the explosion in user-generated content, text, graphics, audio and video, the arrival of virtualisation as a mainstream technology, all are having disruptive effects on how IT is being considered and used.

In security terms however (there is always a 'however', in security terms), we are hearing that may organisations are considering, and even adopting such technologies without necessarily putting the checks and balances in place. In Tuesday’s panel session on virtualisation and security, for example, one attendee described how he was trying to slow down the operations teams, as they were seeing clear financial benefits to server virtualisation and therefore wanted to adopt it as quickly as possible; however they were not taking into account the associated security risks and dealing with them accordingly (there’s a good checklist of pointers from Steve Moyle of Secerno here, if you are interested).

We expect to see similar challenges in adoption of cloud computing technologies, social networking and the like – indeed, there are plenty of examples already of organisations being caught short due to data leaks through social sites, for example, or falling foul of compliance law through inappropriate adoption of SaaS. Conclusion: while IT security may not be centre-stage at the moment relative to all these new trends, it doesn’t take a rocket scientist to predict that this time next year, it will be security professionals that are handed the broom and left to clear up the pieces.

All the same I don’t think they will be alone, given the second perspective: that is, how IT security is evolving. This time last year I commented how interesting it was that there were a number of non-traditional-security vendors present – Google, F5 and the like. We’ve seen more of that this year, as (for example) a larger number of log management companies have joined the fray. It’s a small symptom of technical cross-over into new domains, such as application management and IT operations. 

This development is clearly accelerating, judging by a number of the conversations I had with a number of vendors and end-user organisations across the three days. There was plenty of talk about ‘policy’, ‘risk’, ‘governance’ and the like – but not just (as previous years) in passing. Rather, there was a general recognition that, for security to succeed, it needed to be integrated with other IT and business management disciplines. This message came through loud and clear for example in the second panel session I hosted, on data integrity – all panellists were unanimous that data integrity could not exist in isolation of data quality, for which there already exists an ISO standard (ISO 8000).

From my perspective, this is a very welcome development – not least because security is never as effective as it could be if it is being considered as a silo. If I had a hot dinner for every time I have said words to the effect of, ‘the only risks that matter in business are business risks’ - but we all know how hard if can be to engage a disinterested business audience and extract out of then exactly what those risks are, never mind get any funding to mitigate them. So it is surely a healthy thing that we should think about information risk at the same time as information management, insider threat at the same time as business process management and collaboration management, and so on?

Well, yes, but with a caveat. What we’re talking about here is a significant change not only in how security is considered, but also who is doing the considering. With the best will in the world (and through no fault of their own) many security professionals have been focused more on the technical aspects of security rather than such broad topics as information governance or business risk. Meanwhile, there are plenty of more business-oriented specialists who lack the detail in terms of what security technologies can bring to the party. For a successful evolution, it will be necessary to bring down the Chinese wall between security as a technical discipline and governance as a business discipline.

Where to start? This is not something that can be resolved with a game of football between the two sides, as the issue is more one of differing language than any lack of desire to communicate. Ultimately, for security to be successful it needs to be treated as an inherent part of an organisation’s governance processes – we can look at HSBC’s bold decision to integrate their IT security team into their business fraud unit, for example.

If governance is the ‘what’, security is at least one part of the ‘how’. But for integration to be successful, it will require all sides to face the fact that it is only by starting with the ‘what’ that we can succeed. IT security has existed for too long as an end in itself, an isolated satellite leading an independent existence, largely due to a lack of understanding about where it should fit. For IT security, it is time for it to rejoin the mother ship.

This makes interesting reading - it's a report, sponsored by those good people at Imperva, about password worst practices. It's got some sage advice too, for anyone who wants to know how to get a bit better at setting passwords.

Her's the top 10 - personally I'm surprised that swear words don't figure, but that's small consolation. 

1. 123456
2. 12345
3. 123456789
4. Password
5. iloveyou
6. princess
7. rockyou
8. 1234567
9. 12345678
10. abc123

Take a look at the full report here.