The most common problems in secure application development and deployment are uncertainty about dev and ops responsibilities, deployment and outdated enterprise security policies, according to Owen Garrett, head of products for NGINX. Under pressure to build and deploy software quickly, it’s easy for one side to think the other has done needed security tasks. Secondly, enterprises need to revamp security policies to fit the rapid development and deployment model. Do these two things well and app teams can work at maximum velocity and still have full visibility into and control over security.
In this interview, Garrett explained which secure software app development tasks belong to either dev or ops, as well as the security risks with containers and developing microservices.
Hackers today have sophisticated tools, like hacker cloud services. What tactics can DevOps teams take to deal with these more sophisticated tools?
Owen Garrett: In DevOps, developers and the operations team each need to play to their strengths. They need to coordinate to make sure that, between them, all of the necessary security measures are properly covered in a standard way.
First of all, developers should follow good application security practices when architecting applications. That involves coding defensively. So, assuming that all incoming input – so, in NGINX speak, that's all network traffic -- assume that it's potentially attack traffic and build the application so that it's very defensive in the way that it handles requests. And often what's necessary to do that is to follow a pattern when you build a facade in front of the application. And that facade exposes a very simple version. It exposes just the APIs you need to be consumed externally, and then it translates those to the richer, internal APIs. Secondly, developers must follow good principles, like minimum privilege [and] minimum data.
What are some of operations' responsibilities in defending against hackers?
Garrett: The operations team must take responsibility for standards like authentication or encryption or certificates. Take those off developers so they don't need to worry about those, and put those in the hands of subject matter experts on the ops team.
The operations team needs to build an environment that is robust and reliable -- one that allows them to identify security issues and respond to those quickly. For ops, good practices include deploying a load balancer or reverse proxy devices with security scanners to ensure that all incoming traffic has to go through those entry points, making sure there are no ways around those entry points.
What is a common result of poor coordination between developers and operations teams in secure application development?
Garrett: The result is usually unsecured or untracked interfaces to their applications. These appear to be commonly exploited or explored as a way to try and find a way around the primary security for an application. When a complicated application is deployed online, it's often comprised of many different components, and it may be possible to bypass security measures for some of those components. It can be very challenging for the security team to know all about the entire envelope they need to protect.
Would you say that there are different, worse or better security situations for DevOps teams developing microservices?
Garrett: It's a very different security situation with microservices for a couple of reasons.
One reason is that microservices tend to be used because organizations want to iterate and deploy applications very, very quickly. And when they're doing very, very quick deployments, then that can compound the security challenge because you can't afford to run lengthy security procedures against every single deployment. So that's one challenge to consider.
Another challenge to consider is that if an individual microservice were to be exploited in some way, then that could provide a gateway into the entire application. So it's very important to track and manage all of the traffic coming in, to control which microservices can be directly addressed by external parties and to focus on them with your security efforts to ensure that they are very, very difficult to compromise and they have limited privileges should they be compromised.
Owen Garretthead of products, NGINX
With microservices, the temptation is to make many of your services externally accessible via APIs. And if those services haven't been designed with security in the first place, then that's a very, very risky decision. So it takes discipline. The facade pattern where you build a wall in front of your application that exposes safe, security-audited, managed APIs, and then you have the chaos and the validity of the microservices application behind.
How does using containers impact secure application development?
Garrett: That’s quite similar to the anarchy that's created with microservices. Just as microservices allow developers to push out functionality much more quickly, containers allow [DevOps] to deploy code more quickly. In many cases like this that I’ve seen, corporate security standards bypassed to ensure speed.
Part of the rationale for using containers is that each individual component has its own operating environment. So, if it needs a different version of an operating system library or a different framework, then that can be achieved by putting that in the container. But the risk is then that the developer might build an application that contains components that don't meet the internal security standards. Maybe they use components that haven't been vetted or have known bugs. Maybe they’re not using secure containers.
There's a growing body of thought around how you need to audit and track the software that's deployed within the containers to make sure that those meet internal architectural standards of quality and reliability, of supportability.
What are enterprise architects' main responsibilities in creating and maintaining secure application development and deployment policies and supporting architectures?
Garrett: Building security into the architecture for an organization's application is the most important part of secure development and deployment. This is the deployment architecture, so architects must create a safe environment for the application to be deployed in.
Safety requires full visibility of the traffic coming in. Also, you must be able to correlate unexpected application behavior with that traffic. If it fails or users lock the CPU, you can correlate that with requests and have the ability to then control that traffic. So, you must be able to apply rate limits or block particular requests, if you determine these are bad for the application. You must be able to manage all of the traffic coming in and to apply those rules.
Build an architecture, an environment, where you can deploy the application, and then you can control, and track and monitor how it's behaving. Within that architecture, you can provide actionable information to developers if you see an anomaly or an error. If you build it well, that takes some of the onus off the developers to focus on the architectural areas of security.
Meanwhile, the developer, of course, has to continue to focus on classic security issues -- things like injection attacks, or insecure object references or poor passwords. If you’ve focused on the infrastructure first and created an environment where you can control and secure the traffic, secure development and deployment is easier -- not easy, but easier.
Why citizen developers play key role in secure app development
Think DevSecOps when securing apps
Take these steps for secure microservices development