Application Security: Focus on flaws, not on bugs


September 3, 2013 By Derek Weeks

I recently listened to Gary McGraw’s interview on the Trusted Software Alliance Website. One thing he said (among many) that captured my attention was work that Cigital is doing on architecture risk analysis. Gary noted that security defects can be the result of bugs or flaws. “We pay more attention to (application) bugs and we need to focus more on (design) flaws”.

I’ve also had several recent conversations that relate to Gary’s comments:

  • In discussing the state of the application security market, Ryan Berg noted: “we don’t have a problem finding problems, we have trouble fixing them”.
  • In discussing the DevOps role in delivering trusted software quickly, Curtis Yanko talks about the need to “shift things left”. Shifting problem discovery earlier in the development process or better yet, preventing problems in the first place, can help expedite the development process.

We’ve done a lot of work in our solutions to help the security team guide the developers at the beginning of the development process – the developer can select optimal components based on security, licensing and architecture policies. Selection of optimal components eliminates problems that have to be fixed later. This “shifts activity to the left” and relates to Gary’s push to spend more time focusing on security during the design process.

In addition to selecting optimal components early in the development process, what other security design approaches can be used to ensure that design flaws are minimized? We plan to start a dialogue with Gary and Ryan – feel free to join in – but a good place to start is with BSIMM and OWASP.

BSIMM has several objectives and activities that relate specifically to security design:

  • Among other things, the Strategy and Metrics practice addresses the planning, sponsorship, success criteria, and “marketing” support needed to drive security success.
  • The Security Features and Design discusses the role of architecture, the need to inject security into the architecture group, the role of reuse, the use of approved security features and frameworks, and the practice of secure-by-design principles.
  • The BSIMM also addresses the need to create security standards, address compliance constraints as requirements, and the use of secure coding standards.

The OWASP Secure Application Design Project addresses the need to give equal attention to “Secure Design”, vs. focusing on “secure coding”. OWASP provides a methodology to be followed for design reviews. Security requirements are determined by doing a design study and design analysis that addresses things such as data flow/code layout, access control, etc. The security requirements result in design change recommendations that are discussed with the development team and included in the finalized design.

Stay tuned for more as we discuss how to consider security in the design process of today’s agile, component-based applications.

 

  • Mindyourbusiness person

    thanks for highlighting that…