Presented at
AppSec USA 2017,
Sept. 21, 2017, 1:30 p.m.
(45 minutes).
Writing secure code is not as glamorous as releasing the next cool feature. However, we know that fixing security vulnerabilities in production is hard and costly. In order to have a more secure application it is important to consider what makes an application secure from the start during the design phase. But what security requirements make sense? How can a security organization track whether the multitude of applications are adhering to application security best practices and known secure states? How does a development team prioritize all the security requirements?
Driving uniformed security requirements across a large company can be no small task. Many development groups write security requirements guided by regulation or industry standards for their specific application that are not seen by other development teams or the security organization. Further difficulties arise from teams that are dispersed using different tools and processes. Acquired development organizations that are accustomed to different processes pose their own challenges. The sum of these items leads to a siloed approach to writing and tracing security requirements complicating efforts by the security organization to understand how applications are developing secure code.
With the OWASP ASVS, a set of verification statements can be used to create a list of functional and non-functional requirements and controls that an application can adhere to in order to maintain a secure posture for their risk tolerance. Our Application Security team used the verification statements from the ASVS and created a set of security requirements, controls, and technical design decisions that our applications can use in their normal Scrum process as they would for feature development. The Application Security team also provides a priority ranking on each of the work items in order to assist the application in prioritizing the work.
Our team developed a modified version of the open source Google VSAQ in order to present our applications with a questionnaire that determines the ASVS level that an application should strive toward. This questionnaire will ask questions related to the type of features and functions that the application may have in order to identify the tasks that the application needs to complete to meet that ASVS level. In some cases, the application may use a third party or another internal application to handle the functionality that is listed in the ASVS giving the development team the ability to opt out of some security requirements. For instance, the user authentication may be a module developed by another application as in the case of an SSO enabled application.
As with most projects, creating new processes and procedures for something specific like security requirements can create turmoil and outright revolt among the consumers of the new process. So bringing a set of uniformed security requirements to an established organization requires working within the existing process. To this end we are utilizing current internal requirements tracking, enhancement tracking and testing tools as a way to reduce reluctance to the new project. Through this already defined process security tasks can be viewed and treated as any other type of development tasks. This allows the security organization to see which applications are adhering to the controls, which ones are not, which controls are the most challenging across the application base, and follow the work through the lifecycle using standard reporting.
Test plans can be written using the ASVS verification statements as they are or as a guide to a more specific test plan. To verify that the requirements have been met by an application, the test plans will be mapped to the requirement in a requirements tracking tool.
Secure development does not need to be painful or difficult. In this talk I would like to show how an organization can apply the ASVS to their Software Security Life Cycle to create more secure applications. Working with a ready baked set of security requirements and methods of validation takes the ambiguity out of creating security requirements and makes them more consumable to development teams. The OWASP ASVS provides the guidance to that prepared set of requirements that can be used in an already established software development life cycle.
Presenters:
-
Derek Fisher
- Application Security Manager - Cerner Corp
I have nearly 20 years of experience in both hardware and software engineering. I have spent the last 5 years in an Enterprise Security role as a developer, an architect and an application security manager where my team provides security services to our development organization. These services include vulnerability management and remediation, assistance with secure code analysis tools, threat modeling, risk evaluation of development features, and driving the secure software development life cycle across development.
I have been the lead architect on some of the more exciting security projects in our organization, including projects related to HTTPS and certificate management. I lead a weekly meeting of security architects that meet to discuss and review security topics impacting our industry and applications.
Becoming the application security manager in the Enterprise Security organization has given me the opportunity to work with our development organization to discover opportunities for improvement and engage in many different parts of the engineering space from design to delivery. Because of this visibility, I have spent the past year working on how our development organization can leverage the ASVS in our software development life cycle. This has required me to navigate the various nuances of our culture, process, and operating procedures in order to understand where and how the ASVS can be used to deliver more secure software.
Links:
Similar Presentations: