Contributed By Oren Yunger, Investor at GGV Capital, and Omer Singer, Senior Director of Security at Snowflake

For every hour that security teams spend triaging alerts, how many minutes do they spend applying their cybersecurity expertise? In our experience, it’s only a small fraction of the time. Why such a ratio? The complexity of their environment requires analysts to rely on intimate familiarity with the organization to determine whether an alert represents an actual breach. In this article, we’ll share how data-driven security teams are breaking down data silos, improving alerts telemetry and enjoying a 90% reduction of false positive alerts.

Most security professionals are probably familiar with Target’s classic example of alert triage failure. In 2013, Target’s Security Operations Center disregarded a generic alert that could have provided early warning of its massive data breach. Some observers might call out the SOC’s actions as negligent. But that would not be taking into account the challenge of dealing with thousands or millions of daily alerts in a complex and dynamic environment like that of Target.

While this challenge is well recognized, the prevailing approaches each suffer from major drawbacks.

Security engineers and vendors should consider a fourth approach – adding more data into the mix. While too much data seemed to be a part of the problem, it turns out that more data can reduce noise for security teams that join together diverse data sets.

Consider a situation where an AWS user terminates ten Linux servers. A typical threat detection solution may alert on this anomaly as a possible indication of compromise, so that an analyst or automated playbook may disable the user and prevent further destruction. Triage is required before a decision can be made because there are a few possible explanations with very different outcomes.

One possible explanation is that a DevOps engineer was cleaning up old test servers that haven’t been used in a year. Alternatively, the same activity might be a compromised service account being hijacked to bring down core business servers during peak hours.

The correct triage depends on the context – there is a big difference between a DevOps engineer, who is a trusted privileged user, operating from the office with a company managed device, authenticated through Okta, as opposed to a recently terminated IT admin who’s logging in from Starbucks.

Understanding these differences makes up most of the time that people spend on alert triage. Automatically differentiating between those two scenarios requires additional data beyond the activity logs. The additional data must provide context to the decision making, changing the logic from a single dimension (“what happened”) to multiple dimensions, which include user context (“who is this user”) and asset context (“what is this system”).

As the field of security analytics matures, contextual information is increasingly applied to the alert logic. Multi-dimensional detection logic can avoid raising alerts that would be disregarded by analysts. Even better, breaches that would otherwise be missed can be surfaced to security teams in time.

For example, resources in AWS may be tagged by role: production, sandbox, etc. While AWS CloudTrail activity logs do not include these tags, detection logic that can access stored instance configuration data can avoid alerts for sandbox resources and elevate severity on production ones. Another application for context can be HR data – even routine activity by someone that’s been recently fired or given notice of termination should set off alarm bells.

The catch? The correlations described above require analyzing data that is not found in most organizations’ SIEM solutions or security data lakes. As such, security teams looking to cut noise and improve detection capabilities through better security analytics need to start by getting the data into a single, queryable location. For many of these data sources, that means reaching across the organization to teams that have never before thought of their data as “security data”.

Examples of data sources that can enrich context and improve alert fidelity include:

• Human Resources (HR) records with data on employee termination
• User directory records with data on employee team affiliation
• Endpoint activity logs describing what was running on the laptop of an admin while their user was making changes to the cloud environment
• Email activity logs indicating possible phishing prior to unusual user activity
• Vulnerability management findings for at-risk servers
• AWS tag data linking resources to environments and data classifications

Unfortunately, not all of this information is readily interconnected and accessible for security teams today. Let’s dive into what analytics stack is available for organizations that are looking to tap into the potential of contextual data for improving their security analytics. Some threat detection solutions are optimized for search rather than joining myriad datasets. Traditional SIEM solutions, such as HP’s ArcSight, support correlation along a single dimension but suffer from performance limitations on joins and actually warn users against going beyond very limited data joining. These limitations prevent the needed contextual enrichment. For that purpose, modern data warehouses are increasingly becoming the platform for multi-dimensional threat detection and response, the kind of “connecting the dots” that frees up analysts and catches intrusions that would have otherwise been missed.

Not all organizations will be able to go beyond aggregating data to their data warehouse. For more advanced threat detection and mitigation capabilities, emerging vendors combine existing datasets to provide actionable insights. A new breed of security startups is focusing on effective analytics instead of adding more sensors. Customers should ask security vendors to demonstrate that they are able to combine multiple datasets to see the full picture and achieve high-fidelity results.

Even with access to a modern data warehouse, many security teams may not be able to create the analytics and correlation needed to take advantage of the technology. There is a great amount of knowledge siloed across different organizations. This is a great opportunity for open source collaboration to lower the barriers and improve security teams telemetry. In the area of data connectors, open source can be used to standardize how event logs, asset inventory and configuration data is collected from the relatively short list of commonly used cloud-based sources. For connecting the dots among the same common sources, open source detection logic can be written, shared, and maintained by the community. The fact that JSON and SQL are standard across data sources and analytics systems means that rules can be vendor agnostic more than ever before.

To conclude, we believe that with a modern approach to data, security teams can move from a “more data equals more noise” paradigm to one where “more data equals more context and less noise”. Join this shift by initiating conversations within the organization to collect more internally available data as well as data from external third-parties. As customers, ask vendors to collect more contextual data and to use it to reduce false positives. Let’s encourage collaboration and knowledge sharing with like-minded security teams, and make our industry a less noisy place to do good security.

The opinions expressed in this article are the personal opinions of the author. The facts and opinions appearing in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.

Contributed by Ryan Riggs, VP of Cloud Services at ProKarma  

Rogue In-Flight Data Load (RIDL), ZombieLoad and Fallout are among the new supervillains of cybersecurity. More widely known as Microarchitectural Data Sampling (MDS) attacks, they compromise Intel processors at the microarchitecture level and skim sensitive data from users.

Understandably, the ramifications are enormous because Intel is the largest semiconductor company in the world and these side-channel attacks affect every chip made since 2011. One more piece of bad news: These supervillains can also compromise public clouds. Information leaks like passwords and credit card numbers from individual users of public clouds may have already happened with no trace of the security lapse.

Intel, Apple, Google, Amazon and others have pushed out operating system patches to counteract MDS attacks, but the only guaranteed way to prevent an MDS attack is to disable Intel’s Hyper-Threading Technology, which could result in a 25 to 35% drop in performance. While Google preemptively shut down hyper-threading on its Chromebooks, most other companies’ patches only upgraded their security parameters. Cyber threats like MDS attacks – which could result in massive data breaches of public clouds, where networked computers transfer and share data between millions of users — will become increasingly prevalent as hackers develop more sophisticated tools to tap into a richer tapestry of data.

One viable long-term solution is to use continuous, near real-time patches and microcode updates to combat this ever-evolving threat. Although continuous patching requires sustained effort and can frustrate end users who don’t want to have to reboot their computers, these barriers pale in significance when considered alongside the likelihood of a data breach that can cost millions and degrade customer confidence.

To achieve near real-time patching, organizations will need to take a different approach to updates. Developing a unique approach to systems, audit and support will enable greater agility and time-to-market for releases.

Design to tolerate outages

While designing systems and platforms for failure may strike IT folks as risky, it is far less risky than the consequences of a breach. Near real-time patching can be well managed with today’s centralized management and monitoring tools. As with a ship taking on water, it’s essential to seal off the compromised sections while plugging the leak. When systems and platforms are designed in such a way that outages are compartmentalized, they can continue to operate optimally when an outage happens. Solutions designed in this way enable automatic updates at a much higher frequency. It’s still possible to utilize a more traditional approach to testing updates, but it gets moved to a subset of the production infrastructure, and any issues are resolved before a wider rollout of patching.

Keep your eye on the ball

Successful implementation of continuous patching requires appropriate levels of observation. Consider the following minimum areas of coverage before automating patch rollout:

• Service availability: Measure of a system’s performance to deliver when demanded
• Application functionality: The set of functions or capabilities associated with computer software
• System and application errors: Occurs when an operating system halts, because it can’t operate safely
• Application performance: The performance and availability of software applications

By establishing baselines for each of these areas and creating an infrastructure that will sound the alarm when a given parameter exceeds its threshold, updates and other changes can be implemented more rapidly and with a reduced risk of issues.

Up-level your IT support

IT departments need regular processes to identify and manage the risk of new vulnerabilities. My cybersecurity team evaluates Common Vulnerabilities and Exposures (CVEs) for our operating systems, network devices, application software and embedded devices daily. With processes in place to escalate issues that impact the environments, we ensure awareness and timely response. Thanks to automated patching, we’ve reduced the number of escalations required by more than 90%.

Consider future risks

While public and private clouds often steal the limelight when it comes to MDS attacks, don’t overlook the impact on Internet of Things (IoT) devices. Intel chips power many smart devices and shutting down their hyper-threading to prevent an MDS attack isn’t an option. The 25 to 35% hit to performance isn’t feasible for IoT systems that are already running on modest computing power due to cost considerations and power requirements. With 75 billion IoT devices expected to be on the market by 2025, the next big hack could come via your Roomba or integrated manufacturing plant. Remaining vigilant with near real-time patching and microcode updates will need to be the norm to prevent actual harm.

The facts, opinions, and language in the article do not reflect the views of CISO MAG and CISO MAG does not assume any responsibility or liability for the same.

While there are several companies that are jumping on the cloud bandwagon, a lot of businesses are shying away from it as well. There are several myths due to which many companies think it is better to have data stored on-premises than over the cloud. We here take a look at five myths that surround cloud and cloud security while busting them.

1. On-premise security is better than cloud security

This is by far one of the most common myths about cloud security. Several companies still feel that on-premises data center and security is better than cloud security. But on the contrary, there are far fewer breaches on a public cloud while the breaches on on-premises overpower it on a gargantuan scale. Often, it is the glitches and configuration errors that lead to a debacle around the security of cloud buckets. Cloud is inherently safe by design. A recent survey from the Cloud Security Alliance showed that nearly 22 percent of respondents linked a data breach due to compromised credentials. One key area is to focus on Identity and Access Management (IAM) policy for cloud apps.

2. Accessing data in cloud is relatively easier 

In simple words, it isn’t. Several companies are moving toward cloud and major public cloud offerings have over time being sprucing up their security to an extent that having such defenses for small enterprises are a difficult and an expensive affair. Even with AWS buckets, the security teams from Amazon apply security policies for the entire cluster of containers by providing security to each pod. Even when you are trying to communicate or troubleshoot with the pod, the insight will stop traffic between the host and the cluster. There are reasons why AWS is the behemoth in the space, it is one among the most reliable ones out there. All you need to do is check all the boxes for any configurational glitches.

3. Cloud witnesses more breaches

This is another major myth. Like we have established above, the number of attacks on public cloud offerings are far less than the number of attacks companies and enterprises handle from several other vectors. Often times, cloud security deploys several firewalls and layers on both external and internal networks. The external layers protect the enterprises from threats like malware while the internal security layers prevent errors from the consumer level. There is also a belief among several cybersecurity leaders of large enterprises that storing data on-premises means better control and visibility, which is not often the case when the data is moved to cloud servers and containers, which is entirely a false claim.

4. Security is the job of a vendor

You have probably moved to the cloud to make sure that data management is easier and free of risk, not to make it even more complicated. But security must take your precedence. Your cloud vendor will surely try their best to make sure their buckets are configured well and you do not become a cause of vulnerability. At an organization’s end, it is important that you limit tour access to data and revoke access for employees with whom you have ended your business relationship et al. It is also imperative that you make sure employees are trained and are aware of threats emerging from the space.

5. Compliance is a difficult aspect while deploying cloud

The necessity for cloud adoption varies from company to company. And in most cases, the benefits of cloud computing depend on the kind of business the organization is. Just like with any tool, organizations ultimately must consider their risk profiles, staffing and access, resource allocation, and regulatory policies within the organization, and risk appetite before making a decision about cloud storage. Compliance should be a part of the ethos of companies. The scenario isn’t much different for cloud security as well.

What are the cloud security challenges that your organization is facing? Let us know by participating in this short survey. Click here to take the survey and get $20 off on CISO MAG’s subscription.

We at CISO MAG are set to publish the Power List, a comprehensive publication which will explore critical areas of cloud security while elucidating best practices to adopt for securing the cloud space. Ahead of it, we are discussing several trends and vendors in the space while we tell you what differentiates each product from the rest. To know more about it, click here: http://bit.ly/CISOMAGPowerList