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)

I was semi-impressed yesterday when I visited a global retail chain, signed up for a new credit card and they handed me back the application form for me to destroy.  Retail stores that manage payment card information must abide by strict rules governed by PCI — the Payment Card Industry standard developed to protect card information.

The form that I filled out had Personal Information (PI) and not payment card information, so therefore would not fall under the PCI purview.

I asked the retail clerk processing my information what would happened if I left the form behind – in an attempt to better understand the security process.  The retail clerk told me that they place remaining forms in the bin behind her and that a disposition company destroys everything in the bin.  They receive a certificate from the said company once the data is destroyed for proof.

Good start.  The company could have taken this protection process a step further by having a more secure bin with a cover and a lock instead of using a standard looking waste paper basket.  Still, one giant leap for better InfoSec Data Protection.

201 CMR is here to stay, at least until H.R. 2221 gets passed

How is your company doing so far with meeting the Massachusetts regulation for the protection for PI?  If you are outside the Commonwealth and do not store Mass. residence PI, are you doing anything to protect your state’s residents PI?

jay.martin@cppit.com – ITIL, CISM, ISMAS – www.cppit.com

I mentioned in my blog in late November that the cost to Health Net over loss of an unencrypted hard drive containing 450,000 patient records (revised down from 1.5m) would be much greater than the cost of securely controlling and protecting their information assets. Health Net will begin the process of emptying their wallets in an effort to build a defense against the lawsuit levied against them by Attorney General Richard Blumenthal.

The breach occurred in May of 2009 and was not reported until November. As discussed, Connecticut’s breach notification law are fairly strict and I would assume holding off reporting such an incident for 5+ months is over the top which could cause Blumenthal to make Health Net an example for all to see. To add fuel to the fire, the American Recovery and Reinvestment Act of 2009 (also known as the HITECH act) also imposes notification mandates that were apparently neglected. See my November blog post under security entitled “Health Net Breach — A Failure of People, Process & Technology” for more details.

jay.martin@cppit.com

CISM, ISMAS

www.cppit.com

The national Data Accountability and Trust Act, H.R. 2221 passed within the House of Representatives earlier this month (Dec. 8th, 2009).  The Bill — as with 201 CMR 17.00, the Massachusetts Protection for Personal Information — seeks to protect consumer personal information and requires notification to individuals in the event of a breach, albeit from a national level.  The bill is set to go before the Senate next and then the President.

H.R. 2221 would require “for profit” organizations to develop the necessary security policies and safeguards to protect U.S. Residence personal information within 1 year of passing.

More to come later…

jay.martin@cppit.com

CISM, ISMAS

www.cppit.com

 A huge chink in the armor of end-to-end encryption took a big hit last week when the US-CERT reported that a man-in-the-middle exploit code against SSL and TLS is publicly available.   The exploit allows a malicious attacker to insert themselves into an SSL or TLS conversation during a client or server initiated renegotiation of their security context.  The vulnerability affects pretty much every site we securely connect with including our online banking sites, paypal, etc.  It also affects all operating systems and browsers.

Updates are not available to remediate the exploit, but there appears to be an Internet draft standard dated November 14, 2009 to fix TLS.  The RFC is here if you wish to review.  This means that the committee that wrote the new Internet draft was aware of the vulnerability and was secretly meeting to provide a fix prior to CERT releasing the news.

As you may know, SSL will not be updated as most of us are really using TLS in our browsers when we connect to secure web sites.  We still may call it SSL, but SSL is a fallback protocol to TLS.

I suspect a patch is on its way within the next few weeks, so make it a priority to update your systems through your normal patch update mechanism.

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

As many of you are aware, the new Massachusetts Standards for the Protection of Personal information (201 CMR 17.00) will hit the books on January 1, 2010.  The law establishes protection standards to be met by persons who own, license, store or maintain personal information about a resident of the Commonwealth of Massachusetts in both electronic and paper format.  So even if you do not run your business in the Commonwealth you are still affected if you keep personal information about a resident of Massachusetts. 

Personal information (PI) is defined here.

Here are the 5 things you need to do today to begin the process for compliance:

1.  Read the Regulation (http://snipurl.com/ipfwi) and the 201 CMR 17 checklist (http://snipurl.com/201_cmr_checklist)
2.  Roles and Responsibilities – Assign ownership for the overall security program within your organization.  Next, elect a Security Council comprised of senior staff or management that are stakeholders in protecting personal (and other sensitive corporate) information.  The Security Council facilitates consensus relative to the risks, impacts and priorities for compliance and will help with achieving (or changing) the security culture for your organization
3.  Find the Personal Information (PI) – Through interviews with Business Managers, Data Owners and Subject Matter Experts.  Additionally, the use of technology such as IdentityFinder can facilitate speedier PI discovery. Once discovered:

• Determine whether this data is still required and needed in the discovered location
• Do you need all the PI data or can you do without (do you still need your old customer’s credit card number)?
• Determine who requires mandatory access to the information and plan for the modification of your access lists to comply
• Ensure other safeguards are in place to protect this information (Physical access, firewalls, strong authentication/passwords, encryption).  If not, budget and plan accordingly

4.  Review your current Written Information Security Policies, if they exist, and plan for their update to include compliance.  If they do not exist, develop a project plan to begin the development process.  The larger the organization, the longer this will take for development and approval.
5.  Determine if your Third-Parties, partners, consultants, etc. have access to PI and begin the process of discovering their protection mechanisms

Compliance doesn’t happen overnight.  The sooner your company develops a strategy for 201 CMR 17.00 compliance the better your organization’s chances to meet the January 1, 2010 mandate.  These safeguards not only make good business sense, they will soon be the law.

Important update.  The amended or revised 201 CMR 17.00 has softened the requirement for third-parties you do business with and that have access to personal data.  The original regulation slated for a May 1, 2009 compliance date stated that businesses would require “certification that such service provider has a written, comprehensive information security program that is in compliance with the provisions of these regulations”.

The revised regulation scheduled for January 2010 now states that businesses should ensure that third-parties are taking all reasonable security measures — at least as stringent as those provided in the 201 CMR 17.00 regulation — in protecting personal information.

Ensure?  How are you going to “ensure” that your third-parties are protecting themselves? 

Here’s what I recommend, and I suggest you follow my advice.  Send each of your third-parties (whether they do business in the Commonwealth or not) the 201 CMR 17.00 Audit Compliance Checklist that I provided a link for in my first blog on this very subject (see below).  Take the checklist and add a signature page and have your third-parties sign it.  If they don’t fully comply, have them put together a letter that outlines their security improvement plan with dates and have them sign that. 

If your third-party is not willing to go the extra mile, you’ll have not choice but to move on.  The eventual financial risks and public image drubbing may be too high.  Are you willing to chance it?

Let me know your thoughts.

The Massachusetts Office of Consumer Affairs and Business Regulation (OCABR) this week pushed back the compliance date for its Standards for the Protection for Personal Information from May 1, 2009 to January 1, 2010.  This is the second delay to the Mass. legislation which was initially scheduled for January 2009. 

The revision was filed on Thursday, February 12th, 2009 and OCABR Undersecretary Daniel C. Crane stated, “We understand the impact of the current business environment, and feel this is an appropriate timeframe for companies to implement the necessary protections.”

As I stated in my blog last week, this regulation sets strict guidelines for businesses and other holders of Massachusetts residence’s personal information.  The policy states that personal information (a combination of a residence’s name and a social security number, driver’s license number, credit card number or financial institution account number) must be encrypted when stored or transmitted electronically over a public network.  Protection for paper documents is also included.

I recommend that you do not wait until the last minute. 

As I suggested, developing and fine tuning your Information Security Policy, educating your staff, planning your budget and making any necessary purchases and deploying them should start ASAP.

201 CMR 17.00 — Massachusetts’ New Privacy Law Sets Strict Standards for the Protection of Personal Information