Keeping Your Boat Afloat with a Cloud Access Security Broker

By Prasidh Srikanth, Senior Product Manager, Bitglass

boat on an Alpine lakeIf you were on a sinking ship that was full of holes of various sizes, which ones would you patch first? Probably the big ones. Now, consider this: As an enterprise, you’ve been successfully sailing and securing your corporate data on premises for some time. However, now you’re migrating to the cloud, looking for increased productivity, collaboration, and cost savings. In this new ocean, organizations must decide how to prioritize security concerns so that they can prevent data leakage.

There are two schools of thought on how organizations should accomplish the above. The first entails beginning by securing your most-used SaaS apps (Office 365BoxG SuiteSlack, et cetera). This is ideally done through a multimode cloud access security broker (CASB) that secures data access in real time via proxy, and secures data at rest in the cloud through API integrations. As these major apps are the primary locations to which your data is flowing, they are your first responsibility to address.

From there, a shadow IT discovery tool can be used to identify the other, less frequently used SaaS apps that employees are accessing. When these uncommon, less widely known apps are discovered, you may then choose to perform policy-based remediations; for example, coaching users to sanctioned alternatives, making shadow IT apps read only, or blocking access altogether. In this way, the larger security gaps are addressed before the smaller ones, meaning that your boat is successfully patched and gets to sail onward.

The other approach to cloud security says that organizations should perform shadow IT discovery before they begin to secure major SaaS applications and enforce data protection policies. In other words, you have to identify everything before you can begin securing anything. With this approach, you start by hunting down every minuscule security gap before beginning to address the apps that represent the largest data leakage threats, meaning that your boat is allowed to take on water.

Gaining insight into SaaS app usage is helpful for the enterprise; however, there’s a handful of apps that act as the gateway to your cloud journey. Addressing these commonly used applications first is the right way to secure your cloud migration. Once you have your bases covered in this way, you can further strengthen your security posture by performing shadow IT discovery and securing the other apps that represent the metaphorical small holes in your boat. With this measured and methodical security approach, you can confidently continue to transform your business and sail into the cloud.

Fixing Your Mis-Deployed NGFW

By Rich Campagna, Chief Marketing Officer, Bitglass

firewall logo imageThe Firewall/Next-Gen Firewall has been the cornerstone of information security strategy for decades now. The thing is, changes in network traffic patterns have resulted in most firewalls protecting a smaller and smaller percentage of enterprise network traffic over time.

This post will illustrate the root cause of these firewall mis-deployments, and how the typical enterprise can correct the issue, restoring the efficacy of their security strategy.

In the beginning

In the beginning, your firewall was in position to protect the majority of your corporate data and applications. Most users were on managed devices, on network (either physically or via VPN), and connected to data and applications inside of the enterprise (private) data center. Everything was protected and the deployment was sound:

premise apps to managed devices

Time goes on

As time went onthe first sanctioned SaaS applications were introduced to the organization. These typically took the form of major SaaS applications like Office 365, G Suite, and Salesforce. Since these applications are publicly available from anywhere, BYOD started to rear its ugly head as well (even if you had held it off in the past). This was the first step towards firewall mis-deployment, with a good portion of corporate data now existing unprotected outside the firewall:

premise apps to BYOD

Eventually, the business got the idea that cloud was easier, more agile, and more cost effective than premises applications, so the demands started to increase. In addition to major SaaS apps, niche industry and/or functional applications started popping up, and the organization began migrating premises applications (both custom apps and package software) to IaaS platforms. Today’s picture for most enterprises looks something like this:

premise apps to IaaS

Results are in

The result? Your firewall is currently protecting only a small percentage of your enterprise applications and data. There is, however, a simple fix for this deployment challenge:

firewall zero to CASB

With the constant wave of applications migrating to the cloud, it won’t be long before we hit Firewall Zero, with Cloud Access Security Brokers taking the firewall’s place as the cornerstone of enterprise security strategy.

Data Breaches on the Rise in Financial Services

By Jacob Serpa, Product Marketing Manager, Bitglass

Financial World: Breach Kingdom report coverFinancial services organizations are a prime target for hackers looking to steal and sell valuable data. This is because these firms handle sensitive information known as PII, personally identifiable information, as well as other financial data. In Financial World: Breach Kingdom, Bitglass’ latest financial breach report, the Next-Gen CASB reveals information about the state of security for financial services in 2018. Read on to learn more.

The rise of financial services breaches

2018 has seen the number of financial services breaches reach new heights. This is likely due to a large number of reasons. For example, some organizations may have an overreliance upon existing cybersecurity infrastructure and find it difficult to justify additional expenses in light of their existing sunk costs in security. Other firms may simply overestimate what traditional endpoint and premises-based tools can do to protect data from evolving threats. Regardless, the fact remains that financial services firms were breached in 2018 nearly three times more than they were in Bitglass’ previous, 2016 report.

Malware leads the pack

In prior years, the causes of financial services breaches were fairly diverse. Lost or stolen devices and hacking each caused about 20 percent of breaches, while unintended disclosures and malicious insiders were responsible for 14 percent and 13 percent, respectively.

However, this year saw a massive shift in the balance of power. Nearly three quarters of all financial services breaches in 2018 were caused by malware or hacking. This seems consistent with headlines over the last year – ransomware, cloud cryptojacking, and highly specialized malware variants have dominated the news when it comes to breaches.

What to do?

In financial services, far more must be done to secure sensitive information. While it is imperative that the enterprise can protect data against any threat, it is now clear that defending against malware deserves special attention. This is particularly true in light of the rise of cloud and BYOD. More devices and applications are storing and processing data than ever before, creating more opportunities for malware to infect the enterprise. Fortunately, there are appropriate solutions available.

To learn more about the state of cybersecurity in financial services, download Financial World: Breach Kingdom.

Seven Reasons Why Proxy-based CASBs Are Required for Office 365

By Rich Campagna, Chief Marketing Officer, Bitglass

O365 logoA competing CASB vendor blogged recently on why proxy-based Cloud Access Security Brokers (CASBs) shouldn’t be used for Office 365.

The post cites “7 reasons,” all of which are variations of just one reason: their CASB breaks each time Microsoft makes changes to Office 365.  What they call “application breakages” due to “updates,” are really “CASB outages.”  In other words, dog ate their homework.

A commonly cited issue with proxies (the only way to achieve real-time cloud data loss prevention or DLP) is their ability to adjust to the near constant changes in cloud applications. However, without an automated solution that can respond to these changes in real time, it’s up to quick response by CASB engineers to fix breakages after they occur, which leads to inevitability of downtime. Make sure you don’t fall into this trap. Select a CASB that can adapt to changes on the fly. Don’t throw out proxy technology completely just because some vendors can’t do it properly.

Proxy-based CASBs: Seven reasons why

So, knowing that a proxy-based solution for Office 365 can work, if you pick the right one, why go inline with Office 365 versus relying purely on out-of-band API integration? Here are 7 unique reasons:

  1. Managed vs Unmanaged Device Access Control – For most organizations, a managed device represents a much lower risk than an unmanaged BYO device. Proxy-based controls allow you to distinguish between the two and provide a different level of access to the app and to sensitive corporate data.
  2. OneDrive Sync Client Control – A OneDrive sync client constantly synching many GBs of corporate data to an unmanaged device is riskier than a user on that device logging into OneDrive via web browser to download a couple of files that they need. Proxy allows you to control by access method,
  3. Real-time Data Leakage Prevention – API-based integration with apps like Office 365 is great for scanning data-at-rest, but only provides “Monday morning” notifications of data leakage. Proxies prevent data leakage in real-time.
  4. BYOD Malware Prevention – Your organization probably has unmanaged devices connecting into Office 365. Devices that could be infected with malware. Proxy-based solutions stop malware from making its way into Office 365, thwarting would-be attempts to use Office as an IT sanctioned and paid for malware distribution tool.
  5. Session Management – You likely want to aggressively time out and reauthenticate users on unmanaged or new devices. Possible with proxy, not possible with API.
  6. Step-up Multifactor Authentication – See suspicious activity mid-session? Evidence of credential compromise? Only inline CASB allows you to do something about it as it starts to occur.
  7. Data-at-rest Encryption – In many industries, there is a desire to use the public cloud but without giving up control over your data. Proxy-based CASBs allow you to encrypt data before it gets to the cloud. Public cloud apps with private cloud security – have your cake and eat it too!

Bonus: One bonus add — Office 365 might be your main (or only) cloud app today, but that will most definitely change in the future. The fact is, only a small handful of cloud applications provide APIs that are security relevant, whereas a properly architected proxy can support any application.

POC the CASB

By Rich Campagna, Chief Marketing Officer, Bitglass

POCtheCASB poster imageThe Cloud Access Security Broker, or CASB, space has quickly made its way to the mainstream, with organizations of every size and every industry deploying CASBs whenever their data moves beyond the firewall.

While ready for primetime and widely deployed, some enterprises are taking the risky step of skipping the proof-of-concept or trial phase. Given the rapid evolution of the enterprise use cases, and of CASB vendor solutions, we always encourage organizations to #POCtheCASB (of course, it helps that our sales team has complete confidence in the quality of our CASB solution and in our support …).

Seven ways to #POCtheCASB

Here are a few of the key areas to focus on for a successful trial:

  • Proxy Robustness – A commonly cited issue with proxies (the only way to achieve real-time cloud data loss prevention or DLP) is their ability to adjust to the near constant changes in cloud applications. However, without an automated solution that can respond to these changes in real time, it’s up to quick response by CASB engineers to fix breakages after they occur, which leads to inevitability of downtime. Make sure you don’t fall into this trap. Select a CASB that can adapt to changes on the fly. Don’t throw out proxy technology completely just because some vendors can’t do it properly.
  • User Experience – The days of the security team being able to put their needs ahead of the user experience are long gone. Be sure to test with volunteer users from a variety of different business units or departments. Ensure that the CASB solution preserves the user experience and requires minimal or no retraining for your test group.
  • Managed and Unmanaged Device Access – Even if you held BYOD at bay with premises applications, it will become a reality when you move to the cloud. Be sure to test the capabilities of the CASB on both managed devices, as well as on a range of BYO device types to ensure that policy and control capabilities work equally well on all device types.
  • Performance – A well-architected CASB solution should offer high performance and low latency for all users globally, as well as when under peak load. Test from a variety of geos and from several different times of day.
  • Enterprise Integration – Most enterprises end up integrating their CASB into several other systems including Active Directory, IDaaS, network DLP, SIEM and more. Test to be sure that the CASB has appropriate connectors for each of these systems.
  • Flexibility – You might initially deploy a CASB for a small number of cloud applications, but for most enterprises, their cloud footprint begins to evolve and grow rapidly once cloud takes root in the organization. Ensure that you develop test cases that exercise the CASBs ability to test not only your current needs, but the future needs of your business.
  • Policy – Last but not least, test out the policies you plan to develop on your CASB! Whether you’re planning to use baseline policies like access control and UEBA, or more sophisticated policies involving DLP and encryption, run the test CASB(s) through their policy paces.

Pwned Passwords – Have Your Credentials Been Stolen?

By Paul Sullivan, Software Engineer, Bitglass

hacker in a hoodie with credit cards, computer screenData breaches now seem to be a daily occurrence. In recent months, Have I Been Pwned (HIBP) introduced  Pwned Passwords, which allows you to securely check your password against a database of breach data. There are over 280 breaches in the database, and that’s only the tip of the iceberg. Breaches aren’t just a problem for the users who lose their data, but for the companies responsible for it.   

So how does all this data get breached?

Surely, it was some sinister character in a hoodie with extensive knowledge of computers, right? As it turns out, many of the data breaches came from misconfigured databases and Amazon S3 buckets that were left wide open for anyone who knows where to look. S3 is easy to use, which is great for security-conscious developers. However, it also makes it easy for someone who doesn’t understand security to toss some data into the cloud (so that it’s publicly viewable) and forget about it. As noted by Troy Hunt, the security researcher who runs HIBP, one company was breached because it stored personal data from IoT devices in MongoDB and Amazon S3 buckets with no credentials. It’s not just small, unorganized companies that make these mistakes either. Big corporations are losing track of their configurations, too.

Proper training is a good way to help with these problems, but it’s not always enough. Fortunately, a cloud access security broker (CASB) can help keep S3 and other cloud data secure by encrypting the data at rest. That way, even if data can be accessed by unauthorized parties, it is still unreadable and protected. A CASB can also provide auditing and analytics tools to help detect suspicious activity so that data breaches can be detected early as well as prevented from happening in the first place.

EU GDPR vs US: What Is Personal Data?

 

By Rich Campagna, Chief Marketing Officer, Bitglass

GDPR-personal data screen shotMay 25, 2018—GDPR enforcement day,—has come and gone with little fan fare (and about 6 quadrillion privacy policy updates), but that doesn’t mean we all know what to do to get into compliance. In fact, some measures put only one third of organizations in compliance as of the deadline, and the linked article refers to UK organizations—what about US organizations that are only now catching on to the fact that they probably need to be GDPR compliant? We thought that contrasting GDPR with typical US regulations and definitions would be helpful.

It’s personal. Or, is it?

First topic, what constitutes personal data?

In the US, when we hear “personal data,” that usually equates to Personally Identifiable Information (PII). PII, according to the CIO of the US Navy, is “information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, including any other personal information which is linked or linkable to a specified individual.” This has become an important enough topic that NIST has created a list of specific fields that constitute PII.

GDPR: It’s more than PII

How does this differ from how personal data is defined in GDPR?

Well, according to the GDPR, personal data means “any information relating to an identified or identifiable natural person.”

Side note: In GDPR, “natural persons” are typically referred to as, “data subjects,” which is the least personal and least natural possible way to describe natural persons that I can think of, but I digress…

GDPR clarifies that “identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.

In other words, personal information includes the US definition of PII, but goes much further. In addition to PII, personal information can include IP address (yes, even dynamic IPs with user behind a router doing NAT/PAT), sexual preference, medical prescriptions, occupation, eye color, shoe size and puzzling fandom of the band Survivor.

That’s lesson #1 – personal data, as defined by GDPR, goes far further than the typical US definition of PII.

More to come in future posts…

 

 

What Is a CASB?

By Dylan Press, Director of Marketing, Avanan

Email is the #1 attack vector. Cloud Account Takeover is the #1 attack target.
A CASB is the best way to protect against these threats.

cartoon of man asking What is a CASBGartner first defined the term Cloud Access Security Broker (CASB) in 2011, when most IT applications were hosted in the data center and few companies trusted the cloud. Most online services were primarily aimed at the consumer. At the time, CASB products were designed to provide visibility for so-called Shadow IT and limit employee access to unauthorized cloud services.

Today, organizations have embraced the cloud, replacing many of their datacenter applications with Software as a Service (SaaS) or moving much of their IT into infrastructure (IaaS) providers like Amazon or Azure. Instead of limiting access, CASBs have evolved to protect cloud-hosted data and provide enterprise-class security controls so that organizations can incorporate SaaS and IaaS into their existing security architecture.

CASBs provide four primary security services: Visibility, Data Security, Threat Protection, and Compliance. When comparing CASB solutions you should first make sure that they meet your needs in each of these categories.

Visibility

A CASB identifies all the cloud services (both sanctioned and unsanctioned) used by an organization’s employees. Originally, this only included the services they would use directly from their computer or mobile device, often called “Shadow IT“. Today, it is possible for an employee to connect an unsanctioned SaaS directly to a an approved SaaS via API. This “Shadow SaaS” requires more advanced visibility tools.

Shadow IT Monitoring: Your CASB must connect to your cloud to monitor all outbound traffic for unapproved SaaS applications and capture real-time web activity. Since nearly all SaaS applications send your users email notifications, your CASB should also scan every inbox for rogue SaaS communication to identify unapproved accounts on an approved cloud services.

Shadow SaaS Monitoring: Your CASB must connect to your approved SaaS and IaaS providers to monitor third-party SaaS applications that users might connect to their account. It should identify both the service as well as the level of access the user has provided.

Risk Reporting: A CASB should assess the risk level for each Shadow IT/Shadow SaaS connection, including the level of access each service might request (i.e. read-only access to a calendar might be appropriate, read-write access to email might not.) This allows you to make informed decisions and prioritize the applications that need immediate attention.

Event Monitoring: Your CASB should provide information about real-time and historical events in all of your organization’s SaaS applications. If you do not know how the applications are being used, you can not properly control them or properly assess the threats facing your organization.

Data Security

A CASB enforces data-centric security policies by offering granular access controls or encryption. It incorporates role-based policy tools, data classification and loss prevention technologies to monitor user activity and audit, block or limit access. Once, these were stand-alone systems. Today it is vital that they are integrated into the organization’s data policy architecture.

Data Classification: Your CASB should identify personally identifiable information (PII) and other confidential text within every file, email or message. Taking this further, it should be capable of applying policies to control how that sensitive information can be shared.

Data-Centric Access Management: Your CASB should allow you to manage file permissions based upon the user’s role and the type of data the file contains using cloud-aware enforcement options that work within the context of the cloud service.

Policy-based Encryption: Your CASB should be able to encrypt sensitive information across all your cloud services to ensure data security, even after files leave the cloud.

Threat Protection

A CASB protects cloud services from unwanted users or applications. This might include real time malware detection, file sandboxing or behavior analytics and anomaly detection. New threats require new protections, so the list should include anti-phishing, account-takeover detection and predictive (A.I.) malware technologies.

Anti-phishing Protection: Phishing attacks are the #1 source of data breaches every year, but few CASBs offer phishing protection for cloud-based email. For a technology that is protecting your cloud environment, anti-phishing is a must. It has been proven over and over again that your email provider is not a viable solution to the phishing problem.

Account Takeover Protection: Your CASB should monitor every user event (not just logins) to identify anomalous behavior, permission violations, or configuration changes that indicated a compromised account.

URL Filtering: Your CASB should check every email, file, and chat messages for malicious links.

Real Time Malware Detection: Your CASB should scan every email and file for active code and malicious content before it reaches the inbox.

Advanced Threat Sandboxing: Your CASB should test suspicious files in an emulation environment to detect and stop zero-day threats.

Compliance

Regulated organizations require auditing and reporting tools to demonstrate data compliance and a CASB should provide all the necessary auditing and reporting tools. More advanced solutions offer policy controls and remediation workflows that enforce regulatory compliance in real time for every industry, from GDPR and SOX to PCI and HIPAA..

SIEM Integration: Your CASB should collect and correlate user, file and configuration events from each cloud application installed in your organization’s environment and make them visible through your organization’s existing reporting infrastructure.

Auditing: Your CASB should have access to historical event data for retrospective compliance auditing as well as real-time reporting.

Enforcement: Your CASB should be able to move and encrypt files, change permissions, filter messages or use any number of cloud-native tools to ensure compliance through automated policies.

Email Security from Your CASB

As you may have noticed, across all the CASB criteria, email security is a major component. Can this really be that important? After all, so few CASBs include email security.

No matter the motivation, email continues to be the most common vector for enterprise breaches. Phishing and pretexting represented 98% of social incidents and 93% of breaches last year. Protection for the cloud must include protection for cloud-based email. Without cloud-based email security, a CASB is not truly providing full cloud security and is just acting as a simple Shadow IT tool.

Conclusion

While a solution doesn’t need to have every feature mentioned in this blog post in order to sell themselves as a CASB, they are the criteria that separate the CASBs that are complete security solutions from those that will need to be paired with additional security tools. If you want a CASB to act as your full security suite protecting your organization from cloud-borne threats then this will serve as a useful checklist.

Microsoft Workplace Join Part 1: The Security Timebomb

By Chris Higgins, Technical Support Engineer, Bitglass

timebomb countdown to Workplace Join infosecurity riskIt’s no secret that enterprise users wish to access work data and applications from a mix of both corporate and personal devices. In order to help facilitate this mix of devices, Microsoft has introduced a new feature called Workplace Join into Azure Active Directory, Microsoft’s cloud-based directory and identity service. While the intent of streamlining user access to work-related data is helpful, the delivery of this feature has resulted in a large security gap—one that can’t easily be disabled. This is another example of an app vendor optimizing for user experience ahead of appropriate controls and protections—demonstrating the basis for the cloud app shared responsibility model and the need for third-party security solutions like cloud access security brokers (CASBs).

According to Microsoft, “…by using Workplace Join, information workers can join their personal devices with their company’s workplace computers to access company resources and services. When you join your personal device to your workplace, it becomes a known device and provides seamless second factor authentication and Single Sign-On to workplace resources and applications.”

How does it work?

When a user links their Windows machine to “Access Work or School,” the machine is registered in Azure AD, and a master OAuth token is created for use between all Microsoft client applications as well as Edge/I.E. browsers. Subsequent login attempts to any Office resource will cause the application to gather an access token and log in the user without ever prompting for credentials. The ideology behind this process is that logging in to Windows is enough to identify a user and give them unrestricted access to all Office 365 resources.

In plain language, this means that once you login to Office 365 from any device (Grandma’s PC, hotel kiosks, etc.), you, and anyone accessing that device, are logged in to Office 365 automatically moving forward.

Why is this such a big security issue?

Workplace Join undoes all of your organization’s hard work establishing strong identity processes and procedures—all so that an employee can access corporate data from Grandma’s PC (without entering credentials). Since Grandma only has three grandkids and one cat, it likely won’t take a sophisticated robot to guess her password—exposing corporate data to anyone who accesses her machine. Making matters worse, user accounts on Windows 10 don’t even require passwords, making it even easier for data to be exfiltrated from such unmanaged devices.

Workplace Join is enabled by default for all O365 tenants. Want to turn it off? You’ll have to wait for the next blog post to sort that out.

In the meantime, download the Definitive Guide to CASBs to learn how cloud access security brokers can help secure your sensitive data.

Cloud Security Trailing Cloud App Adoption in 2018

By Jacob Serpa, Product Marketing Manager, Bitglass

In recent years, the cloud has attracted countless organizations with its promises of increased productivity, improved collaboration, and decreased IT overhead. As more and more companies migrate, more and more cloud-based tools arise.

In its fourth cloud adoption report, Bitglass reveals the state of cloud in 2018. Unsurprisingly, organizations are adopting more cloud-based solutions than ever before. However, their use of key cloud security tools is lacking. Read on to learn more.

The Single Sign-On Problem

Single sign-on (SSO) is a basic, but critical security tool that authenticates users across cloud applications by requiring them to sign in to a single portal. Unfortunately, a mere 25 percent of organizations are using an SSO solution today. When compared to the 81 percent of companies that are using the cloud, it becomes readily apparent that there is a disparity between cloud usage and cloud security usage. This is a big problem.

The Threat of Data Leakage

While using the cloud is not inherently more risky than the traditional method of conducting business, it does lead to different threats that must be addressed in appropriate fashions. As adoption of cloud-based tools continues to grow, organizations must deploy cloud-first security solutions in order to defend against modern-day threats. While SSO is one such tool that is currently underutilized, other relevant security capabilities include shadow IT discoverydata loss prevention (DLP), contextual access control, cloud encryptionmalware detection, and more. Failure to use these tools can prove fatal to any enterprise in the cloud.

Microsoft Office 365 vs. Google’s G Suite

Office 365 and G Suite are the leading cloud productivity suites. They each offer a variety of tools that can help organizations improve their operations. Since Bitglass’ 2016 report, Office 365 has been deployed more frequently than G Suite. Interestingly, this year, O365 has extended its lead considerably. While roughly 56 percent of organizations now use Microsoft’s offering, about 25 percent are using Google’s. The fact that Office 365 has achieved more than two times as many deployments as G Suite highlights Microsoft’s success in positioning its product as the solution of choice for the enterprise.

The Rise of AWS

Through infrastructure as a service (IaaS), organizations are able to avoid making massive investments in IT infrastructure. Instead, they can leverage IaaS providers like Microsoft, Amazon, and Google in order to achieve low-cost, scalable infrastructure. In this year’s cloud adoption report, every analyzed industry exhibited adoption of Amazon Web Services (AWS), the leading IaaS solution. While the technology vertical led the way at 21.5 percent adoption, 13.8 percent of all organizations were shown to use AWS.

To gain more information about the state of cloud in 2018, download Bitglass’ report, Cloud Adoption: 2018 War.

Bitglass Security Spotlight: Twitter, PyRoMine, & Stresspaint

By Jacob Serpa, Product Marketing Manager, Bitglass

man holding coffee cup and reading newspaper cybersecurity industry newsHere are the top cybersecurity stories of recent weeks:

—Twitter exposes user credentials in plaintext
—PyRoMine mines Monero and disables security
—Stresspaint malware hunts Facebook credentials
—MassMiner malware mines cryptocurrency
—Access Group Education Lending breached

Twitter exposes user credentials in plaintext

Despite the fact that Twitter doesn’t store or display users’ credentials in plaintext, the social media company recently had a security mishap. Passwords were stored in internal logs before they were successfully obfuscated, exposing them to employees in plaintext. While the information wasn’t made viewable to outside parties, it’s still a cause for concern for Twitter’s users.

PyRoMine mines Monero and disables security

New malware, PyRoMine, leverages a host of previously disparate capabilities featured in other strains of malware. For example, it uses NSA exploits while mining Monero, a cryptocurrency. Malware is continuing to grow more sophisticated, compelling organizations to adopt advanced anti-malware solutions.

Stresspaint malware hunts Facebook credentials

Disguised as a stress-relieving paint program, Stresspaint is a piece of malware that is attacking users in an attempt to gather their Facebook credentials. In particular, the malware is targeting influential users – those who manage Facebook pages or have numerous friends and followers. It is primarily distributed through emails and messages on Facebook.

MassMiner malware mines cryptocurrency

MassMiner is the latest in a slew of malware strains that engage in malicious cryptomining. This threat seeks to take advantage of known vulnerabilities in order to commandeer web servers and mine Monero – which continues to be a common target in malicious cryptomining.

Access Group Education Lending breached

Unfortunately for those who have used the organization’s services for their student loans, Access Group Education Lending has been breached. Nearly 17,000 borrowers had their information exposed when a loan processing vendor working for the group shared their information with an unauthorized, unknown company.

Fortunately for the enterprise, cloud access security brokers (CASBs) can defend against zero-day malware and countless other threats. To learn more, download the Zero-Day Solution Brief.

How ChromeOS Dramatically Simplifies Enterprise Security

By Rich Campagna, Chief Marketing Officer, Bitglass

chrome logoGoogle’s Chromebooks have enjoyed significant adoption in education, but have seen very little interest in the enterprise until recently. According to Gartner’s Peter Firstbrook in Securing Chromebooks in the Enterprise (6 March 2018), a survey of more than 700 respondents showed that nearly half of organizations will definitely purchase or probably will purchase Chromebooks by EOY 2017. And Google has started developing an impressive list of case studies, including WhirlpoolNetflixPinterestthe Better Business Bureau, and more.

And why wouldn’t this trend continue? As the enterprise adopts cloud en masse, more and more applications are available anywhere through a browser – obviating the need for a full OS running legacy applications. Additionally, Chromebooks can represent a large cost savings – not only in terms of a lower up-front cost of hardware, but lower ongoing maintenance and helpdesk costs as well.

With this shift comes a very different approach to security. Since Chrome OS is hardened and locked down, the need to secure the endpoint diminishes, potentially saving a lot of time and money. At the same time, the primary storage mechanism shifts from the device to the cloud, meaning that the need to secure data in cloud applications, like G Suite, with a Cloud Access Security Broker (CASB) becomes paramount. Fortunately, the CASB market has matured substantially in recent years, and is now widely viewed as “ready for primetime.”

Overall, the outlook for Chromebooks in the enterprise is positive, with a very real possibility of dramatically simplifying security. Now, instead of patching and protecting thousands of laptops, the focus shift towards protecting data in a relatively small number of cloud applications. Quite the improvement!

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

patches on jeansI 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.”