Software Security and Quality Assurance (SSQA) Gate 3 Guidance

Software Security and Quality Assurance (SSQA) Gate 3 Guidance

[NIAF-SSQA-G3G] Understanding the Final SSQA Assessment Gate

Compliance and Data Protection Department

First Published: October 2018 Last Updated: August 2020

1.1 Public

of 42

Title: Software Security and Quality Assurance (SSQA) Gate 3 Guidance Version: 1.1 compliance.qcert.org Classification: Public

DISCLAIMER The implementation of the Software Security and Quality Assurance (SSQA) Controls are required as part of the State of Qatar’s strategy to enhance cyber security. Risk, particularly in information systems, cannot be completely removed through the implementation of controls. It is for this reason that the implementation of the controls identified within this standard, while required to improve the quality and security of software development activities, cannot substitute effective risk analysis and risk management practices which should continue to be practiced by all Agencies.

of 42


LEGAL MANDATE(S) Emiri decision No. (8) for the year 2016 sets the mandate for the Ministry of Transport and Communication (hereinafter referred to as “MOTC”) provides that MOTC has the authority to supervise, regulate and develop the sectors of Information and Communications Technology (hereinafter “ICT”) in the State of Qatar in a manner consistent with the requirements of national development goals, with the objectives to create an environment suitable for fair competition, support the development and stimulate investment in these sectors; to secure and raise efficiency of information and technological infrastructure; to implement and supervise e-government programs; and to promote community awareness of the importance of ICT to improve individual’s life and community and build knowledge based society and digital economy. Article (22) of Emiri Decision No. 8 of 2016 stipulated the role of the Ministry in protecting the security of the National Critical Information Infrastructure by proposing and issuing policies and standards and ensuring compliance.

This Understanding the Final SSQA Assessment Gate has been prepared to take into consideration the current applicable laws of the State of Qatar. If a conflict arises between this document and the laws of Qatar, the latter shall take precedence. Any such term shall, to that extent be omitted from this Document, and the rest of the document shall stand without affecting the remaining provisions. Amendments, in that case, shall then be required to ensure compliance with the relevant applicable laws of the State of Qatar.

of 42


REFERENCES • [IAP-NAT-DCLS] National Information Classification Policy • [IAP-NAT-IAFW] Information Assurance Framework

• [NIAF-SSQA-S-SSL1] – SSQA Level 1 Software Security Standard • [NIAF-SSQA-S-SSL2] – SSQA Level 2 Software Security Standard • [NIAF-SSQA-S-SSL2] – SSQA Level 3 Software Security Standard

of 42


Table of Contents Introduction ................................................................................................................................................................ 7 Scope ............................................................................................................................................................................ 8 Purpose ........................................................................................................................................................................ 8 1. The SSQA Gate Assessments ..................................................................................................................... 9 2. The Testing and Pre-Deployment Control Gate................................................................................ 10 3. Pre-Gate Activities....................................................................................................................................... 11

3.1. Conduct Testing .................................................................................................................................. 12 3.2. Integrate Security into Established Environments or Systems ......................................... 13 3.3. Assess System Security ................................................................................................................... 14 3.4. Review Operational Readiness ...................................................................................................... 15 3.5. Perform Configuration Management and Control ................................................................... 16 3.6. Conduct Continuous Monitoring .................................................................................................... 17

4. Applicable SSQA Controls .......................................................................................................................... 18 5. Expected Inputs ............................................................................................................................................ 38 6. Expected Outputs ........................................................................................................................................ 39 7. Stakeholders .................................................................................................................................................. 40

7.1. Database Administration Group .................................................................................................... 40 7.2. Developer ............................................................................................................................................... 40 7.3. Implementation Manager ................................................................................................................. 40 7.4. Integration Manager .......................................................................................................................... 40 7.5. Project Manager .................................................................................................................................. 40 7.6. Project Sponsor .................................................................................................................................... 40 7.7. Testing Lead ......................................................................................................................................... 40 7.8. Testing Team/Tester ......................................................................................................................... 40

8. Legacy System Considerations ............................................................................................................... 41

of 42


Introduction The State of Qatar’s Software Security and Quality Assurance (SSQA) framework, forming part of the National Information Assurance Framework (NIAF), is implemented to promote the enhancement of security and quality within software development projects and eServices. The introduction of security related controls into the Software Development Lifecycle (SDL) stages enables the development of a Secure Software Development Lifecycle (SSDL), ensuring that security is considered throughout all stages of systems development. To support the NIAF and as part of the National Information Security Compliance Framework (NISCF), the Ministry of Transport and Communications (MOTC) has developed a certification process for eServices that relies upon successful assessment across three assessment gates to validate the implementation of the SSQA controls provide quality assurance.

of 42


Scope This guidance is provided for all Agencies, engaged in the development or implementation of software systems and for outsourced partners developing or providing software to, or on behalf of agencies.

Purpose This guidance document describes the activities necessary leading to the completion of the Design phase of the system development, highlighting relevant SSQA controls, desired project artefacts and key decision points.

of 42


1. The SSQA Gate Assessments The SSQA Gate process forms part of the Ministry of Transport and Communications (MOTC) assurance processes. Such processes are often referred to as phase-gate or stage-gate processes which allow for decision points (known as gates) which assist with mitigating the risk of development activities proceeding without appropriate oversight and consideration of key controls. At each gate, an evaluation is performed by the National Information Security Certification Team (NISCT). The evaluation is based upon information available at the time, from project related documentation and the evidenced fulfilment of relevant SSQA control requirements observed by an accredited auditor. Accredited Auditors (as chosen by constituents) will evaluate systems at defined lifecycle stages to assess the organization’s implementation of relevant SSQA controls and to review documentation and evidence developed by the constituent to assure the security conscious development of eServices. As constituents become more familiar with the SSQA framework and the gate processes implemented to build assurance into software development activities for eServices, it is likely that common (or standard) artefacts (or resources) will be created as a matter of course. The assurance gates are not designed by nature to prevent or inhibit the development of software systems and eServices. The intent however is to ensure the consideration of security throughout development activities and provide direction and oversight, supporting the achievement of secure development practices.

of 42


2. The Testing and Pre-Deployment Control Gate The objective of the Testing and Pre-Deployment assessment is to ensure that the system has been installed and evaluated within the organization’s operation environment prior to being brought into operations. Prior to this assessment gate, the system should be installed and evaluated in the organization’s production environment. When all necessary security arrangements have been completed and satisfied through testing, and plans are established for configuration and continuous monitoring, authorization to go-live can be granted and the system can become part of operations. Following the authorization of go-live and the integration of the system into operations, the system should be periodically assessed to determine how the system can be made more effective, secure, and efficient. Key security activities for this phase include:

• Integrate the information system into its environment, • Plan and conduct testing of security controls, • Conduct an operational readiness review,

• Manage the configuration of the system, and, • Institute processes and procedures for assured operations and continuous monitoring

of the information system’s security controls. Operations continue if the system can be effectively adapted to respond to an organization’s needs while maintaining an agreed-upon risk level.

of 42


3. Pre-Gate Activities Prior to assessment, it is assumed that several core project activities will be completed that help to evidence the consideration of security throughout the development process and support effective project governance. In relation to the Transition and Testing stages, the following activities should be completed prior to the gate assessment:

• Conduct Testing (Functional and Security), • Integrate Security into Established Environments or Systems,

• Assess System Security, • Review Operational Readiness, • Perform Configuration Management and Control, and,

• Conduct Continuous Monitoring.

of 42


3.1. Conduct Testing The objective of in-development testing and evaluation is to validate that the developed system complies with the functional and security requirements. Testing of security controls is based on technical security specifications. Following the completion of testing, it may be necessary to update solution security requirements, solution architecture and existing risk assessments. 3.1.1. Outputs

• Documentation of test results, including any unexpected variations discovered during testing.

3.1.2. Notes Only test, “stub”, “synthetic” or “dummy” data should be used during system development. Absolutely no operational, security-relevant, or personally identifiable information (PII) should reside within any system or software during development.

of 42


3.2. Integrate Security into Established Environments or Systems System integration occurs at the operational site when the information system is to be deployed for operation. Integration and acceptance testing occur after information system delivery and installation. Security control settings are enabled in accordance with manufacturers’ instructions, available security implementation guidance, and documented security specification. 3.2.1. Outputs

• Verified list of operational security controls, and, • Completed system documentation.

3.2.2. Notes Issues encountered during installation should be evaluated for inclusion into the contingency plan based on the potential for reoccurrence and the Software Security Group (SSG) should review the installed system to ensure that controls are in place and properly configured. Following the integration of the system into the production environment the test and development environment should be cleaned, ensuring the removal of all test data. Extreme care should be exercised when integrating information systems into operational environments or systems so that critical operations are not disrupted.

of 42


3.3. Assess System Security Systems being developed should be formally assessed prior to go-live. The objective of the security assessment process is to validate that the system complies with the functional and security requirements and will operate within an acceptable level of residual security risk. Prior to initial operations, security testing should be conducted to assess the extent to which the controls are implemented, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the system. In addition, periodic testing and evaluation of the security controls in an information system must be conducted to ensure continued effectiveness. In addition to verifying security control effectiveness, security testing may uncover and describe actual vulnerabilities in the information system. The determination of security control effectiveness and information system vulnerabilities provides essential information to facilitate credible, risk-based security accreditation decisions. 3.3.1. Outputs

• Security Assessment Report. 3.3.2. Notes Security Assessment results should be shared with the major stakeholders (including) the system owner, the Software Security Group (SSG), the Project Sponsor and developers (as well as system administrators). Assigning a core team of representatives from the major stakeholders to meet throughout testing will assist in communication and reduce surprises.

of 42


3.4. Review Operational Readiness Many times, when a system transitions to a production environment, unplanned modifications to the system occur. If changes are significant, a modified test of security controls, such as configurations, may be needed to ensure the integrity of the security controls. This step is not always needed; however, it should be considered to help mitigate risk and efficiently address last-minute surprises. 3.4.1. Outputs

• Evaluation of security implications due to any system changes. 3.4.2. Notes When an application is enhanced or changed, regression testing helps to ensure that additional vulnerabilities have not been introduced. For example, adding source code can often introduce errors in other areas and may negatively impact existing and stable functions. Changes that include additional data fields should be noted and analyzed to determine if the security posture of the system has degraded or introduced a need for additional controls. Ensure users are adequately trained on security awareness and practices for the new IT system prior to deploying the system in a production environment

of 42


3.5. Perform Configuration Management and Control An effective configuration management and control policy and associated procedures are essential to ensure adequate consideration of potential security impacts resulting from changes to an information system or its surrounding environment. Configuration management and control procedures are critical to establishing an initial baseline of hardware and software components for the system and subsequently for controlling and maintaining an accurate inventory of changes which may have a significant security impact. Documenting information system changes and assessing the potential impact on the security of the system on an ongoing basis is an essential aspect of maintaining security. These steps, when implemented effectively, provide vital input into the system’s continuous monitoring capability. 3.5.1. Outputs

• Updated security documentation. 3.5.2. Notes Security architecture should provide key details on component-level security service, which in turn provides a benchmark to evaluate the impact of the planned change. For example, if you are upgrading database software to a new version that has less auditing capability, the security architecture or security control documentation should provide insight into whether that component needs that level of auditing capability. Resulting analysis would identify whether further review is needed before implementing. The security significance is not always easy to identify when looking at Change Management (CM) artifacts. The reviewer should keep in mind any changes that would directly or indirectly impact confidentiality, integrity, and availability. Some system enhancements that add new data may require a review of impact to the system security categorization and associated security controls. Expedited CM processes that allow for unique emergency situations should be identified for emergency purposes. These situations should always be followed up with a full review when time permits.

of 42


3.6. Conduct Continuous Monitoring The objective of continuous monitoring is to provide assurance that security controls in the information system continue to be effective over. A well-designed and well-managed continuous monitoring process provides essential, near real-time security status information which can be used to take appropriate risk mitigation actions and make credible, risk-based decisions regarding the continued operation system and formal risk acceptance. The ongoing monitoring of security control effectiveness can be accomplished in a variety of ways, including security reviews, self-assessments, configuration management, antivirus management, patch management, security testing and evaluation, or audits. Automation should be leveraged where possible to reduce level of effort and ensure repeatability. 3.6.1. Outputs

• Security reviews, metrics, measures, and trend analysis, • Updated security documentation, and,

• Documented results of continuous monitoring. 3.6.2. Notes Continuous monitoring should be adjusted as risk levels fluctuate significantly and security controls are modified, added, and discontinued. Prioritizing continuous monitoring activities by importance of each control to mitigating risk and realize that it is neither feasible nor cost-effective to monitor all the security controls in any information system on a continuous basis. A schedule should be developed that ensures that all controls requiring monitoring are adequately covered and that all controls are covered at least once between each certification review. Continuous monitoring processes should be evaluated periodically to review changes in threats and how this could affect the ability of controls to protect a system. These threat updates may result in updated risk decisions and changes to existing controls. When implemented effectively, continuous monitoring activities can provide useful data to support security performance plans and measures of security return on investment (ROI).

of 42


4. Applicable SSQA Controls The SSQA Framework provides a collection of controls applicable either throughout multiple phases of the software development lifecycle or during specific phases / stages. Due to this, it is important to understand that not all controls will be applicable at each assessment gate. Within the context of Control Gate 3, the Testing and Pre-Deployment Assessment Gate, the concentration is predominantly around controls related to Transition, Testing, Operations and Deployment, however there are some controls that either permeate through all lifecycle stages or exist outside of specific lifecycle stages that should be considered prior to the commencement of development activities. The guidance is provided below concerns the controls that are considered relevant during towards the middle of the development lifecycle. These controls, are documented within each SSQA Software Security Standard, Level 1, Level 2 and Level 3.

of 42


NIA Control

Category Level Control and

Control Objective Guidance So

ftwar

e Se

curit

y

Leve

l 2

Share security results with QA Results from security reviews should be routinely shared with the Quality Assurance (QA) department. Agile development methodologies make this easier because of the way testing is integrated in a cross-functional team. Over time, QA engineers learn the security mindset and using security results to inform and evolve testing patterns can be a powerful mechanism leading to better security testing. This activity benefits from an engineering-focused QA function that is highly technical.

Develop the security mind set of the Quality Assurance capability.

Include security tests in QA automation Security tests should be run alongside functional tests as part of automated regression testing. The same automation framework can house both. Security tests can be driven from abuse cases identified earlier in the lifecycle or tests derived from creative tweaks of functional tests.

Enhance regression testing.

of 42


NIA Control



ftwar

e Se

curit

y

Leve

l 2

Perform fuzz testing customized to application APIs

Test agile team members should customize a fuzzing framework to the organization’s APIs. They could begin from scratch or use an existing fuzzing toolkit, but customization goes beyond creating custom protocol descriptions or file format templates. The fuzzing framework has a built-in understanding of the application interfaces it calls into. Test harnesses developed explicitly for applications can make good places to integrate fuzz testing.

Improve fuzzing frameworks and testing harnesses.

Track software bugs found in operations through the fix process Where defects are found in operations, they should be fed back to

development teams through an established defect management system and tracked through the fix process. Improve Defect Management with operational data.

of 42


NIA Control



ftwar

e Se

curit

y

Leve

l 2

Schedule periodic penetration tests for application coverage

The Software Security Group (SSG) should periodically ensure the penetration testing of all applications according to an established schedule, which could be tied to the calendar or to release cycles. The testing provides assurance and helps ensure yesterday’s software isn’t vulnerable to today’s attacks. This also helps maintain the security of software configurations and environments, especially in the cloud. High-profile applications might get a penetration test at least once a year. One important aspect of periodic testing is to make sure that the problems identified in a penetration test are fixed and they don’t creep back into the build.

Obtain periodic assurance of the security of all solutions.

Provide penetration testers with all available information

Penetration testers, whether internal or external, should use all available information about their target. Penetration testers can do deeper analysis and find more interesting problems when they have source code, design documents, architecture analysis results, and code review results. Give penetration testers everything you have created throughout the Secure Software Development Lifecycle (SSDL) and ensure they use it.

Support in-depth analysis of solution.

of 42


NIA Control



ftwar

e Se

curit

y Leve

l 2

Use code signing The organization should use code signing for software published across trust boundaries. Code signing is particularly useful for protecting the integrity of software that leaves the organization’s control, such as shrink-wrapped applications or thick clients. The fact that some mobile platforms require application code to be signed does not indicate institutional use of code signing.

Assure the integrity of software leaving the organizations control.

Leve

l 3

Create and use automation to do what the attackers will do

The Software Security Group (SSG) should provide testers and auditors with automation to do what attackers are going to do. For example, a new attack method identified by the science team could require a new tool. The SSG packages the new tool and distributes it to testers. The idea is to push attack capability past what typical commercial tools and offerings encompass and then package that information for others to use. Tailoring these new tools to a firm’s technology stacks and potential attackers is a really good idea.

Develop tools to automate the testing of new attack methods of interest to the organization.

of 42


NIA Control


Control Objective Guidance

Softw

are

Secu

rity

Leve

l 3

Automate malicious code detection Automated code review is used to identify dangerous code written by malicious in-house developers or outsourced providers. Examples of malicious code that could be targeted include backdoors, logic bombs, time bombs, nefarious communication channels, obfuscated program logic, and dynamic code injection. Although out-of-the-box automation might identify some generic malicious-looking constructs, custom rules for static analysis tools used to codify acceptable and unacceptable code patterns in the organization’s codebase will quickly become a necessity. Manual code review for malicious code is a good start but is insufficient to complete this activity.

Efficiently identify malicious code developed in-house or by outsource providers.

Drive tests with risk analysis results Testers use architecture analysis results to direct their work. For example, if architecture analysis concludes, “the security of the system hinges on the transactions being atomic and not being interrupted partway through,” then torn transactions will be become a primary target in adversarial testing. Adversarial tests like these can be developed according to risk profile – testing for high-risk flaws first.

Align security testing efforts with Architecture Analysis (AA) activities.

of 42


NIA Control



Softw

are

Secu

rity

Leve

l 3

Leverage coverage analysis Testers should measure the code coverage of their security tests to identify code that isn’t being exercised. Code coverage drives increased security testing depth. Standard-issue black box testing tools achieve exceptionally low coverage, leaving a majority of the software under test unexplored. Don’t let this happen to your tests. Using standard measurements for coverage such as function coverage, line coverage, or multiple condition coverage is fine.

Improve the coverage of testing efforts, ensuring that all code is exercised.

Begin to build and apply adversarial security tests (abuse cases)

Testing begins to incorporate test cases based on abuse cases. Testers move beyond verifying functionality and take on the attacker’s perspective. For example, testers might systematically attempt to replicate incidents from the organization’s history. Abuse and misuse cases based on the attacker’s perspective can also be driven from security policies, attack intelligence and guidelines. This turns the corner from testing features to attempting to break the software under test.

Develop test cases derived from abuse cases to move beyond functionality testing.

Fix all occurrences of software bugs found in operations

The organization should fix all instances of each software bug found during operations and not just the small number of instances that have triggered bug reports. This requires the ability to re-examine the entire codebase when new kinds of bugs come to light. One way to approach this is to create a rule set that generalizes a deployed bug into something that can be scanned for using automated code review.

Eliminate all instances of each bug identified during operations.

of 42


NIA Control



ftwar

e Se

curit

y

Leve

l 3

Operate a bug bounty program The organization should solicit vulnerability reports from external researchers and pay a bounty for each verified and accepted vulnerability received. Rewards may typically follow a sliding scale linked to multiple factors, such as vulnerability type (e.g., remote code execution is worth $10,000 versus Cross-Site Request Forgery (CSRF) which may be worth $750). Weaknesses demonstrating exploitability command much higher rewards, as should weaknesses that affect widely-deployed or critical services. Ad hoc or short-duration activities, such as capture-the-flag contests, do not count.

Encourage the responsible identification and disclosure of bugs.

of 42


NIA Control



ftwar

e Se

curit

y

Leve

l 3

Use external penetration testers to perform deep-dive analysis

The organization should use external penetration testers to do deep-dive analysis for critical projects and to introduce fresh thinking into the Software Security Group (SSG). These testers are experts and specialists; they keep the organization up to speed with the latest version of the attacker’s perspective and have a track record for breaking the type of software being tested. Skilled penetration testers will always break a system. The question is whether they demonstrate new kinds of thinking about attacks that can be useful when designing, implementing, and hardening new systems. Creating new types of attacks from threat intelligence and abuse cases prevents checklist-driven approaches that only looks for known types of problems and is essential when it comes to new technology.

Introduce intelligence-based assessment into critical projects.

of 42


NIA Control



ftwar

e Se

curit

y Leve

l 3

Have SSG customize penetration testing tools and scripts

The Software Security Group (SSG) should either create penetration testing tools or adapts publicly-available tools so they can more efficiently and comprehensively attack the organization’s systems. Tools improve the efficiency of the penetration testing process without sacrificing the depth of problems the SSG can identify. Automation can be particularly valuable under agile methodologies because it helps teams go faster and tools that can be tailored are always preferable to generic tools.

Improve the efficiency of the penetration testing process.

Leve

l 3

Use code protection To protect intellectual property and make exploit development harder, the organization should implement barriers to prevent reverse engineering. This is particularly important for widely-distributed mobile applications. Obfuscation techniques could be applied as part of the production build and release process. Employing platform-specific controls such as Data Execution Prevention (DEP), Safe Structured Error Handling (SafeSEH), and Address Space Layout Randomization (ASLR) can make exploit development more difficult.

Prevent reverse engineering to protect Intellectual Property (IP) and increase the difficulty of exploit development.

of 42


NIA Control



Softw

are

Secu

rity

Leve

l 3

Use Application Containers The organization should use application containers to support its software security goals. The primary drivers for using containers include ease of deployment, a tighter coupling of applications with their dependencies, and isolation without the overhead of deploying a full OS on a virtual machine. Containers provide a convenient place for security controls to be applied and updated consistently. Containers used in development or test environments without reference to security do not count.

Support security and simplify solution deployment.

of 42


NIA Control


Control Objective Guidance Ri

sk M

anag

emen

t

Leve

l 2

Collect and publish attack stories To maximize the benefit from experiences, the Software Security Group (SSG) should collect and publish stories about attacks against the organization. Over time, this collection helps the organization understand its history. Both successful and unsuccessful attacks can be noteworthy and discussing historical information about software attacks has the effect of grounding software security in the reality of a firm. This is particularly useful in training classes to counter a generic approach over-focused on irrelevant and outdated platform attacks. Hiding information about attacks from people building new systems does nothing but develop a false sense of security from potentially ineffective practices.

Collect and publish information concerning attacks against the organization, both successful and unsuccessful.

of 42


NIA Control


Control Objective Guidance Ri

sk M

anag

emen

t

Leve

l 2

Build and maintain a top N possible attacks list The Software Security Group (SSG) helps the organization understand attack basics by maintaining a living list of attacks most important to the firm and using it to drive change. This list combines input from multiple sources: observed attacks, hacker forums, industry trends, etc. The list does not need to be updated with great frequency and the attacks can be sorted in a coarse fashion. For example, the SSG might brainstorm twice per year to create lists of attacks the organization should be prepared to counter “now,” “soon,” and “someday.” In some cases, attack model information is used in a list-based approach to architecture analysis, helping to focus the analysis as in the case of STRIDE.

Develop and maintain a list of the most relevant possible attacks using insight gained from internal and external sources.

Logg

ing

and S

ecur

ity

Moni

torin

g

Leve

l 1

Use application input monitoring The organization should monitor the input to software it runs to spot attacks. For web code, a web application firewall (WAF) can do the job. The Software Security Group (SSG) could be responsible for the care and feeding of the system. Incident response is not part of this activity. Defanged WAFs that write log files can be useful if somebody reviews the logs periodically. On the other hand, a WAF that’s unmonitored is of little benefit.

To monitor software inputs for signs of misbehavior that may indicate attack or exploitation.

of 42


NIA Control



Logg

ing

and S

ecur

ity

Moni

torin

g

Leve

l 3

Use application behaviour monitoring and diagnostics

The organization should monitor the behaviour of production software looking for misbehaviour and signs of attack. This activity goes beyond host and network monitoring to look for problems that are specific to the software, such as indications of fraud. Intrusion detection and anomaly detection systems at the application level may focus on an application’s interaction with the operating system (through system calls) or with the kinds of data that an application consumes, originates, and manipulates.

Monitor Software for signs of attack or misuse.

Incid

ent M

anag

emen

t

Leve

l 2

Have emergency codebase response The organization should be able to make quick code changes when an application is under attack. A rapid-response team should work in conjunction with the application owners and the Software Security Group (SSG) to study the code and the attack, find a resolution, and push a patch into production. Often, the emergency response team is the development team itself, especially when agile methodologies are in use. Fire drills don’t count; a well-defined process is required and a process that has never been used may not actually work.

Support the rapid evaluation and response to codebase attacks.

of 42


NIA Control


Control Objective Guidance In

ciden

t Man

agem

ent

Leve

l 3

Simulate software crisis The Software Security Group (SSG) should simulate high-impact software security crises to ensure software incident response capabilities minimize impacts. Simulations could test for the ability to identify and mitigate specific threats or, in other cases, could begin with the assumption that a critical system or service is already compromised and evaluate the organization’s ability to respond. When simulations model successful attacks, an important question to consider is the time required to clean up. Regardless, simulations must focus on security-relevant software failure and not on natural disasters or other types of emergency response drills. If the data center is burning to the ground, the SSG won’t be among the first responders.

Ensure incident response capabilities for software security crises.

of 42


NIA Control


Control Objective Guidance Go

vern

ance

Leve

l 1

Make code review mandatory for all projects Code review should be a mandatory release gate for all projects. Lack of code review or unacceptable results should stop the release. While all projects must undergo code review, the review process might be different for different kinds of projects. The review for low-risk projects might rely more heavily on automation and the review for high-risk projects might have no upper bound on the amount of time spent by reviewers. A code review gate with a minimum acceptable standard should force projects that don’t pass to be fixed and re-evaluated before they ship.

Establish code review as a mandatory check within the development lifecycle to enhance assurance levels.

of 42


NIA Control



vern

ance

Leve

l 2

Require security sign-off for compliance-related risk

The organization should have a formal compliance risk acceptance and accountability process addressing all software development projects, regardless of development methodology. The Software Security Group (SSG) might act as an advisor when the risk acceptor signs off on the state of the software prior to release. For example, the sign-off policy might require the head of the business unit to sign off on compliance issues that have not been mitigated or Secure Software Development Lifecycle (SSDL) steps related to compliance that have been skipped. Signoff should be explicit and captured for future reference. Any exceptions should be tracked, even under the fastest of agile methodologies. Even an application without security defects might still be non-compliant.

Implement a process for accepting of compliance risk for each software development project by requiring sign-off by an authorized individual with advice from the Software Security Group (SSG).

of 42


NIA Control



vern

ance

Leve

l 2

Require security sign-off The organization should have an initiative-wide process for accepting security risk and documenting accountability. A risk acceptor should sign off on the state of all software prior to release. For example, the sign-off policy might require the head of the business unit to sign off on critical vulnerabilities that have not been mitigated or Secure Software Development Lifecycle (SSDL) steps that have been skipped. The policy must apply to outsourced projects, such as a boutique mobile application, and to projects that will be deployed in external environments, such as the cloud. Informal or uninformed risk acceptance alone does not count as security sign off, as the act of accepting risk is more effective when it is formalized (e.g., with a signature, form submission, or something similar) and captured for future reference. Similarly, simply stating that certain projects never need a sign-off does not achieve the desired results.

Implement a process for accepting security risk by requiring sign-off by an authorized individual and documenting accountability for all software prior to release irrespective of whether it is developed internally or externally.

of 42


NIA Control



vern

ance

Leve

l 2

Develop operations inventory of applications The organization should have a map of its software deployments. If a piece of code needs to be changed, operations or DevOps should be able to reliably identify all the places where the change needs to be installed. Sometimes common components shared between multiple projects are noted so that when an error occurs in one application, other applications that share the same components can be fixed as well.

Improve understanding of application deployments to support changes.

Leve

l 3

Enhance the Secure Software Development Lifecycle (SSDL) to prevent software bugs found in operations

Experience from operations should lead to changes in the Secure Software Development Lifecycle (SSDL). This enables the SSDL to be enhanced and prevent the reintroduction of bugs found during operations. To make this process systematic, each incident response post mortem could include a “feedback to SSDL” step. This works best when root cause analysis pinpoints where in the SDL an error could have been introduced or slipped by uncaught. Cross-functional agile teams might have an easier time with this because all the players are involved, but an ad hoc approach is not sufficient.

To ensure that development activities consider the avoidance of bugs identified during operation, preventing their reintroduction to future solutions.

of 42


NIA Control



Docu

men

tatio

n

Leve

l 2

Publish installation guides The Secure Software Development Lifecycle (SSDL) should require the creation clearly described documentation, such as configuration and installation guides to help deployment teams and operators install and configure the software securely. If special steps are required to ensure a deployment is secure, the steps are either outlined in the installation guide or explicitly noted in deployment automation. The guide should include discussion of Commercial-Off-The-Shelf (COTS) components. Make sure that all deployment automation can be understood by people and not just a machine. Evolving DevOps and integrated team structures do not eliminate the need for human-readable guidance.

Guide deployment teams and operators in secure installation and configuration of solutions.

of 42


5. Expected Inputs • Verified List of Operational Security Controls, • Completed System Documentation, and, • Security Assessment Report.

of 42


6. Expected Outputs • Security Authorization Sign-Off & Risk Acceptance, and, • Compliance Authorization Sign-Off and Risk Acceptance.

Upon receipt of Security and Compliance Authorization Sign-Off, it may be appropriate to copy all the System and Project documentation to WORM (Write-Once-Read-Many) media, such as a CD (Compact Disk) for future reference to preserve the integrity of the data.

of 42


7. Stakeholders 7.1. Database Administration Group Assist with integration of the solution design and data conversion tests.

7.2. Developer Prepares all solution documentation and manuals for operations and assists with building tests and the analysis of test results. Developers should also supply or support requested training to help operations learn the solution’s behaviours.

7.3. Implementation Manager Assist with analysis of test results.

7.4. Integration Manager Assist with analysis of test results.

7.5. Project Manager Resolve resource, scheduling, budget issues; review and report progress.

7.6. Project Sponsor Sponsors and signs off team effort; reviews strategy and artifacts.

7.7. Testing Lead The Testing Lead provides quality assurance of the Testing Team and Tester activities and outputs, formally signing-off testing results and affirming alignment to testing requirements.

7.8. Testing Team/Tester The Testing Team or Tester performs testing activities in relation to functional and security requirements or coordinates the conduct of external testers as necessary.

of 42


8. Legacy System Considerations Organizations may be applying the Software Security and Quality Assurance (SSQA) lifecycle controls and assessments to legacy systems that have been in operation for some extended period. Some legacy solutions may have excellent security plans that provide comprehensive documentation of the risk management decisions that have been made, including identifying the security controls currently employed. Other legacy solutions may have limited documentation available. The security considerations, however, are still relevant to these legacy solutions, and should be applied and documented to ensure security controls are in place and functioning effectively to provide adequate protections for the information and the information system. Effective communication of security requirements and expectations will be a vital and challenging step. The key is to document the security requirement in specific and measurable terms so that it clearly identifies who is responsible and accountable. The expectations should be manageable and cost-effective.

compliance.qcert.org

End of Document

Software Security and Quality Assurance (SSQA) Gate 3 Guidance

Documents

Transcript of Software Security and Quality Assurance (SSQA) Gate 3 Guidance