The software engineering community is slowly beginning to realize that information security is also important for software whose primary function is not related to security [1]. Since prevention is often more economical than remediation, empirical security knowledge such as common attacks and vulnerabilities are made public and available for practitioners through web-based portals such as NVD [2], CWE [3], OWASP [4]. Security standards, such as PCI DSS [5] or ISO [6] provide high level guidelines and impose several compliance requirements to application developers.
In reality, software analysts, developers, and testers are overwhelmed with the amount of available information and variety of tools they can employ. Analysts are given massive lists of security requirements, guidelines, and standards, and they need to provide tangible and audit-able evidence that the products comply with security guidelines. Employing tools can help application testers. However, security testing tools are usually intimidating and their adoption rate is low, specially because application developers and testers are not often security experts. Testers also need to tailor the testing scripts for the platforms and technologies that they use.
The bottom line for practitioners is finding the relevant body of information to their projects. However, there is a significant gap between the existing body of empirical knowledge collected in (web-based) knowledge portals and actual development demands.
To fill the current gaps, we introduce a secure application development management tool, called SD Elements, which provides a set of core values to application developers, system analysts, and quality assurance teams.
SD Elements is a web-based knowledge repository of security guidelines, empowered by a retrieval tool. SD Elements surveys users to learn about the nature of the project, platform, language, and technologies, and then it tailors security knowledge:
-Generates relevant security requirements.
-Provides tailored guidelines on secure architecture design. SD Elements focuses on vulnerability prevention instead of detection. It integrates security knowledge into the development life cycle, thus, security is built into the application from the early phases. SD Elements provides a compliance mechanism, i.e., users can trace which guidelines are employed, implemented, and tested. This provides businesses with tangible and traceable evidence for audit purposes. Finally, it provides requirements, implementation, and testing guidelines, in situations that compliance with PCI DSS and HIPPA is needed.
SD Elements users will be software developers such as requirements analysts, programmers, testers, project leaders, and security analysts. For each project, SD Elements surveys the developers about the nature of the project, security features and users of the application, types information being handled by the application, business drivers and policies, platforms, technologies, programming languages, and application interfaces. By collecting these information about the project, SD Elements retrieves a customized set of guidelines and requirements, appropriate for specific projects.
For example, application general questions (Figure 1) uncover the type of application, type of web server, programming languages, platforms, third party technologies and libraries. The survey also enables users to provide more details about the features and functions of the project. For example, developers can specify whether the application being developed involves interactions with operating system, file-upload function, authentication of end users, etc. The answer to the questions enable the tool to refine the rest of questions as well as retrieve relevant security guidelines and requirements. These guidelines in the SD elements knowledge base are developed according to:
-Current vulnerabilities for different technologies, platforms, and languages.
Each guideline or requirement corresponds to a vulnerability in Common Weakness Enumeration list of vulnerabilities [3].
-Best practices and existing standards such as OWASP [4], WASC threat classification [7]; empirical data about commonly-exploitable applications in web applications based on years of penetration testing; threat models, and source code review; and regulatory compliance including PCI DSS, HIPPA HITECH, GLBA, NERC CIP, and international privacy laws.
SD Elements' knowledge storage and retrieval is based on Boolean logic. The knowledge retrieval engine provides security guidelines, based on what users has specified. For example, if users select a J2EE project, then SD Elements concludes the user will be developing a web application that is probably multitiered, etc. Thus it does not require overwhelming efforts for users and project owners to describe the nature of project for receiving useful information. Project managers can get security guidelines as well, without knowing much of technical details.
-Surveys analysts about the project settings.
-Generates a list of relevant security requirements (in different categories) which are tailored with respect to the project settings. -Links generated requirements to relevant vulnerabilities.
-Links the generated requirements to a design/implementation guidelines and test cases. -Lists the requirements criteria of acceptance. These criteria are actually the test cases. Thus, analysts will know from the early stages, how the requirements will be tested.
SD Elements provides project-specific implementation guidelines. Suggested guidelines correspond to the list of security requirements and settings of the project. Sample (and tested) code, whenever applicable, is provided as part of the content. For example, for the HTML encoding for JSPs, SD Elements provide a sample code as depicted in Figure 3. Figure 4 shows an example list of development guidelines in the authentication category. Test cases are linked to security requirements, and user can specify a test is passed. Then, the requirements status is changed (to satisfied) as well. Figure 5 shows a screen shot of a sample test case.
Incremental survey: The survey section of the tool can be answered gradually and incrementally, i.e., the more questions answered by the user, the more specific and accurate guidelines are retrieved by SD Elements.
A Traceability System: Users can trace which guidelines they have applied, which ones are not applicable, and which guidelines are outstanding. Applicable guidelines and implementation standards can be added to bug tracking systems and generated requirements can be imported to general requirements documents such as PDF and doc files.
4 Beta Test Plan SD Elements will be in beta test in a variety of sectors, such as energy, independent software vendors, healthcare, and financial services. It will be mostly championed by application security managers and development team leaders. The beta tests will help us investigate various aspects of real world application of SD Elements. By the end of the beta test phase, we will have concrete data to evaluate usefulness and usability of SD Elements in real world practice.
Various web-based software vulnerability knowledge bases provide a shared and standard way for identifying, specifying, and measuring software weaknesses and vulnerabilities. Common Weakness Enumeration (CWE) [3] provides a unified, measurable set of software weaknesses for enabling effective discussion, description, selection, and use of software security tools and services that can find these weaknesses in source code and operational systems. National Vulnerability Database (NVD) portal provides a search engine over the Common Vulnerability and Exposure (CVE) and Common Configuration Enumeration (CCE)
databases. However, these knowledge portals usually lack specific guidelines to prevent the introduction of vulnerabilities. The burden of identifying relevant vulnerabilities in the massive lists of these portals is on developers. SD Elements solves these issues by providing customized guidelines for preventing CWE vulnerabilities.
The need for security guideline customization has been addressed in another tool called TeamMentor [8]. TeamMentor only provides two layers of guidelines filtering: 1) technology and 2) role of the user. Thus, still a massive list of guidelines without specific categorization is provided to the user. A link between the suggested guidelines for different phases of life cycle is not considered, thus traceability is not possible. Project specific features and functionalities are not used to generate the list of guidelines, and still software developers can become overwhelmed with the large list of guidelines.
SD Elements is a web-based security knowledge base that provides security guidelines for different development life cycle phases. The main goals of SD Elements is to build security into the application, from the early phases of the life cycle. The outstanding contribution of SD Elements is tailoring the guidelines according to project description. SD Elements helps businesses provide tangible security audit evidence and trace compliance with security standards.
The results of the beta tests will help us investigate whether by applying SD Elements, more vulnerabilities are actually prevented. In future releases, SD Elements will be customizable to different domains and businesses. End user administrators will be able to add their own questions, answers, and content items so that they can support any technology stack. Also, we will continuously add more content, thus SD Elements will work as a subscription service rather than a single tool.