Ok, so maybe it's not the definition that's the problem. Maybe it's the fact that most people think of DAST and SAST when it comes to application security. And when most developers are faced with DAST and SAST, they run for cover.
Or maybe it's the fact that most security practices are primarily focused on the perimeter - there is a certain comfort that comes with control or the illusion of control that one gets when the network is protected. Along with the perimeter focus, there is also a huge investment in authentication, authorization, encryption, etc. - application security is just not front and center.
I think there are many reasons why application security is narrowly defined or reluctantly used by developers, but what I'd like to touch on in this post is why application security has to change to stay relevant. And, I'm hoping that this will be genesis for conversation at the BlackHat USA 2013 conference this week in Las Vegas.
Here is my Top 10 list for today - what am I missing, what do I have wrong?
- Agile / DevOps is the new game - While I try to avoid the buzzword of the day, it's important to note that 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 - Ok, 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 re-usable components, and they assemble their applications vs. 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 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 - and 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. And 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 additional 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 you do, and chances are 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 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. Why? 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, 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.
Let us know what whether these topics came up at Black Hat - and let us know what you takeaways were from the conference or the conference coverage.
