Domain 1. Secure Software Concepts

Core Concepts (C-I-A)

• Confidentiality: preventing the disclosure of information to unauthorised parties.
  • A loss of confidentiality is the unauthorised disclosure of information.
• Integrity: protecting data from unauthorised alteration.
  • A loss of integrity is the unauthorised modification or destruction of information.
• Availability: a system being available to authorized users when appropriate.
  • A loss of availability is the disruption of access to or use of information or an information system.

Action-Oriented Core Concepts

• Authentication: the process of validating an entity’s claim of identity.
  • Authentication factors:
    • Knowledge
    • Ownership
    • Characteristics
  • New emerging factors:
    • Behaviour
    • Location
• Authorisation: the process of validating an entity’s access to resource.
  • Subject-Object-Action model:
    • Subject: the requesting entity
    • Object: the requested entity
    • Activity: the requested access rights
• Accountability: the measurement of an entity’s activities.
  • Non-repudiation: an entity should not be able to deny its activities.
    • Auditing: detective, can also be deterrent
    • Identification
  • Key components:
    • Monitoring
    • Detection
    • Response
  • Challenges:
    • Performance
    • Information overload
    • Capacity limitation
    • Configuration interfaces protection
    • Audit log protection

Common Challenges

• Iron Triangle Constraints
  • Project perspective:
    • Schedule
    • Scope
    • Budget
  • Product perspective:
    • Functionality
    • Usability
    • Security
• Security is often an afterthought

Adversaries

• Adversary Types:

• Adversary Groups:

• Insider vs. Outsider Threat
• Threat Landscape Shift
  • Originally defined by actors and motivation
  • Criminalisation of cyberspace: everything becomes a target
  • The latest shift is toward individuals, detection becomes difficult

Security Models

• Security models provide:
  • Steps required to develop secure software
  • Blueprint for security policy implementation
  • Description of system operations w.r.t desired characteristics
• Multilevel Security Model: a descriptive model of security where separate groups (containers) are given labels, thus keeping information and processes separated based on the labels.

Confidentiality Model

• Bell-LaPadula Confidentiality Model
  • A confidentiality preserving model that employs both mandatory and discretionary access controls.
  • Two basic principles:
    • Simple Security Rule (no-read-up): no subject can read from an object with a higher security classification.
    • Star property (no-write-down): no subject can write to an object with a lower security classification.
• Take-Grant Model
  • A theoretical model, built upon graph theory, based on mathematical representation of the controls in the form of a directed graph.
    • Vertices: subjects and objects
    • Edges: rights (i.e: Take, Grant, Read, Write)
  • Advantage: can be used to definitively determine rights.
  • Not particularly used for implementation, but used for analysis.

Integrity Models

• Biba Integrity Model
  • Integrity levels: indicate the level of “trust”, used to separate permissions.
    • Higher integrity level means more reliable.
  • 1st rule (low-water-mark policy) (no-write-up): no subject can write to an object with a higher integrity level.
  • 2nd rule (no-read-down): reading from an object with a lower integrity level lowers down the integrity level of the subject.
• Clark-Wilson Model
  • A transaction-based model that ensures the integrity of commercial data.
  • Two levels of integrity:
    • Constrained Data Items (CDI): is subject to integrity controls
    • Unconstrained Data Items (UDI): is not subject to integrity controls
  • Two types of processes:
    • Integrity Verification Processes (IVPs)
      • Ensure that CDI data meets integrity constraints
    • Transformation Processes (TPs)
      • Change the state of data
      • Data cannot be modified directly by a user

Information Flow Models

• Brewer-Nash Model (Chinese Wall)
  • A model designed to enforce confidentiality in commercial enterprise operations to mitigate conflict of interest.
  • The model exercises Separation of Duties.
  • Involves three elements:
    • Technology
    • People
    • Process
• Data Flow Diagrams
  • Designed to document the states of data in a system.
  • Levels:
    • Level 0: highest, contextual view
    • Level 1: medium, expected from level 0
    • Level 2: lowest, expended from level 1
• Use Case Models
  • The use case (normal and abnormal) model examines the system from a functional perspective.
• Assurance Models
  • Software assurance: the level of confidence that software is free from vulnerabilities and functions as expected.
  • Assurance case: consists of a set of arguments and requires evidence to demonstrate specific security claims.
    • Bbjective
    • Evidence: demonstrates the elimination of undesirable behaviours and preservation of the desired behaviours.
    • Confirmation
• Operational Security Model
  • Three primary methods:
    • Prevention
    • Detection
    • Response
  • Protection = Prevention + Detection + Response
    • Prevetion => Access Control, Firewalls, Encryption
    • Detction => Audit Logs, Intrusion Detection Systems, Honeypots
    • Response => Backups, Incident Response, Computer Forensics
• NIST Cybersecurity Framework (CSF) Model
  • NIST CSF provides a policy framework for private sectors in US to assess and improve their security capability.
  • Five functions: Identify, Protect, Detect, Respond, Recover

Risk Assessment & Risk Management

• Risk Assessment:
  • The process of analysing an environment to identify the risks and mitigations.
• Risk Management:
  • The process of identifying, controlling, and eliminating or minimizing uncertain events that may affect system resources.
  • Improves the future, not explaining the past.
  • To make Redisual Risk within acceptable range.
• Types of Risk:
  • Systematic:
    • Predictable
    • e.g fire, theft, bugs
  • Unsystematic:
    • Unpredictable
    • e.g recession, epidemics, protocol design errors
  • Business Risk: associated with the operation of the business
    • Treasury management
    • Revenue management
    • Contract management
    • Fraud
    • Regulatory
    • Business continuity
    • Technology
  • Technology Risk: a major subject of business risk
    • Security
    • Privacy
    • Project risk management
    • Change management
• Standard categories of risk associated with impact analysis
  • Financial, People, Customer
• Common Practices:
  • Risk analysis
  • Cost-benefit analysis
  • Selection
  • Implementation and testing
  • Security evaluation of safeguards
  • Overall security review
• Protection Priority:
  • 1st, people
  • 2nd, data
• Challenges:
  • Risk management is still maturing
  • Asset value is subjective
  • Technical aspect is only a portion
  • Data is limited
• Glossary:
  • Asset: any resource or information an organisation needs to conduct its business.
    • Tangible: people, data
    • Intangible: reputation
  • Risk: the possibility of suffering harm or loss.
  • Inherent risk: the risk before any controls are introduced to reduce the risk.
  • Residual risk: the risk that remains after a control is utilised.
  • Total risk: the sum of all risks.
  • Threat: any circumstance or event with the potential to cause harm to an asset.
  • Vulnerability: any characteristic of an asset that can be exploited by a threat to cause harm.
  • Attack: the instance of attempting to perform undesired or unauthorised activities via a vulnerability.
  • Impact: the loss resulting when a threat exploits a vulnerability.
  • Mitigation: any action taken to reduce the likelihood or impact of a threat.

Risk Controls

• Controls: the measures taken to detect, prevent, or mitigate the risks associated with the threats a system faces.
  • Security controls do not remove the threats, but reduce the likelihood and impact.
  • Improper implementation of controls may become a threat.
  • Countermeasures: the controls applied after a threat has been materialised, reactive.
  • Safeguards: the controls applied before a threat is materialised, proactive.
• Classes
  • Administrative
  • Technical
  • Physical
• For each class, there are 4 types
  • Preventative (deterrent): proactive
  • Detective: reactive
  • Corrective (recovery): reactive
  • Compensating: reactive
• Risk Handling
  • Ignore: neglect the risk
  • Avoid: discontinue with the software
  • Mitigate: implement controls
  • Accept: when cost to mitigate outweight the gain, can accept
  • Transfer: insurance, disclaimers (transfer to end user)
    • using 3rd party assessor is not transfering risk, only showing due diligence
    • any liability must be explicitly stated and contractually enforceable

Qualitative v.s Quantitative Risk Management

• Purpose:
  • Allow the prioritisation of resource employment.
  • Iidentify the appropriate use of limited resources to reduce risk.
  • Key determinant: criticality of information.
• Qualitative: subjective, relies on expert judgement.
  • Two elements used: impact, likelihood
  • Using simple measures: low, medium, high
  • Qualitative Matrix by Federal Information Processing Standard (FIPS) 199
  • Failure Mode Effects Analysis (FMEA)
    • A structured methodology for the assessment of failure modes and their effects on the system.
    • Ranking risks in a system: risk = severity * probability * detectability
• Quantitative: objective, relies on historical data, metrics and models.
  • Exposure Factor (EF): a measure of the magnitude of loss of an asset.
  • Single Loss Expectancy (SLE): the monetary loss or impact of each occurrence of a threat.
  • Annualised Rate of Occurrence (ARO): the frequency with which an event is expected to occur on an annualised basis.
  • Annualised Loss Expectancy (ALE): how much an event is expected to cost per year.
  • SLE = Asset Value * Exposure Factor
  • ARO = #evets / #years
  • ALE = SLE * ARO
  • Risk = Probability(R, E, DI) * Impact(D, A)
    • Probability: Reproducibility (R), Exploitability (E), Discoverability (DI)
    • Impact: Damage Potential (D), Affected Users (A)
  • Residual Risk Model
    • Absolute Security: residual risk will not be zero
    • Major issue of Defense in Depth and Quantitative Risk Management: lack of full understanding of the inter-dependency between components and scale to model all conditions.

Risk Management Models

• General Risk Management Model
  1. Asset Identification
     • Asset classification: classify assets by information criticality w.r.t the business objectives
  2. Threat Assessment
     • Identify likelihood
  3. Impact Determination and Quantification
     • Identify impact
  4. Control Design and Evaluation
     • Controls can be actions, devices, or procedures
     • NIST SP 800-53 gives a list of comprehensive controls
  5. Residual Risk Management
     • Risks cannot be completely eliminated
     • Evaluate residual risks to identify additional controls
• Software Engineering Institute (SEI) Model - Continuous Risk Management Guidebook
  1. Identify: examine the system, enumerating potential risks
  2. Analyse: convert the risk data gathered into information that can be used to make decisions
     • Evaluate the impact, likelihood and time frame of the risks
     • Classify and prioritise each risk
  3. Plan: review and evaluate the risks and decide what actions to take to mitigate them
     • Implement the plan
  4. Track: monitor the risks and the mitigation plans.
     • Trends may provide information to activate plans and contingencies
     • Review periodically to measure progress and identify new risks
  5. Control: make corrections for deviations from the risk mitigation plans
     • Correct products and processes as required
     • Changes in business may require adjustments in plans or actions

Governance, Risk, and Compliance (GRC)

• Two types of Compliance:
  • Compliance: activities associated with external requirements.
  • Conformance: activities associated with internal requirements.
  • Priority: Compliance > Conformance, penalty-driven.
  • Senior management is responsible for all residual risks.
  • Development effort needs to be mapped to regulatory requirements.
• Legal, two issues of significant risks:
  • Intellectual Property (IP): need both legal and prevention controls.
  • Data breach:
    • Loss of PII implies additional legal issues.
    • Legal issues and consequences can be used to prioritise the controls.
    • Two strategies w.r.t PII:
      • Prevention
      • Encryption

Regulations and Privacy Acts

• Mandates a check-and-balance mechanism to earn stakeholder trust and prevent infromation disclosure.
  • Personally Identifiable Inforamtion (PII)
  • Personal Heath Inforamtion (PHI)
  • Personal Financial Inforamtion (PFI)
• Challenges with Regulatory Mandates
  • Open interpretations
  • Auditor’s subjectivity
  • Localized jurisdiction
  • Regional variations
  • Inconsistent enforcement

Federal Information Security Management Act (FISMA) - PII

• FISMA 2002: mandates federal agencies to implement an agency-wide information security program.
• NIST Risk Management Framework (RMF):
  • Inventory of systems
  • Categorize information and systems according to risk level
  • Security controls
  • Certification and accreditation of systems
    • Including risk assessment and system security plans
  • Training
  • Information Security Automation Program
  • Security Content Automation Protocol (SCAP)
• NIST SP 800-39: structured methodology of managing information security risks.
  • Categorize information systems
  • Select security controls
  • Implement security controls
  • Assess security controls
  • Authorize information systems
  • Monitor security controls

Data Protection Act - PII

• Regulate the collection, processing, holding, using and disclosure of PII.
• Software need to be designed with deletion or de-identification mechanisms.
• European Union Personal Data Protection Directive (EUDPD) declares PII as human rights.
• Canadian Equivalent: Personal Information Protection and Electronics Document Act (PIPEDA)

Computer Misuse Act - PII

• Makes provisions for securing computer material against unauthorised access and/or modification.

Mobile Device Privacy Act - PII

• Require vendors to disclose to consumers:
  • The existence of any monitoring software
  • Type of information monitored
  • Who is collecting or transmitting
  • How the information is used
• Consumer consent is needed before the monitoring software can collect any information.

State Security Breach Laws - PII

• Covers security breaches associated with the compromise of personal information.
• California civil code 1798.82 requires
  • Personal information be destroyed when it is no longer needed.
  • Breach notification to information owner.

HIPAA and HITECH - PHI

• Healthcare Insurance Portability and Accountability Act (HIPAA)
  • Not prepared for movement to electronic records.
• Health Information Technology for Economic and Clinical Health Act (HITECH)
  • Enhance privacy provisions of electronic records.

Sarbanes-Oxley Act (SOX) - PFI

• Originally created in reflection to several major accounting and corporate scandals.
  • To improve quality and transparency in financial reporting, independent audits and accounting services for public companies.
• a.k.a Public Company Accounting Reform and Investor Protection Act
  • Public Company Accounting Oversight Board
  • Auditor Independence
  • Corporate Responsibility
  • Enhanced Financial Disclosures
  • Analyst Conflicts of Interest
  • Commission Resources and Authority
  • Studies and Reports
  • Corporate and Criminal Fraud Accountability
  • White-Collar Crime Penalty Enhancements
  • Corporate Tax Returns and
  • Corporate Fraud and Accountability
• Section 302: corporate responsibility for financial controls.
• Section 404: management assessment of internal controls.
  • Mandates a specific level of internal control measures.
  • The systems used for financial accounting must have certain integrity controls to be trusted.

Gramm-Leach-Bliley Act (GLB Act) - PFI

• a.k.a Financial Modernization Act of 1999
• Three primary rules:
  1. The Financial Privacy Rule, which governs the collection and disclosure of PFI, including companies that are nonfinancial in nature.
  2. The Safeguards Rule, which applies to financial institutions and covers the design, implementation, and maintenance of safeguards deployed to protect PFI.
  3. The Pretexting Protections, which addresses the use of pretexting (falsely pretending) to obtain PFI.

BASEL II - PFI

• European Financial Regulatory Act
• Protects against financial operation risks and fraud.
• Developed for banking regulators and provide recommendations on banking regulations and laws.

Federal Financial Institutions Examination Council (FFIEC) - PFI

• Aimed for Internet banking authentication.
• Mandates multifactor authentication.

Privacy

• Privacy: the principle of controlling information about one’s self.
  • Who it is shared with
  • What’s the purpose
  • How it is used and transferred to other parties.
• General rules:
  • If you don’t need it, don’t collect it.
  • If you need to collect it for processing only, ask for consent but don’t store it.
  • If you have the need to collect it for processing and storage, ask for consent and only store for allowed time frame.
  • If you have the need to collect it and store it, then don’t archive it.
• Foundational privacy elements:
  • Notice
  • Choice
  • Transfer
  • Security
  • Integrity
  • Access
  • Enforcement
• Privacy in Software Development
  • Data needs to be categorised into privacy tiers based on the impact.
  • When production data is imported into test, protection against disclosure of private information must be considered.
  • Acceptably Use Policy (AUP)
    • Can be on the screen as a declaration that information will be collected.
    • Can be a deterrent means to discourage violators.
    • Must be complementary and not contradictory to information security policies.
• Privacy Policy: the high-level document that describes the principles associated with the collection, storage, use, and transfer of personal information within the scope of business.
  • Detail the firm’s responsibility to safeguard information.
  • Privacy Disclosure Statement: a customer-facing privacy policy to inform them of how data is protected, used and disposed.
• Data Anonymization: the process of removing private information from the data.
  • Operations: replacement, suppression, generalisation, pertubation
  • The primary challenges associated with PII is the effect of data aggregation, i.e unlinkability.
• Disposition:
  • All systems/information are vulnerable until disposed in a secure manner.
  • Electronic media disposal:
    • Overwriting (using software or hardware products to format media)
    • Degaussing (exposing the media to a strong magnetic field in order to disrupt the recorded magnetic domains)
    • Destroying (disintegration, pulverization, melting, incinerating, or shredding)
• Breach Notifications:
  • Internal incident response
  • Customer notification

Data Protection Principles

• European Union requires that personal data should not be processed, except when three conditions are met:
  • Transparency
  • Legitimate purpose
  • Proportionality
• Difference in default option:
  • US, opt-in by default, need to opt-out
  • EU, opt-out by default, need to opt-in (Consent must be received before collecting data)

Safe-harbour principles - allows non-EU firms to deal with Data Protection Directive (EUDPD)

• Notice: Customers must be informed that their data is being collected and how it will be used.
• Choice: Customers must have the ability to opt out of the collection and forward transfer of the data to third parties.
• Onward Transfer: Data transfer may only occur to other organisations that follow adequate data protection principles.
• Security: Reasonable efforts must be made to prevent loss of collected information.
• Data Integrity: Data must be relevant and reliable for the purpose it was collected for.
• Access: Customers must be able to access information held about them and correct or delete it if it is inaccurate.
• Enforcement: There must be effective means of enforcing these rules

General Data Protection Regulation (GDPR)

• Aim: to give back to people control of their personal data, while imposing strict rules on those hosting and processing this data, regardless of where they are in the world.
• Personal data: any information relating to an identified or identifiable natural person (online identifiers, IP, cookies)
• Individuals must have full access to information on how their data is processed in a clear and understandable way.
• Companies collecting the data must make clear the following:
  • The identity and contact details of the organisation behind the data request (who is asking)
  • The purpose of acquiring the data and how it will be used (why they are asking)
  • The period for which the data will be stored (how long they will keep it)
  • Whether the data will be transferred internationally (where else it can go)
  • The individual’s right to access, rectify, or erase the data (right to be forgotten)
  • The individual’s right to withdraw consent at any time (even after collection)
  • The individual’s right to lodge a complaint
• GDPR principles apply to all EU data and replaces the The Safe Harbor principles.

California Consumer Privacy Act 2018 (AB 375)

• Have a right to know how personal data is being used
• Have a right to disclosure and objection relating to who data is being sold to
• Have a right to know who data has been provided to
• Experience no discrimination if they object to data being sold
• Have a right to access the data being held

Security Policies

• Security Policy: a set of security requirements that needs to be part of the system or software that makes it:
  • Resistant to most attacks
  • Tolerable to attacks
  • Recoverable from an undesirable state
• Scope:
  • Organisational
  • Functional
• Policy Development
  • Policy provides enforceability
  • Not an one-time event

Security Standards

• Security Standards: established norms used to define a specific set of rules governing some form of behavior
  • To define a set of rules associated with ensuring a specified level of quality.
  • Standards are mandatory, guidelines are optional.
• Types:
  • Internal: e.g coding
  • External: e.g industry, government, international, national
• Benefits of Security Standards
  • Provide a common and consistent basis for building secure software
  • Provide interoperability
  • Provide a competitive advantage, liability protection
  • Provide a common baseline for assessment
  • Demonstrate indirectly governance

ISO Standards

• Need to be periodically reviewed (at least every 5 years)

ISO/IEC 15408 – Evaluating Criteria for IT Security (Common Criteria)

• Allows the product to be evaluated by an independent 3rd party against Evaluation Assurance Levels (EALs).
  • Ensure the products meet minimum security functionality.
  • Ensure independent evaluation.
  • Ensure Organisational Security Policies are enforced.
  • Ensure threats are countered to acceptable levels.
  • Ensure security objectives are achieved.
• Evaluation Assurance Levels (EALs):
  • EAL1 Functionally tested
  • EAL2 Structurally tested
  • EAL3 Methodically tested and checked
  • EAL4 Methodically designed, tested and reviewed
  • EAL5 Semi-formally designed and tested
  • EAL6 Semi-formally verified design and tested
  • EAL7 Formally verified design and tested
• ISO/IEC 15408-1:2005 provides common criteria:
  • Protection Profile (create a set of requirements)
  • Security Target (specifies security functions, used by evaluators as the basis in conformance of ISO/IEC 15408)
  • Target of Evaluation and relationship between these
• ISO/IEC 15408-2:2008 contains a hierachical catalog of predefined security functional requirements for:
  • Target of Evaluation (TOE): the product or system that is being evaluated
  • Security Target (ST): the security properties associated with a TOE
  • Protection Profile (PP): a set of security requirements associated with a class of products
• ISO/IEC 15408-3:2008:
  • Security Assurance Requirements (SARs)
  • Evaluation Assurance Levels (EALs)

ISO/IEC 9126 Quality Characteristics

• Measured in six aspects:
  • Functionality
  • Reliability
  • Usability
  • Efficiency
  • Maintainability
  • Portability

ISO/IEC 12207 Systems and Software Engineering—Software Life Cycle Processes

• Establishes a set of processes covering the lifecycle of the software.
• Each process has a defined set of activities, tasks and outcomes associated with it.

ISO/IEC 15408 Standard and Software Security

• Predefined Security Functional Requirement (SFR) and Security Assurance Requirements (SAR).
• Can be used to address vulnerabilities from failures in requirement, development and operations.

ISO/IEC 15504 Information Technology—Process Assessment

• A set of technical standards documents for the computer software development process.
  • a.k.a Software Process Improvement and Capability Evaluation (SPICE)
• Capability levels:
  • 5 optimising process
  • 4 predictable process
  • 3 established process
  • 2 managed process
  • 1 performed process
  • 0 incomplete process

ISO/IEC 21827:2008 – Systems Security Engineering Capability Maturity Model (SSE-CMM)

• Guidelines to ensure security engineering of systems, encompass all phases in SDLC.
• Best practices for interactions with other organisations:
  • Acquisition
  • Certification and Accreditation (CNA)
• De facto standard metric for evaluating security practices.

ISO/IEC 25000:2005 – Software Engineering Product Quality

• Provides guidance on how to use Software project Quality Requirements and Evaluation (SQuaRE).
• Provides guidance on the transition from ISO/IEC 9126 to SQuaRE.

ISO/IEC 27000:2009 – Information Security Management System (ISMS) Overview and Vocabulary

• Provides common glossary
• Provides introduction to ISMS on the following aspects:
  • Requirements definition
  • Guidance on interpreting Plan-Do-Check-Act
  • Sector-specific guidance and conformity assessment

ISO/IEC 27001:2005 – Information Security Management Systems Requirements

• For all types of organisations, specifies how to manage a documented ISMS.
  • Formulating security requirements
  • Ensuring compliance with external and internal policies, regulations and standards
  • Managing security risks cost effectively
  • Generating and selecting security controls requirements
  • Identifying existing ISMS processes and defining new ones
  • Determining the status of the information security management program
  • Communicating organisational information security policies, standards and procedures to other organisations and customers
  • Enabling the business instead of impeding it

ISO/IEC 27002:2005/Cor1:2007 – Code of Practice for Information Security Management

• A technical corrigendum to correct a technical error or ambiguity, replaces ISO 17799
  • Provide common basis for developing organisational security standards and management practices.
  • Provide guidelines on initiating, implementing, maintaining, improving, information security management.
  • Provide best practices of controls to address the finding from risk assessment.

ISO/IEC 27005:2008 - Information Security Risk Management

• To ensure organisational risks are reduced to acceptable levels.
• Provide guidelines on risk management and control implementation to reduce risks.

ISO/IEC 27006:2007 – Requirements for Bodies Providing Audit and Certification of Information Security Management Systems

• Support CNA bodies that audit information security management system.
• Provide competency and reliability requirements for an auditing body.
• Provide guidance on how to interpret requirements.

ISO 28000:2007 - Specification for security management systems for the supply chain

• Provide requirements for security management system, including aspect specific to supply chain.
• Provide prescriptive recommendations on where and when they have an impact.

NIST

• Core competency: development and use of standards.
  • Improving quality of software, secure electronic data, maintain availability of critical electronic services.
• Two main types of documents: SP and FIPS
  • Information Technology Laboratory (ITL):
    • SP 500: generic
    • SP 800: information security publications
    • SP 800-64: SDLC security considerations
  • Feferal Information Processing Standards

SP 800-12: An Introduction to Computer Security: The NIST Handbook

• Provide overview and guidelines to secure hardware, software and information.
  • Security and planning in computer systems lifecycle
  • Security concepts
  • Cost consideration
  • Inter-relationship of security controls
    • Control types:
      • Management
      • Operational
      • Technical
• Not mentioned:
  • Requirements, but discussed benefits of controls and application scenarios
  • Penalty

SP 800-14: Generally Accepted Principles and Practices for Security IT Systems

• Provide baselines on establishment and review of IT security programs.
• Provide basic security requirements to:
  • Management
  • Internal auditors
  • Users
  • Developers
  • Security practitioners
• Provide a foundation as a reference point, includes generally accepted principles and common practices.

SP 800-18: Guide for developing Security Plans for Federal Systems

• Provide a framework for developing security plans:
  • Classification of information assets based on impact to C-I-A
  • Provide system security plan responsibilities
  • Provide a sample plan template
• Security planning is to improve the protection of information system resources.
• Security plan must be periodically reassessed for contextual correctness and applicability.

SP 800-27: Engineering Principles for Information Technology Security

• Provide a baseline for achieving security, covers both people and process.

SP 800-30: Risk Management Guide for IT

• Provide critical success factors for an effective risk management program.
• Provide integration into the system lifecycle with roles and responsibilities.
• Provide a 9 steps RARM process.
• Also covers:
  • Control categories
  • Cost-benefit analysis
  • Residual risk evaluation
  • Mitigation options
  • Post-assessment actions

SP 800-61 – Computer Security Incident Handling Guide

• Cover Advanced Persistent Threats (APTs)
• Assists organisation in establishing capabilities and incident handling procedures.
• Useful for both established and newly formed incident response teams.

SP 800-64: Security Considerations in the Information Systems Development Life Cycle

• Provide guidance for building security into IT systems/software lifecycle.
  • Identify/mitigate vulnerabilities and misconfig early
  • Bring up design issues that may require re-design
  • Identify shared services to reduce dev cost
  • Involve executive on risk decisions
• Covers owners, developers and managers.
• Covers well defined and non-well-defined projects:
  • Supply chain and software assurance
  • Service oriented architecture
  • Specific accreditation of security modules for reuse
  • Cross organisational solutions
  • Technology advancement and major migrations
  • Data centre or IT facility development
  • Virtualisation

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

• Covers a wide range of information security program elements:
  • Information security governance
  • RARM
  • Capital planning
  • Investment control
  • Security planning
  • IT contingency planning
  • Interconnecting systems
  • Performance measures
  • Incidence response
  • Configuration management
  • CNA
  • Acquisitions
  • Training
  • SDLC

Federal Information Processing Standards (FIPS)

• A mandatory sets of requirements on federal agencies and specific contractors.
  • Provide interoperability of disparate systems
  • Provide portability of data and software
  • Provide computer security

FIPS 140: Security Requirement for Cryptographic Modules

• Provide 4 increasing qualitative levels to cover a wide range of potential application and environments.
• Covers secure design and implementation of cryptographic module.
• Specify that developers and vendors need to document implemented controls to mitigate other attacks.

FIPS 186: Digital Signature Standard

• Provide a suite of algorithms to generate signature.
• Provide guidelines for digital signature generation, verification and validation.

FIPS 197: Advanced Encryption Standard

• An approved cryptographic algorithms to ensure Confidentiality.
• AES: symmetric block cipher
  • Replaces FIPS 46-3, Data Encryption Standard (DES) or Triple Data Encryption Algorithm (TDEA)

FIPS 201: Personal Identity Verification (PIV) of Federal Employees and Contractors

• Ensure the claimed identity who require physical/electronic access to facilities/data are properly verified.
• Specifies architecture and technical requirements for a common identification standard.

Payment Card Industry (PCI) Standards

• Mandatory contractual requirements with penalties.

Data Security Standard (PCI DSS)

• A multi-faceted security standard on protective measures for the processing/storing of cardholder data.
  • Details the contractual requirements for members that accept/process bank cards
• Goal: to facilitate organisation’s efforts to proactively protect card holder payment account data.
  • 12 high-level requirement covered in 6 sections
• Certain data cannot be stored (even though cryptographically protected):
  • Full magnetic strip
  • Security code
  • PIN block
• Requirement 6 is directly related to software security
  • 6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Install critical security patches within one month of release.
  • 6.2 Establish a process to identify newly discovered security vulnerabilities (e.g., alert subscriptions) and update configuration standards to address new vulnerability issues.
  • 6.3 Develop software applications in accordance with industry best practices (e.g., input validation, secure error handling, secure authentication, secure cryptography, secure communications, logging, etc.), and incorporate information security throughout the software development life cycle.
  • 6.4 Follow change control procedures for all changes to system components.
  • 6.5 Develop all web applications based on secure coding guidelines (such as OWASP) to cover common coding vulnerabilities in software development.
  • 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either reviewing these applications annually or upon change, using manual or automated security assessment tools or methods, or by installing a web application firewall in front of the public-facing web application.

Payment Application Data Security Standard (PA DSS)

• a.k.a Payment Application Best Practices (PABP)
  • By Payment Card Industry Security Standards Council
  • To assist Qualified Security Assessors (QSAs)
  • To validate the application is compliant to PCI DSS
• Describes requirements in a manner consistent with software activity, not the firms.
  • Compliance with PA DSS signals that the software is properly designed
  • PA DSS alone is not sufficient, there are also non-software requirements
• Examples that the application can prevent PCI DSS compliance:
  • Store the magnetic stripe data and/or equivalent data on the chip
  • Disable protection features in order to get the payment application work

PIN Transaction Security (PTS)

• Security aspects associated with the PIN
• Applicable to PIN Entry Devices (PEDs)

SAFECode

• Industry-backed organisation dedicated to communicating best practices.
• Publications:
  • SAFECode Releases Software Security Guidance for Agile Practitioners
  • Software Assurance: An Overview of Current Industry Best Practices
  • Fundamental Practices for Secure Software Development
  • Fundamental Practices for Secure Software Development, 2nd Edition
  • Overview of Software Integrity Controls
  • Security Engineering Training
  • List of security-focused stories and security tasks for agile-based development environments

Organisation for the Advancement of Structured Information Standards (OASIS)

• OASIS drives the development, convergence and adoption of open standards for the global information society.
• Potential:
  • Lower cost
  • Stimulate innovation
  • Protect the right of free choice of technology
• Publications:
  • Application Vulnerability Description Language (AVDL)
  • 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

Enterprise Application and Security Frameworks

Control Objectives for Information and related Technology (COBIT)

• Designed to assist management in bridging the gap between control requirements, technical issues, and business risks.
• Defines reasons for IT governance, stakeholders and what it needs to accomplish.
• Components:
  • Executive summary
  • Framework
  • Control objectives
  • Audit guidelines
  • Implementation toolset
  • Management guidelines
• Key principles:
  • 1: Meeting Stakeholder Needs
  • 2: Covering the Enterprise End to End
  • 3: Applying a Single, Integrated Framework
  • 4: Enabling a Holistic Approach
  • 5: Separating Governance from Management

Committee of Sponsoring organisations (COSO)

• A collection of worldwide recognized frameworks that provides guidance on organisational governance, business ethics, internal controls, enterprise risk management, fraud and financial reporting.
  • Describes a unified approach for evaluation of internal control systems.
• COSO emphasises identifying and managing risks across enterprise (i.e Enterprise Risk Management):
  • Control environment
  • Risk assessment
  • Control activities
  • Information and communication
  • Monitoring

Information Technology Infrastructure Library (ITIL)

• Describes a set of practices focused on aligning IT services with business needs:
  • ITIL Service Strategy
  • ITIL Service Design
  • ITIL Service Transition
  • ITIL Service Operation
  • ITIL Continual Service Improvement

Capability Maturity Model Integration (CMMI)

• A process improvement methodology used in development (products), delivery (services) and acquisition (products and services).
  • By Software Engineering Institute (SEI)
  • Based on Total Quality Management (TQM)
• Standard CMMI Appraisal Method for Process Improvement (SCAMPI): a collection of best practices used to compare organisational processes.
• Measures maturity of SDLC using a 1-5 rating scale:
  • Initial (Level 1) – Processes are ad hoc, poorly controlled, reactive and highly unpredictable.
  • Repeatable (Level 2) – reactive in nature, the processes grouped at the project level, characterized as being repeatable, managed by basic project management tracking of cost and schedule
  • Defined (Level 3) – proactive, Level 2 maturity level deals with processes at the project level, but in this level, the maturity of the organisational processes is established and improved continuously. Processes are characterized, well understood.
  • Managed Quantitatively (Level 4) – processes are measured against appropriate metrics and controlled.
  • Optimizing (Level 5) – continuous process improvements through innovative technologies and incremental improvements, have the ability to quickly and effectively adapt to changing business objectives, allowing the organisation to scale.

Zachman Framework

• To algin IT to business, depicted as a 6*6 matrix:
  • Planner, Owner, Designer, Builder, Programmer, User
  • Data (what), Function (how), Network (where), People (who), Time (when), Motivation (why)
• A highly structured and formal method of defining an enterprise.

Sherwood Applied Business Security Architecture (SABSA)

• A framework:
  • Based on security requirements determined from business requirements
  • Layered model covers IT lifecycle: strategy, design, implementation and operations
• Used for:
  • Developing risk-based enterprise security architectures
  • Delivering security solutions that support business initiatives

Open Web Application Security Project (OWASP)

• OWASP Top 10
• For development: covers the various security controls that software developers should build into the software.
• For code review: covers how to detect web application vulnerabilities in the code and relevant safeguards.
  • Reviewer must be familiar with:
    • Programming language (code)
    • Working knowledge of the software (context)
    • End-users (audience)
    • Impact to business (importance)
• For testing: covers the procedures and tools that are necessary to validate software assurance.
• Other projects:
  • Application Security Desk Reference (ASDR)
  • Enterprise Security Application Programming Interface (ESAPI)
  • Software Assurance Maturity Model (SAMM)

Build Security In (BSI)

• A project communicating information on research, best practices and generic principles for software security.
• A collaborative effort to provide practices, tools, guidelines, rules, principles and other resources that can be used to build security into software.
• Backed by U.S. Department of Homeland Security
• Web-based and open to the public https://buildsecurityin.us-cert.gov/bsi/home.html

Trusted Computing

• Software Assurance: to establish a basis for gaining justifiable confidence that software will work as intended.
  • By State-of-the-Art Report (SOAR)
  • An assurance on trust
• Software Security Assurance
  • An assurance on security
• Trusted Computer Group (TCP):
  • Security
  • Privacy
  • Interoperability
  • Portability of data
  • Controllability
  • Ease of use

Microsoft Trustworthy Computing Initiative

• A company-wide effort to address concerns over security and privacy.
• Four key pillars:
  • Security
  • Privacy
  • Reliability
  • Business integrity

Trusted Platform Module (TPM)

• An implementation of specifications detailing secure cryptostorage on a chip.
  • Holds an encryption key that is only accessible through the TPM.
  • Current version, 1.2 rev 116 defatiled in ISO 11889.

Ring Protection

• Ring 0: OS kernel, BIOS
• Ring 1: I/O utilities
• Ring 2: Drivers
• Ring 3: User Applications
• Rings can only interact with themselves or adjacent ring

Reference Monitor

• An access control methodology where a reference validation mechanism mediates the interaction of subjects, objects and operations.
• Elements:
  • Subject: requester for resource
  • Object: requested resource
  • Reference Monitor: mediates access
• Trusted Computing can only be possible when the reference monitor itself is:
  • Tamperproof
  • Always invoked
  • Verifiable

Protected Objects

• An object whose existence may be known but cannot be directly interacted with.
  • Any interaction must be done through a protected subsystem.

Trust Boundary (or Security Perimeter)

• Point at which trust levels change.

Trusted Computing Base (TCB)

• The totality of protection mechanisms within it responsible for enforcing a computer security policy
  • By Trusted Computer System Evaluation Criteria (TCSEC)
  • Kernel and Reference Monitor are part of TCB, Applications are not
  • Different from trustworthy and trusted computing
• Two important characters
  • Simple
  • Testable
• Ensure that the security policy is enforced by monitoring:
  • Process Activation
    • Activated: when a process is allowed to interact with the CPU.
    • Deactivated: when a process no longer needs to interact with the CPU.
  • Execution Domain Switching
    • One process executing at a particular domain cannot switch to another domain that requires a different level of trust.
  • Memory Protection
    • Ensure that disclosure, alteration and destruction of memory contents is disallowed.
  • Input/Output (I/O) operations
    • Ensures that the sequence of cross-domain communications for access to I/O devices does not violate the security policy.

Software Development Methodologies

• The objective of a secure DLC is to reduce the number and severity of vulnerabilities.
• SMART: Specific, Measurable, Attainable, Realistic, and Time bound
  • Applicable to both process and software
  • Ensuring that all elements of a software package are constructed and operated securely
  • Security Features != Secure Software
• Security vs Quality
  • Quality: fitness for use
  • If the product has quality but lacks security, then the result is a set of vulnerabilities
  • If the software is secure but is lacking in quality, then undocumented features may result in undesired behaviors

Secure Development Lifecycle Components

• Software Team Awareness and Education
  • Two forms:
    • Basic knowledge
    • Advanced topics
  • Key element: ensure that all members are properly equipped with the correct knowledge before the SDLC
• Gates and Security Requirements
  • Bug Tracking
    • DREAD, risk calculation/rating method, overcome inconsistencies and qualitative risk ratings
      • Damage potential – What will be the impact upon exploitability?
      • Reproducibility – What is the ease of recreating the attack/exploit?
      • Exploitability – What minimum skill level is necessary to launch the attack/exploit?
      • Affected users – How many users will be potentially impacted upon a successful attack/exploit?
      • Discoverability – What is the ease of finding the vulnerability that yields the threat?
    • Different perspective may give different ratings to a bug
    • Bug bar: a measurement level (scoring) that, when exceeded, indicates that the bug must be fixed prior to delivery
  • Threat Modeling
    • A design technique used to communicate information associated with a threat throughout the development team.
    • Attention needed on:
      • The application as a whole
      • Security and privacy features
      • Features whose failures have security or privacy implications
      • Features that cross trust boundaries
    • STRIDE
      • Spoofing – Impersonating another user or process
      • Tampering – unauthorised alterations that impact integrity
      • Repudiation – Cannot prove the action; deniability of claim
      • Information Disclosure – Exposure of information to unauthorised user or process that impact confidentiality
      • Denial of Service – Service interruption that impacts availability
      • Elevation of privilege – unauthorised increase of user or process rights
    • Threat Trees
      • A graphical representation of the elements that must exist for a threat to be realized
      • Logical combination of elements, using ANDs and ORs
  • Fuzzing
    • A test technique where the tester applies a series of inputs to an interface in an automated fashion and examines the outputs for undesired behaviors.
    • Two kinds of inputs: random and structured
    • Fuzzing frameworks can be based on:
      • Mutation: using existing data and mutate them
      • Generation: created based on models of the system
    • Advantages:
      • Easy to setup large number of tests
      • Focuses on the input (entry points to the software)
• Security Reviews: examine the process and ensure that the security-related steps are being carried out and not being bypassed.
• Mitigations:
  • Do nothing
  • Warn the user
  • Remove the problem
  • Fix the problem

Software Development Models

• Waterfall
  • Requirement (security requirements must be in)
  • Design
  • Implementation (construction, integration)
  • Verification (testing, debugging)
  • Installation
  • Maintenance
  • developers are limited to go back only one stage to rework
• Iterative
  • Broken into small versions, avoid disastrous faulty assumptions
  • Each version is a prototype to the final Release To Manufacturing (RTM)
  • Increase opportunity to user input
  • If planning cycle too short, security requirements can be missed out
• Spiral
  • Has elements from waterfall and interactive, for larger projects
  • Each phase has a risk assessment review on cost and time, cut the losses before investing too much
  • Using planning as primary control mechanism
• Prototype
  • A representative model designed to demonstrate some set of functionality.
  • Primary reasons for prototyping is to reduce risk.
  • Two flavours:
    • Throwaway: a simulation is constructed to gain information on some subset of requirements
    • Evolutionary: a mockup that provides some form of functionality is created, allowing testing of the designed functionality
  • Can be horizontal (a framework or infrastructure) or vertical (stovepipe-type, db access functions)
• Agile
  • Designed to increase innovation and efficiency of small programming teams
    • Rely on quick turns involving small increases in functionality
    • Reduce failure rate by providing more iterations and small timeframes
    • Changes can be made quickly
    • Using regular tests and releases as primary control mechanism
  • Extreme programming model (people-centric), useful for small projects
    • Adapatability to change, incremental updates, feedback from user/customer, respect/courage for people
    • Success factors
      • Starting with simplest solutions
      • Communicatioin between team members
    • Key feature: the use of feedback to manage the three-step process of release planning/iteration/acceptance testing
  • Scrum (process-centric)
    • 30 days cycle, a sprint, sprint backlog, Burn Down Chart
    • Software is in a constant state of readiness for release
    • Participants have pre-defined roles (pig roles i.e product owners, devs, chicken roles i.e users)
    • Sprint: a 30-day cycle
    • Burn-down: daily accomplishment
    • Backlog: list of tasks
  • Lean
  • Kanban
  • Crystal methodologies (a.k.a lightweight methodologies)
  • Dynamic systems development method (DSDM)
  • Feature-driven development (FDD)
  • Unit testing enables collective code ownership and is critical to assure software assurance
• Open Source: not a model, more of a philosophy

Microsoft Security Development Lifecycle

• A process designed to enable development teams to build more secure software and address security compliance requirements.
• SDL is designed to achieve two objectives:
  • Reduce the number of security vulnerabilities in a product
  • Reduce the severity of security vulnerabilities that remain in a product
• Secure by Design, Secure by Default, Secure in Deployment and Communications (SD3+C) program.
  • Design: the incorporation of security thinking as part of the design process
    • Privacy
    • Cryptography
  • Default: ensuring that the default configuration of the software is, by design, as secure as possible
    • Minimizing attack surface
  • Deployment: ensuring security and privacy are properly understood and managed through the deployment process
  • Communications
    • the user base can become actively engaged in the security solution, avoiding preventable security incidents
    • improves usability and creates greater long-term value through reduced administrative costs

SDL Components

• Training
  • Include all personnel
  • Core training (basic concepts and componenets) and advanced training (up-to-date practice)
• Requirements
  • The establishment of the security and privacy requirements for the software
  • The creation of quality gates and bug bars
  • The development of security and privacy risk assessments for the software
• Design
  • Risk and privacy analyses are performed to ensure that security and privacy issues are thoroughly mitigated by design
  • The use of attack surface reduction techniques and threat modeling is used to improve design coverage against known and potential threats
• Implementation
  • The application of secure coding practices in a programming language to achieve design objectives
• Verification
  • Testing the code for known and potential sources of vulnerabilities
  • Review of the attack surface
  • Verifying the as-built model matches the design goals
• Release
  • Prepared for and ultimately released to end users
  • Incident response plan
  • Final check to ensure that all security-related activity was performed and done
• Response
  • The collection of error reports and handling per the release-based incident response plan

Microsoft SDL

• Training
  • Core security training
• Requirements
  • Establish security and privacy requirement
  • Create quality gates/bug bars
  • Perform security and privacy risk assessments
• Design
  • Establish design requirements
  • Attack surface analysis/reduction
  • Threat modelling
• Implementation
  • Approved tools
  • Deprecate unsafe functions
  • Static analysis
• Verification
  • Dynamic analysis
  • Fuzz testing
  • Attack surface review
• Release
  • Create an incident response plan
  • Final security review
  • Certify release and archive
• Response
  • Execute incident response plan

Software Assurance Methodologies

Socratic Methodology

• A method that addresses issues arise from individuals who have opposing views on the need for security in the software they build.
• A form of cross-examination, investigate ideas and stimulate rational thought.

Six Sigma

• A business management strategy for quality in process improvement by eliminating defects, 3.4 defects/million DPMO
• Key sub-methodologies:
  • DMAIC: Define, Measure, Analyse, Improve, Control, for improving existing process
  • DMADV: Define, Measure, Analyse, Design, Verify, for developing new process

Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE)

• A risk-based information security strategic assessment methodology.
  • Provide insight into organisational risk, state of security and resiliency within the organisation.
  • Can be done by self-directed or by cross-functional teams.
• 3 flavours:
  • original OCTAVE for any organisation
  • OCTAVE-S for smaller organisation
  • OCTAVE-Allegro, a streamlined approached for information security assessment and assurance
• 3 phases:
  1. Build asset-based threat profiles
     • Determine assets with value to the business operations
     • Priorities assets into critical assets, describe security requirements
     • Identify threats, creating a threat profile
     • Determine risk at organidational level
  2. Identify infrastructure vulnerabilities
     • Examines infrastructural components and level of resistance against attacks to identify vulns
     • Determine technical risks
  3. Develop security strategy and plans
     • Makes plan to address threats, mitigate vulns

Open Source Security Testing Methodology Manual (OSSTMM)

• A peer-reviewed testing method for security tests and how to measure the results using applicable metrics.
  • Provide a way for the characterisation of security through examination and correlation of test results.
  • Provide guidelines to auditors to perform an assurance audit to assure the quality of the tests and results.
• Security Test Audit Report (STAR): the output that includes
  • The specific actions conducted in tests.
  • The corresponding metrics and the state of the strength of controls.

Flaw Hypothesis Method (FHM)

• A vulnerability prediction and analysis method that uses pen-test to test the strength of security.
• Simulating attacks to find weaknesses in design and implementation.
  1. Hypothesizing potential flaws in the software from documentation
  2. Confirmation of flaws by conducting actual simulation pen-test and desk checking tests
     • Desk checking attests program logic by executing program statements using sample data.
     • The flaws that are exploitable are marked as ‘confirmed’ and those that are not are marked as ‘refuted’.
  3. Generalization of confirmed flaws to uncover other possibilities of weaknesses
  4. addressing current version or designing safeguard for future version
• Drawback: identifies only known issues

Acquisition

• Commercial off-the-shelf (COTS)
  • Primary consideration: IP
• Government off-the-shelf (GOTS):
  • Developed for government use
• Decision on buy/build dependent on the time (schedule), resource (scope) and cost (budget)
  • Determined by degree of fit
• Outsourcing also determined by cost and benefits.
• Security assurance requirements must be part of the process.
• Contractual Terms and Service Level Agreements (SLA)
  • Purchase should include references to security controls or standards that are expected to be implemented.
  • SLA can include acceptance criteria.