Cloud Computing in Healthcare

NCCoE Releases Final Version of NIST Securing Telehealth Remote Patient Monitoring Ecosystem Guidance

Posted by HIPAA Journal

The National Cybersecurity Center of Excellence (NCCoE) has published the final version of NIST guidance on Securing Telehealth Remote Patient Monitoring Ecosystem (SP 1800-30).

Healthcare delivery organizations have been increasingly adopting telehealth and remote patient monitoring (RPM) systems to improve the care they provide to patients while reducing costs. Patient monitoring systems have traditionally only been used in healthcare facilities but there are advantages to using these solutions in patients’ homes. Many patients prefer to receive care at home, the cost of receiving that care is reduced, and healthcare delivery organizations benefit from freeing up bed space and being able to treat more patients.

While there are advantages to be gained from the provision of virtual care and the remote monitoring of patients in their homes, telehealth and RPM systems can introduce vulnerabilities that could put sensitive patient data at risk and if RPM systems are not adequately protected, they could be vulnerable to cyberattacks that could disrupt patient monitoring services.

Special Publication 1800-30 was developed by NCCoE in collaboration with healthcare, technology, and telehealth partners to form a reference architecture that demonstrates how a standard-based approach can be adopted along with commercially available cybersecurity tools to improve privacy and security for the telehealth and RCM ecosystem.

The project team at NCCoE performed a risk assessment based on the NIST Risk Management Framework on a representative RPM ecosystem in a laboratory environment. The NIST Cybersecurity Framework was applied along with guidance based on medical device standards, and the team demonstrated how healthcare delivery organizations can implement a solution to enhance privacy and better secure their telehealth RPM ecosystem.

SP 1800-30 explains how healthcare delivery organizations can identify cybersecurity risks associated with telehealth and RPM solutions, use the NIST Privacy Framework to broaden their understanding of privacy risks, and apply cybersecurity and privacy controls. How-To guides are provided that include detailed instructions for installing and configuring the products used to build NCCoE’s example solution. NCCoE used solutions from AccuHealth and Vivify, but the principles can be applied to other solutions.

The final guidance and How-To guides can be downloaded from NCCoE here.

Image Source: J. Stoughton/NIST

The post NCCoE Releases Final Version of NIST Securing Telehealth Remote Patient Monitoring Ecosystem Guidance appeared first on HIPAA Journal.

SalusCare Takes Legal Action Against Amazon to Obtain AWS Audit Logs to Investigate Data Breach

Posted by HIPAA Journal

SalusCare, a provider of behavioral healthcare services in Southwest Florida, experienced a cyberattack in March that saw patient and employee data exfiltrated from its systems. The exact method used to gain access to its servers has not been confirmed, although the cyberattack is believed to have started with a phishing email that was used to deliver malware. The malware was used to exfiltrated its entire database to an Amazon AWS storage account.

The attack occurred on March 16, 2021 and the investigation into the breach established that the attacker, an individual who appeared to be based in Ukraine, gained access to its Microsoft 365 environment, downloaded sensitive data, and uploaded the stolen data to two Amazon S3 storage buckets.

Amazon was notified about the illegal activity and it suspended access to the S3 buckets to stop the attacker accessing the stolen data.  SalusCare requested access to the audit logs, which it requires to continue to investigate the breach and determine exactly what data was stolen. SalusCare also wants to make sure that the suspension is permanent and will not be lifted by Amazon.

The S3 buckets may have been used to store SalusCare data, but Amazon will not voluntarily provide copies of audit logs or a copy of the data stored in the S3 buckets as they do not belong to SalusCare. The two S3 buckets are understood to include almost 86,000 files that were stolen in the attack.

To get access to the audit logs and data, SalusCare filed a lawsuit in federal court seeking injunctive relief under Florida’s Computer Abuse and Recovery Act. SalusCare seeks a ruling that will compel Amazon to provide the audit logs and a copy of the content of the two S3 buckets. SalusCare also wants the courts to order Amazon to make the suspension of access permanent to prevent the attacker from accessing the data or copying the stolen information to another online storage service. SalusCare has also sued the individual behind the attacks – John Doe.

The lawsuit argued that the data stolen in the attack and hosted by Amazon is extremely sensitive and could be used to commit identity theft, could be sold by the hacker on darknet marketplaces, or leaked to the public.

“The files contain extremely personal and sensitive records of patients’ psychiatric and addiction counseling and treatment,” explained SalusCare in its petition to the U.S. District Court in Fort Myers. “The files also contain sensitive financial information such as social security numbers and credit card numbers of SalusCare patients and employees.”

The lawsuit requests that after Amazon provides a copy of the data and audit logs to SalusCare the S3 buckets should be purged to prevent any further unauthorized access.

Amazon did not oppose any injunctive relief sought by SalusCare and The News-Press reports that a District Court federal judge granted the requests on March 25, 2021.

The post SalusCare Takes Legal Action Against Amazon to Obtain AWS Audit Logs to Investigate Data Breach appeared first on HIPAA Journal.

NSA Warns of Authentication Mechanism Abuse to Gain Access to Cloud Resources

Posted by HIPAA Journal

The U.S. National Security Agency (NSA) has issued an alert that warns about two hacking techniques that are currently being used by threat groups to gain access to cloud resources containing protected data. These techniques abuse authentication mechanisms and allow attackers to steal credentials and maintain persistent access to networks.

These techniques have been used by the threat actors who compromised SolarWinds Orion platform. The hackers behind the attacks have yet to be identified, but some evidence has emerged that suggest this is a nation state attack by a Russian threat group, possibly APT29 (Cozy Bear). Secretary of State Mike Pompeo said in a radio interview on Friday that “now we can say pretty clearly that it was the Russians that engaged in this activity,” although on Saturday President Trump downplayed the attack and suggested there is a possibility China is responsible, although President Trump is largely alone in having that viewpoint.

The SolarWinds Orion platform supply chain attack was used to push malware out to customers through the SolarWinds software update mechanism, but that is one of several methods currently being used to compromise public and private sector organizations and government agencies.

“Initial access can be established through a number of means, including known and unknown vulnerabilities,” explained the NSA in its alert. “The recent SolarWinds Orion code compromise is one serious example of how on-premises systems can be compromised, leading to abuse of federated authentication and malicious cloud access.”

Once initial access had been gained, through the SolarWinds compromise for example, the techniques described in the alert are used to gain additional privileges through the forging of credentials to maintain persistent access. The NSA has provided guidance on how to detect attacks and mitigate against them, regardless of how the initial access is gained. The NSA notes that these tactics are not new and have been used by threat actors since at least 2017 and continue to be effective.

The techniques described in the alert involve the use of compromised authentication tokens and abuse of compromised system administration accounts in Microsoft Azure and other cloud platforms once a local network has been compromised.

The first technique involves compromising an on-premises federated identity provider or single sign-on (SSO) system. These systems allow organizations to use the authentication system they already own to grant access to resources, including cloud services. These systems use cryptographically signed automated messages – assertions – which are shared via Security Assertion Markup Language (SAML) to show that users have been authenticated. Threat actors are abusing the authentication mechanism to gain illicit access to a wide range of assets owned by organizations.

The attackers either steal credentials or private keys from the SSO system that allow them to sign assertions and impersonate a legitimate user and gain sufficient privileges to create their own keys and identities, as well as their own SSO system. The second approach involves compromising admin accounts to assign credentials to cloud application services, after which the attackers call for the application’s credentials to gain automated access to cloud resources.

The NSA has warned that threat actors are continuing to exploit the recently disclosed command injection vulnerability in VMware products (CVE-2020-4006). In one case cited by the NSA exploitation of this vulnerability allowed initial local network access to be gained, rather than the SolarWinds method. The techniques described in the alert were then used to gain access to cloud resources. A patch has been released to correct the flaw affecting VMware products. The patch should be applied as soon as possible. Users of SolarWinds Orion should follow the previously published mitigations.

These attack methods to gain access to cloud resources do not exploit vulnerabilities in cloud infrastructure, federated identity management, the SAML protocol, or on-premises and cloud identity services, instead they abuse trust in the federated identity system.

“The security of identity federation in any cloud environment directly depends on trust in the on-premises components that perform authentication, assign privileges, and sign SAML tokens. If any of these components is compromised, then the trust in the federated identity system can be abused for unauthorized access,” said the NSA.

To prevent the new techniques from being successfully used to gain access to cloud resources, the NSA recommends the following:

  • Lock down SSO configuration and service principle usage
  • Harden systems running on-premises identity and federation services
  • Monitor logs for suspicious tokens that do not match the organization’s baseline for SAML tokens.
  • Audit tokens to detect anomalies
  • Examine logs for suspicious use of service principles
  • Look for unexpected trust relationships that have been added to Azure Active Directory

The post NSA Warns of Authentication Mechanism Abuse to Gain Access to Cloud Resources appeared first on HIPAA Journal.

CloudHealth Launches New Tools to Operationalize AWS Savings Plans Management

Posted by HIPAA Journal

CloudHealth has announced a significant expansion of its AWS Savings Plan capabilities with the general release of several new tools that help drive better business outcomes through the entire lifecycle of Savings Plans management.

AWS launched Savings Plans in late 2019 to give businesses an alternative to Reserved Instances to save money on their AWS spending. CloudHealth incorporated Savings Plans into its cloud cost optimization and governance platform, initially providing customers with Cost History Reports to provide information on costs as they are incurred or over the life of the Savings Plan. Usage Reports gave customers insights into where Savings Plans had been applied to show how much compute usage was covered by the Savings Plan discounts.

Convertible Reservation Exchanger was introduced to allow businesses to get the most out of their existing Reserved Instances before taking advantage of Savings Plans, and the company established a Strategic Savings Desk staffed by AWS experts to help customers with Savings Plans and discount management.

Now new tools have been released to help companies determine which of the six Compute Savings Plan purchase options is best option for their business, along with the different trade offs with each of the 6 options. Those trade-offs can be quickly and easily compared on a single screen.

It is now possible to set specific KPIs for savings, spend, or coverage, and view which of the recommendations best meets those requirements, and analyses can be exported into a CSV output for further evaluation.

After comparing the various options, Savings Plans can now be purchased directly through the CloudHealth platform, without having to go to AWS.

Cost, usage and performance data can be presented in various groupings to show the units, teams, and projects that have received the benefit of the Savings Plan and the impact of Savings Plan discounts on KPIs can be easily evaluated. The new tools make it much easier to plan and forecast future purchases of Savings Plans.

Data can also be easily shared with relevant stakeholders, with customizable reports generated for each individual stakeholder showing the data they need. The reports show how Savings Plans have impacted business goals, custom dashboards can be easily built, and it is possible to subscribe to regular updates and receive new reports via email.

The post CloudHealth Launches New Tools to Operationalize AWS Savings Plans Management appeared first on HIPAA Journal.

OCR Publishes New Resources for MHealth App Developers and Cloud Services Providers

Posted by HIPAA Journal

The Department of Health and Human Services’ Office for Civil Rights has announced it has published additional resources for mobile health app developers and has updated and renamed its Health App Developer Portal.

The portal – Resources for Mobile Health Apps Developers – provides guidance for mobile health app developers on the HIPAA Privacy, Security, and Breach Notification Rules and how they apply to mobile health apps and application programming interfaces (APIs).

The portal includes a guidance document on Health App Use Scenarios and HIPAA, which explains when mHealth applications must comply with the HIPAA Rules and if an app developer will be classed as a business associate.

“Building privacy and security protections into technology products enhances their value by providing some assurance to users that the information is secure and will be used and disclosed only as approved or expected,” explained OCR. “Such protections are sometimes required by federal and state laws, including the HIPAA Privacy, Security, and Breach Notification Rules.”

The portal provides access to the Mobile Health Apps Interactive Tool developed by the Federal Trade Commission (FTC) in conjunction with the HHS’ Office of the National Coordinator for Health IT (ONC) and the Food and Drug Administration (FDA). The Tool can be used by the developers of health-related apps to determine what federal rules are likely to apply to their apps. By answering questions about the nature of the apps, developers will discover which federal rules apply and will be directed to resources providing more detailed information about each federal regulation.

The portal also includes information on patient access rights under HIPAA, how they apply to the data collected, stored, processed, or transmitted through mobile health apps, and how the HIPAA Rules apply to application programming interfaces (APIs).

The update to the portal comes a few months after the ONC’s final rule that called for health IT developers to establish a secure, standards-based API that providers could use to support patient access to the data stored in their electronic health records. While it is important for patients to be able to have easy access to their health data to allow them to check for errors, make corrections, and share their health data for research purposes, there is concern that sending data to third-party applications, which may not be covered by HIPAA, is a privacy risk.

OCR has previously confirmed that once healthcare providers have shared a patients’ health data with a third-party app, as directed by the patient, the data will no longer be covered by HIPAA if the app developer is not a business associate of the healthcare provider. Healthcare providers will not be liable for any subsequent use or disclosure of any electronic protected health information shared with the app developer.

A FAQ is also available on the portal that explains how HIPAA applies to Health IT and a guidance document explaining how HIPAA applies to cloud computing to help cloud services providers (CSPs) understand their responsibilities under HIPAA.

The post OCR Publishes New Resources for MHealth App Developers and Cloud Services Providers appeared first on HIPAA Journal.

AI Company Exposed 2.5 Million Patient Records Over the Internet

Posted by HIPAA Journal

The personal and health information of more than 2.5 million patients has been exposed online, according to technology and security consultant Jeremiah Fowler.

The records were discovered on July 7, 2020 in two folders that were publicly accessible over the Internet and required no passwords to access data. The folders were labeled as “staging data” and had been hosted by an artificial intelligence company called Cense AI, a company that provides SaaS-based intelligent process automation management solutions. The folders were hosted on the same IP address as the Cense website and could be accessed by removing the port from the IP address, which could be done by anyone with an Internet connection. The data could have been viewed, altered, or downloaded during the time it was accessible.

An analysis of the data suggests it was collected from insurance companies and relate to individuals who had been involved in automobile accidents and had been referred for treatment for neck and spinal injuries. The data was quite detailed and included patient names, addresses, dates of birth, policy numbers, claim numbers, diagnosis notes, payment records, date of accident, and other information. The majority of individuals in the data set appeared to come from New York. In total, there were 2,594,261 records exposed across the two folders.

Fowler identified extremely uncommon names and performed a Google search to verify those individuals were real, checking the name, region and demographic data. Fowler was satisfied that this was a real data set and not dummy data. Fowler made contact with Cense via email and while no response was received, the data was no longer accessible on July 8, 2020.

Fowler suspects that the data had been temporarily loaded into a storage repository prior to being loaded into Cense’s management or AI system. There was no way of determining how long the data had been exposed.

Currently, there is no breach notice on the Cense website and the incident has not appeared on the HHS’ Office for Civil Rights website. Fowler said he only accessed a limited amount of data for verification purposes and did not download any patient information; however, during the time the folders were exposed, it is possible that other individuals may have found and downloaded the data.

Data leaks such as this are all too common. Misconfigurations of cloud resources such as S3 buckets and Elasticsearch instances frequently leave sensitive data exposed. Cybercriminals are constantly searching for exposed data and it does not take long for data to be found. Once study conducted by Comparitech showed that it takes just a few hours for exposed Elasticsearch instances to be found.

Cloud services offer many advantages over on-premises solutions, but it is essential for protections to be put in place to secure any cloud data and for policies and procedures to be implemented to allow misconfigurations to be rapidly identified and corrected.

The post AI Company Exposed 2.5 Million Patient Records Over the Internet appeared first on HIPAA Journal.

Healthcare Data Leaks on GitHub: Credentials, Corporate Data and the PHI of 150,000+ Patients Exposed

Posted by HIPAA Journal

A new report has revealed the personal and protected health information of patients and other sensitive data are being exposed online without the knowledge of covered entities and business associates through public GitHub repositories.

Jelle Ursem, a security researcher from the Netherlands, discovered at least 9 entities in the United States – including HIPAA-covered entities and business associates – have been leaking sensitive data via GitHub. The 9 leaks – which involve between 150,000 and 200,000 patient records – may just be the tip of the iceberg. The search for exposed data was halted to ensure the entities concerned could be contacted and to produce the report to highlight the risks to the healthcare community.

Even if your organization does not use GitHub, that does not necessarily mean that you will not be affected. The actions of a single employee or third-party contracted developer may have opened the door and allowed unauthorized individuals to gain access to sensitive data.

Exposed PII and PHI in Public GitHub Repositories

Jelle Ursem is an ethical security researcher who has previously identified many data leaks on GitHub, including by Fortune 500 firms, publicly traded companies, and government organizations. Ursem decided to conduct a search to find out if any medical data had been leaked on GitHub. It took just 10 minutes to confirm that it had, but it soon became clear that this was far from an isolated case.

Ursem conducted searches such as “companyname password” and “medicaid password FTP” and discovered several hard-coded usernames and passwords could be found in code uploaded to GitHub. Those usernames and passwords allowed him to login to Microsoft Office 365 and Google G Suite accounts and gain access to a wide range of sensitive information such as user data, contracts, agendas, internal documents, team chats, and the protected health information of patients.

“GitHub search is the most dangerous hacking tool out there,” said Ursem. Why go to the trouble of hacking a company when it is leaking data that can be found with a simple search on GitHub?

Ursem attempted to make contact with the companies concerned to alert them to the exposure of their data and ensure the information was secured, but making contact with those organizations and getting the data secured proved problematic, so Ursem contacted databreaches.net for assistance.

Together, Dissent Doe of DataBreaches.net and Ursem worked together to contact the organizations concerned and get the data secured. In some cases, they succeeded – with considerable effort – but even after several months of attempts at contacting the companies concerned, explaining the severity of the situation, and offering help to address the problems that led to the exposure of data, some of that data is still accessible.

9 Leaks Identified but There are Likely to be Others

The report details 9 leaks that affected U.S. entities – namely Xybion, MedPro Billing, Texas Physician House Calls, VirMedica, MaineCare, Waystar, Shields Health Care Group, AccQData – and one unnamed entity: Unnamed because the data is still accessible.

The most common causes of GitHub data leaks were developers who had embedded hard-coded credentials into code that had been uploaded into public GitHub repositories, the use of public repositories instead of private repositories, and developers who had abandoned repositories when they were no longer required, rather than securely deleting them.

For example, Ursem found that a developer at Xybion – a software, services and consulting company with a presence in workplace health issues – had left code in a public GitHub repository in February 2020. The code included hard-coded credentials for a system user that, in connection with other code, allowed Ursem to access billing back-office systems that contained the PHI of 7,000 patients, together with more than 11,000 insurance claims dating back to October 31, 2018.

It was a similar story with MaineCare – a state- and federally-funded program that provides healthcare coverage to Maine residents. In that case, hard-coded credentials gave Ursem administrative access to the entire website, access to the internal server infrastructure of MaineCare / Molina Health, MaineCare SQL data sources, and the PHI of 75,000 individuals.

The Typhoid Mary of Data Leaks

The report highlights one developer, who has worked with a large number of healthcare organizations, whose GitHub practices have led to the exposure of many credentials and the PHI of an estimated 200,000 clients. That individual has been called the “Typhoid Mary of Data Leaks”.

The developer made many mistakes that allowed client data to be exposed, including leaking the credentials of 5 employers on GitHub and leaving repositories fully accessible after work had been completed. In one case, the actions of that developer had allowed access to the central telephone system of a large entity in debt collection, and in another credentials allowed access to highly sensitive records for people with a history of substance abuse.

While it was not possible to contact that individual directly, it appears that the work of DataBreaches.net and Ursem has gotten the message through to the developer. The repositories have now been removed or made private, but not before the data was cloned by at least one third party.

This was just one example of several outsourced or contracted developers who were being used by HIPAA-covered entities and business associates, whose practices exposed data unbeknownst to the CEs and BAs.

“No matter how big or small you are, there’s a real chance that one of your employees has thrown the front door key under the doormat and has forgotten that the doormat is transparent,” explained Dissent Doe of DataBreaches.net. Regardless of whether your organization uses GitHub, HIPAA Journal believes the report to be essential reading.

The collaborative report from Jelle Ursem and DataBreaches.net explains how the leaks occurred, why they have gone undetected for so long, and details several recommendations on how data breaches on GitHub can be prevented – and detected and addressed quickly in the event that mistakes are made. You can download the full PDF report on this link.

Many thanks to Dissent Doe for notifying HIPAA Journal, to Jelle Ursem for discovering the data leaks, and for the hard work of both parties investigating the leaks, contacting the entities concerned, and highlighting the problem to help HIPAA-covered entities and their business associates take steps to prevent GitHub data breaches moving forward.

The post Healthcare Data Leaks on GitHub: Credentials, Corporate Data and the PHI of 150,000+ Patients Exposed appeared first on HIPAA Journal.

70% of Companies Have Suffered a Public Cloud Data Breach in the Past Year

Posted by HIPAA Journal

A recent study conducted by Sophos has revealed 96% of companies are concerned about the state of their public cloud security. There appears to be a valid cause for that concern, as 70% of companies that host data or workloads in the cloud have experienced a breach of their public cloud environment in the past year. The most common attack types were malware (34%), followed by exposed data (29%), ransomware (28%), account compromises (25%), and cryptojacking (17%).

Data for the study came from a survey conducted by Vanson Bourne on 3,521 IT managers in 26 countries including the United States, Canada, France, Germany, India, and the United Kingdom. More than 10 industry sectors were represented.  Respondents used one or more public clouds from Azure, Oracle Cloud, AWS, VMWare Cloud on AWS, Alibaba Cloud, Google Cloud and IBM Cloud. The findings of the survey were published in the Sophos report: The State of Cloud Security 2020.

The biggest areas of concern are data loss, detection and response and multi-cloud management. Companies that use two or more public cloud providers experienced more security incidents than companies with just one cloud service provider. Up to twice as many breaches were experienced by companies using multiple clouds compared to those just using one public cloud provider.

India was the worst affected country with 93% of organizations experiencing a cloud security breach, with Italy the least affected with 45% of organizations experiencing a breach. 68% of organizations in the United States reported experiencing a public cloud data breach in the past 12 months. Sophos suggests the relatively low number of cloud security incidents in the United States is due to US organizations having a much better understanding about where the responsibilities for security lie. 90% of respondents from organizations in the United States understood that while the cloud service provider ensures the platform is secure, security is also the responsibility of each cloud customer. “Cloud security is a shared responsibility and organisations need to carefully manage and monitor cloud environments in order to stay one step ahead of determined attackers,” explained Sophos’ principal research scientist Chester Wisniewski. Organizations in the United States also have greater visibility into their public cloud environment. 85% of respondents from organizations in the US said they were fully aware of all of their cloud assets, which is 17% more than the global average.

The most common cause of public cloud security breaches were system misconfigurations and flaws in firewall applications, which were exploited in 66% of public cloud security incidents and allowed cybercriminals to gain access to sensitive data over the internet. 44% of attacks involved misconfigured web application firewalls and 22% were due to cloud resource misconfigurations. 33% of attacks involved the theft of account credentials. In the United States, 75% of successful breaches were due to misconfigurations and 23% involved the use of stolen credentials.

As companies introduce more cloud services and increase the number of clouds they use, complexity increases, the attack surface grows, and there is greater potential for misconfigurations. It is therefore important for organizations to have the right tools to provide full visibility into their cloud environments and to have staff with expertise in cloud security. Despite the high number of public cloud data breaches, only one in four organizations was concerned about a lack of staff expertise, suggesting many organizations undervalue the skills required to create a good cloud security posture.

Organizations need to continuously monitor their cloud resource configurations to identify misconfigured cloud services. A recent study conducted by Comparitech showed cybercriminals are conducting automatic scans to identify misconfigured cloud services and unsecured resources are rapidly found and attacked. In the Comparitech study, which used an exposed Elasticsearch honeypot, the first attempt to access data came within 9 hours of the resource being created.

Organizations also need to proactively manage cloud access. The Sophos survey revealed 91% of respondents had over-privileged identity and access management roles. By ensuring users only have access to the cloud resources they need, harm can be minimized in the event of a breach.

The increase in remote working due to COVID-19 has also presented new opportunities for cybercriminals. Remote workers should be provided with VPNs to ensure they can access cloud resources securely and access attempts should be monitored.  It is also important to set up multi-factor authentication. Even though multi-factor can prevent data breaches, 98% of respondents had disabled MFA on their cloud provider accounts.

The post 70% of Companies Have Suffered a Public Cloud Data Breach in the Past Year appeared first on HIPAA Journal.

Webinar Today: A Practitioner’s Guide to Cloud Security and Compliance Processes

Posted by HIPAA Journal

Many organizations find it difficult to keep their cloud environments secure and compliant with data protection standards as cloud usage grows. While they had effective security processes for their on-premises infrastructure, they do not always translate to the cloud and fail to mitigate risks associated with decentralized cloud usage.

Ensuring security processes are in place that are effective at identifying cloud misconfigurations that could be exploited by threat actors to gain access to cloud data is essential, but if those processes are not implemented, security becomes an impossible task.

One of the problems is that while standalone configurations may be correct, they can combine with other configurations which can potentially allow unauthorized access to sensitive data. These complex violation chains can be difficult to identify and are a common cause of cloud security breaches. Creating security policies to address risks can cause problems, as security policies can easily have an impact on productivity.

The creation of effective security policies that do not negatively affect the organization is a challenge, but one that can be easily overcome by adopting the right strategies.

The Cloud Security Alliance is running a webinar on Tuesday July 7, 2020 to help organizations scale their cloud usage while also improving their security posture. The CSA will be highlighting proven strategies that also empower teams to take full advantage of the agility benefits of the cloud.

The webinar will cover some of the most common security vulnerabilities and threats that increase security and compliance risks, how it is possible to ensure governance while maintaining the flexibility required for developer productivity, explain key steps that can be taken to improve your security posture, and cover lessons that have been learned from scaling these processes to support a growing cloud environment

The Cloud Security Alliance will be joined by Kolby Allen, Senior Architect at Zipwhip, and Jason Needham, Senior Director of Cloud Security at VMware.

Webinar Details

A Practitioner’s Guide to Cloud Security and Compliance Processes

Tuesday July 7, 2020

10 am PT / 1 pm ET

Click here to register for the webinar

The post Webinar Today: A Practitioner’s Guide to Cloud Security and Compliance Processes appeared first on HIPAA Journal.