Security Inside The Perimeter

A key in a keyboard lock

One of the issues that was being discussed at this past Oracle Open World 2012 was the importance of considering security during the design stage of a system development effort.  Technology journalist Michael Lee wrote about this issue last fall in a piece titled Developers ignore their security responsibilities: Oracle.  In it, Lee addressed the observations of Oracle Chief Security Officer Mary Ann Davidson:

Marines don’t consider perimeters to be completely unbreachable, and hence, need to be prepared to defend themselves from attack from the inside … Davidson said that many organisations still assumed that attackers won’t get inside their perimeter … [1]

Davidson is totally right, but it is starting to change.  An increasing number of the customers I work with are starting to operate on the assumption that security perimeters will be breached.  Security measures are no longer limited to protection at the perimeter.

This is one place where analytics can play a role.  I’m not just talking about security information and event management (SIEM).  Through data collection and pattern analysis, an alert system can proactively monitor for aberrations in the data flows and process flows within a system, and can help identify probabilities of a possible intrusion and take actions accordingly. But the point is that most security starts with a healthy dose of common sense, applied at all levels of a system’s operational capabilities.

I live in the suburbs of Washington, DC, but recently attended an NFL football game in Philadelphia, and afterwards was having dinner in downtown Philly, when I received a call on my mobile phone from Visa.  They said it was a courtesy call regarding my credit card, and offered some proof of who they were and how they knew my account, and then asked a few questions to confirm who I was.  The exchange was professional and left me confident of the authenticity of the call.  They then asked if they could review a few recent purchase requests on my credit card, and I said – sure.  Sitting there in the restaurant, I listened as they asked me if I had authorized a purchase of gasoline in Pennsylvania that morning?  I said well yes, as a matter of fact, and feeling comfortable that they were who they said they were, I offered that I was heading to the Redskins-Eagles game that day, and was intending to use the same card to pay for the dinner I was eating as they were speaking to me.

They then asked if I’d attempted to purchase a washing machine at a Target department store in Washington, DC on that same afternoon.

I said – uh – no.  I was sitting in the Eagles stadium in Philadelphia about that time.

What about a refrigerator at a second location, also in DC?

Definitely not.

They then said well, you probably didn’t authorize these additional six or seven attempts to purchase large appliances at five different department stores in Washington, DC this afternoon, if you’re in Philly at a football game.  I said – no, not at all.

Thank you, they said, we rejected all of those attempts and just wanted to confirm we did the right thing.  And should you use the card to purchase your dinner tonight, it will be approved with no problem.  But we’re going to cancel this number and issue a new credit card to you, you’ll not be charged.

I said – thank you.

I enjoyed the rest of dinner, paid for it with no trouble, and two days later I had my new credit card with the new number.  I was never charged anything inaccurate or fraudulent.  It all worked out remarkably well.

To help put the incident in perspective, I had the correct physical credit card with me at all times, and the would-be scammer did not, but whoever it was had my credit card number, and he or she was attempting to use the number alone – without the card – to make these purchases.  Visa rejected them all, and according to what they told me, it was in large part due to the fact that the purchases conflicted with my patterns.  Also, this all happened right before Visa began issuing cards with an additional numeric code printed on the back of the card.  That started immediately after these events, so it didn’t apply to these circumstances.

At the end of the day, security is not only about the latest technological breakthrough.  It’s about a combination of two things:

  • A sound understanding of the how the fundamentals of technology operate
  • A common sense approach to defense against classic con games

Any system developer must keep these concepts in mind, and recognize them in securing perimeters, and in developing a solid plan of defense for those times when perimeters are broken.  Perimeters will be broken.  The only question is:  how will you respond?

Footnotes

[1] http://www.zdnet.com/developers-ignore-their-security-responsibilities-oracle-7000005808/