Sunday, January 22, 2017

Healthcare IT, Security and Cloud Services


Over the last year, more so with the focus on the Omnibus Rule requirements coming to a head, I've been hearing a lot of discussion around the how to when it comes to betting managing these requirements.

When we speak about HIPAA, invariably the two components of data security and data privacy arises.

In the traditional data centers, database managers and data owners know where their data resides and implement the necessary processes to preserve privacy and audit access.

However, when we move to the cloud, the cloud being all about data, we are looking at servers, network, and storage that are abstracted. This raises concern that data owners may not necessarily know where their data sets physically reside and we are looking at Cloud Service Provider (CSP) employees who will be handling confidential patient data or Personally Identifiable Information (PII).

Of importance here is that when it comes to leveraging the cloud ecosystem for healthcare segments, the foremost concerns are around HIPAA and the  HITECH Act compliance capabilities and meaningful use provisions.

Most of us within the Healthcare IT world have an understanding of meaningful use.

According to HealthIT.gov
"Meaningful use is the set of standards defined by the Centers for Medicare & Medicaid Services (CMS) Incentive Programs that governs the use of electronic health records and allows eligible providers and hospitals to earn incentive payments by meeting specific criteria." 

The goal of meaningful use is to promote the spread of Electronic Health Records (EHR) to improve health care in the United States.
Benefits of meaningful use of EHRs include:

  • Complete and accurate information.
  • Better access to information.
  • Patient empowerment.

In the healthcare world, organizations are positioning to attain meaningful use. This to capture the incentives allocated by the Federal Government as well as to ensure that reimbursements do not face jeopardy for providers not in line with the meaningful use provisions.

As healthcare practitioners and organizations increase the use of technology solutions in delivering clinical care, their IT departments are faced with additional stress to provide availability on demand and operate data center approaching 99.999 percent availability. In most cases this is a major challenge that can lead to the risk of unscheduled outages and costly solutions.

What I'm increasingly seeing is a lack of IT Security and Operational resources to monitor, manage and continually assess security within some organizations.

This is no fault of anyone, but rather demand is outpacing supply for skilled ITSec professionals, possessing a good mix of business need understanding, an ITSec track record with automated and manual testing skills, as well as ability to find "new" threats to any one system.

Assuring high availability for healthcare applications, means meeting up-time requirements; and in today's environments will require access to more than one data center for fail-over and continuity or even for managing a DDoS attack be they through dispersed cleaning sites or other traffic management processes. This can significantly impact the overall capital investment in data center infrastructure for healthcare organizations.

Looking to the cloud as a solution is not only the next step in services but will ensure high availability of clinical applications. This will allow a healthcare organization to leverage the expertise and financial stability of an established CSP. Another advantage of leveraging a cloud ecosystem, is that of rapid provisioning and deployment, with the ability to change compute capacity as demand changes.

Thus in the event of failure, server instances can be seamlessly moved to alternate hosts or in anticipation can be clustered to provide redundancy.
Some may ask whether it is risky to transfer data from site to cloud. The answer is no as a majority of organizations move data over the Internet via encryption channels. Where we can see concerns arising is with the hand-off of data into the (CSP) environment.

In a seamless environment all data will have site to site encryption up to and including storage. Where we can see some separation is with healthcare application vendors support.

In the cloud, it is a given that we can have a number of people with access to the physical servers and storage that cloud consumers have no control over. For an IT Security person this will elicit conflicting concerns as on one hand there is the presupposition that complete control is being relinquished which can only be assured with prescriptive precautions defined by a CSP.

The cloud computing ecosystem is still evolving and as such there is still a lack of industry-wide certifications. As we mature within this ecosystem the intent is to drive toward processes, best practices and certifications which would provide legal protection that can reduce the complexities of a long negotiation and complex SLA requirements.

Within a regular data center or even a small IT shop, as an IT Security leader one of my first expectation for any shop is some form of centralized logging with automation. Similarly by transferring such a mindset into the cloud ecosystem (they are after datacenters) any healthcare customer security leaders expect the assurance that detailed reporting is a given.

Having worked on the security strategy and assessment separately for a few cloud computing projects, I have seen first-hand, that access rights was a major focus. In light of this, it is not a complex process to segment solutions for healthcare.

As a result any access to servers and storage dedicated to a healthcare customer by anyone within a CSP organization will be logged and thus can provide the assurance of controls around access.

From a legal perspective, more specifically talking contracts, healthcare customers expect the provisions of strong financial penalties to indemnify against a breech as well as to hold the CSP accountable.

Some CSPs are moving to providing a HIPAA Business Associate Agreement (BAA) for their healthcare customers. The assurance provided by their BAA demonstrates meeting the compliance requirements (enabling the physical, technical, and administrative safeguards required) of the HIPAA and the HITECH Acts.

In closing, I will state that HIPPA compliance and cloud computing do not have to be in conflict. Rather healthcare entities can leverage the benefits of the cloud, coupled with the necessary due diligence and legal contracts to meet their needs

Software as a Service (SaaS), Security and Risk Management: Part 1

As cloud computing technologies and offerings mature and evolves in its services to customers, one common consumer use will be that of the Software as a Service (SaaS) model.



Earlier articles by this author have touched on the various models, risks, security and forensics at several levels. There also a plethora of resources available now that end users can educate themselves with that are freely available online.



This article will focus on aspects of security that impact the SaaS environment as developed, presented or augmented by the author for several Cloud Computing projects.



Before we proceed in the subject matter, a brief clarification of what this author refers to as the cloud follows. Keep in mind that this term “cloud computing” is now being used to describe a broad range of services to include product descriptors that sits outside the common definition of the cloud.



For ease of reference I will refer to the National Institute of Standards and Technology (NIST) [1] definition of which the following is a part. “Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.”



Over the years since the concept of Cloud Computing evolved we have seen an accepted concept of the “Cloud Computing Stack”, with its three distinct categories: Software as a Service, Platform as a Service and Infrastructure as a Service; where the IaaS Is the platform upon which PaaS rests and which is turn has SaaS rests moving up from IaaS to SaaS.



 It is important to keep this basic stack in mind as the building blocks of the Cloud Computing system and not get distracted by all the “as a Service” spring up across markets as we proceed with this article.



As we move more and more services into the Cloud ecosystem, there will always be concerns regarding security. However a prescriptive combination of both preventive and detective controls at those data centers housing the IaaS ecosystem is on the path to security compliance and event mitigation. These controls, as a step toward better cloud computing security should be assessed and assured to meet industry tested security controls, as well as regulatory and policy requirements. The same format can be modified and applied up the stack to the PaaS segment. 



However it is at the SaaS layer that we can perceive additional challenges with cloud security. One critical area of concern stems from the potential risk that a client’s data can be exposed to as it is stored within the storage system of its SaaS provider. This risk can potentially increase in the event of the SaaS provider in turn utilizing the services of a third party IaaS provider.



Whilst effective data center security controls are good for inside a data center, web-services or applications outside this area are a growing target for application layer type attacks. This can lead to the loss of critical to sensitive customer data as well as intellectual property and other corporate data. 

A challenge for the IT security professional here is how to implement a level of protection that meets IT Security control requirements as well as ensures compliance with information security regulations, E.g. PCI-DSS in the case of transactions via web services. 



In both the traditional environments and cloud services infrastructure environments, we have firewalls tweaked and configured with rulebase automation as a best practice. However in the dynamic cloud environment I believe that having to manage firewall signatures for example, amongst other issues could be challenging and counter-productive. 



Essentially we would need to implement security in a layered approach which should include the network, servers, databases and coding, augmented by a system that should have a defined security process based on the SaaS environment and its functionality. This should be an additive measure to augment other monitoring and logging systems deployed to secure this environment.



This system should also have the ability to implement tools that will be able to dynamically learn the behavior of an application supported by an automated mechanism, thus removing the need for signatures in the case of firewall systems as mentioned earlier.



Within the SaaS environment we need to ensure adequate security in input validation by SaaS end users, effective user authentication and authorization, proper data segregation with security encapsulation for data in motion using SSL (3.0 or above) or TLS (1.0 above), effective software patching policies and procedures by the SaaS provider working with its software vendors as well as a key generation strategy. 



(While SSL/TLS is encryption for data in motion between a Web Server and a browser is a good practice, administrators should disable weak algorithms and ciphers residing on the Web Server).



There must also be assurance for uptime or availability that is formalized in a Service Level Agreement (SLA). Impact on environments supporting the SaaS ecosystem can be attacks impacting Network Security as well as the process for Backup and Recovery.



Researchers Bhadauria and Sanyal [1] stated “Two types of servers are used by SaaS: the Main Consistence Server (MCS) and Domain Consistence Server (DCS). Cache coherence is achieved by the cooperation between MCS and DCS. In SaaS, if the MCS is damaged, or compromised, the control over the cloud environment is lost. Hence securing the MCS is of great importance.”

 

Another concern within this ecosystem is that of cross site scripting attacks that targets Asynchronous JavaScript and XML- AJAX [2].A best practice here would be to have a policy that ensures that all calls are verified with the Web Server and Service to ensure proper authentication and authorization before allowing the request. 



Moving away a bit from the technology of security in this environment, Cloud Computing and SaaS on a whole was in its infancy and in some circles denounced as a viable IT service (no names called here, but a tech company leader specializing in databases and now cloud products comes to mind).



In terms of regulations that impact web services and by extension SaaS, we can reference the Gramm-Leach-Bliley Act (GLBA) passed in 1999, Sarbanes-Oxley Act (SOX) in 2002, and the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule and Security Rule of 2003.  All three of these regulations, although important in their relative environments (e.g. Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), Intellectual Property systems (IPS) and Human Resources Systems), were not crafted to include elements of a SaaS environment then.



 As a result there needs to be finite and focused addendums or improvement to these acts as was in the case of SAS 70 to SSAE 16 to meet this technological evolution.



Of importance is that, despite the security measures and attestations provided by a SaaS provider to assure a client of their security controls or compensating controls and compliance processes in place to meet regulatory and security standards; it is still the responsibility of a data owner to maintain industry regulated requirements to comply with confidentiality, integrity, non-repudiation and security control over sensitive to critical information. 



So the challenge here is to ensure that a cloud client requirement (Security Policy, Strategy, Data Provenance, Operational and End-User Security) is part of the discussion with the cloud provider and most if not all requirements mirror.



 The designation of data classification is part of another topic and should be the influenced by the result of risk impact and gap analysis.



As a closing point the value of vulnerability assessments and penetration tests within the SaaS environment is an important tool for an independent set of eyes to present information that a potential attacker will find and use against the SaaS. This is not only related to technology as is well known due to the rise of social engineering.



References

[1] A Survey on Security Issues in Cloud Computing www.ijcaonline.org › Archives › Volume 47 › Number 18, Rohit Bhadauria; Sugata Sanyal, 2012



[2] Jesse James Garrett (18 February 2005). "Ajax: A New Approach to Web Applications". AdaptivePath.com.









Risk and Its Impact on Security Within the Cloud - Part 1 The effect of people and processes on cloud technologies

These days when we hear the term "cloud computing" there is an understanding that we are speaking about a flexible, cost-effective, and proven delivery platform that is being utilized or will be utilized to provide IT services over the Internet. As end users or researchers of all things "cloud" we expect to hear about how quickly processes, applications, and services can be provisioned, deployed and scaled, as needed, regardless of users' physical locations.

When we think of the typical traditional IT security environment, we have to be cognizant of the potential for an onslaught of attacks, be they zero day, the ever-evolving malware engines and the increase in attacks via social engineering, the challenge for any security professional is to develop and ensure as secure an IT system as possible.

Thoughts on Traditional Security and Risk
Common discussions within the spectrum of IT security are risks, threats and vulnerability, and an awareness of the impact of people and processes on technologies. Having had opportunities to work on data center migrations as well as cloud services infrastructures, a primary question of mine has been: what then of the cloud and cloud security and the related risk derived from selected services being outsourced to a third-party provider?

ISO 27005 defines risk as a "potential that a given threat will exploit vulnerabilities of an asset or group of assets and thereby cause harm to the organization."

In terms of an organization, risk can be mitigated, transferred or accepted. Calculating risk usually involves:

Calculating the value of an asset
Giving it a weight of importance in order to prioritize its ranking for analysis
Conducting a vulnerability analysis
Conducting an impact analysis
Determining its associated risk.

As a security consultant, I also like the balanced scorecard as proposed by Robert Kaplan and David Norton, especially when aimed at demonstrating compliance with policies that will protect my organization from loss.

Cloud Security and Risk
In terms of cloud security, one key point to remember is that there is an infrastructure somewhere that supports and provides cloud computing services. In other words the same mitigating factors that apply to ensure security within a traditional IT infrastructure will apply to a cloud provider's infrastructure.

All this is well and good within the traditional IT environment, but how then can we assess, or even forecast for and/or mitigate risk when we are working with a cloud computing system? Some argue that "cloud authorization systems are not robust enough with as little as a password and username to gain access to the system, in many private clouds; usernames can be very similar, degrading the authorization measures" (Curran,Carlin 2011)

We have had the arguments that the concentrated IT security capabilities at cloud service provider (CSP) can be beneficial to a cloud service customer (CSC); however, businesses are in the realm of business to ensure a profit from their engagements. One study by P. McFedries (2008) found that "disciplined companies achieved on average an 18% reduction in their IT budget from cloud computing and a 16% reduction in data center power costs."

To mitigate this concern, a CSC will need to ensure that their CSP defines the cloud environment as the customer moves beyond their "protected" traditional perimeter. Both organizations need to ensure that all high risk security impact to the customer organization meets or exceeds the customer organization's security policy and requirements and their proposed mitigation measures. As part of a "cloud policy" a CSC security team should identify and understand any cloud-specific security risks and their potential impact to the organization.

Additionally a CSP should leverage their economies of scale when it comes to cloud security (assets, personnel, experience) to offer a CSC an amalgamation of security segments and security subsystem boundaries. Any proficient IT Security practitioner then can benefit from the advantage of leveraging a cloud provider's security model. However, when it applies to business needs the 'one size fits all' cloud security strategy will not work.

Of utmost importance when looking to engage the services of a cloud provider is gaining a clear picture of how the provider will ensure the integrity of data to be held within their cloud service/s. That said all the security in the world would not prevent the seizure of equipment from government agencies investigating a crime. Such a seizure can interrupt business operations or even totally halt business for an innocent CSC sharing a server that hosts the VM of an entity under investigation. One way to manage the impact on a CSC function within the cloud as suggested by Chen, Paxon and Katz (2010) is the concept of "mutual auditability."

The researchers further went on to state that CSPs and CSCs will need to develop a mutual trust model, "in a bilateral or multilateral fashion." The outcome of such a model will allow a CSP "in search and seizure incidents to demonstrate to law enforcement that they have turned over all relevant evidence, and prove to users that they turned over only the necessary evidence and nothing more."

Is it then feasible for a CSC to calculate the risk associated with such an event and ensure that there is a continuity plan in place to mitigate such an incident ? That will depend on the business impacted.

Another cause for concern from cloud computing introduces a shared resource environment from which an attacker can exploit covert and side channels.

Risks such as this need to be acknowledged and addressed when documenting the CSP-CSC Service Level Agreement (SLA). This of course may be in addition to demands with respect to concerns for Availability, Integrity, Security, Privacy and Reliability? Would a CSC feel assured that their data is safe when a CSP provides assurance that they follow the traditional static based risk assessment models?

I argue not, since we are working within a dynamic environment. According to Kaliski, Ristenpart, Tromer, Shacham, and Savage (2009) "neighbouring content is more at risk of contamination, or at least compromise, from the content in nearby containers."

So how then should we calculate risk within the Cloud? According to Kaliski and Pauley of the EMC Corporation, "just as the cloud is "on-demand," increasingly, risk assessments applied to the cloud will need to be "on-demand" as well."

The suggestion by Kaliski and Pauley was to implement a risk as a service model that integrates an autonomic system, which must be able to effectively measure its environment as well as "adjust its behavior based on goals and the current context".

Of course this is a theoretical model and further research will have to be conducted to gather data points and "an autonomic manager that analyses risks and implements changes".

In terms of now, I believe that if we can utilize a portion of a static risk assessment, define specific controls and control objectives as well as map such to that within a CSP or, define it during the SLA process, a CSC can then observe control activities that manage and/or mitigate risk to their data housed at the CSP.

Traditionally governance and compliance requirements should also still apply to the CSP, e.g., there must be a third-party auditor for the CSP cloud services and these services should have industry recognized security certificates where applicable.

Conclusion
Some things that a CSC needs to be cognizant of with regard to cloud security in addition to tradition IT security measures with a CSP are:

The ability of the CSP to support dynamic data operation for cloud data storage applications while ensuring the security and integrity of data at rest
Have a process in place to challenge the cloud storage servers to ensure the correctness of the cloud data with the ability of original files being able to be recovered by interacting with the server (Wang 2011)
Encryption-on-demand ability or other encryption metrics that meets an industry standard, e.g., NIST
A privacy-preserving public auditing system for data storage security in Cloud Computing (W. L. Wang 2010)
Cloud application security policies automation
Cloud model-driven security process, broken down in the following steps: policy modelling, automatic policy generation, policy enforcement, policy auditing, and automatic update (Lang 2011) 

Continued in Part 2

Works Cited

Curran, Sean Carlin and Kevin. "Cloud Computing Security. ." International Journal of Ambient Computing and Intelligence, 2011: 38-46.
Lang, Ulrich. Model-driven cloud security. IBM, 2011.
Thomas Ristenpart, Eran Tromer, Hovav Shacham, and Stefan Savage. Hey, You, Get Off of My Cloud!Exploring Information Leakage in Third-Party Compute Clouds. CCS 2009, ACM Press, 2009.
Wang, Wang, Li, Ren. Privacy-Preserving Public Auditing for Data Storage Security in Cloud Computing. IEEE INFOCOM, 2010.
Wang, Wang,Li Ren. Lou. "Enabling Public Verifiability and Data Dynamics for Storage Security in Cloud Computing." Chicago, 2011.
Yanpei Chen, Vern Paxson,Randy H. Katz. What's New About Cloud Computing Security? Berkeley: University of California at Berkeley, 2010.