When it comes to application security, network administrators need to think differently about web applications.
Web applications are typically secured by external controls, like web application firewalls and load balancers. Administrators do their best with legacy tools that are not designed for securing today’s apps when, really, the best way to secure a web app is during the development cycle.
But there is a problem – friction. Development and security teams have competing priorities.
The Development and DevOps teams are resistant to anything that slows down a code project. But Security and SecOps need to secure web applications. Their methods are sometimes intrusive and can feel like roadblocks to productivity. In some cases, the DevOps teams sometimes use unapproved processes and tools to skirt security requirements. This rogue attitude puts the application and the environment in which it runs at risk.
On the other hand, the Security and SecOps teams feel that the Development and DevOps teams don’t appreciate the importance of compliance and app security. Actually, everyone knows it’s important, but some make it a lower priority, preferring to focus on meeting milestones.
Other problems are more technical in nature.
For example, vulnerabilities in web applications usually occur at the code level, or as a result of improperly written code. Those types of vulnerabilities are not always easy to identify.
Application architectural design plays a role, too. Modern web applications are open and distributed. They’re more like multiple applications communicating with one another, with lots of interactions between application programming interfaces and services, as well as endpoints and devices. This approach clearly has its benefits, but it also creates more attack surfaces – more points of entry for malicious actors – and those attack surfaces often evolve.
A few things need to happen to overcome team friction, code vulnerabilities and inadequate security tools.
First, the development and security teams need to come together on security — they need to form a partnership in which both teams understand how security aligns with the development life cycle. And they need to agree to cooperate. With strong cooperation, when one team is successful, so is the other.
Second, comprehensive code security reviews are needed. And timing is important. It’s best to review code for security gaps once the architecture behind the code commit has been properly reviewed. By code commit, we mean when changes are saved to the source code in a repository.
It’s also important to review code when new features are added or anything significant changes. A change in one part of the code can affect code downstream, so another review helps to ensure security hasn’t been broken.
Finally, invest in tools designed for securing modern web applications and their attack surfaces. As long as you rely on legacy tools, you are leaving yourself vulnerable. Today’s web servers and cloud-based application delivery platforms run collections of tools for both developing and securing web applications.