What they’re talking about is the same concept of “intent” that’s being applied in software-defined networking (SDN) circles. Also known as the declarative model, intent is a way to simplify and automate network operations. It lets operators use normal language to tell the network what they want, leaving the network devices to configure themselves accordingly.
This would represent “the next step past SDN, where all the orchestration and policy is in place, but you can speak business language to the Fabric,” says John Maddison, Fortinet’s senior vice president of products. (He’s referring to the Fortinet Security Fabric, a combination of the company’s security products.)
But intent-based security isn’t quite the same as intent-based networking. Security differs from networking, in that “the security system really cares about the full state of a connection for its entire existence,” says Marc Woolward, CTO of vArmour.
Illumio got the jump on RSA, announcing in January the ability to tweak access control lists (ACLs) in Cisco and Arista switches and to support security groups in Amazon Web Services (AWS) and Microsoft Azure.
Here’s some of the other intent-based talk that was going around at the conference.
Fortinet’s Future Fabric
Fortinet, which has a broad portfolio and an installed base to deal with, plans to develop intent-based security in stages. “It’s going to take us a few years to get there even in a simplistic way, but we’ll get there,” Maddison said.
That timeframe comes partly from Fortinet’s ambition; its plans include creating the business language for communicating with the business architecture.
That would be the final step. For now, Fortinet has taken the initial step of improving network visualization. The FortiOS 5.6 software release, announced in January, lets operators see how elements such as switches, firewalls, and email systems are interconnected. It can also recommend changes; it might spot a node that’s out of compliance with regulatory rules, for instance.
Fortinet is also building APIs to include other vendors’ gear in FortiOS’ visualization capabilities, creating a more thorough picture of an enterprise’s security landscape.
Maddison said the next step would be to build in some automation — the ability to apply a policy that distributes itself across the fabric. After that, the company hopes to develop the language for communicating intent to the infrastructure.
Other vendors have already begun developing automation for their intent-based architectures. That’s the case with vArmour, which has a couple of years’ worth of experience shipping its Distributed Security System (DSS), which applies microsegmentation to the network and enforces the appropriate policies.
The company was recently awarded a patent for a way to link containers to a predefined set of security templates, so that containers could be created with security policies attached. That should make it simpler to apply policy to microservices even as those services change, Woolward said.
Going a step further, vArmour has been working on a way to compute policies based on what’s been happening in the network. It’s not unique; Illumio can do this, as can Cisco with its Tetration product, Woolward says.
By observing a sample of network activity, vArmour can figure out what’s there — it can tell which node is a web server or a database, for instance — and build graphs of the rules being applied in that environment. From there, vArmour calculates a zero-trust policies for the network. (This compares particularly well with Tetration, Woolward says, because the graph is lightweight, whereas Tetration records all activity in the network.)
It’s a machine-learning process, and it’s not perfect. A lot depends on the timing of DSS’ network scan; it might not notice the existence of standby servers, for instance. It’s meant to create a policy for humans to check.
This policy computer returns a numeric rating for the network’s security and can update that number in response to tweaks, letting developers try out what-if scenarios. That can be a motivator. “As soon as you publish your code coverage numbers to developers, the numbers go up. Human nature, right?” Woolward says.
Containers and Intent
Intent and containers are a natural fit, because containers, which house an application along with dependencies such as libraries, “know exactly what processes they’ll be running,” he says. “We can look for what the developer meant to run.”
Security could, for instance, build a whitelist of permitted activities “based on what we can tell from the design” of the application, Bernstein says. For example, if a container includes Ubuntu, MongoDB, and configuration code, it’s probably hosting a database.
Even if a container isn’t built from pieces — if the application inside was freshly written — the container format tends to make it easier to discern the developer’s intent. Simplicity is a factor here; containers are meant to be immutable, and they leave out functions such as DNS that are important but aren’t directly part of the application, Bernstein notes.
More generally, Bernstein sees the rise of intent-based security and networking as a logical next step for the cloud. The public cloud is already declarative as far as developers are concerned; they ask AWS or any other provider for CPUs and storage, and they get it, without having to muck with configuration details.
It’s a declarative model that Bernstein sees spreading as the cloud’s role grows.
“Developer is cloud. I believe developer and the cloud will become one and the same,” Bernstein says.