Firewall

The traditional firewall is dead or at the very least dying.

Cloud and hybrid environments, mobile access, and online applications have made it all but obsolete, experts say, and data center operators should be looking at replacing their firewalls with more granular security technologies.

Applications and data used to live in data centers and be delivered from there to employees who were themselves on a corporate network with a desktop on a static IP address.

“Even when off-site, they were VPNing into the network,” said Michael Beesley, CTO at Skyport Systems.

That’s not true anymore. Today, applications can live in cloud and hybrid environments or be delivered via websites by external services providers. Employees and customers access them, often via the web, from wherever they happen to be.

That means the firewall can’t see what’s going on, where the connections are coming from, or where they’re going, while the IP addresses change all the time or are obscured by content delivery networks like CloudFlare.

“The firewall becomes blind,” he said.

Meanwhile, the traffic that used to be distributed among many different ports is now all concentrated on port 80 and 443.

“I think we’re approaching a tipping point where out of necessity enterprises are going to adopt a different approach with regard to how they secure themselves,” Beesley said. “The empirical data is that in a hybrid environment the firewalls are not doing their job. Infrastructure needs to evolve to a zero-trust environment rather than trying to secure it from a networking point of view.”

Then there’s the encryption issue.

According to Google, 79 percent of traffic in the Chrome browser is currently encrypted.

“The browser is what killed the firewall,” said Ryan Spanier, director of research at Kudelski Security. “Because you had clients asking for things on the internet, and the firewall wouldn’t stop a thing.”

With encrypted traffic, all the firewall knows is the source and the destination of the traffic, and now that everything is in the cloud, even that doesn’t tell you much. “There’s not a lot of room for the firewall anymore,” he said.

According to a survey released this month by network security vendor Ixia, 88 percent of respondents said they experienced a business-related issue from a lack of visibility into public cloud data traffic.

Finally, there’s the transformation of application development from monolithic to microservices. Enterprises have moved from running applications on dedicated servers to virtual machines to containers, each time dramatically increasing the number of endpoints that need to be protected while simultaneously accelerating the rate at which new ones are spun up and shut down.

Given we cannot rely on network security or firewall to protect our services, then what is the solution? Unlike the old world you have monolithic applications, if you have hundreds or thousands of microservices deployed in the cloud with some well known interface like REST, then everyone can access it if there is no authentication or authorization.

In Light, we are moving the security to the application itself as part of the framework and all each individual service instance to enforce the security policy defined on light-oauth2 server. In another words, centralized policy management but decentralized policy enforcement.

The reason all vendors trying to provide commercial offering for secuity are based on the network layer is due to lack of knowledge on the application itself or lack of access to the application.

As we build the security handler as a middleware handler and wire it into the request/response chain of your service, it intercepts the request and have the clear text data as TLS termination is done already. It can make the decision on if the request is authorize or not based on two different layers of security.

Technical Layer of Security

This layer of security is based on OAuth 2.0 and is the same for all kind of services regardless the business domain. It is implemented in the light-4j and related frameworks and ready to be plugged in. It uses JWT tokens and validate if the client_id in the token has access to the service and if the scope in the token has access to the endpoint it is calling. So the authorization level is at the endpoint level in this layer.

Business Layer of Security

The is the next layer of security after the technical layer and it must be run within the business context. If the previous layer of security is passed and the request has access to the endpoint like fund transfer, there are certain authorization rules that need to be executed in order to authorize the request. For example, if original user is just a teller, he/she can only transfer less than $10K, if the user is based at Asia, then he/she cannot transfer out fund for customers based at America.

As you can see this layer of security is business related and cannot be handled at technical level in a generic way. In Light, we are providing a generic handler framework and our customers can fill in the business rules to define fine-grained authorization.