A quick glance back at the biggest cybersecurity incidents of 2021 tells us two things, according to NetFoundry CEO Galeal Zino: secure access service edge (SASE) has proven effective at securing user-to-app communications and it’s not enough to keep the threat actors out.
“All the major 2021 attacks, they’ve not been between the user and the app, they’ve been what I would call below the waterline of the iceberg, server to server, webserver to database, every single one of them,” he told SDxCentral.
That’s not to say SASE isn’t necessary or isn’t effective, Zino said. “It’s just that it’s not sufficient.”
The problem is there are still plenty of avenues by which attackers can exploit enterprises’ existing infrastructure and development environments, he explained. SASE might protect the application front-end, but the app’s underlying dependencies, databases, and APIs are still vulnerable to attack. Addressing this requires moving “security into the heart of the development cycle.”
Zero Trust at the Application, API Layer
The platform works by closing all inbound firewall ports to the application and then deploying a series of lightweight, containerized routers, which control the flow of traffic between application components like the front-end and back-end database or between the application and an external API.
These routers only accept connections between workloads if they are properly identified and authorized based on least privileged access. This ensures that only workloads that are specifically meant to communicate with each other are able to, dramatically reducing the attack surface in the process, Zino said. “This app server needs to talk to that database, it doesn’t need to talk to anything else.”
You can think of it a little like a toll road where at every exit and onramp there’s a toll booth operator checking your identity and determining whether the traffic is allowed to be there. This means that even if an attacker manages to get a ransomware shell script onto the network, it’s effectively quarantined because it can’t phone home to load its payload and even if it could, it couldn’t move laterally across the network, Zino explained.
“At the end of the day, what we’re trying to do is make the business case really, really expensive for the attacker,” he said. “The reason we’re struggling today is the business case for the attacker is really good. It’s just too easy… If you make the business case expensive and time consuming and prohibitive, they’re going to go elsewhere.”
The API Security Challenge
For internal deployments, implementing Ziti is relatively straightforward. The platform can be deployed at the device level via a container or virtual machine, or at the application level via the Ziti SDK.
Where things get tricky, Zino explains, is when customers want to implement the technology on services they don’t control, for example, API integrations with third parties.
To take advantage of Ziti, API providers need to integrate the company’s SDK. And while NetFoundry has seen some buying from private API providers, it’s been a slow road when it comes to the public providers, Zino admits.
One example of a company using Ziti for its private APIs is Ozone. The integration ensures secure communications between the application delivery vendor’s control plane and its customer’s Kubernetes environments.
The NetFoundry has taken steps to minimize the effort required to integrate the technology at the API level.
“We’ve done our best to make it turnkey,” Zino said. “Most common web apps have a fairly common framework for addressing the network for passing the packets down towards the driver or the virtual NIC,” he said. “Our code is just a wrapper around that.”
“That’s exceptionally attractive for these folks, because it means that they don’t need to ask people to put clients or agents on devices,” Zino added.
See the original from here.