Majority of Australian Data Breaches Caused by Human Error

By Rich Campagna, Chief Marketing Officer, Bitglass

world mapIt wasn’t long ago that the first breach under the Office of the Australian Information Commissioner’s (OAIC) Privacy Amendment Bill was made public. Now, OAIC is back with their first Quarterly Statistics Report of Notifiable Data Breaches. While the report doesn’t offer much in the way of detail, it does highlight a couple of interesting trends.

The statistic that jumps out most is that of the 63 reported breaches in this first (partial) quarter, the majority (51%) were the result of “human error.” According to OAIC, “human error may include inadvertent disclosures, such as by sending a document containing personal information to the incorrect recipient.” Sounds like too few Australian organizations are controlling things like external sharing, even though sharing (and many other potentially risky activities) can be controlled quite easily with a Cloud Access Security Broker (CASB).

human error leading cause of breaches

The report also breaks down number of breaches by industry. Health service provides had the misfortune of leading the charge in this initial quarter, representing nearly a quarter of breaches. Healthcare organizations have a particularly difficult task with data protection. On one hand, they have a very mobile workforce that requires immediate access to data, from anywhere and from any device. On the other hand, medical records are some of the most valuable sources of personal data, including not only medical history, but personal information, financial information, and more.

healthcare most breaches

Fortunately, this first quarter didn’t include any large, “mega-breaches,” as more than half involved the personal information of fewer than 10 individuals, and 73% involving fewer than 100 individuals.

most breaches small

It will be interesting to see whether schemes like this, and the upcoming GDPR, have an impact on overall data protection outcomes.

Bitglass Security Spotlight: LinkedIn, Vector, and AWS

By Jacob Serpa, Product Marketing Manager, Bitglass

man reading cybersecurity headlines while eating breakfastHere are the top cybersecurity stories of recent weeks:

—LinkedIn security gap exposes users’ data
—Vector app reveals customers’ information
—AWS misconfiguration makes LocalBlox user information public
—New malware steals data via power lines
—Banking apps deemed the most unsecured

LinkedIn security gap exposes users’ data
LinkedIn’s AutoFill functionality was recently discovered to be easily exploitable. The feature allows users to have fields on other websites automatically populated with information from their LinkedIn accounts (for rapid registrations and logins, for example). Researchers quickly realized that this could be exploited by malicious websites that initiate AutoFill, regardless of where visitors click, in order to steal information.

Vector app reveals customers’ information
New Zealand energy company, Vector, developed an application designed to update users on the status of their power; for example, by providing estimates on when power might return during outages. Unfortunately, the app didn’t provide the functionality that the company originally intended. Additionally, it made all of its users’ information (including home address) accessible to anyone who downloaded the app.

AWS misconfiguration makes LocalBlox user information public
Another AWS misconfiguration has exposed the personal information of various individuals – 48 million of them. LocalBlox, which gathers information from public online profiles, was recently found to be leaking Twitter, Facebook, and LinkedIn information through an unsecured AWS S3 bucket. Leaked information included email addresses, job histories, and even IP addresses in some cases.

New malware steals data via powerlines
PowerHammer, a new type of malware, can steal data in a variety of complex, frightening ways. For example, through computers’ power cables. To learn more about the ins and outs of PowerHammer, click here.

Banking apps deemed the most unsecured
A recent study found that banking applications are typically the most vulnerable type of cloud app. Despite the fact that these services are used by hundreds of millions of people, they consistently hold security flaws that leave them open to the advances of hackers.

Learn more about cloud access security brokers (CASBs) and how they can help you secure data in our cloud-first world with the Definitive Guide to CASBs.

Orbitz: Why You Can’t Secure Data in the Dark

By Jacob Serpa, Product Marketing Manager, Bitglass

plug into the cloudOn March 1, 2018, Orbitz discovered that a malicious party may have stolen information from one of its legacy platforms. The compromised platform housed Orbitz customer information such as mailing addresses, phone numbers, email addresses, and full names, as well as details about nearly 900,000 payment cards.

This data breach highlights the struggle that many companies face on a day-to-day basis.

Stated simply, organizations cannot afford to secure their data in the dark. Lacking comprehensive visibility makes it nearly impossible to protect sensitive information – you cannot defend against threats that you can’t see. Where enterprises fail to maintain automatic, thorough logging of all events involving corporate data, breaches are sure to follow.

The fact that Orbitz was unable to confirm whether a hacker had stolen information is evidence that it lacked adequate visibility. If the company had tools that provided said visibility, then identifying a data breach would have been fairly simple. Additionally, with real-time capabilities, the company could have identified the potential breach the moment that it occurred (somewhere between October and December of 2017), rather than months after the fact.

The speed at which hackers, malware, and malicious insiders can exfiltrate data demands real-time security and comprehensive visibility. Incomplete, reactive security tools are incapable of providing protection in today’s rapid, cloud-first world. Only a cloud access security brokers (CASB) can provide what the modern enterprise needs.

One Simple Way to Avoid 57 Percent of Breaches

By Rich Campagna, Chief Marketing Officer, Bitglass

patched jeans representing unpatched known vulnerabilitiesI recently caught wind of a survey of 3000 cybersecurity professionals commissioned by ServiceNow and Ponemon. One of the first statistics that jumped out at me?

“57% of data breach victims said they were breached due to an unpatched known vulnerability.”

That’s bananas!

And this massive number of data breaches due to lack of vulnerability patching comes despite respondent companies spending 321 hours per week – or approximately 8 full time employees vulnerability response process.

So, an average of eight people chasing a manual process, and they’re always behind, resulting in the majority of data breaches coming as the result of KNOWN vulnerabilities for which THERE IS A FIX?

What’s the average enterprise to do?

Move to the cloud!

With cloud apps, you’re not only outsourcing the application itself, you’re outsourcing many of the mundane, manual tasks like patching, that your organization never quite keeps up on. Microsoft spends more than $1 billion per year on security. Do you think you’d get patching under control if you had that kind of coin dedicated to security? Of course you would.

The fact remains that the major cloud vendors are doing a pretty good job of protecting their apps and their infrastructure against widespread, service impacting security events (such as unpatched vulnerabilities being exploited).

The enterprise cloud security and compliance challenge is not to take an inherently insecure app and make it secure. Rather, it’s to secure the usage of those cloud applications. That’s where Cloud Access Security Brokers come into play.

The Case for CASB: Healthcare

By Rich Campagna, Chief Marketing Officer, Bitglass

doctor and patient looking at healthcare record on tabletOver the past couple of years, Cloud Access Security Brokers (CASBs) have gone from a nascent, barely known technology to the de facto standard for secure public cloud enablement in every enterprise vertical. Early on, it’s tough to draw patterns across industries, but once you have a few hundred enterprise deployments under your belt, it becomes quite interesting to observe how organizations in one industry use the same technology (CASBs) in an entirely different way than organizations in another industry.

With that in mind, I’m creating a series of blog posts to cover some of the key differences in CASB usage that we see across industries. First up? Healthcare.

Like most industries, healthcare organizations are adopting cloud applications at a very rapid clip. Most start with major SaaS applications (like Office 365), but once they get a handling on security and compliance, start expanding their cloud footprint, with even applications like Electronic Medical Record (EMR) systems moving to the cloud. Across this massive change, the organization must still comply with HIPAA – no small feat.

So what are the big security and compliance drivers that lead healthcare organizations to adopt a CASB?

  • Protecting PHI and Complying with HIPAA
    This one is quite obvious, but this post wouldn’t be complete without mentioning it. Protected Health Information (PHI) makes its way to cloud applications, and not just EMR and other clinical systems designed to store PHI. Email and files, via productivity suites like Office 365, typically contain PHI as well. The organization’s cloud footprint must have mechanisms in place to identify PHI, to eliminate access by unauthorized individuals, and to control the flow of PHI out of cloud applications. Healthcare organizations use either keyword and regular expression-based DLP policies, or increasingly, exact data match capabilities where electronic health record (EHR) data is exported from an application like Epic, tokenized, and uploaded to a CASB DLP engine to provide matching on patient data with much less risk of false positives.
  • Protecting Data That Leaves the Cloud
    Healthcare organizations have gotten comfortable with the fact that major cloud vendors are investing heavily in security, and doing a pretty good job of protecting data-at-rest, so their primary objective is to protect data once it leaves the cloud, via mechanisms such as BYOD and external sharing.
    Note that this is in contrast to other industries, like financial services, where a big driver is to keep sensitive data from getting to the cloud.
  • Protecting Data on BYO Devices
    Most healthcare workers are mobile, requiring access from both home and from the bedside, alike. Complicating matters is the fact that clinical staff are not typically employees of the organization. This means that IT’s ability to force management control over personal mobile devices is even more difficult than with employees. It’s impossible if that user’s device is already controlled by another organization’s Enterprise Mobility Management/Mobile Device Management solution.
    Regardless of these challenges, the organization must continue to protect PHI and other sensitive data that is synchronized or downloaded to both managed and unmanaged devices.

In summary, healthcare organizations are adopting cloud applications, and their leading objective is to protect patient data as it leaves the cloud – with the top concerns being BYOD and external sharing.

Australia’s First OAIC Breach Forecasts Grim GDPR Outcome

By Rich Campagna, Chief Marketing Officer, Bitglass

map showing GDPR and OAIC areasThe first breach under the Office of the Australian Information Commissioner’s (OAIC) Privacy Amendment Bill was made public on March 16. While this breach means bad press for the offending party, shipping company Svitzer Australia, more frightening is the grim outcome it forecasts for organizations subject to GDPR regulations, which go into effect on May 25, 2018.

In the Svitzer case, 60,000 emails containing sensitive personal information on more than 400 employees were “auto-forwarded” to external accounts, a not uncommon way for employees to “get access” to their work emails from outside of the office. While the details of why these auto-forwarding rules were set up, and whether the intent was malicious or benign, in many cases, the objective is to avoid IT management of the user’s device while still gaining access to sensitive data.

Another common scheme to bypass unwanted IT controls is to set up sharing of one’s cloud file sharing drive to a personal email account. Both of these challenges are easily solved with Cloud Access Security Brokers (CASBs), which can secure employee devices without taking management control (helping to avoid auto-forwarding outcomes), and control the flow of data into/out-of cloud apps (including external sharing control).

The outcome in this case is bad press for Svitzer, causing loss of goodwill and perhaps some customers. It could have been worse, however. Under the Australian scheme, when OAIC if notified of the breach, which Svitzer has apparently done, the breach is made public but there are no direct financial penalties. If Svitzer hadn’t notified, they would have been subject to fines of “up to $1.8 million.” Penalties initially start with public apologies and compensation payments to the victims, with continued examples of non-notification ratcheting up fines to a maximum of $1.8 million.

What does all of this have to do with GDPR? Simple. With the upcoming GDPR enforcement deadline, some organizations are scrambling to reach compliance, while others are taking a wait-and-see approach. Once we pass the deadline, there WILL be companies with similarly simple issues that have a breach. The difference is in the penalties with GDPR. Rather than starting with simple fixes such as apologies and victim compensation, GDPR comes with severe penalties of up to €20 million or 4% of annual revenue, whichever is greater. Depending on the size and health of the organization, penalties like this could be terminal.

My prediction? We’ll quickly see the first examples, like Svitzer, and before the end of 2018, we’ll see the first bankruptcy as a result of GDPR fines and loss of business.

Zero-Day in the Cloud – Say It Ain’t So

By Steve Armstrong, Regional Sales Director, Bitglass

Zero-day vulnerabilities are computer or software security gaps that are unknown to the public – particularly to parties who would like to close said gaps, like the vendors of vulnerable software.

To many in the infosec community, the term “zero-day” is synonymous with the patching or updating of systems. Take, for example, the world of anti-malware vendors. There are those whose solutions utilize signatures or hashes to defend against threats. Their products ingest a piece of malware, run it through various systems, perhaps have a human analyze the file, and then write a signature. This is then pushed to their subscribers’ end points in order to update systems and defend them against that particular piece of malware. The goal is to get the update to systems before there is an infection (sadly, updates are not always timely). On the other hand, there are some vendors who reject this traditional, reactive method. Instead, they use artificial intelligence to solve the problem in real time.

When assessing threats, it comes down to what you don’t know. It can be difficult to respond to unknown threats until they strike. As they say, it’s not what you know that kills you. This is also true in the SaaS space. The analogy is simple, new applications appear daily – some good, some bad – and even the good ones can have unknown data leakage paths. Treat them as a threat.

In order to respond to unknown cloud applications, you can do one of two things.

First, the standard practice from CASBs (cloud access security brokers) is to find the new application, work to understand the originating organization, analyze the application, identify the data leakage paths, gain an understanding of the controls, and then write a signature. This is all done by massive teams of people who have limited capacities to work – very much like the inefficient, signature-based anti-malware vendors. It can take days, weeks, or even months until an application signature is added to a support catalog. For organizations who want to protect their data, this is simply not good enough.

Option two is to utilize artificial intelligence and respond to new applications in the same manner as advanced anti-malware solutions. This route entails analyzing the application, identifying the data leakage paths, designing the control, and securing the application automatically in real time.

New, unknown applications should be responded to in the same fashion that an enterprise would respond to any other threat. Rather than waiting days, weeks, or months, they should be addressed immediately.

Cloud App Encryption and CASB

 

By Kyle Watson, Partner/Information Security, Cedrus Digital

man staring at bulletin boardMany organizations are implementing Cloud Access Security Broker (CASB) technology to protect critical corporate data stored within cloud apps. Amongst many other preventative and detective controls, a key feature of CASBs is the ability to encrypt data stored within cloud apps. At the highest level, the concept is quite simple – data flowing out of the organization is encrypted, as it is stored in the cloud. However, in practice there are nuances in the configuration options that may have impact on how you implement encryption in the cloud. This article outlines important architectural decisions to be made prior to the implementation of encryption solutions through a CASB.

Gateway Delivered, Bring Your Own Key (BYOK), or Vendor Encryption

There are three generic methods in cloud-based encryption.

Gateway delivered encryption – In this model, the CASB may integrate with your organization’s existing key management solution through Key Management Interoperability Protocol (KMIP) or provide a cloud-based key management solution. In either case, the keys used to encrypt your data never leave your CASB.

  • Data is encrypted before it leaves your environment and is stored at the vendor
  • You control the keys
  • The vendor retains no capability to access your data

BYOK encryption – In this model, the keys are generated and managed by your organization, and then are supplied to the vendor. BYOK allows you to manage the lifecycle of the keys, which are then shared with the vendor. This includes revoking and rotating keys. The keys are then provided to and utilized by the vendor to decrypt requested data for use by authorized users. CASB can be involved as a broker of the keys to simplify, centralize, and streamline the process of key management by allowing you to perform this administration directly in the CASB User Interface (UI). This also may be done using KMIP with your existing key management solution. Alternatively, without a CASB you may still enjoy the benefits of encryption with your own keys, but administration would be manual on an app-by-app basis.

  • Data is encrypted at the vendor
  • You can control the keys
  • The vendor retains the capability to access your data

Vendor provided encryption – In this model, the vendor provides keys and key management. The administration may be provided through user interfaces provided by the vendor. The CASB is not involved.

  • Data is encrypted at the vendor
  • The vendor controls the keys
  • The vendor retains the capability to access your data

Important Considerations

There is not a “best” way to manage encryption for cloud apps. One important consideration for you to make the best decisions for your company begins with your motivation. Is your primary concern compliance, mitigating risk of vendor compromise, protecting data from being disclosed in blind subpoenas, all three?

  • Compliance – Encryption for compliance can be met easily by any of the three approaches, and is simplest with vendor provided encryption.
  • Mitigating risk of vendor compromise – Using encryption to mitigate the risk of vendor compromise implies the need to manage your own key, since your data will not be accessible without the key. Gateway delivered encryption is the approach that can provide the highest level of risk mitigation due to vendor compromise, as your keys never leave your environment. Cyber- attackers stealing your data will not be able to decrypt it without using your key or breaking your encryption. Risk may also be mitigated through BYOK, but agreements must be secured from the vendor to communicate breaches in a timely fashion. Then you must take appropriate revocation actions in your key management process.
  • Protecting data from being disclosed in subpoenas / blind subpoenas – Using encryption to protect data from being disclosed in subpoenas also implies the need to manage your own key. Gateway delivered encryption is the approach that can provide the highest level of risk mitigation from blind subpoena through a completely technical means, as third parties retrieving your data will not be able to decrypt it without your key. Risk may also be mitigated through BYOK, but agreements must be secured from the vendor to communicate third-party requests for your data in a timely fashion. Then you must take appropriate revocation actions in your key management process.

Unstructured and Structured Data

To further explain these approaches we must break out two very different types of data prevalent in the cloud: Unstructured and structured data. Unstructured data refers to data generated and stored as unique files and is typically served through end user apps, for example, Microsoft Word documents. Structured data refers to data that conforms to a data model and is typically served through relational databases and User Interfaces (UI), for example, Salesforce UI.

Structured Data

  • Gateway delivered encryption – Since the CASB sits between your end user and the application, structured data can represent a challenge to usability. From a usability perspective, whenever the application vendor changes field structures, the encryption must be addressed in order to maintain usability. From a security perspective, the app must decrypt and reveal some information in order to allow search, sort, and type-ahead fields to work properly in a cloud app UI. This is known as “Format Preserving”, “Order Preserving”, and “Order Revealing” encryption, which can lower the overall standard. A growing body of research is challenging this method and exposing weaknesses that may lead to compromise. For example, if you were to type “JO” in a field and it revealed all of the persons with names beginning with JO, this data has to be retrieved decrypted to support the UI.
  • BYOK encryption – since you supply the keys to the vendor, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. From a security perspective, BYOK does not suffer from the same risk of compromise in “reveal”, as exists in gateway delivered encryption.
  • Vendor provided encryption – Since the vendor owns the keys, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. From a security perspective, vendor provided encryption does not suffer from the same risk of compromise in “reveal”, as exists in gateway delivered encryption.

Unstructured Data

  • Gateway delivered encryption – Risk of usability problems is low on unstructured data in cloud storage. However, an important consideration is key rotation. Data encrypted under one set of keys can only be opened with those keys. Keys may need to remain available in archive, for reads, even if they have been retired.
  • BYOK encryption – Since the keys are supplied to the vendor, encryption/decryption occurs within the vendor application architecture as does key rotation and management.
  • Vendor provided encryption – Since the vendor owns the keys, encryption/decryption occurs within the vendor application architecture. This reduces the risk of usability problems when using encryption, because the decryption happens under vendor control. Key management processes will be dependent upon the vendor.

Industry Direction

Most major cloud vendors are moving toward the support of a BYOK model. Some of these include Salesforce, ServiceNow, Box, Amazon Web Services (AWS), and Microsoft Azure to name a few. As more and more vendors are offering this type of capability, at Cedrus we believe that this is the direction of cloud encryption.

Opinion

  • Gateway delivered encryption – This is the highest level of security that can be provided when it comes to cloud app encryption, but may have an impact to the business in usability issues, especially when applied to structured data. High-risk apps and data are safest in this configuration and require the most care and feeding.
  • BYOK encryption – This implementation can provide a very high level of security without the impact that comes with gateway encryption. Through integration with a CASB as a broker of keys to centralize this management, this solution provides an excellent balance between protection and usability for high-risk apps and data.
  • Vendor provided encryption – This implementation provides a much higher level of security than not implementing encryption. This solution may be best suited for apps and data of lower criticality or meeting compliance requirements, only.

Recommendations

As with all security decisions, risk and compliance must be the yardstick in any decision. Since we do not know the industry, application, or risk to your business; this is a generic recommendation.

Where possible, always leverage your own keys over vendor-provided keys. Remember, a breach into a lower-risk app may provide clues to breach other apps.

When provided as an option, the best trade-off between security and usability is BYOK. It is very important to gain agreement from vendors for proactive communication. Where BYOK is not offered, the risks must be weighed carefully between vendor provided and gateway delivered encryption, especially for structured data.

When considering a move to gateway encryption, risk analysis of the app and data are critical. The risk of compromise should be clear and present danger. This is because a decision to move to gateway encryption for structured data means a commitment to the management and maintenance at a much higher level than BYOK or vendor provided encryption. This is not a recommendation against taking this course, but advice to consider this path carefully and plan the resources necessary to maintain this type of implementation. In a recent exchange with a customer they articulated the challenge: “We use CASB to provide field level encryption for our Salesforce instance. There are many issues requiring a lot of support and we have plans to move away from it and leverage encryption that is part of the Salesforce platform.”