Secure Software Design

Fuzz testing, Fuzzing

A black-box software testing technique that can be automated or semiautomated and provides invalid, unexpected, or random data to the inputs of a computer software program

Fuzz testing

A black-box software testing technique which can be automated which provides invalid, unexpected, or random data to the inputs of a computer software program

Attacker profile

A collection of information about a type of threat actor

Policy compliance analysis

A continuation of the A2 policy compliance review in which any policy that exists outside the domain of the SDL policy is reviewed

Sprint

A cycle of development during which chunks of code are built

Plan of action and milestone schedule

A detailed required document of the corrective measures planned to increase the effectiveness of the security controls and provide the requisite security for the software prior to its release

Service-level agreement (SLA)

A document or policy put in place to ensure that organizations providing services to internal and/or external customers maintain an appropriate level of service agreed on by both the service provider and the vendor

OWASP Software Assurance Maturity Model (SAMM)

A flexible and prescriptive framework for building security into a software development organization

User Story

A format to express functional and nonfunctional requirements for applications

SAFECode

A global, industry-led effort to identify and promote best practices for developing and delivering more secure and reliable software, hardware, and services

MITRE Corporation Common Computer Vulnerabilities and Exposures (CVE)

A list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems

Commercial Off-The-Shelf (COTS) and open-source software

A majority of software development organizations make use of code developed elsewhere

Waterfall development

A more traditional approach to software development which is typically higher-risk, more costly, less efficient, uses requirements that are already known, each stage is signed off before the next commences, and requires extensive documentation

Master test plan

A plan used to outline the entire test process; augmented by detailed test plans for individual test stages and individual modules

Software security policy

A policy intended to define what needs to be protected and how it will be protected, including reviewing and incorporating policies from outside the SDL that may impact the development process

ISO/IEC 27034-1:2011

A standard for application security which offers a concise, internationally recognized way to get transparency into a vendor/supplier's software security management process

ISO/IEC 27034

A standard that provides guidance to help organizations embed security within their processes that help secure applications running in the environment, including application lifecycle processes

ISO/IEC 27001

A standard that specifies a management system intended to bring information security under formal management control

Building Security In Maturity Model (BSIMM)

A study of real-world software security initiatives organized so that you can determine where you stand with your software security initiative and how to evolve your efforts over time

Product Security Incident Response Team (PSIRT)

A team dedicated solely to conduct security M&A assessments, third-party reviews, post-release certifications, internal reviews for new product combinations of cloud deployments, or review for legacy software that is still in use or about to be re-used

Agile method

A time-boxed iterative approach that facilitates a rapid and flexible response to change, which in turn encourages evolutionary development and delivery while promoting adaptive planning, development, teamwork, collaboration, and process adaptability throughout the lifecycle of the project

Penetration testing

A white-box security analysis of a software system to simulate the actions of a hacker, with the objective of uncovering potential vulnerabilities resulting from coding errors, system configuration faults, or other operational deployment weaknesses

Code review

Allows you to find and fix a large number of security issues before the code is tested or shipped

Open design

An access control system design evaluated and tested by a large number of experts providing a more secure authentication method than one that has not been widely assessed

Iterative Waterfall development model

An approach that carries less risk than traditional approaches but is more risky and less efficient and the overall project is divided into various phases, each executed using the traditional method

Formal business requirement

An artifact that lists software requirements and business risks mapped to the three pillars of information security: confidentiality, integrity, and availability

Third-party security assessment

An extensive review that will be conducted by your software security architect, a third party, or a combination of both

Scrum

An iterative and incremental Agile software development method for managing software projects and product or application development

Gray box

Analyzing the source code for the purpose of designing the test cases, but using black-box testing techniques; both the source code and executable binary are available for analysis

Test scenarios

Based on misuse and abuse possibilities developed through the methodologies and threat modeling; should incorporate both known attack patterns & anomalous interactions that seek to invalidate assumptions made by the software and environment

Building security in

Based on the idea that problems found early in the software lifecycle are significantly easier and less costly to correct than problems discovered post-implementation or post-deployment

Privacy Impact Assessment (PIA)

Before developing this component, you will need to evaluate what regulatory legislation or policies are applicable to the software you are developing, called the data sensitivity assessment

Software Security

Building security into the software through a SDL (Security Development Life Cycle) in an SDLC (Software Development Life Cycle)

Dashboard

By using the metrics in the SDL model, you will be able to provide information to your corporate management and internal customers as to the current state of your program which can be used to identify gaps used to justify headcount, funding, and other resources when needed

Major considerations when evaluating vendors

Certification, security policy, security awareness

Two very popular software security maturity models that have been developed and continue to mature at a rapid rate

Cigital BSIMM, OWASP Open SAMM

Other popular SDL models

Cigital Software Security Touchpoints model, OWASP SDL, Cisco Secure Development Lifecycle (CSDL)

SWE

Common Weakness Enumeration

Three core elements of security

Confidentiality, integrity, and availability (the C.I.A. model)

Important criteria in choosing a vendor to purchase a product

Cost, reputation, location, skilled and qualified staff

Considerations when comparing outsourced or in-house vendor support

Cost, warranty

Techniques used in penetrating valid channels of authentication

Cross-Site Scripting (XSS), Structured Query Language (SQL) injection, buffer overflow exploitation

Traditional organized crime syndicates

Cybercrime has evolved from the domain of individuals and small groups to these groups and criminally minded technology professionals working together and pooling their resources and expertise

NCSD

Department of Homeland Security National Cyber Security Division

NIST Special Publication (SP) 800-64, Security Considerations in the System Development Life Cycle

Developed to assist federal government agencies in integrating essential information technology security steps into their established IT system development lifecycle

Mixed source

Draws on the strengths of both open-source and proprietary software to deliver the highest value at the lowest cost; becoming a dominant practice in industry

Final security review

During this phase of software being developed, all of the security activities performed, including threat modeling, tools output, and performance against requirements defined early in the process, are assessed again to determine whether the software product is ready for release and shipping:

A4 Policy Compliance Analysis

During this phase, any policy that exists outside the domain of the SDL policy is reviewed (or reviewed again); this may include policies from outside the development organization

Functional Testing

Each feature, security or otherwise, must be thoroughly tested to prove that it works as designed

SDL Optimization Model

Enables development managers and IT policymakers to assess the state of the security in development

Authorization

Ensures that the user has the appropriate role and privilege to view data

Authentication

Ensures that the user is who he or she claims to be and that the data come from the appropriate place

Advantages of using third party software

Faster delivery, proven solutions, interoperability, cheaper

Lean

Focuses on features rather than groups of features, you select, plan, develop, test, and deploy one feature before you select, plan, develop, test, and deploy the next feature

Bugtraq IDs

Identifiers for a commercially operated vulnerability database that are used in security advisories and alerts, as well as for discussions on the mailing list

Quality assurance (QA)

In a typical SDLC cycle, software goes through testing that includes unit, performance, system, and regression testing

Quality and security

In terms of coding defects, the product not only has to work right, it also has to be secure

Senior software security architects

Individuals who have five to ten years of development/coding experience before they come into the security field, and who are also experienced in the areas of software, networking, and cloud/SaaS architectural design

Real disadvantages to using third party software

Inflexibility, do business their way, unknown functionality, no visibility into source code, cost, licensing, maintenance

ISMS

Information Security Management System

ISO/IEC

International Standards Organization (ISO) / International Electrotechnical Commission (IEC)

Kick-off meetings

It is important in initial formalized meetings, when the software security team is included, to ensure that security is a key element of the SDLC and is built into the process

Weakest link

It is important to identify the mechanisms in the security chain and layers of defense and improve them so that risks to the system are mitigated to an acceptable level

Third-party code reviews

Many companies use these to help identify these situations rather than spend the limited resources of their internal teams

NIST

National Institute of Standards and Technology

NSA

National Security Agency

P3: Low Privacy Risk

No behaviors exist within the feature, product, or service that affect privacy. No anonymous or personal data is transferred, no PII is stored on the machine, no settings are changed on the user's behalf, and no software is installed

OWASP

Open Web Application Security Project

Vulnerabilities

Out of the population of extant errors, some proportion will have effects that can be manipulated to the advantage of an attacker

PII

Personally identifiable information

PITAC

President's Information Technology Advisory Committee

PSIRT

Product incident response team

COTS

Products already approved, Commercial Off the Shelf

Challenges of using proprietary software

Proprietary format, increased license fees, end of support

Application Security

Protecting the software and the systems on which it runs after release

Common Vulnerability Scoring System (CVSS)

Provides an open framework for communicating the characteristics and impacts of IT vulnerabilities

Principle of least privilege, principle of minimal privilege, principle of least authority

Requires that in a particular abstraction layer of a computing environment, every module must be able to access only the information and resources that are necessary for its legitimate purpose

Product Security Incident Response Team (PSIRT)(2)

Responsible for responding to software product security incidents involving external discoveries of post-release software product security vulnerabilities

Leveraging existing components

Reviewing the state and settings of the extant security mechanisms and ensuring that they are operating at their optimum design points will greatly improve the security posture of an information system

Concerns of security in third party software

Secure development environment, malware implanted during development, trusted distributions of software, digital "shrink-wrap"

SCAP

Security Content Automation Protocol

SDL

Security Development Life Cycle

Additional considerations when evaluating vendors

Security engineering processes, requirements gathering, ability to work with business representatives, SDLC methodology and maturity

Test environment

Should duplicate the anticipated execution environment in which the software will be deployed, and be kept entirely separate from the development environment

"Trust but verify"

Since secure coding is still very much an art, with local language and runtime variations adding to complexity, a strong, real-world SDL operates by this idea

Bug

Since the dawn of the software industry, software engineers adopted this term meaning "software error"

Part of a certification process by a third party to evaluate a vendor

Social media comments, track record, incidents, crisis communication, security breaches

SDLC

Software Development Life Cycle

GOTS

Software used in government systems, Government Off the Shelf

Security or privacy certifications

Standards that could become necessary for a software product to comply with post-release requirements due to market or use-case changes

Issues commonly addressed in SLAs

System uptime, maximum consecutive downtime, peak load, average load, responsibility for diagnostics, failover time.

White box

Testing from an internal perspective, i.e., with full knowledge of the software internals; the source code, architecture and design documents, and configuration files are available for analysis

Black box

Testing the software from an external perspective, i.e., with no prior knowledge of the software; only binary executable or intermediate byte code is available for analysis

Software Assurance Program

The SwA Program seeks to reduce software vulnerabilities, minimize exploitation, and address ways to improve the routine development and deployment of trustworthy software products

National Vulnerability Database (NVD)

The U.S. government repository of standards-based vulnerability management data

Legacy code

The acceptance of this is based on an assumption of what is expected to happen, in that the software must be proven to be functionally correct and operationally viable

Dynamic program analysis

The analysis of computer software that is performed by executing programs on a real or virtual processor in real time

Dynamic program analysis, dynamic application security testing (DAST)

The analysis of computer software that is performed by executing programs on a real or virtual processor in real time:

Static program analysis

The analysis of computer software that is performed without actually executing programs

Static program analysis, Static application security testing (SAST)

The analysis of computer software that is performed without actually executing programs

Attack surface

The entry points and exit points of an application that may be accessible to an attacker

Discovery

The essential meeting an SDL kick-off meeting where the key SDLC stakeholders get on the same page at the beginning of the process so that security is built in rather than bolted on post-release

P1: High Privacy Risk

The feature, product, or service stores or transfers personally identifiable information (PII), changes settings or file type associations, or installs software

Penetration test report

The final deliverable of the penetration test should focus on what data was compromised and how, provide the customer with the actual method of attack and exploit, along with the value of the data exploited

Data flow diagram (DFD)

The first step of the threat modeling process; to develop a visual representation of the threat flows, typically drawn during a whiteboard session

Analysis phase

The phase that determines how PII will be handled to ensure that it conforms to applicable legal, regulatory, and policy requirements regarding privacy

Least privilege

The principle that maintains an individual, process, or other type of entity should be given the minimum rights and resources for the minimum period of time required to complete a task

Software Assurance Metrics And Tool Evaluation (SAMATE)

The project dedicated to improving software assurance by developing methods to enable software tool evaluations, measuring the effectiveness of tools and techniques, and identifying gaps in tools and methods

Functional requirements

The requirements that describe what an application must do to serve a business need

Nonfunctional requirements (NFRs)

The requirements which address how well the functional requirements are met, or they constrain the functional requirements to specified operating ranges

Key Success Factors/Success Criteria

The setting of this criteria for any SDL phase will make it more effective and will help in performing post-mortem afterwards to understand what worked and what didn't

P2: Moderate Privacy Risk

The sole behavior that affects privacy in the feature, product, or service is a one-time, user-initiated, anonymous data transfer

Deliverables

The tangible documented outcome of all required activities

Trustworthy Computing (TwC)

The team which formed the concepts that led to the Microsoft Security Development Lifecycle

Software security champion (SSC)

There will ideally be one of these roles per Tier 1 software product within each engineering software product development group

Exceptions

These are made because the remediation will prevent optimal software performance, restrict a critical function in the product, or even require a complete architecture redesign

Socio-political attacks

These attacks are often intended to elevate awareness of a topic but can also be a component or a means to an end with regard to political action groups, civil disobedience, or part of a larger campaign

Strategic attacks

These attacks are typically planned and controlled to target information assets including specifications, technologies, plans, capabilities, procedures, and guidelines to gain advantage

Vulnerability scanners

These can carry out complex and comprehensive data flow analysis to identify vulnerability points that might be missed in the course of manual human review

User-targeted attacks

These specific software attacks can be strategic, tactical, or opportunistic and may involve targeting a privilege escalation of a specific user that exploits a vulnerability in software to gain access to resources and information that would normally be unrestricted

Benchmarks

These tests are used to compare estimates to actual results

Exploratory

These tests emphasize the personal freedom and responsibility of the individual tester to continually optimize the quality of his or her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project

Scheduled

These tests include mandatory requirements to validate the security of the software and associated system being tested, which must be conducted regardless of whether security issues or vulnerabilities are detected or tuning is required

Tactical cyber attacks

These threats are typically surgical by nature, have highly specific targeting, and are technologically sophisticated

SDL policy compliance

This SDL component covers all projects that have meaningful security and privacy risks and is analyzed in each phase and updated to cover new threats and practices

Project plan

This SDL component should outline security milestones based on the information gained during the previous phase and integrate them into the overall SDLC schedule to allow proper preparation as changes occur

Threat modeling(2)

This exercise requires a special set of skills, experience, and mindset, and the team must be able to think like an adversary. A senior software security architect or a seasoned software security champion typically runs this aspect

Software security evangelist (SSE)

This individual has two roles, as an SSC in training and as an evangelist for the overall software product security program promulgated policy, enforcing policy, and evangelizing the overall SDL process

Fuzz testing, Fuzzing(2)

This is a Black Box software testing technique, which basically consists of finding implementation bugs using malformed/semi-malformed data injection in an automated fashion

Cyber spying, cyber espionage

This is the act or practice of obtaining secrets without the permission of the holder of the information for advantage using methods on networks or computers through the use of cracking techniques and malicious software

Defense in depth

This is the application of multiple layers of protection, such that a subsequent layer will provide protection if a previous layer is breached

Technical debt

This is the difference between what was delivered and what should have been delivered

Fail safe

This means that if a system encounters a fault, it reverts to a state where the security of the system and its data are not compromised

Separation of duties

This principle requires that completion of a specified sensitive activity or access to sensitive objects is dependent on the satisfaction of multiple conditions

Least common mechanism

This principle states that a minimum number of protective mechanisms should be common to multiple users, as shared access paths can be sources of unauthorized information exchange

Economy of mechanism

This promotes simple and comprehensible design and implementation of protection mechanisms, so that unintended access paths do not exist or can be readily identified and eliminated

Dynamic testing

This refers to executing the source code and seeing how it performs with specific inputs

Psychological acceptability

This refers to the ease of use and intuitiveness of the user interface that controls and interacts with the access control mechanism

Post-release privacy response

This response should be built into the PSIRT process just as security should be built into the SDLC

Software security champions (SSCs)

This role should have a minimum of 3-5 years of software development experience; a background in software security; trained in software security and software security tools, plans, & processes; and must know how to develop software and how to deconstruct while "thinking like a hacker" regarding all possible paths or exploits that an adversary could take

Open-source

This software is free and it increases innovation, efficiency, and competitiveness for software product development

ISO Standard on Vulnerability Disclosure (29147)

This standard provides guidance on how vendors should deal with vulnerability reports from external finders and the recommended process for interfacing between vendors and the external discoverers or finders

ISO Standard on Vulnerability Handling Processes (30111)

This standard provides guidance on how vendors should investigate, triage, and resolve all potential vulnerabilities, whether reported by external finders or via the vendor's internal testing

Cyber war

This term gives the impression that the conflict is happening only online, when in fact a more accurate interpretation is weapons are used in the digital theater of conflict that can be strategically aligned with traditional (physical) warfare activities

Attack and penetration (A&P) testing

This type of testing involves a skilled human tester who behaves like the most skilled and sophisticated attacker

Software risk-based security testing

This type of testing should always augment traditional requirements-based testing

Privacy requirement verification

This verification is typically verified concurrently with the final security review and in many cases is now considered part of the same process

Risks

Threats become these and vulnerabilities are equated to the same in isolation

Merger and acquisition (M&A)

To be competitive, most companies want to develop new products and access new markets and will seek alternatives when they cannot do this with their current resources

Meaningful security metrics

To measure the security posture of an organization effectively, product security must first ensure that the proper framework is in place, minimizing the remaining defects that lead to vulnerabilities

Threat modeling

To understand the potential security threats to the system, determine risk, and establish appropriate mitigations. Applies principles such as least privilege and defense-in-depth; requires human expertise and not tools to accomplish

Static analysis tools

Tools that look for a fixed set of patterns or rules in the code in a manner similar to virus-checking programs

The most well-known SDL model

Trustworthy Computing Security Development Lifecycle (SDL)

Manual security code review

Typically done as a line-by-line inspection of the software to determine any security vulnerabilities in the software product

Virtual team

Unlike a fully centralized function, this type of team, handled with care, can be coalesced and led by a far smaller central team

False positives

Vulnerabilities where the scanner has identified the software as being vulnerable when, in fact, it is not

Complete mediation

Where every request by a subject to access an object in a computer system must undergo a valid and effective authorization procedure

CPO

chief privacy officer

DAST

dynamic application security testing

GRC

governance/risk/compliance

SAST

static application security testing