Obama and Cybersecurity

President Obamas speech regarding the US "Cyber Infrastruture" (delivered on May 29th) makes for interesting reading, primarily since it seems that although the US recognizes the overall importance of the web, convergence and technology etc.. and how they effect the way we work, play and go to war, it would appear that they're really not doing a great deal about it.

I stumbled across this article written by Gene Spafford which breaks the speech down and highlights the inherent flaws in the whole P.R stunt.. couple of the smile crackin' quotes from this review are below:

"...the new position is rather like a glorified cheerleader: there is no authority for budget or policy, and the seniority is such that it may be difficult to get the attention of cabinet secretaries, agency heads and CEOs.."

"...no mention of new resources. In particular, no new resources for educational initiatives or research. We can pump billions of dollars into the bank accounts of greedy financiers on Wall Street, but no significant money is available for cyber security and defense..."

I look forward to seeing how this plays out. Is the Pres' going to actually do something about helping protecting his country (and by implication the rest of the world), or will this present a false sense of security to the masses thereby allowing the criminal elements who hang out in the darker corners of the online world to do their thing unimpeded. More interestingly, I'm curious to see who they get to the fill the roll.

Moving on...

After over 5 years with the Pricewaterhousecoopers, I'm moving on. I joined PwC back in 2004 and have had an asolute blast. I've loved working with some of the smartest folks I've met, and enjoyed both the challenges faced, and the friendships made. I shall miss all of my colleagues, but look forward to my new immensly. I've taken a position with Meyers Norris Penny where I'll be looking to grow the Technical Risk Services function as part of the Enterprise Risk Services practice.

Curtain goes up tomorrow morning, so I shall enjoy my last day before I engage in my new position by getting out in the sun, and embracing all that Toronto's harbourfront has to offer today.

On the tracks..

Living in downtown Toronto, I have the pleasure of avoiding streetcars as they whizz from one place to another. For something that stays on tracks, I frequently find myself crossing a road to find one of the "rockets" bearing down on me and having to leap out of the way.

A couple of months ago, I came out of my condo only to watch a Hummer attempting to make a u-turn across some streetcar tracks. What the driver didnt see, was the 36 tonne (yes.... i looked it up - see here - .. thats how much these things weigh) streetcar merrily trundling towards it. Of course, the inevitable happened.. streetcar and hummer collided..metal crunched.. tempers flared. Everyone was ok, and to my amazement the hummer faired a lot better then the streetcar.

This got me thinking recently about how we work with our people. How, as security professionals, we look to enforce security on the masses. I kinda like the analogy that was forming, so thought I`d jot down my thinking, and some conclusions.

Thinking about what happened above, lets line up the factors involved with a corporate environment:

1. City = Business Environment

2. Road = Policy

3. Streetcar & Vehicle = End point devices (desktops, laptops, etc.. etc..)

4. Tramlines = Security guidelines

5. Users = Commuters

We, as security people, would like to see all of our users (commuters) using end point devices (streetcars) and being taken from one place to another using pre-defined routes under the control of one centralized system. We`d have the controls in place that keep the users in line; we`d let them know that when they use their pc`s what the risks are (security awareness education), how best to behave for their own safety and that of their fellow users. Most users would be happy to do this since why would they bother going through the trouble of doing things themselves (like driving), when they can be transported on their business journey and protected care of the city (infrastructure). All they have to do is follow some basic rules and they'll get what where they're going in a relatively safety. The only downside for them is that they are at the mercy of the city as to what they'll see along the way, and when they're going to get to where they'e going.

Simple, safe, and relatively cost effective. The city itself keeps things flowing, and the commuters are happy unless something breaks and they have to walk!

Onto our hummer driving friend. He (we'll assume he is a "he", since I don't know many woman that drive hummers) He is part of the city, he's going to use the road to get where he's going and, for most part, is going to take the same route as his fellow users. The key difference here is that he's not going to be constricted by the tramlines. He'll be able to stop anywhere he likes, and sometimes head off road and take a look around at his leisure. He'll not have to abide by the same restrictions that apply since he really doesnt have to stick to the tramlines or the direction in which they go.

A user like this in an actual business environment is what we typically categorize as a rogue user. These are the ladies and gentleman that can cause us, the businesses, and their fellow users the biggest headaches. They have the knowledge to navigate the infrastructure without having to follow the same line as everyone else, and can be horribly disruptive when not paying attention to exactly what they're doing.

So, what's the moral of this quickly constructed caffeine fueled bit of thinking?... Keeping users on a constrained and defined path is still the best where to protect your information assets, but when designing and building an infrastructure, make sure you do so expecting that there will be the odd user that knows how to swing off the rails and try to do their own thing.

People and Process...technology just doesn't do it any more.

"Security is something we should consider once we are in the detailed design phase of the project".

This is something that I heard in a meeting a while ago. My immediate response was to politely slap the guy that said it but then realised that my income would be questionable if I did that, so I let him continue....

"We don't need to formulate detailed security requirements at this stage..." (I should point out that they were planning to be designing the functional requirements for the solution in question for over a year) "...since these will come out of any risk assessments we do"

Let me understand this (I thought), this company has spent several $millions coming up with the solution, invested in resources, and only now are thinking about security. Combine that and the fact that no risk assessments had been done...at all... no really.. I'm not making this up.

It made me think, I've been in security for around 20 years, specifically information security for about 13. I appreciate that when I started out, security was the thing that got in the way of functionality. It was a pain, it was expensive and it was tricky to implement without making the user experience a complete nightmare.

What's changed? Well, the key is the thinking. A lot of businesses still think in terms of technology. Buying a firewall, AV, IPS/IDS and "hardening" systems is all good and well, but placing sole reliance on these to protect corporate assets? I think not. The need to get the business to understand security is the way to go; and by business I mean the suits with the executive bathrooms. These guys and girls are now responsible for protecting assetts (SoX anyone?), yet they have trouble understanding this sometimes. So how can we help them sleep easy at night. Here's my take on a couple of areas...

1) People - aka Layer 8 (geek joke.. look it up!).

Since security is generally getting better, we need to convince firms that their people need to be more aware of security risks and how to act and react in the face of these. Social engineering is a good example and it is a nightmare to train people to identify. Since the users have access to the assets we are trying to protect (the data), the easiest way to get to it is not to launch a complex technical attack against the systems, but to launch a simple dumb attack against the users.

Many moons ago I used to do physical penetration testing (can I get in the building and get to the server room etc...) and as part of that did social engineering. 9 times out of 10, I would get the data I needed. I did it with banks ( and got them to read bank statements over the telephone to me), did it with medical facilities (medical records anyone?), even did it military facilities (you don't want to know). The problem was always the same... People like to be helpful and want an easy life. If they can help me with my problem, it makes them feel good about themselves.

A small test for you if you're reading this in your office. If you have an area that is secure and you shouldn't go in (think swipe card, keypad etc..), I challenge you to stand outside the door with a cup of coffee in each hand and a mobile phone clamped between to your ear and your shoulder pretending to talk (hint - turn the phone off first.. really embarrassing if it rings when you do this!). I will guarantee that a majority of the time someone with legitamate access will stroll up, see you in your predicament and offer to hold the door open for you. NOTE - I don't condone this, I'm not responsible if you get fired doing this and I will not refund money invested for coffee. NOTE 2 - Doing this when there are armed guards on either side of said door is dumb!

Summary...educate staff. They need to be part of the security process. In fact, they need to be a major part since if they can be educated correctly, they can extend your security perimeter dramatically. Effectively you can create a human IDS - one that can determine the threat, analyze the risk and prioritize the escalation path.

2) Process

OK, so we've got the people sorted out. They've brought into the security idea and are raring to get out there into the workplace and become foot soldiers of the C.I.S.O. Now we need to do some things to baseline the security and build some rules for monitoring the environment and updating our overall security to adjust to threats.This really is not rocket science (aside - have you ever wondered what rocket scientists say in place of that phrase? Me too!). Here are some things to be done:

• Risk Assessment: A process to identify threats, vulnerabilities, attacks, probabilities of occurrence, and outcomes.
  
• Information Security Strategy: A plan to mitigate risk that integrates technology, policies, procedures and training. The plan should be reviewed and approved by the board of directors.
  
• Security Controls Implementation: The acquisition and operation of technology, the specific assignment of duties and responsibilities to managers and staff, the deployment of risk-appropriate controls, and assurance that management and staff understand their responsibilities and have the knowledge, skills, and motivation necessary to fulfill their duties (back to the people again!!)
  
• Security Testing: The use of various methodologies to gain assurance that risks are appropriately assessed and mitigated. These testing methodologies should verify that significant controls are effective and performing as intended.
  
• Monitoring and Updating: The process of continuously gathering and analyzing information regarding new threats and vulnerabilities, actual attacks on the institution or others combined with the effectiveness of the existing security controls. This information is used to update the risk assessment, strategy, and controls. Monitoring and updating makes the process continuous instead of a one-time event.

These are processes. Doing them will go some way to helping the business become and stay secure. Thing is - going back to my original point - do not wait until you are midway through a multi-million refit / project / installation before thinking about these. This will add to timelines and invariably cost the business a lot of cash later on in the project.

Oh yeah, and the firewalls and other stuff... they're still there under the banner of security controls implementation. So all of you Checkpoint people can now relax.

Here endeth the ranting….