Category Archives: Software security

Killed by code – back to the future

Back in 2011, I thought it’s only a question of time before we have a drive by execution of a politician with an ICD (implanted cardiac device).

Fast forward to Jan 9, 2017 FDA reported in a FDA Safety Communication on “Cybersecurity Vulnerabilities Identified in St. Jude Medical’s Implantable Cardiac Devices and Merlin@home Transmitter.

At risk:

  • Patients with a radio frequency (RF)-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Caregivers of patients with an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter
  • Cardiologists, electrophysiologists, cardiothoracic surgeons, and primary care physicians treating patients with heart failure or heart rhythm problems using an RF-enabled St. Jude Medical implantable cardiac device and corresponding Merlin@home Transmitter

I’ve been talking to our medical device customers about mobile security of implanted devices for over 4 years now.

I  gave a talk on mobile medical device security at the Logtel Mobile security conference in Herzliya in 2012 ago and discussed proof of concept attacks on implanted cardiac devices with mobile connectivity.

But – ICD are the edge, the corner case of mobile medical devices.  If a typical family of 2 parents and 3 children have 5 mobile devices, it is a reasonable scenario that this number will double withe devices for fetal monitoring, remote diagnosis of children, home-based urine testing and more.

Mobile medical devices are becoming a pervasive part of the Internet of things; a space of  devices that already outnumber workstations on the Internet by about five to one, representing a $900 billion market that’s growing twice as fast as the PC market.

There are 3 dimensions to medical device security – regulatory (FDA), political (Congress) and cyber (vendors implementing the right cyber security countermeasures)

The FDA is taking a tailored, risk-based approach that focuses on the small subset of mobile apps that meet the regulatory definition of “device” and that:

  • are intended to be used as an accessory to a regulated medical device, or
  • transform a mobile platform into a regulated medical device.

Mobile apps span a wide range of health functions. While many mobile apps carry minimal risk, those that can pose a greater risk to patients will require FDA review. The FDA guidance document  provides examples of how the FDA might regulate certain moderate-risk (Class II) and high-risk (Class III) mobile medical apps. The guidance also provides examples of mobile apps that are not medical devices, mobile apps that the FDA intends to exercise enforcement discretion and mobile medical apps that the FDA will regulate in Appendix A, Appendix B and Appendix C.

Mobile and medical and regulatory is a pretty sexy area and I’m not surprised that politicians are picking up on the issues. After all, there was an episode of CSI New York  that used the concept of an EMP to kill a person with an ICD, although I imagine that a radio exploit of  an ICD or embedded insulin pump might be hard to identify unless the device itself was logging external commands.

Congress is I believe, more concerned about the regulatory issues than the patient safety and security issues:

Representatives Anna Eshoo (D-CA) and Ed Markey (D-MA), both members of the House Energy and Commerce Committee sent a letter last August asking the GAO to Study Safety, Reliability of Wireless Healthcare Tech and report on the extent to which FCC is:

  • Identifying the challenges and risks posed by the proliferation of medical implants and other devices that make use of broadband and wireless technology.
  • Taking steps to improve the efficiency of the regulatory processes applicable to broadband and wireless enabled medical devices.
  • Ensuring wireless enabled medical devices will not cause harmful interference to other equipment.
  • Overseeing such devices to ensure they are safe, reliable, and secure.Coordinating its activities with the Food and Drug Administration.

At  Black Hat August 2011, researcher Jay Radcliffe, who is also a diabetic, reported how he used his own equipment to show how attackers could compromise instructions to wireless insulin pumps.

Radcliffe found that his monitor had no verification of the remote signal. Worse, the pump broadcasts its unique ID so he was able to send the device a command that put it into SUSPEND mode (a DoS attack). That meant Radcliffe could overwrite the device configurations to inject more insulin. With insulin, you cannot remove it from the body (unless he drinks a sugary food).

The FDA position that it is sufficient for them to warn medical device makers that they are responsible for updating equipment after it’s sold and the downplaying of  the threat by industry groups like The Advanced Medical Technology Association is not constructive.

Following the proof of concept attack on ICDs by Daniel Halperin from the University of Washington, Kevin Fu from U. Mass Amherst et al “Pacemakers and Implantable Cardiac Defibrillators:Software Radio Attacks and Zero-Power Defenses”  this is a strident wakeup call to medical device vendors  to  implement more robust protocols  and tighten up software security of their devices.

Tell your friends and colleagues about us. Thanks!
Share this
Information Security Best Practices

What is more important – patient safety or hospital IT?

What is more important – patient safety or the health of the enterprise hospital Windows network?  What is more important – writing secure code or installing an anti-virus?

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.

Continue reading

Tell your friends and colleagues about us. Thanks!
Share this
safeguard your head office small business

How to secure your data when firing employees

 

What kind of risk are you creating when you fire the IT security officer?

When a company decides to fire a big piece of it’s work force – it’s to reduce costs in anticipation of reduced revenues. Risk management and IT governance runs a distant second and third when it’s a question of survival. The IT department is often in the line of fire, since they’re a service organization. The IT security staff may be the first to get cut since  companies view information security as a luxury, not as a must to run the business.

There is nothing in the information security policy of any organization that I have seen that talks about how to manage risk when 300 employees are being fired in a short period of time in a business unit.

What is your risk appetite?

A key part of formulating and establishing information security   policies for your organization is in deciding how much risk is   acceptable and how to minimize unacceptable risk.

This process initially involves undertaking a formal risk assessment which is a  critical part of any ISMS.  However – it’s a mistake to assume that risk assessment is a static process when the business is a dynamic process.  Risk assessment must be dynamic and continuous, moving at the front line of the business not as an after though or not at all.

The ISO 27000 standards provide some guidance on how this  risk assessment process is to be undertaken.  This guidance is   summarized and annotated below:

  • Use systematic approach to estimate magnitude of risks (risk  analysis)
  • Compare estimated risks against risk criteria to measure the  significance of the risk (risk evaluation)
  • Define the scope of the risk assessment process to improve  effectiveness (risk assessment)
  • Undertake risk assessments periodically to address changes in  assets, risk profiles, threats, safeguards, vulnerabilities and risk  appetite (risk management)
  • Risk measurement should be undertaken in a methodical manner to  produce verifiable results (risk measurement)

The stumbling block to doing continuous risk assessment is both world view (“hire a consultant once every 2 years to check us out”) and technical (“the cost of said consultant”).  We have a great  free ISO 27001 risk assessment software that can automate the process, save you money and help you respond fast to changes in the business. The software is based on the popular PTA (practical threat analysis) Professional risk assessment tool.

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
skin mounted medical devices

Shock therapy for medical device malware

Israel has over 700 medical device vendors.  Sometimes it seems like half of them are attaching to the cloud and the other are developing mobile apps for all kinds of crazy, innovative applications like Healthy.io ( Visual Input Turned Into Powerful Medical Insight – translation: an app that lets you do urine analysis using your smart phone).

But – let’s not forget that many Medical devices  such as bedside monitors, MRI, nuclear medicine and  catheterization devices all reside on today’s hospital enterprise network.

An enterprise hospital network is a dangerous place.

Medical devices based on Microsoft Windows  can be extremely vulnerable to attack from hackers and malware who penetrate the hospital network and exploit typical vulnerabilities such as default passwords.

More importantly – medical devices that are attached to a hospital network are a significant threat to the hospital network itself since they may propagate malware back into the network.

While a thorough software security assessment of the medical device and appropriate hardening of the operating system and user-space code is the best way to secure a medical device in a hostile hospital network – this is not usually an option for the hospital once the medical device is installed.

Taking a page out of side-channel attacks and using the technique to detect malware, University of Michigan researchers have developed WattsUpDoc, a system designed to detect malware on medical devices by noting small changes in their power consumption.

The researchers say the technology could give hospitals a quick way to identify medical devices with significant vulnerabilities.

The researchers tested WattsUpDoc on an industrial-control workstation and on a compounder, which is used to mix drugs.

The malware detector first learned the devices’ normal power-consumption patterns. Then it tested machines that had been intentionally infected with malware. The system was able to detect abnormal activity more than 94 percent of the time when it had been trained to recognize the malware, and up to 91 percent of the time with previously unknown malware. The researchers say the technology could alert hospital IT administrators that something is wrong, even if the exact virus is never identified.

For the full article see WattsUpDoc

 

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

Software in Medical Devices – Update

We have previously written about various aspects of the software development process, especially, the verification and validation activities in implanted and invasive medical devices.

Here is  an update on what is happening in the regulatory arena and how the regulatory groups are checking up on what we are doing.

Software Recalls 2012

The estimate for software recalls by the FDA for 2012 is 173. The software recalls for 2011 were 177 and for 2010 were 76. So far there are quite a few software recalls in 2013.

There are a number of new guidances and standards released and soon to be released – it’s worth getting up to speed if you are developing software for medical devices and concerned about reliability and software security:

  1. 21 CFR 880.6310, Medical Device Data Systems, FDA – released. This standard relates to hardware or software products that transfer, store,convert formats, and display medical device data. This application can be defined as a medical device which is a Class I device instead of the classification of your system. It has been used by a number of companies to define gateways between systems.
  2. ISO 82304-1, Healthcare Software Systems – Part 1: General Requirements For Product Safety – to be released maybe later this year. There is a draft copy out. This relates to medical devices that are only software. 
  3. MEDDEV 2.1/16, January 2012 – Guidelines on the qualification and classification of standalone software used in healthcare within the Regulatory framework of medical devices 4) ISO/IEC TIR 80002-1:2009, Medical device software – Part 1: Guidance on the application of ISO 14971 to medical device software – refers to the risk analysis on the software. This is an interesting aspect as we tend to analyze the risks on a system level.  If you have any questions please contact us. 
  4. ISO/IEC TR 80002-02, Medical device software – Part 2: Validation of software for regulated processes – to be released maybe later this year. This refers to software used in the all other aspects in the organization. 
  5. IEC 80001-1:2010, Application of Risk Management for IT Network incorporating Medical Devices – This is the risk management doctrine for hospitals, etc. employing medical devices on the network. If you supply your system to a hospital, you may be requested to let the hospital know if you are 8001 compliant. Once we know more on this, we’ll update you. 
  6. AAMI TIR45:2012, Guidance on the use of agile practices in the development of medical device software – This is a technical report from the AAMI on the use of Agile in the software development.
  7. AAMI/ANSI SW87:2012, Application of Quality Management System concepts to Medical Device Data Systems (MDDS) – provides guidance for Application of Quality Management System concepts to Medical Device Data Systems (MDDS) 
  8.  AAMI TIR on Guidance on Health Software Safety and Assurance – future release
  9.  AAMI TIR on Classification of defects contributing to unacceptable risk in health software – future release

Click here to download the full article on FDA standards and guidance and software in medical devices  Software Update 020613

Courtesy of my colleague Mike Zeevi

Tell your friends and colleagues about us. Thanks!
Share this
selling security products with fear, ignorance and online marketing

The mistakes you will make on your next cloud project

Are you considering cloud security in the abstract or cloud security in your software?

Looking at cloud security issues in the abstract, we see 4 areas of concern:

  1. Mobility of Resources and multi-tenancy
  2. Identity and access management
  3. Data protection
  4. Incident response and assessment

When choosing a cloud solution for your business application, it is easy to get dragged into a low level engineering discussion of these issues.

However, we don’t implement things in the abstract; we implement real-life applications in the cloud.

Our decisions on implementing security countermeasures in the cloud should actually not be a function of  4 abstract security concerns but of  business and security management decisions:

  1. The cloud service model you choose. This is a business decision constrained by software engineering factors.
  2. How you detect and mitigate your application vulnerabilities. This is a security management decision.

The cloud service model is supremely important and is closely tied to your business requirements.  If you are a business unit manager at healthcare provider looking to implement a private social network for healthcare, you will be looking at SaaS alternatives.  If you are a VP engineering at a company developing business analytics, you will be considering PaaS or IaaS service models where the language support is one of your key drivers. If you are a Java shop and the BigTable key-value data model used by Google App Engine appeals to you, then Google App Engine may be your best fit.  On the other hand, if you are a Ruby shop, you may want to consider Heroku.

Once you choose a cloud service model, you should spend as much time as possible doing threat modeling of your software and estimating your value at risk.

Since buggy software is insecure software, and since most bugs are baked into the design, and since it’s cheaper to fix bugs in software at the beginning of the software life cycle – it’s about getting the software architecture right and then doing the implementation well and not about bolting on some third-party application security firewall rented out to you by your cloud service provider.

Service models

Mobility of Resources and multi-tenancy is are a core requirement for a cloud service provider. If he’s doing a good job, it’s his first order of business,  not your first order of concern.

Regarding  Incident response and assessment, if your cloud provider is proactive, that is a very good sign that Incident response and assessment will be handled properly.  If he waits for you to tell him that there is a hacking issue on your server, then it’s time to start looking for a different cloud service provider.

Identity and access management are part of your application. The architecture and deployment of your application is influenced by your choice of service model but it’s still your code running in the cloud.

Data protection is either some, not or all your responsibility depending on the service model and your software applications. This is why we need to do threat analysis on the software and consider data protection as one of the areas of concern.

Choosing the right cloud service model

The market is shaking out right now and in any given segment there are only 2 or 3 players you should be considering.

SaaS

High integration, low flexibility, high vendor lock-in Meant for end-users. Think SF.com

PaaS

Less integration, mid flexibility, medium vendor lock-in Meant for application developers. Think Google App Engine, Appforce.com, heroku, Azure

IaaS

No integration, total flexibility, low vendor lock-in. Good for engineers. Think Amazon WS, Rackspace Cloud

2 management mistakes you will probably make on your next cloud project

  1. Overengineering defense in depth and
  2. Ignoring or mis-estimating your application software threat surface

This is a situation we often see with product development companies that develop a cloud service using IaaS (infrastructure as a Service) where they  implement too many controls in too many layers and ignore or minimize  the threat surface of the application software for security and compliance breaches.

Overengineering defense in depth

You can over-engineer your  defense in depth strategy and implement Firewall, load balancers, IPS in multiple layers in the cloud: in the WAN, on the LAN, in the virtual machines  and in hardware appliances.  The more layers you have, the more things that can go wrong. You will be more vulnerable instead  of being more secure and you will have to deal with half a dozen new issues that you created your self:

  1. Patch management is hard
  2. Different management systems, since each layer has it’s own management
  3. Different administrators, since each management system has it’s own admin
  4. Visibility for the end user customer is impossible
  5. Almost impossible to audit

What things can go wrong when you ignore application threat surfaces?

Lots. DB exploits Connector vulnerabilities Shell script vulnerabilities SQL injection DDOS, information disclosure by malicious insiders.

Typical Web 2.0 attack scenarios

Here are a few you should be thinking about:

  1. Any kind of code injection
  2. Server or client returns invalid HTML
  3. Pages that contain dead links
  4. HTML forms that don’t match field types expected by controllers
  5. Client side code that makes bad assumptions about AJAX services
  6. Servers  that may attempt to execute invalid SQL queries
  7. Improper marshaling/un-marshaling between DB server to Web server DB server to application tier Web server to browser

Typical Web 2.0 vulnerabilities

Here are a few you should be thinking about:

  • Running a number of heterogeneous stacks guarantees too much chewing gum
  • Mixing  languages and frameworks may be problematic causing typing and interface issues.
  • PHP, Ruby, Python Flexibility, no static type guarantees
  • C#, Java Static typed, but only at Web server
  • Code complexity that increases application threat surfaces.
  • Redundant code on servers and clients
  • Redundant data on servers and clients

Summary

At the end of the day, the Cloud Security Control model looks great, but it doesn’t mitigate core vulnerabilities in your software or tendencies by system architects to over engineer. Once you choose the right service model and vendor, you should put aside the cloud security reference models and focus on hardening your own application software –

Remember – it’s your code that will be running in someone elses cloud.

Tell your friends and colleagues about us. Thanks!
Share this
skin mounted medical devices

Bionic M2M: Are Skin-mounted M2M devices – the future of eHealth?

In the popular American TV series that aired on ABC in the 70s, Steve Austin is the “Six million Dollar Man”, a former astronaut with bionic implants. The show and its spinoff, The Bionic Woman (Lindsay Wagner playing a former tennis player who was rebuilt with bionic parts similar to Austin after a parachuting accident) were hugely successful.

Modern M2M communication has expanded beyond a one-to-one connection and changed into a system of networks that transmits data to personal appliances using wireless data networks.

M2M networks are much much more than remote meter reading.

The fastest growing M2M segment in Germany, with an average annual growth of 47 percent, will be from consumer electronics with over 5 M2M SIM-cards. The main growth driver is “tracking and tracing”. (Research by E-Plus )

What would happen if the personal appliance was part of the person?

Physiological measurement and stimulation techniques that exploit interfaces to the skin have been of interest for over 80 years, beginning in 1929 with electroencephalography from the scalp.

A new class of electronics based on transparent, flexible 50micron silicon film laminates onto the skin with conformal contact and adhesion based on van der Waals interaction. See: Epidermal Electronics John Rogers et al. Science 2011.

This new class of device is mechanically invisible to the user, is accurate compared to traditional electrodes and has RF connectivity.  The thin 50 micron film serve as temporary support for manual mounting of these systems on the skin in an overall construct that is directly analogous to that of a temporary transfer tattoo, as can be seen in the above picture.

Film mounted devices can provide high-quality signals with information on all phases of the heartbeat, EMG (muscle activity) and EEG (brain activity). Using silicon RF diodes, devices can provide short-range RF transmission at 2Ghz.  Note the antenna on the device.

After mounting it onto the skin, one can wash away the PVA and peel the device back with a pair of tweezers.  When completely removed, the system collapses on itself because of its extreme deformability and skin-like physical properties.

Due to their inherent transparent, unguarded, low cost and mass-deployed nature, epidermal mounted medical devices invite new threats that are not mitigated by current security and wireless technologies.

Skin-mounted devices might also become attack vectors themselves, allowing a malicious attacker to apply a device to the spine, and deliver low-power stimuli to the spinal cord.

How do we secure epidermal electronics devices on people?

Let’s start with some definitions:

  • Verification means is the device built/configured for its intended use (for example measuring EMG activity and communicating the data to NFC (near field communications) device.
  • Validation means the ability to assess the security state of the device, whether or not it has been compromised.
  • RIMs (Reference Integrity Measurements) enable vendors/healthcare providers define the desired target configurations of devices, for example, is it configured for RF communications

There are 3 key threats when it comes to epidermal electronics:

  1. Physical attacks: Reflashing before application to the skin in order to modify  intended use.
  2. Compromise of credentials: brute force attacks as well as malicious cloning of credentials.
  3. Protocol attacks against the device: MITM on first network access, DoS, remote reprogramming

What are the security countermeasures against these threats?  We can consider a traditional IT security model and a trusted computing model.

Traditional IT security model?

Very large numbers of low-cost, distributed devices renders an  access-control security model inappropriate. How would a firewall on an epidermal electronics device enforce intended use, and manage access-control policies? What kind of policies would you want to manage? How would you enforce installation of the internal firewall during the manufacturing process?

Trusted computing model?

A “trusted computing model”  may be considered as an alternative security countermeasure to access control and policy management.

An entity can be “trusted” if it predictably and observably behaves in the expected manner for its intended use. But what does “intended use” mean in the case of epidermal electronics that are used for EKG, EEG and EMG measurements on people?

Can the traditional, layered, trusted computing models used in the telecommunications world be used to effectively secure cheap, low-cost, epidermal electronics devices?

In an M2M trusted computing model there are 3 methods:  autonomous validation, remote validation and semi-autonomous validation. We will examine each and try and determine how effective each model is as a security countermeasure for the key threats of epidermal electronics.See: “Security and Trust for M2M Communications” – Inhyok Cha, Yogendra Shah, Andreas U. Schmidt, Andreas Leicher, Mike Meyerstein

Autonomous validation

This is essentially the trust model used for smart cards, where the result of local verification is true or false.

Autonomous validation does not depend on the patient herself or the healthcare provider. Local verification is assumed to have occurred before the skin-mounted device attempts communication or performs a measurement operation.

Autonomous validation makes 3 fundamental assumptions – all 3 are wrong in the case of epidermal electronics:

  1. The local verification process is assumed to be perfectly secure since the results are not shared with anyone else, neither the patient nor the healthcare provider.
  2. We assume that the device itself is completely trusted in order to enforce security policies.
  3. We assume that a device failing self-verification cannot deviate from its “intended use”.

Device-based security can be broken and cheap autonomous skin-mounted devices can be manipulated – probably much easier than cell-phones since for now at least, they are much simpler. Wait until 2015 when we have dual core processors on a film.

In addition, autonomous validation does not mitigate partial compromise attacks (for example – the device continues to measure EMG activity but also delivers mild shocks to the spine).

Remote validation

Remote validation has connectivity, scalability and availability issues. It is a probably a very bad idea to rely on network availability in order to remotely validate a skin-mounted epidermal electronics device.

In addition to the network and server infrastructure required to support remote validation, there would also be a huge database of RIMs, to enable vendors and healthcare providers define the target configurations of devices.

Run-time verification is meaningless if it is not directly followed by validation, which requires frequent handshaking with central service providers, which in turn increases traffic and creates additional vulnerabilities, such as side-channel attacks.

Remote validation of personally-mounted devices compromises privacy since the configuration may be virtually unique for a particular person and interception of validation messages could reveal the identity based on location even without deccrypting payloads.

Discrimination by vendors also becomes possible, as manipulation and control of the RIM databases could lock out other applications/vendors.

Semi-Autonomous Validation

Semi-autonomous validation divides verification and enforcement between the device and the healthcare provider.

In semi-autonomous validation, the device verifies itself locally and then sends the results in a network message to the healthcare provider who can decide if he needs to notify the user/patient if the device has been compromised or does not match the intended use.

Such a system needs to ensure authentication, integrity, and confidentiality of messages sent from epidermal electronics devices to the healthcare provider.

RIM certificates are a key part of semi-autonomous validation and would be signed by a trusted third party/CA.

Semi-autonomous validation also allows for more granular delegation of control to the device itself or the healthcare provider – depending on the functionality.

Summary

Epidermal electronics devices are probably going to play a big part in the future of healthcare for monitoring vital signs in a simple, cheap and non-invasive way.  These are medical devices, used today primarily for measuring vital signs that are directly mounted on the skin and not a Windows PC or Android smart phone that can be rebooted if there is a problem.

As their computing capabilities develop, current trusted computing/security models will be inadequate for epidermal electronics devices and attention needs to be devoted as soon as possible in order to build a security (probably semi-autonomous) model that will mitigate threats by malicious attackers.

 References

  1. Security and Trust for M2M Communications – Inhyok Cha, Yogendra Shah, Andreas U. Schmidt, Andreas Leicher, Mike Meyerstein
  2. Epidermal Electronics John Rogers et al. Science 2011.
Tell your friends and colleagues about us. Thanks!
Share this

Free risk assessment of your web site

With all the news about credit card breaches, there are probably a lot of people scurrying about trying to figure out the cheapest and fastest way to reduce the risk of some Saudi hacker stealing credit cards or mounting a DDOS attack on their web site.

I have written here, here and here about how to reduce the risk of a data breach of a web site.

Not to rain on the media party, but the actual cost to a online marketer of a hacker breaching a web site or defacing the web site could be very low since card-holders are covered by the credit card issuers and as long as the online commerce site continues operation, a temporary revenue dip might be offset by additional visits to the publicity.

Then again, the cost of a data breach to your operation could be very high, especially if you scrimp on security.

So – what is the right answer?

The right answer is the right security for your web site at the right cost to your pocket, not what Symantec says or what Microsoft says but what your risk assessment says.

In order to implement the most cost-effective security for your web site, you need to do a risk assessment that takes into consideration the value of your assets, the probability of attacks,  current vulnerabilities of your web site and operation (don’t forget that trusted insiders may be the more significant vulnerability in your operation) and possible countermeasures, including the cost of said countermeasures.

Sounds complex, right?

Actually – performing a threat analysis of  your web site can be a fairly straightforward exercise using the free risk assessment software provided by PTA Technologies.

You can download the free risk assessment software here and start improving your security today.

Any questions – feel free to reach out to the professional software security consultants in Israel at Software Associates.

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