Category Archives: Information security

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
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
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

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
Courtesy of firstpost.com

Why your security is worse than you think

Thoughts for Yom Kippur – the Jewish day of atonement – coming up next Wed.

Security on modern operating systems (Windows, OS/X, iOS, Android, Linux) is getting better all the time – but  Android using SELinux and MAC (mandatory access control) doesn’t make for catchy, social-media-sticky news items.

A client (a good one) once told me that people never remember your successes, only your failures. (He also believed that all software developers are innately incapable of telling the truth but that’s another story).

The corollary to this notion of failure-skew in the business (and security) world is media reporting. Consider media emphasis on reporting violent and/or negative events. It’s not a hot news item to say that 39% of Israeli Arabs are proud to be Israeli nor is it newsworthy to report that 29% are very proud. The world (Middle East included) is actually a much better place then it seems when not viewed through the lens of social media news reporting and re-purposing (I’m not sure what the correct term for the Huffington Post is so I’ll just use the word repurpose).

FB and Twitter create discussion threads, not examination-of-empirical data threads. Discussion is easier, more fun and cheaper than collecting data and examining it’s quality.

In addition, radical voices are far more interesting than statistics. Who cares that according to World Bank statistics, in 1990 there were 1.91 billion people who lived on less than $1.25 a day an in 2011 it was just one billion. Radical voices (amusingly adopted by the US President) will continue to blame poverty on the rise in Islamic and Iranian terror even though it emanates from the wealthiest countries in the world.

The Jews over the world are up to bat this coming Wed on Yom Kippur. We can bemoan how bad things are and what a terrible President or PM we all have and how our society is falling apart, or we can take a little piece of our own life and fix it. Send thank you notes to people.  Patch your systems once/week. That’s a good start. And pretty easy to do.

Now what does this have to do with software security you ask?

Everything.

Our clients read social media.  They read about zero-days and they get all excited and then do nothing.

Yet another serious Android security issue was publicized this week, with the latest exploit rendering devices “lifeless,” and said to affect more than half of units currently on the market.  Latest Android security exploit could leave more than half of current devices ‘dead’ & unusable

Now let’s check out that URL – its from Apple Insider. Hmm – somebody has an ax to grind I bet.

Security on modern operating systems (Windows, OS/X, iOS, Android, Linux) is getting better all the time – but  Android using SELinux and MAC (mandatory access control) doesn’t make for catchy, social-media-sticky news items.

So this year – I mean this Wednesday – don’t wring your hands.  Do a security assessment on your systems and prioritize 1 thing, find that one weakest link in your system and harden it up.

 

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

14 years after 9/11, more connected, more social, more violent

Friday, today is the 14’th anniversary of the Al Queda attack on the US in New York on 9/11/2001.

The world today is more connected, more always-on, more accessible…and more hostile. There are threats from Islamic terror, identity theft, hacking for pay, custom spyware, mobile malware, money laundering and corporate espionage. For those of us working in the fields of risk management, security and privacy, these are all complex challenges in the task of defending a business.

The biggest challenge is the divide between IT and  management. It’s similar to the events leading up to 9/11: The FBI investigated and the CIA analyzed, but the two sides never discussed the threats and the potential damage of Saudis learning to fly, but not how to land airplanes.
Continue reading

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

The importance of risk analysis for HIPAA compliance

A chain of risk analysis

The HIPAA Final Rule creates a chain of risk analysis and compliance from the hospital, downstream to the business associates who handle / process PHI for the hospital and sub-contractors who handle / process PHI for the business associate.

And so on.

The first thing an organization needs to do is a risk analysis.   How important is a risk analysis?  Ask Cancer Care Group who were just fined $750,000 for non-compliance with the Security Rule.

$750,000 HIPAA settlement emphasizes the importance of risk analysis and device and media control policies

Cancer Care Group, P.C. agreed to settle potential violations of the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rules with the U.S. Department of Health and Human Services (HHS), Office for Civil Rights (OCR). Cancer Care paid $750,000 and will adopt a robust corrective action plan to correct deficiencies in its HIPAA compliance program. Cancer Care Group is a radiation oncology private physician practice, with 13 radiation oncologists serving hospitals and clinics throughout Indiana.

On August 29, 2012, OCR received notification from Cancer Care regarding a breach of unsecured electronic protected health information (ePHI) after a laptop bag was stolen from an employee’s car. The bag contained the employee’s computer and unencrypted backup media, which contained the names, addresses, dates of birth, Social Security numbers, insurance information and clinical information of approximately 55,000 current and former Cancer Care patients.

OCR’s subsequent investigation found that, prior to the breach, Cancer Care was in widespread non-compliance with the HIPAA Security Rule. It had not conducted an enterprise-wide risk analysis when the breach occurred in July 2012. Further, Cancer Care did not have in place a written policy specific to the removal of hardware and electronic media containing ePHI into and out of its facilities, even though this was common practice within the organization. For more information see the HHS Press Release from Sep 2, 2015 $750,000 HIPAA settlement emphasizes the importance of risk analysis and device and media control policies

Risk analysis is the first step in meeting Security Rule requirements

I have written here, here, here and here about the importance of risk analysis as a process of understanding the value of your assets, the impact of your threats and the depth of your vulnerabilities in order to implement the best security countermeasures.

The HIPAA Security Rule begins with the analysis requirement in § 164.308(a)(1)(ii)(A). Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with and carry out the standards and implementation specifications in the Security Rule. Therefore, a risk analysis is fundamental to the entire process of HIPAA Security Rule compliance, and must be understood in detail by the organization in order to specifically address safeguards and technologies that will best protect electronic health information. See Guidance on Risk Analysis Requirements under the HIPAA Security Rule. Neither the HHS Guidance nor NIST specify a methodology – we have been using the Practical Threat Analysis methodology for HIPAA Security risk analysis with Israeli medical device companies since 2009 and it works smoothly and effectively helping Israeli medical device vendors comply and implement robust security at the lowest possible cost.

§ 164.308(a)(1)(ii)(A) Risk Analysis (R1): As part of the risk management process, the company performs information security risk analysis for its services (see company procedure XYZ) analyzing software application  security, data security and human related vulnerabilities. Risk analysis is performed according to the Practical Threat Analysis methodology.

1 A refers to addressable safeguards, and R refers to required safeguards.

Do it.  Run Security like you Run your business

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

On Shoshin and Software Security

I am an independent software security consultant specializing in medical device security and HIPAA compliance in Israel.   I use the state-of-the art PTA – Practical Threat Analysis tool to perform quantitative threat analysis and produce  a bespoke, cost-effective security portfolio for my customers that fits their medical device technology.

There are over 700 medical device companies in Israel – all doing totally cool and innovative things from My Dario (diabetes management), to Syneron (medical esthetics),  to FDNA (facial dysmorphology  novel analysis at your fingertips) to Intendu (Brain Rehabilitation).

This is a great niche for me because I get to do totally cool projects and  work with a lot of really smart people at Israeli medical device vendors helping them implement cost-effective  security and privacy compliance + it’s fun learning all the time.

One thing I have learned is that there is very little connection between FDA medical device risk assessments and a software security risk assessments.   This somewhat counter-intuitive for people who come from the QA and RA (regulatory assurance) areas.

Security is an adversarial environment very unlike FDA regulatory oversight.

FDA medical device regulatory oversight is about complying in a reliable way with standard operating procedures and software standards.

FDA believes that conformance with guidance documents, when combined with the general controls of the Act, will provide reasonable assurance of safety and effectiveness…

FDA recognizes several software consensus standards. A declaration of conformity to these standards, in part or whole, may be used to show the manufacturer has verified and validated pertinent specifications of the design controls. The consensus standards are:

  • ISO/IEC 12207:1995 Information Technology – Software Life Cycle Processes
  • IEEE/EIA 12207.O-1996 Industry Implementation of International Standard ISO/IEC12207:1995 (ISO/IEC 12207) Standard for Information Technology – Software Life Cycle Processes

Barry Boehm succinctly expressed the difference between Verification and validation:

Verification: Are we building the product right?

Validation: Are we building the right product?

Building the right product right is no more a guarantee of security than Apple guaranteeing you that your Mac Book  Pro  will not be stolen off an airport scanner.

Medical device security is about attackers and totally unpredictable behavior

Medical device security is about anticipating  the weakest link in a system that can be exploited by an attacker who will do totally unpredictable things that were inconceivable last year by other hackers, let alone 20 years ago by an ISO standards body.

You cannot manage unpredictable behavior (think about a 2 year old) although you can develop the means for anticipating threats and responding quickly and in a focused way even when sleep-deprived and caffeine-enriched.

The dark side of security is often hubris and FUD.

For security consultants, there is often an overwhelming temptation to show clients how dangerous their security vulnerabilities are and use that as a lever to sell products and services.   I’ve talked about hubris and FUD here and here and here and here and here.   A good example of exploiting clients with security FUD are the specialty HIPAA-compliant hosting providers like Firehost that are masters of providing expensive services to clients that may or may not really need them.

However, I believe that intimidation is not necessarily a strategy guaranteed to win valuable long-term business with clients.

Instead of saying – “that is a really bad idea, and you will get hacked and destroy your reputation before your QA and RA departments get back from lunch“,  it is better to take a more nuanced approach like:

I see that you are transferring credentials in plain-text to your server in the cloud.   What do you think about the implications of that?“.   Getting a client to think like an attacker is better than dazzling and intimidating them which may result in  the client doing nothing, hunkering down into his current systems or if the client has money – going off and spending it badly.

How did I reach this amazing (slow drum roll…) insight?

About 3 years ago I read a book called Search Inside Yourself and I learned an idea called – “Don’t take action, let action take you“.    I try to apply this approach with clients as a way of helping them learn themselves and as a way of avoiding unnecessary conflict.  The next step in my personal evolution was getting acquainted with a Zen Buddhist concept  called Shoshin:

Shoshin (初心) means “beginner’s mind”. It refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject, even when studying at an advanced level, just as a beginner in that subject would.

Shoshin means doing the exact OPPOSITE of what you (the high-powered, all-knowing, medical device security consultant) would normally do in the course of a security threat assessment:

  1. Let go of the need to add value – you do not have to provide novel security countermeasures all the time. Sometimes, doing the basics very well (like hashing and salting passwords) is all the value the client needs.
  2. Let go of the need to win every argument – you do not have to show the client why their RA (regulatory assurance) manager is making fatal mistakes in database encryption after she took some bad advice from Dr. Google.
  3. Ask the client to tell you more – ask what led them to a particular design decision.  You may learn something about their system design alternatives and engineering constraints. This will help you design some neat security countermeasures for their medical device and save them some money.
  4. Assume you are an idiot –  this is a corollary of not taking action.   By assuming you are an idiot, you disable your ego for a few moments and you get into a position of accepting new information  which in the end, may help you anticipate some threats and ultimately take your client out of potentially dangerous adversarial threat scenario.

Thank you to James Clear for his insightful post – Shoshin: This Zen Concept Will Help You Stop Being a Slave to Old Behaviors and Beliefs

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