Domain 3: Secure Software Requirements

General Requirements knowledge

The two types of software requirements are:

  • Functional: Functional requirements describe how the software is supposed to do its job. These include business requirements, IT requirements (deployment environment, database, infrastructure, etc.), corporate coding, and security requirements. Functional requirements are often described in use cases or user stories.

  • Non-Functional: Non-functional requirements include operational and deployment requirements. These describe how the software will fit into an organization’s IT infrastructure and interact with other software and systems.

A requirements traceability matrix (RTM) helps to track the state of requirements for software. An RTM commonly contains columns for:

  • Business Requirements: Describes the initial business need

  • Functional Requirements: Describes the functional requirement developed to meet the business need

  • Test Requirements: Describes how the functional requirement will be tested

The RTM may also contain requirement ID numbers, use cases, or other information linked to the requirement.

Security requirements should flow down to supplier/providers. The Open Web Application Security Project (OWASP) has developed sample contractual terms based on six key philosophies:

  • Security Decisions Will Be Based on Risk

  • Security Activities Will Be Balanced

  • Security Activities Will Be Integrated

  • Vulnerabilities Are Expected

  • Security Information Will Be Fully Disclosed

  • Only Useful Security Documentation is Required

Misuse case diagrams describe explicitly prohibited activities that a user might take. They are developed during the requirements phase to guide the design of the software.

Information Lifecycle Management (ILM) addresses various aspects of data management, including security. The information lifecycle has three main stages:

  • Generation: When data is created, it should be appropriately classified and stored.

  • Retention: While data is needed and in active use, it should be encrypted while at rest and in transit and be protected by access controls.

  • Disposal: When data is no longer needed, it should be disposed of securely.

Intellectual property (IP) can be protected in various ways, including:

  • Patent: A patent provides exclusive rights to an invention for a specified period of time. Patents can be used to prevent others from using an invention even if they claimed to have invented it independently.

  • Copyright: A copyright protects written works and artistic expression from being used or copied without the creator’s consent and proper attribution. They limit adaptations, performances, and who can profit from the work.

  • Trademark: A trademark protects brand association and can be either registered or common-law. Images and company names are commonly trademarked items.

  • Trade Secret: A trade secret is intellectual property that is protected only as long as it remains secret. The Cola-Cola secret recipe is probably the most famous example of a trade secret.

Some methods by which organizations can protect data from unauthorized access and disclosure include:

  • Data Minimization: Data minimization involves collecting, processing, and storing the minimum data required. It is the most effective data protection mechanism because an organization can’t breach or misuse data that it doesn’t have.

  • Data Masking: Data masking involves hiding part or all of the sensitive data, such as replacing most of a credit card number with asterisks on a receipt.

  • Tokenization: Tokenization uses a random value to represent sensitive data in insecure locations. The actual values can be looked up based on the token value as needed.

  • Anonymization: Anonymization involves removing any data from a record that can be used to uniquely identify an individual. This is difficult as even combinations of non-identifying characteristics can be combined to uniquely identify an individual.

Data can be labeled based on:

  • Sensitivity: An organization may have various types of sensitive data that should be accessible to different parties. For example, HR may be the only one with access to employee records, while the financial department manages payroll records.

  • Impact: Impact describes the magnitude of the potential effects if corporate data is mishandled. Impact is commonly labeled as high, medium, or low, and organizations may have multiple impact labels for confidentiality, integrity, etc.

The data custodian is responsible for the day-to-day management of data. This can include implementing the access controls, backup systems, and retention policies defined by the data owner.

The data subject is the customer whose data is collected and processed by an organization. The data owner controls access to data and acts in the best interest of the organization. They are responsible for defining access controls, backup requirements, and retention policies.

A Subject/Object/Activity matrix is used to describe what activities users (subjects) are permitted to take on objects. Actions/activities are defined for a particular object, and then access controls are used to restrict the actions that a particular user can take.

Sequencing deals with the possibility that the order in which certain operations are performed could vary on a multi-threaded computer. If this can impact the functionality or security of the software, it is referred to as a race condition.

NIST and Federal Standards

The National Institute of Standards and Technology (NIST) is a United States government agency that defines standards that govern federal agencies and act as a reference for the public sector. NIST publishes a few standards relevant to software security, including:

  • Federal Information Processing Standards (FIPS): FIPS are mandatory standards for US government agencies and some federal government contractors

  • Special Publication 500 (SP 500): The SP 500 series of NIST publications describes general Information Technology requirements

  • Special Publication 800 (SP 800): The SP 800 series outlines research and best practices for information security

NIST’s FIPS standards define security requirements for government agencies and contractors. Some significant FIPS standards include:

  • FIPS 140: Security Requirements for Cryptographic Modules

  • FIPS 186: Digital Signature Standard (DSS)

  • FIPS 197: Advanced Encryption Standard (AES)

  • FIPS 199: Standards for Security Categorization of Federal Information and Information Systems

  • FIPS 200: Minimum Security Requirements for Federal Information and Information Systems

The Federal Information Security Management Act of 2022 (FISMA) makes an information security program mandatory for all federal agencies. The National Institute of Standards and Technology (NIST) developed a risk management framework (RMF) for FISMA that is published in NIST SP 800-39 and includes six steps for risk management, including:

  1. Categorize information systems

  2. Select security controls

  3. Implement security controls

  4. Assess security controls

  5. Authorize information systems

  6. Monitor security controls

NIST’s SP 800 series outlines best practices for information security. A few significant NIST SP 800 publications include:

  • NIST SP 800-12: An Introduction to Computer Security

  • NIST SP 800-18: Guide for Developing Security Plans for Federal Information Systems

  • NIST SP 800-30: Guide for Conducting Risk Assessments

  • NIST SP 800-53: Security and Privacy Controls for Information Systems and Organizations

  • NIST SP 800-63: Digital Identity Guidelines

  • NIST SP 800-100: Information Security Handbook: A Guide for Managers

  • NIST SP 800-107: Recommendations for Applications Using Approved Hash Algorithms

  • NIST SP 800-152: A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS)

ISO/IEC

ISO/IEC 15408: Information technology — Security techniques — Evaluation criteria for IT security defines the Common Criteria used to evaluate security technologies. The Target of Evaluation (TOE) has associated security properties or a Security Target (ST), and each type of solution (firewall, operating system, etc.) has a Protection Profile (PP) it must meet. The end result of an evaluation is one of the following Evaluation Assurance Level (EALs):

  • EAL 1: Functionally Tested

  • EAL 2: Structurally Tested

  • EAL 3: Methodically Tested and Checked

  • EAL 4: Methodically Designed, Tested, and Reviewed

  • EAL 5: Semiformally Designed and Verified

  • EAL 6: Semiformally Verified, Designed, and Tested

  • EAL 7: Formally Verified, Designed, and Tested

ISO/IEC 33001:2015 Information Technology – Process Assessment defines methods for Software Process Improvement and Capability Determination (SPICD). It defines capability levels as:

  • Level 5: Optimizing Process

  • Level 4: Predictable Process

  • Level 3: Established Process

  • Level 2: Managed Process

  • Level 1: Performed Process

  • Level 0: Incomplete Process

The ISO/IEC 2700X series of standards lays out guidance for information security management systems. Its standards include the following:

  • ISO/IEC 27000:2018: Information technology — Security techniques — Information security management systems — Overview and vocabulary

  • ISO/IEC 27002:2013: Information technology — Security techniques — Code of practice for information security controls

  • ISO/IEC 27003:2017: Information technology — Security techniques — Information security management systems — Guidance

  • ISO/IEC 27004:2016: Information technology - Security techniques - Information security management - Monitoring, measurement, analysis and evaluation

  • ISO/IEC 27005:2018: Information technology — Security techniques — Information security risk management

ISO/IEC 25010:2011: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models replaces ISO/IEC 9126 and defines metrics for measuring the quality of software systems. The eight quality characteristics that it defines are:

  • Functional Suitability

  • Reliability

  • Performance Efficiency

  • Usability

  • Security

  • Compatibility

  • Maintainability

  • Portability

ISO/IEC 21827 is Information technology — Security techniques — Systems Security Engineering — Capability Maturity Model.

Industry Standards and Regulations

The Sarbanes-Oxley Act of 2022 (SOX) is an anti-fraud regulation developed in response to corporate scandals. Publicly-traded companies are required to have integrity protections for accounting data to verify the accuracy of reported data.

The Gramm-Leach-Bliley Act (GLBA) or the Financial Modernization Act of 1999 is intended to protect personal financial information (PFI).

The Health Insurance Portability and Accessibility Act (HIPAA) is a U.S. regulation that covers protected health information (PHI). The Health Information Technology for Economic and Clinical Health Act (HITECH Act) is a related law governing the use of electronic health records.

The Payment Card Industry Data Security Standard (PCI DSS) was implemented by major payment card brands to fight payment card fraud and protect cardholders’ personal data. The Payment Application Data Security Standard (PA DSS) is related to PCI DSS. It ensures that applications processing payment card data comply with PCI DSS requirements.

The Gramm-Leach-Bliley Act (GLBA) or the Financial Modernization Act of 1999 is intended to protect personal financial information (PFI). It includes many rules, including:

  • Financial Privacy Rule: Controls collection and disclosure of PFI

  • Safeguards Rule: Discusses design, implementation, and maintenance of PFI safeguards

  • Pretexting Protections: Rules about pretexting or falsely pretending to access PFI

The Payment Card Industry Data Security Standard (PCI DSS) was implemented by major payment card brands to fight payment card fraud and protect cardholders’ personal data. It includes twelve high-level requirements divided into six control objectives:

Build and Maintain a Secure Network

1. Install and maintain a firewall configuration to protect cardholder data

2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

3. Protect stored cardholder data

4. Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

5. Use and regularly update anti-virus software or programs

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures

7. Restrict access to cardholder data by business need to know

8. Assign a unique ID to each person with computer access

9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks

10. Track and monitor all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an Information Security Policy

12. Maintain a policy that addresses information security for all personnel

The General Data Protection Regulation (GDPR) is an EU data privacy law that went into effect in May 2018. It protects the personally identifiable information (PII) of EU citizens. The GDPR and laws based on it provide various rights to data subjects, including:

  • Consent: Under the GDPR, data subjects must be informed of how their data will be used and provide affirmative consent (opt in) before data collection begins.

  • Access: The GDPR allows users to request a copy of the data that a company has stored about them in a usable format.

  • Correction: EU subjects can require organizations to correct inaccuracies in their records.

  • Disposition: The GDPR includes the “right to be forgotten” or to have their data erased by companies that have collected it.

  • Retention: Under the GDPR, organizations must delete collected data after the original purpose for collecting and processing it no longer exists.

  • Data Residency: The data of EU citizens cannot be transferred to countries or companies without privacy protections equivalent to those provided by the GDPR.

The Organization for the Advancement of Structured Information Standards (OASIS) develops open standards for information security. Some relevant OASIS standards include:

  • Application Vulnerability Description Language (ADVL)

  • Security Assertion Markup Language (SAML)

  • eXtensible Access Control Markup Language (XACML)

  • Key Management Interoperability Protocol (KMIP) Specification

  • Universal Description, Discovery, and Integration (UDDI)

  • Web Services (WS-*) Security

Last updated