It’s been about a year since I first met the co-founders of Edgewise Networks, Peter Smith and Harry Sverdlove. The excitement I felt when Peter first described the Edgewise vision still resonates. I remember pushing my chair away from a conference room table, looking at Peter, and saying something like, “Well, that certainly needs to be built!”
We’re hiring now at Edgewise, so I get to relive that excitement a few times per week as I talk to candidates for our ever-growing engineering team. As I have those discussions, I see candidates experience the same reaction I did a year ago: “Well, that certainly needs to be built!”
Every time I speak with security practitioners—be it at conferences like RSA Conference 2018 last month or during my regular conversations with industry colleagues—I see and feel that same excitement play out. Each time I explain zero trust security and what we’re building here at Edgewise (based on the idea of zero trust), it is almost as if a light bulb emoji pops up over people’s heads. I love that a-ha moment when people come to understand how Edgewise can simplify and strengthen their operational security.
The use case that makes me, personally, most excited about Edgewise’s products is the one that hits closest to home. I’ve worked in engineering at SaaS and Cloud companies since before we called them “SaaS” and “Cloud.” In every case, I worked as part of the team that built and deployed the software; some other group always managed the network, including network security policy. With network security policy out of my control, and usually out of my line of sight, it meant that I frequently sacrificed control and predictability for security. It’s not that I didn’t care about security, but it wasn’t part of my workflow. Someone else was responsible for making sure that the software was traveling securely through the network. This wasn’t optimal, but it was the best we could do at the time, and it worked OK in on-premises networks of 15 or 20 years ago.
Adapting to today’s networks
Today’s software development life cycle, though, needs to account for the dynamic nature of networks, even ones not managed by the company building and deploying software (i.e., cloud). Retrofitting network policies to deployed software isn’t effective, which is why Peter and Harry dreamt up Edgewise, and what keeps me excited today. Our ZT Advise and ZT Protect products protect servers and workloads for our customers. We visualize network traffic, propose policy to reduce attack surface, and ultimately protect network paths by allowing only cryptographically validated applications and processes to communicate on the wire.
What’s cool about this is that it lets us zero trust all the things.
In a production network of any size and complexity, traditional network security policy is unwieldy, controls are insufficient, and the combinatorial problem presented by multiple apps, interfaces, hosts, and containers makes the problem extremely convoluted and costly, at best. The dark art of configuration management (and the insidious drag-along mess of “change control boards”) is a compensatory measure for this problem but hardly solves it.
Imagine a world where your security policy is not controlled by IP address and port but by an application’s fingerprint. Only verified applications can talk on the wire, they can only do so when they’re in the environment where you expect them, and they can only talk to their and cryptographically verified dependencies.
In that world, you deploy policy once, segment your topology once, and deploy software into it forever.
That's where Edgewise ZT Protect comes in.
ZT Protect lets development teams deploy software into a network where policy is already in place, managed in the Edgewise platform, and implemented on each host by Edgewise agents.
What this means for me is an easier, more predictable life, with no compromise in operational security:
- No more late night firewall changes.
- No more change control board.
- No more untested rollback plans.
- No more getting paged because someone else blocked a port on a firewall without understanding what was talking on that port, or why.
Simplifying security further
We’ve just released a set of features that allows us to apply zero trusty policy to collections of apps and hosts. I’m excited about it because it gives us a user-defined abstraction layer that can be used to provide fine-grained control over what apps (on which hosts/containers) participate in policy. In practice, this means that I can move my software releases through our pipeline—from Dev to Stage to Prod—using predefined security policy to make sure that our software can talk over network paths we approve, and if we choose, that only our software can talk on those paths.
As a result, software lands in Prod fully protected. Only my ingress nodes can receive traffic from the public internet. My data processing tier can only listen to my ingress nodes, and can only talk to my microservice data processing tier. My data tier is only exposed to the containers, hosts, and apps that legitimately need access. My system—the dozens of disparate components that make up the Edgewise cloud—is locked down, even while we’re continuously deploying new builds into it!
This will only get easier through the summer. With a full backlog of integrations (including the ability to control collection members directly from your pipeline via an API hook to Jenkins), our growing feature set will make life easier for people like me, and safer for software like ours (and probably like yours too).
That’s what gets me excited. And that use case will only improve as we continue to build product here at Edgewise.
(And oh yeah, did I mention we’re hiring?)