Notes - MCS
Robust Software
Notes - MCS
Robust Software
  • Robust Software
  • Secure Software Design Principles
    • Motivation
    • Secure and Resilient/Robust Software
    • Best Practices for Resilient Applications
    • Designing Applications for Security and Resilience
    • Architecture for the Web/Cloud
  • Software Security Lifecycle
    • Motivation
    • Secure Development Lifecycle
    • Software Security Touchpoints
    • Software Assurance Forum for Excellence in Code (SAFECode)
    • Secure SW Lifecycle Processes Summary
    • Adaptations of the Secure Software Lifecycle
    • Assessing the Secure Software Lifecycle
    • Recommendations
  • Software Quality Attributes
    • Motivation
    • Software Quality Assurance
    • Software Quality Standards
    • Software Quality Attributes
    • Extra Software Quality Assurance Properties
  • Security Requirements
    • Motivation
    • Security Requirements
    • Threats
    • Defenses
    • Confidentiality
    • Integrity
    • Availability
    • What about other goals/properties?
    • Security Requirements Engineering
    • Types of Security Requirements
    • Security Policy
    • Precision
    • Completeness and Consistency
    • Examples of Non-Functional Requirements
    • Goals and Requirements
    • Measures
    • Requirements Interaction
    • Natural Language Requirements
    • Best Practices
  • Common Software Attacks
    • Objectives
    • 10 Major Cyber-Attacks of 21st Century
    • Software Security Basics
    • Defenses Methods
    • SANS SWAT Checklist
  • Safe Programming
    • Secure Coding Practices
    • Top 10 Secure Coding Practices (CERT/SEI)
    • 7 Pernitious Kingdoms
  • Robustness, PenTest, Fuzzy and Static Code Analysis
    • Security/Robustness Testing
    • Robustness Tests Checklist Example
    • Penetration Testing
    • Penetration Testing Roadmap
    • Tools
    • Fuzz Testing
    • Static Code Analysis
    • Side Channels
  • Safety (and Security)
    • Safety
    • A safety Lifecycle Example
    • Risk Management Process
    • System Definition
    • Hazard Identification and Classification
    • Desk-based Hazard Identification
    • Workshop-based Hazard Identification
    • HAZOP
    • Hazard Identification and Classification
      • Broadly acceptable risks
    • Risk Evaluation and Risk Acceptance
    • Use of codes of practice
    • Use of reference system
    • Explicit risk estimation
    • Qualitative risk estimation
    • Quantitative risk estimation
    • Safety measures
    • Safety requirements
    • Hazard Management
    • Hazard life cycle
    • Independent Assessment
    • Safety Plan
    • Safety Case
    • FMEA Example
    • DevSecOps
Powered by GitBook
On this page
  • Requirements Precision
  • Stakeholder perspective
  • System perspective
  • Trades perspective
  • Transformation
  • Stakeholder requirements and Security Requirements
  1. Security Requirements

Security Requirements Engineering

Requirements engineering is the process of establishing:

  • the services that the customer requires from a system.

  • the constraints under which it operates and is developed.

Requirements Precision

Problems arise when requirements are not precisely stated.

Ambiguous requirements are interpreted in different ways by developers and users.

For example, 'recover password' from the previous slide:

  • User intention - mechanism which allows the user to view the password after going through an authentication procedure

  • Developer interpretation - allowing the user to reset their password so that it can be set again.

Thus, requirements shall be defined as precisely and clearly as possible.

Ideally, requirements should be both complete and consistent:

  • Complete - they should include descriptions of all facilities required.

  • Consistent - there should be no conflicts or contradictions in the descriptions of the system facilities.

In reality, it is very difficult/ impossible to produce a complete and consistent requirements document.

Stakeholder perspective

Mission/ business needs; operational performance objectives and measures; lifecycle concepts; laws; regulatory, statutory, and certification criteria; governing policies; loss and risk tolerance; accreditation, approval, and other independent authorization criteria; and all associated concerns and constraints.

System perspective

System self-protection capability, system architecture, system design, and system implementation decisions, developmental fabrication, manufacturing, and production standards, secure system management, technical performance objectives and measures, and all associated concerns and constraints.

Trades perspective

Requirements trades, engineering trades, risk treatment trades, and other lifecycle trades.

Transformation

Transformation of protection needs into security requirements and policy.

  • Security requirements specify security capability, performance, effectiveness, and the associated verification and validation measures, as well as constraints on system requirements.

  • Security policy consists of a well-defined set of rules that govern all aspects of the security-relevant behavior of system elements.

A requirement is a condition or capability that must be met or possessed by a system or system element to satisfy a contract, standard, specification, or other formally imposed document

- IEEE 610.12

Functional requirements specify capability and behavior while nonfunctional requirements specify quality attributes of the capability and behavior.

Stakeholder requirements and Security Requirements

  • Operational, protection, safety, and other needs (e.g. usability, human factors, form factor, and operational performance) and expectations of stakeholders, including legal, policy, regulatory, statutory, certification, policy, and other constraints for solutions that support the mission or business.

  • Provide the protection needed for the mission or business, the data information, processes, functions, human, and system assets; the roles, responsibilities, and security-relevant actions of individuals that perform and support the mission or business processes; the interactions between the security-relevant solution elements; and the assurance that is to be obtained in the security solution.

  • (security) Define the protection capabilities provided by the security solution; the performance and behavioral characteristics exhibited by the security solution; assurance processes, procedures, and techniques; and the evidence required to determine that the system security requirements have been satisfied.

  • Specify the capability and quality attributes of the delivered system.

Last updated 1 year ago