Archive - April, 2010

On the lookout for attacks

After school, my first employment opportunity came in the financial services industry.  I worked for a bank and was initially responsible for a group of firewalls that separated the Internet from the internal bank network.  It was a little more complicated than I am describing as there were technically several networks with different ‘trust levels’ and the firewalls deployed policy in an attempt to enforce these levels of trust.  Aside from my role of ensuring the policy accurately reflected the business requirements, I spent time ‘looking’ for anomalies, potential attacks or issues.  This work involved writing lots of Perl scripts to parse and correlate logs, analyzing packet captures, running vulnerability and penetration tests and the other typical functions a security analyst performs.   While it sounds very proactive, the amount of actual proactive work was in reality minimal.   You get bogged down with other projects, meetings, lack of resources, a deadline here or a emergency there.  I eventually switched to a different team that designed the networks and security.  My new manager who till this day I have the utmost respect for and who is now retired wanted to have myself and another individual be given permission to spend a week or so of dedicated time to snoop around the network, servers, and systems.  We would attempt to gather what information we could obtain authorized or not. We would be given free rein to see what we could gather.  The only restrictions were no DoS attacks or causing outages and we were to remain stealth.  We would put all this information in a confidential report for management.  He presented this, but was told no.  I was very disappointed.  The project sounded very exciting and fun and I was so looking forward to it.  My manager was disappointed as well, although he said he expected that response and shared with me why that decision was made.  He is a very smart man and was ahead of his time.

Over the Easter weekend, I had the opportunity to speak to a friend who has worked for the federal government for over 30 years.  My friend was telling me about a security team who’s  sole responsibility is to be proactive.  This team searches the network looking for vulnerabilities or attacks that are in progress, usually under the radar using a variety of open source and other tools.  My friend was very positive about them, indicating the team has done really good work and produced excellent results.  I was happy to hear that a large organization such as the federal government had a full time team dedicated to this purpose.

In my years consulting for many different industries both large and small, I have seen a very obvious increase in proactive security monitoring, analysis, and investigation.  Most financial industries have teams in place today as well as other large organizations.  Unfortunately, in some cases, these teams are not dedicated full time, rather it is one part of their many responsibilities.  In my opinion, this is where a mistake is being made and the effectiveness of having proactive security teams starts to be a problem.

One of the biggest reasons that proactive security analysis teams are not present, or only part-time is cost and lack of measurable valid metrics.  How do you measure the effectiveness?  It is possible the team might go for weeks, not finding any big vulnerabilities.  Maybe there are not currently any attacks present on the network.  Maybe there are active attacks, but they are currently not looking in the right places?  Maybe they don’t have the expertise required to see the attack in progress?   From a financial perspective, one sees large sums of money for the team of experts and you may or may not get tangible results.  It is a tough justification.  If money gets tight within the organization, this problem often worsens.  Research often falls into very similar circumstances.  There is an intrinsic value to having these types of teams, but how does one represent that financially?  I haven’t figured out an answer to this yet.

For industries that provide infrastructure or financial services, or deal with data that is sensitive, I believe that regulation from government is necessary for this type of activity to be provided with guarantees.  I think as a society we will eventually get there, but it will be a long battle with industries pushing back indicating that they can self-regulate.  Given the types of attacks that are now prevalent, proactive analysis with expert people is absolutely necessary.

If you ask any organization large or small they will all state they take information security very seriously.  But would you expect a different answer?  I have spent the last 8 years consulting, and this has given me an insight into those statements.  In my experience, the reality of those statements contain quite a bit of variance.  From my Consulting engagements in many different parts of the world, I find that this is somewhat geographically based.  If you head over to the middle east for example, I have found that proactive security is present in many organizations and it is not new.  The attitude is different as well.  Proactive security is expected, from senior management down and if you mention the idea of not having it, the reaction is to look at you as if you are nuts and in most cases that reaction is a truthful one,

How serious is your organization about security?  Do there actions match their statements or are they just words?

A GM Equinox, end user experience and security

We own a 2007 Equinox built by General Motors.  Besides being a little heavy on gas usage by today’s standards, it is a good vehicle.  It is comfortable, handles well in winter, has plenty of room.  I have never been a fan of North American vehicles.  I personally tend to favour Acura, Audi, and Mazda, but the Equinox at least got me feeling better about GM vehicles.  Then I had to change the headlight.

The passenger headlight was no longer working.  When I went in to get the oil changed, one of the technicians informed me that it was out.  I asked if they changed light bulbs.  He said they do, but not on this vehicle as they did not stock the bulb.  What he said made sense and I knew he wasn’t lying, but something about the way he said it bothered me.  A couple days later, my Mazda was at Canadian Tire getting the brakes done and the summer tires put on.  I asked the mechanic if they could replace a light bulb on a 2007 Equinox.  He said they could but it would be at least an hour in labor charges.   How hard could this be I thought to myself?  So I purchased the light bulb for $10.00 and thought I could put it in myself.  The manual had a single page with 3 diagrams and 4 steps each a single sentence.  With instruction manual, light bulb and required tools I was Clear to go …. or so I thought.

In order to get at the light bulb to change it, I had to remove 11 screws, one of which is way down through a tiny hole that you can barely get your arm in, let alone the ratchet tool needed to undo it. The first 8 screws loosen the front grill, so you can bend it back, so you can get at the light.  You have to loosen and pull the light unit out to replace the bulbs.  The actual bulb replacement was easy, took 2 minutes.  Then you get to put everything back together.  Needless to say I was happy I accomplished it, but frustrated it was so much work.  I now understand why mechanics charge an hour of labour to replace a headlight.

I think something went wrong during the design of the Equinox, they lost the perspective of the end user.  I expect to have to do certain tasks to maintain my vehicle in good working condition.  The end user will have to put gas in it, check the oil level, check the washer level, check the tire pressure, change light bulbs. When designing a vehicle these things should be easy to do.  Removal of an entire front grill, reaching to find screws in small confined places to remove a headlight assembly are just silly.  Where was the person that during the design process said “Wait a moment.  The end user will not be able to replace a burnt out light easily. We need to re-think this.”?

This whole situation reminds me of the security industry I am a part of.  So many of us are paranoid, constantly trying to ‘lock’ things down, create multiple steps that a user has to go through to get access or maintain access to networks and data, often to the point of inconvenience and annoyance.  One of my first managers, now retired constantly complained about this type of behaviour.  He was a very smart person and I learned a lot from him technically.  I also learned a lot from him about large financial institutions and people.  One example was the password requirements.  It was required that every 3 or 4 weeks, you had to change your password.  The password had to have so many characters, including a numerical as well as a ‘symbol’ character or two.  He kept changing between two passwords.  Then someone in security got the brilliant idea that in order to increase security, they would remember the last 30 passwords so that users would be forced to create new ones.  That would increase security right?  He was so annoyed that he changed his two passwords to a single password with the month and year on the end.  Every time he needed a new password he would simply change the month and year.  Problem solved.  It was unique and predictable.

If we are designing vehicles, applications, network security, or procedures it is important to include in the design the answers to typical human behaviour.  How will end users will respond and react to design decisions?  Is this response what we wish?  What ways could it be mis-used?  If you are not satisfied with the answers, you should re-consider the design.  In the case of security, it is important to accurately assess what you are protecting and design security accordingly.  By attempting to enforce more security than is necessary, you may actually increase and not decrease the risk of what you are trying to protect.

One thing for sure, the next time I purchase vehicle, I will be checking how much work it is to change a headlight.