The first thing you need to know about blockchain is that it enables the creation of virtual currencies and intelligent contracts. At its core is the concept of a “distributed ledger,” where data on transactions is recorded across a range of specified databases. Every transaction can be tracked and replicated in real time. That’s how the identities of user accounts, even if they are anonymous, can be verified and secured behind advanced cryptography and digital signatures.

read more

(c)iStock.com/jackaldu

Healthcare companies that are accustomed to complete control over physical systems often struggle to understand their responsibilities in a cloud environment. Who is responsible for which aspects of compliance? Can healthcare companies trust Amazon with their mission-critical apps and sensitive data? What are the rules and boundaries for AWS compliance?

Mastering these intricacies can help you create compliance-ready systems on AWS. In this article, we will cover the basics, but for a deeper dive, download our eBook on Compliance on AWS.

Shared compliance responsibility on AWS (the short version)

By migrating to AWS, you have a shared compliance responsibility. This shared model means that AWS manages the infrastructure components from the host operating system (virtualisation layer) down to the physical security of AWS’ data centres. It is the customer’s responsibility to configure and secure AWS-provided services. In other words, AWS controls physical components; the customer owns and controls everything else. As AWS states repeatedly, “AWS manages security of the cloud, security in the cloud is the customer’s responsibility.”

Bottom line: Think of operating a compliant environment in AWS as similar to operating in a rented data centre. The data centre is responsible for controlling access to the data centre, locking the cages, and the physical security of the network — but you are responsible for everything else.

The AWS Shared Responsibility Model. Includes tasks performed by Logicworks. If you are managing your own environment, the tasks in blue would be your responsibility.

The same line of demarcation applies to IT controls. Customers in AWS shift the management of some IT controls to AWS, which results in a shared control environment. AWS manages controls associated with the physical and architectural infrastructure deployed in the AWS environment; the customer is responsible for network controls (Security Group configurations), access controls, encryption, and any control not directly managed by AWS.

For example, AWS provides the Identity and Access Management (IAM) tool and is responsible the IT controls in place that govern access to the physical infrastructure that holds your access policies, and customers are responsible for the setting up and maintaining roles and users in IAM. Inappropriate or unauthorised usage of an AWS resource as a result of inadequate IAM controls is the customer responsibility.  

Physical security and environmental controls

Any customer can access a copy of AWS’ SOC 1 Type II report, which provides significant detail about physical security and environment controls. The report can be accessed through AWS Artifact, a repository of audit artifacts. This means that if an auditor requests specifics regarding the physical controls of a customer’s system, they can reference the AWS SOC 1 Type II report. AWS does not allow data centre tours, as independent reviews of data centre security are also part of the SOC, ISO 27001, and other audits.

Data privacy

AWS customers retain control and ownership of their data, and customers can move data on and off of AWS storage as required. AWS does not leverage any third-party providers to deliver services to customers and therefore does not provide any customer information or access to data to any other provider. Customers must control access to applications and data through the AWS Identity and Access Management service.

Client environments on AWS infrastructure are by default logically segregated from each other and have been designed to prevent customers from accessing instances not assigned to them. AWS has both instances that are dedicated to a single customer (Dedicated Instances) and instances hosted on shared infrastructure. AWS is responsible for patching the hypervisor and networking services, while customers patch their own guest operating systems, software, and applications.

Backups

AWS provides services to help customers perform their own backups. Amazon S3 and Glacier are the most popular options, and AWS provides data durability and redundancy guarantees. In this way, AWS provides services to enable disaster recovery and resiliency but does not automatically provide backups.

HIPAA in AWS

New AWS customers often ask: Is AWS compliant with HIPAA? The answer to this question is complex. The short answer is that AWS is not “HIPAA compliant”, but it provides services that facilitate HIPAA compliance.

The U.S. Health Insurance Portability and Accountability Act (HIPAA) Privacy and Security Rules for protecting Protected Health Information (PHI) does not provide a certification or Attestation of Compliance to cloud providers or to healthcare companies. HIPAA is a set of federal regulations, not a security standard. A company and its business associates can be periodically audited for compliance with HIPAA regulations by the HHS Office for Civil Rights (OCR), and in the course of that audit it can meet or fail to meet those requirements, but it cannot be “Certified HIPAA Compliant”.

In order to process, store, or transmit PHI in AWS, a healthcare company (the “covered entity”) must sign a Business Associate Agreement (BAA) with AWS, meaning that AWS is performing function or activities on behalf of the covered entity.

However, signing a BAA with AWS does not mean that the customer is “HIPAA compliant”. The customer can maintain compliance with HIPAA regulations through its own efforts to use cloud tools, architect applications, control access, etc. in a manner that complies with those regulations. AWS only assumes responsibility for physical hardware security controls of a limited number of covered services.

Covered services

For each compliance standard, there is a subset of AWS services/programs that are “in scope” of either the Attestation of Compliance, report, or contract. This means that these services have been audited by a third party for that specific compliance standard.

Customers may use any AWS service in an account designated as a HIPAA account, but they should only process, store and transmit PHI in the HIPAA-eligible services defined in the BAA. There are nine HIPAA-eligible services today, including:

• Amazon DynamoDB
• Amazon EBS
• Amazon EC2
• Amazon Elastic MapReduce (EMR)
• Amazon Elastic Load Balancer (ELB)
• Amazon Glacier
• Amazon Relational Database Service (RDS) [MySQL and Oracle engines]
• Amazon Redshift
• Amazon S3

Again, this does not preclude customers from using services that are not in scope. For example, AWS CloudFormation, an infrastructure as code service that we discuss in-depth in our eBook, is not included in the list of services in scope for a HIPAA BAA. But as long as no PHI is stored, processed or transmitted in AWS CloudFormation, a covered entity may use it. AWS CloudFormation is a templating service that can build out the core components of AWS architecture (networks, instances, etc) and therefore rarely if ever touches customer data in any use case, even in non-HIPAA regulated environments. Similarly, customers can use a service like AWS CloudWatch Logs, a logging service, if logs are scrubbed of customer information.

Compliance responsibility: Insource vs. outsource

Compliance management is a complex set of tasks with many interrelated components. By outsourcing to AWS, you are already removing some of the risk and cost of compliance, particularly as it relates to physical infrastructure security. Outsourcing infrastructure management to a third party Managed Services Provider further reduces your compliance burden.

Most companies that have compliance obligations and are new to AWS choose to work with a partner to plan, build, deploy, and operate their AWS environment in order to minimise risk, rapidly build out a compliance-ready environment, and minimise the time and effort of ongoing compliance maintenance.

Below is an example of a compliance responsibility matrix when you work with Logicworks:

Resources

AWS has published extensively on the topic of shared compliance responsibility. If you are considering hosting regulated data in AWS, we highly recommend that you utilise these resources:

General compliance information:

• Continuous Compliance on AWS: http://go.logicworks.net/aws-continuous-compliance
• AWS Compliance: https://aws.amazon.com/compliance/
• AWS Risk and Compliance Whitepaper: https://d0.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf
• Frequently Asked Questions About Compliance in the AWS Cloud: https://aws.amazon.com/blogs/security/frequently-asked-questions-about-compliance-in-the-aws-cloud/
• AWS Services in Scope by Compliance Program: https://aws.amazon.com/compliance/services-in-scope/
• AWS Security Whitepaper: https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

HIPAA-specific documentation:

• Architecting for HIPAA Security and Compliance on AWS: https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf
• Frequently Asked Questions About HIPAA Compliance in the AWS Cloud: https://aws.amazon.com/blogs/security/frequently-asked-questions-about-hipaa-compliance-in-the-aws-cloud/
• How to Automate HIPAA Compliance (Part 1): Use the Cloud to Protect the Cloud: https://aws.amazon.com/blogs/security/how-to-automate-hipaa-compliance-part-1-use-the-cloud-to-protect-the-cloud/

The post How to Achieve HIPAA Compliance on AWS appeared first on Gathering Clouds.

(c)iStock.com/jackaldu

Healthcare companies that are accustomed to complete control over physical systems often struggle to understand their responsibilities in a cloud environment. Who is responsible for which aspects of compliance? Can healthcare companies trust Amazon with their mission-critical apps and sensitive data? What are the rules and boundaries for AWS compliance?

Mastering these intricacies can help you create compliance-ready systems on AWS. In this article, we will cover the basics, but for a deeper dive, download our eBook on Compliance on AWS.

Shared compliance responsibility on AWS (the short version)

By migrating to AWS, you have a shared compliance responsibility. This shared model means that AWS manages the infrastructure components from the host operating system (virtualisation layer) down to the physical security of AWS’ data centres. It is the customer’s responsibility to configure and secure AWS-provided services. In other words, AWS controls physical components; the customer owns and controls everything else. As AWS states repeatedly, “AWS manages security of the cloud, security in the cloud is the customer’s responsibility.”

Bottom line: Think of operating a compliant environment in AWS as similar to operating in a rented data centre. The data centre is responsible for controlling access to the data centre, locking the cages, and the physical security of the network — but you are responsible for everything else.

The AWS Shared Responsibility Model. Includes tasks performed by Logicworks. If you are managing your own environment, the tasks in blue would be your responsibility.

The same line of demarcation applies to IT controls. Customers in AWS shift the management of some IT controls to AWS, which results in a shared control environment. AWS manages controls associated with the physical and architectural infrastructure deployed in the AWS environment; the customer is responsible for network controls (Security Group configurations), access controls, encryption, and any control not directly managed by AWS.

For example, AWS provides the Identity and Access Management (IAM) tool and is responsible the IT controls in place that govern access to the physical infrastructure that holds your access policies, and customers are responsible for the setting up and maintaining roles and users in IAM. Inappropriate or unauthorised usage of an AWS resource as a result of inadequate IAM controls is the customer responsibility.  

Physical security and environmental controls

Any customer can access a copy of AWS’ SOC 1 Type II report, which provides significant detail about physical security and environment controls. The report can be accessed through AWS Artifact, a repository of audit artifacts. This means that if an auditor requests specifics regarding the physical controls of a customer’s system, they can reference the AWS SOC 1 Type II report. AWS does not allow data centre tours, as independent reviews of data centre security are also part of the SOC, ISO 27001, and other audits.

Data privacy

AWS customers retain control and ownership of their data, and customers can move data on and off of AWS storage as required. AWS does not leverage any third-party providers to deliver services to customers and therefore does not provide any customer information or access to data to any other provider. Customers must control access to applications and data through the AWS Identity and Access Management service.

Client environments on AWS infrastructure are by default logically segregated from each other and have been designed to prevent customers from accessing instances not assigned to them. AWS has both instances that are dedicated to a single customer (Dedicated Instances) and instances hosted on shared infrastructure. AWS is responsible for patching the hypervisor and networking services, while customers patch their own guest operating systems, software, and applications.

Backups

AWS provides services to help customers perform their own backups. Amazon S3 and Glacier are the most popular options, and AWS provides data durability and redundancy guarantees. In this way, AWS provides services to enable disaster recovery and resiliency but does not automatically provide backups.

HIPAA in AWS

New AWS customers often ask: Is AWS compliant with HIPAA? The answer to this question is complex. The short answer is that AWS is not “HIPAA compliant”, but it provides services that facilitate HIPAA compliance.

The U.S. Health Insurance Portability and Accountability Act (HIPAA) Privacy and Security Rules for protecting Protected Health Information (PHI) does not provide a certification or Attestation of Compliance to cloud providers or to healthcare companies. HIPAA is a set of federal regulations, not a security standard. A company and its business associates can be periodically audited for compliance with HIPAA regulations by the HHS Office for Civil Rights (OCR), and in the course of that audit it can meet or fail to meet those requirements, but it cannot be “Certified HIPAA Compliant”.

In order to process, store, or transmit PHI in AWS, a healthcare company (the “covered entity”) must sign a Business Associate Agreement (BAA) with AWS, meaning that AWS is performing function or activities on behalf of the covered entity.

However, signing a BAA with AWS does not mean that the customer is “HIPAA compliant”. The customer can maintain compliance with HIPAA regulations through its own efforts to use cloud tools, architect applications, control access, etc. in a manner that complies with those regulations. AWS only assumes responsibility for physical hardware security controls of a limited number of covered services.

Covered services

For each compliance standard, there is a subset of AWS services/programs that are “in scope” of either the Attestation of Compliance, report, or contract. This means that these services have been audited by a third party for that specific compliance standard.

Customers may use any AWS service in an account designated as a HIPAA account, but they should only process, store and transmit PHI in the HIPAA-eligible services defined in the BAA. There are nine HIPAA-eligible services today, including:

• Amazon DynamoDB
• Amazon EBS
• Amazon EC2
• Amazon Elastic MapReduce (EMR)
• Amazon Elastic Load Balancer (ELB)
• Amazon Glacier
• Amazon Relational Database Service (RDS) [MySQL and Oracle engines]
• Amazon Redshift
• Amazon S3

Again, this does not preclude customers from using services that are not in scope. For example, AWS CloudFormation, an infrastructure as code service that we discuss in-depth in our eBook, is not included in the list of services in scope for a HIPAA BAA. But as long as no PHI is stored, processed or transmitted in AWS CloudFormation, a covered entity may use it. AWS CloudFormation is a templating service that can build out the core components of AWS architecture (networks, instances, etc) and therefore rarely if ever touches customer data in any use case, even in non-HIPAA regulated environments. Similarly, customers can use a service like AWS CloudWatch Logs, a logging service, if logs are scrubbed of customer information.

Compliance responsibility: Insource vs. outsource

Compliance management is a complex set of tasks with many interrelated components. By outsourcing to AWS, you are already removing some of the risk and cost of compliance, particularly as it relates to physical infrastructure security. Outsourcing infrastructure management to a third party Managed Services Provider further reduces your compliance burden.

Most companies that have compliance obligations and are new to AWS choose to work with a partner to plan, build, deploy, and operate their AWS environment in order to minimise risk, rapidly build out a compliance-ready environment, and minimise the time and effort of ongoing compliance maintenance.

Below is an example of a compliance responsibility matrix when you work with Logicworks:

Resources

AWS has published extensively on the topic of shared compliance responsibility. If you are considering hosting regulated data in AWS, we highly recommend that you utilise these resources:

General compliance information:

• Continuous Compliance on AWS: http://go.logicworks.net/aws-continuous-compliance
• AWS Compliance: https://aws.amazon.com/compliance/
• AWS Risk and Compliance Whitepaper: https://d0.awsstatic.com/whitepapers/compliance/AWS_Risk_and_Compliance_Whitepaper.pdf
• Frequently Asked Questions About Compliance in the AWS Cloud: https://aws.amazon.com/blogs/security/frequently-asked-questions-about-compliance-in-the-aws-cloud/
• AWS Services in Scope by Compliance Program: https://aws.amazon.com/compliance/services-in-scope/
• AWS Security Whitepaper: https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf

HIPAA-specific documentation:

• Architecting for HIPAA Security and Compliance on AWS: https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf
• Frequently Asked Questions About HIPAA Compliance in the AWS Cloud: https://aws.amazon.com/blogs/security/frequently-asked-questions-about-hipaa-compliance-in-the-aws-cloud/
• How to Automate HIPAA Compliance (Part 1): Use the Cloud to Protect the Cloud: https://aws.amazon.com/blogs/security/how-to-automate-hipaa-compliance-part-1-use-the-cloud-to-protect-the-cloud/

The post How to Achieve HIPAA Compliance on AWS appeared first on Gathering Clouds.

Chat apps characteristics make them very appealing to businesses and marketers. Prominent ones include their size, user retention, usage rates, and user demographics. In fact, the combined user base of the top four chat apps is larger than that of the top four social networks. Chat apps also have higher retention and usage rates than most mobile apps. Finally, the majority of their users are young, an extremely important demographic for brands, advertisers and publishers.

read more

Serverless is considered the successor to containers. And while it’s heavily promoted as the next great thing, it’s not the best fit for every use case. Understanding the pitfalls and disadvantages of serverless will make it much easier to identify use cases that are a good fit. This post offers some technology perspectives on the maturity of serverless today.
First, note how we use the word serverless here. Serverless is a combination of “Function as a Service” (FaaS) and “Platform as a Service” (PaaS). Namely, those categories of cloud services where you don’t know what the servers look like. For example, RDS or Beanstalk are “servers managed by AWS,” where you still see the context of server(s). DynamoDB and S3 are just some kind of NoSQL and storage solution with an API, where you do not see the servers. Not seeing the servers means there’s no provisioning, hardening or maintenance involved, hence they are server “less.” A serverless platform works with “events.” Examples of events are the action behind a button on a website, backend processing of a mobile app, or the moment a picture is being uploaded to the cloud and the storage service triggers the function.

read more

(c)iStock.com/RonBailey

Microsoft has announced the launch of the Azure IP Advantage program to help protect intellectual property from ‘patent trolls’ in the cloud.

Patent trolls, defined by the Electronic Frontier Foundation (EFF) as companies or people who ‘use patents as legal weapons, instead of actually creating any new products or coming up with new ideas’, are becoming an increasing problem with code and products hosted on cloud servers.

As a result, Microsoft is making 10,000 of its patents available to customers who use Azure services as something of a protection racket; the patents are ‘broadly representative of Microsoft’s overall patent portfolio and are the result of years of cutting-edge innovation’, according to the company.

Picture credit: Microsoft

Brad Smith, Microsoft president and chief legal officer, cited in a company blog post a Boston Consulting Group article which argued that there was a 22% rise in US cloud-based IP lawsuits over the past five years.

“Our goal is to help foster a community that values and protects innovation and investments in the cloud,” Smith wrote. “We want software developers to be able to focus on coding, and businesses and enterprises to be able to respond to the changing needs of their customers with agility without worrying about lawsuits.

“It’s a goal that we believe deserves more attention than it has received to date,” Smith added.

This naturally comes at a price, however; Azure customers eligible for patent protection must be spending more than $1,000 per month over the past three months and have not filed a patent infringement lawsuits against another Azure customer for their Azure workloads over the past two years. Only patent litigations after February 8 are part of the package, meaning companies currently fighting lawsuits and who see this as a get out of jail card are out of luck.

“We take seriously our responsibility to make sure the cloud is used for good, and we stand with our customers to protect them against intellectual property risk,” added Smith. “In partnership with our customers, we are committed to creating an ecosystem where developers, entrepreneurs, enterprises and customers can innovate with confidence.”

You can find out more here.

(c)iStock.com/RonBailey

Microsoft has announced the launch of the Azure IP Advantage program to help protect intellectual property from ‘patent trolls’ in the cloud.

Patent trolls, defined by the Electronic Frontier Foundation (EFF) as companies or people who ‘use patents as legal weapons, instead of actually creating any new products or coming up with new ideas’, are becoming an increasing problem with code and products hosted on cloud servers.

As a result, Microsoft is making 10,000 of its patents available to customers who use Azure services as something of a protection racket; the patents are ‘broadly representative of Microsoft’s overall patent portfolio and are the result of years of cutting-edge innovation’, according to the company.

Picture credit: Microsoft

Brad Smith, Microsoft president and chief legal officer, cited in a company blog post a Boston Consulting Group article which argued that there was a 22% rise in US cloud-based IP lawsuits over the past five years.

“Our goal is to help foster a community that values and protects innovation and investments in the cloud,” Smith wrote. “We want software developers to be able to focus on coding, and businesses and enterprises to be able to respond to the changing needs of their customers with agility without worrying about lawsuits.

“It’s a goal that we believe deserves more attention than it has received to date,” Smith added.

This naturally comes at a price, however; Azure customers eligible for patent protection must be spending more than $1,000 per month over the past three months and have not filed a patent infringement lawsuits against another Azure customer for their Azure workloads over the past two years. Only patent litigations after February 8 are part of the package, meaning companies currently fighting lawsuits and who see this as a get out of jail card are out of luck.

“We take seriously our responsibility to make sure the cloud is used for good, and we stand with our customers to protect them against intellectual property risk,” added Smith. “In partnership with our customers, we are committed to creating an ecosystem where developers, entrepreneurs, enterprises and customers can innovate with confidence.”

You can find out more here.

With major technology companies and startups seriously embracing Cloud strategies, now is the perfect time to attend @CloudExpo | @ThingsExpo, June 6-8, 2017, at the Javits Center in New York City, NY and October 31 – November 2, 2017, Santa Clara Convention Center, CA. Learn what is going on, contribute to the discussions, and ensure that your enterprise is on the right path to Digital Transformation.

read more