Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

7/17/2018
02:30 PM
Gunter Ollmann
Gunter Ollmann
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Cloud Security: Lessons Learned from Intrusion Prevention Systems

The advancement of AI-driven public cloud technology is changing the game of "protection by default" in the enterprise.

I recently had the opportunity to brief an industry analyst on the rapid advancement of artificial intelligence (AI) in solving public cloud security. Both the analyst and I had navigated the inception and commercialization of intrusion prevention systems (IPS) and have been skeptical for many years that just because a security technology is capable of preventing a threat or an active attack, customers won't necessarily operate the technology in a protection mode.

Even today, I'd estimate that 80% of network IPS is operated in detection-only mode and, while faring better, host-based IPS is likely deployed in 60% of enterprise environments as detect and alert only.

During our conversation, a question arose for both of us, two IPS-wary veterans: are customers prepared to turn on protection? Or, more specifically, why would customers enable the protection piece now? Since my initial discussion with the analyst, I've been looking for a more complete way to articulate why I think IPS history fails to answer the question of why "protection" will inevitably be enabled by default for businesses operating from the cloud.

With or without the next generation or NG prefix, IPS is expected to operate in a standalone manner — a bit like a firewall — to independently analyze a local stream of traffic or data, identify specific events or attack techniques, raise an alert, and (if operated in prevention mode) block or terminate that stream. Enterprise security teams are typically reluctant to enable IPS blocking due to three critical objections:

1. Prevention decisions are made in real-time at the IPS device level, reliant upon inspecting streaming traffic at that precise time and physical location within the network. IPS is therefore not "context aware" — which leads to high levels of false positives if expert environmental tuning is not regularly performed.
2. Prevention actions are performed locally against the stream of traffic and data being inspected. While the IPS may be best placed to detect a particular threat at that physical location within the enterprise, it is often not the optimal place to take a preventative action.
3. The prevention methods available to an IPS are fairly crude, ranging from firewall-level blocking of traffic, to performing TCP Resets for session termination, requiring coarse-grained parameters for response (e.g., IP address, port number, protocol).

When it comes to enterprise security and threat visibility, public cloud and its wielding of AI are, quite simply, game changers.

At its core, the requirement to meter and bill customers for compute, storage, or traffic — accompanied with the transparent capability to dynamically balance workloads and elastically scale on demand — afford a level of environmental visibility and control unheard of in traditional enterprise network architectures.

While most public cloud provider's built-in security products share the same nomenclature as their enterprise network cousins, they bear little resemblance under the hood as they are architected specifically for that providers' cloud and benefit from unique environmental visibility, shared logging and alerting management, cross-product analytics, built-in automation and orchestration APIs, and increasingly advanced AI capabilities.

Few of these advancements are immediately visible to public cloud customers, so why will security teams enable and allow "protection" in the cloud like they never did with IPS? I believe the technical answer lies in a combination of the following:

  • "Protection" decisions are automatically applied to the most efficient and natural place in the cloud environment rather than just the location where primary detection may have taken place. This enables greater precision when blocking.
  • Mitigation steps don't have to be harsh all-or-nothing controls and can instead be distributed among multiple security products and cloud applications simultaneously. This greatly reduces possible negative business impact and adverse user experiences, for example, combining conditional access controls and network traffic throttling when handling a suspicious user event initiated from a shared and trusted remote device.
  • Cross-product visibility and threat telemetry are combined, allowing intelligent systems to identify new threats and reach decisions on what and how to mitigate at lower thresholds and with higher confidence than stand-alone single-source protection products.
  • Threat detection precision, anomaly identification and labeling, and overall detection confidence levels have increased as legacy signature and statistics-based approaches have been replaced with high-accuracy supervised learning models and behavioral anomaly capabilities.

While the technical capabilities of cloud security offerings lend themselves to higher confidence and trust in their protection ability, I think that two more important dynamics are driving "protection by default" adoption in the cloud faster than on-premises.

First, the escalation in volume, sophistication, and rapidity of attack is forcing organizations to respond to threats quicker and in a more automated fashion than ever; it's just easier to preemptively enable protection and tune out business exceptions afterward.

Second, and likely most important, is that the majority of businesses moving to public cloud do not have in-house information security expertise. Put simply, security alerts are unactionable and a distraction for them. They demand a secure platform to run their business and expect the cloud provider to fully protect them.

Related Content:

Learn from the industry's most knowledgeable CISOs and IT security experts in a setting that is conducive to interaction and conversation. Register before July 27 and save $700! Click for more info

Gunter Ollmann serves as CTO for security and helps drive the cross-pillar strategy for the cloud and AI security groups at Microsoft. He has over three decades of information security experience in an array of cyber security consulting and research roles. Before to joining ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
benmajece
50%
50%
benmajece,
User Rank: Apprentice
8/10/2018 | 9:55:42 AM
My opinion
This article will be useful to read for students! I've learned a lot of new info about securiy here
Why Cyber-Risk Is a C-Suite Issue
Marc Wilczek, Digital Strategist & CIO Advisor,  11/12/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19071
PUBLISHED: 2019-11-18
A memory leak in the rsi_send_beacon() function in drivers/net/wireless/rsi/rsi_91x_mgmt.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption) by triggering rsi_prepare_beacon() failures, aka CID-d563131ef23c.
CVE-2019-19072
PUBLISHED: 2019-11-18
A memory leak in the predicate_parse() function in kernel/trace/trace_events_filter.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption), aka CID-96c5c6e6a5b6.
CVE-2019-19073
PUBLISHED: 2019-11-18
Memory leaks in drivers/net/wireless/ath/ath9k/htc_hst.c in the Linux kernel through 5.3.11 allow attackers to cause a denial of service (memory consumption) by triggering wait_for_completion_timeout() failures. This affects the htc_config_pipe_credits() function, the htc_setup_complete() function, ...
CVE-2019-19074
PUBLISHED: 2019-11-18
A memory leak in the ath9k_wmi_cmd() function in drivers/net/wireless/ath/ath9k/wmi.c in the Linux kernel through 5.3.11 allows attackers to cause a denial of service (memory consumption), aka CID-728c1e2a05e4.
CVE-2019-19075
PUBLISHED: 2019-11-18
A memory leak in the ca8210_probe() function in drivers/net/ieee802154/ca8210.c in the Linux kernel before 5.3.8 allows attackers to cause a denial of service (memory consumption) by triggering ca8210_get_platform_data() failures, aka CID-6402939ec86e.