Stuart King's Security and Risk Management Blog

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/