» application security

HIE’s – Now That the Funding is Complete, What Will the Operational Environment Look Like?

Posted on by John Reno in Main | 1 Comment

Last week the Department of Health and Human Services (HHS) announced an additional round of $162M in funding for Healthcare Information Exchanges. Combined with the state grants announced in February, this brings total funding to $547M. This means that all the states and state designated entities are on a path towards implementing the vision of the Office of the National Coordinator for Health Information Technology (ONC) laid out in their strategic plan.

The next step in the process calls for states to develop and align strategic and operational plans that cover what the ONC has termed as the five essential domains: governance, finance, technical infrastructure, business and technical operations and legal/policy. These plans are critical because strategic and operational plans must be approved by HHS before the states are free to begin to use HIE funds for implementation purposes. The plans are also critical to ensure coordination around standards and expand the use of HIE to a national level.

As one might expect this has created a great deal of activity in the healthcare IT sector as vendors position themselves for the operational phase associated with the state funding. As we enter this next phase in the evolution of HIE’s one of the major challenges to be overcome in driving HIE success is associated with ensuring security and privacy, as well as efficiently demonstrating compliance with HIPAA and HITECH requirements. With user requirements ranging from large hospitals to small physicians’ offices, answers to basic questions such as appropriate technical protection mechanisms and access controls present significant challenges. To a certain extent, forming the appropriate answers to questions of security and privacy requires definition of the compute and storage model that will be most prevalent in the environment.

In many respects, the leading model that is emerging in the HIE market is that of a cloud services based platform. In this model the cloud service provider is responsible for providing highly scalable services, authorization, access control, audit logging and data protection. Many vendors such as Axolotl, Covisint, IBM, Microsoft HealthVault/Amalga and Medicity have announced offerings in some form. These have included API’s that allow specialized applications to be developed rapidly while taking advantage of the core infrastructure services. Example applications range from clinical decision support to meaningful use reporting. An illustration of this framework is shown below.


The platform as a service model can be very powerful in the HIE environment because security and privacy services can be leveraged by the applications as well as the providers and consumers of the information. However, for rapid deployment and efficient ongoing operations it is critical that the providers of healthcare cloud services communicate security, privacy and compliance practices and procedures to customers in a transparent fashion. The hospitals, laboratories and physician practices that form the customer base of the HIE need to be able to understand this information and ensure that their security, privacy and compliance needs are met.

A further critical requirement in this model is for the API’s to support a secure ecosystem with common security controls that have been thoroughly tested. I think the emerging nature of the HIE market presents an excellent opportunity for platform vendors to coalesce around a common set of application security controls such as OWASP Enterprise Security API. Adoption of ESAPI would provide consistent application protection as well as leverage for both cloud platform providers and application developers.

As the HIE market evolves through this important phase of development it will be critical to continue to look for additional areas of leverage in the areas of privacy, security and compliance among the many stakeholders.

Force Multipliers for Web Application Security

Posted on by John Reno in Main | Leave a comment

Over the last several years many analysts, including Gartner, have identified application security as the area presenting the most significant risk to companies with internet facing applications. As a result a number of best practices have emerged, ranging from secure coding practices and developer training from organizations such as Microsoft to change management driven black-box testing. However, one area where I see developers and security teams consistently struggle (and often introduce significant vulnerabilities) in terms of application security is with development of their own security controls.

Even with extensive security training, security controls are very difficult to get right. It requires extensive understanding of potential attacks, as well as implementation skill. Furthermore, a lot of things can go wrong – failure to perform output encoding, weak hashes and lack of access control, just to name a few areas.

A leveraged way to solve this problem is to take advantage of the open source work that OWASP has done with the Enterprise Security API.

As shown in the diagram above these libraries cover a wide range of security issues.  They are a standard, high quality and well tested set of security controls that developers should take advantage of. ESAPI is available for a wide range of development environments including Microsoft .NET, J2EE and PHP. This can be an important foundation for an application security program.

Web Application Security

Posted on by admin in Main | Leave a comment

Customers often ask the following question:  What is the best approach to securing my web applications?  Of course, the answer to the question is what our web application security assessments are all about.  But if you haven’t yet engaged in that process, this post briefly outlines some ideas that you can institute to have a greater degree of confidence that your web applications are secure.

Fundamentally, secure web applications are a result of a secure software development lifecycle.  There are a number of books on the subject.  I have found that a useful reference can be found through OWASP: http://www.owasp.org/index.php/CLASP_Concepts.   What‘s necessary is for the software development team to have a structured set of guidelines to ensure that information security is kept as a key requirement as part of the development process.  Often it is helpful to maintain an implementation guide and templates that reflect best practices.  As with any endeavor related to security, I recommend a risk based approach where development effort to secure the application is guided by the risks to business.

In order to have an understanding of the risks associated with an application; developers must understand the threats that are present.  A common practice is to develop a threat model that characterizes the threats and risks to the application.  Microsoft has invested significant resources in formalizing this process.  They recommend a step by step process of identifying security objectives; reviewing the application in terms of components, data flows and trust boundaries; decomposing the application in terms of components to identify areas where security needs to be evaluated; creating a structured list of threats; and enumerating likely vulnerabilities associated with the class of application in development.  To assist in this effort of threat and risk modeling Microsoft advocates a threat classification scheme known as STRIDE.  This scheme aims to characterize the threats with respect to the exploit that may be employed.  This clever acronym stands for:

  • Spoofing Identity
  • Tampering with data
  • Repudiation
  • Information disclosure
  • Denial of service
  • Elevation of privilege

These areas provide a helpful mechanism for enumerating threats to the application.  Closely associated with this process is a scoring scheme to help evaluate risk to the application.  Another acronym applies to this problem as well: DREAD.

DREAD attempts to quantify, compare and prioritize the amount of risk presented by a given threat.  It stands for

  • Damage potential
  • Reproducibility
  • Exploitability
  • Affected users
  • Discoverability

Typically each of these areas is assessed on a scale of 1 to 10 with 10 referring to the most severe risk.  As always risk needs to be evaluated in terms of both probability and impact.

During the development process the team can often benefit from using tools aimed at identifying security flaws.  The most prevalent approach used by security conscious developers is to employ source code analysis tools.  These tools automate the process of evaluating source code for common security vulnerabilities.  Many commercial tools have gained popularity and there are open source options as well, including RATS and Flawfinder.

As the application reaches the integration stage best practices call for black-box testing.  Many commercial tools address this method of testing applications from a security point of view.  Open source solutions exist as well including, Spike and WebScarab.  I have found that one of the more effective processes calls for integration of the black-box test with the build cycle.  In this fashion, when the application is built, the black box testing program is run as well.  Once complete, developers can review the results and address vulnerabilities that have been identified.

The techniques described above help secure new applications, but organizations must also be aware of the risks associated with applications that are running in production.  To assess these applications a different strategy must be employed.  One potential approach is to run a black-box test with a suite of attacks that are known to be non-invasive and likely will not take down the application.  Because this approach can miss many high impact vulnerabilities, I would recommend against it.  A better option, given that the application is deployed in a virtualized environment, is to take a “snapshot” of the application to be tested.  This image is then moved to a staging environment where it can be tested thoroughly.  When vulnerabilities are identified the application must be fixed, tested and then released back to production under change control.

Hopefully, these notes on securing applications have generated some ideas regarding how you can go about improving your application security process.