Is there a way to break out of the security checklist mentality?

IT security auditors commonly use  standard/fixed checklists, often based on the compliance regulation being audited: the HIPAA Security Rule or  ISO 27001 for example;
In this article we suggest considering an alternative approach based on generating and analyzing multiple threat scenarios for the particular organization/business situation being audited.
Large organizations may reap significant benefits from this approach since they tend have many unconnected stovepipes of compliance and data governance.  Multiple threat scenarios enable security analysts to side-step large scale self-assessment checklists and problematic integration of data across stovepipes and focus on key assets, attacks and common vulnerabilities in key business processes.
Small to mid-size hospitals, nursing homes, medical device vendors, and healthcare applications software development teams have by definition much simpler  audit requirements.
A small business or development team is primarily interested in how cheaply the audit can be done and how much money they can save by getting it right.  For a small business unit – using the technique of multiple threat analysis will help show the best and most cost-effective way to progress from audit to HIPAA compliance and more secure systems.

You can do some research online and then hire a HIPAA security and compliance consultant who will walk you through the security safeguards in CFR 45 Appendix A and help you implement as many items as possible.  This seems like a reasonable approach, but the more safeguards you implement, the more money you spend and moreover, you do not necessarily know if your security has improved –since you have not examined your value at risk – i.e how much money it will cost you if you have a data security breach.
If you read CFR 45 Appendix A carefully, you will note that the standard wants you to do a top-down risk analysis, risk management and periodic information security activity review.
The best way to do that top down risk analysis is to build probable threat scenarios – considering what could go wrong – employees stealing a hard disk from a nursing station in an ICU where a celebrity is recuperating for the information or a hacker sniffing the hospital wired LAN for PHI.

Threat scenarios as an alternative to compliance control policies

When we perform a software security assessment of a medical device or healthcare system, we think in terms of “threat scenarios” or “attack scenarios”, and the result of that thinking manifests itself in planning, penetration testing, security countermeasures, and follow-up for compliance. The threat scenarios are not “one size fits all”.  The threat scenarios for an AIDS testing lab using medical devices that automatically scan and analyze blood samples, or an Army hospital using a networked brain scanning device to diagnose soldiers with head injuries, or an implanted cardiac device with mobile connectivity are all totally different.
We evaluate the medical device or healthcare product from an attacker point of view, then from the management team point of view, and then recommend specific cost-effective, security countermeasures to mitigate the damage from the most likely attacks.

1. A robust, cost-effective security portfolio based on attack analysis  results in robust compliance over time.
2. Executives related well to the concepts of threat modeling / attack analysis. Competing, understanding the value of their assets, taking risks and protecting themselves from attackers is really, at the end of the day why executives get the big bucks.
3. Threat scenarios are a common language between IT, security operations teams and the business line managers

This last benefit is extremely important in your healthcare organization, since business delegates security to IT and IT delegates security to the security operations teams.
As I wrote in a previous essay “The valley of death between IT and security“, there is a fundamental disconnect between IT operations (built on maintaining predictable business processes) and security operations (built on mitigating vulnerabilities).
Business executives delegate information systems to IT and information security to security people on the tacit assumption that they are the experts in information systems and security.  This is a necessary but not sufficient condition.
In the current environment of rapidly evolving types of attacks (hacktivisim, nation-state attacks, credit card attacks mounted by organized crime, script kiddies, competitors and malicious insiders and more…), it is essential that IT and security communicate effectively regarding the types of attacks that their organization may face and what is the potential business impact.
If you have any doubt about the importance of IT and security talking to each other, consider that leading up to 9/11, the CIA  had intelligence on Al Qaeda terrorists and the FBI investigated people taking flying lessons, but no one asked the question why Arabs were learning to fly planes but not land them.
With this fundamental disconnect between 2 key maintainers of information protection, it is no wonder that organizations are having difficulty effectively protecting their assets – whether Web site availability for an online business, PHI for a healthcare organization or intellectual property for an advanced technology firm.
IT and security  need a common language to execute their mission, and I submit that building the security portfolio around most likely threat scenarios from an attacker perspective is the best way to cross that valley of death.
There seems to be a tacit assumption with many executives that regulatory compliance is already a common language of security for an organization.  Compliance is a good thing as it drives organizations to take action on vulnerabilities but compliance checklists like PCI DSS 2.0, the HIPAA security rule, NIST 800 etc, are a dangerous replacement for thinking through the most likely threats to your business.  I have written about insecurity by compliance here and here.
Let me illustrate why compliance control policies are not the common language we need by taking an example from another compliance area – credit cards.
PCI DSS 2.0 has an obsessive preoccupation with anti-virus.  It does not matter if you have a 16 quad-core Linux database server that is not attached the Internet with no removable device nor Windows connectivity. PCI DSS 2.0 wants you to install ClamAV and open the server up to the Internet for the daily anti-virus signature updates. This is an example of a compliance control policy that is not rooted in a probable threat scenario that creates additional vulnerabilities for the business.
Now, consider some deeper ramifications of compliance control policy-based security.
When a  QSA or HIPAA auditor records an encounter with a customer, he records the planning, penetration testing, controls, and follow-up, not under a threat scenario, but under a control item (like access control). The next auditor that reviews the  compliance posture of the business  needs to read about the planning, testing, controls, and follow-up and then reverse-engineer the process to arrive at which threats are exploiting which vulnerabilities.
Other actors such as government agencies (DHS for example) and security researchers go through the same process. They all have their own methods of churning through the planning, test results, controls, and follow-up, to reverse-engineer the data in order to arrive at which threats are exploiting which vulnerabilities.
This ongoing process of “reverse-engineering” is the root cause for a series of additional problems:

• Lack of overview of the the security threats and vulnerabilities that really count
• No sufficient connection to best practice security controls, no indication on which controls to follow or which have been followed
• No connection between controls and security events, except circumstantial
• No ability to detect and warn for negative interactions between countermeasures (for example – configuring a firewall that blocks Internet access but also blocks operating system updates and enables malicious insiders or outsiders to back-door into the systems from inside the network and compromise  firewalled services).
• No archiving or demoting of less important and solved threat scenarios (since the data models are control based)
• Lack of overview of security status of a particular business, only a series of historical observations disclosed or not disclosed.  Is Bank of America getting better at data security or worse?
• An excess of event data that cannot possibly be read by the security and risk analyst at every encounter
• Confidentiality and privacy borders are hard to define since the border definitions are networks, systems and applications not confidentiality and privacy.

Using value at risk to figure out how much a breach will really cost you

Your threat scenarios must consider asset (your patient information, systems, management attention, reputation) values, vulnerabilities, threats and possible security countermeasures. Threat analysis as a methodology does not look for ROI or ROSI (there is no ROI for security anyhow) but considers the best and cheapest way to reduce asset value at risk.

And – as we opened the article – the question is  “How can I do this for as little money as possible?”