Monthly Archives: April 2013

Federal court rules SMB — not bank — liable for loss from online theft

Even though Uniform Commercial Code places loss risk with banks for unauthorized transfers, a Federal court ruled against an SMB in Missouri last month and with the larger bank — primarily because the SMB did not implement fraud prevention controls offered by the bank.  This resulted in a $440,000 loss for the SMB.  Here’s the nutshell version:

  1. SMB has business account with bank
  2. Bank offers security (fraud prevention) controls for SMB
  3. SMB declines to implement controls (twice)
  4. SMB computer hacked & SMB’s credentials used to transfer money from its bank to Cyprus bank
  5. SMB sues bank for loss stemming from stolen funds
  6. Federal court rules against SMB and with bank
  7. SMB out $440,000 plus legal expenses

If this indeed sets precedent, this further increases SMB business risk.

Some lessons learned:

  • If your bank offers recommended security services or tools, use them (unless you can show that this directly and materially negatively impacts your business)
  • Use Positive Pay where list of authorized checks are provided to the bank via separate channel (i.e. bank has to cross check against that list prior to paying checks/requests presented to them)
  • Use a dedicated computer for banking transactions
  • Use two-factor authentication where possible
  • If not using Positive Pay or similar service, establish criteria with your bank for when they should alert you that a check or transfer request seems unusual

 More here in this Dark Reading story.

Risk Managing Residual Old-School Devices

I’ve encountered this risk discussed in this Forbes article more than once when taking over an organization and doing an initial information risk assessment.  People tend to forget that these embedded devices can have simple or full fledged Linux distributions (or other OS) in the firmware.  Also, the default ports that were left open can be eye opening.

An image from H.D. Moore's presentation on serial server security vulnerabilities, showing an oil and gas infrastructure setup networked with serial port connections. (via Forbes.com)

An image from H.D. Moore’s presentation on serial server security vulnerabilities, showing an oil and gas infrastructure setup networked with serial port connections. (via Forbes.com)

Researcher’s Serial Port Scans Find More Than 100,000 Hackable Devices, Including Traffic Lights And Fuel Pumps

Risk Mapping: Determining Impact & Probability in the movie Aliens

In describing the Alien threat that they (Ripley and the tactical team) are facing as the evening wears on, the young female protagonist, Newt,  states:

“They mostly come out at night. Mostly.”

When Ripley tries to assuage her by sharing that there are armed soldiers to protect her, Newt states:

“It won’t make any difference”

Newt and Ripley

Newt and Ripley

Analysis: 

Let’s define this particular Risk Register item “Alien attack at night”

We have it from a first-hand observer of multiple instances of Alien attack, Newt, that they mostly come out at night. (Mostly).  If we’re using Low, Medium, & High to represent probabilities  0 < p < 33%, 33% < p < 67%, 67% < p < 100%, respectively, then I think we can safely convert these observations to High likelihood of Alien attack at night.

We have direct observations of destruction and further interviewing of a first hand observer who shares that having several well-armed soldiers in place “won’t make any difference”.  Given this information and defining Impact as Low = no fatalities/minor injuries, Medium = 1 to 3 fatalities (or capture with subsequent implantation & cocooning) & severe injuries , and High = greater than 3 fatalities (or capture w/subsequent implantation & cocooning) & very severe injuries (that includes Alien acid-blood burns), I believe that we can call this a High Impact.

If Hudson were keeping his Risk Register current, I think he could reasonably update with:

        • Risk Description: Alien attack @ night
      • Probability: High
      • Impact: High

 

How would you assess this situation?

Verizon Data Breach Study & SMB Factors

Verizon just released their 2013 Data Breach Investigations Report (DBIR).  It draws data from work done by several law enforcement agencies, incident-reporting groups, research institutions, and private security firms. It studies over 2,500 confirmed data breaches (representing more than 1 billion records).

Some observations from the report for all company sizes:

  • 75% of attacks were opportunistic, ie a specific company or individual was not directly targeted
  • Attackers consisted of activists, criminals, & spies
  • Of the cases of insider sabotage, 50% came from old accounts or back doors that had not been disabled
  • The vast majority of attacks (68%) were considered “Low” difficulty (meaning basic attack methods with little or no customization required)
  •  ‘Unapproved’ hardware accounted for 41% of misuse
  • It is taking longer to discover breaches, up 10% from 2012.  This means that the bad guy can operate at will for longer periods of time.

Some observations for small and medium sized businesses (employee count < 1000):

  • In companies less than 100 in size, retail had an exceptionally large exposure, followed by food services companies
  • 57% of attacks were from organized crime and 20% were state-affiliated
  • 72% of attacks were from hacking, 54% from malware, and 32% from social media
  • In 86% of the attacks, spyware or keyloggers were installed as a part of the attack
  • SMB’s are at higher risk for ransomware schemes
  • Desktop sharing was primary attack vector for hacking attacks for SMB’s
  • Email was primary vector for social attacks
  • Unapproved hardware contributed to misuse in 52% of cases in small & medium sized companies (compared with only 22% of large companies)
  • Point of Sale devices most often attacked information asset for SMB’s

2013 Data Breach Investigations Report

Executive Summary

 

 

Communicate risk in a single page (the first time)

One of the most challenging aspects of work for an IT or information management professional is to communicate risk.  If you are in a resource-constrained business, e.g. small and medium size businesses (SMB), that hasn’t analyzed information risk before, consider communicating it the first time in a single page.

The reason for a single page communication is that risk can be so complicated and obscure and IT technologies, concepts, and vocabulary can also be complicated and obscure that the combination of both can go well beyond mystifying to an audience not familiar with either or both (which is most people).

A few years ago I was in a position to try to communicate information risk to a number of highly educated, highly accomplished, and high performing professionals with strong opinions (doctors).  I only had a tiny sliver of time and attention for them to listen to my pitch on the information risk in their work environment.  If I tried some sort of multi-page analysis and long presentation, I would have been able to hear the ‘clunk’ as their eyes rolled back in their heads.

Clearly, there was no lack of intellectual capacity for this group, but there was a lack of available bandwidth for this topic and I had to optimize the small amount that I could get.

After several iterations and some informal trials (which largely consisted of me pitching the current iteration of my information risk presentation while walking with a doc in the hall on the way to the operating room), I came up with my single page approach.  It consists of three components:

  • (truncated) risk register 
  • simple heat map
  • 2 – 3 mitigation tasks or objectives
Single Page Risk Plan Communication

Communicate risk in a single page (click to enlarge)

I put the attention-getting colorful heat map in the upper left hand corner, the risk register in the upper right, and a proposed simple mitigation plan at the bottom of the page.

This ended up being pretty successful.  I actually managed to engage them for 5 – 10 minutes (which is a relatively large amount of time for them) and get them thinking about information risk in their environment.

To communicate risk in a single page, I am choosing to leave information out.  This can tend to go against our nature in wanting to be very detailed, comprehensive, and thorough in everything that we do.  However, that level of detail will actually impede communication.  And I need to communicate risk.  By leaving information out, I actually increase the communication that occurs.

Also, notice in the Proposed Mitigation section, I am not proposing to solve everything in the register.  I am proposing to solve things that are important and feasible in a given time frame (three months in this case).

In three, six, or nine months, we can come back with a new presentation that includes results from the proposed mitigation in this presentation.

Notice that I put “Sensitive” in a couple of places on the document to try to remind people that we don’t want to share our weak spots with the world.

If at some point, your company leadership or other stakeholders want more detail, that’s fine.  If they ask for it, they are much more likely to be able and willing to consume it.

To communicate risk, start simple.  If they want more, you’ll be ready by being able to use your working risk register as a source.  I’ll be willing to be bet, though, that most will be happy with a single page.

 

Have you presented information risk to your constituents before? What techniques did you use?  How did it go?

Password management in small & medium sized businesses

Poor password policies and management can be an Achilles heal for any business.  Making it more challenging for small and medium sized businesses is that they often cannot afford to implement or support full Identify Access Management systems.  There is, however, some middle ground.

Impact vs Probability

Climbing aboard the helicopter for a training flight one evening was probably the first time that I thought about the difference between probability and impact as components of risk.   For whatever reason, I remember looking at the tail rotor gearbox that particular evening and thinking, “What if that fails? There aren’t a lot of options.”

Tail rotor failures in helicopters are not good.  The tail rotor is what provides the counterbalance for the torque generated by the main rotor that generates all of the lift.  It’s what keeps the fuselage of the helicopter from spinning in the opposite direction of the main rotor in flight.  If the tail rotor fails in some way, not only are you no longer in controlled flight (because the fuselage wants to spin around in circles), but the emergency procedures (EP’s) are pretty drastic and probably won’t help much.

helo1riskslide

tail rotor gearbox

So I found myself thinking, “Why in the world would I (or anyone) climb on board when something so catastrophic could happen?”  And then the answer hit me, “because it probably won’t fail.”  That is, the impact of the event is very bad, but the probability of it happening is low. This particular possibility represented the extremes — very high impact and generally low probability.

helo2riskslide

nose gear

But there are possibilities in between also.  For example, what if the nose gear gets stuck and won’t come back down when I want to land.  While not desirable, it’s certainly not as bad as the tail rotor failing.  I could come back and land/hover and keep the nose gear off the deck while someone comes out and tried to pull it down.  Or they could put something underneath the nose of the helicopter (like a stack of wooden pallets) and set it down on that. While not a high likelihood of occurrence, a stuck nose gear happens more often than a tail rotor failure, so let’s call it a medium probability for the sake of argument.

While the impact of the stuck-nose-gear-event is much less than that of the tail rotor failure, the potential impact is not trivial because recovery from it requires extra people on the ground that are placed in harm’s way. So maybe this is a medium impact event.

helo3riskslide

multiple components/multiple systems

Similarly, what if the main gear box overheats or has other problems? Or other systems have abnormalities, problems or failures? What are the probabilities and impacts of each of these?

There are multiple pieces to the puzzle and each piece needs to be considered in terms of both impact and likelihood.  Even as commercial airline passengers,

If we based our decision to fly purely on an analysis of the impact of an adverse event (crash), few people would ever fly.

We do board the plane, though,  because we know or believe that the probability of that particular plane crashing is low.  So, in making our decision to fly, we consider two components of risk: the probability of a mishap and the impact of a mishap.

We have the same kind of thing in managing risk for IT and Information Management services.  We have many interconnected and complex systems and each has components with various probabilities of failure and resulting impacts from failure.

itimriskslide

multiple components and multiple systems in IT & Information Management systems as well

 What if I’m working in a healthcare environment and users store Protected Health Information (PHI) on a cloud service with a shared user name and password and PHI leaks out into the wild?  This might have risk components of: Probability — High.  Impact — Medium to High, depending on size of leak.  What about laptop theft or loss containing PHI? Same for USB thumb drives.  What is the probability? What is the impact? What about malware infestation of workstations on your network because of lack of configuration standards on BYOD devices? What is the likelihood?  What is the impact?

It’s possible that our server or data center could be hit with an asteroid.  The impact would be very high.  Maybe there are multiple asteroids that hit our failover servers and redundant data centers also !  That would surely shut us down.  But does that mean that we should divert our limited business funds to put our server in an underground bunker?  Probably not — because the likelihood of server failure due to asteroid impact is very low.

As with flying, when we analyze risks  in IT and Information Management operations, we have to dissect and review the events in terms of their respective impacts and probabilities.  Only when we have these two components, impact vs probability, can we start to do meaningful analysis and planning.

 

What are events do you plan for that have Low Probabilities but High Impacts?  What about High Probabilities but Low Impacts?