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.

Office 365 Security: It Takes Two to Tango

Many cloud apps – including Office 365 – operate under a shared responsibility model. Here’s what that means for your company

By Beth Stackpole, Feature Writer, Symantec

cloud Security concerns, once a long-standing hurdle to cloud deployment, may be on the wane, but the issue is still very much alive when it comes to cloud-based applications such as Microsoft Office 365.

It’s not that Office 365 is inherently less secure than other SaaS offering; it’s that companies still harbor misperceptions related to the shared responsibility model now commonplace for many cloud applications, including Microsoft Office 365. The issue is particularly acute given the rising popularity of the Microsoft cloud platform. Global cloud adoption has topped 81 percent, while Office 365 usage has surged from 34.3 percent to 56.3 percent this last year, eclipsing Google’s G suite, which held steady at 25 percent.

Under the shared responsibility model, security of physical assets, host infrastructure, network controls, and application-level controls are squarely in the hands of cloud service providers (CSPs) like Microsoft, but that hardly covers all the bases. Identity and access management and client and end point protection remain a split responsibility between the CSP and the customer; more importantly, the enterprise needs to take the reins when it comes to data security and classification—a delineation that is often lost on customers expecting that a SaaS solution means security requirements are taken care of.

“One of the most common misperceptions is that Microsoft, by default, is protecting all the data and that’s simply not the case,” says Swapnil Deshmukh, senior director of information security at Visa. “Organizations need to figure out how to protect the application stack and any code that resides there as well as how to protect data stored on the cloud itself.”

Not surprisingly, there have already been some well-publicized breaches. A wave of phishing attacks aimed at stealing passwords used Microsoft 365 Office files posing as tax forms, affecting millions of users. And then there was last year’s mishap when the Office 365 Admin Center itself inadvertently revealed usage data belonging to other tenants, which highlighted the risks in the context of regulations like the European GDPR (General Data Protection Regulations).

A holistic security approach

Symantec’s 2018 Shadow Data Report, which covers the key challenges encountered when trying to secure data and maintain compliance in cloud apps and services, reveals just how high the stakes have become. The report found that 32 percent of emails and attachments in the cloud are broadly shared and 1 percent of those contain compliance-related data, including Personally Identifiable Information (PII), Payment Card Information (PCI), and Protected Health Information (PHI), revealing a much higher risk than anticipated.

Moreover, 68 percent of organizations have some employees who exhibit high-risk behavior in cloud accounts, encompassing everything from data destruction to data exfiltration and accounts takeovers. It gets worse: The 2017 Symantec Internet Security Threat Report (ISTR) found that in 2016 one out of every 131 emails contained a malware attack, and 61 percent of organizations were hit by ransomware incidents.

Microsoft Office 365 delivers an array of security controls, including encryption of data both at rest and via network transmission, threat management and security monitoring capabilities, and online protection to ward against spam and malware. Azure Active Directory is used for authentication, identity management, and access controls and there is support for multi-factor authentication. The platform also has a built-in feature for email encryption, but it isn’t part of the default settings.

This highlights a problem for many users who simply don’t know what’s available beyond Office 365’s default security controls, notes Payton Moyer, president and COO of MLS Technology Group, a managed IT services provider. “Office 365 offers baseline security features baked in and ready to go by default, but to get the maximum security, you have to make an effort to add capabilities and turn them on,” he says.

What’s really important, experts say, is for enterprises to layer on additional security capabilities, including digital rights management; Data Loss Prevention services; as well as threat analytics, blocking, and remediation.

Adds Symantec Senior Technical Sales Manager, Adrian Covich: “People are looking for the base functionality and don’t necessarily proceed with security in mind. They also misunderstand the point to which Microsoft will secure them out of the box versus what they still need to do. There are still fundamental questions you need to answer with SaaS when it comes to the delineation of responsibilities and who has access to data. Are your users who they say they are? What data are you storing and are your business processes sufficiently secure?”

These extra protections should work holistically across the entire enterprise domain, not just for the Microsoft Office 365 cloud silo. To this point, a Cloud Access Security Broker (CASB) can integrate Office 365 and other cloud apps into the broader enterprise security architecture, delivering visibility into shadow IT and cloud application usage, providing data governance and controls for data stored in cloud apps, and leveraging machine learning and user behavior analytics to deliver advanced security and data protection.

“A CASB sits between the enterprise end user and Microsoft Office 365, looks at all the data, and allocates the right controls to it,” says Visa’s Deshmukh. “It stops data exfiltration avenues from an internal perspective and identifies adversaries that may have compromised end users.”

By sharing responsibility and taking a holistic approach, enterprises can close security gaps, minimize potential risks, and ensure a stress-free path to the cloud.

This post was originally published on Sept. 24, 2018, on Symantec.com.

The “Ronald Reagan” Attack Allows Hackers to Bypass Gmail’s Anti-phishing Security

By Yoav Nathaniel, ‎Customer Success Manager, Avanan

Ronald Reagan phishing attack on G SuiteWe started tracking a new method hackers use to bypass Gmail’s SPF check for spear-phishing. The hackers send from an external server, the user sees an internal user (For example, your CEO) and Gmail’s SPF-check, designed to indicate the validity of the sender, shows “SPF-OK.”

Why are we calling this “The Ronald Reagan Attack”? Several of these attacks originated from reagan.com, a website that offers a private email with the domain name of Ronald Reagan, the 40th president of the United States, encouraging its users to “be a cowboy.”

If you are a Gmail for Business customer and suffer from phishing attacks, you might find some comfort in knowing that the lives of Office 365 users are much worse. Maybe it’s because hackers target Office 365 more, maybe because Google does a better job in filtering phishing attacks, but the end result is that Gmail users get less phishing.

How The Ronald Reagan Attack Works
At the core of the attack is the fact that when Gmail’s anti-phishing layer scans the email for impersonation and performs an SPF check, it looks at one “sender” field in the email header but the sender name presented to the human receiver of the email in the Gmail web interface, is taken from another field in the email header.

There are two fields in the email header that play a role here:

1. X-Sender-Id: This is the field that Gmail uses in its SPF-check and and is used for spear phishing and impersonation analysis

2. From: This is the field that is actually presented to the Gmail user

The result is that the machine that tests for phishing finds this email completely legitimate and passes it to the recipient with no warning. But for the recipient, this shows up as an email from someone else, presumably someone in the organization that they know. The recipient has no practical way to find the actual value of the X-Sender-Id field.

Here’s an example of a real such attack and why it was effective (Numbers explained below):

 

(1) X-Sender-Id – This is the real sender. It is the most important part of the attack because in fact it is not spoofed. It is well aligned with the server that sent the email.

(2) The “Reply To” header is presented to the end-user but the actual reply goes to a field called “Return-Path” (Field 5 below). This is also spoofed – it uses the impersonated victim name in a domain that doesn’t exist (And indicates the usage of a mobile phone)

(3,4) Authentication-Results, Received-SPF and Arc-Authentication-Results: These are the fields that indicates the receiver’s (Gmail) calculated authenticity of the email. Note that in all tests, the email address from the X-Sender-ID is selected as the identity to test with (As indicated in the X-Auth-Id field) and that all tests pass successfully – the email is ‘authentic’

(5) Return Path: This field is what the mail server would use if the end-user chooses to reply to sender. The hackers spoofed the “Reply To” field with an address that is presented to the end-user but does not exist, however any actual reply from the recipient will be routed to the attacker.

(6) From: This is the actual attack – the email address of the impersonated sender. The field was used nowhere aside from when it is presented to the recipient!

What Is Google Doing About It?
A quick search in Google’s reporting system reveals that they don’t see SPF vulnerabilities as critical. Therefore, not prioritized to be fixed. If we hear differently, we will update this blog.

What Can I Do?
In many phishing attacks we described, we started by the regular ‘educate your users’, ‘suspect every email’, ‘look at the links’, etc. etc.  But this is one examples when the end-users can do nothing. Their email client shows an authentic email of an internal sender and there’s no warning in the email to indicate anything is wrong with it. In this case, you do need another layer of security on top of the default security from Google.