Our IT Security Duty


There have been a number of security … questions/concerns … that I have had recently that have caused me to initiate different actions.  I won’t go into details about the specific items other than to say that it caused me to look at a bunch of different sites that I thought you might be interested in:

  • Information Is Beautiful.  To be precise, the page showing the World’s Biggest Data Breaches.  It’s fascinating to go trolling around and looking at all of the breaches that have occurred and dig down into some of the details.  The recent Equifax debacle is just a small incident when you take a look at the scale of some of the breaches that have occurred.  I’m just glad that we’re not on the list.
  • Vigilante.pw.  These guys are tryuing to raise awareness of database breaches by publicizing the breach.  In particular they point out the type of encryption used for the passwords, if passwords were indeed compromised.
  • Data Breach Today. Essentially a news site.  When writing this the latest story is about how the Equifax breach may have actually started in the March time frame, instead of in May as Equifax has stated.

Reading through some of the attached stories gives me the chills.  For instance:

In a report released earlier this year, FireEye said it found that, on average, a breached organization takes 100 days to discover that it’s been breached. In Equifax’s case, however, the company took 141 days.

On average it takes 100 days.  A lot of damage can be done in 100 days.  Let’s assume for a moment that hackers are able to VPN into a network due to some compromised credentials.  (I’ve had multiple attempts to hack my account in the past week alone so this doesn’t seem beyond the realm of possibility.)  Now that they are on the network what do they do?  Well, you’ve got, on average, 100 days to fortify your position and steal data.  Whose credentials were compromised?  Let’s assume that it is someone innocuous, a developer who does not have any access to production.  We’re safe, right?

Not in the least.

Just because someone doesn’t have access to production doesn’t mean that they don’t have access to production data.  People take production data into other environments all the time.  So now we’ve got developer credentials that have access to production data, albeit in a non-production environment.

Other scenarios include the hacking being an inside job.  A 2016 IBM X-Force Cyber Security Intelligence Index report stated that 60% of all attacks were done by insiders.  (This also includes people duped by a phishing scam.)  An insider is actually a bigger threat.  They know the rules, they know the loopholes, they know the weaknesses in the system.

Vigilance is key.  And while the security courses from employers provide a good basis for much of what we need to do, because IT people handle the data on a day to day basis our responsibility is increased.

“With great power comes great responsibility.” – Ben Parker

Developers have great power and with that power comes the responsibility to mitigate the risk.  If you are responsible for maintaining a database in a development environment, make sure that it is not open to public.  Make sure that you don’t send screenshots of production data to people how should never have access to that data.

100 days.  That’s a long time, but by following proper security protocols it won’t be long enough for any potential hacker.

Leave a Reply