Category Archives: Compliance

informed-consent-consideration

Why HIPAA Policies and Procedures are not copy and paste

Compliance from Dr. Google is a very bad idea.

Searching for HIPAA Security Rule compliance yields about 1.8Million hits on Google. Some of  the information is outdated and does not relate to the Final Rule and a good deal of other information is sponsored by service providers and technology companies selling silver bullets for HIPAA compliance.

The online dialog on HIPAA Security Rule compliance is dominated by discussions by requirements for health providers.   There is very little information online for the downstream medtech and medical device vendors who are increasingly using the cloud to store data and process transactions for their covered entity customers

If you are a small medtech or medical device company, and you copy from a big healthcare provider you will be overpaying and over-implementing SOP’s which may not be relevant to your business situation.

The risk analysis for a SaaS provider or medical device that stores PHI in the cloud is not even remotely similar to the risk analysis for a hospital.

If you copy and paste a risk analysis – you won’t understand what you’re doing and why you’re doing it and since HIPAA privacy infractions carry both a criminal civil penalty, you don’t want to even attempt to comply via Google.

For example – if you are a mobile medical device vendor – you will need to take into account technology and privacy considerations such as mobile app software security, application activity monitoring, mobile and cloud data encryption and key management none of which may be relevant for a traditional IT hospital-run electronic health records system.

What policies and procedures do I need for HIPAA compliance?

We provide clients with  a bespoke package of SOP’s which are required by HIPAA – Acceptable use, Incident response, Security and risk management process, Disaster recovery plan, and Security Officer Job description (which is required by the Final Rule).     This is in addition to the Risk Analysis / Security Assessment report (§ 164.308(a)(1)(ii)(A) ).

6 reasons why  HIPAA security policies and procedures are not copy and paste:

  1. It depends on the business situation and technology model. A biotechnology company doing drug development will not have the same threat surface as a mobile health company.
  2. Your security is worse than you think. When was the last time you looked? Or had an external audit of your encryption policies?
  3. It also depends on timing – if the life science company is doing clinical research, then informed consent may release the sponsor from HIPAA privacy rule compliance. But in clinical research, physician-investigators often stand in dual roles to the subject: as a treating physician (who has to comply with the HIPAA Privacy Rule) and as a researcher (who has to comply with both GCP and 21 CFR Parts 50 and 56 regarding informed consent with adults and children).  In my experience with medical device companies, they often do clinical trials in parallel to commercial betas and work closely with physician-investigators. This means that your HIPAA Security Rule compliance posture needs to be nailed down in order to eliminate holes of privacy leakage.
  4. Life science companies have quality management systems as part of their FDA submissions – the HIPAA Security Rule policies and procedures need to become part of your quality system.We work with you to make sure that your regulatory/QA/QC leads understand what it means to implement them and help them integrate into their own internal formats, policies and training programs.
  5. Covered entities may also have impose specific  requirements in their BAA on the life science vendor;  we then need to customize the policies and procedures to comply with the their internal guidelines.     Sometimes these are quite strange like  the story of the West Coast hospital that deliberately weakened the WiFi signal of their routers in the thought that it was a security countermeasure for hacking their wireless access points.
  6. There are also situations of intersection with other Privacy regulation such as CA 1280.15 for Data breach – California is sticky on this and then if  you do business with U of C – there are will be additional things to cover

Feel free to contact us  for a free quote – we’re always looking for interesting projects.

 

Tell your friends and colleagues about us. Thanks!
Share this
Federal Healthcare Chart

The chasm between FDA regulatory and cyber security

 

When a Risk Analysis is not a Risk analysis

Superficially at least, there is not a lot of difference between a threat analysis that is part of a software/hardware security assessment and a risk analysis (or hazard analysis) that is performed by a medical device company as part of their submission to the FDA.    In the past 2 years, FDA added  guidance for cybersecurity for medical devices and the format and language of the guidance is fairly similar.

The problem is that hazard analysis talks about patient safety and relates to the device itself as a potential attacker whereas software  security talks about confidentiality of patient data, integrity of the code and its data and credentials and system availability and relates to the device as a black box.

So in fact – medical device risk analysis and cyber security assessments are 2 totally different animals.

Some of my best friends work in medical device regulatory affairs. I admire what they do and I like (almost) all of them on a personal basis.

But – over the past year, I have been developing a feeling of deep angst that there an impossible-to-cross chasm of misunderstanding and philosophy that exists between medical device regulatory people and medical device security analysts like me.

But I can no longer deny that even at their best – regulatory affairs folks will never get security.

Why do I say this?   First of all – the empirical data tells me this.  I  interface with several dozen regulatory professionals at our medical device security clients in Israel and the best of them grasp at understanding security.  The worst cases hang on to their document version controls for dear life and claim earnestly even as they are hacked that they cannot modify their device description because their QA process needs several weeks to approve a 3 line bug fix. (This is a true story).

We intend to implement encryption of EPHI in our database running on a cloud server since encryption uses check sums and check sums ensure integrity of the data and help protect patient safety.
True quote from a device description of a mobile medical device that stores data in the cloud…the names have been concealed to protect the innocent.  I did not make this up.

The chasm between FDA regulatory and cyber security

The second reason I believe that there is an impossible-to-cross chasm between medical FDA device regulatory people and medical device security is much more fundamental.

Systems like mobile medical devices live in the adversarial environment of the Internet and mobile devices. Unlike traditional engineering domains like bridge-building that are well understood and deal with winds that obey rules of physics and always blow sideways; security threats do not play by set rules. Imagine a wind that blows up and down and then digs underground to attack bridge pylons from 50m below earth and you begin to understand what we mean when we say “adversarial environment”.

General classes of attacks include elevation of privilege, remote code execution, denial of service and exploits of vulnerable application interfaces and network ports. For example:

  • Attacker that steals personal data from the cloud by exploiting operating system bugs that allow elevation of privilege.  Zero-days that were unknown when your QA people did V&V.
  • Attacker that exploits vulnerabilities in directory services that could allow denial of service. What ?  We’re using directory services???
  • Attacker that tempts users to download malicious mobile code that exploit mobile APIs in order to steal personal data. What?  This is just an app to measure blood sugar – why would a patient click on an add that injects malicious code into our code while he was taking a picture of a strip to measure blood sugar??

We talk about an attacker in an abstract sense, but we don’t know what resources she has, when she will attack or what goals she has. Technology changes rapidly; a system released 2 years ago may have bugs that she will exploit today. Our only recourse is to be paranoid and think like an attacker.

Thinking like attackers not like regulators

By being extremely paranoid and thinking like attackers, medical device security requires us to systematically consider threat models of attacks, attack vectors, assets at risk, their vulnerabilities and appropriate security countermeasures for prevention, detection and response.

While this approach is not a “silver bullet” it lends structure to our paranoia and helps us do our job even as the rules change.

And this where the chasm begins.   The rules change.   There is no QA process. There are no rules.   We are not using IEEE software engineering standards from 40 years ago.  They are useless for us.

Dorothy – we are not in Kansas anymore. And we are definitely not in Washington DC in a regulatory consulting firm of high-priced lawyers.

 

 

Tell your friends and colleagues about us. Thanks!
Share this

PCI DSS is a standard for the card associations not for your business

 

I recently saw a post from a blog on a corporate web site from a company called Cloud compliance, entitled “Compliance is the New Security Standard“.

Cloud Compliance provides a SaaS-based identity and Access Assessment (IdAA) solution that helps identify and remediate access control and entitlement policy violations. We combine the economies of cloud computing with fundamental performance management principles to provide easy, low cost analysis of access rights to prevent audit findings (sic) and ensure compliance with regulations such as SOX, GLBA, PCI DSS, HIPAA and NERC.

The basic thesis of the blog post was that since companies have to spend money on compliance anyhow, they might as well spend the money once and rename the effort “security”.   This is an interesting notion – although perhaps “placebo security” might be a cheaper approach.

Compliance is not equivalent to security  for several fundamental reasons.  Let’s examine this curious notion, using  PCI DSS 1.2 as a generic example of a regulatory compliance standard that is used to protect payment card numbers:

A. Filling out a form or having an auditor check off a list is not logically equivalent to installing and validating security countermeasures. A threat modeling exercise is stronger than filling out a form or auditing controls – it’s significant that threat modeling is not even mentioned by PCI DSS, despite the ROI in think time.

B. Although PCI DSS 1.2 is better than previous versions – it still lags the curve of typical data security threats – which means that even if a business implements all the controls – they are probably still vulnerable.

C. PCI DSS was designed by the card associations – there is no way that any blanket standard will fit the needs of a particular business – anymore than a size 38 regular suit will fit a 5′ 7″ man who weighs 120 kg and wrestles professionally.

D. PCI DSS talks about controls with absolutely no  context of value at risk. A retailer selling diamond rings on-line, may self-comply as a Level 4 merchant but in fact have more value at risk than then the payment processor service provider he uses. (See my previous post on Small merchants at risk from fraudulent transactions )

E. PCI DSS strives to ensure continued compliance to their (albeit flawed) standard with quarterly (for Level 1) and yearly (for everyone else) audits.   The only problem with this is that a lot of things can happen in 3 months (and certainly in a year).   The automated scanning that many Level 2-4 merchants do is essentially worthless but more importantly – the threat scenarios shift quickly these days – especially when you take into account employees and contractors who as people are by definition, unpredictable.

F. Finally – PCI DSS is a standard for whom? It’s a standard to help the card associations protect their supply chain.   It is not a policy used by the management of a company in order to improve customer service and grow sales volume.

F. PCI DSS 1.2 mandates security controls for untrusted networks and external attacks.   The phrases “trusted insider” or “business partner” are not mentioned once in the standard. This is absurd, since a significant percentage of the customer data breaches in the past few years involved trusted insiders and business partners. A card processor can be 100 percent compliant but because they have a Mafia sleeper working in IT – they could be regularly leaking credit card numbers. This is not a theoretical threat.

To summarize:

  • PCI DSS is a standard for the card associations not for your business nor for your customers.
  • As a security standard it is better than none at all but leaves much to be desired because it is not oriented towards the business and consumer protection
Tell your friends and colleagues about us. Thanks!
Share this
Three business people working

Risk does not walk alone

Israeli biomed companies often ask us about the roles of audit and risk management in their HIPAA security and compliance activities.  At the eHealth conference in Israel last week – a lawyer gave a presentation on HIPAA compliance and stated:

If you have to do one thing, make sure everything is documented – your policies and procedures, corrective action you took. Everything.  That is your best line of defense.

Security is not an exercise in paperwork.

With all due respect to lawyers – no.   Your best line of defense is implementing real security countermeasures in a prioritized way an ensuring that you are doing the right stuff all the time by integrating your HIPAA Security Rule and Compliance activities with your internal audit and risk management teams.

Risk does not walk alone

Risk is not an independent variable that can be managed  on its own.  It is not an exercise in paper work. Risk is a function of external and internal attackers that exploit weaknesses (vulnerabilities) in people and systems and processes in order to get something of value (assets).   The HIPAA Security Rule prescribes in a well-structured way – how to implement the right security countermeasures to protect EPHI – the key assets of your patient customers.

The importance of audit for HIPAA

While audit is not specifically mentioned in the HIPAA Security Rule – security review and risk management are key pieces – audit is crucial for you to stay on track over time.

According to the Institute of Internal Auditors, internal auditing is an “independent, objective assurance and consulting activity designed to add value and improve an organization’s operations.” Internal audits provide assurance and consulting services to management in an independent and objective manner. But what does that mean? It means that internal auditors can go into your business operation and determine if your HIPAA security and compliance is a story on paper or a story being acted out in real life.

Audit – necessary but not sufficient

However, internal audit is not a line of defense and neither is a corporate risk management function a line of defense.

HIPAA Security and Privacy Rule compliance regards investigating plausible threats, valuable assets, vulnerabilities and security countermeasures that mitigate asset vulnerabilities and reduce the risk which is the result of threats exploiting vulnerabilities to damage assets.

When we frame security defenses in terms of mitigating attacks – we immediately see that neither audit nor corporate risk management fall into the category of countermeasures.

So why is audit and risk management important?

Audit is crucial to assuring that the security portfolio is actually implemented at all levels. Yes – all levels – including the CEO office and the last of the cleaning team. Audit strengths are also their weakness – they generally do not understand the technical side of security and therefore audit must work hand in glove with the operational and engineering functions in an organization.

Risk management is key to prioritizing implementation of security countermeasures – because – let’s face it – business and engineering operations functions are not qualified to evaluate asset value.

In summary

Your HIPAA and Security Rule compliance is not just about paper-work.  It’s about getting it right  – day in and day out.

 

Tell your friends and colleagues about us. Thanks!
Share this
dilbert Data Security

3 things a medical device vendor must do for security incident response

You are VP R&D or CEO or regulatory and compliance officer at a medical device company.

Your medical devices measure something (blood sugar, urine analysis, facial anomalies, you name it…). The medical device interfaces to a mobile app that provides a User Interface and transfers patient data to a cloud application using RESTful services over HTTPS.

Sound familiar?

The Medical device-Mobile app-Cloud storage triad is a common architecture today for many diagnostic, personal well-being and remote patient monitoring indications.

We have numerous clients with the Medical device-Mobile app-Cloud storage system architecture and we help them address 4 key security issue –

  1. How to ensure that personal data and user authentication data is not stolen from the mobile medical app,
  2. How to ensure that the mobile medical app is not used as an attack pivot to attack other medical device users and cloud servers,
  3. How to comply with the HIPAA Security Rule and ensure that health data transferred to the cloud is not breached by attackers who are more than interested in trafficking in your users’ personal health data,
  4. How to execute effective security incident response and remediation – its a HIPAA standard but above all – a basic tenet for information security management.

How effective is your security incident response?

The recent SANS Survey on Security Incident Response covers the challenges faced by incident response teams today—the types of attacks they detect, what security countermeasures they’ve deployed, and their perceived effectiveness and obstacles to incident handling.

Perceived effectiveness is a good way of putting it – because the SANS Survey on Security Incident Response report has some weaknesses.

First – the survey that is dominated by large companies: over 50% of the respondents work for companies with more than 5,000 employees and fully 26% work for companies with more than 20,000 employees.    Small companies with less than 100 employees – which cover almost all medical device companies are underrepresented in the data.

Second – the SANS survey attempts, unsuccessfully, to reconcile reports by the companies they interviewed that they respond and remediate  incidents within 24 hours(!) with reports by the PCI (Payment Card Industry) DSS (Data security standard) Association that retail merchants take over 6 months to respond.       This gap is difficult to understand – although it suggests considerable variance in the way companies define incident response and perhaps a good deal of wishful thinking, back-patting and CYA.

Since most medical device companies have less than 100 employees – it is unclear if the SANS findings (which are skewed to large IT security and compliance organizations) are in fact relevant at all to a medical device industry that is moving rapidly to the medical device-App-Cloud paradigm.

3 things a medical device vendor must have for effective incident response

  1. Establish an IRT.  (Contact us and we will be happy to help you set up an IRT and train them on effective procedure and tools).  Make sure that the IRT trains and conducts simulations every 3-6 months and above all make sure that someone is home to answer the call when it comes.
  2. Lead from the front. Ensure that the head of IRT reports to the CEO.   In security incident response, management needs to up front and not lead from behind.
  3. Detect in real time. Our key concern is cloud server security.    Our recommendation is to install OSSEC on your cloud servers. OSSEC sends alerts to a central server where analysis and notification can occur even if the medical device cloud server goes down or is compromised.
Tell your friends and colleagues about us. Thanks!
Share this
Data loss prevention

Refreshing your HIPAA Security Rule compliance

Clients frequently ask us questions like this.

Danny,

I have a quick question about our HIPAA compliance that we achieved back in early 2013. Since then  we have released a couple of new software versions and we are wondering to what extent we need to perform another security and compliance assessment.  Please let us know what sort of information you might require to evaluate whether or not a new HIPAA security rule assessment is required.

What about the upcoming changes in HIPAA in 2016?

Any software changes that increase the threat surface to attacks (new ports, new interfaces, new modules that use PHI) would be reason to take a look at your Security Rule compliance.
Re HIPAA 2016 – OCR is still making plans but it is almost certain they will be doing audits.    I believe that due to sheer size of the program – they will start with the biggest hospitals – I do not think that small medical device vendors will be on their radar – although the big guys that had serious adverse events will probably get audited (insulin pumps, implanted cardiac devices)
In general, if you are developing medical software that connects to the Internet or the mobile Internet – you should not wait 3 years between security assessments.  Make secure software development methdology part of the way you develop software and audit once/year or on any major release.
Danny

 

Tell your friends and colleagues about us. Thanks!
Share this
hipaa cloud security

Privacy, Security, HIPAA and you.

Medical devices, mobile apps, Web applications – storing data in the cloud, sharing with hospitals and doctors. How do I comply with HIPAA? What applies to me – the Security Rule, the Privacy Rule or both?

Consider a common use case these days – you’re a medical device vendor and your device stores health information in the cloud. You have a web and/or mobile application that enable doctors/hospitals to access the data from my device as part of their healthcare services. If you operate in the United States, what HIPAA regulations apply ? Do I need to comply with the Privacy Rule, the Security Rule or both?

There is a good deal of confusion regarding the HIPAA Privacy and Security Rules and how things work. In this article, we will examine the original content of the HIPAA regulation and explain who needs to do what.

What is the Privacy Rule?

The HIPAA Final Rule (enacted in Jan 2013) has 2 pieces – the Privacy Rule and the Security Rule.

The Privacy Rule establishes standards for the protection of health information. The Security Rule establishes security standards for protecting health information that is held or transferred in electronic form. The Privacy Rule broadly defines ‘‘protected health information’’ as individually identifiable health information maintained or transmitted by a covered entity in any form or medium. The Privacy Rule is located at 45 CFR Part 160 and Subparts A and E of Part 164.

Who needs to comply with the Privacy Rule?

By law, the HIPAA Privacy Rule applies only to covered entities – health plans, health care clearinghouses, and certain health care providers. However, most health care providers and health plans do not carry out all of their health care activities and functions by themselves. Instead, they often use the services of a variety of other persons or businesses – and transfer/exchange health information in electronic form to use these services. These “persons or businesses” are called “business associates”; defined in 45 CFR 164.502(e), 164.504(e), 164.532(d) and (e) 45 CFR § 160.102, 164.500.

What is the Security Rule?

The Security Rule operationalizes the Privacy Rule by addressing the technical and non-technical safeguards that the “covered entities” and their business associates must implement in order to secure individuals’ “electronic protected health information” (EPHI). The Security Rule is located at 45 CFR Part 160 and Subparts A and C of Part 164.

Who needs to comply with the Security Rule?

Since its an operational requirement, the Security Rule (by law) applies to covered entities, business associates and their sub-contractors. While the Privacy Rule applies to protected health information in all forms, the Security Rule applies only to electronic health information systems that maintain or transmit individually identifiable health information. Safeguards for protected health information in oral, written, or other non-electronic forms are unaffected by the Security Rule.

Business associate liability

Section 13404 of the HITECH Act creates direct liability for impermissible uses and disclosures of protected health information by a business associate of a covered entity “that obtains or creates” protected health information “pursuant to a written contract or other arrangement described in § 164.502(e)(2)” and for compliance with the other privacy provisions in the HITECH Act.

Section 13404 does not create direct liability for business associates with regard to compliance with all requirements under the Privacy Rule (i.e., does not treat them as covered entities). Therefore, under the final rule, a business associate is directly liable under the Privacy Rule for uses and disclosures of protected health information that are not in accord with its business associate agreement or the Privacy Rule.

Permitted use of EPHI by a business associate

While a business associate does not have health care operations, it is permitted by § 164.504(e)(2)(i)(A) to use and disclose protected health information as necessary for its own management and administration if the business associate agreement permits such activities, or to carry out its legal responsibilities. Other than the exceptions for the business associate’s management and administration and for data aggregation services relating to the health care operations of the covered entity, the business associate may not use or disclose protected health information in a manner that would not be permissible if done by the covered entity (even if such a use or disclosure is permitted by the business associate agreement).

Taken from the Federal Register

General Definitions

See § 160.103 for HIPAA general definitions used by the law – definitions of business associates, protected health information and more.

Summary

  • The Privacy Rule establishes standards for the protection of health information.
  • The Security Rule establishes operational security standards for protecting health information that is held or transferred in electronic form.
  • The Security Rule applies only to electronic health information systems that maintain or transmit individually identifiable health information. Safeguards for protected health information in oral, written, or other non-electronic forms are unaffected by the Security Rule.
  • Business associates do not have direct liability with regard to compliance with all requirements under the Privacy Rule (i.e., does not treat them as covered entities). A business associate is directly liable under the Privacy Rule for uses and disclosures of protected health information that are not in accord with its business associate agreement or the Privacy Rule.

 

Tell your friends and colleagues about us. Thanks!
Share this
Security is not fortune telling

Back to basics with HIPAA – 3 things you must do.

Before you start spending money on regulatory consultants get back to basics.  Do you or do you not need to comply with the HIPAA Security Rule?  If you do – what is the very first thing you should do?   In this post – we will get back to basics with 3 practical ways of complying and reducing your regulatory risk.

I specialize in cyber security and privacy compliance consulting for medical device companies in Israel.  While this may sound like a niche, it is actually a very nice and not so small niche – with over 700 biomed vendors and a market growing 7-8% / year.

Israeli biomed startups are incredibly innovative and it’s fun working with smart people.  Here are 3 ways to improve your HIPAA risk analysis in just a few minutes:

Check # 1 – Maybe you are not a HIPAA Business associate

If you are a medical device vendor and you connect to a hospital network or share data  with doctors, you are automatically a BA; a Business associate according to the HIPAA Business Associate definition.   If you are a BA – you need to comply with the HIPAA Security Rule. But maybe you are not a BA.

By law, the HIPAA Privacy Rule applies only to covered entities – health plans, health care clearinghouses, and certain health care providers. A “business associate” is a person or entity that performs certain functions or activities that involve the use or disclosure of protected health information on behalf of, or provides services to, a covered entity.  If an entity  does not meet the definition of a covered entity or business associate, it does not have to comply with the HIPAA Rules.  See definitions of “business associate” and “covered entity” at 45 CFR 160.103.

So – if you developed a consumer mobile app that monitors stress  with a cool dashboard to visualize data stored in the cloud enabling your users to reduce their stress and compare themselves with other people like them; so long as the software doesn’t share data with a covered entity (like their doctor) – you are not a BA. Check.

 Check # 2 – Maybe you don’t even need to comply with HIPAA

HIPAA applies to storage of EPHI (electronic protected health information).   Simply put – EPHI is the combination of PII (personally identifiable information – such as a name, email and social security number) and healthcare / clinical data.

So – getting back to our hypothetical mobile medical app for personal stress tracking, let’s suppose that the stress data includes heart rate and respiratory rate in addition to how many times/day the consumer called their girl friend to make sure she still loves them  (when they are freaking out with stress before a big exam). If your mobile medical app for stress management doesn’t store personal information with the clinical data, then you don’t have to comply with HIPAA because you don’t you don’t create, store or transmit EPHI in the cloud. Check.

Check # 3 – Using contractors for software development? Vet them and oversee them

There is commonly-used expression in Hebrew – “launch and forget” (שגר ושכח).  I believe that this is a Hebrew translation of the American English term “Fire and forget” that refers to a type of missile guidance which does not require further guidance after launch.

When it comes to contractors you do not want to “launch and forget”.

Maybe you are a BA and you have to comply with HIPAA – just because the HIPAA Security Rule does not have a standard safeguard for vetting contractors, can you afford to gloss over this area?

This is a big one boys and girls.   If you use contractors for code development, make sure you thoroughly vet them before engaging with them on upwork.  I am not talking about quality of work – it is a given that you need someone highly competent in whatever problem problem domain you are trying to crack (your girl-friends brother-in-law may not be your best fit).  I am talking about the threat of a contractor stealing your code, dropping Android malware into your app, or enabling tap-jacking to steal personal data).

Even if they don’t steal your code, consider the threat of your contractor working for a competitor, leaking your IP or being hired by a business partner who click-jacks your entire business model.

It’s tempting to work with software developers in Ukraine or China but be careful. Consider the case of Russian programmers who wrote code for U.S. military communications systems or the  DOJ accuses firm that vetted Snowden of faking 665,000 background checks. 

In the Federal space, it is sad but true that there is huge a Federal procurement machine that enables these kinds of attacks to happen because of organizational complexity ( a nice way of saying that accountability falls between the cracks) and greed  ( a not so nice way of saying that big contracts are a challenge to morality and governance).

US Federal agency purchasing managers who sign purchase orders without appropriate contractor vetting and oversight are not a justification for a privately-held Israeli medical device company to sin…

The calls for more legislation are a knee-jerk reaction to the horses having left the barn years ago but when common sense and good business practices yield to greed then perhaps we do need a tail wind. Vetting software development contractors should be a standard requirement in the core security guidance such as HIPAA, PCI and FDA cyber security but in the meantime – don’t wait for the US Federal Government to tell you to vet your contractors and oversee their work. Put an accountability clause into your contracts.

Tell your friends and colleagues about us. Thanks!
Share this
dilbert-paradigm-intro1

10 ways to detect employees who are a threat to PHI

Software Associates specializes in software security and privacy compliance for medical device vendors in Israel.   One of the great things about working with Israeli medical device vendors is the level of innovation, drive and abundance of smart people.

It’s why I get up in the morning.

Most people who don’t work in security, assume that the field is very technical, yet really – it’s all about people.   Data security breaches happen because people or greedy or careless.    100% of all software vulnerabilities are bugs, and most of those are design bugs which could have been avoided or mitigated by 2 or 3 people talking about the issues during the development process.

I’ve been talking to several of my colleagues for years about writing a book on “Security anti-design patterns” – and the time has come to start. So here we go:

Security anti-design pattern #1 – The lazy employee

Lazy employees are often misdiagnosed by security and compliance consultants as being stupid.

Before you flip the bozo bit on customer’s employee as being stupid, consider that education and IQ are not reliable indicators of dangerous employees who are a threat to the company assets.

Lazy employees may be quite smart but they’d rather rely on organizational constructs instead of actually thinking and executing and occasionally getting caught making a mistake.

I realized this while engaging with a client who has a very smart VP – he’s so smart he has succeeded in maintaining a perfect record of never actually executing anything of significant worth at his company.

As a matter of fact – the issue is not smarts but believing that organizational constructs are security countermeasures in disguise.

So – how do you detect the people (even the smart ones) who are threats to PHI, intellectual property and system availability:

  1. Their hair is better organized then their thinking
  2. They walk around the office with a coffee cup in their hand and when they don’t, their office door is closed.
  3. They never talk to peers who challenge their thinking.   Instead they send emails with a NATO distribution list.
  4. They are strong on turf ownership.  A good sign of turf ownership issues is when subordinates in the company have gotten into the habit of not challenging the VP coffee-cup holding persons thinking.
  5. They are big thinkers.    They use a lot of buzz words.
  6. When an engineer challenges their regulatory/procedural/organizational constructs – the automatic answer is an angry retort “That’s not your problem”.
  7. They use a lot of buzz-words like “I need a generic data structure for my device log”.
  8. When you remind them that they already have a generic data structure for their device log and they have a wealth of tools for data mining their logs – amazing free tools like Elasticsearch and R….they go back and whine a bit more about generic data structures for device logs.
  9. They seriously think that ISO 13485 is a security countermeasure.
  10. They’d rather schedule a corrective action session 3 weeks after the serious security event instead of fixing it the issue the next day and documenting the root causes and changes.

If this post pisses you off (or if you like it),  contact danny Lieberman me.  I’m always interested in challenging projects with people who challenge my thinking.

Tell your friends and colleagues about us. Thanks!
Share this
Security is not fortune telling

The top 5 things a medical device vendor should do for HIPAA compliance

We specialize in software security assessments, FDA cyber-security and HIPAA compliance for medical device vendors in Israel.

The first question that every medical device vendor CEO asks us is “What is the fastest and cheapest way for us to be HIPAA-compliant”?

So here are the top 5 things a medical device vendor should do in order to achieve HIPAA compliance:

1. Don’t store EPHI

If you can, do not store EPHI in your system at all.  That way you can side-step the entire HIPAA compliance process.    (This is not to say that you don’t have to satisfy FDA cyber-security requirements or have strong software security in general but that is a separate issue).

What is EPHI? EPHI (electronic protected health information) is any combination of PII (personally identifiable information and any clinical data.   OK – you ask so what is the definition of PII from the perspective of HIPAA?   Basically – PII is any combination of data that can be used to steal someone’s identity – in a more formal sense – here is a list of PHI identifiers:

  1. A name
  2. An address. The kind that FedEx or USPS understands
  3. Birth dates – age does not count.
  4. Phone numbers including (especially) mobile phone
  5. Email addresses
  6. Usernames of online services
  7. Social Security numbers
  8. Medical record numbers
  9. Health plan beneficiary number
  10. Account numbers
  11. Certificate/license numbers – any number that identifies the individual. A certificate on winning a spelling bee in Junior High doesn’t count.
  12. Vehicle identifiers and serial numbers, including license plate numbers;
  13. Device identifiers and serial numbers that can be tied back to a person
  14. URLs – that can be tied back to a person using DNS lookups
  15. IP address – for example the IP address of a home router that can be used to lookup an identify a person
  16. Biometric identifiers, including finger and voice prints;
  17. Full face pictures

2. If you store EPHI do a threat analysis of your medical device

The HIPAA Security Rule and the FDA cyber security guidance are very clear on this point. You can learn more about threat modeling and analysis here, here and here. Regarding encryption and medical device security, read this.

3. Implement software configuration management and deployment tools

The best advice I can give a medical device vendor is to use Git.   If you use Azure or are a Microsoft shop (our condolences – read here and here why Windows is a bad choice for medical devices) then TFS is a great solution that is integrated nicely in Azure. Note that Azure is a great cloud solution for Linux as well. Don’t get me wrong – Microsoft does a lot of things right.  But using Windows for medical devices is a really bad idea.

4. Implement log monitoring

Monitoring your logs for peaks in CPU, memory or disk usage is a great way to know if you’re being attacked.  But – if you have medical device logs and no one is home to answer the phone then it’s a waste of time.

5. Make sure the lights are on and some one is home

You’ve done a great job on your medical device software.   You did Verification and Validation and you implemented threat modeling in your development process and you have logs.  Just make sure that it’s someone knows that it’s their job to keep on eye on security events.   If you get a notice from a customer or a ping from your log manager, or an email from your cloud provider that they’re gonna reboot your services because of VENOM – just make sure the lights are on and some one is home.

 

 

 

In summary

Robust security for your medical is not fortune telling but neither is it an organizational construct.  The best way to think about your medical devices is to think about something you would give a child (or a soldier on the battle field). It has to totally reliable and safe for the patient even under the most adverse conditions.

 

Tell your friends and colleagues about us. Thanks!
Share this