Cybersecurity And National Health IT Week

So this week is National Health IT Week (#NHITWeek).

And here I am, writing about cybersecurity in healthcare and data protection, with a reference or two to shed some light on the concept of SIEM – Security Information and Event Management.  And why SIEM matters so much.

Can I be honest?  I often struggle to differentiate cybersecurity by industry.  There’s only one case that stands out.  The control room of a utility or processing plant, and that’s because their systems aren’t exactly workstations or servers, but rather PLCs (programmable logic controllers).  Control systems.  Everyone else deals with workstations and servers, switches and routers, SANs and VMs.  Nothing to differentiate the needs of a specific industry from another.

True, compliance requirements differ (you can read more about healthcare specific ones here), which is unfortunate.  Since security IS security, and a workstation is a workstation, having diverse compliance requirements often instills in people the notion that they’re different. And somehow, in IT, different seems to imply ‘better’. There’s this unspoken sense of superiority stemming from the idea that if my issues are different than yours, then somehow my issues are ‘harder’ than yours; and since I fight harder issues, I must, by extrapolation, be better than you (please join me in shaking my head).

Let’s all get off our high horses.

Now.

There’s zero difference in the cybersecurity needs of a hospital vs those of a bank.  Or hotels vs restaurants.  Or manufacturers vs schools.  Let me qualify this by acknowledging that yes, the legal requirements differ – CIPA applies to schools, HIPAA and HITECH apply to medical information.  But that’s it.  How you accomplish the task of defending yourself from cyberattacks, that remains the same.  Across the board.  Policies, procedures, user education, firewalls, IPS, anything you name.

Security technology is the same for all industries.

The real difference comes in regulatory requirements.  And those are necessary since we’re dealing with human nature.  Even with cybersecurity in the news every day, many still think they’re impervious to attacks, to breaches.  And unless you literally shove it down their throats as a mandatory must-have (for instance, Medicare not paying your bills if you’re not HITECH compliant), they won’t listen.  Until you start putting people in jail, naysayers remain.  Either they don’t care.  Or they don’t understand.  Or both. Neither of which matters in the grand scheme of things since their behavior puts others at risk.  That’s why we must regulate and impose where needed.  Unfortunate but so necessary.

Thanks regulatory requirements, we’ve started seeing requests for log data to be retained, offsite, for a certain number of years.  The minimum being a year.  While companies react with disdain to this, they understand there’s a reason.  Threats often lurk in a network for a long time before they unleash havoc.  Having logs that are a year old allow forensics analysis to determine what caused the issue.  When the malicious code might have been installed.  When a certain change, which ended up causing big security issues, was made and by whom.  Just as in process control we understand that change control is necessary to keep things secure, we must also realize that retaining logs is vital.  The ability to go back, dissect the ‘what when how‘, and learn, possibly rectify, is imperative.

Log retention isn’t a nuisance; it’s a necessity.

How long we keep these logs is debatable.  But the fact that we need to keep them for at least a year is, in my opinion, an absolute no brainer.  And they must be retained offsite.  You can’t keep longterm logs in the same place they were produced – you could lose everything during an attack, fire, or other unfortunate incident.  Offsite retention offsite, preferably in the cloud, is much safer.

As we collate the data, doesn’t it make sense to also use it to analyze patterns and assist in detecting potential issues before they explode into actual problems?  That’s what a SIEM does.  SIEM stands for Security Information and Event Management.  A coupling of two security concepts happening concurrently namely Information and Event.

Information means simply that – knowledge of what’s going on. Knowing Joe connected via VPN from home is information. Event is slightly different.  My attempting to change a password can be defined as an event.  Someone scanning my network from Japan is another type of event.

Is there anything to learn by knowing immediately about the connection or the scanning?

Maybe not.  Both can be ‘expected’.  I logon to the VPN very often.  Hackers scan networks for open ports all the time.  It’s really not ‘news’ to know someone’s scanning my firewall at this moment.  What’s worth knowing is I’m apparently logging onto the VPN from, say, Norway.  Or that the scan’s occurring at an unusual frequency.  Or someone’s attempting to login remotely and keeps keying in an incorrect password.  Major red flag. These are defined as events.  Events worth knowing about as soon as they occur.

And that’s why, at Network Box USA, we don’t call it Information but Intelligence.  Security Intelligence and Event Management, to be precise.  Because knowing about a certain event (or chain of events) immediately is important and can help save a network.  An escalation of privileges on an AD server isn’t something that should wait 2 days to be discovered.  It’s something that must be known instantly, and that’s why we call it intelligence.  The event raises an alarm causing someone to immediately check.  To ensure if escalation is warranted, authorized, legitimate.  Neither rogue nor due to a hacker trying to attack your AD server.

So the question should be – is security for healthcare different from security for banks?

No.

Is a SIEM going to help both?  Absolutely.  How long should the data be kept?  Depends on regulations pertaining to your sector.  Ask your auditors but be prepared to keep it at least one year, otherwise it’s simply not worth your efforts.