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
  • Examples
  • Response to threats
  1. Security Requirements

Threats

Examples

  • Advanced persistent threat

  • Backdoors

  • Bootkits

  • Computer crime

  • Viruses

  • Denial of service

  • Eavesdropping

  • Exploits

  • Keyloggers

  • Logic bombs

  • Malware

  • Payloads

  • Phising

  • Ransomware

  • Rootkits

  • Screen scrapers

  • Rootkits

  • Screen scrapers

  • Spyware

  • Trojans

  • Vulnerabilities

  • Web shells

  • Web application security

  • Worms

Response to threats

Possible responses to a security threat or risk can be:

  • Reduce/ mitigate - implement safeguards and countermeasures to eliminate vulnerabilities or block threats.

  • Assign/ transfer - place the cost of the threat onto another entity or organization such as purchasing insurance or outsourcing.

  • Accept - evaluate if the cost of the countermeasure outweighs the possible cost of loss due to the threat.

A parallel to Safety: SRAC - Safety Related Application Condition.

  • The concept of SRAC is defined on CENELEC EN50129 standard and it is the responsibility of RAMS/Safety Engineer to document and deliver to the user.

  • SRACs must be seen as a legal contract associated with the transfer of a device or an installation, with connotations related to safety.

  • Its importance requires robustness and its treatment must meet expectations regarding the implications that they entail.

  • SRACs clarify the safety responsibilities of the entities, in charge of the installation, maintenance and operation, that is, of the entire service cycle of the equipment or installation.

Last updated 1 year ago