software security and quality assurance (ssqa ... - q-cert · title: software security and quality...

of 30 Title: Software Security and Quality Assurance (SSQA) Gate 3 Guidance Version: 1.0 Classification: PUBLIC

Software Security and Quality Assurance

(SSQA) Gate 3 Guidance

Understanding the Final SSQA Assessment Gate


Document Control Approval

Name Role Date of Approval Version Number

Ashraf Ali-Ismael NISCF Compliance

Manager 08/10/2018 1.0

The guidance manual is owned by Ministry of Transport and Communications (MOTC) who shall update

the document as necessary.


Table of Contents

Introduction .................................................................................................................................................. 6

The SSQA Gate Assessments ........................................................................................................................ 8

The Testing and Pre-Deployment Control Gate ........................................................................................... 9

Pre-Gate Activities ......................................................................................................................................10

Conduct Testing ......................................................................................................................................11

Integrate Security into Established Environments or Systems ...............................................................12

Assess System Security ...........................................................................................................................13

Review Operational Readiness ...............................................................................................................14

Perform Configuration Management and Control .................................................................................15

Conduct Continuous Monitoring ............................................................................................................16

Applicable SSQA Controls ...........................................................................................................................17

Expected Inputs ..........................................................................................................................................28

Expected Outputs .......................................................................................................................................28

Stakeholders ...............................................................................................................................................29

Legacy System Considerations ...................................................................................................................30


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 guideline has been prepared taking into consideration current applicable laws of the State of Qatar.

In the event that 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.


References • [IAP-NAT-DCLS] National Information Classification Policy

• [IAP-NAT-IAFW] Information Assurance Framework

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



A glossary of terms is defined within the Information Assurance Framework, [IAP-NAT-IAFW].


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 E-Government Services.

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 E-Government Services that relies upon successful assessment across three assessment

gates to validate the implementation of the SSQA controls provide quality assurance.


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

government 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.


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 E-

Government services.

As constituents become more familiar with the SSQA framework and the gate processes

implemented to build assurance into software development activities for E-Government services, 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 E-Government services. 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.


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.


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.


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.

Outputs

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

testing.

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.


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.

Outputs

• Verified list of operational security controls, and,

• Completed system documentation.

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.


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.

Outputs

• Security Assessment Report.

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.


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.

Outputs

• Evaluation of security implications due to any system changes.

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.


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.

Outputs

• Updated security documentation.

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.


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.

Outputs

• Security reviews, metrics, measures, and trend analysis;

• Updated security documentation, and,

• Documented results of continuous monitoring.

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).


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.


NIA Control

Category Level

Control and Control Objective

Guidance

Soft

wa

re S

ecu

rity

Lev

el 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.

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.


NIA Control

Category Level


Guidance So

ftw

are

Sec

uri

ty

Lev

el 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.

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.

Lev

el 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.


NIA Control

Category Level


Guidance So

ftw

are

Sec

uri

ty

Lev

el 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.

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.


NIA Control

Category Level


Guidance So

ftw

are

Sec

uri

ty

Lev

el 3

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.

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.

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.


NIA Control

Category Level


Guidance So

ftw

are

Sec

uri

ty

Lev

el 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.

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.

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.


NIA Control

Category Level


Guidance

Ris

k M

an

ag

emen

t

Lev

el 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.

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.


NIA Control

Category Level


Guidance

Log

gin

g a

nd

Sec

uri

ty

Mo

nit

ori

ng

Lev

el 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.

Lev

el 3

Use application behavior monitoring and diagnostics

The organization should monitor the behavior of production software looking for misbehavior 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.

Inci

den

t M

an

ag

emen

t

Lev

el 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.

Lev

el 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.


NIA Control

Category Level


Guidance

Go

vern

an

ce

Lev

el 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.

Lev

el 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).


NIA Control

Category Level


Guidance G

ove

rna

nce

Lev

el 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.

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.

Lev

el 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.


NIA Control

Category Level


Guidance D

ocu

men

tati

on

Lev

el 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.


Expected Inputs • Verified List of Operational Security Controls,

• Completed System Documentation, and,

• Security Assessment Report.

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.


Stakeholders Database Administration Group

Assist with integration of the solution design and data conversion tests.

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

behaviors.

Implementation Manager

Assist with analysis of test results.

Integration Manager

Assist with analysis of test results.

Project Manager

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

Project Sponsor

Sponsors and signs off team effort; reviews strategy and artifacts.

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.

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.


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.

software security and quality assurance (ssqa ... - q-cert · title: software security and quality...

Documents