Software Associates specializes in helping medical device vendors achieve HIPAA compliance and improve the data and software security of their products in hospital and mobile environments.

A threat analysis was performed on a medical device used in intensive care units.  The threat analysis used the PTA (Practical threat analysis) methodology.

Our analysis considered threats to three assets: medical device availability, the hospital enterprise network and patient confidentiality/HIPAA compliance. Following the threat analysis, a prioritized plan of security countermeasures was built and implemented including the issue of propagation of viruses and malware into the hospital network (See Section III below).

Installing anti-virus software on a medical device is less effective than implementing other security countermeasures that mitigate more severe threats – ePHI leakage, software defects and USB access.

A novel benefit of our approach is derived by providing the analytical results as a standard threat model database, which can be used by medical device vendors and customers to model changes in risk profile as technology and operating environment evolve. The threat modelling software can be downloaded here.

I.             Introduction

A threat analysis was performed on a medical device used in intensive care units. The analysis considers the security implications of deploying the devices inside a hospital network. Different stakeholders have different security and compliance concerns and therefore different agendas.

• Hospital IT management  - do the medical devices create new entry points for viruses and malware in the enterprise network?
• Medical device vendor and patient care staff – can we assure availability and integrity of the monitoring data?
• Hospital management – can we comply with HIPAA and reduce the risk of data leakage?

System configuration

The embedded system configuration is based on an Intel processor running Windows XP Embedded.  The devices are not members of a Microsoft Active Directory domain and do not have Internet connectivity.

The threat analysis process

A data collection phase employed face to face interviews with software and hardware developers and directly examined the medical device software and hardware. We identified potential attackers, entry points, threats, vulnerabilities and security countermeasures (those already implemented and those that might be implemented).  Following data collection, we performed a threat analysis using the PTA (Practical Threat Analysis) methodology summarized in Appendix A and described at length on the PTA Technologies web site.

Threat model entities

Our threat model uses four base classes; mapping assets to vulnerabilities, threats that exploit vulnerabilities and countermeasures that mitigate vulnerabilities.

For example:

The key assets were medical device availability, the hospital enterprise network and patient confidentiality. We received input from hospital IT management regarding annual rates of occurrence of virus and malware attacks (rare) and phishing attacks on hospital employees (the usual email-borne pharmacy scams etc…).

II.           Top unmitigated threats

After building the threat model with the four base classes and their relationships, we estimated the probability of threat occurrence, percent damage to assets and risk mitigation effectiveness.   Trusted insider information leakage event frequency was estimated as twice/year in the threat model, while virus, denial of service and malware attacks frequency were estimated to be rare (less than once every 3 years).  Hospital IT were primarily concerned with the health of their enterprise network (as opposed to the availability of the medical devices) – described in threat T017.

The 5 most severe unmitigated threats in our model (shown below), are derived using the PTA calculative method (http://www.ptatechnologies.com/?action=4pta), which takes into account estimated asset value, threat probability and  percent damage due to a threat event.

The TXXX identifiers in the left hand column refer to the entities in our model.

Removing electronic Protected Health Information (ePHI) from the medical device

Unauthorized disclosure of ePHI (T002) was nominally the most severe threat at the start of the analysis due to compliance (HIPAA) / patient privacy concerns.

Protected health information (PHI) is any information in the medical data set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis or treatment.

Following the threat analysis, it was decided to remove all personally identifying information and use an alphanumeric designator, displayed on the medical device screen and at a central management station. Nurses can respond quickly to alarms of changes in patient signs (heart/respiratory rate) reported by a particular bedside unit without being exposed to personally identifiable information.

After removing ePHI, the risk assessment changed and the threat of the medical device infecting the hospital enterprise network (T017) then became our primary concern.

III.          Recommended countermeasure plan

Using the PTA quantitative threat model, we then calculated a prioritized plan of security countermeasures as shown in the following table. The below table is sorted according to recommended priority of implementation in terms of risk mitigation effectiveness. After implementing the below countermeasures, the calculative model estimates a residual risk of less than 3% to system assets.

Security countermeasures plan

The TXXX and CXXX numeric identifiers refer to threat and countermeasure entities in our threat model.

Patch management

The question of patch / update management always arises in the course of a threat analysis of medical devices;  the results are perhaps counterintuitive for typical IT managers:

• IT policy of running automated Windows Update on Windows PCs in the office is not necessarily a relevant countermeasure for embedded medical devices.

• Although FDA 510(K) recertification of the medical device may not be necessary when applying security patches – running Windows Update is practically impossible in an embedded device that does not have Internet access. The medical device vendor would typically apply patches to the embedded image as part of ongoing device field maintenance.

We note that an ICO medical device  is a specialized (not COTS) embedded device that does not have Internet or removable device connectivity. The device does not run MS Office, does not run IE and is not connected to the Internet and therefore has a much smaller threat surface than a typical Windows PC installed on the hospital network.

For these reasons, we focused our efforts on security countermeasures that would reduce the most severe threats – ePHI leakage, software defects and USB access to the medical device itself.

IV.         Propagation of viruses/malware in the enterprise network

One of the key security concerns when operating networked, Windows-based embedded medical devices is whether new entry points for viruses and malware are created in the enterprise network.

We sub-divided this concern into 3 separate threat scenarios:

1. Can the medical devices be infected from the enterprise network?
2. Can the medical devices be infected via USB devices?
3. Can infected medical devices propagate malicious software back into the enterprise network?

Can the medical devices be infected from the enterprise network?

The short answer is no.

The medical device analyzed in the study uses Windows XP Embedded and a proprietary TCP/IP messaging protocol in order to communicate with a central management station.

The operating system itself is hardened, does not run Windows shell, does not run IE and shuts down all unneeded services such as SMB and RPC. In addition, it runs a Windows Firewall instance that blocks all ports except the TCP/IP listener ports.

Although a dedicated attacker with the right skill set might be able to sniff traffic, reverse engineer the protocol and fuzz, there is always the question of whether or not the value of the asset justifies the cost of the attack.  In this particular medical device, considering the hardware configuration and use of a proprietary messaging protocol; we felt that the medical device was not particularly vulnerable to such attacks.

1. 2. Can the medical devices be infected via USB devices?

The short answer is yes – potentially by anyone who inserts an infected USB removable storage device.

We have addressed this vulnerability in countermeasure C048 – “Implement an IO-board hardware toggle for enabling/disabling USB ports”. We also strongly recommended migration to Linux – with no USB auto-run functions (see next section).

1. 3. Can USB-infected medical devices propagate malicious software back into the enterprise network?

The short answer is yes.

Although the proprietary request/response communications protocol used by the units cannot be used to transport files to other Windows PCS, a worm such as Conficker can exploit vulnerabilities in Windows services, disable the Windows firewall and propagate from the source computer to the hospital network on an arbitrary port between 1024 and 10000.

V.           Future: segregation of bio-med and IT domains

While hospital IT systems typically use Microsoft Windows; for an embedded medical device, we highly recommend using Linux due to its ease of maintenance and resistance to USB exploits and worms such as Conficker that exploit Windows software.  A suggested minimal configuration should consist of an up-to-date Linux kernel, QT, touch-screen, network support and a main loop to run the medical device application.  A more detailed discussion of the proposed Linux implementation is beyond the scope of this article. See the excellent article “The Top 10 mistakes embedded Linux developers make for some guidelines“.

VI.         Summary

A threat analysis of a networked medical device was performed and a mitigation plan of countermeasures was produced, including recommended priority of implementation.  As a result of the analysis, it was decided to modify the medical device design and not to store ePHI. This is obviously the most effective countermeasure possible for HIPAA compliance and protecting patient privacy. In addition, a decision was taken to migrate the medical device OS platform to embedded Linux to eliminate typical Microsoft Windows network and removable device vulnerabilities.

In this post I want to talk about 5 mistakes CIOs make:

1. Rely on fixed controls

Any information security professional will tell you that security countermeasures are comprised of people, processes and technology.  The only problem is that good security depends on stable people, processes and technology. A stable organization undergoing rapid and violent change is an oxymoron.  Visualize your company has ISO 27001 certification but the stock drops by 90% because of an options back-dating scandal at the top, the company fires 900 employees and all of a sudden, the fixed controls are not as effective as you thought they were.  Think about the Maginot Line in WWII.

2. Train for security awareness

Security awareness training is probably a hopeless waste of resources considering the increasing number of options that people have (Facebook, smartphones..) to do stuff that causes damage to the business.Security awareness will lose every time it comes up against an iPad or Facebook.

People countermeasures should be a mix of common-sense, background checks (at a depth proportional to job exposure to sensitive assets), and deterrence.  Andy Grove once said “Despite modern management theory regarding openness – a little fear in the workplace is not a bad thing”.  When a lot of employees are RIF‘d – there is a lot of anger and people who don’t identify with their employer; the security awareness training vaporizes and fear and revenge take over. Some of the security people will be the first to go, replaced by contractors who may not care one way or the other or worse – be tempted by opportunities offered by the chaos.

Why is  common sense a good alternative to awareness training? Common sense  is easy to understand and enforce if you keep it down to 4 or 5 rules:  maintain strong passwords, don’t visit porn sites, don’t blog about the business, don’t insert a disk on key from anyone and maintain your notebook computer like you guard your cash.

3. Manage GRC processes (while the hackers are attacking your software)

It’s a given that business processes need to be implemented in a way that ensures confidentiality, integrity and availability of customer data.  A simplistic example is a process that allows a customer service representative to  read off a full credit card number to a customer. That’s a vulnerability that can be exploited by an attacker.  But – that’s a trivial example – while you’re busy managing processes and using security theater code words – the attackers are attacking your software and stealing your data.

4. Rely on defense in depth (instead of questioning your defenses)

Technology countermeasures are not a panacea – and periodically you have to step back and take a look at your security portfolio both from a cost and effectiveness perspective.  You probably reply on a defense in depth strategy but end up with multiple, sometimes competing and often ineffective tools at different layers – workstation, servers and network perimeter.

Although defense-depth is a sound strategy – here are some of the fault lines that may develop over time:

5. Align with the business (instead of investing in competence)

Business alignment is one of those soft skill activities that keep people in meetings instead of mitigating systems vulnerabilities – which requires hard professional skills and high levels of professional security competence. It’s a fact of life that problem solvers hate meetings and rightly so – you should invest in competence and go light on the business alignment since it will never stop the next data breach.

Claudiu Popa, president and chief security officer of data security vendor Informatica Corp. told  Robert Westervelt in an interview  on searchsecurity.com that:

…once an organization reaches the right level of maturity, security measures will not only save time and money, but also contribute to improved credibility and efficiency.

This is nonsense – security is a cost  and it rarely contributes to efficiency of a business (unless the business can leverage information security as part of it’s marketing messages) and as  for an organization firing 30% of it’s workforce over night – words like maturity, credibility and efficiency go out the door with the employees.

At that point –  highly competent and experienced security professionals who are thinking clearly and calmly are your best security countermeasure.

How does your company mitigate the risk of data security threats?

Is your company management adopting a policy of “It’s other peoples money”?

In a recent thread on LinkedIn - Jody Keyser shared some quotes from David Vose’s book on risk, reliability and computerized risk modeling:  Risk Analysis a quantitative guide.

The responses to correctly identified and evaluated risks are many but generally fall into one of the following categories:

- Cancel Project
- Eliminate ( do it another way)
- Transfer (insure back to back contract)
- Share (with partner or contractor )
- Reduce (take a less risky approach)
- Add a contingency (increase budget, deadline etc.,to allow for possibility of risk)
- Collect more data to better understand risk
- Do nothing (cost is just too dang high)
- Increase ( maybe the plan is too cautious )

In my experience – when it comes to data security, data loss prevention, DLP projects – the top 2 responses to data security threats are “accept the risk” followed by “cancel the project” in a close second place.

The other alternatives are almost all non-starters. The question is – why?

Eliminating risk by changing the business process is often not an option or too much trouble for employees. For example – consider the process of transferring documents to external contractors – even though it’s trivial to encrypt documents inside a Zip file and share the password – most companies don’t make it part of their security procedure and those that do require encryption of documents sent to external business partners, don’t deploy DLP monitoring to ensure compliance with the encryption policy.

There are multiple reasons for data security risk being accepted by business managers.  Most are related to cost, complexity, changing business requirements and a tacit disbelief in effectiveness of technology in preventing data theft and fraud.

The reasons for accepting data security risk are related to  the difference between being secure and feeling secure.  Since most companies don’t monitor data flows, they don’t know how many sensitive digital assets are being leaked to the competition – ergo they don’t have the empirical data to analyze their data security threats and measure data security risks in terms of dollar threat to the business.  This would lead to enable a business to deploy data security countermeasures and be secure at an acceptable cost. It would also enable them to measure the cost effectiveness of their data security technology and challenge their innate beliefs and skepticism.

However – the company management already feel secure because they have delegated that part of  the business to the information security folks and reading the papers tells them that customers (not the business management) pay the cost of a data security breach.

As a kid growing up in South Jersey – when there was the occasional report of an urban boondoggle or million dollar NASA toilets – my Dad (who worked for RCA on defense projects and knew about these things) would always use the expression – “Other peoples money” or if it was closer to home – “Pa’s rich and Ma don’t care”…which is really close to home this year for Americans as President Obama takes the US to an unprecedented $1.35 trillion budget deficit in  2010.

Last September, Forrester did a seminar in Amsterdam on data security – only 10% of the CTOs/CIOs that attended the meeting had plans to implement DLP in 2010.

The Europeans have a point – but, policies and procedures are only as good as the monitoring and enforcement behind them. This is where DLP comes into play- collecting data in several realms – data channels, content and organizational anomalies (downloads, uploads etc…).

In addition – there is a strong and well-known link between the social health of employees in an organization and the company’s economic/business health.  In a successful business unit – people are happy, and happy people contribute to the success of the business.   Unhappy people don’t identify, have problems contributing and leave or cross the line to malicious behavior.

For my money (and this is my experience in a dozen DLP deployments in EMEA) – the key value add of DLP technology is not the prevention part but the monitoring part and it’s role in a feedback / educational loop with the organization.

If you only do one thing this year – you should start measuring data security events and using those measurements to improve your policies, procedures and systems – and user education.

Leading up to the Al Quaeda attack on the US in 9/11, the FBI investigated, the CIA analyzed but no one bothered to discuss the impact of Saudis learning to fly but not land airplanes.

Dissonance in organizations is often resolved  by building separate silos of roles and responsibilities.

However, it is impossible to take wise decisions on risk management in the business when the risk intelligence is in separate silos.

We help protect customer data and intellectual property from fraud and breaches of confidentiality.  We’re always looking for interesting projects – call or text me at  +972 54 447 1114 at  any time.

Richard Stiennon is a well known and respected IT analyst – he has a blog called IT Harvest.

A recent post had to do with Trusted insider threats.Despite the length of the article, I believe that the article has a number of fundamental flaws:

• Overestimating  the value of identity and access management in mitigating trusted insider threats
• Lacking  empirical data to support the claim that “the insider threat actually outweighs the threats from cyber criminals, hackers and the malware”
• Missing a basic management issue of accountability

The role of identity and access management in preventing trusted insider security violations

Stiennon writes that IAM (Identity and access management) “is the single most valuable defense you have against the insider threat.”. I beg to disagree – and I will attempt to explain by using the model of a crime.

Like any other crime, in order to steal or disclose assets, a person needs a combination of means, opportunity, and intent

IAM provides the means for the trusted insider. Companies issue users legitimate user accounts with the rights to access certain data, applications, databases and file services. Insiders have knowledge of how the system works, the business processes, the company culture and how people interact. They know who manages the rights management systems and who grants systems permissions. With the right knowledge and social connections, means can be obtained even if they were not originally granted by design in the IAM system.

A trusted insider is an employee who is motivated by self-interest, influenced by personal preferences, social context, corporate culture and her aversion to risk taking compared with the premium gained by stealing data.   There is little in the traditional access control model to mitigate any of these threats once access has been granted.

In 100 percent of the cases we investigated in our data security practice – the client’s permissions systems were working properly, the trusted insiders involved all had been granted appropriate rights, they did not perform any elevation of privilege exploits – they took data that they had appropriate access to. Directors of new product development, system managers, sales managers – each and every one that took and/or abused data did so with appropriate permissions.

Lacking empirical data

“While often overlooked, the insider threat actually outweighs the threats from cyber criminals, hackers and the random malware that most organizations concentrate on”

Stiennon doesn’t bring any evidence for this populistic statement. As a research analyst, I would expect some independent numbers behind the statement. Au contraire Richard – according to our data security practice of over 5 years in Europe and the Middle East (and according to the Verizon Business report, the past 2 years),  insider events are a rare, high-impact event that are a complex interplay of agents ( criminals, competitors, business partners) and vulnerabilities (human and application software).

Missing a basic management issue of accountability
Stiennon talks about HR and IT. The truth is that there is a fundamental management disconnect between HR and IT (HR hires but has no accountability when an employee is involved in a security breach and gets fired) IT has some of the data and almost never shares it with HR. I suggest higher levels of HR accountability and involvement in data security together with their audit, IT and information security management colleagues.

I wrote about the great IT-management divide last year in my post on the 7th anniversary of the Al Queda attack on the US

We were group of 5 programmers – we had some nice accounts – like Intel, and National Semiconductor, Hadassah Hospital and Amdocs, but I always felt intimidated by the big IT integrators. One day – my DEC account manager told me that we should hold our heads high – he figured that our largest competitor didn’t have more than 1 or 2 experts at our level.

Are data security specialists like programmers – where the rock stars have 3 orders of magnitude better productivity than the average guy or gal?

And should we try to have one of these folks on the staff and make sure they are happy?

Now I think we have reached a new level of Microsoft sycophancy with the Obama administration implementing a Bush decision to standardize IT but in a way that makes practically no sense at all – let’s ban all non IE browsers.  It’s really scary to what lengths the Obama administration will go undo Bush policy.

In keeping with the requirements of the Federal Desktop Core Configuration, all third-party browsers will be removed from customer workstations beginning Tuesday, Aug.18. Internet Explorer is the standard browser and will be maintained. Netscape, Google Chrome and Firefox will be removed.”

It does make sense to standardize on a browser – but why standardize on the most vulnerable browser and operating system?  Why not standardize on Ubuntu and FF 3 on the desktop or standardize on diskless workstations with Citrix or TightVNC?

The full item is here – USDA unit bans browsers other than Internet Explorer

Talking with clients we stress threat modeling and analysis and doing quantitative risk analysis but I believe that psychology may be more important than the technology. This is for several reasons:

• Preventing data breach events is an admission of weakness. Data loss is caused by an attack launched from inside the company (whether by a trusted insider, business partner or malicious hacker). attacks that exploit internal vulnerabilities like the new Sharepoint server that the marketing team installed last week without consulting with the IT security team.  Who wants to spend  money on something when the first step is admitting that you’re vulnerable and that your existing security systems, policies and procedures do not meet business requirements?
• The need for instant gratification. Need to keep food fresh? – buy a fridge, Want music, voice, SMS, Web and mail? – buy an iPhone, Want IT security – buy a UTM appliance from Checkpoint or Cisco, want a CRM system – get salesforce.com, need a new enterprise software system – outsource to India. This is related to two other needs I think:
• The need to keep things simple and
• The need to walk on the safe side, not on the wild side.   Who wants to spend 6 figures on a DLP solution that requires a risk assessment from someone who isn’t your accountant,  a complex policy implementation by people who need to learn your business, integration with internal procedures and processes with employees who could care less, and buyin from a CEO who is scrappling for survival with the board during the biggest financial crisis in 80 years?

I will talk about how to sell DLP through the psychology and not the technology in an upcoming post. Stay tuned.

Like the warnings on cigarette packets – whistle blowing may be hazardous to your health.

HBOS chief risk officer Paul Moore blew the whistle on the bank’s risk exposure and lost his job. Last week, the UK Treasury Select committee heard allegations from  Moore ( who was sacked by Sir James Crosby in 2005) – that senior executives ignored repeated warnings about excessive risk-taking.

Following the political firestorm – Sir James Crosby has left his position as deputy chairman of the UK Financial Services Authority. Crosby was a close adviser to prime minister Gordon Brown, and former HBOS CEO – leading HBOS during a period of high-rolling profits.

Are there sins of hubris at your company – let me know!

It appears that chief executives at the big banking institutions like Lehman Brothers and AIG were totally out of touch with the realities of risk management.  Out of touch to the point where out of hubris – they were probably not even listening to the Cassandras in their organizations.  When your’e flying a private jet, taking home $10M in bonuses and staying at the premium class hotels – it’s tough to relate to bearers of bad news and it’s even harder for a middle manager to gain access to the big guys and sell a case that toxic assets, data breaches and and internal fraud that could kill the $10M bonus.