About Us  | Contact Us

Archive for the ‘Continuity/DR’ Category

Complacency in the Cloud

I don’t like the fact that I have a trust issue.  I wish I could change — but I can’t.  Oops sorry folks, I thought I was in my therapist’s office.

Last week’s issues with LastPass (LP), read here, should make me want to flame them to crispy pieces.  Alas, I have no one to blame but myself.  Unlike my other overdone, paranoid-driven steps to protect myself, I was not properly prepared for this outage.  The result:  I was completely locked out of several of my business accounts where I solely rely on LP for authentication.   LastPass is a password manager that stores passwords so you don’t have to remember them.

This outage got me thinking.  Are we getting too complacent with cloud services in our business and personal lives?

Sure, there were contingencies I could have put in place.  For instance, did I download pocket LastPass (the version where you can access your secure notes and passwords without having to rely on the internet)?  “No”.  Did I export my LP data to a file and encrypt it?  “Ah, no”.  (Imagine head banging against wall here).

I’ve always been careful to backup my business and personal data.  I have a 1TB Firewire encrypted drive that I use to backup my PCs.  In addition I utilize Dropbox as my file system, storing these files locally AND in the cloud.  I also backup my critical business files into the cloud, periodically zipping and exporting both folders and Outlook data to Carbonite.  Way over the top?  Why yes, of course.  But that is just me.  Do you think I would follow the same paradigm with *ALL* of my authentication information for my most critical access needs?

Now why did LP cut me off like a rich father cutting off his deadbeat son?  Because they experienced an “anomaly” on their network.  Learning from their past, they promptly and proactively set up safeguards, which unfortunately left many — including myself — unable access our passwords.  Let this be a lesson to all, there is no safe haven, even in the Cloud.

Build your own safeguards, controls and processes into your cloud strategy for your business and don’t be complacent.

- Jay Martin (jay.martin@cppit.com)

Leave a Comment

What I Learned From Getting Hacked

In CPP’s June Podcast, we discussed a security breach that occurred a few years ago and the steps my team took to detect, respond and remediate the incident.  Here are the five things I learned from that breach.

1).  Planning your response to a disaster or security incident is just as important as the safeguards you put in place
You cannot protect against everything.  The following often delays or prohibits putting the necessary mitigation plans and preventative controls in place:
   -  Residual risk that remains based upon your organization’s tolerance or risk appetite
   -  The cost of mitigating risks and putting necessary controls in place to thwart threats & vulnerabilities
   -  Business strategies and priorities that conflict with your security program
   -  Zero day threats and vulnerabilities
If you agree with at least one of the bullets above, then it is of the upmost importance to have Incident Response Plans and Response Teams in place that you can trust.
2).  Select a team or teams you can trust
Tough times don’t last, tough people do.  Choosing people for your Emergency Response and Incident Response teams should be done on a selective basis.  Having the right people on call at the right time may save your organization from further loss.  Creative people that can think clearly in stressful situations can make all the difference between ending up in the headlines or heading the bad guys off at the pass.
3).  Store your Incident Plans in plain sight (and at multiple sites)
When an incident or disaster occurs you don’t want to leave your response to chance — even if you have selected a great team.  Know exactly where your Continuity, DR and Incident Response Plans are located.   This is achieved through constant awareness and possibly automation.  Both electronic and paper documents should exist in multiple locations.
4).  Monitor, Monitor, Monitor
Our security breach was discovered by a higher-than-normal CPU event that triggered an automated alert to our Service Desk.  Good processes and disciplines (automated and otherwise) must take over from there.  Monitoring for anomalies on your servers, network devices, databases and applications are an important first step in addition to the traditional security monitoring (IDS/IPS, Anti-virus, logging, etc.). 
5).  Embed good processes and practices such as ITIL into your organization’s daily life
I brought ITIL into my previous employer’s organization in 1999.  Good Event, Incident and Problem Management disciplines were vital in detection, notification, “root cause” and escalation of the attack.  Change/Configuration and Release Management disciplines were significant in quickly correcting the incident, the underlying problem and putting the necessary corrective, compensatory and deterrent controls in place.

Comments are welcome.
Jay Martin
jay.martin@cppit.com

Leave a Comment