Stuart King's Security and Risk Management Blog

One of the problems with information security and risk assessments is that we're really dealing with uncertainty rather than risk. There is a difference. You can estimate risk when you know the probability of an event. When it comes to information security there is a lack of valid data. Not only that, but the nature of security threats change so rapidly these days that the chances of us being able to gather a meaningful set of data about vulnerabilities may never be possible. As by the time you've collected enough data the environment will have changed.

Decisions are actually being made on the basis of trusted opinions. It's still a "risk assessment" but it's an opinion. In information security, two people can be given the same set of data about threats and vulnerabilities, use the same risk modelling methodology and reach two different conclusions. I've seen it happen many times.

Interesting to note is the fact that given all our risk models, the world of information security wholly failed to predict and prevent the recent and continuing spate of data breaches. As an acquaintance of mine recently said, "We've been focusing on brain surgery while the patient dies of the common cold."

My favorite example of the futility of the risk assessment comes from Nassim Taleb's excellent book The Black Swan. 

Consider a turkey that is fed every day. Every single feeding will firm up the bird's belief that it is the general rule of life to be fed every day by friendly members of the human race...On the Wednesday before Thanksgiving, something unexpected will happen to the turkey. It will incur a revision of belief.

As Taleb points out, the turkeys feeling of safety likely reached its maximum when the risk was highest. 

So, our risk assessments cannot prevent bad things from happening. We can have an opinion based on our "expert" knowledge but now look back over most - maybe all - of the information security related risk assessments that you've made. Did you really need to work through the model to get to the conclusion that you've reached or did you know what you were going to say before you started?  

 

The data breach suffered by the British National Party is a low-tech incident against which there is little defence. See http://news.bbc.co.uk/1/hi/uk/7736794.stm.

I have no personal sympathy for the BNP - and their politics are not for comment on this blog - but the incident is a good example of the impact that a disgruntled insider with access to confidential data can have.

It's similar to a recent case that came my way where a former company employee, shortly after leaving his organisation, anonymously sent an email to senior management containing an alleged exposé of poor management practices within his business unit. A real case of sour grapes that fortunately had little impact other than to create some mischief.

While it's possible to restrict an individuals access to the office and network once they have resigned or been fired, it's not always easy to know what grudges may be held or what information or documentation might already have been removed. The insider threat, as the BNP have now discovered, remains a potent one.

It's interesting to speculate how three seperate hospital computer systems have managed to simultaneously fall victim to malware. See http://news.bbc.co.uk/1/hi/england/london/7735502.stm. Given that the rest of us have not today fallen victim to anything new, and that other hospitals appear to still be functioning, it looks like a highly targeted attack. The Register reports that it might be a case of the Mytob worm however, I'm dubious: Mytob is more nuisance malware rather than disruptive, it's signature is well known, and I doubt it would result in the networks of three hospitals being so thoroughly disrupted. If it were a new variant evading the anti-malware protection, then we'd all be seeing it.

I've learnt the hard way that however much time gets assigned to a business unit security review, that you invariably step off the plane on arriving home and suddenly think of three more questions that you could or should have asked, or on getting back to the office the first question the boss asks just happens to be the one that you didn't get an answer to.

For most reviews I follow a fairly mature checklist based process. It's been reliable up until now. However, the environment is changing rapidly but the checklist has stayed the same. It now needs to be modified so that, in many of the instances I deal with, proper account is taken of challenges around things such as joint ventures and externally hosted services. Keep in mind that you might not always be able to get access to review systems that become in scope or talk to the right people to get the information that you need.

My approach is to document what I do know and state what I don't. The issue, as I've discovered lately, is that we frequently don't know what we don't know. And as they say, what you don't know is often far more relevant than what you do know!

My first rule of Information Security has today been demonstrated to good effect to still hold true. The rule being: "If you don't check then it hasn't been done."

The somewhat related second rule of "people will tell the Security Director what they think he wants to hear" is also proving to still be very current and valid.

The fifth rule of "never trust a network diagram to show a true and full picture" is now promoted up to third place.

The problem for those who feed me incorrect information is that they clearly haven't yet learnt that I always check the detail.

It's still only Monday too!

I was reading with interest a two-part blog posting from Chris Hayes on his Risktical Ramblings site. It's a detailed and thorough run through of a risk assessment process. I actually think it's very instructive and those of you who want to learn about how many information security professionals approach assessing risk should read through it. That's not supposed to be complementary. Sorry.

The problem is that it's completely impractical. I'll take a recent, and fairly typical situation as an example. I was taking issue with the manner in which remote access was being provisioned for a third party vendor to connect to a system hosted by one of our European business units. To cut a long story short, it was not only a breach of policy but highly insecure. I wanted the access to be disconnected, the business unit director wanted my risk assessment. And he didn't want to wait for it.

To quote Chris Hayes, spending time on working out the expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force was not going to pacify an angry Italian fearful that my decision was going to cost him money. He wanted my explanation of the risk and more importantly, what I was going to offer as a solution to keep his business functioning.

Information security risk assessment does not require detailed and scientific analysis. This is not rocket science, it's business. If you have a problem then you need to be able to explain the reasons why in a language that even somebody in the marketing department can understand. Risk models have their place, it's useful to understand the components that create risk but most of what I read that's aimed at the information security market is less than useless for working with on a daily basis.

When I need to document a risk assessment I use a very simple form: list the threats, state the level of vulnerability, list the associated operational costs and potential revenue hits. High, medium, or low risk? Describe the controls and options. Write up who needs to do what, and how much of their time it's going to take. Job done.

My daughter's school (which she has attended for the past two years) has sent a questionnaire for me to complete for their records. They apparently need details of her ethnic origin and first language.

I've ticked the boxes indicating that she is a Romany/Gypsy with Hindi as her first language. Call me childish but I couldn't resist. However, today there is a message on my answer phone from the school asking if I will call them back to confirm some information.....

A few days ago, I was privy to the first quarterly Security Awareness Newsletter distributed by a large corporate organisation for the digestion of a globally dispersed workforce. By all accounts the content had been decided, written and designed by their Information Security Group, with reviews and editing by their US-based legal department - a process that apparently took 6 months to complete - before the edition went out by email...

Now, I don't know about you but I reckon the average Information Security professional knows as much about marketing, design, and effective communications as a coffee table knows about the origins of life, the universe and everything. I also reckon that in a multiple choice exam on the subject of global marketing, the answer "d) distribute all content in English-American after being reviewed and amended for audience acceptability by an American lawyer" probably doesn't score you maximum points. You end up with content so dry and devoid of life that it might have fallen from the moon.

The main problem I see is that said newsletter doesn't appear to have a purpose other than to tick a box which says "security awareness campaign." If that's the only goal then consider the box ticked but I doubt it's of much use.

Recent history shows us that the world doesn't end when we introduce change. The people who should feel threatened by the introduction of cloud-based services are those who refuse to adapt and change their mindset.

A colleague and I were yesterday discussing some of the opportunities now available: it's now feasibly possible to open a business and provision all the IT services you need without having to purchase a single piece of hardware: from your laptop computer you can set up your CRM database, develop and host your website on Salesforce.com, produce all your documentation through Google Apps, create server storage space on Amazon's EC2. If you're concerned about spam and URL filtering, have that managed using something like Webroot's Email and Web SaaS. The possibilities are endless - mobile versions of SFDC enable even more flexiblity for the roving sales people. Are the days of the IT department numbered? You join a company, they mail you your laptop, your security token and authentication credentials - and wham, you're part of the organisation. Need to correspond with colleagues: you do it through your organisation's private Facebook Group. Meeting time? There's plenty of video conferencing solutions out there: I found CloudMeeting. Might be worth a try.

There are SaaS payroll services and hosted systems for employees to do their expenses on such as GlobalExpense.

The entrepreneurial CIO is already looking at ways to take advantage of all this. The opportunity to achieve the truly flexible, agile, cheap, manageable, IT infrastructucture has arrived. Is it all secure? I've yet to talk to a CIO who's even considered that question or wants to sully his/her board presentation with anything so mundane.

Like anything else, it's all in the implementation. Choose the right vendors, ask them the right questions, give your employees the right information and there's no reason why working in-the-cloud can't be a magnitude more secure than the way we currently work. Here's my short check list of things for the CIO to consider

1. You can outsource services to the cloud but you can't outsource the responsibility for security. If there's a data breach, it doesn't matter that your service provider might have been negligent, the liability is yours. You must do the proper up front due-diligence.

2. The management processes around assigning and closing user accounts is critical. If you're struggling to get this right now then it's not going to be getting any easier when your services are all externalised.

3. Fast, reliable, high bandwidth connectivity is not ubiquitous. If you're reliant on your sales teams to always be able to connect to their cloud-based service consider that even in the UK you can't always get a decent broadband connection or GPRS signal. Elsewhere the situation may be even more desparate.

4. You can't depend on an SLA guaranteeing up-time as being the foundation of your business continuity plan. Assume that one day the cloud will burst and it might be a while before your service comes back online.

5. I've tried to avoid talking about compliance here because, quite frankly, it all becomes very complex when things move into data centres hosted goodness only where. There's also the case of what happens to the memory space your business utilised when the virtual server space you purchased is no longer required and absorbed back into the cloud. Is your data really gone? How will you know? What about if you're subsequently subpoenaed for information that was virtually stored in the cloud on server space that you no longer own?

6. My completely biased opinion that your information security officer is one of the most important people on your team. Make him/her an ally and use their knowledge about compliance, skills on risk assessment, and the natural tendency that most of us security folk have to ask difficult questions and spell out potential pitfalls.

Dreamforce is the snazzy name for Saleforce.com's annual show-and-tell extravaganza. It's a pretty stylish event too: rock bands, parties, and big theatrical presentations. I didn't go but if you're working for an SFDC customer it's difficult not to get caught up in the hype.

Force.com is the associated development platform. The functionality has now been extended and you can do everything from integrating Salesforce with Facebook to hosting your own websites on the platform itself.

It's exciting stuff and there's no doubt that the PaaS model has real benefits for businesses that more than ever need to be dynamic, flexible, and quick to market with new products. Where's the catch? It's right here: in all the rush to implement products on the platform you probably forgot some basics: namely the fact that utilising cloud-based servcies doesn't dissolve your responsility from doing a proper job of upfront planning and ensuring that applications you're developing for the new platform still follow the basic tenets of application security.

A respected figure within the security industry suggested to me a short while ago that he considers PaaS/SaaS products to still be some way short of being fully enterprise ready. I'm ready to disagree with that opinion. I think that you can begin to put more of your eggs into the PaaS basket but don't get too drawn into thinking about the service providers security at the expense of forgetting to think of your own: are your Force.com developers trained in secure development practices, how resilient is your own connectivity to the remote servcies, in your haste to produce new products after drinking the conference cool-aid, did you do the right upfront planning? 

You've got to get to know the platform first and that means learning much more than what you're going to get from attending the conference.