Application Security: 10 Reasons It Must Change to Remain Relevant

 
 
By Darryl K. Taft  |  Posted 2013-08-22 Email Print this article Print
 
 
 
 
 
 
 
 

Application security needs to be redefined to stay relevant, Mark Troester, director of product marketing at Sonatype, a provider of component-based software development products, wrote in a recent blog post. Troester lists 10 reasons application security must morph to remain relevant. With Sonatype's blessing, this eWEEK slide show covers Troester's assertions. He notes that maybe most people think of dynamic application security testing (DAST) or static application security testing (SAST) when it comes to application security and that developers avoid this. Or perhaps because security practices typically lie at the perimeter and not at the center of things, it is not viewed as a central issue. "There is a certain comfort that comes with control or the illusion of control that one gets when the network is protected," Troester said. "Along with the perimeter focus, there is also a huge investment in authentication, authorization, encryption, etc.—application security is just not front and center."

 
 
 
  • Application Security: 10 Reasons It Must Change to Remain Relevant

    by Darryl K. Taft
    1 - Application Security: 10 Reasons It Must Change to Remain Relevant
  • 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.
    2 - Agile/DevOps Is the New Game
  • 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.
    3 - Open-Source Usage Continues to Expand
  • 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.
    4 - Security Professionals Need to Be Audience-Aware
  • 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.
    5 - Security From the Start Needs to Be a Reality
  • 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.
    6 - Security Tools Need to Promote Action
  • 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.
    7 - Applications Can't Be Contained Within a Perimeter
  • 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.
    8 - Compliance Efforts Are Gaining Steam
  • 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.
    9 - Security Should Not Be an Island
  • 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.
    10 - Approval-Based Mechanisms Will Fail
  • 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.
    11 - It's About the Software Supply Chain
 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
Rocket Fuel