Application-Centric Security

This blog contains some thoughts from earlier in 2021 about some shifts in the application security space. The following blog contains some newer thoughts about the shifts in the application security space. The intent is to speculate about how new tools and approaches may be changing how we do network security and the role of firewalls moving forward.

Let’s start with some context.

In May of 2019, my blog, Does Security Belong Near Endpoints? was posted. Here’s a brief recap:

Security in the form of stateful ACL enforcement may be shifting (or augmenting) to focus more on endpoints. Using a scale-out rather than a scale-up approach might help deal with firewall price/performance challenges.
Another point it discusses is that we might use firewalls with heavy-duty inspection and ALGs (Application Layer Gateways) at the Internet edge, where speeds are lower, and use switch-based ACLs (access lists) for simpler but high-speed segmentation internally. That is, use switch-based ACLs for high volume “East-West” traffic within a data center. Or shift to endpoint-based security.
A corollary to this that I’ve seen with SD-Access is that it uses the switching fabric to distribute intra-VN (intra-VRF) segmentation and policy enforcement. Fusion firewalls can then control inter-VN and user to server / Internet traffic. They are a traffic concentration point hence subject to loading. Endpoint-based security might be a way to avoid that!
One attraction of endpoint-based security is avoiding the potential for problems due to asymmetric paths through stateful devices (firewalls, some server load balancers / “application delivery controllers,” etc.).
One concern with endpoint-based security is that some devices, e.g., proprietary appliances or virtual appliances, or IOT devices, may well not support agent-based approaches. Also, there may be vendor-managed servers or VMs or other applications where support or other contractual issues preclude the installation of an agent.

Application-Centric Security

A Cisco blog about “applications on the move” points out that application mobility complicates traditional approaches to security. How can a security team hope to stay current as the application landscape evolves?

Within that context, Security that “moves with” an endpoint is definitely a lot more productive than security tied to a server/user’s physical location.

Desired Business Outcome: Simplify operations in a hybrid cloud world with mobile users via security that is not tied to server/application location so much as to the application itself.

One alternative I can think of is to have some way to auto-detect an application and apply enforcement on a switch port the application is “present” on. But that likely wouldn’t be stateful.

Security Close to the Application

The Cisco blog mentioned earlier is about moving security closer to the application.

As of CiscoLive 2019 (U.S.), Cisco is marketing “Application-First Security.” The rationale is “protection that is continuous, adaptive, and closer to the applications.”

Cisco has renamed Tetration as “Cisco Secure Workload” to make sure we’re all equally confused.

Products supporting this:

Cisco Secure Workload (to gather copious detailed flow and context information, and then provide endpoint enforcement via agents and scalable rule deployment)
Cisco StealthWatch Cloud (visibility and threat detection), and now SecureX as well
Duo (corporate vs. personal devices, control user access to applications)
AppDynamics (application performance monitoring)

There is definitely some attractiveness to Cisco Secure Workload’s built-in support for enforcement. And where necessary, support for third-party tools to generate and configure a policy on, e.g., firewalls.

I should also note, the Cisco Secure Workload product has come a long way from launch. Initially, the common reaction was, “I have to have the appropriate Nexus infrastructure and drop $1M plus on this. So this is a non-starter”.

Cisco has addressed that. There are now less costly variations of Cisco Secure Workload (see below) and multiple methods of getting information into Cisco Secure Workload, including agents. Lately, Cisco has been coming on strong with StealthWatch as a perhaps lighter-weight alternative (more or less) focused on visibility.

For more specifics, see the relevant Cisco At A Glance document for the product positioning.

Practical Experience

In revising these words, I’m having the thought that it all may come down to “pick your pain point.” Or more positively worded, “pick what will work best for you and your organization.”

NetCraftsmen has worked with and is working with several large organizations on various forms of security rationalization and/or tightening. This is sometimes combined with migration to firewalls from a different vendor.

Potential Win #1: Much better visibility.

Potential Win #2: (Cisco Secure Workload in particular). Building a policy in an automated form and then deploying it. That beats doing it manually. You still have to be careful not to break anything.

I think I’m hearing some common themes from our folks staffing those consulting engagements. No real surprises, but while these solutions are quite powerful, it is best to ease into them with a focused initial project, and also to plan on creating services labels and groupings up front.

Whether you are working with firewalls (and cleaning up rulesets), or other security approaches, you need information about the application flows. Cisco Secure Workload or StealthWatch or other tools get you that, don’t they?

It’s that simple! — NOT! You have to arrange the data feeds, ahem “telemetry” from devices to the tools, in order for the tools to be useful. Agents, NetFlow/IPFIX, etc. NetFlow can be painful if your code isn’t current, even for older Nexus/linecard combinations.

Similarly, for “micro-segmentation” with both Cisco ACI and VMware NSX, you need the flow information. But that’s just the starting point…

It’s that simple! — NOT!

Problem #1: Tracking down the application owner. You’re likely getting data, but it’s usually helpful to gather some information about the application, as in what other servers/apps it is supposed to be talking to, what its purpose is, what are the infrequent flows like, year-end reporting, etc.

Unless the organization has a service catalog of all applications and owners, tracking down the owner can be extremely time-consuming. Service catalogs seem to be very rare except in very large organizations, and even then, there’s always the question of whether the information is up to date.

Problem #2: Getting solid information about the application. Some (often, most!) applications were purchased, not developed in-house. The application owner may be the person that bought the application, or more often, someone who was assigned ownership and is the third such person after the initial application advocate. They sometimes know a lot about the application. More often, they know relatively little or provide suspect information. (Suspect facts? Are those better than fake facts?)

Problem #3: Incomplete coverage. NetFlow and other sources of actual flow data tend to be implemented piecemeal, with gaps often occurring right where you need data the most. Server agents, ditto. Most physical probes have portions of the data center they do not see the traffic for. Murphy’s Law applies. When you need to investigate something, it will involve the part of the network you don’t yet gather information on.

Problem #4: Grouping services and Application Dependency Mapping (ADM) is labor-intensive. In fact, everything about identifying flows and getting to policy is labor-intensive. Great benefit when done, but the labor up front needs to be expected as a cost.

Real World

Back to the real world … None of the above is intended to criticize the products, more noting that you had better budget some smart labor, and lots of it as well.

NetCraftsmen initially saw some increased customer interest in the Cisco Cisco Secure Workload product, among other products. And more recently, a big uptake on StealthWatch as well.

One factor may be that organizations are recognizing that the piecemeal NetFlow / expertise / owners-based approach is either not working or will take forever to finish. And just seeing the flows and some statistics is useful, but more analytical tools would be better.

One consequence is increased willingness to commit to agents on servers (yet another agent?), with the hope of actually getting agents onto at least 80-90% of the hosts.

Hardware or other forms of sensors can then address the sensitive or proprietary servers/VMs/virtual appliances. I see deploying comprehensive taps (Gigamon, etc.) as a costly approach, but spot use of them to fill gaps might be quite useful.

While Cisco Secure Workload is impressive, covering the application inventory is still quite a journey.

How To Do It

What we see in practice, and what Cisco is advising:

Prioritizing applications is important, especially when starting.
Management buy-in is key (Did I mention “agents”? And sufficient budget / reasonable expectations?).
Work on ADM (Application Dependency Mapping) but be willing to revisit and simplify.

Meta-lesson: Be it ISE, SD-Access segments, and user groupings, or Cisco Secure Workload service groupings, overly finely grained segments or security objects slow you down and can cause project failure.

My conclusion: do something useful but well-bounded (“start small”), then do it better, or in finer granularity! Drain a lake, not the ocean!

Leverage the automated whitelist generation capability in Cisco Secure Workload.
As with other mature security products, once you have policies, you can deploy them in monitor mode to see if any existing traffic would be blocked.
Once there is confidence that the ruleset is solid, you can switch to enforcement mode.
With StealthWatch, pick an expanding set of areas of interest to monitor. Make sure there’s an ROI for getting NetFlow deployed. Traffic levels on WAN or Internet links are often a good low-hanging fruit. (That is: “what’s eating up my bandwidth?”)

Follow on security activities:

Track normal server processes, spot anomalies, identify relevant software vulnerabilities, spot possible data exfiltration flows, …
Leverage AnyConnect NVM proxy sensor on user systems, smartphones, etc.

Admittedly, at one point in 2019 or 2020, I became a bit of a Cisco Secure Workload fan-boy. Justification: the Cisco Secure Workload team has pivoted and done some things I totally didn’t expect, and they seem to be adding value to the product quite quickly. I’m impressed!

On the other hand, more recently, sites doing StealthWatch seem to be finding fairly quick value in it. Especially by picking a do-able project for starting project, as noted above.

Competing Products

There is one competitor in the endpoint/application security space that I am aware of, Illumio (link included below). There are probably others.

My Google search turned up Cisco Secure Workload Competitors and Alternatives: VMWare NSX, GuardiCore, vArmour DSS, Trend Micro Deep Security, and others.

I don’t consider NSX to be in quite the same category — it assumes you’re running NSX everywhere, including the cloud. There’s the same problem with Cisco ACI. How desirable that dependency will vary with different requirement sets.

Personally, I see that security that is independent of the infrastructure automation platform as being highly advantageous. Independent modular functionality is usually a good thing.

Visibility

StealthWatch and SecureX also deal (to a degree) with the integration of non-Cisco tools to provide efficient Sec Ops.

Efficiency starts with seeing all the traffic that hits the network. But it extends to integrating that with other information and detecting malicious activity. This whole area of products and capabilities is in rapid flux. The more that a vendor can provide automation support (deploying NetFlow or agents, grouping flows, etc.), the better, as long as it expedites useful results.