Comments
Security in the Cloud: Pitfalls and Potential of CASB Systems
Newest First  |  Oldest First  |  Threaded View
PatrickF934
50%
50%
PatrickF934,
User Rank: Apprentice
6/16/2017 | 3:07:16 PM
Re: CASBs can, in fact, take action on the issues they highlight.
Thanks for your response to the article. I work with Tim at Evident.io, and while I understand your points, I want to clarify some things. Taking action is not sending the data off to a non-CASB product and throwing the issue over the wall.  Sure, if you are a legacy man-in-the-middle approach to control you can attempt to take action, but architecturally this would fail when cloud services are accessed outside the networks behind the CASB solution. "Public Cloud" is exactly that... unconstrained access from anywhere in the world. This is where the CASB approach fails. No CASB player has full API coverage for public cloud and therefore cannot lay claim that they are true hybrid coverage solutions, much less process the environments in real time and mitigate risk across the overall attack surface. Integrations with other point products is a referral network, and not core CASB remediation capability.
nets651
0%
100%
nets651,
User Rank: Apprentice
6/8/2017 | 10:32:43 AM
CASBs can, in fact, take action on the issues they highlight.
The comment by the gentleman from Evident.Io is plainly inaccurate. Multi-mode CASBs have gone far beyond Discovery for many years and can take a multitude of actions on anomalies, threats detected, DLP violations etc... both inline and out-of-band, including access control, alerting, quarantine, blocking, coaching, redirecting, encrypting/tokenizing and more. These actions can be taken across all modes, from out-of-band APIs to reverse proxy or full forward proxy.  They can be integrated with existing DLP, UBA, Threat Detection and IR solutions for end-to-end closed-loop remediation. 


Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
New Mexico Man Sentenced on DDoS, Gun Charges
Dark Reading Staff 5/18/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11354
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the IEEE 1905.1a dissector could crash. This was addressed in epan/dissectors/packet-ieee1905.c by making a certain correction to string handling.
CVE-2018-11355
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, the RTCP dissector could crash. This was addressed in epan/dissectors/packet-rtcp.c by avoiding a buffer overflow for packet status chunks.
CVE-2018-11356
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the DNS dissector could crash. This was addressed in epan/dissectors/packet-dns.c by avoiding a NULL pointer dereference for an empty name in an SRV record.
CVE-2018-11357
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the LTP dissector and other dissectors could consume excessive memory. This was addressed in epan/tvbuff.c by rejecting negative lengths.
CVE-2018-11358
PUBLISHED: 2018-05-22
In Wireshark 2.6.0, 2.4.0 to 2.4.6, and 2.2.0 to 2.2.14, the Q.931 dissector could crash. This was addressed in epan/dissectors/packet-q931.c by avoiding a use-after-free after a malformed packet prevented certain cleanup.