New World, New Rules: Securing the Future State

I published an article today on the Oracle Cloud Security blog that takes a look at how approaches to information security must adapt to address the needs of the future state (of IT). For some organizations, it's really the current state. But, I like the term future state because it's inclusive of more than just cloud or hybrid cloud. It's the universe of Information Technology the way it will be in 5-10 years. It includes the changes in user behavior, infrastructure, IT buying, regulations, business evolution, consumerization, and many other factors that are all evolving simultaneously.

As we move toward that new world, our approach to security must adapt. Humans chasing down anomalies by searching through logs is an approach that will not scale and will not suffice. 

Here's an excerpt:

If you never change tactics, you lose
the moment the enemy changes theirs

While chasing down a domestic terrorist, FBI Agent Will Brody found himself in an unfamiliar and dangerous environment. (Brody is the protagonist in Marcus Sakey's 2017 novel Afterlife.) To survive in its perilous conditions, its residents commit to two simple rules: (1) pull your own weight and (2) only kill in self-defense. These rules have kept them safe from the obvious imminent threats around them for decades. But Brody sees a change happening in the environment that others don't yet see and warns his new community: "If you never change tactics, you lose the moment the enemy changes theirs." His mantra becomes "New World, New Rules." In other words, you must adapt to changing threats or face the consequences.

As Information Security professionals, we find ourselves in a similar situation. Our environment is transforming rapidly. The assets we're protecting today look very different than they did just a few years ago. In addition to owned data centers, our workloads are being spread across multiple cloud platforms and services. Users are more mobile than ever. And we don’t have control over the networks, devices, or applications where our data is being accessed. It’s a vastly distributed environment where there’s no single, connected, and controlled network. Line-of-Business managers purchase compute power and SaaS applications with minimal initial investment and no oversight. And end-users access company data via consumer-oriented services from their personal devices. It's grown increasingly difficult to tell where company data resides, who is using it, and ultimately where new risks are emerging. This transformation is on-going and the threats we’re facing are morphing and evolving to take advantage of the inherent lack of visibility.

Organizations are in varying stages of migration toward this future state of IT where we have massive distribution and where visibility is elusive. But we all seem to be moving in the same direction. So, we simply can't live by the same old rules. We can’t rely on old security techniques. New World, New Rules.

The old SIEM approach won't suffice
in the future state.

Traditionally, security professionals have relied heavily on SIEM (Security Information and Event Management) solutions to track activity in their environments. The SIEMs resided somewhere on the network and collected logs and event information from other network-connected systems and devices. SIEMs measured themselves by their ability to ingest data from anything and everything on the network. But SIEM users have struggled to translate that event data into actionable intelligence. In many cases, because of the enormous quantity of event data and the inability to parse it quickly and efficiently, SIEM solutions became forensic tools; used after-the-fact to research what may have happened after a breach was detected. The old SIEM approach won't suffice in the future state.

Although many organizations report struggling with the complexity and cost of SIEM solutions, the SIEM market continues to expand. This is because the need for visibility has only grown more urgent with increasing regulations and more aggressive and sophisticated attack techniques. But you want more. Traditional SIEM approaches aren't enough. There simply aren't enough hands-on-deck to rely on manual processes for investigating event data or identifying on-going attacks.

The technologies that have exacerbated the
problem can also be used to address it

Here's the good news: The technologies that have exacerbated the problem can also be used to address it. On-premises SIEM solutions based on appliance technology may not have the reach required to address today's IT landscape. But, an integrated SIEM+UEBA designed from the ground up to run as a cloud service and to address the massively distributed hybrid cloud environment can leverage technologies like machine learning and threat intelligence to provide the visibility and intelligence that is so urgently needed.

Machine Learning (ML) mitigates the complexity of understanding what's actually happening and of sifting through massive amounts of activity that may otherwise appear to humans as normal. Modern attacks leverage distributed compute power and ML-based intelligence. So, countering those attacks requires a security solution with equal amounts of intelligence and compute power. As Larry Ellison recently said, "It can't be our people versus their computers. We're going to lose that war. It's got to be our computers versus their computers."

But to effectively secure the future state, you need more than a SIEM designed for cloud. Here are a few other innovations that we should demand from our security platform:

• Application Topology Awareness: Detect multi-tier application attacks and lateral movement indicators. Alert application owners not server administrators.
• Threat Stage Awareness: Map potential and in-progress threats to well understood attack stages to provide better contextual data on how to respond. See developing threats before they happen.
• Data-Deep Visibility: Detect data access anomalies for any user, database or application.
• Broad Data Capture: Don't rely solely on security logs. Leverage operational logs, threat feeds, embedded reputation data, and more.
• User Attribution: Report the identity even if the user context is missing via composite identity awareness and rich user baselines.
• Configuration Change Awareness: Inject configuration drift context into threat detection.
• Orchestration: Respond to threats immediately and with precision via REST, scripts, or 3rd party automation frameworks.

Obviously, we're writing about this for a reason. These features are built into Oracle's Security Monitoring and Analytics service (SMA). When we say that our SIEM was designed from the ground up for cloud, we're not just talking about the product architecture. We're talking about its features and functionality. It was designed to address the complexity and peril of distributed cloud environments. It was designed to secure the future state; to be the new rules for the new world.

SMA is built on Oracle’s unified platform for future-state security that also includes Identity, CASB, and Configuration Compliance. It was built 100% in the cloud to address the security needs of hybrid, multi-cloud environments. Traditional SIEMs lack Identity, CASB, and Configuration Compliance functions. And they typically only layer UEBA on top of their legacy SIEM architecture. They lack advanced features like data-deep visibility, user attribution, orchestration, and awareness of threat stages and application topology. Leveraging these innovations, Oracle's approach enables shorter investigations and faster response times while accommodating for all the complexity of the future state.

Oracle simplifies management and
security for the future state.

And, to top it off, Oracle's security services are built on Oracle Management Cloud which, in addition to security, provides a single pane of glass for IT monitoring, management, and analytics. Oracle simplifies management and security for the future state, reducing cost and effort, and providing richer intelligence across increasingly complex environments.

Learn more about how Oracle is addressing these security concerns and incorporating machine learning into adaptive intelligence by reading our whitepaper, "Machine Learning-Based Adaptive Intelligence: The Future of Cybersecurity."

Access Governance on Unstructured Data

Gartner research VP Earl Perkins posted a few days ago on the intersection of data and applications within IAG (Identity and Access Governance). I've certainly seen the same issues and we've been working with customers on these challenges quite a bit over the past six months. In fact, I authored a paper on the topic in April which is available in the STEALTHbits resource library titled Access Governance on Unstructured Data.

I hinted at the paper back in February and it was clear from the response I got that many are not willing to acknowledge a shift from the era of Identity Management to the era of Access Governance. But, I still see our current Access Governance efforts (as an industry) as analogous to what we did about a decade ago for Identity Management. Obviously, the industry remains dynamic and there's overlap but I think we have a pretty good handle on managing accounts while we're still working on the best ways to provide governance over access (whether to applications or data).

In my own phrasing (and ignoring structured and semi-structured data for the moment), the issue Earl addresses is, essentially that traditional IAM and IAG solutions are application-centric but a significant portion of enterprise data is unstructured (many estimates indicate that 80% of data is unstructured) rather than accessed and controlled via applications. IAG vendors are struggling with getting their arms around data as it sits out in the environment. And it's a hard problem.

I've been a part of two software vendors who addressed access rights to unstructured data. Neither company nailed it in the first attempt and there were challenges along the way. I've spoken with three large companies who tried to build in-house solutions for themselves. All failed and eventually sought commercial solutions. And I've spoken to IAG vendors who struggle with unstructured data solutions - even having tried popular brand name commercial solutions with unsatisfactory results. In my paper, I point out many of the challenges (platform coverage, geography, scalability, deployment, etc.) and how we've addressed them.

The one item that I'd differ on in Earl's post is that he mentions IAG vendors as looking to partner with SIEM and/or DLP solutions to address the issue. I don't think either is a good fit. SIEM is obviously event-driven and relies on logs. It may answer a piece of the question but it's not a direct fit. Even where it does provide value (who is doing what), it's data is limited to what shows up in logs, which isn't ideal for this scenario and doesn't generally enable context-based filtering.

And DLP may get much of the right information but the folks I've talked to describe it as overkill (too expensive and too difficult to deploy). Where DLP seems to shine is in the actual prevention (blocking action at the end-point or at the firewall). But for a quick, efficient scan of access rights and the ability to analyze high-risk conditions, I'm not sure you can bend DLP solutions to do what you need.

I'd love to discuss more with anyone interested. Let me know. I can also get you a copy of the paper. It's short and to-the-point, but is a good conversation starter.

Rule-Based Log Correlation: An Alternative Approach

In an article at SYSCON Media, Gorka Sadowski writes about SIEM technologies and specifically about the complexity of event correlation.

Why Rule-Based Log Correlation Is Almost a Good Idea: The Future of SIEM

He points out that there are some challenges with static rule-based correlation. But, he calls it "the engine for the first generation of [SIEM]". That sounds about right. What scares me is that the future solutions to which Sadowski alludes look even more complicated. So, there may be a trade off to get the perceived increase in value.

I have an alternative solution that simplifies things for the SIEM. Over the past few years at NetVision, we've had a number of organizations interested in the NVMonitor solution (now called StealthINTERCEPT) because of its advanced filtering and from-the-source event collection. It doesn't rely on logs and enables a highly advanced ability to filter events as they happen eliminating the need for after-the-fact correlation.

For example, when looking at Active Directory Security Group events, you can return only changes to high-risk groups or changes to business-line groups that are not made by a specified subset of users (even if they may be a domain administrator). These events are pre-filtered and sent to the SIEM only when appropriate. It can also block events, btw, and send the event to the SIEM as an "attempt" rather than an actual event. And of course, it has it's own alerting and response mechanisms built in for real-time, contextual response.

Improved data collection on key source systems may be a better alternative to mathematic modeling from the event archive. Perhaps not in every case, but on core security infrastructure like Active Directory where rules are definable and today's challenge lies in the ability to implement, it's not only better, it's here today and already proven in production environments.

Implication of Cisco MARS decision on SIEMs?

Notice the question mark first. I'm interested in what you think this means. This isn't me trying to make any great claims.

Cisco has acknowledged that it will stop adding support for additional devices on its MARS SIEM platform. While the plan is to continue providing updates for already-supported devices, it's difficult to argue that this isn't a strategic move toward completely dropping support for the product (in it's current form).

I, of course, wanted to use a title like "The END of SIEM", but it's hard to make that leap given that one of the biggest SIEM players was ranked among Deloitte's 2009 Technology Fast 500 with over $100 Million in revenue for 2008. And ArcSight has shown 32%, 34%, and 25% year over year growth in its last three quarters respectively.

Still, Cisco is thought to be the most widely deployed SIEM with over 4000 installations. For them to make a strategic move to discontinue addition of future platforms means (and read this with your favorite accent) something doesn't smell right in Denmark.

As I speak to organizations about NetVision (and we are clearly NOT a SIEM player), I hear concerns about SIEM tools and log management applications that are big, complex, difficult to implement, expensive, and not user-friendly. I have nothing against SIEM tools or the role they play. In fact, many of our customers integrate our product with SIEMs. ...which is why the topic comes up. But, I've been wondering if the fire-hose approach to data collection is proving to be too much. i.e.) too much data and too much complexity given the problem at hand.

I sense that the SIEM approach is troublesome and that SIEM vendors who can't adapt to changing market expectations for more readily available answers will start making announcements like Cisco's indicating that they won't be around forever continuing to support an ever-growing number of devices. There will likely continue to be a market for large scale event data collection into the foreseeable future. I'm not arguing against that. But a segment of the market seems to be defining itself as a group that wants easy answers in lieu of a data flood.

Am I reading too much into it? What do you think?

NetVision - Actionable Intelligence

When I last wrote about SIEMs and Actionable Intelligence, I promised to tell you how NetVision sees the problem. ...post available at the NetVision blog:

Actionable Intelligence

Actionable Intelligence the Achilles Heal of SIEM

Today, I watched the fourth in a series of video discussions moderated by Richard Stiennon on various security topics. This one was focused on ESM (Enterprise Security Management) and SEM (Security Event Management). I combine the acronyms as 'SIEM'.

The panelists (Amrit Williams, Martin McKeay, and Mike Murray) covered a number of aspects of ESM-SEM solutions. My one line summary conclusion of the discussion is that:

SIEM's are not able to effectively correlate information and provide actionable intelligence.

A few of the supporting statements:

Murray: They lack the ability to "take data and pull information out of it"

Williams: The problem "can't be solved in a centralized way." The only way SIEMs would meet their goal is via "cooperation, communication and cognizance distributed out so the agents are essentially communicating with each other and responding to events that are being provided to each other" "I've talked to customers that are 18 months in and still can't get it properly deployed"

Murray: "there are vendors out there that you still have to manually setup every agent... the cost is staggering"

McKeay: "when I think SIEM, I think glorified log management"

Williams: "rarely are these things being used to detect and respond to incidents in real time... the market driver [...] is compliance... it is unfortunate"

McKeay: "it comes down to being able to understand your own environment... it's the definition of the problem that we don't have yet"

The consensus seemed to be that vendors do a good job of gathering and storing logs to meet compliance requirements that mandate storage of those logs. What customers really need and want from these vendors, however, is actionable intelligence.

Williams concisely defined the goal of information security:

"to limit the possibility of an incident from occurring... and when it does occur, to limit its impact (by identifying it quickly and responding)"

He continued "...what the ultimate goal of an intelligence system would be is that it's able to detect what are seemingly innocuous events and provide some actionable level of intelligence that shows that that's actually an incident occurring and you can respond to it and limit its impact on the environment - that's what they'd like to be, but they're not that"

Murray added that customers want the solution to "just tell me the five things I need to do - that's what SIEMs should do"As an industry, we're "really good at generating reams of data, but we're not very good at handling information... turning it into 'here's the 5 things'..." SIEM tools are great if "you have defined the problem that you're trying to solve and you know what the information is that you're trying to manage and you can setup a way to manage that."

It was a really interesting discussion. I've enjoyed each of the video discussions in this series so far which have also covered DLP and Firewalls/IPS.

Next, I'll tell you what NetVision is doing about the problem. We're not a SIEM vendor, but we beat the SIEMs to the finish line of actionable intelligence. Actionable Intelligence has been our internal mantra for the past year or so and it is the motivator behind our latest solution to market (as well as a few that are still on the road map).

Better data from Active Directory for your SIEM

If you Have or are Planning to Have:

• A SIEM solution (ArcSight ESM, RSA enVision, Novell Sentinel, IBM TCIM)
• An enterprise Log Management solution (LogLogic, TriGeo, SenSage)

And your employees log on to:

• Microsoft Active Directory / Windows
• Novell eDirectory / NetWare

And you're unhappy with the solution's ability to:

• Get complete information from the directory or file system
• Filter which information is collected
• Generate highly relevant alerts based on filtered event data and custom policies
• Collect event data directly from the source (independent of system logs)
• Apply decisions or alerts based on WHO is performing the action
• Report on ANY combination of objects and attributes in the directory
• Report on who is opening or modifying files, folders, or file system permissions

THEN ...Please give us a call.

I recently wrote a paper discussing how we (NetVision) extend the ability of SIEM or log management solutions by getting better, more reliable, and more relevant information directly from what is arguably your most critical source (the network directory). The paper isn't publicly available (it's not that kind of paper). So, let us know and we'll pass it along or we can save you the trouble of reading and just explain it.