Sarbanes-Oxley Act

Understanding the risk of penalties for violating data privacy laws

The “Massachusetts Data Privacy Law? We call it ‘the toothless wonder,’” laughed one smug senior technology executive from a prominent high-tech firm at a MIT industry gathering April 30 in Cambridge, Mass.

But not everyone is laughing. In April 2008, Andrea Smith, age 25, of Trumann, Ark., was convicted of privacy violations under HIPAA, as was Fernando Ferrer Jr., of Naples, Fla., in January 2007. As of today, a total of eight cases have resulted in criminal convictions with jail time for data privacy violations under HIPAA.

The U.S. Department of Health and Human Services (HHS) has served notice (as of Feb. 18) that organizations can also expect substantial fines like the one extracted from CVS. That $2.5 million fine, coupled with others won by OCR or the FTC against Providence Health & Services, demonstrate that the risk of penalties is significantly more realistic going forward.

The probability of criminal convictions and risk of substantial penalties doesn’t, however, correlate to the likelihood of other serious compliance issues. “Stricter internal controls mandated by Sarbanes-Oxley have made it more difficult for improper payments to be concealed,” notes CorpWatch.

Consider the case of Richard Scrushy, founder of HealthSouth. Although theoretically acquitted of Sarbanes-Oxley (SOX) charges, he nevertheless sits in a Birmingham, Ala., prison. Although Scrushy was technically jailed for probation violations related to a vacation on a Miami yacht when he was supposed to be under house arrest in Birmingham, SOX materially contributed to Scrushy’s imprisonment. Some commentators have pointed to the few convictions under SOX when dismissing likelihood of consequences. But, as anyone involved with the legal system can attest, likelihood of conviction and fines barely begin to measure likelihood of serious problems. Let’s look at some other data:

HIPAA Enforcement Results by Year

• 2008 HIPAA investigations – 3,373
• 2008 HIPAA cases resulting in a requirement for corrective actions – 2,210
• Total HIPAA investigations 2003-2008 - over 11,000
• Total HIPAA cases resulting in a requirement for corrective actions – over 7,000

Source: U.S. Department of Health and Human Services

Simply receiving notice of an investigation requires firms and individuals to incur the costs of retaining counsel and allocating time, energy and resources to preparation. That’s a nerve-racking process with an unsure outcome. The investigation alone can be a big headache. And while only 10 cases have resulted in major fines or jail time, significantly more cases were prosecuted.

Preparing and presenting a criminal or civil defense in a legal case is, again, a costly undertaking with an unsure outcome, where even acquittal can leave an organization or an individual at a huge financial loss for attorney’s fees and energy, resources and the uncertainty that legal action causes.

How about nonconviction convictions? Plea deals can result in CWOF results, or Continued Without a Finding, and result in probation. Home-free, right? That’s what Richard Scrushy thought. The reality is that each step along the legal path increases the likelihood that subsequent or related, seemingly minor developments will result in jail time or fines. Organizations and individuals amass track records, which work against them over time.

SOX and HIPAA are only two of dozens of statutes under which privacy violations can be prosecuted. Try these for a few:

Health privacy laws
1974—The National Research Act
1996—Health Insurance Portability and Accountability Act (HIPAA)

Financial privacy laws
1970—Bank Secrecy Act
1998—Federal Trade Commission
1999—Gramm-Leach-Bliley Act (GLB)
2002—Sarbanes-Oxley Act (SOX)
2003—Fair and Accurate Credit Transactions Act

Online privacy laws
1986—Electronic Communications Privacy Act (ECPA), pen registers
1986—Stored Communications Act (SCA)

Communication privacy laws
1978—Foreign Intelligence Surveillance Act (FISA)
1984—Cable Communications Policy Act
1986—Electronic Communications Privacy Act (ECPA)
1994—Digital Telephony Act - Communications Assistance for Law Enforcement Act (CALEA), 18 USC 2510-2522

Education privacy laws
1974—Family Educational Rights and Privacy Act (FERPA)

Information privacy laws
2001—USA Patriot Act, expanded pen registers

Other
1974—Privacy Act
2005—Privacy Act, sale of online PII data for marketing

Still skeptical? California alone has over 88 data privacy laws — and it actively investigates and prosecutes violations.

Twenty-three thousand HIPAA investigations over five years x 100 laws = over 2 million investigations. Your chances are looking worse and worse. And the cost of voluntary compliance is looking cheaper and cheaper by comparison.

Database logging and privileged access control

Ship captains have long started their days by initialing log entries. As a former senior security executive at a financial services firm with $500 billion in assets under management and over 20,000 employees, my day would start similarly. Each morning, I’d take responsibility for reviewing lists of accounts with privileged access to high-risk data.

What defines “privilege” in the world of security access is really the ability to “write” or alter a database. It also includes the ability to alter the audit trail documenting who has “write” access. “High-risk” data includes customer balances and transaction values, for example. This morning ritual of personally reviewing privileged access should be a part of a compliance program before you attempt database logging. Both are fundamental controls that everyone should have in place. Reports that document identities that have privileged access need to be designed and implemented. Operational procedures for review and follow-up on those reports need to be put in place.

Every morning, automated reports would appear in my inbox based on tightly defined criteria. I reviewed them, printed them, signed them, and had them filed. Auditors checked these randomly several times a year. Once a week, I reviewed similar reports signed by my subordinates, my VPs, reflecting use of emergency IDs, temporary IDs, vendor IDs, and privileged transactions. In other words, even before the Sarbanes-Oxley Act (SOX) required senior executives to take a more proactive role in security, I was starting my business day the same way, monitoring the list of those with the keys to the company’s crown jewels, so to speak.

My daily morning executive-level review of high-risk access should tell you a few things:

1. Even at an enormous firm, the number of privileged IDs with access to high-risk data should be short enough for a busy executive to personally review
2. It is both feasible and reasonable for senior executives to personally review this information and record that they have done so
3. Anyone can expect this kind of review may be taking place in any major organization handling high-risk data, although it is not as universal as it should be

There are no specific standards or frameworks telling you how to create these reports or what to include. Don’t waste your time on a fool’s errand searching for detailed technical guidelines. COBIT and SOX frameworks indicate only that this type of review in general should be defined by each organization and put into place. Whether it is daily, weekly, or monthly, and what exactly it includes, will be up to each organization, compliance officer and CISO, depending on its businesses and risks.

Here are some general considerations for specifying these reports:

1. The number of individuals with write access to this data should be zero. If someone needs regular access to unlock or fix operational issues, you should know those people by name very well and they should number no more than three.
2. Revoke privileges after resolution. Anyone who was granted write access to resolve an issue should have had the privilege revoked after an issue was resolved. Thus, the only names showing up on your report would and should be individuals continuing to resolve issues which cross the timeframe of the running of the report, which should be timed around 3a.m. every day.
3. Turn off audit switches in identities. Don’t forget to include identities in your review that have the ability to turn “audit” on and off for each database or account. Unless you include this privilege, individuals can turn “audit” off prior to access and turn it on again immediately afterwards. You will have no idea of any change. Which means:
4. Include all changes to “audit” status in the prior 24 hours in the privileged transaction report: Was audit turned on or off?
5. Review emergency access for IDs. Did anyone check out an emergency ID with high privileges? Was it checked back in? Does it correspond to a change management ticket reflecting a valid reason for the use of the emergency ID?

Please feel free to comment or write to editor@searchcompliance.com with any questions on these types of controls.