Software Security and Quality Assurance (SSQA) Gate 1 …compliance.qcert.org/sites/default/files/library/2019-02/MOTC-CDP-SSQA...Title: Software Security and Quality Assurance (SSQA)

Page 1 of 35 Title: Software Security and Quality Assurance (SSQA) Gate 1 Guidance Version: 1.0 Classification: PUBLIC

Software Security and Quality Assurance

(SSQA) Gate 1 Guidance

Understanding the Initial SSQA Assessment Gate


Document Control Review Schedule: Annually, following major incidents amongst constituents, or because of major changes to the software

security domain.

Date of next Scheduled Review: 08/10/2019

Document Storage Document Title: Software Security and Quality Assurance (SSQA) Gate 1 Guidance

Document Location:

[PORTAL

NAME]/National_Information_Assurance_Framework/Software_Security_and_Quality_Assurance/Stan

dards/

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 the Ministry of Transport and Communications (MOTC) who shall

update the document as necessary.


Table of Contents

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

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

The Inception and Design Assessment Gate ................................................................................................ 9

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

Initiate Project Security Planning ...........................................................................................................11

Classify the System .................................................................................................................................13

Assess Business Impact ...........................................................................................................................14

Assess Privacy Impact .............................................................................................................................15

Ensure Secure System Development ......................................................................................................16

Applicable SSQA Controls .......................................................................................................................18

Expected Inputs ..........................................................................................................................................31

Expected Outputs .......................................................................................................................................32

Stakeholders ...............................................................................................................................................33

Legacy System Considerations ...................................................................................................................35


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 organizations 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 Inception and Design Assessment Gate The objective of the Inception and Design Assessment Gate is to ensure a somewhat reasonable

expectation that a secure, reliable and effective system can be built on time and within cost to meet

business requirements.

Inception activities are designed to ensure that the development objective:

• aligns with the Mission & Vision of the Agency,

• Presents no legal or ethical infringements or liabilities, and,

• Is not a replication of an existing system or one currently in-development.

Prior to the completion of the systems inception and, as a core requirement for the design, some

form of project document (such as project charter, a project management plan, and a project budget

plan) should be developed to help lead agencies forwards through a successful project.

Considering security upfront is key to diligent and early integration and thereby ensuring that

threats, requirements, and potential constraints in functionality or integration are addressed.

At this point, security is looked at from a high-level and focuses more in terms of business risks. For

example, an agency may identify a political risk resulting from a prominent website being modified

or made unavailable during a critical business period, resulting in decreased trust by citizens.

Key security activities for this phase include:

• Initial delineation of business requirements in terms of confidentiality, integrity, and

availability;

• Determination of information categorization and identification of known special handling

requirements to transmit, store, or create information such as personally identifiable

information; and,

• Determination of any privacy requirements.

Early planning and awareness will result in reduced cost and timesaving through proper risk

management planning.

Security discussions should be performed as part of (not separately from) the development project

to ensure solid understandings among project personnel of business decisions and their risk

implications to the overall development project.


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 Inception and Design stages, the following activities should be completed prior to

the gate assessment:

• Initiate Project Security Planning,

• Classify the System,

• Perform a Business Impact Assessment (BIA),

• Perform a Privacy Impact Assessment (PIA); and,

• Ensure Secure Systems Development.


Initiate Project Security Planning Security planning should begin during Inception and Design by:

• Identifying key security roles for the system development,

• Identifying sources of security requirements, such as relevant laws, regulations, and

standards;

• Ensuring all key stakeholders have a common understanding, including security implications,

considerations, and requirements; and

• Outlining initial thoughts on key security milestones including time frames or development

triggers that signal a security step is approaching.

This early involvement will enable the developers to plan security requirements and associated

constraints into the project.

It also reminds project leaders that many decisions being made have security implications that

should be weighed appropriately, as the project continues.

The Software Security Group (SSG) should guide the business stakeholders (and developers) to an

early understanding of appropriate security steps, requirements, and expectations so security can be

effectively planned prior to development. Discussion topics may include the consideration of:

• Security Responsibilities,

• Security Reporting Metrics,

• Common Security Controls Provided (if applicable),

• Certification & Accreditation Process,

• Security Testing and Assessment Techniques,

• Security Document & Requirement Deliverables,

• Secure Design, Architecture, and Coding Practices;

• Security Acquisition Considerations, and,

• Major activities with development schedule and resource impacts such as active testing,

accreditation, and training.

Developing an initial project outline for security milestones that are integrated into the project

schedule will allow appropriate planning as and oversight. At this stage, activities may be more in

terms of decisions followed by security activities.


Outputs

Following completion of initial project security planning, project teams should be able to produce:

• Supporting project documents (such as slides, meeting minutes, briefings, role and

responsibilities etc.);

• a common understanding of security expectations, and,

• An initial schedule of security activities or decisions.

Notes

Security planning in the inception and design phases should include preparations for the entire

system life cycle, including the identification of key security milestones and deliverables, as well as

key tools and technologies.

Special consideration should be given to items that may need to be procured (e.g., test/assessment

tools) and a series of milestones or security meetings should be planned to discuss each of the

security considerations throughout development.

A project schedule should integrate security activities to ensure proper planning of any future

decisions associated with schedules and resources.


Classify the System Security classification, provides a vital step towards integrating security into business and

information technology management functions and establishes the foundation for security

standardization among information systems.

Security classification starts with the identification of what information supports which lines of

business, as defined by the Enterprise Architecture. Subsequent steps focus on the evaluation of

security in terms of confidentiality, integrity, and availability.

The result is strong linkage between business objectives, information, and systems with cost-

effective information security.

Outputs

• Security Classification Assessment, and,

• High-Level Security Requirements.

Notes

The security classification should be revisited if there are significant changes to the system or when

the business impact analysis is updated; and, a formal process should be developed to enable the

continuous and consistent re-validate the security classifications of existing systems.


Assess Business Impact An assessment of an impact on the lines of business correlates specific system components with the

critical business services that are provided.

That information is then used to characterize the consequences of a disruption to the system

components. An initial draft of this product early in the life cycle alerts system stakeholders to key IT

and security decisions.

This task should also consider the availability impact level identified during the security classification

activity.

Outputs

• Identify lines of business supported by this system and how those lines of business will be

impacted,

• Identify core components needed to maintain minimal functionality,

• Identify the length of time the service can be down before the business is impacted (initial

idea of the needed Recovery Time Objective), and

• Identify the business tolerance for loss of data (initial idea of the needed Recovery Point

Objective).

Notes

Some of this information can be derived from the original business case for the initiative; however,

the Business Impact Assessment (BIA) should be reviewed periodically and updated as major

development decisions (such as new functionalities) occur or the system’s purpose and scope

change significantly. Further, as the system matures, the BIA should be augmented with greater

detail.

For larger and more complex developments, consider holding a stakeholder meeting to brainstorm

possible linkages and impacts.

The results of a BIA can be used to develop requirements or objectives for service-level agreements

(SLAs) with supporting service providers.

Reuse data and information for multiple purposes when applicable. Classification decisions can be

reused for BIA, Disaster Recovery (DR) and Business Continuity Planning (BCP).


Assess Privacy Impact When developing a new system, it is important to directly consider if the system will process

information that may be considered privacy data or personal information. This typically is identified

during the security classification process when identifying information types.

Once identified as a system that will likely handle personal information, the system owner (with

assistance from the Software Security Group) should work towards identifying and ensuring the

implementation of appropriate safeguards and security controls, including processes to address

incident handling and reporting requirements.

Either a one- or two-step model may be implemented to address privacy considerations.

The one-step model requires all projects to develop a Privacy Impact Assessment (PIA) that outlines

criteria for privacy information determination and documents security controls planned to properly

protect the information.

In contrast, under a two-step model, all projects perform a threshold analysis (or Mini PIA) which is

focused on whether a privacy impact assessment should be performed. A positive answer would

then result in the execution of a more detailed evaluation of privacy and security controls in the

form of a full PIA.

The resulting document of either process should be incorporated into the system security plan and

maintained appropriately.

Outputs

A Privacy Impact Assessment providing details on where and to what degree privacy information is

processed within the system.

Notes

As a result of the PIA, any Security controls identified or assessed as a requirement to protect

identified personal data will have an impact on the System Security Plan, Contingency Plan, and

Business Impact Assessment.

The PIA should continue to be reviewed and updated as major decisions occur or system purpose

and scope change significantly.


Ensure Secure System Development Primary responsibility for application security, during early phases, lies in the hands of the

development team which has the most in-depth understanding of the detailed workings of the

application and the ability to identify security defects in functional behavior and business process

logic.

They are the first level of defense and opportunity to build in security, therefore it is important that

their role not be assumed or diminished.

Additional security training may be needed for developers to understand the current threats and

potential exploitations of their products as well as to support secure design and coding techniques.

This enables the developers to create more secure designs and empowers them to address key

issues early in the development processes.

Special attention should be placed upon code repositories with an emphasis on systems that support

distributed code contribution with check-in/check-out functionality.

Role-based access should apply to accessing the code repository, and logs should be reviewed

regularly as part of the secure development process.

Code should be developed in accordance with standard practices.

Secure coding standards and patterns embody code level examples and accompanying

documentation that illustrate how to meet specific functional requirements while simultaneously

achieving security mandates. These patterns can then be reused by developers to ensure that all

software components are developed in an assured fashion, having been vetted and adopted by the

organization. When possible, completed software components that have passed security review

should be retained as reusable components for future software development and system

integration.

As a team, system developers and security representatives should agree on what steps can and

should be taken to ensure valuable and cost-effective contributions to a secure development

environment.

System development should occur with standard processes that consider secure practices and are

documented and repeatable. To accomplish this, appropriate security processes for the assurance

level required by the system should be determined and documented. As a result, systems with a

high assurance requirement may need additional security controls built into the development

process.

Quality management, which includes planning, assurance and control, is key to ensuring minimal

defects within and proper execution of the information system. This reduces gaps or holes that are

sometimes left open for exploitation or misuse (whether intentional or not) causing vulnerabilities in

the system.

Outputs

• Plans for development phase security training,

• Planned quality assurance techniques, deliverables, and milestones; and,

• Development and coding standards including development environment.


Notes

Understanding modern application security defects and attack methods is essential to protecting

systems against them. Providing application security training to the development and testing teams

will increase understanding of the issues and techniques and should enable the development of

more secure systems. If developers are aware of what to look for and what to test during the

development phase, the number of security defects developed and released to Quality Assurance

(QA) should be reduced.

In addition, the QA test team will be well educated around application security,

Any weakness known by the development team should be addressed as soon as possible. It is

unwise to assume that complicated attacks requiring significant knowledge of the internal workings

of the system are unlikely from malicious attackers. On more than one occasion, system owners

have been surprised to find that attackers were able to “discover” information that the system

owners assumed to be hidden.

To reduce the possibility of security defects in the system, security-focused additions should be

investigated and incorporated into the existing coding standards or development guideline

documents. These documents should account for all types of software development languages used,

such as C++, Java, HTML, PHP, JavaScript, and SQL as examples.

Lessons learned from completed projects and previous security testing activities should be evaluated

for appropriateness in adjusting development processes and standards to prevent embedding

weaknesses.

Similarly, IT development standards should contain appropriate methodologies that add value to the

process and do not detract from security and system development training and orientation should

include basic (and environment specific) security awareness, training, and education.


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 1, the Inception and Development Assessment Gate, the

concentration is predominantly around controls related to Inception and Design, 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.

Guidance is provided below for controls considered relevant during early stages of development and

are documented within each SSQA Software Security Standard, Level 1, Level 2 and Level 3.


NIA Control

Category Level

Control and Control Objective

Guidance D

ocu

men

tati

on

Lev

el 1

Create policy

The SSG guides the rest of the organization by creating or contributing to software security policy

that satisfies regulatory and customer-driven security requirements. The policy provides a unified

approach for satisfying the list of security drivers at the governance level.

Architecture standards and coding guidelines are not examples of software security policy. On the

other hand, policy that prescribes and mandates the use of coding guidelines and architecture

standards

Utilize the Software Security Group (SSG) to develop or contribute to Software Security Policy that guides the organization by addressing regulatory and customer-driven requirements.

Create security standards The SSG meets the organization’s demand for security direction by creating standards that explain

the accepted way to adhere to policy.

Standards can be deployed in a variety of ways. In some cases, standards and guidelines can be

automated in development environments (e.g., worked into an IDE). In other cases, guidance can be

explicitly linked to code examples or even containers to make them more actionable and relevant.

Develop Standards, Procedures and Guidance to support adherence to organizational policy.

Lev

el 2

Create standards for technology stacks Ideally, the organization will create a secure base configuration for each technology stack, further

reducing the amount of work required to use the stack safely. A stack might include an operating

system, a database, an application server, and a runtime environment for a managed language.

For the SSG, this means a reduced workload because the group does not have to explore new

technology risks for every new project.

Establish consistent baseline security configurations for specific technology stacks in operation within the organization.

Standardize architectural descriptions (include data flow)

Developing standard descriptions icons for architecture analysis and ensuring that these are used

consistently, in UML diagrams, Visio templates, and whiteboard drawings; helps to ease

understanding amongst those who are not security experts and provide an explicit picture of

information assets that require protection. Develop a common vocabulary and design to describe architectures and dataflow.


NIA Control

Category Level


Guidance G

ove

rna

nce

Lev

el 1

Publish process (roles, responsibilities, plan), evolve as necessary

Most organizations pick and choose from a published methodology, such as the Microsoft SDL or

the Cigital Touchpoints, and then tailor the methodology to their needs.

An SSDL process must be adapted to the specifics of the development process it governs (e.g.,

waterfall, agile, etc.) and evolves both with the organization and the security landscape. A process

must be published to count.

Establish a suitable Secure Software Development Lifecycle (SSDL) methodology and tailor this to the requirements of the development process.

Identify gate locations, gather necessary artefacts The first two steps toward establishing internal security-specific release gates are:

1) to identify gate locations that are compatible with existing development practices; and

2) to begin gathering the input necessary for making a go/no-go decision. Importantly at this stage,

the gates are not enforced.

The idea of identifying gates first and only enforcing them later is extremely helpful in moving

development toward software security without major pain. Socialize the gates, and only enforce

them when most projects know how to succeed.

Determine the location for specific security gates within development processes and identify evidence required for go/no go decisions.

Engage SSG with architecture Have an SSG member attend regular architecture

Meetings to keep security from falling out of the discussion and endure the architecture group takes

responsibility for security the same way they take responsibility for performance, availability, or

scalability. Ensure appropriate integration between the Software Security Group (SSG) and the Architecture team.

Create a security portal Ensure that the organization has a well-known central location for information about software

security maintained by the SSG.

Stakeholders can refer to the repository for security standards and requirements as well as other

resources provided by the SSG.

An interactive wiki is better than a static portal with guideline documents that rarely change, and

these materials can be supplemented with mailing lists and face-to-face meetings.

Develop a central repository maintained by the Security Group that contains relevant documentation and resources.


NIA Control

Category Level


Guidance G

ove

rna

nce

Lev

el 1

Have SSG lead design review efforts

The SSG takes a lead role in architecture analysis by performing design review to build the

organization’s ability to uncover design flaws and it is likely they’ll need help from architects or

implementers to understand the design.

The SSG might carry out the detailed review with a minimum of interaction with the project team.

At higher levels of maturity, the responsibility for leading review efforts shifts towards software

architects.

Enhance security design review expertise within the Software Security Group (SSG) and impart knowledge to the architects.

Lev

el 2

Identify metrics and use them to drive budgets The SSG and its management choose the metrics that define and measure software security

initiative progress.

These metrics will drive the initiative’s budget and allocation of resources.

One metric could be security defect density. A reduction in security defect density could be used to

show a decreasing cost of remediation over time.

In agile methodologies, metrics are best collected early and often in a lightweight manner.

The key is to tie technical results to business objectives in a clear and obvious fashion to justify

funding.

Measure software security initiatives through metrics agreed by Senior Management and the Software Security Group (SSG) and utilize measurements to drive initiative budgets and resource allocation.

Create SSG capability to solve difficult design problems When the SSG is involved early in the new project process, it contributes to new architecture and

solves difficult design problems.

If, for example, the SSG is involved in the design of a new protocol, it could analyze the security

implications of existing protocols and identify issues. Likewise, having a security architect

understand the security implications of moving an existing application to the cloud could prevent a

lot of headaches later.

Designing for security up front is more efficient than analyzing an existing design for security and

then refactoring when flaws are uncovered.

Engage the Software Security Group (SSG) with Project teams from the earliest stages of a project to prevent the costly remediation of security weaknesses.


NIA Control

Category Level


Guidance G

ove

rna

nce

Lev

el 2

Create a standards review board

The organization creates a standards review board to formalize the process used to develop

standards and ensure that all stakeholders have a chance to provide input.

The review board could operate by appointing a champion for any proposed standard. The onus is

on the champion to demonstrate that the standard meets its goals and to get approval from the

review board.

Enterprise architecture or enterprise risk groups sometimes take on the responsibility of creating

and managing standards review boards.

Establish an authority to review security standards, formalizing the activity and enabling active involvement of stakeholders.

Lev

el 3

Form review board or central committee to approve and maintain secure design patterns

Organizations should create a review board or central committee that formalizes the process for

reaching consensus on design needs and security trade-offs.

Unlike the architecture committee, this group is specifically focused on providing security

guidance.

The group also periodically reviews already-published design standards to ensure that design

decisions remain up-to-date and relevant.

Establish a central authority to approve design patterns and review existing design standards to ensure continuing relevance.

Have software architects lead review efforts Software architects throughout the organization lead the architecture analysis process most of the

time. The Software Security Group (SSG) still might contribute to architecture analysis in an

advisory capacity or under special circumstances.

This activity requires a well-understood and well-documented architecture analysis process. Enable consistent, expert driven design reviews.


NIA Control

Category Level


Guidance

Inci

den

t

Ma

na

gem

ent

Lev

el 1

Create or interface with incident response Organizations should ensure that the Software Security Group (SSG) is prepared to respond to an

incident and is included in the incident response process.

The group either creates its own incident response capability or regularly interfaces with the

organization’s existing incident response team.

A regular meeting between the SSG and the incident response team can keep information flowing

in both directions. Sometimes cloud service providers need to be looped in.

Integrate with the organizations incident response process.

NIA Control

Category Level


Guidance

Ris

k

Ma

na

gem

ent

Lev

el 1

Perform security feature review To get started in architecture analysis, center the process on a review of security features.

Security-aware reviewers first identify the security features in an application (authentication, access

control, use of cryptography, etc.) then study the design looking for problems that would cause

these features to fail at their purpose or otherwise prove insufficient.

At higher levels of maturity, the activity should be more thorough.

In some cases, use of the firm’s secure-by-design components can streamline this process.

Identify weaknesses in the design of application security features.


NIA Control

Category Level


Guidance R

isk

Ma

na

gem

ent

Lev

el 1

Perform design review for high-risk applications

It may be impractical to perform design reviews for every development project, or it may not be

required where approved designs are utilized, therefore, design review efforts should be focused

upon high-risk development activities.

The reviewers must have experience performing detailed design review and breaking the

architecture being considered, especially for new platforms or environments.

Design reviews produce a set of architecture flaws and a plan to mitigate them. If the SSG is not yet

equipped to perform an in-depth architecture analysis, it uses consultants to do this work.

Develop mitigation plans for architectural flaws observed within high-risk.

Use a risk questionnaire to rank applications To support the prioritization of security feature and design review efforts the Software Security

Group (SSG) should collect basic information about each system to determine a risk classification

and prioritization scheme.

The questionnaire should be short enough to be completed within a matter of hours and ad-hoc

validation efforts should be enforced to ensure accuracy.

Provide a risk-based categorization of applications and enable prioritization.

Lev

el 2

Define and use Architecture Analysis (AA) process The Software Security Group (SSG) should define and document the process for architecture

analysis so that a standardized approach for thinking about attacks, security properties and

associated risks can be applied consistently.

The process should be defined with enough detail that even stakeholders outside of the SSG can be

taught to carry it out.

Microsoft’s STRIDE and Cigital’s ARA are examples of such process.

Standardize approach to reviewing threats and security controls to enable consistent application of architecture analysis within design review efforts.

Lev

el 3

Control open source risk The organization has control over its exposure to the vulnerabilities that come along with using

open source components and their of dependencies. Use of open source could be restricted to pre-

defined projects; it could also be restricted to open source versions that have been through the

Software Security Group’s (SSG) security screening process, had unacceptable vulnerabilities

remediated, and is available through internal repositories.

Legal often spearheads additional open source controls due to the “viral” license problem

associated with GPL code. Getting legal to understand security risks can help move an organization

to practice decent open source hygiene.

Manage the organizations exposure to risk through implementing restrictions governing the use of Open Source systems.


NIA Control

Category Level


Guidance So

ftw

are

Sec

uri

ty

Lev

el 1

Identify PII obligations

The Software Security Group (SSG) should play a key role in identifying and describing privacy

obligations stemming from legislation, regulation and customer expectations.

It uses this information to promote best practices related to privacy. For example, if the

organization processes credit card transactions, the SSG will identify the constraints that the PCI

DSS places on the handling of cardholder data and inform all stakeholders. Note that outsourcing to

hosted environments (e.g. the cloud) does not relax PII obligations.

Utilize the Software Security Group (SSG) to promote best practice related to privacy arising from regulation and customer expectations.

Create data classification scheme and inventory The organization should agree upon a data classification scheme and use the scheme to inventory its

software according to the types of data the software processes, regardless of whether the software is

on or off premise.

This allows applications to be prioritized by their data classification.

Depending upon the scheme and the software involved, it could be easiest to first classify data

repositories, then derive classifications for applications according to the repositories they use.

Develop a Data Classification Scheme and inventory software according to the data processed.

Build and publish security features Rather than have each project team implement all their own security features

(e.g., authentication, access control, key management, audit/log, cryptography etc.), the Software

Security Group (SSG) should provide proactive guidance by building and publishing security

features for other groups to use.

Project teams benefit from implementations that come pre-approved by the SSG and the SSG

benefits by not having to repeatedly track down the kinds of subtle errors that often creep into

security features.

The SSG can identify an implementation they like and promote it as the accepted system.

Guide project teams by publishing and promoting systems, pre-approved by the Security Group that can be implemented to prevent developing multiple implementations of similar functionality.

Translate compliance constraints to requirements

Compliance constraints should be translated into software requirements for individual projects. This

is a critical to helping the organization’s compliance strategy as, by representing compliance

constraints explicitly with requirements, demonstrating compliance becomes a manageable task. Develop a collection of security requirements derived from regulatory constraints.


So

ftw

are

Sec

uri

ty

Lev

el 2

Build internal forum to discuss attacks The organization should create an internal forum that allows the Software Security Group (SSG),

the satellite, and others discuss attacks.

The forum serves to communicate the attacker perspective.

The SSG could maintain an internal mailing list where subscribers discuss the latest information on

publicly known incidents. The dissection of attacks and exploits that are relevant to a firm are

particularly helpful when they spur discussion of development mitigations.

Develop a mechanism that enables the Security Group, Satellite members and other stakeholders to discuss attacks from the perspective of the attacker.

Assign tool mentors Mentors should be available to show developers how to get the most out of code review tools. If the

Software Security Group (SSG) is most skilled with the tools, it could use office hours to help

developers establish the right configuration or get started interpreting results. Alternatively,

someone from the SSG might work with a development team for the duration of the first review

they perform.

Enhance awareness and familiarity of systems and improve developer efficiency.

NIA Control

Category Level


Guidance


Soft

wa

re S

ecu

rity

Lev

el 3

Have a science team that develops new attack methods

Organizations should develop a team that works to identify and defang new classes of attacks

before real attackers even know they exist. This could be a subset of the Software Security Group

(SSG) or a separate function.

Because the security implications of new technologies have not been fully explored in the wild,

doing it yourself is sometimes the best way forward. This isn’t a penetration testing team finding

new instances of known types of weaknesses—it’s a research group innovating new types of

attacks. A science team may include well-known security researchers who publish their findings at

conferences like Defcon.

Establish dedicated resources within the Security Group to identify new and innovative types of attack.

Find and publish mature design patterns from the organization

The Software Security Group (SSG) should promote the reuse of approved design patterns,

collecting them and publishing them for everyone to use and the process should be formalized.

A section of the SSG website could promote positive elements identified during architecture

analysis so that good ideas are spread as access to common and approved design patterns makes

system development quicker.

Foster centralized design reuse by collecting design patterns and publishing them for use across the organization.

Drive analysis results into standard architectural patterns

Where failures are identified during architecture analysis they should be fed back to the security

design committee so that similar mistakes can be prevented in the future, improving design patterns

and helping to drive development efficiency.

Security design patterns can interact in surprising ways that break security. The architecture

analysis process should be applied even when vetted design patterns are in standard use.

Proactively avoid the introduction of design failures and improve design patterns.

Build a factory The organization should combine assessment results so that multiple analysis techniques feed into

one reporting and remediation process.

The Software Security Group (SSG) may write scripts to invoke multiple detection techniques

automatically and combine the results into a format that can be consumed by a single downstream

review and reporting system. Analysis engines may combine static and dynamic analysis.

The tricky part of this activity is normalizing vulnerability information from disparate sources that

use conflicting terminology. In some cases, a CWE-like approach can help with nomenclature.

Integrate the results of multiple analysis techniques into a singular reporting and remediation process.

NIA Control

Category Level


Guidance


NIA Control

Category Level


Guidance

Thir

d-P

art

y Se

curi

ty

Ma

na

gem

ent

Lev

el 2

Create SLA boilerplate

The Software Security Group (SSG) should work with the legal department to create a standard

SLA boilerplate that is used in contracts to require software security efforts. This includes cloud

providers.

Develop Boilerplate Clauses concerning Service Level Agreements (SLAs) that can be implemented in new and renewed contracts.


NIA Control

Category Level


Guidance Tr

ain

ing

an

d A

wa

ren

ess

Lev

el 1

Create evangelism role and perform internal marketing

To build support for software security throughout the organization, someone in the Software

Security Group (SSG) should perform an evangelism role.

This internal marketing function helps keep executives and stakeholders current on the magnitude

of the software security problem and the elements of its system.

Evangelists might give talks for internal groups including executives, extend invitations to outside

speakers, author white papers for internal consumption, or create a collection of papers, books, and

other resources on an internal website and promote its use.

Build support Software Security throughout the organization.

Educate executives Executives are periodically shown the consequences of inadequate software security and the

negative business impact that poor security can have. They’re also shown what other organizations

are doing to attain software security. By understanding both the problem and its proper resolution,

executives come to support the software security initiative as a risk management necessity.

This can involve demonstrating worst-case scenarios (in a controlled environment), providing

presentations to the Board and involving outside expertise.

Raise awareness of Software Security amongst Senior Management.

Deliver role-specific advanced curriculum (tools, technology stacks, bug parade)

Software security training goes beyond building awareness and enables trainees to incorporate

security practices into their work. The training is tailored to the role of trainees; trainees get

information about the tools, technology stacks, development methodologies, or kinds of bugs that

are most relevant to them.

An organization might offer four tracks for engineers: one for architects, one for Java developers,

one for mobile developers, and a fourth for testers. Tool-specific training is also commonly

observed in a curriculum.

Build capabilities beyond awareness through tailored role specific training.

Create and use material specific to company history For the organization to make a strong and lasting change in behaviors, training should include

material specific to the business’s history. When participants can see themselves in the problem,

they are more likely to understand how the material is relevant to their work and to know when and

how to apply what they have learned. One way to do this is to use noteworthy attacks on the

company as examples in the training curriculum.

Ensure that training is relatable, covering relevant content such as platforms and languages used by

developers

Tailor training materials to incorporate relevance to the organization using historical references related to the organization.


NIA Control

Category Level


Guidance

Tra

inin

g a

nd

Aw

are

nes

s

Lev

el 3

Establish SSG office hours

The Software Security Group (SSG) offers help to all comers during an advertised lab period or

regularly scheduled office hours.

By acting as an informal resource for people who want to solve security problems, the SSG

leverages teachable moments and emphasizes the carrot over the stick.

Drop in sessions might be held one afternoon per week in the office of a senior SSG member or,

alternatively, roving office hours may apply, with visits to stakeholder groups by request.

Set expectations as to the availability of Software Security Group (SSG) services.


Expected Inputs • Supporting Project Documents (including Slides, Briefings, Meeting Minutes, Roles and

Responsivities and other documentation from planning sessions);

• System Documentation,

• Security Classification,

• High-Level Security Requirements,

• Resource Estimates (Effort and Rigor),

• Privacy Impact Assessment (PIA),

• RTO and RPO Objectives,

• Core Components,

• Link to Business Drivers,

• Development Team Security Training Plan,

• Quality Assurance Plans, and,

• Development and Coding Standards.


Expected Outputs Project Charter and Project Definition Document

The project charter and definition document should:

• Identify sponsors and define their responsibilities,

• Assign Project Manager,

• Identify other stakeholders,

• Have an estimate of project costs,

• Provide processes and procedures for requirements management; project tracking,

contractor management, verification and validation, quality assurance, change

management, and risk management; and,

• Define Scope Boundary, including both in-scope and out-of-scope items.

Project Management Plan

The project management plan should:

• Define project schedule,

• Identify the resource requirement and allocated resources,

• Define Breakdown of tasks and their dependencies,

• Include cost estimation and project budget plan,

• Provide cost and schedule performance measurement,

• Schedule Milestones and reviews, and,

• Include an acquisition plan to define how the needed resources will be obtained and when.

The period of status reports should follow the procedures defined in project communication plan

which will vary between waterfall and agile development methodologies. It should provide the

sponsor and stakeholders with progress status of the project and compare the actual status with the

forecast.


Stakeholders Architects

Design system architecture, software components, etc.

Business Analyst

Provide requirements to the design team; review system design and artefacts.

The Business Analyst (BA) must first develop a plan for how the requirements analysis activity will be

accomplished.

The BA must then document the business process descriptions and collect the requirements of the

system from the Subject Matter Experts (SME’s) in a manner which allows traceability to documents

generated in previous activities and creates a framework for future activities.

All identified requirements should fall within the constraints of the project scope and align with the

customer’s statement of needs. The BA will generate a requirements traceability matrix which

becomes the basis for the system design.

Database Team

Assist with architecture design and data conversion strategy.

The most important role in this step is that of the Technical Architect as she aims to describe the

required functions and operations such as screen layout, business rules, and database layouts for the

system in detail and provide the architectural plan down to the physical level. A system architecture

is not only a product of requirements but equally a result of organizational goals, architect’s

experience and her technical environment.

Developer/Construction Team

Assist in finalizing data conversion strategy; review of the architecture and software components.

Other Stakeholders

If there are other stakeholders in the project, their requirements must be clearly identified.

Project Manager

The person with the overall responsibility and authority for the day-to-day activities associated with

a project. Finalize data conversion strategy and test strategy; review system design and artefacts.

The project manager is accountable for the success of this phase. The primary responsibility of the

Project Manager during Requirements Analysis is to ensure the Business Analyst(s) has access to the

proper: Subject Matter Experts, Business Process documentation, existing technology and potential

technological systems as well as current and desired artefacts. A major impediment to successful

requirements analysis is lack of exposure to any of the previously listed items

Project Sponsor

The principle authority on matters regarding the expression of business needs, the interpretation of

functional requirements language, and the mediation of issues regarding the priority, scope and

domain of business requirement.


Subject Matter Expert

The Subject Matter Expert understands the current business processes and any new requirements

that are to be satisfied by the project. They must work closely with the BA to transfer both stated

and tacit knowledge for inclusion in the Functional Requirements Documents

Testing Lead

The Testing Lead is involved during this activity to ensure that the requirements identified by the BA

and accepted by the customer are measurable and that IT has the resources to complete adequate

testing. Having the Testing Lead involved at this step allows for proper scheduling and preparation

for the various stages of testing that occur during the SDL.

Testing Team/Tester

Assist with identifying and finalizing testing strategy; review of the architecture and software

components.


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.