C706 - CHAPTER 5 -- DESIGN AND DEVELOPMENT (A3)

Design & Development (A3) Stage A3 Policy compliance analysis Security test plan composition Static Analysis Threat model updating Design security analysis and review Privacy implementation assessment During this phase, any policy that exists outside the domain of the SDL policy is reviewed and might include policies from outside the development organization that set security and privacy requirements and guidelines to be adhered to when developing software or applications. What is this phase? -Policy compliance analysis -Policy compliance assessment -Policy requirements assesment -Policy compliance review Policy compliance analysis A3 policy compliance analysis is a continuation of the A2 policy compliance review. During this phase, any policy that exists outside the domain of the SDL policy is reviewed. These might include policies from outside the development organization that set security and privacy requirements and guidelines to be adhered to when developing software or applications. One element of security testing is to identify software weaknesses in order to avoid security violations and noncompliance with security requirements that could cause the software to fail or be out of compliance with any of software security requirements. (True or False) True False True One element of security testing is to identify software weaknesses so that security violations and noncompliance with security requirements that could cause the software to fail or be out of compliance with any of software security requirements are avoided. The following are common steps that can be used to implement a test plan regardless of the strategy, framework, or standard being used: Define test scripts. Scripts are very detailed, logical steps of instructions that tell a person or tool what to do during the testing. Functional testing scripts are step-by-step instructions that depict a specific scenario or situation that the use case will encounter as well as the expected results. Secure testing scripts are scripts created specifically to test the security of the application. The basis for these scripts comes from the threat models that were generated during the design phase. Misuse cases define what needs to be protected (assets) and what types of attacks can gain access to those assets. Secure test scripts define the acts of carrying out those attacks. Define the user community. Defining the user community helps testers identify acceptable levels of failures and risk. Identify the showstoppers. Defining the must-haves and the "what-if-available" scenarios should be in the use case. If not, a revisit to the requirements might be necessary so that these specifications can be documented. Identify internal resources. Internal resources come from the company's organization, including developers, analysts, software tools, and sometimes project managers. Identify external resources. External resources are tools or people who are hired on a temporary basis to come into a project, test the application, and report findings. External resources are best suited for security testing because they typically come highly trained in secure programming techniques and they are far removed from the code and any internal politics. If external resources are needed, the test plan needs to answer the following questions: (1) What are they going to test? (2) To whom will they report? and (3) With whom will they be working?2 Software security testing techniques can be categorized as white box, gray box, or black box: White Box White box. Testing from an internal perspective, i.e., with full knowledge of the software internals; the source code, architecture and design documents, and configuration files are available for analysis. Gray Box Gray box. Analyzing the source code for the purpose of designing the test cases, but using black-box testing techniques; both the source code and executable binary are available for analysis. Block box Black box. Testing the software from an external perspective, i.e., with no prior knowledge of the software; only binary executable or intermediate byte code is available for analysis.7,8 Source code analysis (white box) Source-code security analyzers examine source code to detect and report software weaknesses that can lead to security vulnerabilities. The principal advantage that source-code security analyzers have over the other types of static analysis tools is the availability of the source code. The source code contains more information than code that must be reverse-engineered from byte code or binary. Therefore, it is easier to discover software weaknesses that can lead to security vulnerabilities. Additionally, if the source code is available in its original form, it will be easier to fix any security vulnerabilities that are found. Property-based (white box) Property-based (white box). Property-based testing is a formal analysis technique developed by the University of California Davis. Property-based testing validates that the software's implemented functionality satisfies its specifications. It does this by examining security-relevant properties revealed by the source code, such as the absence of insecure state changes. Then these security-relevant properties in the code are compared against the software's specification to determine if the security assumptions have been met