•

» compliance

Focus first on IT security goals, compliance will follow

Posted on June 6, 2010 by John Reno in Main | Leave a comment

I was depressed earlier this week from conversations with a security vendor and a system developer. They both had developed, more or less, the same point of view. The security vendor said, “Compliance is what sells”. The system developer said, “Failed audits are what can get the attention of management.” Compliance is certainly necessary for most companies, whether driven from the standpoint of adherence with internal policies or government regulations. In many cases compliance requirements have provided the impetus and funding for a first class information security program. The problem is that compliance does not necessarily lead to security. Ask any shareholder from TJX.

So then what path can be taken assure security for a given business? Unfortunately, there are no silver bullets available at any price (ask Google). However, structuring a continuous security management process around several important elements can yield results that strengthen the business both qualitatively and quantitatively. These key elements include understanding the threat environment, designing security in as a systems requirement, managing risks and winning the economic contest with adversaries.

For this discussion we’ll focus on security goals and designing security in as a system requirement. In this case the systems we need to consider are not just applications but the networks, policy enforcement points, virtual machines, and servers that support them. Security goals consist of the following:

• Authentication
• Authorization
• Confidentiality
• Data/message integrity
• Availability
• Non-repudiation
• Accountability

These need to be defined in terms of specific, measurable and documented requirements. As such they become features of the overall system, but also contribute to a larger set of processes by which the system is developed, tested, deployed and maintained. Without shared understanding of security goals and requirements among stakeholders such as developers, architects, testers and operations staff, the business is put at risk and efforts to add security after the fact will be frustrating if not impossible. As an example of what not to do, consider the Microsoft SMB protocol. Security goals were never established in initial versions. Later versions still suffered from deficiencies ranging from lack of documentation to no requirement for client authentication to highly complex cross-domain deployment. Today at least 12 dialects of SMB exist that continue to offer attackers a rich target. Over time, Microsoft has emerged as a major proponent of security goals and designing in security, but there are innumerable legacy systems out there where the damage has been done.

What then is the optimum path to a secure and compliant business? My recommendation is to start with security goals, build processes from aggregated goals associated with the business critical systems, adapt internal policies to support the security goals and then extend internal policies to comply with regulatory requirements. Working the process in reverse, starting with compliance to regulatory requirements, means clear security goals may never surface. Without the foundation of security goals for the systems that support the business, security policies and processes are difficult to manage, internal and regulatory compliance is costly to maintain and the business is put at risk.

Economics, HIE’s, and Information Security

Posted on May 5, 2010 by John Reno in Main | Leave a comment

Do economics, HIE’s and information security seem like a strange set of words to find together? I’ve been spending a lot of time recently talking with folks at healthcare providers and healthcare IT vendors, and they have found the relationships among these words fascinating. What I have encountered is a quite different set of viewpoints, that form an interesting contrast with the stories related to ARRA funding, state HIE initiatives and breach notification penalties that have been filling the mainstream healthcare IT trade press.

My primary line of discussion with providers (mainly hospitals and integrated delivery networks or IDNs) and HIE vendors has been around the topic of what are the economic drivers associated with HIE deployment and use. It was interesting to find that while hospitals and IDNs see significant benefit in participating in state funded and operated HIE’s over the medium to long term, they are launching their own HIE programs to take advantage of economic benefits in several areas. Several organizations outlined the following elements of near term focus:

• Decrease costs through elimination of redundant tests, fewer lab orders and imaging procedures.

• Improve productivity through workflow optimization in areas such as finding patient records and overall throughput.

• Increase quality in areas such as e-prescribing and more accurate diagnosis.

Over the medium to long term, expected benefits included additional areas such as meeting meaningful use requirements, increased physician referrals and improved patient satisfaction.

Another significant development that has lowered the barriers to taking on an HIE initiative is the growing popularity of software-as-a-service (SaaS) based solutions from the HIE vendor community. These services from vendors such as Axolotl, eClinicalWorks, Initiate, Medicity and RelayHealth mean that the funding organization does not have a capital outlay.  The hospital or IDN needs to focus simply on the operating model to make the economics work.

So where does information security factor into the equation? Well for one, from the vendors and providers that I have talked with, the prospect of managing the security, compliance and privacy of all the sensitive data that an HIE program drives causes a great deal of lost sleep. But security must also be viewed as an economic enabler – if the patients, physicians and hospital staff can use the system effectively, with the assurance that sensitive data is protected and accessed properly, the benefits described earlier can generate the necessary top-line and bottom-line results. Often a common pitfall encountered in structuring security programs is a reliance on simply meeting compliance requirements. While necessary, such an approach by no means is a formula for ensuring security or reducing risk.

In working with both vendors and providers on security, privacy and compliance in the HIE space, we have found the most productive approach is to start with an assessment, break the problem down in to manageable areas, staff appropriately and manage risk on an ongoing basis. The table below outlines how we structure a security assessment for both vendors that are operating a SaaS-based HIE solution or healthcare providers that are using the system.

The information security program is fundamental to the success of an HIE initiative. Making the economic model work effectively requires a focus beyond obvious areas such as compliance and technical controls with careful attention to governance, risk management, and operational process. Draw on expert experience and the business benefits of an HIE program will yield near term and long term results.