Tom Olzak

Posts Tagged ‘security’

Health Care Information Security Challenge

In Data Security, HIPAA, Regulation, Security Management on December 27, 2012 at 15:27

In the last week, I’ve read several articles claiming that health care information is a prime target for cyber-criminals in 2013.  While I agree with this, I don’t agree with one of the reasons given.

Some bloggers and journalists claim that the HIPAA has not kept up with technology, and this is the reason health care is at risk today.  I disagree with this.  the HIPAA is strongly aligned with ISO/IEC 27002:2005.  General compliance with the ISO standard of best practice brings a covered entity into compliance with the HIPAA security rule.  Add to this HITECH, Subtitle B, and a covered entity has everything it needs to keep information safe.  In my view, the problem isn’t with the HIPAA; the problem is with perspective.

Compliance is not security: it is not effective risk management.  When I was director of security for a national health care organization, compliance initially went down this path.  C-level management began to ask why risk still existed after we were judged “HIPAA compliant.”  Putting the need in terms of bottom-line risk helped to turn perspectives; it made management look at HIPAA as a starting point, not an endpoint.

Today, many health care organizations are HIPAA compliant, but that does not mean risk has been sufficiently mitigated.  This is also true of publicly traded companies who pass SOX audits.  One of the biggest mistakes we as security professionals can make is allowing our employers or clients believe they are secure simply because they are compliant with a regulation.

So this begs the question… Is the current health care information security challenge a problem with the regulation or a problem with how we view compliance and risk?

Lion eats a Trojan…

In apple, Application Security, Computers and Internet, OS X Lion, Safari on September 28, 2011 at 14:21

If you’re a Mac user, you’ve probably grown complacent about security from time to time.  However, criminals are starting to go after you… me included.  In a recent CSO online article, George Hulme writes about two OS X Trojans that made the news this week.  In addition, he writes about a vulnerability Mac users who still aren’t using Firefox have in their Safari browsing experience:

“It’s those users that keep their standard system settings that are at the greatest risk, Intego says. Because the Safari browser is set to consider installer packages as safe (those files with a .phg or .mpky extension) it will automatically launch after download if their settings aren’t changed from the default. Intego advises users remove those settings.”

Following graphic shows the Safari setting in Snow Leopard.

Uncheck this box!

I guess it’s time for less Windows-bashing and a little more attention to Mac security…

It’s All about TRUST…

In Business Continuity, Data Security, Risk Management, Security Management, Trust on June 20, 2011 at 18:41

Consumers and the press like to bash vendors and online social networks for lacking perfect privacy, but there is no such thing.  Rather, this is the victim’s argument for getting pwned…

Whenever we perform an action, or fail to act, there are consequences.  A popular zen teaching uses an analogy of picking up a stick; if you pick up a stick holding one end, the other comes with it.  The same is true of sharing personal information online.  There is always the chance  your information will fall into the wrong hands.  Whether or not you share your information should be a matter of trust, of your assessment of risk.

Trust varies between online services.  For example, the steps my bank takes to protect my information are regulated and pretty strong–not perfect, but strong enough for me to take the risk of using its online services.  On the other hand, I would never post anything I don’t want the world to know about on Facebook.

Social networks are not heavily regulated… yet.  And we don’t want them to be.  I don’t want the government sticking its finger into everything I do online.  So, I need to take some responsibility for my actions and not complain to my congressman or senator when my pictures of my last frat party compromise my integrity and that of several others.  Knowing Facebook is a social network, designed for SHARING, why would I assume the risk of putting sensitive content there?  Why would I place my trust in any social networking service?

The same is true of doing business online.  There are differences in how “due diligence” is defined between online business services.  It is our responsibility to ask the right questions before using any service.  If we don’t, we are just as responsible as the service provider when data is stolen… or worse.  Further, regular audits or other assessments are necessary to ensure initial trust does not drift in the wrong direction.

Before sharing your business or personal information with anyone, ask yourself how much you trust the other guy.  If the answer is, “not as far as I can throw him,” then go somewhere else.

Security None-sense

In Data Security, iPad, Network Security, Risk Management, Security Management on December 1, 2010 at 13:03

I’m sitting in my mother’s hospital room. It is in a new, modern, well thought-out addition to the Toledo Hospital. There is even high-speed Internet access via Wi-Fi. However, the hospital’s IT department blocks social networking sites. Why?

If it’s for security, why bother? I can access Facebook and Twitter from my iPhone and iPad using other tools. For example, I sent a Facebook post (just because I could) using my email. I continued to receive friend updates via email and text messaging. I could also post photos or video from my iPhone. So any HIPAA compliance intent is fully circumvented.

If the hospital is blocking social networking to preserve bandwidth, it needs to reconsider. Today’s patients–and their families–have integrated 24/7 social contact into their lifestyles. Blocking access is simply a poor business decision.

Finally, they may block blogging before my next visit, given that I am writing this on my iPad will sitting in my mom’s room…

Give business continuity a chance…

In Business Continuity, Computers and Internet, Disaster Recovery, Risk Management on October 16, 2010 at 11:25

Business continuity is the practice of understanding critical business processes and ensuring their availability.  Disaster recovery is a component of business continuity.
Understanding business processes includes answering the following questions:

  1. What are the manual tasks that support the process?
  2. What are the human and technical resources necessary to enable the process?
  3. What other processes feed data to or receive data from this process?
  4. Is it reasonable and appropriate to build redundancy into the system?
  5. What is the maximum tolerable downtime of the process (how long can the process be broken without causing irreparable harm to the business)?
  6. Based on current capabilities, what is the recovery time if one or more of the components is broken or missing (including processes that feed this process)?
  7. Based on current capabilities, what is the recovery time following a catastrophic event (disaster recovery)?

It takes a group representing a cross-section of the organization to answer these questions.  Note that the planning is around processes, not systems.  Processes are enabled by systems and manual tasks.  For example, questions 4, 6, and 7 should include manual workarounds if automated tasks fail.  (A process is something like processing payroll with expected outcomes including checks for employees, tax payments, etc.)

Once the questions are initially answered, a remediation action plan is created to mitigate risk (shorten recovery time).  Risk mitigation takes two forms: interim and long-term.  Interim mitigation includes workarounds to enable critical outcomes while recovery tasks are performed.

When the action plan is complete, the team should once again answer questions 6 and 7.  If recovery times are not shorter than maximum tolerable downtime, additional remediation steps should be identified.  This cycle repeats until maximum tolerable downtime exceeds recovery time.

%d bloggers like this: