As Ben noted that in the clinical research field, putting together such an offering is not trivial. Open Clinica is the worlds fastest growing clinical trials software with an interesting Open Source business model of community-supported Open Source and revenue from enterprise licensing, cloud services and training.

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.  We have been working with a regulatory affairs consulting client for over 3 years now, using the Open Clinica application for managing  large multi-center, international clinical trials using Rackspace hosting and more recently using Rackspace Cloud.

I can attest that running multi-center clinical trails in the cloud is neither for the faint of heart nor weak of stomach.  Past the security, compliance and regulatory issues – there is also the issue of performance.

Although resources are instantly scalable on-demand in the cloud, resources are not a substitute for secure software that runs fast.

As I noted in a previous essay “The connection between application performance and security in the cloud“, slow applications require more hardware, more database replication, more load-balancing and more firewalls. More is not always better, and more layers of infrastructure increase the threat surface of the application with more attack points on the interfaces and more things that can go wrong during software updates and system maintenance.

If there is a design or implementation flaw in a cloud application for clinical trials management that results in the front-end Web server making 10,000 round trips to the back-end database server to render a matrix of 100 subjects, then throwing more hardware at the application will be a fruitless exercise.

If we do a threat analysis on the system, we can see that our No. 1 attacker is the software itself.

In that case, the application software designers have to go back to the drawing board and redesign the software and get that number down to 1 or 2 round trips.

The effort will be well worth it in your next bill from your cloud service provider.

Security is about reducing the impact of unpredictable attacks to a your organization.

IT and security adopt a common goal and a common language – a language  of customer-centric threat modelling

Typically, when a company ( business unit, department or manager) needs a line of business software application, IT staffers will do a system analysis starting with business requirements and then proceed to buy or build an application and deploy it.

Similarly, when the information security group needs an anti-virus or firewall, security staffers will make some requirements, test products, and proceed to buy and deploy or subscribe and deploy the new anti-virus or firewall solution.

Things have changed – both in the IT world and in the security world.

Web 2.0 SaaS (software as a service) offerings (or  Web applications in PHP that the CEO’s niece can whip together in a week…) often replace those old structured systems development methodologies. There are of course,  good things about not having to develop a design (like not coming down with an advanced case of analysis paralysis) and iterating quickly to a better product, but the downside of not developing software according to a structured systems design methodology is buggy software.

Buggy software is insecure software. The response to buggy, insecure software is generally doing nothing or installing a product that is a security countermeasure for the vulnerability  (for example, buying a database security solution) instead of fixing the SQL injection vulnerability in the code itself.   Then there is lip-service to so called security development methodologies which despite their intrinsic value, are often too detailed for practioners to follow), that are not a replacement for a serious look at business requirements followed by a structured process of implementation.

There is a fundamental divide, a metaphorical valley of death of  mentality and skill sets between IT and security professionals.

• IT is about executing predictable business processes.
• Security is about reducing the impact of unpredictable attacks.

IT’s “best practice” security in 2011 is  firewall/IPS/AV.  Faced with unconventional threats  (for example a combination of trusted contractors exploiting defective software applications, hacktivists or competitors mounting APT attacks behind the lines), IT management  tend to seek a vendor-proposed, one-size-fits-all “solution” instead of performing a first principles threat analysis and discovering  that the problem has nothing to do with malware on the network and everything to do with software defects that may kill customers.

Threat modeling and analysis is the antithesis of installing a firewall, anti-virus or IPS.

Analyzing the impact of attacks requires hard work, hard data collection and hard analysis.  It’s not a sexy, fun to use, feel-good application like Windows Media Player.   Risk analysis  may yield results that are not career enhancing, and as  the threats  get deeper and wider  with  bigger and more complex systems – so the IT security valley of death deepens and gets more untraversable.

There is a joke about systems programmers – they have heard that there are real users out there, actually running applications on their systems – but they know it’s only an urban legend. Like any joke, it has a grain of truth. IT and security are primarily systems and procedures-oriented instead of  customer-safety oriented.

Truly – the essence of security is protecting the people who use a company’s products and services. What utility is there in running 24×7 systems that leak 4 million credit cards or developing embedded medical devices that may kill patients?

Clearly – the challenge of running a profitable company that values customer protection must be shouldered by IT and security teams alike.

Around this common challenge, I  propose that IT and security adopt a common goal and a common language – a language  of customer-centric threat modelling - threats, vulnerabilities, attackers, entry points, assets and security countermeasures.  This may be the best or even only way for IT and security  to traverse the valley of death successfully.

George Colony, the chairman and CEO of Forrester Research, re-ignited a minor firestorm recently, with a presentation at the LeWeb conference in which he argued that the web is dead, and being replaced by the app economy — with mobile and smartphone apps that leverage the cloud or other services rather than the open web.

I have written here and here about the close correlation between Web application security and Web performance.

I know that Mr. Colony has sparked some strong sentiment in the community, in particular from Dave Winer:

If I can’t link in and out of your world, it’s not even close to a replacement for the web. It would be as silly as saying that you don’t need oceans because you have a bathtub. How nice your bathtub is. Try building a continent around it.

Of course, that is neither true nor relevant.

Many apps are indeed well connected, and the apps that are not wired-in, don’t have to be wired; the app is simply doing something useful for the individual consumer (like iAnnotate displaying a PDF file of music on a iPad or Android tablet).

iAnnotate turns your iPad into a world-class productivity tool for reading, annotating, organizing, and sending PDF files. Join the 100,000s of users who turn to iAnnotate for their PDF annotating needs. We designed iAnnotate to suit your individual workflow.

I became even more cognizant that apps may overtake the open Web over the past 2 weeks when Google Apps was going through some rough spots and it was almost impossible to read email to  software.co.il or access or calendars…except from our Android tablets and Nexus S smartphones.   Chrome and Google Apps was almost useless but Android devices just chugged on.

There is a good reason why apps are overtaking the open browser-based web.

They are simply more accessible, easier to use and faster.

This is no surprise as I noted last year:

The current rich Web 2.0 application development and execution model is broken.

Consider that a Web 2.0 application has to serve browsers and smart phones. It’s based on a heterogeneous server stack with 5-7 layers (database, database connectors, middleware, scripting languages like PHP, Java and C#, application servers, web servers, caching servers and proxy servers.  On the client-side there is an additional  heterogeneous stack of HTML, XML, Javascript, CSS and Flash.

On the server-side, we have

• 2-5 languages (PHP, SQL, tcsh, Java, C/C++, PL/SQL)
• Lots of interface methods (hidden fields, query strings, JSON)
• Server-side database management (MySQL, MS SQL Server, Oracle, PostgreSQL)

On the client side, we have

• 2-5 languages ((Javascript, XML, HTML, CSS, Java, ActionScript)
• Lots of interface methods (hidden fields, query strings, JSON)
• Local data storage – often duplicating session and application data stored on the server data tier.

A minimum of 2 languages on the server side (PHP, SQL) and 3 on the client side (Javascript, HTML, CSS) turns developers into frequent searchers for answers on the Internet (many of which are incorrect)  driving up the frequency of software defects relative to a single language development platform where the development team has a better chance of attaining maturity and proficiency. More bugs means more security vulnerabilities.

More bugs in this complex, broken execution stack means more things will go wrong and as devices and apps are almost universally accessible now; it means that customers like you and me will not tolerate 2 weeks of downtime from a Web 2.0 service provider.  If we have the alternative to use an app on a tablet  device, we will take that alternative and not look back.

Information security and  risk analysis is complex stuff, with multiple dimensions  of people, software, performance, management, technology, assets, threats, vulnerabilities and control relationships.  This is why it’s hard to sell security to organizations. But, information security is also a lot like fashion with cyclical hype and theater: today – , HIPAA, iOS and Android security,  yesterday – Sarbanes-Oxley, federated identity management, data loss protection and application security firewalls.

Back in 2007,  I thought we might a return to the Age of Reason, where rational risk management replaces blind compliance check lists – I thought that this could happen  for 2 reasons:

1. Compliance projects  can have good business value, if you focus on improving the product and it’s delivery.
2.  Security is like fashion – both are cyclical industries, the wheel can also turn around in the right direction.

HIPAA compliance is a minimum but not sufficient requirement for product and process improvement.

Healthcare companies and medical device vendors that do HIPAA compliance projects, may be paying a steep price for HIPAA compliance without necessarily getting a return on their investment by improving the core features and functionality of their products and service offerings.

Compliance driving improvements in products and services is good for business, not just a mantra from Mcafee.

It could happen, but then again, maybe not. Look at the trends. Taking a sample of articles published in 2011 on the  eSecurityPlanet Web site we see that  mobile devices and cloud services lead the list, followed by IT security with healthcare closing the top 15. I guess cost-effective compliance is a lot less interesting than Android security.

1. iOS vs. Android Security: And the Winner Is?
2. 5  iOS 5 Enterprise Security Considerations – You can’t keep Apple out of the enterprise anymore so it’s best to figure out the most secure way to embrace it, writes Dan Croft of Mission Critical Wireless.
3. PlayBook Tops in Tablet Security – Recent price reductions may mean more Blackberry Playbook tablets entering your organization, but that may not be such a bad thing for IT security teams.
4. Android Security Becoming an Issue – As the Android mobile platform gains market share, it also garners a lot of interest from cyber crooks as well as IT security vendors.
5. Which Browser is the Most Secure? – The ‘most hostile’ one, say researchers at Accuvant Labs.
6. How to Prevent Employees from Stealing Your Intellectual Property -It’s the employee with the sticky hands that is the easiest and cheapest to thwart.
7. Security Spend Outpacing the Rest of IT – High profile breaches and mobile devices are driving IT security spending.
8. Public Cloud Keys Too Easy to Find -If you put the keys to your cloud infrastructure in plain sight, don’t be surprised if you get hacked.
9. Zeus (Still) Wants Your Wallet – The antivirus community has failed to figure out this able and persistent piece of malware. It’s as simple as that.
10. Spear Phishing Quickly Coming of Age – Even the security giants are not immune from this sophisticated and growing form of attack, writes Jovi Bepinosa Umawing of GFI Software.
11. Penetration Testing Shows Unlikely Vulnerabilities – Enterprises need to dig deeper than just automated scanning to find the really interesting and dangerous cyber security flaws.
12. Bank Fraud Still Costing Plenty – Bank fraud is and will continue to be an expensive problem.
13. Do IT Security Tools Really Make You Safer? – Yet another suite of tools for IT security folks to administer and manage can actually have the opposite effect.
14. Siege Warfare in the Cyber Age – In one the unlikeliest turn of events brought about by technology, it looks like Middle Ages’ siege warfare may be making a comeback, writes Gunter Ollmann of Damballa.
15. Healthcare Breaches Getting Costlier – And it’s not just dollars and cents that are on the line – reputations are on the line, writes Geoff Webb of Credant Technologies.

In principle I shut down as many operating services as I can – especially those that call out and/or listen on the Internet but this is supposed to be a development machine with access to our private git repository and sending out email via a Postfix relay.

On our own  small scale of a lab with 6-7 machines for testing network and software security of customer applications, I  got  thinking that most system vulnerabilities live in the cracks of system integration of components and packaged software while most of the industry’s efforts in software security are directed towards new software implementations.

Faced with a steep bill for securing a new cloud application, a client asked us to help find a way to reduce their risk exposure at the lowest possible cost. By using the Business Threat Modeling methodology and PTA (Practical Threat Analysis) software, we were able to build a risk mitigation plan that mitigated 80% of the total risk exposure in dollars at half the original security budget proposed by the vendor.

This paper describes a customer case study of a risk analysis for a next generation call accounting system provided as a cloud service. A private medical school (let’s call them Campton College – some of the names have been deliberately changed for privacy reasons), needed to replace an aging call accounting system, which frequently lost call records and lacked the capability to provide unified campus-wide telephony billing features. Campton wanted to implement and operate an integrated Web based call accounting system that would service student dorms and administrative departments. The institution contracted with TACS, a call accounting solution provider, to replace the old software and provide a modern, Web-based managed application service that would be cheaper to maintain and easier to use. Prior to implementing the TACS managed call accounting services, Campton retained Software Associates in order to help them perform a risk assessment of the SaaS call accountingsolution.

The TACS managed call accounting service in a nutshell

TACS offers small to mid-sized organizations a managed software as a service application for call accounting that includes basic billing functionality and is capable of collecting and processing call detail records from variety of sources. The Web-based user interface caters to four different types of users: PBX technicians, administrators, phone users and organization managers.

Technicians - TACS technicians are responsible for installing the CDR (call detail records) buffer devices connected to the PBXs for accumulating the calls. A technician defines the parameters of the protocols used by the buffer, data collection schedule, format of call records and performs initial testing of data collection in order to validate that the calls are collected and parsed successfully by TACS data back-end data processing systems.

Administrators - Customer administrators handle ongoing management of the telephone switch resources and subscribers as follows:

• Allocate phone-extensions and other telephony resources, such as cellular phones etc.
• Set the pricing programs that calculates and attaches a price tag to each call
• Define phone users and system users
• Associate users with telephony resources and pricing programs
• Manage system access permissions

Subscribers (phone users) – Subscribers can view and print the detailed listings of their private calls and their monthly bills.

Managers - User department Managers can produce reports that summarize calls traffic and the usage of telephony resources in the organization. They also monitor the billing and payments of phone users.

System Architecture

The TACS system ASP architecture is based on Microsoft Windows Server 2003 that runs several .Net applications responsible for the call accounting processing, and a suite of web applications that interact with users via browsers (IE 5.5 and higher). The system database is managed by a stand alone MS SQL 2000 machine connected to the application server via LAN.

Database

The TACS MS SQL Server 2000 stores all types of system data, including call records, pricing programs, users, organizational structure and system configuration. The CDR tables can handle several million records per month and are indexed by a multiple fields to support rich reporting.

The SQL Server scheduler mechanism is used to schedule and dispatch the data collection activities.

Processing

The processing of CDRs has 3 stages:

• Data Collection collecting the calls from the CDR buffers. The output is blocks of raw CDR data.
• Parsing and reformatting – the output is structured call records in a uniform format invariant to origin of the calls.
• Load to database – call record are associated with the corresponding end point device, subscriber id and telecom provider and then inserted to the database.

The implementation is based on a several Windows services that use worker components to implement the required functionality. For example, the data collection service operates several different collector components to collect the call records from different data sources via the appropriate protocols. Campton College operates 3 PBXs from different vendors: Avaya, Siemens and a small Cisco VoIP switch. The operating parameters of the components are kept in the database.

The data is transferred between the 3 processing stages via MSMQ private queues that serve as non-volatile buffers for data in process.

The service processes and some of the worker components were developed using .NET technology. Other worker components are legacy Win32 components wrapped with .NET Interop layer.

Web applications

The Web Applications are implemented in ASP.NET combined with Microsoft reporting engine. Some of the applications are capable of directly viewing and editing data tables in the database via ASP.NET server side controls.

In the TACS system, all Web applications share the same infrastructure for user login and secure access to the database.

Pricing, database maintenance and data exchange

The pricing, database maintenance and data exchange tasks are implemented with a Windows service that uses worker components to perform the actual tasks, similar to the call records processing architecture. The tasks are executed in a periodical manner according to the system schedule.

Why conduct a threat analysis?

“By retiring an aging 80′s in-house system and outsourcing to TACS we will move into the 21st Century in less than nine months; and get an easy to use service that is available to all students and generates a revenue stream,…quot; said Joan Walz, Campton campus operations manager, “but we had security concerns about using an outsourced service.”

“We knew that TACS is an experienced call accounting solution provider but we were unsure that their software and operations team had adopted a best-practices approach to information security and we asked TACS to submit to an external assessment of their systems…” said Walz.

What is Business Threat Modeling?

A Business Threat Modeling study focuses on protecting valuable assets, is sponsored by a senior manager, has 2-5 participants with relevant knowledge, is guided by an experienced security analyst with specific domain expertis (in this case telecommunications).  A typical threat modeling study lasts 2-5 days where the last day is devoted to presenting the results to management.

In a pre-kickoff planning meeting, the consultant works with the sponsor to set clearly defined goals and outcomes for the session. Since much of the work is done in small breakout groups, all stakeholders take an active part. The consultant guides the group through a fast-paced process to:

1. Identify assets
2. Identify vulnerabilities
3. Define countermeasures
4. Compose threat scenarios
5. Understand calculated risk
6. Optimize countermeasures

The data collection and risk calculation is performed using PTA Professional. PTA captures the information in a structured database and automates the  risk what-if calculation process. Analysts and stakeholders don’t need to maintain unstructured Word or Excel documents. Users can quickly create new threat scenarios and countermeasures. All issues are captured and nothing is lost. Management can ask for and quickly receive any reports they want.

PTA kickoff

At the first day kickoff session, the functional and architectural descriptions of TACS system were presented to the consultant, by Dympna O’Connell, TACS product manager. “We’re already documenting and revising our customer provisioning and configuration procedures”, said O’Connell. “We realize that these process steps are crucial to our customer’s information security and we want to make sure there are no security holes and opportunities for data manipulation”.

Step 1 of the study – Identify Assets

In the first step of the study the group mapped the system’s major assets, their financial values and the losses that may be caused when assets are damaged. The following major system assets were identified:

The detailed list of identified assets is part of the full threat-model database available for download from Call Accounting Case Study threat model. To view the detailed entities lists you should have PTA software installed on your computer.

Step 2 Identify Vulnerabilities

In order to identify vulnerabilities and flaws, Open Solutions analysts studied the functional and architecture documents supplied by Ms. O’Connell. “Since TACS bases its architecture on Microsoft infrastructure, we used the PTA MS-Telecom entity library as a base line checklist for picking up system common vulnerabilities” said Yuval,  risk consultant. “More then 70% of the stuff was already there. We have just had to complement the picture by diving into the CDR collection equipment and by studying Campton specific business procedures with the help of Mr. Walz.

“Identifying the relevant vulnerabilities is an iterative process bundled with the understanding of the actual threats. All in all, we came up with 15 focused vulnerabilities relevant to the specific architecture, the specific telephony infrastructure and the ASP mode of operation” said Yuval.

Step 3 – Define Countermeasures

During this step the team defined the countermeasures relevant for mitigating the identified vulnerabilities. Some of the countermeasures were well known safeguards picked up from the predefined PTA entity library such as enforcing OS patches deployment and strong passwords policy. Others were more unique e.g. the development of mechanism for managing data collection buffer passwords in an encrypted repository.

“We worked directly with Ms. O’Connell and her developers on estimating countermeasures implementation costs needed by PTA for calculating countermeasures cost-effectiveness” said Yuval.

The lists of the 22 countermeasures that were defined and the identified vulnerabilities are included in the case study database available for download from Call Accounting Case Study threat model.

Step 4 Build Threat Scenarios

“Building the threats is the peak of the process”, said Software Associates founder and CTO Mr. Danny Lieberman, “this is the point where we use our experience to compose the threat scenarios, evaluate their feasibility and estimate the probability they will actually happen”.

“The flexibility of the PTA database driven model enables us ‘what-if’ experiments and the calculative capabilities gives us immediate feedback on the severity of threats” , said Yuval.

Step 5 – Understand the calculated Risk

After refining threat probabilities, the PTA software calculated the following bottom-line:

• The total yearly value of assets that might be damaged if threats materialize is $2.21M
• The risk level (the value of the financial losses that may be caused to the system due to the identified threats) is 249% of the total assets (~$5.5M). Although it is clear that the actual damage to the system assets cannot exceed their total value, the risk level does not express the actual damage. It reflects the amount of effort that has to be invested in order to mitigate the threats to the system, and since in this specific system several threats threaten the same assets, the risk level exceeds 100%.

The following bar chart presents the 5 most dangerous threats calculated and displayed by PTA (the value of risk is presented in real $):

Top Threats by Risk

Not surprising, it was found that the most dangerous threats are the ones that threaten the calls data either in the system database on the various collecting stages.

“The ranking of the threats reflects a typical heterogeneous software system. The ability to take into account non-standard threats specific to the analyzed system is one of the great strengths of PTA “, said Lieberman, “We were not limited to generic information security standards, such as ISO 27001 and indeed you can see some interesting threats that indigenous to this particular system e.g. the CDR buffers vulnerabilities. Complex systems like this often have huge risks that are hidden in the cracks of generic standards…”

Step 6 Optimize Countermeasures

It was clear that a level of 249% of risk is dangerous and that countermeasures should be applied to reduce the system risk before going into heavy-duty production operation. We asked Open Solutions to show us how to reduce the risk to an acceptable level of 60% at lowest cost, said Ms. Walz. Since our budget was constrained, we considered canceling the whole info-sec project and taking our risks by doing nothing. At that step, said Yuval, we ran the PTA optimized risk reduction plan with a target risk level of 50%. We obtained an optimized plan with the following countermeasures that should be applied:

• Install content leakage prevention system
• Install firewall
• Enforce deployment of latest security patches for OS, database and Web server
• Develop mechanism for secure managing of CDR buffers passwords
• Use CDR buffers with secure transfer and login authentication protocols
• Enforce security code review
• Enforce data access via stored procedures with formal parameters content validation
• Implement validation of input fields in web pages
• Develop secured passwords and role-based mechanism for web users
• Develop monitoring mechanism for back-end processing (system health)
• Limit access of ASP employees and technicians to system resources
• Enforce quality passwords policy for protecting each of the machines on the network
• Use Windows integrated authentication policy
• Database login accounts should be given the minimal rights that are necessary for their functionality

Implementing the recommended set of countermeasures reduces the system risk to 54.3% at a cost of 127,000 $. Only 14 countermeasures out of the 22 were selected – the proposed order of countermeasures also ensures a quickest reduction of risk per $ spent throughout the system modification process. The implementation of the following countermeasures was suspended to later stages in system life cycle:

• Create acceptable use policy for email and Internet access
• Install anti-DoS appliance
• Enforce deployment of latest security patches for OS, database and Web server
• Develop fraud detection mechanism
• Security officer should assure the personal integrity of employees
• Develop module for logging changes in data initiated by users
• Enforce employees’ liability for disclosing private calls information
• Restrict display of phone numbers and sensitive information in detailed reports

Ms. Walz of Campton College and Ms. O’Connell of TACS summarized their impressions of the study.

“We were pleased with the speed and quality of results of the PTA methodology that Open Solutions uses; with the fact that it created consensus among the stakeholders; with the effective use of senior manager time; and above all getting us the best risk reduction at the lowest cost. “

Appendix 1. Abbreviations and terminology

PBX Private Exchange telephony device; interchangeable with the term Switch

MSMQ Microsoft Middleware Queue system

CDR  Call Detail Record

Telephony buffer Intermediate buffer device for storing CDRs collected from PBX

Data Source origin of telephony calls data e.g. PBXs, IP Switches etc.

Users Individuals that have access to the university telephony resources and to TACS system e.g. students, academic staff, administration and personnel

It is now time to slaughter one more sacred cow: SSL.

One of the most prevalent misconceptions with vendors in the medical device and healthcare space regards the role of SSL and TLS in protecting patient information.  When faced with a requirement by a government or hospital customer for compliance to one of the US privacy and security standards, a vendor usually reacts with the CEO asking his CTO to look into “solutions”. The CTO’s answer usually goes  like this:

I did some research. Apparently to be FIPS  (or HIPAA, or …) compliant we should use TLS and not SSL. I think that configuring the browser to be FIPS  (or HIPAA, or …) compliant may take a little work.

Action items are given out to the technical team, they usually look like this:

Joe – You establish a secure web site

Jack - Make sure all the addresses on the workstation point to https instead of http

Jack and Joanne - Compile a new version of the Servers and workstation to work properly on the new site.

Jack and Jill - Do what ever needs to be done so that the web services work on the new site.

That’s all – No other changes need to be done to the application.

Oooh.  I just love that last sentence – “No other changes need to be done to the application”.  What about patching Web servers and the Windows operating systems? What about application software vulnerabilities?  What about message queue vulnerabilities ? What about trusted insiders, contractors and business partners who have access to the application software?

There are multiple attack vectors from the perspective of FIPS and HIPAA compliance and PHI data security.  The following schematic gives you an idea of how an attacker can steal PHI, figure using any combination of no less than 15 attack vectors to abuse and steal PHI:

There are potential data security vulnerabilities in the client layer, transmission layer, platform layer (Operating system) and cloud services (Amazon AWS for example).

So where does SSL fit in? Well, we know that the vulnerabilities for a PHI data breach can not only happen inside any layer but in particular there are vulnerabilities in the system interfaces between layers. That means between server layers and client-server interfaces.  SSL  Quoting from the Apache Tomcat 6.0 SSL Configuration HOW-TO:

SSL, or Secure Socket Layer, is a technology which allows web browsers and web servers to communicate over a secured connection. This means that the data being sent is encrypted by one side, transmitted, then decrypted by the other side before processing. This is a two-way process, meaning that both the server AND the browser encrypt all traffic before sending out data.

Another important aspect of the SSL protocol is Authentication. This means that during your initial attempt to communicate with a web server over a secure connection, that server will present your web browser with a set of credentials, in the form of a “Certificate”, as proof the site is who and what it claims to be. In certain cases, the server may also request a Certificate from your web browser, asking for proof that you are who you claim to be. This is known as “Client Authentication,” although in practice this is used more for business-to-business (B2B) transactions than with individual users. Most SSL-enabled web servers do not request Client Authentication.

In plain English, SSL is good for protecting credentials transmitted between the browser and web server during the login process from eavesdropping attacks.  SSL may still be vulnerable to man in the middle attacks by malware that piggybacks on the plain text browser requests and responses before they are encrypted. Similarly, SSL may be vulnerable to cross-site scripting attacks like the Paypal XSS vulnerability discovered in 2008 that would allow hackers to carry out attacks, add their own content to the site and steal credentials from users.

SSL is a key component in a secure login process, but as a security countermeasure for application software vulnerabilities, endpoint vulnerabilities, removable devices, mobile devices and data security attacks by employees,  servers and endpoints, it is worse than worthless because it sucks the medical device/healthcare vendor into a false feeling of security.

SSL does NOT make a medical device/healthcare Website secure. The SSL lock symbol in the  browser navigation window just means that data in motion between a browser client and Web server is encrypted.   If you can attack the endpoint or the server – the data is not protected. Quoting Gene Spafford ( I think this quote has been used for years but it’s still a good one)

“Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench.”
– Gene Spafford Ph.D. Purdue, Professor of Computer Sciences and Director of CERIAS

This is all fine and dandy, but  recall our conversation from the CTO giving action items to his team to “establish a secure web site” as if it was point and click on a Microsoft Office file. The team may discover that even though SSL is not a very good data security countermeasure (albeit required by FIPS and HIPAA), it may not be that easy to implement, let alone implement well.

It’s no wonder that so many web servers are misconfigured by the clueless being led by other clueless people who never read the original documentation and were all feeding off google searches for tutorials. Yikes!

Most people don’t bother reading the software manuals and google for advice looking for things like “Tomcat SSL configuration tutorial“.  Jack, and Jill and Joanne in our example above, may discover themselves wandering in an  abundance of incorrect,incomplete and misleading information in cyberspace, which is mixture of experts who assume everyone  knows how to setup secure AJP forwarding and Tomcat security constraints and a preponderance of newbies who know nothing (or a little bit, which is worse than nothing).

Working with a client in the clinical trial space, I realized that the first and perhaps biggest problem is a lack of decent documentation, so I wrote SSL and Certificate HOW TO – Apache 2.2 and Tomcat 6, Ubuntu which I hope will be my modest contribution (along with this blog) to dispelling some of the confusion and misconceptions and helping medical device and healthcare vendors implement secure Web applications. No promises – but at least I try to do my bit for the community.

It is significant that discussions of cloud security and performance focus almost exclusively on infrastructure issues such as virtualization or procedural issues such as infrastructure compliance with various security standards and frameworks.

I remarked to Avner in the course of our chat, that there is a close correlation between performance and security issues for Web applications running in the cloud.  Avner  asked me how I came to that conclusion.

Here is why cloud performance and cloud security have common issues.

Virtually all applications deployed in the cloud are either Web-based applications or smartphone apps for Android or IOS that use http/https as their application transport.

The current rich Web 2.0 application model is broken and it has nothing to do with the  serious and fundamental issues with Microsoft monoculture, Windows operating systems vulnerabilities and Internet Explorer non-compliance with IETF  standards.

It will not help if you use Ruby on Rails or CakePHP or Zend Framework either. The debate between the Ruby on Rails, ASP.NET and PHP camps is mildly interesting but irrelevant from a cloud security and performance perspective.

A deeper look at Web applications reveals that the current rich Web 2.0 application development and execution model suffers from a broken architecture that cannot be fixed by tweaking languages.

Further examination shows that data typing, message passing, redundant code, data and multiple tier issues that are security vulnerabilities for Web applications in the cloud are also root causes of application performance issues and latency that result in a poor user experience and high cost of operation for the application operator. Note that in a utility model where you pay for CPU cycles,  you pay more for inefficient applications. That is the dark side of the externally vivacious cloud service model.

The attached presentation examines some of the root causes of the currently broken Web 2.0 application development and execution model and shows that the same security vulnerabilities born out of Web 2.0 client/server architecture result in 10x poorer performance than a traditional client-server model based on stateful, TCP unicast socket communications.

See Web application security in the cloud

Did you ever have a feeling that your IT integrator was treating you like a couple of guys selling you a Persian rug?  ”Take it now – it’s so beautfiful, just perfect for your living room, a steal  for only $10,000 and it’s on sale” and when you ask if it will last, they tell you “Why do you want it to last? Enjoy, use it in good health, wear it out quickly and come back to the store so that we can sell you Persian Rug 2012″.

I had a meeting with a long-time client today – I’ve developed some systems for them in the FDA regulatory and clinical trial management space. We met for lunch to discuss a new project which involved an extension to an existing multi-center study.

The question of disaster recovery planning and offsite backup came up and  they asked me what I thought about backing up their clinical trial data together with their office file backups taken by their outsourcing IT provider.

I said this is a very bad idea because while their IT contractor specializes in providing Microsoft Windows/Office support for small businesses, they just don’t have the know-how or security expertise for HIPAA compliant data storage.

In general, small business IT integrators are  behind the curve on data security, compliance, disaster recovery and application software security. Their job is to keep Microsoft SBS running smoothly and install anti-virus software, not mitigate data security and HIPAA compliance attacks. The typical SMB integrator mindset is dominated by the Microsoft monoculture, and I would not expect them to be able to analyze data security threats correctly.

Whenever I go somewhere – I’m always looking at things with a security perspective – open doors, windows – things that could be easily lifted. Who might be a threat. Storing clinical data with a bunch of Microsoft Office files is just too big a risk to take. The CEO accepted my recommendation to encrypt data on a secure, hardened virtual server instance in the cloud and monitor potential exposure to new emerging threats as their application and project portfolio evolves.

After lunch and getting back into the office, I realized that Risk analysis is a threat to IT vendors.

Not every security countermeasure is effective or even relevant for your company. This is definitely a threat to an IT vendor salesperson who must make quota.

I am a big proponent of putting vendor suggestions aside and taking some time to perform a business threat analysis (shameless plug for our business threat analysis services,  download our free white paper and learn more about Business Threat Modeling and security management). In a business threat  analysis you ignore technology for a week or 2 and systematically collect assets, threats, vulnerabilities …and THEN examine the cost-effective security countermeasures.

Your vendor wants to sell you a fancy $20,000 application security/database firewall, but it may turn out that your top vulnerability is from 10 contract field service engineers who shlep your company’s source code on their notebook computers. You can mitigate the risk of a stolen notebook by installing a simple security countermeasure - Free open-source disk encryption software for Windows Vista/XP, Mac OS X, and Linux.

Information security vendors often promote their backup/data loss prevention/data retention/application security products using a compliance boogeyman.

The marketing communications often reaches levels of the absurd as we can see in the following example:

NetClarity (which is a NAC appliance) claims that it provides “IT Compliance Automation” and that it “Generates regulatory compliance gap analysis and differential compliance reports” and “self-assessment, auditing and policy builder tools for Visa/Mastercard PCI, GLBA (sic), HIPAA, CFR21-FDA-11,SOX-404, EO13231 government and international (ISO270001/17799) compliance.”

A network access control appliance is hardly an appropriate tool for compliance gap analysis but asserting that a NAC appliance or Web application firewall automates SOX 404 compliance is absurd.

Sarbanes-Oxley Section 404, requires management and the external auditor to report on the adequacy of the company’s internal control over financial reporting. This means that a company has to audit, document and test important financial reporting manual and automated controls. I remember the CEO of a client a few years ago insisting that he would not accept any financial reports from his accounting department unless they were automatic output from the General Ledger system – he would not accept Excel spreadsheets from his controller, since he knew that the data could be massaged and fudged. If there was a bug in the GL or missing / incorrect postings he wanted to fix the problem not cut and paste it.

Appropriate, timely and accurate financial reporting has absolutely nothing to do with network access control.

But the best part is the piece on the NetClarity Web site that claims that their product will help “Deter auditors from finding and writing up IT Security flaws on your network”.

And I suppose this really proves my point best of all.

Information security vendors like NetClarity do not have any economic incentive to really reduce data security and compliance breaches that would reduce  sales, making it better business for them  (not for their customers) to sell ineffective products.

This raises an interesting question about information security business models – but that’s a topic best left to another post.

Well – not exactly. Actually, probably not.

As Craig Balding pointed out on his blog post Is Amazon AWS Really HIPAA Compliant Today? there are some basic issues with AWS itself.

There is no customer accessible AWS API call audit log
In other words, you have no way to know if, when and from where (source IP) your AWS key was used to make API calls that may affect the security posture of your AWS resources (an exception is S3, but only if you turn on logging (off by default)).

There is no way to restrict the source IP address from which the AWS API key can be used.
The AWS API interface can be used from any source IP at any time (and as above, you have no audit trail for EC2 API calls).  This is equivalent of exposing your compute and storage management API to the entire planet.

Each AWS account is limited to a single key – unauthorized disclosure of the key results in total breakdown of security

It only gets worse.
Web services and storage are just a small part of  data security.
Even if Amazon AWS was perfect in terms of it’s data security countermeasures – there would still be plenty of opportunity for a data breach of PHI.

There are multiple attack vectors from the perspective of HIPAA compliance and PHI data security.  The following schematic gives you an idea of how an attacker can steal PHI, figure (inspired of my colleague Michel Godet) using any combination of no less than 15 attack vectors to abuse and steal PHI:

There are potential data security vulnerabilities in the client layer, transmission layer, platform layer (Operating system) and cloud services (Amazon AWS in our example).

Note that the vulnerabilities for a PHI data breach can not only happen inside any layer but in particular there are vulnerabilities in the system interfaces between layers.

Let’s take a specific example.

Consider a remote medical diagnostic service that collects information, transmits it over secure channels (https for the sake of argument) to a centralized facility for processing and diagnosis.  The entire transmission stream can be secure but if the processing and diagnosis facility uses Microsoft IIS as an interface, it is possible to attack the IIS Web server, create denial of service and exploit IIS7 and Windows operating system vulnerabilities in order to gain access to the machine itself, the data in motion and possibly gain access and compromise the internal network.

A discussion of HIPAA compliance needs to include a comprehensive threat analysis of the entire supply chain of data processing and not just limit itself to the cloud services that store electronic medical records.

For further reading, see the below resources on HIPAA compliance with Amazon Web services and work that Software Associates has done on threat modeling.

• Creating HIPAA-Compliant Medical Data Applications with Amazon Web Services – The article briefly outlines how companies can use Amazon Web Services to power HIPAA-compliant information processing systems. It focuses on the HIPAA sections The Privacy Rule and The Security Rule, and how to encrypt and protect your data in the AWS cloud.
• Encrypted Storage in the Cloud – Commentary and insight based on the article above.