Application Security: 10 Reasons It Must Change to Remain Relevant
Application Security: 10 Reasons It Must Change to Remain Relevant
by Darryl K. Taft
Agile/DevOps Is the New Game
The traditional waterfall development and delivery approach is (or should be) a thing of the past. Agile and DevOps approaches are driven by a real business need—to reduce the cycle time between the inception of an idea that will drive the business and delivery of that idea in reliable software. If application security is not re-thought in the context of scrum development methods, continuous integration and continuous delivery, application security will become even less relevant and successful than it is today.
Open-Source Usage Continues to Expand
You are probably thinking "Yes, I know that Linux, MySQL, are being used. And, my developers are also using a bunch of open-source tools to help manage the development process," but I'm not talking about infrastructure or tools, I'm talking about open-source components that are used to build today's applications. Thankfully, developers have turned to reusable components, and they assemble their applications, versus writing source code from scratch. Why create your own Web framework, logging mechanism, etc., when you can turn to components and frameworks from open-source projects? But, the usage of these components needs to be managed, or you will introduce security, licensing and quality issues into your applications.
Security Professionals Need to Be Audience-Aware
There is much written about how chief information security officers (CISOs) need to communicate with the executive staff and board using their language. They simply won't care about techno-babble, or specific exploits. The CISO must communicate in the language of the business. Translating security strategy and implementation approaches into business risk or the bottom line of the business is a must to be effective. But I don't see a similar focus on communication with the development team. Instead of talking at the development team, the security team needs to learn their language, learn the development process, etc. Then, they need to communicate using developer language and deliver solutions that fit their needs.
Security From the Start Needs to Be a Reality
OK, here is another concept that is certainly not new. Plus, some organizations have achieved some success by factoring security in early, defining nonfunctional requirements as part of the design stage. (OK, and nonfunctional has to be the worst term ever when it comes to software engineering.) While this is a start, this approach needs to be modified so that it works in an agile, DevOps-based environment. Also, security considerations should be integrated into the entire software lifecycle—design, optimal component selection, trusted build and deployment, and full production support.
Security Tools Need to Promote Action
For application security to be truly effective, it has to move from delivering reports plagued with false positives to driving actions directly in the tools that developers and related constituents use. Forcing developers and others to learn a new tool, or to deal with a new set of reports, especially if the information adds more work or is delivered late in the development lifecycle, is not acceptable. And the approach to deliver information without recommended actions needs to be replaced with guided and/or automated remediation built into the tools they use today.
Applications Can't Be Contained Within a Perimeter
Although server, network and other security approaches are still necessary, applications can no longer be contained behind a perimeter. This is driven by the business factors, such as partner ecosystems, and by the need to communicate and service customers more effectively. And it's exacerbated by the proliferation of technology that makes sharing and communicating easy—Internet, mobile, etc. The application has become a common exploit target, and protecting the application with a perimeter is not enough.
Compliance Efforts Are Gaining Steam
Even if you are not in a regulated or compliance-driven industry, you are not immune from compliance efforts. Do you process credit cards? Do you store customer demographic data? Chances are that you do, and chances are that you have compliance efforts that you need to address—even if they are only internal. Your compliance efforts have to evolve so that they meet how today's applications are developed and delivered. This is evidenced by the introduction of A9 in the Open Web Application Security Project (OWASP) Top 10 that addresses the reality of component-based development.
Security Should Not Be an Island
This relates to some of the other items, but the security team has to be integrated. A great opportunity is to do this in the context of DevOps. Although the initial focus of most DevOps efforts is to improve the process of moving new functionality or enhancements into production in shorter and more successful cycles, DevOps is about driving collaboration between those involved in the software lifecycle. Proactive security professionals should jump in now; they should look to expand DevOps to DevSecOps/DevOpsSec.
Approval-Based Mechanisms Will Fail
All too often, we want to fall back on a system of checks and balances, or processes that are driven by gates and approvals. While this approach has a place, if you take this approach when your organization is leveraging components to build applications, short agile-based delivery style, continuous integration and deployment, then you will either stop the process or force developers to work around the process. This will happen even if you automate the workflow process because no process can scale to meet the volume, complexity and version frequency of the components that are used to build applications. And traditional approaches that rely on a locked-down, or golden, repository of components will also fail, and your developers will find a workaround.
It's About the Software Supply Chain
This is a great place to end, because in a sense, thinking about the software lifecycle as a software supply chain is a good metaphor for many of these considerations. It allows us to extend the concept of lean manufacturing that has been an inspiration for agile development, and it reflects the fact that today's software applications come together not solely from internal efforts. Software components flood in from many "suppliers," and if your security approach does not accommodate this, well, good luck explaining to your executive team or to your auditors that you can't track the source of the breach because you don't have visibility into that part of your software supply chain.