Risk Management with Stuart King and Duncan Hart

I've been doing a lot of research into the actual and potential impact on a business of various types of security incident and trying to work out how the various statistical models and other data might fit into my own organisation. It's no easy task because information security incident reporting is very much an ad-hoc business at best and historical data is fairly limited.Some of the easiest to digest research has been performed by the Ponemon Institute and there have also been many papers presented at the various Workshops on the Economics of Information Security amongst others. The general conclusion is that security breaches generally only have a significant financial impact if they involve a breach of confidential data, and that even in this case the effects are likely to short-lived. In fact I can cite various incidents that made the popular press over the last couple of years that support this conclusion. However, if you are operating within an organisation that is increasingly placing more eggs into the Internet basket and as a consequence increasing your risk exposure does the research still hold sway?

A couple of days ago I encountered a person whose business card made reference to no less than 5 different information security related certifications. Should I be impressed? The answer is simple: yes I am! Let me explain.

We seem to be very hasty to pour scorn onto fellow professionals who flaunt their certification credentials. A few years ago I achieved MCSD (Microsoft Certified Software Developer) status. The entire process required a good deal of study, no small amount of time and a fair amount of personal expense. However, as I proudly displayed my new Microsoft Professional card around the office, the overwhelming opinion of my colleagues at the time was that all it meant was that I could study the required texts and pass a multiple choice exam. However, the certification opened a few doors for me and a couple of years later I found myself in a position where I was interviewing candidates for development roles. I would then give preference to the MCSD certified candidates every time because, practical skills aside, their certificate demonstrated back to me that they were passionate about their career, and had studied their field in depth.

I was reading David Lacey's latest blog entry with some interest. One of the challenges I'm currently faced with is to present an achievable and realistic set of objectives against which my personal performance for 2007 can be judged. But it's important for more reasons than just my own assessment because without having a useful set of metrics against which to measure success, and given that information security can often appear to be a big money pit with little return on investment, then how else can there be any judgement on success or otherwise? Of course, from a web product perspective we could just measure success in terms of the number of reported incidents. That's all fine and dandy but if we have no incidents then does that mean we have good security? Nope. It probably means that we've just been lucky. Instead, let's judge success against an assessed security standard - set your standards (first you have to define what it is that you are protecting against and define your mitigating controls) then find out the degree to which you have controls in place sufficient to achieve the required standard. So, you now have a standard and you also have something against which success can be measured because it's possible to develop a strategy based around improving the overall assessment scores.

This isn't a program that I can lay claim to any credit for as it was in place within my own organisation long before I came along, however, it's something that has become more sophisticated over time and the results of assessments have become useful and measurable security metrics.

Anyway, just a short blog entry today as I'm in the final stages of putting together a workshop session on product risk. As always, leave your comments on this subject and any of the others that I've raised, whether you agree with me or otherwise.

Much of today was spent leading a workshop session for product management people on the subject of security and risk. The session went well and one particular point of feedback resonated: it was commented upon that the perception prior to the workshop was that it would be a day full of technical jargon for a technical audience and consequently attendence was under some duress. So, the person in question was pleasantly surprised to find that the topics were discussed at an easy to understand non-technical level and more suprised to actually learn something and take away some useful information.

Now - and hold on a moment while I get my soapbox out for this bit - talking up to non-technical stakeholders is pretty essential in my opinion if we want to ensure that security and risk are understood at a senior level. It's where soft communication skills win over hard techie talk and I'll be the first to admit that this is something that takes time to learn. I can chirp on all day about encryption algorithms, cross site scripting and denial of service attacks, and just watch the audience all reach for their blackberry's simultaneously at only the third mention of the term "regulatory compliance." What is wanted is some plain talking, business orientated discussion. In other words: here's the problem, here's a solution, this is how much it's going to cost.

So, right here and now I'm kicking off my personal campaign for clear talking. No jargon, no technie twaddle. If we want to win the business over when it comes to security and get the right messages across, then clear talking wins the day!

What do we mean by "security"? Really, what we are doing in this job is probably more adequately described as "asset protection" although I once chatted with a professional bodyguard and that's what he said he did. Perception is important because within the organisation, as an information security professional, you are likely to be in a very small minority.

If you say that you work in security what's the first thing that people reply. Here a few responses that I've had:

"Where's your peaked hat?"
"Do you want to check my pass?"
"Have you got a gun?"
"Let's go to bed"

OK, I made up the last one. And tell someone that you are in IT Security and the sex factor takes a real plummet as they imagine you sitting in a dark basement, munching endless pizza, trying to hack into government computers for a game of thermonuclear war.

One of the stated objectives of this blog is to describe some of the operational challenges that I encounter on a day-to-day basis. My role is certainly challenging with a good deal of variety: one day I might be conducting a risk assessment on behalf of any one of more than two hundred business units, and the next being of assistance to a development group requiring guidance on how to achieve regulatory compliance. A lot of my job is writing reports and updating various internal guidelines and standards. It sounds mundane but our documentation is a part of corporate governance and so it's important that it's suitable for the audience to which it's aimed.

I've been involved in a debate today about iTunes. More to the point, about whether iTunes should be permitted installation onto a company owned PC. A colleague of mine was quite adamant in his view that "there is no business reason for it so it shouldn't be installed." Now, I can quite readily concur with this view, but hold on a moment: I'm not sure that some-one from Information Security should be expressing a view on what is and what isn't a justifyable business application. As far as I am concerned, we make decisions based upon a) corporate policy b) reasoned professional judgement c) associated level of risk d) the needs of the business as they are described to us. So, if someone within the business says that they want iTunes and we don't have a good policy based reason to say "no" (in fact we do have a policy on unauthorised software but the question was whether or not this particular software could be allowed), then the next thing we can do is provide some measure of informed council to the party concerned.

In this particular instance my recommendation was not to allow the software to be installed - my justification being that the onus is on the business to support it, keep it updated, together with added risks from files that might end up on the PC in breach of copyright. It's also worth noting the End User License Agreement (EULA). How many of you actively make sure that this is reviewed, by someone with contract experience, for all software installed onto company machines?

Personally I have nothing against the software in question - use it myself at home - and I don't want to spoil anyone's fun. However, in the workplace we need to consider such requests from a risk perspective, do our research, and if we are going to refuse a request have a reasoned arguement based on facts in support of our decision. Obviously there is an arguement that a standard desktop build with a more restrictive policy on software installations would go a long way towards negating the issue altogether. I don't dispute that however, company culture also plays it's part and I'm glad to be part of an organisation that provides a degree of flexibility within most aspects of work-life. It might make for a more challenging security environment - and that's perfectly OK by me - it also makes it a better place to work!

Some news in SC Magazine caught my eye:

Businesses are failing to boost productivity by preventing wireless internet access to visitors due to security concerns, new research shows.

This is just the sort of crass reporting that really gets my goat. Firstly, the organisation performing the research in this instance is a WiFi provider so it's not exactly a neutral viewpoint they are coming from. Secondly the quoted Managing Director of Guestbridge is one of their customers and thirdly, the article says that they sought the views of IT workers - well, I'm sorry to say this but just about everyone I know in IT will say that we need to have the fastest, newest, shiniest, technology without a thought for whether it's actually of any use or not. Me included (and support - if you are reading this, please can I have one of those new shiney things that goes beep, before it becomes obselete?).

Now I can tell you that the reason there is no wireless in Corporate Towers (the office I'm based in) is absolutely none of those listed in the article - and while 23% of the HR department polled suggested that they suspect it might be useful if a guest turns up with a laptop computer expecting unlimited Internet access at our expense, the corporate management decided that we'll make them endure the horrid incoveniance of having to plug in a nasty cable. And do you know what: I'm not sure that our productivity has dropped by a single percent as a result. But the productivity of our IT support certainly would if they have to spend all their time running after VIP guests who want to check their Hotmail accounts from the comfort of the reception area and wonder why they are viewing the Intranet system of the company next door.

I'm astute enough to know that having wireless can be conveniant for visitors. We have a number of business units that do have wireless and offer guest access. In fact, as an organisation we've done a good deal of research into wireless and associated security - providing campus wide solutions and being early adopters of new technology. But does it increase productivity? Perhaps the missing 12% from The Cloud's research might be able to tell us (check the numbers).

Is it possible to demonstrate a return on investment for our security efforts? This is an aspect of security of particular interest and something I always consider to quite a degree when thinking about policy and how best to mitigate risk.

One particular challenge is how best to deal with the need to ensure that the business meets all of its regulatory requirements and customer expectations around the protection of data whilst also considering the pressure to manage costs.

There are a number of aspects to the problem. Firstly, a lack of "emperical probabilistic risk data" for us to be able to assess the real probability of various attacks occuring, secondly the rather tenious and misleading ROI product benefits touted by security vendors. So, as one particular researcher stated we usually end up making defensive decisions based on "heuristics and experience" and yet another has stated that the use of financial tools for calculating information security ROI is “highly suspect, often misleading and inaccurate.”

We therefore end up with no real way of measuring the profilitability or otherwise of our security investments.

Security relating to offshore data centers has been in the news lately. Indian call centers in particular have been the target of a good deal of negative attention such as this BBC report about a recent Channel 4 programme.

Personally, I believe such stories are unnecessary scare mongering. I believe this because I've been to India and performed security reviews onsite at a wide variety of locations and without exception, the level of security and the management of security is something that many UK based firms could probably learn a lot from.

David Lacy mentions in his latest blog that our ability to safeguard data depends upon "sensible application of well-established security technologies." I am in complete agreement and this remark also relates to our efforts to maintain regulatory compliance: as I discussed in my blog yesterday.

At the present time I'm working on a method of categorising web products according to their risk profile: the profile is based upon strategic importance, revenue and, of course, the regulatory aspects. By doing this work, we can ensure that a security policy is applied that relates to the risk posed by the product. Of course, just having a policy doesn't provide assurance. That assurance comes through having good development processes throughout the life-cycle, and having thorough risk assessment, review, and risk mitigation processes. It's all part of having a sound Risk Management Plan (RMP). The RMP is the foundation of my work and over the next year I'll be providing some insight into how successful or otherwise this is.

Cryptogram is a monthly newsletter produced by security guru Bruce Schneier. I have a lot of respect for Bruce's writings, and he's been an influence on my own security views. Anyway, this isn't supposed to be testimonial to the work of another person, so I shall get to the point: in the latest edition of Cryptogram, there is an interesting quote: "the reality that passwords have outlived their
usefulness as a serious security device."

I couldn't agree more, but this is not a new message. At last years security summit in London, for instance, Ant Allen of Gartner stated that "passwords are no longer adequate, as threats against them increase." But so much for the propaganda, are passwords really obselete and, if so, then what are we to do about it? It's all very well these pundits telling us what's wrong but they are not exactly forthcoming with a solution!

There is risk attached to everything that we do. In most everyday situations we attach a value to risk using instinct and judgement based on experience. In business we need to be more precise: we can make judgments based on instinct but when there are the interests of customers and bottom line revenue at stake it's much better to have a more scientific process.

First, and more importantly we need to ensure that we have identified the risks most applicable to us. Leo Cronin, Reed Elsevier's Chief Information Security Officer, makes the point that "choosing risks appropriate to the target audience is a key to success." (see this article from Cybertrust on Justifying Security Spending) . While this is true for ensuring that we can make a good case for justifying where we spend our security dollars it is also essential for building a model on which to perform our analysis that contains relevant risks. Risk is most often expressed as the product of threat multiplied by vulnerability, but for business purposes we bring in additional cost factors. So, even if the vulnerability and the threat can be rated as high, if there is no associated cost then it's not a risk worth investing our resources in.

A great example came up today of exactly what I was talking about in yesterdays blog. Some-one raised an issue with regards to our corporate Intranet and the fact that after performing a certain set of actions he could see a directory listing of files. The perceived risk was that data could be compromised.

Firstly, a word about trying to "test" security for yourself - it's generally not a good idea to do so. Your efforts are likely to be interpreted as malicious.

Back to the point. In this particular instance we have:

1) Scenario: the Intranet site can be compromised through mis-configured directory security resulting in modified or deleted data

2) Threat: I rate the threat as low. The reason being that it's an internal Intranet. There is no external access.

3) Vulnerability: I rate this as low/medium. There is clearly some vulnerability as the directory structure is available for all to see. An attacker with the right tools and knowledge might be able to compromise the data. However, as there is no external access I do not rate this vulnerability any higher.

4) Costs: Impact on revenue and reputation I would rate as zero. There is no confidential data available to compromise through this area of the Intranet and an attack would not have any external impact on the good name of the organisation. There are likely to be some resulting opportunity costs - restoring data from backups perhaps and support time to ensure that the server is correctly configured.

We can apply some maths to all of the above factors to give us a calculation thus:

Risk = Threat x Vulnerability x (operational costs + reputation costs + support costs)

In this instance, the result is going to be low risk.

However, why not try this at home! Take your organisation's most important web product and try out this scenario for yourself. Test out a few other scenarios then take a moment to consider what controls you have in place to mitigate the risk. Are they sufficient given the level of risk that you have assessed?

A new VISA incentive program for payment providers (i.e. "acquiring financial institutions") caught my interest. You can read an article about it here. The essential detail is that for every merchant out of compliance with the PCI DSS a fine of between US$5000 and US$25000 will be levied onto the acquirer. Conversely, incentives will be paid out for validation of PCI compliance.

I'm all for PCI compliance - it's really a good set of common sense basic security measures that we should all be implementing in the best interests of protecting customer critical data. And while I'm critical of the way that some of the guidance and standards are put together, the threat of financial penalties can sometimes be a good kick up the rear-end in motivation to put new programs in place.

However, I'm not enthusiastic about an incentive payment scheme - I believe that such schemes have the potential to undermine the standard by turning it into an exercise in achieving the pass mark rather than a serious effort to protect data. For instance, item 1.1.8 of the standard is for a "quarterly review of firewall and router rulesets." The associated audit procedures directs auditors to "verify that the rule sets are reviewed each quarter." Such a review of rulesets is certainly an important process to have in place and some might argue that quarterly is not often enough however, how should an auditor verify this? A signature in a log book would probably suffice as evidence but it does not prove that a process is being followed. There are other areas too that concern me, particularly in section 6 on software development and the means of verifying that systems are not vulnerable to various mentioned vulnerabilities such as cross-site scripting and unvalidated input. Now, I have personally seen examples of systems that have been tested by authorised PCI auditors using application scanning tools and been given a clean bill of health only for it later to be found that they contained discoverable flaws that could have resulted in exactly the sort of incident the PCI standard is supposed to be preventing. And even if an auditor does successfully and accurately give an application a clean bill of health then the very next change request could undermine all the efforts.

Security should be adding value for customers - they come back because they know that their data and payment information is secure with you. VISA have their hearts in the right place so instead of incentives on the acquirers, how about a "VISA certified payment provider" stamp on products and some truely verifiable audit procedures? Just a thought!

How are you viewed within your organisation? Is Information Security seen as an automatic invitation to new project meetings and product reviews, or do peers try to avoid discussing things in too much detail with you just in case they mention something that is out of compliance with policy?

I've spoken a lot about perception already in this blog but I keep coming back to it because to be effective in managing security it's important that the right people are open to working with you and that you are perceived in the right manner. More importantly; as an ally rather than adversary.

If you're in a small organisation rather than the sort of mega-global enterprise that I work in then I don't know if your task is any easier. Maybe it is because you have fewer people to deal with but then again maybe it's more difficult for exactly the same reason.

If I had to sum up the single biggest challenge that I have faced during 2006 in addressing and mitigating risk, it is not technical, it is not operational, it is interpersonal. Every single issue I've raised, presentation I've given, risk assessment I've produced has needed to be tabled in front of multiple groups of people who all need convincing as to the truth, accuracy, and value of what I am saying. If you want people to take time and spend money in the name of risk mitigation then you need to be able to paint a picture in words, appearance and (frequently) PowerPoint in order to have the issue addressed.

Now, it's easy to say that a governance model with teeth would get around some of this issue. But I don't buy that. Sure, if you are in the military then a corporal can go tell a private to dig a hole and the job will get done without question. But here in the business world where your time is measured in an hourly rate and where you'd rather be adding a new ring-tone to your BlackBerry than having to listen to another techie telling you that the world is about to end, then we need to be convincing.

So, in which case can anyone do this job if all they need is a nice suit and a clear voice? I'll let you answer that one....

David Lacey mentions the importance of embedding security into the SDLC in his blog . It's a view I completely support and frequently see the positive impact on risk status between those products with an embedded process and those that don't.

Implementing embedded security within the SDLC does not have to be a complex process. In fact, quite the opposite in my opinion. Making the process simple and transparent is the key to success but getting acceptance within large development groups, used to operating in a particular way, is never going to be easy.

The best technical resource that I would recommend is "The Security Development Lifecycle" by M Howard. You can buy it here on Amazon.

But as usual it comes down to how well you can communicate the benefits. Just about every developer and manager I talk to is open to the concept but in practice the pressures of delivery and costs are seen as being overwhelming. So my advice is to set small, achievable objectives rather than to try to rush headlong into a new all-encompassing process. It's working for me here.

I got asked a very important question today. The question related to a report I have written covering the risk status of various different products and situations. It's a very detailed and indepth report making numerous observations, drawing a variety of conclusions and making recommendations. So, to the point and the question in question. It was "how important is this?"

I thought I'd made the answer to this question clear but I re-read the report and it got me thinking again about quantifying risk and also how my perspective on risk differs from the business perspective. There's some further commentary on this subject and the executive perpsective on Kenneth Belva's blog. But even this is not the full picture because the amount of risk that is acceptable will vary from business to business and from product to product. So, in one case there might be a willingness to spend thousands of pounds preventing an equivalent amount of risk while in another case the attitude to risk could be significantly different.

Kenneth draws attention to a Virtual Trust model and how security can add value. This is a really interesting paper and I recommend that you have a read if you're interested in this subject.

How many botnets reside within your network? Are you worried about the almost certain fact that they do?

I described it to a colleague today as being similar to rats in a sewer. These insidious creatures crawl around within the dark tunnels of our global network usually remaining out of sight. We know they are there but unless we go on a hunt it's unlikely we'll actually see them. My colleagues' view on the matter is as follows

"So in infosec nuisance malware is just that, but must not be allowed to take the focus. The focus needs to be what matters, the effects on the company and its information/reputation. So this comes down to managing the risks and knowing what the critical assets are rather than trying to protect every device and scrap of information as equals. … you have as much hope of protecting everything perfectly as removing the rats from the sewers of London."

It's a view I fully agree with. Instead of chasing rats, focus on protecting assets. We have little choice but to live with the nasty stuff so be aware that it is there, mitigate risk as far as you can, and don't spend too much time trudging through the sewers because it's not very nice down there!

There some more information on botnets here including a link to an interview with a botnet owner - won't his parents just be so proud!

http://www.wormblog.com/2006/03/an_inside_look_.html (an excellent blog)
http://www.mckeay.net/secure/2006/02/botnet_owner_interview.html
http://www.schneier.com/blog/archives/2005/12/dutch_botnet.html

I was recently reading through some literature provided by a vendor describing the security behind a particular solution under consideration. The literature in question describes a multi-layered architecture with domain seperation, and use of encrypted channels between client and server. The document explains how the database and application servers are seperated and that the "connection between the Application Server and the Database Server can also be encrypted using SSL". Brilliant, I think to myself. Sounds like a suitably secure solution for the job in hand. So, being ever diligent, I investigate how it has actually been installed and implemented by the vendor: the originators of the documentation....

Instead of finding something heart-warmingly secure, I instead discover database and application installed on the same patched up file server, open to the global network with no encryption between the clients and the back-end.

Some might - and will - argue that it's an internal application with no external connectivity and a limited user base. In turn I will argue that it is processing confidential data across an open network contrary to good practice and contrary to the interests of the people who presume that their data is being suitably protected.

I have a couple of frustrations

1) That an enterprise project has already been deployed before information security are made aware and further, that I only became aware because of a coffee machine chat with some-one working on the project

2) That a solution has been deployed with no recourse to any security related process. Sure, some effort has been made on ensuring that strong passwords are used but no thought given to security of the data and no consultation with any internal security resources

So, I am readying myself up for a round of meetings, risk assessments, discussions, debates, late nights, too much coffee, resulting insomnia, eventual madness and finally death...ok, ok, I'm being flippant - it's a serious matter. But you've got to laugh.

Todays big challenge has been to deploy a new version of a management tool that we had developed for storing our business unit risk assessment data.

It's a big deal because having the information relating to more than 160 business units stored in a single database allows us to have very granular reports - for example, at an instant we can see a list of all business units that might have one or more risk categories out of compliance with policy, or we can view all business units that are making use of a particular brand of security device. It also enables us to look for patterns across the organisation - for instance perhaps a majority of business units are having difficulty achieving compliance in a certain area so we can focus on that area and determine the best ways forward.

The original process was Excel-spreadsheet based so getting access to this level of information could be a very time consuming process. With the database, it's much easier for us to manage and review security objectives and set measurable targets. It's also easier for businesses to update their own information. Instead of having to fill out a new spreadsheet they only need to update their information online.

So, back to todays challenge of deploying a new version. Did it work? I can hear you asking...no! It's all gone pear-shaped and we are going to have to roll the deployment back to the previous version and hope for better luck tomorrow!

Another news story suggesting that a hacker "may have breached" information but that personal information "was not compromised." If you want to read the full story then go here. I'm not sure it's even a story worth reporting. This particular university has a large computer science department - so we have a large number of students, with access to huge computer facilities, and they get surprised when they find "unauthorized movies and games on the network." Not exactly a case worthy of Sherlock Holmes.

But it does raise the issue of what comprises an incident, how we identify and categorise an incident, and what is an appropriate response. I found this definition of an incident here:

An Information Security incident is an event which appears to be a breach of the organisation's Information Security safeguards.

Incident refers to an adverse event in an information system, network, and/or workstation, or the threat of the occurrence of such an event

An event is any observable occurrence in a system, network, and/or workstation

Anyway, to finish off, here's an interesting blog on incident response for the more technically minded: http://windowsir.blogspot.com/. Lots of links to other resources and some good narrative too.

Still on the subject of incident response, I was reading this article on the "Seven Steps To Follow When Data Leakage Strikes" as described by Experian's CISO, James Christiansen. I've not met James but given his role and his organisation I'd certainly follow his advice on this subject. One item that particularly interested me was this one:

Offer a whistle-blower hotline or some other means for employees to confidentially report on suspicious or criminal activity that should be further investigated. Assign a code to each tipster's name so that identities aren't revealed. Nearly 70% of the time, insiders tip companies off to a problem, Christiansen says.

There's some more good guidance on the CERT website at http://www.cert.org/csirts/Creating-A-CSIRT.html#1. This one begins by stating, rather obviously, that "without management approval and support, creating an effective incident response capability can be extremely difficult and problematic." It's an old, familiar message yet I still encounter technologists who believe that the business revolves around them and their ideas.

Finally, another interesting - if lightweight - article from Michael Gregg MCSE, MCT, CTT, A+, N+, CNA, CCNA, CIW Security Analyst and TICSA (and also two associate degrees, a bachelors degree and a masters degree), the President of Superior Solutions. With those credentials and that company name then we'd better listen! Anyway, Michael's article on incident response is here and I particular like item number 5. This is identification of what caused the problem in the first place. The post-event post mortem is important but I'd suggest not turning this into a witch-hunt with the objective of laying blame on individuals but to be critical of the processes behind the event occuring. The priority should be to ensure that further bad outcomes are mitigated.

What exactly does "compliance" mean? If I'm reviewing a product and conclude that it is compliant against some particular policy or regulation then what that really means is that it is compliant at that particular moment in time. This is a point well made on the PCI blog and it's something that businesses should reflect on regardless of whether they are aiming for compliance with regulation or simply wanting to comply with an internal policy. The reason, obviously I hope, is that web products in particular present a moving target. A component deemed secure today might be completely insecure tomorrow when the next change is implemented .

It's therefore important that change control includes processes for ensuring continual compliance. Changes should be reviewed for security impact, and their risk assessed. It sounds easy doesn't it? But that's assuming that there are suitably security-aware people available and also that the potential impact of a change can really be known. For instance, a change request to open a new port on a firewall can be easily assessed, however, a request to deploy a new customer-facing enhancement to a web product needs a diffierent approach. Having security baked into the SDLC is an obvious good place to begin however, playing devil's advocat here, let's say it's a change that needs to be implemented fast to resolve an earlier customer-facing (non-security) issue. There is going to be a good deal of pressure to deploy: the business needs to maximise revenue and get the product working fast, the development group is going to be under maximum pressure to deliver fast and the developer will be focusing on the functionaility rather than the security. Can a compliant product still be delivered under those circumstances?

The answer, in my opinion, is probably no. The most likely result will be after-the-event bug fixing and a period of non-compliance. It's an expensive way to do things and while we all know it's cheaper to address problems prior to deployment the real-world is often not as we would really like it to be.

So, faced with a need to be compliant on the one hand but a star product requiring a quick but complex change on the other what can we do to ensure we don't attract the ire of the auditors? PCI clause 6.6 might provide some of the solution. Namely "installing an application layer firewall in front of application." Yes, I know that I've previously stomped on this clause and bemoaned the fact that it's not problem solving from a development perspective but from a business perspective it's a different matter because while the bugs still sit on the server, at least the device is protecting against them being exploited.

It's not a perfect solution and I'd prefer to see more review and testing during the life-cycle but as I stated earlier, the reality is frequently less than perfect and our role at the end of the day is to adequately mitigate risk. In my mind that means ensuring that the business can still function, protects assets, and meets it's security and compliance obligations in the easiest, most cost-effective manner.

So, going back to change control, which is where we came in for this blog, we need to work on improving processes to ensure that security impacts are reviewed but we also need to be aware that this cannot always be assured. When that is the case there are alternative solutions that help us maintain compliance. Make sense?

One last word, and sticking on a PCI theme I wonder if TJ Maxx - the latest company to suffer a breach of credit card data were PCI compliant. There's a clause on the TJ Maxx web site privacy policy which states: "Unfortunately, no collection or transmission of information over the Internet can be guaranteed to be 100% secure, and therefore, we cannot ensure or warrant the security of any such information." That, in my opinion, is a crass clause that has no regard for their customers. Instead of making such blunt and utterly pointless statements surely it would be better to state that they are doing all they can to mitigate risk. However, current events show that they obviously were not and I wonder how their own change control measures up. Anyway, another example of a business making the headlines for the wrong reasons and it should serve as a reminder that compromises are still very much a danger if we leave the door open. Amen!

A couple of years ago a UK town council banned hanging flower baskets from public display because of the thoeretical risk that they might fall down and hit someone on the head. You can read the story here. I wonder if this is any more an absurd scenario than the one where an American, talking about his PDA, considers "What happens if I leave it in a phone booth when I'm running to a plane and my competitor picks it up?" as detailed in this article: http://www.networkworld.com/reviews/2000/0320pda.html.

Mr. Paranoid in the above quote should take more care of his toys, and if he has the sort of job where people are chasing after him in the hope that he'll drop something of value then he probably shouldn't be talking about it. However, when we are considering risk scenarios, where are the checks to prevent us trying to waste our time implementing mitigating controls where we really don't need them?

Presumably Bury St Edmunds council had researched statistics of hanging basket related trajedies before they decided that the best risk mitigation would be to remove them altogether (as opposed to perhaps using longer bolts or tougher rope). Now, if there could be found some history of people receiving knocks on the head from falling basket-based fauna then this pro-active reaction is understandable.

Are we prone to taking similar knee-jerk reactions within the information security realm based on non-existant or poorly understood risks? I'd like to think that this isn't the case but a lack of historical data around many of the risks that we consider means that our judgements often have to be based on qualitative opinions rather than quantatitive facts. The danger is that we will end up crying wolf as described by David Lacey over in his blog rather than actually mitigating risk.

There are a number of reasons why we don't have much in the way of historical data to rely on when constructing risk models: for instance some of the risks simply didn't used to exist as we relate them to electronic systems. Another is that organisations have not maintained information security related metrics relating to various bad outcomes, or where metrics have been kept these remain company secrets and are not shared outside of the organisation.

The result is that sometimes we are likely to take unnecessary action and remove a perceived threat even though the assessed risk has never actually been recorded to occur. So, hanging basket lovers everywhere, should be climbing those wobbly step-ladders and taking them down....

What makes for a good security blog? I was reading a comment from a well respected industry name who states that much of the content on the web is either "technical and often incorrect" or of "no practical use to most of the business world who all use a computer on a daily basis." See here for more details. It got me reading back through some of my recent entries and wondering which category they might fall into. My stated objective of this blog is to talk about issues and challenges that are relevant to my everyday work as a security professional within a large organisation, and one of the things I've learnt over the last couple of years is that my while my technical skills are important, my soft skills are most critical to me being able to accomplish my goals in the office.

However, I don't want to play down the importance of maintaining a good set of technical skills. Credibility within the organisation is important and when discussing security with technical people it's important to know and understand the technologies, and to keep up to date with the industry. A good deal of my time is spent trawling through technical guides, installation guides, faqs, knowledge bases, and various other sources of information, and if I still have time after all that I might have some left to mess around in my own test lab. The latest thing I'm looking at is CAS - Central Authentication Service. It's an open source authentication system being assessed by various development groups that I work with. It's fairly simple to implement and a great, scalable, cost effective solution if you're looking for a way to implement centralised authentication without spending a fortune on one of the big commercial enterprise solutions. I'll probably talk more about this and other open source products at some time, maybe even on a technical but correct level!

So, back to my original point, let me know if you think this blog is useful or not or if you'd like me to go into more detail on particular subjects. I can always Google for the right answer! Only kidding....but it reminds me of a consultant I dealt with a few years ago who, on being asked if his company could a service to implement a certain vendors content management system stated "sure, we don't actually know that one but we can download the documentation and come on over to you..." Talk about money for old rope!

Few will argue that vulnerability testing is not an important part of the online product lifecycle but I was caught slightly unawares by this question in a recent meeting: if we test a product, and identify vulnerabilities how do we get the resources and budget to resolve the issues within an already tight project schedule where customer focused features are a priority and margins are tight?

Fixing security is unlikely to take priority over new features unless a very strong case can be made for doing so. So, it begs the question, when is the best time to perform testing and what should you do with the results?

If the development cycle is complete and the product is due to go into production then there can be little expectation that security issues are going to be quickly resolved on the back of a vulnerability test unless they are show-stoppers (i.e. high risk of compromised regulatory data). It's clearly a bad time to be doing this type of testing. Conversely testing further back in the lifecycle is not necessarily going to paint an accurate picture of how the product will look once it's in production - at those stages of the process then unit testing tools are a good solution as discussed in one of my previous postings. Testing the product in it's production environment will provide the best report from a pure black-box perspective but that still leaves the question of how best to address the report and deal with issues.

Now, the whole arguement might sound rather academic - in other words, you're thinking: problems have been found and they need to be resolved. But consider that up against tight schedules and tight budgets. If you can have either 10 days worth of development to resolve security issues against 10 days of development to implement new revenue generating features then which one would you choose? So once again the discussion comes down to assessing, communication of and acceptance of risk. Resolution might need to wait but in the meanwhile the least that can be done is ensuring that potential bad-outcomes are known and that risks are "owned". It's not a problem I've yet had to deal with here, however it's certainly worthy of discussion the next time you begin a round of vulnerability tests.

The current challenge is to put together a new security assessment questionnaire focused on data handling. I'm working on this with one of my American colleagues, and predictably we've both come to the floor with different views on what questions need to be asked. This isn't detrimental though as it's precisely this sort of collaboration enables us to come up with solutions that are viable across multiple different business environments.

So, the decision is to firstly focus on the types of data being handled, and then to dig into the processes in place around storage, transportation, and destruction. We'll score the questionniare in a such a way that answering "yes" to any particular question will show an overall reduction in risk with a minimum acceptable base-line score set so that we can track which businesses are adequately mitigating risks in this area. Make sense?

My blog has been unattended for a couple of days as I returned from some overseas travels and have been playing catch-up on home and work life. One of the subjects that came up whilst away was offshore vendor security.

Offshore vendors are used for an ever increasing variety of work. One of my roles is to evaluate the risk associated with using a particular vendor. It's something I wish I was doing more of because my visits to India and other places east are full of friendly hosts and excellent food. In one particular Mumbai restuarant, Miss World was sitting a couple of table away. She must have known that I was in town although was obviously too shy to come over and say hello...

Besides the hospitality, the onsite visits provide an opportunity to dispel any prejudgements that might have been made with regards to how operations might be organised within a particular location. Without exception, my experiences to date have been very positive, but we need to be clear about something: when we outsource the one thing we do not do is outsource the liability for security. We still have to perform due diligence work to ensure that risks are being adequately mitigated.

There are a number of elements that we focus on dependant to some degree on the sort of work being performed. The one place that we usually start is by making an assessment of the vendor based upon our own standards. If the vendor can meet the same trust levels as one of our own business units in terms of infrastructure and asset management then that's a good indication of them being an acceptable partner for us to have a level of trust in.

However, one of the things I want to draw attention to is that the onus for delivery and the security around it is not completely down to the vendor. When looking at outsourcing I also tend to look inwardly too at the business unit making use of the services. There are a few questions I'll be asking - for instance the degree to which the SLA takes security into account and the estent to which deliverables are reconciled against the SLA. In the case of software development it's also good practice to review deliverables.

It's that final point that often causes me the most frustration because while a business group might state that deliverables are reviewed I am likely to find that the requirements originally given to the vendor lack enough detail for a thorough post-delivery review to be completely successful: because if requirements were lacking then how can a full review be performed!?

Anyway, that's a theme I'm sure I'll come back to. In the meanwhile here's a couple of good blogs dedicated to outsourcing that you might find interesting.

http://www.go4outsourcing.com/blog/
http://www.blogsource.org/
http://www.outsourcing-weblog.com/

I know that this isn't supposed to be a blog for passing comment on the news and that you are all reading this because of my detailed expose of everyday life at the sharp end of risk management. However, I saw this article on the front page of Computer Weekly and couldn't resist taking a swipe of my own. Here's the headline:

An NHS trust board has approved the sharing of smartcards, in breach of security policy under the £12.4bn NHS National Programme for IT (NPfIT), because slow log-in times would restrict the time of doctors treating emergency patients.

It's a disturbing story. What disturbs me most is the retort of "the monitoring process revealed no breaches of security." Monitoring what? It's a breach of security every single time a smartcard is shared. Those words alone make me go pale because they demonstrate a total lack of regard for process within an environment where privacy is critical.

I'm not finished yet on this one.

Having slated an NHS Trust in my blog yesterday for its misuse of smartcards, I was wondering how I would resolve the problem if it were up to me to manage the situation. Let's review the problem: fast access is required to records however, the system doesn't allow system users to gain access as fast as they need to in order for them to perform their jobs. The solution presently in place, as stated in the Computer Weekly article, is for smartcards to be shared - this enables the software to remain logged in and facilitate fast access to the necessary data.

The result is confidentiality at risk because anyone can access records without audit, and therefore integrity may be violated as a result. Lastly access is clearly an issue because of the system as it's been implemented

So, can the sharing of smartcards, as described, be acceptable? The answer has got to be: perhaps. The most important things here are management and accountability, so if someone is sharing their card then that can be acceptable so long as a record is maintained of who it is being shared with and when. Here's what I would do: make smartcard owners responsible for all transactions that occur using their cards and maintain a written log next to the terminal so that people making use of someone elses smartcard can quickly jot the time and their initials when they use the system. It's a simple, low tech, cheap, solution that manages the risk.

You could argue that users of the system will simply forget to sign the book, or that a malicious user could still violate the system. That's all true and you can never manage away all risk however, at some point you have to determine the point of acceptable risk given the constraints.

As the security manager I'm still not happy about smartcards being shared but at least risk is being managed and there is accountability. While all that is going on I trust there is also a plan to have the system modified so that these actions aren't necessary for too extended a period. Risk mitigation actions in deviation from policy must have a clearly defined cut-off date otherwise what begins as a temporary measure ends up becoming acceptable practice.

Problem solved. Time to put the kettle on.

There has been some discussion within the business about whether or not to enforce passwords that contain special characters (e.g. &*$! etc) for access to a particular enterprise system. I'm not in favour.

Here's why. If we enforce strong passwords that contain special characters then everyone will use P@55w0rd. The really clever people who will come up with an eleven character variation of their pets name or line 5 from the 4th page of their favorite novel will then either forget it by the next time time they log in or have to write it down somewhere, invariably lose the piece of paper, and then have to call the helpdesk for assistance.

We can find good guidance in multiple places for creating strong, memorable passwords so I wont go into that detail here except to say that I think it's sensible to have a policy where passwords are enforced to contain a combination of three out of four of i) lower case letters (e.g. a-z) ii) upper case letters (e.g. A-Z) iii) numbers (e.g. 0-9) iv) special characters (e.g. !@#$%^&*()_+|~-=\‘{}[]:";’<>?,./) . This website here will tell you whether or not the password you want to use is strong or not. There's a good article here about the length of time various password lengths will theoretically take to crack.

So back to the original point of todays blog: my policy would be to allow special characters but not to enforce them. Of course, the solution to the problem must, as ever, come down to risk. For some systems we might assess the risk as being too great as not to enforce special characters. But then how do you then enforce users to remember the passwords they have set? Perhaps that comes with practice and for a small group of users then it might be practical. Have a good day! $tU@Rt &1nG

I'm starting off this week with a task to create a better method of assessing risks around data handling. I think that this is an aspect of security sometimes overlooked in the rush to mitigate risks in other areas: and while we do our utmost to ensure that infrastructure elements are being protected and that unauthorised access to data to taken care of, the actual handling of the data itself can leave itself open to exposure.

I'm splitting the assessment into three distinct areas: storage, transport, and disposal\destruction. I'll be looking into not only electronic transport of data (e.g. by email) but also physical transport such as when data is despatched using a courier service. I'll also be looking at storage on removable media such as memory sticks. First and foremost will be a look at the processes in place for marking-up data correctly and also data ownership. This also requires there to be a high level of awareness in place over when data should be marked-up with a classification and what classification to make use of.

It's an important exercise and it'll be interesting to see what variations there are across our global business in how this subject is handled.

I was pleased to read the announcement that OpenID and Microsoft have teamed up. Read more about it here: http://radar.oreilly.com/archives/2007/02/openid_gets_a_b.html.

This could be a significant partnership and a strong boost towards having an accepted consumer standard for single sign-on. What's even more interesting is the rather innocent comment thrown in at the end of the above reference: "Microsoft plans to support OpenID in future Identity server products." If that is the case then I wonder whether they will follow the model of being a federated identity provider on behalf of large corporate enterprises. Once you get over the shock of actually thinking such a thing it's not something too far outside the scope of imagination and could help facilitate identity management for organisations too time\cash strapped to set up their own infrastructure. I'm getting ahead of myself - let's get back to the now!

What, exactly, is OpenID? From OpenID.net, we learn that it is "is an open, decentralized, free framework for user-centric digital identity." In fact, it's not all "open" - the open source elements as originally presented, comprised about a third of the overall code-base. I think I'm correct in stating that the model as it was originally being presented by Verisign, was that for the full industry strength security model, customers would need to buy into the Verisign closed-source OpenID based product. That is my recollection from a meeting I attended a while back - but please correct me if I'm wrong!

The benefits from a customer perspective are better protection against Phishing and the ability to manage as many different profiles as they wish within the same identity framework. There's some interesting comment on this blog here: http://kveton.com/blog/2007/02/06/cardspace-openid-working-together/, and here: http://daveman692.livejournal.com/292084.html.

What about from a business benefits perspective - can we get any benefit right now from OpenID from an enterprise identity management perspective? I think the truthful answer to this is no and right now it seems to be squarely aimed at the customer web product side of things. But I'll be watching the news with interest, particularly as to how Microsoft might work this into their own identity server products. That'll be interesting.

Somebody asked me if I'd put a bit more detail around some of the high level topics I cover in this blog. So I thought I'd talk a bit about the risk assessment processes that I follow.

There are a variety of ways of assessing risk. Most basic is an assessment made based on our own thoughts and opinions about the likelihood of something happening. So, for example, we can put our finger in the air and state "I think there's a high risk associated with a zero day malware attack." This sort of assessment is not very useful because it's based on a single viewpoint with no consideration to scenarios around the risk, causes of the problem, susceptibility to the attack, or the costs involved. At the other end of the scale are the mathematical and statistical based methods used by the likes of financial institutions when working with various types of investment.

What we need is a method of assessing risk, that supports information security as a quick and easy tool for helping us to make decisions, and provides some level of assurance better than the finger-in-the-air method. Read on...

Today in the news we see another example of a government department playing rough-shod over private data. You'll recall that last week we had the story about smart-cards being shared. Today we're informed of the "bank and personal details of thousands of pensioners being sent to the wrong addresses." Read the full story here.

I loved the comment from the spokeswoman of the Department of Work and Pensions (DWP). She says she wanted "to reassure the department's customers that all the letters would be traced, and no more letters would be sent out until the problem was sorted out. " Well, that's ok then, no need to panic. Let's all be British about this and accept that sometimes mistakes are made but be assured that your good ol' government is doing its utmost.

So, what is the problem? It will doubtless be blamed on a "computer error" - in fact I predict that within three days of this blog such explanation will be in the press. I wont believe it. There has been a break-down in process and management to allow these letters to go out incorrectly addressed.

Unfortunately, unlike if a private organisation made this sort of mistake, the pensioners affected cannot take their business elsewhere and have no option but to accept the fate of their private data.

One last quick point, let's keep in mind that there is a plan to combine the databases of the DWP, the Identity and Passport Service (IPS) and the Immigration and Nationality Directorate (IND) to facilitate the National Identity Register. There is some blog comment about this initiative here: http://www.no2id.net/news/newsblog/?p=520. This makes me very nervous indeed because if there is an inability to manage something as simple as posting account statements posted from the DWP then that does not leave much confidence in the ability to manage MY personal data when three giant databases each designed for three seperate purposes are combined.

I'm off on various travels again over the next week so blog entries may become infrequent. However, do check back often.

Sometimes the simplest things can make a difference. I was speaking to a group of Dutch product managers a few days ago, walking through a risk assessment process. The most important parts of the process are marked in green, as they have been for the past five years or so. One of those present exclaimed "but we think that if it's in green then it's not so important. If it's important then I would expect it to be in red." The penny drops!

I've spent a fair amount of time over the past year or so looking at threat modelling as it applies to the product space. Threat modelling is a time consuming process but it's an invaluable tool in helping us to manage risk and understand threats that are relevant to a specific system.

The best resource on offer is that provided by Microsoft here: http://msdn2.microsoft.com/en-us/security/aa570411.aspx. In particular I recommend the book ("Threat Modeling" by Frank Swiderski and Window Snyder) and the associated free software. I could happily sit here and discuss how to do threat modelling and the value of doing so for hours but you can read about that in detail at the above mentioned resource. Instead I want to draw your attention to a quote that caught my eye when I first opened aforementioned book: "Ownership helps drive security processes so that the quality of applications can be improved."

The comment left on my previous entry led me to an excellent blog at http://www.emergentchaos.com/.

One of the contributors to that blog, Arthur, makes an interesting and very true point: "security is 90% about marketing and sales and 10% about technology." I've made similar comments throughout this blog that managing risk is very much about dealing with perceptions and being able to communicate the right messages.

One of the ways I've been doing this recently is to present a list of risks to product owners and ask them the questions "how concerned are you about each of these risks?", "how well do you think you are doing in mitigating them?" This approach has led to a number of very frank and revealing discussions where not only have my audience learnt something but I've become more aware of what the business concerns are and taken feedback on how to better communicate security issues to a non-technical audience.

In fact, I'm working today on various related follow up processes: in particular making sure that all of the right resources are easily available and that communication of how to get to them and use them is clearly stated. I'm sure that this will be a continuing theme.

About 10 years ago I began a short contract working as a programmer for a bank. On beginning the role, my very first task was to read the programming standards manual. This was a custom written 400 page folder describing every allowable way of writing code such as how to lay out loops and variable naming conventions. Not a single line of code went into production without it being peer reviewed against those standards. So, was the product secure? You bet it was. Strict adherence to documented standards might be frustrating but it gets results.

Such adherence to procedure is something I all too rarely encounter and finding the right compromise between procedure and business requirements to deliver fast is an ongoing challenge. I'm told over and over again that security is considered an expensive and often unnecessary overhead however, a few days ago the people giving me that message were the very same whose product had been found to contain vulnerabilities and potentially be at risk.

What frustrates me most is when software or network "engineers" inform me that they don't have the time to work within the bounds of a formal process. Sorry guys but that's just not systems engineering. I looked up a few academic definitions of Systems Engineering and settled on this one from the Open University.

Systems engineering is a set of principles, methods and techniques applied to all the tasks involved in all the life cycle stages of a complex system.

If you are working within a complex and risky environment then you cannot have an expectation that security is something that has zero cost and time attached to it. Refer back to David Lacey's blog entry about the importance of including security within the SDLC. It's not just a suggestion, it's vital and if you're not doing it then I know, sitting here now, that you have security problems.

Sitting next to me on the train yesterday was an employee of a large telecoms company. I know this from the ID badge he was wearing and the asset tag on his laptop. On the lid of his laptop was a yellow post-it on which was scribbled his userid and password. Yes - it really does happen!

Ironically I know that the telecoms company in question runs a very comprehensive and not inexpensive employee security awareness program.

What value a security awareness program? The Security Company make a case of the "critical importance of engaging...personnel in security on a daily basis." and their MD, Martin Smith states "The criminal will always take the simplest route to the riches." That route is likely to be through a lack of awareness of simple security measures such as not writing your password down on a piece of paper so that it can be read by the person sitting on the next train seat!

There's an interesting article in the latest edition of Computers & Security Journal entitled "Information Lifecycle Security Risk Assessment: A tool for closing security gaps" by Ray Bernard. The article discusses aspects of protecting data that you might not consider as typically falling within the bounds of your information security strategy. For example:

For over a year the largest sales branch of a national company experienced a level of sales competition unheard of in any other sales office, resulting in the lowest sales closing average in the company's history. Personnel from a competing company were sneaking up to the sales team's conference room window at night, and peering through tiny slots in the window blinds to copy the daily list of hottest sales prospects from the white board--including products and anticipated sales amounts.

Christiansen's IT Law blog suggests "Lawyers should play an active role at all levels of the information security risk assessment process, from defining the scope of the assessment and determining the legal effects of policies and procedures under assessment, through interpretation of the legal implications of an assessment to advise the officers who must decide what it means to the organization." Another approach could be to use a standard such as ISO27001 to help set the boundaries.

Within my organisation we're now designing different processes depending upon the type of vendor being assessed: so a vendor performing data hosting services will need to answer a different set of questions from a vendor providing software development. So the scope of information security is expanding all the time with boundaries well outside of the organisation.It means that our approach to security has to be flexible and able to adapt to a changing environment.

I've been reading a good, common-sense, article entitled "Compliance Optimization: Defining The Right Level Of Control" written by Michael Rasmussen and published by Forrester. Michael states that we should take "a risk-based approach to compliance and control management." I concur - the point being that we might have a tendency to be seen to be ticking all the right boxes against the compliance checklists without really understanding the implications or the risks that need to be addressed.

Michael goes on to state: "Defining your control environment around just-add-water best practices is exactly what we are trying to overcome." Here's an example: let's say we identitfy gaps in change control processes that prevent compliance with a particular new piece of legislation and decide to address the gap by purchasing some new software. That's fine, we are now compliant! This however, is wrong. Why did we have gaps in the first place? Do we understand the implications of those gaps and where and why we were exposing ourselves to risk as a result? Unless we can answer those questions then we might be ticking the right compliance box but we are not delivering security to our stakeholders.

Forrester have a security and risk management blog here: http://blogs.forrester.com/srm/.

There's another interesting one here from Mcafee: http://siblog.mcafee.com/?cat=15

Today I've been trying to participate in a meeting where everyone except me is sitting in a building in Orlando. Unfortunately, for various reasons I wasn't able to travel over this week so it's a case of straining to join in the discussion in the right place over the telephone and make the right contribution when I can't see the body language of the people I'm talking to.

On the positive side it means I can relax and sip decent tea during proceedings instead of being sat in an air-conditioned tank with a flask of that dark tepid liquid the Americans call coffee.

The subject of risk acceptance was one of the items under discussion, in particular the authority to sign-off on product related risk. Here's my view: it's a business decision every time. The role of Information Security should be to advise and be able to provide consultation on risk and how much of it there is, but it's the key business stakeholders who must make the decisions. They hold the budget, have intimate knowledge of their own strategy, and on how much risk they are prepared to accept. This is why it's so essential that security practitioners are able to communicate with the right people outside of their own domain and be regarded within the organisation as experts who provide guidance rather than a block and hand-brake on important revenue generating project work.

However, there does need to be somebody at a senior enough level who can say "stop - enough's enough" and ensure that a pragmatic and sensible approach is being taken by the business and that risks are not just being accepted when reasonable, cost effective mitigating controls can be implemented.

Here's an example of what I mean. Let's say we run through a risk assessment and identify that a particular security requirement has not been implemented as per policy. For arguements sake we'll say that business unit policy requires URL blocking to be enforced for web sites deemed harmful or offensive but in this instance no such control has been implemented. So, let's now complete a risk assessment identifying the scenarios associated with this particular deviation from policy (e.g. user visits site containing malware and infects his PC/network etc). Assuming we have desktop anti-malware controls in place we might assess the risk here of being low\medium (depending on the type of business, number of employees and so on). We document the scenario, and the resulting risks, then identify any mitigating controls (e.g. perhaps some limited blocking can be implemented at the firewall level, or maybe block access altogether). Armed with the right information, the business stakeholders can now make an informed decision.

That doesn't mean they will make the right decision. And I do believe that InfoSec should also be able to argue strongly in favour of doing the right thing when the business wont. But here's a tip - choose your battles carefully and don't overstate minor risks. It also means that InfoSec should be familiar with the business strategy and the key business drivers so that guidance isn't provided from an ivory tower.

Interesting related blog entry from Bruce Scheier here - Bruce is one of the foremost experts on risk and always makes for interesting reading.

While I've spent a lot of time describing certain aspects of my work within information security, something I've not really touched upon is how the program originated, and the question of where and how it was decided what shape the information security plan that I work to will take.

The best place to start is to know your place. InfoSec is a business support function - that means it's a service to the organisation and not the group providing strategic business guidance. I say that a bit tongue in cheek: that's because I've met, and worked with, many individuals within IT in general who are ever ready to stick their necks out and provide direction to the business. Here's my advice: don't do it. Unless you are intimately familiar with the CEO and having a chat over the breakfast table, then it's more likely that your role is to provide value within the role you've been employed. I still remember the look of thunder on a project managers face a few years ago when, within a meeting that also involved a client, I suddenly had an uninvited "great idea" relating to a product. She was furious, I embarrassed her, cast doubt into the mind of the client, and I learnt a lesson the hard way: focus on your own job and not somebody elses.

So, advice aside, the information security program that I'm working within is
based on the strategy of the organisation. That is very much the start point - using that as the template we've developed (and documented) a bullet pointed security strategy. You don't need a lengthy, wordy, technically detailed document: what's required is a high level list of of strategy aims and objectives. Unfortunately I can't tell you what needs to be in your strategy but there are many resources that try to tell you. For example, this one here is typical: http://www.isect.com/html/strategy.html. It details a 6 point plan but I don't like it because step one is "Implement baseline controls." I'm not sure that step one of any strategy should state "implement" and step 3 is about preparing a business case. There should certainly be a business case prepared around individual controls however, the strategy document is not the place for such detail.

This is a subject pretty close to my heart: I've worked on information strategy, taken advice from strategists on how to prepare a strategy document, and it's something I'm likely to be doing again in the near future. So, here's my plan

1 - Understand the organisations strategy: where are the risks, what is the business investing a lot of money in?

2 - Split information security into a number of programs: a number of individual programs come immediately to mind that probably apply to most businesses: infrastructure, product, desktop etc

3 - Describe high level, achievable, objectives within each of the programs and a short narrative on how they are going to be achieved.

That's it! I realize I've diluted an extremely important task into a few lines of text however, let's be clear: we don't need to have a long detailed explanation of every step of the plan. What we need to have is a lucidly documented, understandable strategy that provides a foundation for your work. Each program can then generate a further strategy of its' own and so on (e.g. a desktop security strategy, a network security strategy based on the top level).

Let me know if this makes sense.

A few short days ago I asked the question "Do the anti-malware controls built into Windows Vista mean that we can begin to think about reducing the amount we spend on third party desktop AV products?" A new report comparing a number of AV products seems to have answered that question for us. Read it here: http://www.av-comparatives.org/seiten/ergebnisse/report13.pdf. The report places Microsoft's OneCare desktop anti-virus product in last place for each of the tests performed, and on the surface appears to be a negative testimony to Microsoft's ability within this area. There's been plenty of commentary already reported such as this article here in Computer World.

Personally I think we need to review this report with some caution. There is no detail as to what configurations or settings were used to perform the evaluation and neither do we get much insight into the test methodology used. On the other hand, OneCare has already passed the ICSA labs certification tests - you can find the evidence of this in the July report link from here.

Conversely, at around the same time as ICSA were performing their lab tests, another report was released by Agnitum. This one is pretty damning, stating as it does that "OneCare firewall failed all but the simplest leak tests and does not offer even the most basic intrusion detection capability, leaving users' PCs wide open to being hijacked into a botnet."

So, what's the real story? I generally put a fair amount of faith in the ICSA lab tests - they are an accepted, reputable standard while other reports, on the surface, appear subjective. For instance, Agnitum discuss weaknesses in the product but then go on to talk about industry reactions to Microsoft's entry into the desktop security marketplace. Their report is also high level, making no mention of how it was installed, the configurations used, or the system it was installed onto.

Fact of the matter is that Microsoft have stuck their wealthy necks out into a market place dominated by aggressively pitched products and are likely to take a fair proportion of the market share aware from the established vendors in this field. That's not a bad thing - competition is good for the consumer and we might start to see some innovation within, what I think, has become a rather staid and predictable field of security.

Enough said?

I was reading the Ponemon Institute Survey on Identity Compliance. You can download it here.

The report focuses on identity management (IdM) across different sized organisations (i.e. enterprise IdM as opposed to customer IdM), eventually concluding

Despite the perceived importance of identity compliance, our results show that a large percentage of respondents believe their companies are not equipped to secure provisioning and access rights management using current methods. Moreover, our study finds that respondents find it difficult to collaborate across different functional areas across the enterprise.

This same point is supported within the report where the survey found only 10% of respondents citing cost savings as their principle business driver. From my perspective, the most revealing statistic being reported is that 65% of respondents report little or no collaboration between IT, audit functions, and the business towards achieving project objectives. This is a recipe for disaster because it means that the interests of all the stakeholders (and when it comes to IdM the entire organisation should be considered as stakeholders) are not being taken into account. The result is likely to be a solution lacking in required features and subsequently lacking support from within various parts of the business.

Here's an example of what I mean: some time ago I was notified about the impending implementation of a new IdM solution. Note: impending implementation. Few outside of the project group involved had been given the opportunity to contribute requirements and the result was a solution lacking some key security features. For example, corporate policy called for two factor authentication for remote access however, the IdM solution had been implemented with an Internet front end that only asked for a username and password. The project was subsequently shelved (not just because of the lack of 2FA I hasten to add) and some tough lessons learnt.

My last comment is the report finding that the element of an identity management solution considered most important by the most number of respondents (39%) is the "ability to track temporary or contract workers who have access to sensitive or confidential data". Really? I'm not denying that this is important - sometimes vitally so - but is it the most important purpose of your enterprise IdM project? Conversely, only 13% cited provisioning and de-provisioning as the most important element. I think these facts should - need - to be the other way around. If you can't focus on provisioning then you're not going to be able to track contractors.

A couple of good blogs that focus on identity management issues:

Kim Cameron's Identity Weblog
Digital Identity Blog

Anyone who has had the pleasure of participating in one of my presentations on information security over the past few years will know I have a favorite picture I like to show. It's of a padlocked gate I photographed whilst out driving through the Texan countryside. Nothing too unusual about a padlocked gate except that this one has no fewer that a dozen padlocks arranged around the central bolt. I took the picture for two reasons: firstly, because I was trying out a new camera at the time and thought that it would make for an interesting shot, and secondly because it's a great lead into a discussion on security controls. More specifically: about having the right number and combination of controls to be effective.

In the case of the padlocked gate, the number of padlocks certainly made for a gate that was harder to force open. In order to do so, our lock-picker would need to pick and break all of the locks. However, if the same tool could be used to break all of them then having 12 locks turns out not to be much more effective than only having one. Even worse though, what if we could just climb over the gate? Suddenly it appears that the security controls are actually in the wrong place completely.

In order to understand which controls are effective we need to understand the nature of the risks and the associated threats that result in the bad outcomes. So, in this case the risk is of an unauthorised access through the gate, and the threats might be listed as a) a person walking through the gate, b) a person climbing over the gate, and perhaps even c) person flying over the gate etc etc. With the threats listed out we can determine how effective the controls we have are at mitigating the risk. Clearly a) mitigates the threat of someone walking through the gate to some degree but doesn't mitigate b) or c).

There are a number of methodologies you can choose from to accomplish your risk assessment. Most of them are far too complex and time consuming for your day-to-day business focused use. A good new resource is this one here at http://www.ism-community.org/ and in particular a documented practical risk metholodogy.

The most important thing of all is understanding your own environment and acknowledging the risks as they apply to your own specific case. It's no five minute job but it doesn't need to be overly complex and time consuming either. Just take a pragmatic approach and work out what is good enough.

Steve Gold's excellent blog at http://securityblog.itproportal.com/ makes mention of the 12 month prison sentence handed out to one of the chaps who hacked into the LexisNexis Accurint database. I concur with the views of Graham Cluley of Sophos who says "The U.S. authorities must be congratulated for another big computer hacking arrest, which will hopefully deter others from following in the footsteps of Perras, who's going nowhere fast for the next few years.."

I do like a happy ending. I also like the outcome of the Shawn Carpenter case. Read all about it here: http://www.time.com/time/magazine/article/0,9171,1098906-1,00.html. The story describes Shawn as a tenacious investigator but he fell foul of confidentiality policies governing with whom he should have been sharing his data with. The fact he has now been compensated for the way he was treated demonstrates that the courts - at least in the USA -are waking up to the difference between criminals who deliberately go out of their way to steal data and those who have a genuine desire to do good but end up being perceived as criminals in doing so.

Here in the UK too, the recent amendments to the Computer Misuse Act are supposed to make it easier to obtain prosecutions although, as noted here, some opions are that the Act still doesn't go far enough. A recent article in the Computer & Law Security Report Journal from John Worthy and Martin Fanning entitled "Denial of Service:Plugging the legal loopholes" was also rather scathing, noting that "Questions remain about the clarity and enforceability of the changes (to the Computer Misuse Act)." The article goes on to give, in my opinion, the best advice of all that we "should continue to adopt a prudent technical and commercial approach to..network architecture (including the use (and regular review) of leading security and anti-intrusion technologies)." That's really the crux of the matter: we want to make the potential return on attack too low for it to be worthwhile an attacker expending time bashing away at our networks, and we want to have the right controls in place to protect data when they do.

Get Safe Online is a British Government sponsored Internet safety guide. It's all good common sense advice and well worth a visit. I wonder how many people do because, as I noted a few days ago "out of 15 million online banking customers it is claimed that less than half "regularly update their anti-virus software, with only 1 in 10 people having anti-spam software installed and about a third having a firewall." That's bad news, and espcially bad when we have individuals with such a flippant regard for computer security working on our networks.

Many organisations these days invest a good deal of time, money and resource on employee security awareness. A nice industry has grown up around teaching otherwise intelligent individuals the importance of common sense. For example, I've just read some guidance that says "Please change your password regularly. " PLEASE?! Maybe if they throw in a free gift they might make the new passwords strong too. As the old saying goes about leading horses to water, you can provide all the best guidance in the world but you can't ensure that anyone is going to read it or take notice of what it says.

Another policy I read says "you should not install any software with first obtaining permission." Not on my network thanks - I want a policy that says "you MUST not" and I want locked down desktops that prevent such a thing happening anyway. But, here's an important point, I also want to tell people why and put some context around the instruction and we also need some flexibility for those instances when somebody really does need to install something.

I'm not ashamed to admit that my first attempts at working on a security awareness campaign failed because I severely underestimated the importance of providing good advice and knowledge to people over and above just providing a set of instructions - I also underestimated the time and cost and the depth of the resources that would be required. I've since learnt that security awareness campaigns need to be focused on specific themes that are continually reinforced over a set period of time. Campaigns also need the buy-in of many other individuals within the business because you're going to need to get the messages communicated and translated into different media: HR, Corporate Comms, Legal, Intranet etc and the list goes on.

Anyway, here's a couple of decent places to look for more guidance on the subject:

- Security Awareness for Ma, Pa and the Corporate Clueless
- Get Safe Online
- The Security Company: Organisers of the Security Awareness Special Interest Group

In his blog entry, "The Importance of Closing the Loop", David Lacey talks about the importance of verifying that policies and standards are being followed and raises the topic of ISO certification.

I am in complete agreement but would go so far as to say that even if you are not considering actual certification then the exercise of working through the standards and performing your own gap analysis can be very useful in itself.

Some useful information and guidance on this blog here: http://systemexperts.blogspot.com/2006/08/iso-2700x-cornerstone-of-security-by.html and I'll discuss ISO 27001 in particular in later blog entries

A timely reminder here that security breaches are not necessarily "just a problem of big name concerns."

Yet another tale about a stolen laptop containing private data. Read all about it here: http://www.theregister.co.uk/2007/03/28/hospital_laptop_theft/.

The healthcare authority concerned say they are "very very sorry" (http://news.bbc.co.uk/1/hi/england/nottinghamshire/6498067.stm). I'm sure they are. Here's a quick fix: for £3.95 you can buy a simple lock. Probably wont deter a targeted crime but should put off the opportunist thief.

My question is: why on earth wasn't the private data stored on that laptop encrypted? Data security is a fundamental - we need to know the value and location of our most valuable data assets and ensure that they are given proper protection. And it's not as if we're not warned because every week there's another article about another hapless organisation bleeding data through it's own carelessness.

Here's some further reading for you:

Article on security awareness from SC Magazine: http://scmagazine.com/us/news/article/634722/train-employees-best-defense-security-awareness/

A blog talking about security awareness with an interesting response: http://www.computerworld.com/blogs/node/4175

Information about the Security Awareness Special Interest Group (SASIG): http://www.thesecurityco.com/kzscripts/default.asp?cid=13

Very useful article about application level logging here on SecurityFocus: http://www.securityfocus.com/infocus/1888/1. In my experience this is an oft forgotten aspect of product security, usually implemented as an afterthought or in response to an audit where the missing functionality will have been noted. Note that this is equally as important for enterprise (i.e inhouse) products as it is for customer facing.

I've been following the story of Gary McKinnon, the chap who is facing extradition to the States as a result of his hacking into a US government computer system on the hunt for UFO evidence. I'm not sympathetic, his was a targeted attack against a restricted system however, if the story is to be believed there was no malicious intent and no motivation to steal for profit. Politics aside (and if you want the political side then browse on over to the Free Gary McKinnon blog) there seems to be a good deal of effort on the American side to see that justice is done and an example set for others who might have similar ideas, but one can't help wondering if Mr McKinnon simply represents an easy target to use as that example.

This story is hot on the tail of another about the number of British businesses that actually report security breaches. Apparently only a third do so and I was wondering where you draw the line between identifying suspicious entries in the logs and responding by making a report of a crime. Tony Neate, whom I know and respect, makes the point that "In order to be effective we need to know what the scale of the problem is, this can only be measured if we report incidents when they occur." Fair enough but I was chatting some time ago to the manager of a web hosting facility for a large and well known portal who was talking me through how much they spend on anti-DDoS measures as a result of being under almost continuous attack. Should each and every source IP be investigated? Chances are most would lead to some zombie'd home PC anyway.

So, should we only report incidents that result in some financial or data loss? Data disclosure laws in the USA make such reporting mandatory in many cases while in the UK there is no such obligation. Should there be? There's an interesting blog entry here where it's stated:

There is a new legal and moral norm emerging: breaches should be disclosed....The reason that breaches are so important is that they provide us with an objective and hard to manipulate data set which we can use to look at the world.

One pearl of wisdom I particularly like is "never say no, put a price on yes." I apply this a lot in my work because, IMHO, the very worst thing a security manager can do is refuse to sign-off on a request without communicating the risks, advocating alternatives, or stating what can be done to mitigate risks associated with the request down to an acceptable level.

We shouldn't be slaves to policy - the landscape is changing fast and current business requirements are often outside what was originally considered when some of those dusty old policy documents were first conceived. As we seek to become more dynamic and take advantage of social networking, virtual worlds, VoIP services etc while also trying to make some sense out of where all our business identities are, we need to bring our ideas about risk management up to date and make sure that we are being pragmatic, doing our research, and above all, effectively communicating risk. That should include revisiting policy and putting a price on saying "yes" through following process based risk assessment and mitigation procedures.

I try to get around some of the challenges by advocating a risk-profile based approach to policy: i.e. there is a minimum baseline standard that applies across the board with an increase in the time, effort, and cost associated with controls as the risk profile increases. The challenge comes in assigning the right profile. I generally take a simple formula as follows:

risk profile = revenue * importance * data loss impact potential

It's not perfect science and there is a degree of subjectivity in the assessment but it's good enough. Remember, the most important thing is to reduce and manage risk: we can't eliminate it.

Let me know if you agree or disagree.

Someone recently posed the following question: Given the constant stream of news regarding attacks against government, banking, and other computer systems, and the depency on Internet connectivity, are we putting too much faith in vulnerable technology?

There's nothing new about trying to hack into electronic systems. Way back in 1972, John T Draper was the first hacker to be convicted of wire fraud. Read his biography here. In the late 70's we had the first online bulletin boards where passwords and credit card numbers could be traded, and in 1983 we had the movie "War Games" where the young hacker used his modem and PC to play "Global Thermonuclear War" with the government computer. The point I'm heading towards is that any time we've connected electronic systems up to be accessed externally, there have always been individuals willing to try to exploit them.

And systems are not becoming any more secure. We could argue that they are because we're devoting more time, effort and resource to making them so. But there are around 50 million lines of code in Windows Vista alone. Add to that all the other systems and their code that we expose to the Internet and the sheer implausibility of thinking that there aren't any security vulnerabilities to be exploited for fun and profit becomes obvious.

I'm in the process of putting together some useful security metrics to report up to the senior management of my organisation. This is one area of the industry that, in my opinion, is sorely lacking in good, detailed guidance, on what to report and how to report it.

One of the better references I've used to help me is a paper entitled "Top 10 Tangible Measures for Effective Information Risk Management" by David Lacey. David makes the point that "Identifying appropriate metrics ideally requires a consideration of the organization’s business goals, strategies and compliance requirements, and the measures that could be used to prioritize activities and help prevent incidents." The message is that the right metrics are unique to a business and the paper offers some some good advice on how to get inspiration for what to report within your own.

According to the latest research from Forrester "the majority of security metrics programs are still in their infancy or planning phases." One of the more useful points of guidance I liked from a paper entitled "Defining An Effective Security Metrics Program" by Khalid Kark and Paul Stamp (published May 2007) is this: "You can measure the time it takes to implement a particular patch to a critical system. This information by itself will not help you analyze anything. Alternatively, if you measure the mean time it takes to patch all critical systems in your environment and then trend this information over time, the results can be used for analysis to determine whether your patch management processes are getting more efficient." The same paper goes on to define seven steps to a successful metrics program. They make it sound simple, like the seven steps to buttering a slice of toast - however, getting past step one "Make measurements and metrics a key part of your security program" (and not, "remove lid from butter") can be a challenge on its own, requiring you to develop a security measurement capability.

I also liked the words of wisdom on the subject from Bruce Schneier. He makes the point that "getting attention (and budget) from top executives such as risk managers, CFOs, and CEOs, means creating metrics that help measure the value of the security effort." I agree and that's why my own metrics program will be focusing on those systems that directly link to business strategy.

Lastly for now, for those of you working on application security, OWASP have an Application Security Metrics project underway and currently in its early stages.

More on this subject to come...

Why should we go to the trouble, time, and effort of producing an information security risk model? What value does it bring to the organisation and who is going to use it?

These are questions I've been asked in the past few days and if they are being asked of me then it's likely they are being asked of you too, or you are asking them yourselves.

I have an opinion on the matter than can be summed up in a few short words: Risk assessment is central to improving information security effectiveness and efficiency. Gartner say "A formalized risk management process will enable you to determine specific threats, impacts and vulnerabilities and to identify the appropriate corrective action."

The value of having a risk model and a risk management program comes at the business unit level. The model provides a framework for identifying controls (which should be measurable, testable, auditable and enforceable) , monitoring for exposure to risk and control effectiveness, and incident management.

The fact that a risk model is constructed around negative themes - the bad things that can happen - does little to further our cause when trying to explain the value of the exercise to executives who are likely to perceive the messages as being counter-productive.

What is true is that if we can begin by identifying a valid set of risks that clearly relate to business objectives, we can assign cost and reputation impacts to various scenarios that apply to each. We now have something that management can directly relate to - the bottom line impact on the business. We also have a basis for asking questions around what controls are in place to mitigate the risks that we've identified and how effective we believe those controls to be.

The book "Information Security Risk Analysis" by Thomas Peltier (ISBN: 0-8493-0880-1) makes the point "with an effective risk analysis process in place, only those controls and safeguards that are actually needed will be implemented." The benefits come because it forces us to focus on the issues that are really important, spending money where we most need to spend it.

The real value will come in how we can present the risk model and associated risk assessments to management. For example, it would undoubtably be shocking for them to see that denial of service is the biggest risk but that the controls to mitigate this risk have not been implemented, or to show that the business is not fully in compliance with relevant legislation.

Some might argue that compliance (with the likes of PCI and SOX) simply requires the business to follow a check list and work through a series of action items until all the right boxes have been ticked and so going to trouble of creating a risk model is simply going to be stating the obvious. There's a blog entitled "Practical Risk Management" which makes the following statement: "If you want to check boxes, surface audits are fine. But if you want to understand your true security exposure, you have to dig deeper. It's not enough to ask whether regular backups are taken and stored offsite. You have to ask how often....You have to dig deeper than the surface and get to where the substance lives if you want to get a real sense of things. After all, if you have to endure a security audit, it'd be nice to actually get some value out of it."

So, with that all said, I hope I've explained why we should be looking at risk models and why they are important.

Anyway, it's the weekend. If I write any more today the bad outcome that will apply is: "disgruntled wife" and the potential event costs are too much to contemplate!

I'm back from a good first day at the Gartner IT Security Summit being held in London. Two of the sessions I attended were particularly good.

Firstly, there was Richard Hunter of Gartner who presented on "IT Risk: Turning Business Threats Into Competitive Advantage." I've seen Richard present before and he's an excellent, eloquent, well prepared, and engaging speaker. In fact, I was so impressed I brought his book. The 4A Risk Management Framework that he describes and the importance placed on business continuity makes for informed reading and there's plenty that can be put into practice.

Secondly, there was a case study session on "The IT Risk Management Framework" from Toni Bekker of Finnish mobile operator TeliaSonera. Toni gave the audience an excellent insight into how he's gotten business engagement and support for information security programs within his organisation. The advice I particularly liked was about creating trust with senior business managers. "Say what you do - do what you say", and he went on to describe the importance of bringing risk into the open. "Reporting risk solicits help, not punishment" was the advice that was given.

The day began with a couple of interesting keynotes. First one from Joanna Rutkowska of InvisibleThings.org had some good content around our lack of ability to know what bad things are on our networks and the impact of "stupid users" as she put it. Joanna has her own blog here where she echoes much of what she spoke about today.

John Pescatore, who has the grand title of "VP Distinguished Analyst" spoke on the subject of "Security 3.0." Most interesting from my perspective was his assertion that data classification doesn't work. His advice is to use content-aware security and keep better track on where data is flowing. John also re-iterated one of the Gartner top 10 predictions for 2007: By the end of 2007, 75 percent of enterprises will be infected with undetected, financially motivated, targeted malware that evaded their traditional perimeter and host defenses. Good food for thought.

The down-side of spending a couple of days sitting through presentations from people offering enlightenment as to how you can be more effective in your job, is that you end up feeling like you've not been doing your job very well. Listening to Les Stevens of Gartner discuss "The Art of Policy Management" during todays Gartner IT Security Summit had me almost running back to the office so that I could quickly implement the framework he described. However, it would have been a long way to run so I stayed to the end and enjoyed his relating the challenges of implementing security policies to Sun Tzu's "The Art of War."

Les made a big point about achieving a conscensus within the business. I don't disagree with the guidance but I do often get frustrated with governance through democracy. I don't think it does the business many favours when it comes to security and personally believe that a more authoritative approach is needed. I challenged Les on that very point and he agreed, stating that if you are in an organisation where you can get away with an autocratic approach then that will certainly make it easier to push policies into operation.

Other presentations today were equally interesting. "Zen and the Art of International Data Protection Compliance" discussed the implications and constraints around moving personal data between the UK and the USA. Surprisingly it's a lot easier than you might think with a lot less risk than you might believe. I'll talk about this more in a latter blog.

In the meanwhile go to www.googlism.com and type in your company name (or your own name). You might find the results interesting!

Neath Port Talbot Council last week sacked a worker for using eBay during office hours. What an absolute waste of time and effort that whole process must have been. How many years have people spent filing their nails, gossiping, staring out of the window, smoking, drinking coffee and otherwise not working? Now, we have the Internet being put onto our desktops so we simply have more ways to be distracted from doing our jobs. You can't give somebody a toy to play with and then punish them for playing with it. If Neath Port Talbot Council don't want their staff to use the Internet then they should block access to it. More to the point, long before they get to the point of firing somebody for misuse, they should have given adequate warning that usage was being monitored and considered to be excessive.

My organisation has an acceptable use policy that allows the concept of reasonable personal use of the Internet. What constitutes reasonable use is open to interpretation, but how granular should we really need to get when we have a good organisational culture that trusts it's workforce? If an individual clearly isn't performing in their job because they are spending all their time on eBay then it's a issue for management resolution. If it gets to the point where somebody is being fired for it then that's a management failure to either identify a problem or deal with it effectively.

There's another point I'd also like to make. The tools we use for analysing Internet usage are often not very good at providing an accurate picture of what's really going on. Log onto Facebook and leave it open but minimised on your desktop for 4 hours whilst you go about your work and you'll see what I mean. A look at the usage logs will show hundreds of page views and give the impression that you've spent all morning chatting with online mates whilst you've have actually been hard at work.

My message to the Neath Port Talbot Council is to tighten your usage policy rules or block access altogether. In this instance you've failed to manage a situation that could easily have been remedied and lost trained staff that you now need to replace.

Somebody showed me a magazine article a few days ago about the "threat within" and ask me if I was concerned and considered it a risk for my own organisation.

It would be a foolish security manager who didn't consider the insider risk. I judge the risk here using two measures.

1. Using the common quoted risk = threat * vulnerability assessment where the threat is likely to be relative to factors such as the number of employees you have, the value of your data to an external organisation, and your staff turn-over. The vulnerability level should take into account factors such as the number of individuals with access rights to high value data or critical systems and the presence of controls such as fraud detection software and system audits. If controls are lacking then read this story on Information Week and consider the consequences if the malicious code planted by the employee had not been discovered.

A former systems administrator at Medco Health Solutions pleaded guilty in federal court Wednesday to writing and planting malicious code that could have crippled a network that maintains customer health care information.

A former IT worker for UBS has been found guilty of attempting to profit by unleashing a 'logic bomb' computer virus on the bank's network that caused more than $3 million in damage.

2. What is the "return on attack" that a disgruntled employee or - let's be plain - thief could get from stealing your data or bringing down a system? In other words, is the crime likely to be quickly detected, and what value does data have once it leaves the office and would the individual be able to profit from it? A paper I quoted from during some related research I performed some time ago makes the point that we must take into account the "difference between mitigating the effects of attacks and discouraging attackers by making their efforts no longer profitable." (from: Evaluating Information Security Investments from Attackers. Perspective: the Return-On-Attack (ROA), by Marco Cremonini and Patrizia Martini). In other words, if they think they will be caught then they are less likely to try to commit the crime in the first place.

There are a variety of things we can use to try to detect malicious or fraudulent activity on our networks:

1. Monitoring of database activity monitoring encompassing database transactions and privileged access.

2. Use of content monitoring and filtering to discover inappropriate use of content and data, although the ability to detect anything of interest will be limited to what can be discovered via simple data pattern rules.

3. Fraud detection software can discover and stop suspect user activity although only for the specific set of applications and business rules with which it interfaces.

4. Network behavior analysis tools can discover anomalous network traffic between applications and associate that traffic with a specific user.

Nothing is going to be 100% reliable and technical controls are only one element. Your organisational culture must also play a part as well as having in place authoritive policies and a documented process for what actions to take in the event that you do suspect an employee of malicious or fraudulent activity.

I really enjoyed reading the interview with Adrian Asher in the latest edition of SC Magazine. Adrian is global head of security for Betfair: a company with more than a million registered customers processing as many transactions each day as the London Stock Exchange. I think that's a security challenge most of us would like to get our teeth into.

Adrian mentions an impending ISO27001 audit and it started me off wondering if perhaps I'm guilty of neglecting this important standard. For those of you who are not familiar, ISO 27001 is regarded as the de-facto standard for establishing, maintaining, and improving an Information Security Management System (ISMS). Achieving certification against the standard is evidence of an organisation proving that they take information security seriously

I'm certainly not unfamiliar with the standard, having documented a gap analysis for my organisation a couple of years ago. What I wasn't able to do is build a convincing business case for proceeding with a project to achieve certification. At the time, being ISO27001 certified wasn't viewed as adding value to an organisation that already had in place many mature risk and information security management processes.

I now find myself wondering if this wasn't short-sighted. I've been re-reading the standard and also reading about how others have gone about their own program of certification and the benefits they achieved from it. The aforementioned Betfair, for instance, are reported as now being able to "demonstrate its commitment to the integrity of its information systems, assuring its customers of optimum security for personal details." The CEO of CHKS, a medical consultancy organisation, stated that "ISO 27001 has provided a rigorous standards framework against which we can be objectively measured. We are delighted to have achieved this internationally-recognised certification especially as the role of IT in corporate governance continues to expand". Monitor Media, a solutions development organisation who also achieved certification state "Though we've always taken the issues of information security extremely seriously, it was nevertheless appropriate to invite an external audit from a tough and respected body like the BSI."

There are many more examples I could quote from. In short, the message is that becoming ISO27001 certified is an indication, not only of taking security seriously, but also of following a good process of governance that can be recognised within the business and by customers too. Win win.

There are many other positive reinforcements of the message that certification is a good thing such as the blog posting here from Brian Honan. In fact there appear to be few, if any, down-sides other than managing ones resources sufficiently and making the time to commence a certification project.

So, I'll be thinking about ISO27001 over the coming months and looking for the opportunity within my own organisation. I'll let you know how it goes.

October is American National Cyber Security Awareness Month. There is a great new strap-line of "Protect Yourself Before You Connect Yourself." It's all good advice and well worth reading through.

In the UK, there is the government sponsored "Get Safe Online". This is a useful resource, so long as people know that it exists and where to find it, offering relevant guidance for the home PC user on everything from safety in Online Dating to information about how spyware works. I took the 5 minute personal risk assessment. My result was: "Your results are good. However, you may be able to improve your level of security in one or two areas by looking at the topics in the "Protect yourself" section of this site. "

Even better though on this site is the information for small businesses. The section of corporate identity theft is very timely although could be updated to discuss social networking based risks as well.

I've recently reminded my own organisation about the value I place in security awareness information for employees. It's cheap and it really does reduce risk. The Security Company make the point that

Employees represent the quickest ‘win’ in the battle to make an organisation’s information securely and appropriately available.

A security-aware workforce will provide:

- appropriate protection for all of an organisation’s assets in a cost-effective and efficient manner
- an environment where all staff members are committed to the protection of an organisation’s assets, particularly information in all its forms
- competitive advantage, improved customer service and an enhanced market image as a result of an organisation’s recognised commitment to security
- measurement and compliance techniques to ensure losses resulting from breaches of security can be identified and continue to be reduced over time

Generally the first line of defence, employees can quickly identify a potential breach or a weak link. Just as importantly, security-aware employees can prevent and lower the impacts of incidents when they do occur.

You need an eye-catching introduction, a memorable end-line and in between a list of points that must sound interesting despite the fact that though not all of them will be relevant to each reader.

Finally, something that recently occured to me is that there are two things that worry me most about a computer virus. First that my computer will be damaged and second, that my kid will be the one who invented it....
(For this and more very bad computer related humour, go to http://www.securitywizardry.com/cartoons.htm.)

I'm back from a new starters induction day. After six months in the company I was surprised to be invited along, but I'm glad I was. The day took the form of a team exercise where each team had to plan and organise a new, imaginary, exhibition (as is the nature of the business I work for) - going about the conceptualization, planning, marketing, and sales side of things. At the end of the day there was a presentation and the winning team won a prize.

From my perspective the day was extremely valuable. I got an insight into how the business works that I didn't previously have. This is very important for managing risk because if you don't know and understand the business then it's unlikely that your security plans are going to be in its best interests.

This is also particularly important when trying to articulate the value of security. One of the things we need to avoid doing is basing information security expenditure requests on undefendable financial projections. Instead we need to clearly articulate balanced value propositions and so must know the potential loss impacts we're dealing with and understand them in business terms.

So, a good lesson learnt today. And did my team win? Not quite.....but we had fun trying!

Back in my days of military service I used to enjoy reading a regular aircrew magazine feature entitled "There I was at 30,000 feet." It was shaggy dog stories of hard learnt lessons where process had fallen down and a pilot would find himself upside down with only one wing and the seat of his pants left for him to get home safely.

While most of my work in Information Security is ground based and non-lethal in it's outcome, I still find it important - no, essential - to follow a process. It's those times when the process breaks that security is usually also found to be broken. I've recently found myself following the Global Project Management Methodology (GPMM). I have to admit that this was imposed upon me when I commenced my job here and it's fair to say that I resisted. Slowly and surely my resistance has been worn down and I'm now finding it to be an essential part of managing the governance programme that I'm imposing on the business.

Clearly, any methodology could have been selected. Prince, for instance, would have been just as valid to use, I don't think that this is so important so long as some formal process is followed. One of the things that it does do is immediately provides me with a measurable metric that I can report against on a regular basis. Even if your security programme is not mature enough to report anything else, GPMM provides a way that you can measure your progress against milestones and indicate success (or not).

Using GPMM also forces me to set realistic timeframes and targets for my programme and estimate how much of my time can be assigned to achieving each of the milestones. With this level of detail documented, new and ad-hoc tasks can be more easily scheduled and management expectations of when they will be delivered managed.

There is a risk in becoming fixated on the plan to the detriment of action. It's also important to treat plans as a continual process of development. My governance, and consequently also my leadership and management are all benefiting from following a formally defined project management methodology. I recommend it.

There's a lot of discussion out in the blogs about security budgeting. Mike Rothman compares security budgeting to "black magic", while Gunnar Peterson discusses a more practical (for most) alignment of security budget with the IT budget.

I'm not sure that you could really prove that either approach is wrong or right. There are also lots of statistics to read about the percentage of the IT budget that is spent on security as if this is also a useful benchmark for us to gauge our own expentidure. John Pescatore, at the recent Gartner Security Summit, suggested "that the average organisation spends 5% of its IT budget on security" but that most have difficulty being able to justify why.

I usually talk about "cost effective controls" within my own organisation. This means implementing controls that meet the risks that are applicable to the business. If there is a high loss impact potential then the business must budget and spend accordingly. If there is low or no loss impact potential then spend less. The start point has to be a risk modelling exercise: identify the risks, evaluate the impacts.

The difficulty in applying ROI calculations to information security investment decisions is one cause of the difficulties we face in this area. I challenge you to prove on paper that the 20k you are about to spend on a new IPS device is really going to be worth the money in investment terms. What about if we consider the investment from another perspective and think about the attackers "return on attack." In other words, is is worthwhile for somebody to attempt to breach your security. Will they achieve financial gain from doing so, and are they likely to be caught? In my opinion, if the answers to those two questions are "yes" and "No" then you must buy the controls. If not then question why you really need to have the control or spend so much.

An interesting exercise once you have completed the risk model is to compare your existing expenditure across each of the categories of risk. You might be surprised to find, as I was, that those categories with the potential highest loss impact are not always the ones attracting the highest expenditure: sometimes the exact reverse. Somewhat less surprising is that technical controls are the ones usually considered to be most important to implement whilst people and process based controls - security awareness and training in particular - attract least investment even though they can have a big impact on mitigating risk. For example - spending 20k on training developers might mean you don't end up with vulnerabilities you'd otherwise need to spend 25k on for an application firewall (plus the FTE you'd need to manage it).

Bottom line in my book is that security priorities must shadow the business strategy. If you want to build a case for more money and controls then understand where your business wants to go.

The question of where Information Security should report into within the organisation has come up in discussion. There is little consistency within my industry contacts. One reports to the CIO, another to a CFO. In my own case I report to a Director of Corporate Governance. Who is the more right? Frankly, I'm not sure that it really matters so long as there is support at the right level for the organisation. There are lots of conflicting views online. Here are some of them:

The right place for information security management is where it belongs; enterprise risk management

If there is an internal audit group, I would say that this function should report wherever this group reports

If you define Information security that it should include data governance and compliance, the methodology I follow make it part of the Business Intelligence organization

Often the most sensible solid line report is to the CIO

I do believe that in many organisations, the infosec function is best positioned reporting directly to the CIO

I think that if Information Security reports into the CIO, Information Security be autonomous from IT Operations

What's in scope for Information Security? I discussed this topic earlier in the year (see my blog of Feb 22) where I asked the question "should information security just involve itself with electronic data assets or ALL data assets however they present themselves?"

The answer, at least as far as I'm concerned, is that information security governance has all data assets in scope. But that's too simple an answer because scope is still a matter for a good deal of debate and too often becomes entwined in politics with the "old school" on the one hand who silo security in with IT, and the "new school" who read CIO magazine from cover-to-cover and then turn to the Financial Times for a conflicting view and just end up confused about the whole thing. Of course, us security folk think we know best and frankly, that doesn't help.

In the news yesterday: A mystery impostor has posted false details about Miss England on a social networking site which she claims makes her sound "thick" and "tarty"....She said: "It is scary to think someone has stolen my ID."

MySpace, Facebook etc are going to be short lived phenomenom in their present forms. Personal and business ID fraud are already rife on the social networks and it wont be long before trust is completely gone. Until we come up with a reliable, simple, and standard way of proving identity there will continue to be beauty queen imposters and 45 year old men posing online as 15 year old girls.

I wrote on this very subject recently in Computer Weekly, stating that "a fundamental flaw of all social networks is the lack of identity validation. Anyone can pretend to be anyone." Is it really a flaw? How many of you can claim to have a unique name - and what can you really do to prove that an online identity was created by and belongs to you? There are plenty of other references to Stuart King online but few of them are me and can anyone prove which one is the real me? The politician, the carpenter, or the policeman? You can't even prove that it's really me writing this blog - authentication into the blog software only requires a password, and it would take a forensic analysis of my PC to prove that I really wrote this.

There's a catch 22 in that we want to share information, but in doing so we also give the information to people we wouldn't usually want to associate with. If you're in the pub and want to tell your friend a secret then you whisper in their ear. On the Internet, we can end up inadvertently publishing our secrets in a place to which 3 billion other people can potentially gain access. Ironically, there was another beauty queen who recently found this one out when "private" photographs that she uploaded to Facebook ended up in the public domain. Read all about it here: http://www.msnbc.msn.com/id/19666279/.

Corporate identity fraud is clearly within scope of an information security program (see my previous blog entry). Smallbusiness.co.uk remarks that corporate identity theft involves "stealing the identity of a company and fraudulently trading under that name without the knowledge of the legitimate company. The consequences can be catastrophic, particularly if the fraud goes undetected." The BBC reported on the risk a couple of years ago but I wonder how many businesses - except those affected - took much note? More to the point though is what controls are there that mitigate the risk?

Companies like Mark Monitor are one company offering a solution that provides "corporations intellectual property and trademark protection to quickly and easily combat brand abuse across the entire Internet, including Web sites, domain name registrations, search engines, major email systems, domain name systems, registries, message boards, and blogs." They seem to be one company in a very small pile and there surely must be scope for more to set up in this function. The only real alternative is for businesses to do the legwork for themselves and deal with the issues when they stumble upon them.

So, no good solutions for now, and as for Miss England, well, I don't believe for a minute that you're really "thick" or "tarty"... :-)

A plug for the interesting podcast on social networking from Maury Shenk, Head of European Legal Programme, SANS Institute. Presented by those good folk over at InfoSecurity Europe...

Download it from here: http://www.infosec.co.uk/page.cfm/link=351

I've been reading a report by the US Government Accountability Office (GAO) entitled "Data Breaches Are Frequent, but Evidence of Resulting Identity Theft Is Limited; However, the Full Extent Is Unknown."

It makes for interesting reading. Findings include that "in reviewing the 24 largest breaches reported in the media from January 2000 through June 2005, GAO found that 3 included evidence of resulting fraud on existing accounts and 1 included evidence of unauthorized creation of new accounts. For 18 of the breaches, no clear evidence had been uncovered linking them to identity theft; and for the remaining 2, there was not sufficient information to make a determination."

The paper discusses in detail breach notification requirements and makes the following claim

Breach notification requirements have several potential benefits, including creating incentives for entities to improve their data security practices (and thus prevent potential breaches from occurring), allowing affected consumers to take measures to prevent or mitigate identity theft, and serving to respect individuals’ basic right to know when their personal information is compromised.

The report goes on to list the data breach causes. These are:

• Hacking
  
• Employee theft
  
• Theft of physical equipment
  
• Deception or misrepresentation to obtain unauthorized data.
  
• Loss of laptop computers or other hardware.
  
• Loss of backup tapes.
  
• Unintentional exposure on the Internet.
  
• Improper disposal of data
  

Regardless of whether or not we operate in a legislative environment where notifications are required, we should be making best effort to protect customer data with an appropriate set of controls. The report concludes

The frequency of data breaches identified in this report suggests that a national breach notification requirement may be beneficial, in large part because of its role in further encouraging entities to improve their data security practices. However, because breaches vary in the risk they present, and because most breaches have not resulted in detected incidents of identity theft, a notification that is risk-based appears appropriate

As security professionals we must accept the fact that conflict is a normal part of our professional and personal lives. Far from being an unnatural phenomenon that must be either avoided at all costs or waged with the goal of absolute destruction, conflict can be beneficial. Those who manage conflict well obtain efficient victories; those who fail to manage conflict well exhaust their resources and are eventually defeated.

The book is impressive because, rather than being another technical know-all guide, it focuses on being effective through managing of relationships within the organisation. I particularly like the following:

Security managers and other leaders who wish to remain relevant and vital to the organizations they serve will keep asking and answering the fundamental questions.

1. What is really important to the organization?
2. How does my department support those priorities?
3. How do other departments support those priorities?
4. How do I personally support those priorities?
5. What are my personal priorities and do they match the overall goals
of the organization I serve?

However, more individuals are now on MSc courses that focus on security or gaining business skills via the MBA route. The profession is becoming professional. This book might just help you to understand what is motivating senior management and how, as a security professional, you can achieve credibility and add value at that level.

No-one would disagree that data is an asset. As such, it has value. It therefore follows that somebody must own it. I would state the responsbilities of a data owner as being:

1. Ensuring that data is correctly classified

2. Granting access to the data

3. Ensuring that the data is valid

4. Ensuring that individuals who need to process the data are correctly trained in doing so and understand their roles and responsbilities

5. Deciding on permissible uses of the data

6. Understanding risks associated with the data (and the consequences of the data being compromised)

A very wise man once said "Without measurable goals, how do you measure success?" It's a good point but one that many security professionals still struggle with.

We have measures of success for everything that we do. For instance, the measure of success for a meal might be that nobody contracts food poisoning, or the measure of success for a long haul flight is that there are an equal number of take-offs and landings. Back in my military days, one measure of success was the number of sandbags that could be pointlessly filled in half a day, whilst for the officers it was the number of brandy's they could pour down each others throats during an evening in the mess....Bitter? Me?

I've seen lots of information out on the web about metrics and KPI's for information security. Much of it is David Brent style management speak (e.g. spotted on one forum "Its my take that as security professionals, we need indicators that clearly demonstrate that our threat prevention investments work as expected. We should then be on the road capable of climbing the mountain of ROI" ) and the rest is well intended but doesn't actually say what to do. I'm not saying that I have the right answer but I thought it might help if I shared with a couple of the metrics that I intend to use. This might help you to get started on defining your own.

1. Progress against security project plans. I have my security program mapped outusing Microsoft Project. For instance, one milestone to attain over the course of the next few months is "Security of Third party vendors assessed." I've estimated the timeline for each of the sub-tasks involved with meeting the milestone. In the monthly report I can simply report on whether I'm on track or falling behind in my plans.

2. Security patch status. I have no intention of reporting the number of patches rolled out or the percentage of coverage. What I will do is take that information from each of our business units and use it to report up to my management that we are either good on desktop security status or not so good on desktop security status.

3. Business unit security status.This metric is based on the results of a standard, repeatable risk assessment questionnaire process that each business unit must update on a regular basis. The results make for a nice chart where senior management can easily see which of our business units have met all their security requirements and which are falling behind.

I wont bore you with the others but I think you get the message that the key performance indicators are intended to be relevant to the business. Problems and anomolies stand out and, overall, it's meaningful information that senior management can quickly digest.

Now, I'm not so arrogant to believe that I have the perfect solution but it works for my business. That's the most important thing of all. Understand what motivates and drives the business and let the metrics reflect and support the strategy.

It would be good to think that I spend all my time defining strategy, sending out edicts,and generally pontificating. Fact is more often than not I become embroiled in issues that are fairly mundane. However, let's not underestimate the importance - they might appear to be mundane but fact is that at the other side of the email or telephone call is a person trying to get a job done. An important point to make is that there is frequently more credibitility to be gained within the business by ensuring that the trivial tactical issues are dealt with than through defining grand new schemes.

Today there were a couple such issues. First up was an issue around the policy set for the length of time before an individual's BlackBerry device will automatically lock and thus requiring a password to be entered before it can be used. The policy is fairly strict and there have been complaints. I've relented to some degree and agreed that the time period can be extended by a modest amount. It appears that others of you have been dealing with a similar issue. For instance here on the BlackBerry forum where it seems individuals are setting policies ranging anywhere from 2 minutes to an hour.

We shouldn't become flippant about the risk. It's easy to shrug it off and presume that no-one would be interested in reading the emails or that we're protected because the devices can be remotely wiped. We should make no such presumptions. The fact is that if somebody can get hold of your BlackBerry, unlocked, then that person can, for all intents and purposes, become you.

I enjoy dealing with day to day issues such as this although the outcomes are not always positive from an end-user perspective - they can easily be left feeling that security is putting a block on their ability to work. What I try to do is ensure that the reasons for a particular policy are clearly communicated and if there is a good reason for preventing a particular action it's always good to have an alternative solution to present. Never say no, put a price on yes!

Some interesting statistics reported here in Computer Weekly relating to disastar recovery planning.

According to the research findings, 48% of organisations have had to execute their disaster recovery plans. Additionally, 44% of organisations without a disaster recovery plan experienced one problem or disaster, while 26% experience two or more, and 11% experienced three or more.

I thought it would be interesting to look more closely at the TCO (Total Cost of Ownership) and ROI (Return on Investment) associated with an IDS/IPS and see whether or not we can realistically make a judgement on the investment using these as metrics. If we can't do so then there's the possiblilty that any supposed benefits of an investment are likely to be speculative and probably marginal. In fact the UK Department of Trade and Industry have stated that “the main barriers (to the further use of information technology) are the lack of appropriate cost-benefit techniques.”

Interestingly enough, when discussing the purchase of a new IPS device a couple of days ago, TCO and ROI weren't considered. The decision was made based on an estimation of the risk and the supposed affinity of the control towards mitigating that risk. I wonder if a different decision would have been made if we'd looked more closely at the value of the investment in pure financial terms or whether it's even possible to do so.

McAfee think that it is. They have written a paper entitled Network Intrusion Prevention Systems Justification and ROI where they take a single case study and claim that for "any organization, the cost of (managing a malicious attack or virus outbreak) will far outweigh the cost of purchasing, implementing, and managing the IPS." The paper goes on to claim that for a $200k investment made in IPS, the company in question makes an annual saving of nearly $4million. I think such data is misleading at best, absolutely wrong at worst. There is no accounting of risks that are most likely to have a significant impact on the business in question, only some tenious reference to the "average cost of the Slammer virus." In claiming annual savings, McAfee are also not taking into account the future, and very dynamic, risk environment.

Of much more value is a study made by Charles Iheagwara back in 2004, in a paper entitled "The effect of intrusion detection management methods on the return on investment" (available in the May 2004 edition of Computers & Security Journal). Iheagwara states

To effectively analyze and calculate the IDS ROI, there is the need to have a sound understanding of the environment where the IDS is deployed including, at a minimum, the business practice, and network architecture and asset values.

a positive IDS ROI is attainable with an effective deployment technique and optimal management approach.

The question becomes one of whether or not any of this is going to figure in the decision whether or not to purchase the device. In my opinion financial analysis must be performed for information security related projects and that this analysis should be subjected to external review from non-IT personnel. Projects will gain a lot of credbility from being described in terms that demonstrate their value to the business. My own conclusion from a paper I wrote some time ago were that the best way to make a financial judgement in support of a particular security control is to use the following formula (from S.A.Purser S,A, "Improving the ROI of the security management process") :

Taking risk into account provides more relevant assessment of a security related project. It is this methodology that I would recommend to the business when making an assessment of the value of security projects

I wanted to follow on the same theme as my previous blog and look more at issues of justifying spending on information security.

One of the difficulties might come from whether your organisation thinks of security as a cost or as an investment. If it's a cost then the CIO will be looking for ways to cut it. If it's an investment then it needs to be managed. What I'd be interested in learning is how many information security leaders are able to influence that level of thinking within their organisations.

Of course, understanding the way that such matters are influenced is a good start, and having an understanding of how to evaluate technology investments would also be a help. I suppose that one of the problem we have in security is the difficulty in measuring the effectiveness of investments against operating costs and net revenue. Security technology can appear to be a dead weight with few individuals even understanding its purpose let alone the value that it's bringing to the business.

Perhaps it would be easier to justify if it wasn't such a dark art. I'm referring to a paper published by one Dr John Leach entitled "Security & Engineering ROI" (apologies for not being able to find a reference for this one). Dr Leach states that we "should treat (information security) as an engineering discipline and reset our expectations about how security systems should be designed and evaluated" before going on to conclude that

Security ROI is just another way for the business to ask us to stop pretending that IT Security is a special type of magic practiced by a chosen few and to start asking security designers to behave like the security engineers they should be.

I don't think I'm too wrong in stating my opinion that many security investments are based on little more that FUD - fear, uncertainty and doubt. Personally though I believe that we need to be making proper economic evaluations of security investments based on the costs and risks associated with security breaches, and taking into account the companies activities and operations.

I'll put my soapbox away now however, I will be keeping my mind on this subject. Anyone care to comment?

From the book "Zen and the Art of Information Security" by Ira Winkler.

When security is a should, people will tell you that security is secondary to business concerns. The security staff demonstrates a great deal of frustration. Employees have a casual attitude to security policies. I want to be clear about one thing, though. When security is a must, it does not mean that security is a priority over business concerns. When security is a must, security is integrated into business concerns. It is a business concern.

I've often been heard to complain that we don't direct security strongly enough - in other words rather than giving direct orders and instructions ("You MUST do this"), we say "please co-operate" or words to that effect and then expect things to fall into place. However, I now find myself unconvinced that taking the militaristic route is the right one. It may simply be more likely to get individuals nodding "yes" in agreement but then saying "no" once your back is turned. I try to take a reasoned middle ground: soliciting feedback and explaining the relevance of policy and risks that we are trying to mitigate.

This is exactly what I'll be doing this week when I present to a group of senior managers from my organisation who are coming together for a meeting from various points of the globe. The group represents a wide range of cultures and a wide range of attitudes to security so the dynamics should be interesting. I'll let you know how I get on.

The Microsoft® Security Intelligence Report (January–June 2007) provides an in-depth perspective on the software vulnerabilities (both in Microsoft software and in third party software), software exploits (for which there is a related Microsoft Security Bulletin), malicious software, and potentially unwanted software observed by Microsoft during the past several years, with a focus on the first half of 2007

I've been giving a lot of thought to the subject of data leakage and associated risks to the business. The problem we have right now is getting a handle on all the different vectors that data leakage can occur. Even when we do have a good idea of the scope of the subject there is probably little we can do in some instances to have the level of control that we would want over what information about our businesses is made available in the public domain.

If I were to identify one of the problems, it's this. Data might be considered to be an asset but the lack of a solid definition around what is and what isn't private, and the many different ways that data gets communicated has cheapened the perception of its value. There is also a fuzzy edge to the scope of business data. for instance, if I write about my organisation on this blog, does that then become business data?

How much risk is there associated with taking consumer products into our enterprise networks? Should we just say no? I think that to do so would not be a good strategic approach because many such products such as MSN Messenger and Skype, for instance, are often "good enough" for what we want to be doing and how we want to be using them.

I've been in many heated discussions about Skype. Where some individuals within the organisation see a need, others simply see unnecessary risk. I can see both sides of the arguement and personally, I think the business needs win over because we can manage the risk. However, to quote the fact that Skype is free to use as an over-riding reason is misleading. Skype is not free however you want to look at it. First thing is that you generally need to pay for an Internet connection before you can use the software. Then, if you're using it on company equipment within a large enterprise, it needs to be supported.

The most sensible thing to do is create some process whereby consumer products can be properly evaluated for use within the organisation. This process should look at risk as well as TCO. It's important because if we don't take into account the needs and the wants of our user population then they are likely to start conspiring against us. Conversely we also need to maintain control of our networks and limit the vectors where data can be inadvertently or maliciously leaked. Strong mandates are becoming more essential than ever .

Some of the consumer focused solutions infiltrating our networks include the various VOIP services sich as the aforementioned Skype, web-mail, desktop search tools, instant messaging, storage devices such as MP3 players. We then have blogs and social networking sites to also contend with.

Some of the risks include there being a lack of management capability, business unfriendly EULAs, introduction of malware, data theft, network compromises. Some consumer software such as GoToMyPC opens up corporate networks across the Internet. Software such as Google Desktop Search enables searching across multiple computers and the search index is stored on Google servers for up to 30 days. There is a whole new myraid of risk to consider and the point I keep on making is that our dusty old data policies and clunky old processes are not going to help us manage it.

What we need is new, agile, risk assessment processes and new policies that take into account our changing environments. Above all we need to maintain control and ownership of our networks.

A friend of mine has a cartoon strip on his desk where somebody asks "why are the two servers named Benson and Hedges?" The response is "Because that's what it said on the design document..."

The case in the press about the ongoing legal battle between EDS and BSkyB over the failed CRM design is an exceptional reminder of what can go wrong when requirements are, in this instance according to the QC, "wholly unspecified."

Ten years ago I sat in a project meeting where it was decided to scrap two months worth of work because there was a lack of documentation against which it could be tested against. It seems that a decade later we still seem to think that we can wing it with projects and hope that they work without documenting requirements. In some instances without even having a good business case to go on.

We can probably get away with it within our own organisations. Somebody might end up being shifted into marketing and somebody else might resign but the outside world will most likely be unaffected. The trouble comes when we start outsourcing - now we have to get the specifications right because if we don't the result is likely to be conflict. "Sky knew it wanted a super-dooper CRM system but had little more idea of what it wanted or needed." Super-dooper is a great requirement but it doesn't quite translate into UML...

Now the EDS/BSkyB case might be extreme in the sums of money that are being laid out but it should serve as a timely reminder of the importance of having solid SLAs and requirements in place before any work commences.

As the winter nights begin to close in, the family gathers around the fireplace for warmth and we'll tell each other stories. My current favorite is an old one entitled "the 10 deadly sins of information security management." This was written by Basie and Rossouw von Solms and published in Computers & Security Journal, July 2004.

Here are the ten sins as they are written...

1. Not realizing that information security is a corporate governance responsibility (the buck stops right at the top)

2. Not realizing that information security is a business issue and not a technical issue

3. Not realizing the fact that information security governance is a multi-dimensional discipline (information security governance is a complex issue, and there is no silver bullet or single ‘off the shelf’ solution)

4. Not realizing that an information security plan must be based on identified risks

5. Not realizing (and leveraging) the important role of international best practices for information security management

6. Not realizing that a corporate information security policy is absolutely essential

7. Not realizing that information security compliance enforcement and monitoring is absolutely essential

8. Not realizing that a proper information security governance structure (organization) is absolutely essential

9. Not realizing the core importance of information security awareness amongst users

10. Not empowering information security managers with the infrastructure, tools and supporting mechanisms to properly perform their responsibilities

The most important thing of all when it comes to our company networks and data is to be in control. This is also the most difficult objective to accomplish. In fact, just defining what we mean by "control" is hard enough although I'll have a go by saying I believe that we are in a good state of control when there are consistent processes being consistently followed throughout the organisation.

But to what lengths do we need to go to in order to accomplish this? I recall the processes followed at one business I visited in India. No employee could take into the building any personal items apart from the clothes they were wearing. Desktops were locked down to the nth degree. No Internet connectivity. All activities were closely monitored and audit logs continually checked. That's all fair and good but it's not exactly an environment condusive to innovation. But then again it wasn't meant to be.

Take the organisation I work for now. It encourages innovation, wants individuals to have ideas and research new ways of doing things. To facilitate that we have to open up to the outside world and provide opportunities to experiment with all matter of new resources and technologies. If there's one challenge above all others in my job, it's trying to define where the balance is between retaining control and letting go whilst still adequately mitigating risks.

The level of risk acceptance will vary from business to business and is dependant upon all measure of variables: value of the data, attitude to risk, regulatory environment and so on. If, for example, your business has an online growth strategy then you, as security officer, had better be prepared to support it and find ways to enable it to happen through your presently over-restrictive policy.

Following on from yesterdays blog, I had a brief discussion with an individual who thought my efforts would be better spent focusing on more timely issues. In a lot of ways, he's right - there are always imemdiate risks to contend with and project plans to update. We need to manage our time appropriately and make sure we're going to meet objectives. That's fundamental stuff. However, the world is changing and if we spend too much time with our heads down then we're more likely to be hit by the next threat before we see it coming.

So, I wanted to continue on the same subject for a while longer because I know it's not only me who has it in mind. Yesterday I mentioned my own opinion that "we should be enabling use of personal equipment and managing the risk" as well as a paper entitled "Zen and the Art of Rogue Employee Management" by Josh Holbrook.

Josh argues both sides of the fence. On the one hand he says that "consumerization creates a new burden that can potentially cripple already fragile IT organizations" while on the other he makes the point that "consumerization is already in motion, so how do corporate IT departments manage the new reality?"

Personally, I think it comes down to what value the consumerization is going to bring to the business, whether that value makes the associated risk worthwhile, and the degree that we can manage the risk. The reality is that this is not going to go away so rather than sticking our fingers in our ears and singing "la la la" we need to be thinking of the approach that we are going to take. Josh Holbrook recommends a number of ways forward:

As David Lacey mentions over on his blog, the question was posed as to “What are the 2, 3 or 4 key measures that are proven to significantly reduce the risk to your PC?”

Andrew Yeomans, who posed the question, regards the information at GetSafeOnline as being too detailed and "with rather too much jargon, that it will be a turn-off for many."

Personally I think that the information at GetSafeOnline is well presented and simple to follow - I've not seen anything better. But then, I'm pretty IT literate. However, the site claims to be "security advice for everyone" so I showed it to my mother.

It got off to a good start. She understands what a PC is. It all started to go wrong when she clicked on the link labelled "Use a firewall." Reading down the page was confusing enough but when it got to the section "How to install a desktop firewall" was when things really started to go wrong. "How do I know if I am using Windows XP or Windows Vista?" she asked. "Where's the control panel?" was the next question. It was the words "most desktop firewalls require some training before they are fully configured." that really got her anxious. "How do I know which ones?" she asked.

And here's the crux of the matter. We can all claim to be experts in our chosen fields but do we really know our audience and market? GetSafeOnline might claim they have a 10 minute guide to Internet safety and that may be true for the switched-on youth of today. However, my mum uses the Internet daily and expects switching on the PC to be as simple as turning on the telly. She has no time to read up about firewalls and viruses and, frankly, couldn't give a hoot so long as she can check her bank statements online.

The problem is that everywhere I look, including this American site, makes the same errors. It's been written by a techie. The solution to deal with individuals like my mother is for shops to sell PC's pre-configured with everything installed, set-up, set to automatically update, so that they can switch on their machines and have assurance that they are safe from the word go. Like turning on the telly.

Andrew's challenge is to prove the value of the top key security measures. Home users shouldn't need to go there - why should they even need to know that there is something called a firewall on their PC?

From a business perspective I can prove which measures work and I can build risk models that use statistics to show the affinity of controls against each of the risks we are concerned about. However, those statistics are only valid for my own organisation, which undoubtably has a very different risk profile from Andrew Yeoman's investment bank. So, the top controls in my office may very well be different from the ones that should apply elsewhere.

What I can also do is point to the fact that there haven't been any virus infections on the network for x days/months/years and refer to other statistics that show this is an improvement from y number of month ago.

That might not necessarily prove the effectiveness of the controls from a strictly scientific point of view but it's good enough for us to continue managing risk on a day to day basis.

Home users, unfortunately, are just going to have to muddle on. Actually, nobody I've spoken to even knew about GetSafeOnline before I mentioned it.

According to The Register, "Salesforce.com (SFDC) has been caught with its pants down after phishers persuaded an employee to hand over customer contact details."

That SFDC customers have been specifically targeted should not come as a surprise. The SaaS and PaaS models mean that more and more sensitive data and applications which manage that data are being built on the SFDC platform. It's an attractive and very large, high-profile target.

Apparently, one of their own employees fell for a phishing scam which resulted in compromised authentication credentials. A commentator on Bruce Schneier's blog suggests that the employee might have "sold his login information to the phishers."

SFDC themselves have issued an email to their customers stating that the intrusion did not "stem from a security flaw in our application or database." While this might be true, what their system didn't do was detect the unauthorised access, nor ensure that access to confidential data requires two-factor authentication (2FA) - or indeed anything stronger than a username and password.

Regardless, SFDC should be respected for quickly reaching out to customers with positive messages and sound advice, such as to modify "your Salesforce implementation to activate IP range restrictions."

This also stands to reinforce the importance of security awareness messages as a mitigating control against data compromise. We've got to work harder and spend a greater proportion of our resources on education. Perhaps we should start to make employees personally accountable as being neglegent if they are tricked into revealing data that results in a compromise? Surely, it's as bad as a developer writing vulnerable code or a network technician opening the wrong port on the firewall. All three scenarios are likely to result in the same outcome so why don't we address each of them with the same effort?

Anton Chuvakin has published a good paper on Database Log Management. You can download it for free here: http://www.infosecwriters.com/text_resources/pdf/AChuvakin_DB_Logging.pdf.

I'm not a conspiracy theorist. Neither am I religious, superstitious, nor to I believe in horoscopes, flying saucers, or any other fantasy "spiritual" mumbo jumbo. That doesn't mean I'm not interested - quite the opposite as I have a bookshelf full of such nonsense that I enjoy reading in my quest to understand why people behave in certain ways.

Individual behaviour is important to security. We need to understand motivations and sometimes we need to work out how to modify behaviour in order to mitigate risk. Yesterday, I met with an HR director who told me that security is taken extremely seriously within her organisation and she can prove this because there is a document that says so published on the Intranet. This happens to also be an organisation where somebody I'd never met before let me into the building - no questions asked - and directed me to the department I wanted to get to then left me to get on with it.

In an ideal world that person would have asked me questions. "Who are you and who are you visiting?" would have been good starts. But she didn't because human nature is not to question for fear of sounding daft or offensive. What, however, if the company in question stated, "anyone who lets anybody into the building without ascertaining they have a right to be here will be fired." I'll bet that would change behaviour.

However, I'm not advocating such a regime - totalitarianism might work for North Korea but it probably wont work for the average plc. Instead, security practitioners need to understand psychology. In fact, the best "social engineers" do this by instinct - it's what makes them able to circumvent your systems with ease.

From learning more about the psychology aspects of security we should be able to build good security awareness campaigns and implement usable processes that really make a difference in mitigating risk.

Quite how David Litchfield of NGS Software can survey a million IP addresses, find 200 vulnerable databases, and then conclude that this means there are half a million others similarly vulnerable and "putting corporate data at risk" strikes me as the same logic Tommy Cooper used to deduce that.."Apparently, 1 in 5 people in the world are Chinese. And there are 5 people in my family, so it must be one of them. It's either my mum or my dad. Or my older brother Colin Or my younger brother Ho-Cha-Chu. But I think it's Colin. "

But let's not undermine the premise that there probably are a number of insecure databases out there for one reason or another. It's reasonable to assume that some of them will contain private data. How do you know if it's one of yours? Of course, you could employ a company such as NGS to find out for you. In fact, that's not a bad idea and here's why. Even if you've hardened the server, configured and locked down the firewall, implemented an IPS, ensured that access is IP strapped, and done everything else the manual on "teach yourself database security in 24 hours" says to do, it's still likely that one day soon, somebody within the organisation will change something, or a new found vulnerability will go unpatched and you'll end up with your kimono open slightly more than you'd like to have. And when that happens, others notice but generally are too polite to tell you about it until it's too late....

An external test, looking at your IP range in the same way as a targeted attack would, will identify any exposures.

Of course, what testing wont help you identify is instances such as the security breach suffered by Certegy in the USA where a database administrator "misappropriated and sold consumer information to a data broker who, in turn, sold a subset of that data to a limited number of direct marketing organizations." You'll need decent internal management processes to avoid that scenario. But that's another blog.

For now, here's some more Tommy Cooper..."So I was getting into my car, and this bloke says to me 'Can you give me a lift?' I said 'Sure, you look great, the world's your oyster, go for it.' "

I must admit that I am still struggling with metrics. One problem is now between what I believe are useful statistics to be gathering against what's useful information for management. Another is the whole gathering exercise to consider: especially as I'm asking individuals to spend more of their valuable time reporting data back to me at the same time as they are receiving umpteen other requests for data from various other sources ranging from Corporate Audit to the Project Office.

I've reviewed what the purpose of metrics are because the danger is that we'll just set about gathering data for the sake of it. The objectives, in my opinion, are to

a) Collate information about the security status of the organisation
b) Measure progress (i.e. to answer the question "Are we more secure today than we were yesterday?")
c) To assess the impact of changes

We also need to be careful not to utilise metrics as a competition between different parts of the business. The motivation should be to understand impacts and risk, and the role of the security manager/director/officer (let's talk about job titles sometime shall we?) to provide management, guidance, and resources for mitigating risk. What we don't want is more league tables because then we'll be ring-fenced and have to work much harder to get the data we want.

I took the following quote from a paper by Shirley Payne entitled A Guide to Security Metrics

Good metrics are those that are SMART, i.e. specific, measurable, attainable, repeatable, and time-dependent, according to George Jelen of the International Systems Security Engineering Association. Truly useful metrics indicate the degree to which security goals, such as data confidentiality, are being met, and they drive actions taken to improve an organization’s overall security program.

So, there's plenty of guidance out there but much more interesting would be some actual comparison of what's being used by different organisations in the real world. Once I've finished defining the format of what I'm planning to collect and collate then I'll share it here.

"A recent virtual meeting of 200 IBMers was held in a recreation of Beijing's Forbidden City, where the avatars of the company's chief scientist, Irving Wladawsky-Berger, and CEO, Sam Palmisano, announced a $100million investment program in innovative technologies, including the business use of virtual worlds." (Information Age, October 2007).

IBM are described as being a "passionate believer" in virtual worlds. But I wonder if we shouldn't be heeding the words of Professor Clive Holtham, of the Cass Business School, who says "communities such as Second Life...are little better than traps for the gullable."

Here is a quick primer on some of the risks we should be thinking about:

1. Identity Management. There are no identity guarantees in the public virtual world. Any avatar can claim to be any real-life person.

2. A business cannot manage its reputation within a virtual world where there are no controls over what can occur around it.

3. Conversations cannot have any assurance of privacy or confidentiality within a public virtual world

4. Virtual world client applications are frequently updated with a resulting lack of control over software within the corporate environment

I'm as aware as anyone that CIOs are speculating on potential business benefits of virtual worlds and looking for revenue generating opportunities. I reckon most will be dissapointed. The benefits do not at this time outweigh the risks and investing money in, for example, Second Life is, in my opinion, simply gambling. The only winner is going to be the vendor.

Even if I'm wrong and businesses begin to accumulate valuable assets, who's to protect them? Let's keep in mind that virtual assets only virtually exist. They are but bits and bytes in memory somewhere on a server - and probably a virtual one at that!

Here's another interesting and disturbing angle reported here

A recent guild disbandment in World of Warcraft may mark the beginning of the decline of “Virtual Worlds” into “Virtual Countries,” as conflict of law issues make it nearly impossible to fairly enforce rights and duties....Facing negative press and potential legal problems in Germany, Linden Lab took steps to remove ageplay from Second Life a few months ago. Though a statute criminalizing virtual child pornography was deemed unconstitutional in the United States (Aschroft v. Free Speech Coalition), U.S. citizens (who would otherwise be allowed to engage in ageplay in Second Life) are barred from it due to the laws of foreign nations, including German and Israeli law.

What I do know is that Second Life et al are here to stay. They can't be uninvented. Please consider the risks to reputation, and the rules of gambling apply: don't risk what you can't afford to lose.

An important point has been missed in the news reports regarding the loss of UK child benefit records. That point is that I don’t believe for a minute that this is the first and only time such important data has been treated in this way. If management processes were so poor this time around then it will definitely have happened on previous occasions. It just happens to be that this time the data went missing and this time we’ve found out about it.

We have no option but to consider the data compromised. As such, every individual whose details were on those disks must be notified of the potential consequences and given the tools they need to ensure that their identities are protected are far as possible.

The investigators need to focus on working out when the data was first compromised – how many copies of that database are there sitting on CD-ROMs and other media? Who else has access? What logs are kept showing the occasions the data is copied off to removable media? How frequently are the logs audited? Is usage of the database actively monitored? What happened to the principles of need-to-know in this instance? Where was the encryption? Any of you whose details are likely to be included should be demanding answers to these questions.

Of course, this is all after the event. The horse has bolted. Investigations and fingers of blame can't undo the incident. The best we can hope for is that it wont happen again. And we should all better understand that poor practices and inadequate controls will most likely eventually catch-up with us. Anyone who says to me "we haven't been hacked before" as an excuse for not putting in place the right controls gets the sharp end of my tongue.

So, if you happen to find an envelope with a couple of CDs in it, please don’t return to sender. They clearly shouldn’t be entrusted with the responsibility. My suggestion is to cover them in a clear plastic and use them as decorative coasters.

Nothing focuses the mind more than being asked to prepare an updated report for the board. Can we report that previously reported risks have been reduced? Certainly we can because that's what we're working on day by day. The difficulty comes in putting across the message that the threat environment is changing - probably more rapidly than ever. This means that some risks are increasing and new ones are emerging. There is also the case that we're as vulnerable today to some risks as we were six months ago but the potential impact has changed.

I recently worked through a security project plan with a business manager. He was very happy to see some ticks next to milestones showing that the particular tasks were complete, and assumed that no further work would be required on the subject. Sorry to dissapoint, but it aint over yet!

The old debate about password strength has resurfaced. Somebody asked me "how many passwords are really cracked?" It's a good question, and one that I don't have the answer to. Which doesn't really help my cause when I'm pushing policies that enforce strong (i.e. a minimum of 7 characters consisting of upper/lower case letters, numbers and symbols) passwords and two-factor authentication. Is it really all necessary?

The fact is that passwords can be cracked and there are plenty of tools out there that will help the hacker do this. For instance, OphCrack uses rainbow tables to crack passwords across multiple platforms. There's an excellent reference on the Coding Horror blog.

To understand how rainbow tables work, you first have to understand how passwords are stored on computers, whether on your own desktop, or on a remote web server somewhere.

Passwords are never stored in plaintext. At least they shouldn't be, unless you're building the world's most insecure system using the world's most naïve programmers. Instead, passwords are stored as the output of a hash function. Hashes are one-way operations. Even if an attacker gained access to the hashed version of your password, it's not possible to reconstitute the password from the hash value alone.

But it is possible to attack the hashed value of your password using rainbow tables: enormous, pre-computed hash values for every possible combination of characters. An attacking PC could certainly calculate all these hashes on the fly, but taking advantage of a massive table of pre-computed hash values enables the attack to proceed several orders of magnitude faster-- assuming the attacking machine has enough RAM to store the entire table (or at least most of it) in memory. It's a classic time-memory tradeoff, exactly the sort of cheating shortcut you'd expect a black hat attacker to take.

You probably use the same password for lots of stuff right?
- Some sites you access such as your Bank or work VPN probably have pretty decent security, so I’m not going to attack them.
- However, other sites like the Hallmark e-mail greeting cards site, an online forum you frequent, or an e-commerce site you’ve shopped at might not be as well prepared. So those are the ones I’d work on.
- So, all we have to do now is unleash Brutus, wwwhack, or THC Hydra on their server with instructions to try say 10,000 (or 100,000 - whatever makes you happy) different usernames and passwords as fast as possible.
- Once we’ve got several login+password pairings we can then go back and test them on targeted sites.
- But wait… How do I know which bank you use and what your login ID is for the sites you frequent? All those cookies are simply stored, unencrypted and nicely named, in your Web browser’s cache.

The top 20 passwords are (in order): password1, abc123, myspace1, password, blink182, qwerty1, , 123abc, baseball1, football1, 123456, soccer, monkey1, liverpool1, princess1, jordan23, slipknot1, superman1, iloveyou1 and monkey

If you were to ask me what I consider the biggest security threats to a large organisation are, then I would reply that it's two things: third parties and portable devices. We're asking more of both and we're trusting more of our private data to both as well. For instance, we might use third party data centers because of in-house space, security and systems management challenges. So, the business will research solutions, invite quotes, and choose it's service provider. At what point do we look at the vendor's security and what questions do we ask?

In my own organisation I've implemented a a vendor risk-assessment process that allows me to score based on a standard set of questions covering everything from connectivity to local security management. The process works well and puts me in a position where I can give a reasonably well judged assessment, based on a standard and repeatable process, to management.

Mobile devices are, as we are all aware, proliferating fast. We are now being overwhelmed with blackberries and laptops and smart-phones and USB thumb drives. Here, security awareness and education probably pay best dividends, but I've also been looking at numerous means of getting the data on those devices encrypted. In the near future, as described here virtualisation might be a solution for managing mobile device security.

Those are my top two concerns. How do they compare with yours? Anyone?...

The Ponemon Institute has concluded this year that "data breach incidents cost companies $197 per compromised customer record in 2007, compared to $182 in 2006. " This data is reported in the document titled "2007 Annual Study: U.S. Cost of a Data Breach" and can be downloaded from the link at the end of this blog.

Interestingly, over 70% of that amount is reported as being down to lost business, the remainder is attributed to detection and escalation, incident response, and notifications. Causes of the breaches are pretty much in line with what I reported on this blog a few days ago. Namely:

• Lost laptop or other device (49%)
  
• Third party or outsourcer (16%)
  
• Paper records (9%)
  
• Malicious insider (9%)
  
• Electronic backup (7%)
  
• Hacked systems (5%)
  
• Malicious code (4%)
  
• Undisclosed (2%)
  

Since 2005, the percentage of incidents where a third party such as an outsourcer or consultant was responsible for a data breach has increased from 21 percent in 2005 to 40 percent in 2007.

The report concludes with some good words to take heed from:

Trust may be intangible and hard to quantify, but the result of breaking that trust is clear as the cost of lost business grew more than 30 percent since 2006.

It's been a busy few weeks with lots of travel. I'm already an old hand at negotiating the ridiculous security countrols at Heathow but lately I've gotten it down to a fine art - laptop out of the bag, shoes off, jacket off, through the machine, beep, back through the machine, remove belt, step forward again, collect belongings, shoes on, drop laptop etc...

Tomorrow morning I've got to do it all over again as I trek down to Spain for a couple of days. I can bear the travel but I can't bear the economy class breakfast rolls filled with cold bacon and scrambled eggs that they serve on British Airways. Those are probably the most disgusting, inedible, foodstuff ever developed. Come on BA, did some-one really make those rolls, sit back and think "Hmmm, that's good and I'm proud of this product"?

Once I've braved the perils of economy class food, the travel pays dividends because I can glean more information and provide more value through two days of being on site than I can in six months of emails and phone calls. Emailed correspondence doesn't provide the opportunity to say "ok, that's interesting, now show me what you mean." When you ask a question by email the respondent will invariably provide an answer that they think you want to hear rather than telling you the full story.

It's also the opportunity to build those relationships and increase mutual trust. Make sure you say what you do and then do what you say. You'll get more information given to you, more questions and issues raised, and as a result, a much greater understanding of the way your organisation works and where the risks to your data are....

Kai is calling to you. She is calling to you to make her internet experience Fun, Social, and Engaging. If she uses your services today, that does not mean she will use them tomorrow. She is brand loyal, but your site will hold her attention primarily if it holds the attention of her community. Her group. Her peeps. Welcome to the fad.

Reality check required. We've yet to perfect "Security 1.0" for "Customer 0.5" so Kai can have no expectation of privacy or security until online security grows up and we can tell the difference between Kai and the umpteen individuals who will be pretending to be her.

More important than ever before is architecture, and particularly making sure that back-end business processes are closely coupled with front-end features, but also ensuring that the security layer provides strong, transparent controls around managing identities and access to functionality.

The danger, of course, is that in the rush to address the perceived needs of Kai, we'll end up chucking architecture out of the window and serve up products that look cool but lack integrity. The result will be that Customer 2.0 is superceded by a "Customer 3.0" who will be mostly untrusting of using any Internet based services at all....

The results are in from the Computer Weekly survey on usage of Social Networking sites. The survey, based on 331 responses from a wide variety of organisations, provide an interesting insight into the impact that social networking sites are having on the work place. My stance, that I'll come to later in this blog, is that there is a serious security threat. Read on...

Just under a third of respondents (31%) allowed unlimited access to social networking sites, with the same proportion (31%) only doing so during non-core hours. 37% did not allow ANY access. Of those that allowed access respondents estimated that employees spent an average of 50 minutes on social networking sites per day. This rose to 56 minutes amongst those companies allowing unlimited access (44 minutes amongst companies not allowing access in core hours), and 62 minutes amongst London based companies.

I've been trying to make the point that we can't protect data by following a checklist and filling in an audit sheet. These tools can assist us to identifying where we think the problems are but at the end of the day we invariably get caught out where we least expect it in spite of all the tools that we have.

Let's take a hypothetical situation. You've been asked to assess and identify issues around data security for a particular customer database - where do you begin?

There are numerous places to begin. Some might firstly want to look at policies governing access to the data. This could be followed up with an assessment of the network infrastructure controls . Then you'd probably want to look at how access is granted to the data and so on. So, how does the data get into the database in the first place? Perhaps it's from a form that customers complete online. In which case, does the data first get stored somewhere else before it gets into the database? Now when you start digging into questions such as this is when you start to realize the scale of the challenge.

It's likely that the data doesn't just exist in a single place. It might be on a server that's hosted externally, it's likely that reports from the data have been created so it's also on spreadsheets. These spreadsheets have probably been emailed. Those emails have likely been printed.

What about back-ups. There is more than likely a formal back-up process onto tape. That's good. But individuals like to have their own back-ups too. So, process owners might also have copied the data into a multitude of locations: local drives, network shares, USB sticks.

So, while the initial task to look into the security controls around a particular database may appear straight forward enough, it never actually is.

At which point in the chain will the data compromise occur? It wont be where you have the strongest security.

If a data breach occurs and you don't know about it then did it really occur and does it matter? Absolutely it does. Every record in that customer database has cost you pounds and dollars to collect. Every record represents potential revenue to your business. Every record represents an individual or organisation that has a right to expect that the data you have collected about them is something you actually give a damn about and will go out of your way to protect.

In some cases we've become fixated on compliance and only seem to care about data if we're likely to fall foul of legislation in the event of a breach. But let's step back to some fundamentals of information security: The "c" stands for confidentiality, not compliance.

If this sounds like I'm standing on a soapbox then no apologies. Somebody has to....

I admit that I've been guilty in the past of making flippant remarks such as "we're not a bank so don't need Fort Knox security" and other such excuses for not doing things as securely as I might want to in an ideal world. Comments like this don't help in the slightest and lead others to presume that security isn't such an important consideration.

Conversely, we need to be pragmatic and seen to be complementary to business strategy. It's a tough trade off and one I've never been particularly comfortable making. An example of the sort of thing I mean is granting developers local administrative rights on their desktops. The reason being that there is a perceived requirement for them to be able to operate as administrators in order to perform their development tasks. However, I actually think that these are, in many instances, the very individuals we need to be more carefully managing. By opening up access I'm seen as being pragmatic and enabling, whilst in reality I'm grinding my teeth and wondering if we can't segregate them from the rest of the building - preferably with barbed wire and a very high wall.

And, as we all really know, developers always insist on asking for more than what they really need. For instance, one such individual recently insisted to me they needed a copy of a live database to test against....on a laptop....

Back to the point which is that, while we're not Fort Knox, we are a profit making business with a good reputation, and servers stuffed full of data that our customers would expect us to protect. So, it's time to quit making the flippant remarks and for everybody to start taking security seriously. If that means upsetting one or two people who see security as being a block to their work then quite frankly I'd rather be seen as being over-cautious and diligent in my work than negligent.

I like to keep a close eye on the technical infrastructure. For instance, I've now got a Landesk client installed on my PC, which enables me to get the metrics I want on our infrastructure security status without having to rely on others to get it for me (I think Landesk is a fantastic product, enabling our technical teams to roll out patches and provide desktop support amonsgt a myraid of other useful tasks).

I also have our perimeter scanned on a regular basis. This is an invaluable service, enabling me to quickly identify new vulnerabilities and alert the right teams on appropriate remediation actions. If you're not already doing this then I recommend you begin. Sometimes, I'll do a bit of testing myself to verify scan results or check the status of a firewall.

As you can probably tell, I still enjoy being able to retain hands-on security skills. I'm often fearful of becoming little more than an administrator and delegator whilst others get to perform all the interesting work. Behaviour not becoming of a security director? Give me a break - I got into this job in the first place because of my interest in the subject and spent years gaining the sort of techical skills and knowledge that allow me to understand what's really going on. I know that these days we're supposed to be good managers and good business people - and I hope I am both - but underneath that (very smart) suit is still a geek and techie looking to break out...

Don't forget physical security. There are a number of aspects that you need to keep in mind including security of server rooms and data centers, access to office space, and verifying that security controls work. Thieves will target hardware: two incidents I'm familiar with involve one case where the alarms weren't working, and another where , in broad daylight, criminals walzed in past the building reception desk and walked out with servers. There have also been some high profile incidents in the press such as this one here.

There are a number of simple questions to ask when thinking about physical security: Does the business share building space with other organisations? How frequently are physical controls tested? Is there a suitably descriptive SLA in place with third party security firms? What restrictions are there in place for accessing server rooms and data centers (and is access to these sensitive areas properly authorised and monitored?).

Keep in mind that assets do not necessarily need to be of a high value before some-one will steal them. If you leave the door open then you'll inviting in the crooks.

You also need to remember that physical security controls do not just apply to hardware assets within the premises. Backup tapes being transported off-site can also be vulnerable so make sure they are encrypted. Mobile computing devices are particularly vulnerable.

Your information security program needs to include an assessment of physical security controls even if you're not the person responsible for it. Don't be afraid to highlight concerns. And always check. I checked and found a server room side-door "locked" using sticky tape and a well placed cardboard box....it's true!

Developers often want to make use of shareware to obtain code they would otherwise need to be spending a lot of time developing. The IT Ethics handbook (by By Stephen Northcutt, ISBN 1931836221) states:

Downloading shareware opens an entire box of ethical issues....the programmer and the Information Security Manager should set up a shareware standard in advance. If the Information Security Manager is too stringent, the programmer will have difficulty getting the job at hand done. This will consequently result in an uncooperative relationship between the programmer and the Information Security Manager

I'm worried about a number of things. Thing number one relates to my recollection of the day a production web site ceased to function. The cause was traced to a shareware component that had been implemented without a thought being given to its 30 day trial period expiry. Oops. I'm also concerned about the somewhat flippant disregard for safety that developers often have as they go blithely surfing the web looking for useful components.

Conversely I don't want to be accused of standing in the way of short lead times and pressure to deliver. The solution might be to give the developers access to all the resources they need so long as it all remains in a segregated network. Fair enough but then I'm now worried about what's going onto the production servers once the components are incorporated into the code.

Of course, one could question why a professional development team using enterprise platforms needs to resort to using shareware and free tools anyway. Maybe some-one could let me know?

Quote of the week has got to be "Before, our systems were a little bit vulnerable, and now they are not" from Andrew Brenson, a spokesman for the charity Children In Need. Almost as good is the report of their business case for implementing a new two factor authentication solution as being that their "previous system needed to be improved."

If only all business cases for spending money on security were so easily written.

The full article from Computer Weekly can be read here: http://www.computerweekly.com/Articles/2007/12/14/228627/save-the-children-brings-in-two-factor-authentication.htm. However, if you have five minutes to waste, rather than reading that article, read this one instead...http://msdn2.microsoft.com/en-gb/security/aa473878.aspx. It's the new "Developer Highway Code" from Microsoft (thanks to Mark Curphey for putting the link on his blog). I'll talk more about this one later in the week.

This is my last entry for a few days as I fully intend to make the most of the holidays. I wanted to take the opportunity to say thanks to those who regularly read and support this blog, and to wish everybody a merry christmas and good luck for the new year.

A number of events have stood out during 2007 that serve to remind of the importance of process over technology when it comes managing information security. Most recently, of course, the HMRC data breach demonstrated that all the technology in the world can't stop people doing daft things that break the rules and put your revenue and reputation at risk.

My priorities for the new year are going to be:

- Focusing on user access and entitlements to company data
- Focusing on the security of the third party vendors that we deal with
- Tightening up our borders and spending more time on testing that the technology side of things is hardened and properly managed
- Security awareness and information for employees

2008 will, I predict, be a challenging year. Stories such as this one reported in The Times about state sponsored hacking probably represent the tip of the iceberg and we'll likely be seeing many more disturbing reports of such activities with consequences for foreign organisations performing business within countries under suspicion. Social networking sites will be a magnet for hackers and identity thieves and stories about both individuals and brands being affected will be rife.

Such an environment means that the information security industry will continue to florish. I was recently in Spain on business where I learnt that few organisations presently employ individuals with the sort of position that I hold. I think that's about to change as countries that have typically lagged behind with regards to technology come of age and begin to suffer their own fair share of electrionic attacks and data breaches.

As for my own personal 2008. I'm looking forward to the challenges ahead and, obviously, another good year of blogging!

Interesting article here on Security Focus entitled "IT Risk and the Millennials" about the Generation Y workforce, their expectations, associated consumersation of IT and the risks that come along with it.

According to the article, "Millennials are demonstrating that the consumerization of IT can actually increase productivity and reduce costs." I disagree. I don't believe that anyone can yet demonstrate anything of the sort and the quoted example given that "you can't deny the cost savings being recognized with free and low-cost VoIP technology, such as Skype" is unfounded. It's not free - because you still need to pay for the Internet and the technology to use it, and it may be low cost but you get what you pay for in terms of quality of service and experience. Anyway, that's another arguement.....

What's most interesting for me is the reported attitude of the so-called Millennials and the additional risks that they bring into the workplace because of it. This article here brings the point home when it states that

Millennials are the most connected generation in history and will network right out of their current workplace if these needs are not met. Computer experts, millennials are connected all over the world by email, instant messages, text messages, and the Internet

My view is firstly to stop this daft labelling of individuals as Generation Y or Millennials or any other term. There appears to be a fine line between providing a decent work environment and making life good for employees on the one hand or, on the other, curtailing to the wants and requests of a spoilt social group who seem to think that they are employed because the employer owes them a favour. From the business perspective, nothing new should be introduced into the environment until somebody knows how to support it and has knowledge about any associated risks. Lastly, before we make any more rash statements about web 2.0 increasing productivity and saving money, somebody please show us the data that supports this?

There is an ever increasing requirement to provide suitable facilities so that employees can work from home. Right now all we have available within my own organisation is an expensive and cumbersome IPSec VPN solution that requires an employee to have company provided equipment on which to install the client software. We use RSA tokens for two-factor authentication.

It's not a particularly flexible solution. First and foremost, I do not allow non-company owned computers to be connected to the network so unless an individual has been provided with a suitably built laptop or has an acceptably built and supported desktop corporate PC at their home then the answer is "no".

One class of solution being investigated is making use of an SSL VPN configured to allow users to access network based resources through a browser using their own PC. This can also be combined with a malware detection solution that can scan any device attempting to connect to determine if has been compromised. We can also go into management over issues such as whether or not users can save and copy documents.

However, if we're going to allow home users to use their own PC's to connect to work resources then should we also be able to mandate acceptable use of that PC and the standards of ownership and management of the equipment in question? We can probably try but I doubt that there is much in the way of enforcement that can be performed.

There have been cases reported of home workers being specifically targeted to get through to corporate data. For example, this story from earlier in the year where hackers "had hoped to exploit lower levels of security in home computers to burrow into the corporate network." One question is how much company data and up to what classification would you trust a home worker to have on their non-company PC? And that's before you begin addressing questions about data backups.

Also, in any typical home PC scenario, it's likely that other members of the family will also be using the same machine for everything from checking email to downloading music to searching for that elusive guitar tab (as happens in my own home...) and all the associated risks of trojans and keyloggers.

Reality though is that it's estimated that by 2012 more that 5 million people will be working from home. Strong authentication is probably the easiest problem to solve. Managing the end-point is much more difficult and I'm not sure we've yet got a good answer. Anyone care to suggest something?

Happy new year to you all. If the predictions are right then we'll be having a busy one. Just to get us into the right frame of mind for what's ahead, there's a good - and short - white paper entitled "The Online Shadow Economy" from Maksym Schipka of MessageLabs that's well worth a read.

The paper doesn't document anything new but it serves as a fitting reminder of the blackmarket built up around the exchange of malware between hackers. Some claim to be earning in excess of $10k a day but it's not so much the amount of money as the sophistication of the industry that's of the most concern.

Research "suggests that malware authors can produce new, unique malware every 45 seconds in order to keep it undetected" and code is sold along with guarantees that "that a given virus or trojan will not be detected using current antivirus programs. If vendors update their software, then the malware author will supply a new version."

A few months ago I quoted John Pescatore from Gartner who predicted that "by the end of 2007, 75 percent of enterprises will be infected with undetected, financially motivated, targeted malware that evaded their traditional perimeter and host defenses." Given the state of the black market, and the increased reports of foreign agencies taking an interest in getting back-door access to corporate data (for instance, see here) then I don't see any reason to doubt that this prediction is too far from reality.

Happy new year indeed!

One particular challenge I keep coming back to is defining what "confidential" means with reference to data. What is the difference between "confidential" and "restricted" and "private" ? I also have the term "High Loss Impact" (HLIP) in use and if I go around the business I'll probably find a whole lot more as well in a dozen different languages.

Clearly if I want people to handle data correctly then the definitions need to be right. From a global corporate governance perspective the problem is that there does not seem to be a single definition that can be used, for instance in the USA that also equally applies to France and China.

I like to use HLIP as the term of choice because that seems to cover everything that might cause trouble if it were to be compromised regardless of whether it's personal data or business related.

Classification schemes are supposed to be based on the value of the data asset being protected but that value is subjective and, in these days of heightened attention of any and all data breaches, often under-rated. On the other hand, you can't simply bag everything up as confidential and lock it in a cupboard because at some point, somebody needs to work with, refer to, copy, print, and eventually dispose of the data.

So, I've taken a path of least resistence. I know the business and I know the data being handled so instead of focusing on the labelling I'm focusing on the content and prescribing process by example. The documentation details examples of the different categories (e.g. financial data, customer data etc) and the different forms (e.g on paper, in an electronic spreadsheet etc) and defines a step by step process for what to do with it. Sort of like a cook-book.

That's not to say that I'm ignoring the fact that data should be labelled with a classification. Far from it. However, with the right communication of the processes we should be some way towards ensuring that all data is being appropriately handled. Make sense?

Two experiences with vendors today: first one gave a credible presentation and quoted some good prices before departing with a promise to put the quote in writing later in the day. Lo and behold the quote arrived via email with a cost three times as much as that quoted during the meeting. The excuse? There were two: i) Quoted in the wrong currency during the meeting ii) it's list price so not really the price we'd pay.

Second vendor is trying to sell the same product to three different parts of the same organisation at three different prices....

I enjoy negotiating but only with people I trust. Once my bullsh*t detector starts twitching I tend to lose interest in how good the product is..

If CIOs are going to make the most of opportunities for using IT to fuel business transformations, and become engaged in experimentation with PaaS, SaaS, virtual worlds, Web 2.0 and the full realm of other new and emerging technologies then Information Security must become an embedded and fundamental component of planning.

Most guidance to CIOs that I've read on the subject of security appears to have come from analysts and journalists. So, this is my view, as incumbant Information Security Director for the world's biggest and best organiser of trade and consumer events.