Domain 2. Secure Software Requirements

Policy Decomposition

  • NIST categories:
    • Program policies: a foundation for the organisation’s information security program
    • Issue-specific policies: address specific issues
      • e.g PII and data retention policy
    • System-specific policies: technical directives aimed at driving a specific technical outcome
  • Policy Documents -> High level objectives -> Security requirements -> Software requirements
    • Policy Documents: SOX, PCI DSS etc
    • High level objectives: confidentiality, secure transmisison, privacy
    • Security requirements: information classification, identity management
      • can have multiple sub-requirements for each requirement
    • Software requirements: input validation, exception handling, output encoding

Security Requirements

  • Security requirements must address the goals and objectives of the organisation.
    • Equal weight should be given to all security requirements.
    • Business requirements must be translated into functional requirements and assured in the process.
  • Key characteristics:
    • Reliability: the software functions as expected.
    • Resiliency: 1) does not violate any security policy, 2) withstand the actions of threat agents
    • Recoverability: 1) restore business operations, 2) limiting/remediating the damage caused by threats
  • Sources for Security Requirements
    • Internal:
      • Policies
      • Standards
      • Guidelines
      • Patterns and practices
      • End user business functionality
    • External
      • Regulations
      • Compliance
      • Geographical
  • Business owners’ responsibilities:
    • Define acceptable risk (residual risk) threshold
    • Own the risks
    • Need to understand the importance and concepts of security

Types of Security Requirements

  • Core Security Requirements
    • Confidentiality requirements
    • Integrity requirements
    • Availability requirements
    • Authentication requirements
    • Authorization requirements
    • Accountability requirements
  • General Requirements
    • Session Management requirements
    • Errors & Exceptions Management requirements
    • Configuration Parameters Management requirements
  • Operational Requirements
    • Deployment Environment requirements
    • Archiving requirements
    • Anti-piracy requirements
  • Other Requirements
    • Sequencing and Timing requirements
    • International requirements
    • Procurement requirements

Internal and External Requirements

  • Internal security requirements include all of the items used by the system to protect its own data and communications.
    • Protect audit logs
    • Manage data loss prevention elements
    • Monitor internal system traffic
    • Monitor internal controls
  • Security policies should ensure compliance with all external obligations: statutory, regulatory, contractual etc.
    • Manage external connections with security controls
    • Manage external connections and authentication
    • Employ content filtering and proxies to protect against web-based threats

Data Classification

  • Data classification is a risk management tool used to:
    • Align protection and asset value in the enterprise.
    • Reduce the data protection cost.
  • Classification Approaches:
    • By state:
      • Creation
      • In storage
      • In transit
      • In processing
    • By usage:
      • Internal data
      • Input data
      • Output data
      • Security-sensitive data
      • PII data
      • Hidden data
      • (Encryption is considered a method, not a usage)
    • By importance:
      • Risk level
      • Financial cost
  • Ownership:
    • Owner: business
    • Owner Responsibilities:
      • Ensure appropriate classification
      • Validate security controls implementation
      • Define authorised access
      • Responsibility delegation
    • Data Custodian: a role delegated by the owner
    • Data Custodian Responsibilities:
      • Maintaining defined security controls
      • Managing authorised users and access controls
      • Performing operational tasks
  • Data Labeling:
    • Based on Sensitivity
    • Based on Impact to C-I-A
      • Impact analysis can be used to determine the impact level:
        • People impact
        • Customer impact
        • Financial impact
    • NIST FIPS 199 and SP 800-18 provide a qualitative framework for data classification
      • Confidentiality:
        • Public
        • Confidential (disclosed to roles)
        • Restricted (disclosded to restricted roles)
      • Integrity:
        • Low (minimal damage)
        • Medium (significant)
        • High (critical)
      • Availability:
        • Support (minimal impact)
        • Essential
        • Criticall
  • Data Types:
    • Structured: the data (not the storage method) is structured and easily parsable.
      • e.g database, json data
    • Unstructured: the data cannot be easily parsed.
      • e.g img, video, email, MS Office doc

Data Lifecycle Management (Information Lifecycle Management)

  • Purpose:
    • DLM focuses on data, ILM is for more complex situation
    • DLM is a policy based approach, not a product
    • DLM is product-oriented
  • Primary Component:Data Classification
  • Other Componenets:
    • Secure Memory Management: prevents disclosure of data when data is processed
    • Data Leakage Prevention: protect against unauthorised disclosure in transit
    • DB encryption: protect sensitive data in storage
    • Hierarchical Storage Management: a common type of DLM solution
      • Hierachy represents different types of media:
        • e.g Redundant Array of Inexpensive Disks (RAID)
      • More critical data may imply more frequently accessed
    • Portable media:
      • Susceptible to thefting
      • Need physical protection
    • Secure archieve
    • Secure disposal
  • Lifecycle:
    • Generation:
      • Can be generated by operations or input
      • Persistent data needs to be classified
    • Retention:
      • Drive: business requirements
      • Need to define:
        • Owner
          • Data owner and custodian have full responsibilities
        • Purpose
        • Protection level
          • For both the data and any copies
        • Storage length
          • Log storage is important for legal reasons
          • A business may have legitimate reasons to exceed the compliance requirements
    • Disposal
      • Purpose:
        • Conserve resources
        • Reduce liability
      • Length of retention determined by:
        • Business purpose
        • Compliance
      • Custodian’s tasks:
        • Need to be properly disposed: backups, copies for DR sites, data warehouse history, other copies
        • Legal hold data needs to be managed separately and not necessary to be disposed

Core Requirements

Confidentiality requirements

  • Goal: protection against the unauthorised disclosure
  • Requirement sources:
    • Data classification:
      • Public: e.g, directory information
      • Non-public: e.g business data
    • Change of classifications
    • Data life cycle requirement (especially non-public data)
    • Time bond: when confidentiality is required for a certain time frame
  • Common Controls:
    • Secret Writing: prevent secret info disclosure
      • Overt: make info indecipherable
        • Encryption: bi-directional
        • Hashing: one-way, primarily for integrity, can ensure confidentiality i.e hashed password in db
      • Covert: hide info in something
        • Steganography
        • Digital Watermarking: embedding information into a digital signal
          • Visible: visible to plain sight
          • Invisible: concealed in other media, watermark can uniquely identify the originator, e.g digital media copyright
    • Masking: weaker protection, info is asterisked out, e.g shoulder surfing, credit card last 4 digits

Integrity Requirements

  • Goal: protection againt unauthorised modification
    • Primarily addresses reliability and accuracy
    • Secondarily addresses completeness and consistency
    • Reliability assurance
    • Integrity should be considered for both system and data
  • Controls:
    • Input validation
    • Parity bit checking
    • Cyclic redundancy checking (CRC)
    • Hashing (the strongest form of integrity)

Availability Requirements

  • Goal: protection against destruction of the software system/data
    • Prevent DoS against authorised users
    • Prevent unauthorsided access
    • Configuration requirements
    • Load balancing requirements
  • SLA should state:
    • Maximum Tolerable Downtime (MTD): the maximum time a process can be interrupted without causing the business to fail.
    • Recovery Time Objective (RTO): the time in which the organisation should have the interrupted process running again.
  • Determining the consequence of downtime (e.g Business Impact Analysis (BIA), stress/performance testing)
    • Quantitative measures:
      • Revenue loss
      • Cost to fix
    • Qualitative measures:
      • Credibility loss
      • Reputation loss

Authentication Requirements

  • Need to determine:
    • Identity mechanism
    • Identity management, including re-affirmation
    • Method of authentication management
    • Strength of authentication method
    • Federated authentication
    • Mutual authentication
  • Common authentication methods:
    • Anonymous (avoid):
      • Accessible to public
      • Unlinkable (no link between user/system and the actions taken)
    • Basic (avoid):
      • HTTP
      • Base64 encoded
    • Digest:
      • Challenge/response mechanism using message digest of original credential
    • Integrated:
      • a.k.a NTLM, NT chanllenge/response (standalone or kerberos)
      • Good for intranet
    • Client certificates:
      • Validate identity of certificate holder issued by CA (ITU X.509 v3)
    • Forms:
      • Mostly for web, credential validated against a directory store
      • Should use TLS or IPsec
    • Token:
      • Useful in SSO
    • Smart cards:
      • Ownership based, capability is limited by the storage
      • Thwart risk of stealing credentials
      • One Time Password (OTP) provides max strength
        • OTP token (a.k.a key fobs) requires two factors (knowledge and ownership)
    • Biometrics:
      • Biological traits may change overtime
        • FIPS 201 Personal Identity Verification mandates biological information to be changed periodically
      • Requires physical access
      • Errors:
        • Type I: False Rejection (FRR)
        • Type II: False Acceptance (FAR)
        • Crossover Error Rate (CER) is used for evaluating the algorithm

Authorization Requirements

Mandatory Access Control (MAC)

  • Mandatory access control restricts access based on the sensitivity of the information and whether the user has the authority to access that information.
    • Subject cannot determine whether access can be granted to another Subject, it’s determined by the system.
    • Access rules are pre-defined by the system.
    • Security controls for access decision cannot be changed.
    • Originated from military, a.k.a Orange Book
    • SELinux is based on MAC
  • Pre-requisite:
    • Data Classification
    • Clearance Labeling
    • Define an Access Control List

Discretionary Access Control (DAC)

  • A means of restricting access to objects based on the identity of subjects and/or groups to which they belong.
    • A subject with certain permission can pass that permission to another subject.
    • Subject access to Object relies on the owner of the Object.
    • Access Control List (ACL) is commonly used to implement DAC.
    • Can be implemented using identities or roles/groups.
    • Adopted by Unix-based system.
  • Strength: simple
  • Weakness:
    • Control is not enforced by the system
    • Low scalability

Role-Based Access Control (RBAC)

  • Resources are not directly mapped to individuals, but to roles.
  • Roles are defined by job functions:
    • Define the trust levels.
    • Access rights are determined based on responsibilities and authority.
  • Role Hierarchy:
    • Define the inherent relationships between roles.
    • Identify contextual and content based constraints.
  • Roles and Groups:
    • Groups: a collection of users instead of not permissions. Permission can be assigned to groups or users.
    • Assigning permissions directly to users may circumvent group-based access control.
    • Access permissions should be done through roles, not directly to users.
  • Characteristics:
    • Discretionary aspect: owner can determine roles.
    • Non-discretionary aspect: security policy is enforced universally on all roles.
    • Mandatory aspect: role is similar to clearance levels, Objects are labeled.
    • Support Least Privilege.
    • Support Sepration of Duties: no individuals can be assigned to two roles that are mutually exclusive.
      • Static SoD: when prevented from being assigned to conflicting roles.
      • Dynamic SoD: when prevented from operating with conflicting roles.
  • Benefits:
    • Simplified subjects and objects access rights administration.
    • Ability to represent the organisational structure.
    • Force enterprise compliance with control policies more easily and effectively.

Rule-based Access Control

  • A series of rules is contained in the access control list.
  • The determination of whether to grant access will be made based on these rules.

Attribute-Based Access Control (ABAC)

  • An extension to Rule-based Access Control based on the use of attributes associated with an identity.
    • e.g: user attributes, resource attributes, environment attributes
  • ABAC can be represented via the eXtensible Access Control Markup Language (XACML)
    • A standard that implements attribute and policy-based access control schemes

Access Control Matrix

  • A simplified form of access control notation where the allowed actions of a subject are listed in a matrix format.
  • Strength: simple for design
  • Weakness:
    • Difficult to implement
    • Low scalability

Non-Discretionary Access Control (NDAC)

  • An access control where the system enforcing the security policies universally despite the subjects.
    • Policy is enforced universally, it doesn’t rely on the subject’s compliance.
    • Unavoidably imposed on all subjects, higher degree of protection.

Resource-Based Access Control

  • Impersonation and Delegation Model
    • Delegation: grant all necessary privileges to a secondary entity to act on the primary’s behalf.
    • Impersonate: grant all privileges of the primary to the secondary.
      • Used by kerberos through the Ticket Granting Ticket (TGT).
  • Trusted Subsystem Model
    • Access is granted based on the identity of a trusted resource instead of the identity of user.
    • Mostly for web applications.

Accountability Requirements

  • Risk-based characteristics:
    • Inherent risk: the risk associated with the process and its inherent errors before any controls are applied.
    • Detection risk: the risk that an audit will not detect an issue that can result in material error.
    • Control risk: the risk that controls will not detect or prevent material errors in a timely fashion.
  • Organisational characteristics:
    • Roles and Responsibilities
    • Separation of Duties
    • Training and Qualifications
    • Change management
    • Control management
  • Benefits:
    • Assist in building a historical record of user actions.
    • Assists in detecting unauthorised modification.
  • Minimum requirement for auditing:
    • Subject: who
    • Object: where
    • Action: what
    • Time: when
  • Recommended: all critical business and administrative functions need to be identified and audited.

General Requirements

Session Management Requirements

  • Protect against brute force attacks, predictability or Man-in-the-middle

Errors & Exception Management Requirements

  • Protect against information disclosure
  • Errors and exceptions must be handled properly
  • Fail secure should be in place

Configuration Parameters Management Requirements

  • Identify and capture appropriate settings
  • Separation of Duties between development and production personnel

Operational Requirements

  • Identify the needed capabilities and dependencies
    • Need to have a concept of operation and interoperability
  • Secure by Design, Secure by Default and Decure in Deployment

Deployment Environment Requirements

  • Attention needed on cryptographic protection in web farm to avoid data corruption
  • Compliance initiatives may require certain environmental protection controls
    • e.g PCI DSS mandates sensitive card holder data to be protected when transmitted in public networks

Archiving Requirements

  • Needed for compliance reasons
    • Organisational retention policies should not contradict with regulatory requirements
  • Need to determine:
    • Location
    • Duration
    • Format

Anti-Piracy Requirements

  • Important for Commercially-Of-The-Shelf software
  • Considerations needed for:
    • Code obfuscation
    • Code signing
    • Anti-tampering
    • Licensing
    • IP protection

Secure Coding Standards

  • Secure coding standards are language-specific rules and recommended practices for secure programming.
    • Describe sources of vulnerabilities and errors in programs
    • Prescribe forms that will preclude vulnerabilities and exploitable conditions
    • Adopt a secure application development framework
      • e.g Standards by Software Engineering Institute/CERT
  • Common issues:
    • Poor error trapping and handling:
      • Prevent error conditions from cascading or propagating through a system
      • Functions should practice complete error mitigation
    • Logging:
      • Ensures appropriate levels of logging
      • Simplify the management of the logging infrastructure

Other Requirements

Sequencing and Timing Requirements

  • Protect against
    • Race conditions
      • Undesirable sequence of events attempting to supersedes its preceding event.
      • Multiple unsynchronized threads executing simultaneously for a process that needs to be completed atomically.
      • Infinite loops that prevent a program from returning control.
    • Time of Check (TOC) and Time of Use (TOU) attack
      • Takes advantage of a separation between the time a program checks a value and when it uses the value
      • Allowing an unauthorised manipulation
  • Infinite loop issue:
    • Complex conditional logic with unhandled states usually result in infinite loops
    • All conditions in each nested loop should be handled in a positive fashion
  • Requirement should define:
    • Race windows
    • Mutex

International Requirements

  • May imply a Legal requirement
  • Technical aspect:
    • Character encoding
    • Display direction
    • ASCII: 7 bits, 128 characters
    • Latin-1 international coding standard, ISO/IEC 646, 8 bits, 256 characters
    • Unicode, 16 bits, 65535 characters, 32 bits 4B characters, compatible with ISO/IEC 10646
      • utf-8 (byte), popular for HTML, ASCII compatible (save char values)
      • utf-16 (word), need to balance efficient char access with economical use of storage
      • utf-32 (double word), memory is not an issue but fixed width single code unit access to char is essential
  • Common encoding issues:
    • Spoofing
    • Overflows
    • Canonicalization

Procurement Requirements

  • Should be included in contracts and SLAs, especially software escrow requirement.

Protection Needs Elicitation (PNE)

  • The methodology to determine security requirements and identify assets that needs protection.
  • Information Assurance Technical Framework (by NSA):
    • Engage the customer
    • Information management modeling
    • Identify least privilege applications
    • Conduct threat modeling and analysis
    • Prioritize based on customer needs
    • Develop information protection policy
    • Seek customer acceptance

Brainstorming

  • Characteristics:
    • Quick
    • Unstructured
    • Requirement are not challenged
    • Only recorded
  • Disadventages:
    • Ideas may not relate to the context
    • Subjective

Surveys

  • Effetive in collecting functional and assurance requirements.
  • Should take into account of risks from Business, Process and Technology.

Subject/Object Matrix

  • Define subject to object access
    • High level objects need to be broken down
  • Threats and requirements can be determined by inversing the allowed matrix actions
  • A list of allowed and denied actions can be used to creat use-case and misuse-case.
  • Assist in correctly defining the relationships between users and the desired functions on objects.

Use Case & Misuse Case Modeling

  • Use Cases:
    • Can help shaping business requirements that are not well defined.
    • Shows the intended system behavior for actors.
  • Misuse Cases:
    • Can be considered a form of use case illustrating prohibited actions.
    • Can be identified based on use cases.
    • Can present commonly known attack scenarios (attacker-centric).
  • Modelling Process (should only model significant behaviours):
    • Identify actors: individual, role, non-human
    • Identify intended behavior
    • Identify sequences and relationships between the actors and the use cases
  • Resources:
    • Secure Quality Requirements Engineering (SQuaRE): provides nine steps to help determining requirements
    • SAFECode: Practical Security Stories and Security Tasks for Agile Development Environments

Requirements Traceability Matrix (RTM)

  • Helps the development team (project managers) to track and manage the requirements and implementation details.
    • Assists in documenting the relationships between security requirements and engineering efforts.
    • Acts as a management tool and documentation system.
    • Ensures all requirements are appropriately managed.
  • Benefits:
    • Ensure no unnecessary features have been added.
    • Assure that the design satisfies the specified security requirements.
    • Ensure that implementation does not deviate from secure design.
    • Provide a basis for defining test cases.
  • RTM should include: ID, Description, Source, Test Objectives, Verification, Use Cases

Examples

Confidentiality Requirements

  • Personal health information must be protected against disclosure using approved encryption mechanisms.
  • Password and other sensitive input fields need to be masked.
  • Passwords must not be stored in the clear in backend systems and when stored must be hashed with at least an equivalent to the SHA-256 hash function.
  • Transport layer security (TLS) such as Secure Socket Layer must be in place to protect against insider man-in-the-middle (MITM) threats for all credit card information that is transmitted.
  • The use of non-secure transport protocols such as File Transfer Protocol (FTP) to transmit account credentials in the clear to third parties outside your organisation should not be allowed.
  • Log files must not store any sensitive information as defined by the business in humanly readable or easily decipherable form.
  • Who is authorised to see what specific data elements
  • What mechanism should be employed to enforce confidentiality
  • What are the business requirements with respect to data collection, transfer, storage, and use with respect to confidentiality

Integrity Requirements

  • All input forms and Querystring inputs need to be validated against a set of allowable inputs before the software accepts it for processing.
  • Software that is published should provide the recipient with a computed checksum and the hash function used to compute the checksum, so that the recipient can validate its accuracy and completeness.
  • All non-human actors such as system and batch processes need to be identified, monitored and prevented from altering data as it passes on systems that they run on, unless explicitly authorised to.
  • Who is authorised to alter which specific data elements
  • What mechanism should be employed to detect errors and enforce integrity
  • What are the business requirements with respect to data collection, transfer, storage, and use with respect to integrity

Availability Requirements

  • The software shall ensure high availability of five nines (99.999%) as defined in the SLA.
  • The number of users at any one given point of time who should be able to use the software can be up to 300 users.
  • Software and data should be replicated across data centers to provide load balancing and redundancy.
  • Mission critical functionality in the software should be restored to normal operations within 1 hour of disruption; mission essential functionality in the software should be restored to normal operations within 4 hours of disruption; and mission support functionality in software should be restored to normal operations within 24 hours of disruption.

Authentication Requirements

  • The software will be deployed only in the intranet environment and the authenticated user should not have the need to provide username and password once they have logged on to the network.
  • The software will need to support single sign on with 3rd party vendors and suppliers that are defined in the stakeholder list.
  • Both intranet and Internet users should be able to access the software.
  • The authentication policy warrants the need for two- or multifactor authentication for all financially processing software.

Authorisation Requirements

  • Access to highly sensitive secret files will be restricted to users with secret or top secret clearance levels only.
  • User should not be required to send their credentials each and every time once they have authenticated themselves successfully.
  • All unauthenticated users will inherit read-only permissions that are part of guest user role while authenticated users will default to having read and write permissions as part of the general user role. Only members of the administrator role will have all rights as a general user in addition to having permissions to execute operations.

Accountability Requirements

  • All failed logon attempts will be logged along with the timestamp and the Internet Protocol address where the request originated.
  • A before and an after snapshot of the pricing data that changed when a user updates the pricing of a product must be tracked with the following auditable fields - identity, action, object and timestamp.
  • Audit logs should always append and never be overwritten.
  • The audit logs must be securely retained for a period of 3 years.

Session Management Requirements

  • Each user activity will need to be uniquely tracked.
  • The user should not be required to provide user credential once authenticated within the Internet banking application.
  • Sessions must be explicitly abandoned when the user logs off or closes the browser window.
  • Session identifiers used to identify user sessions must not be passed in clear text or be easily guessable.

Errors & Exception Management Requirements

  • All exceptions are to be explicitly handled using try, catch and finally blocks.
  • Error messages that are displayed to the end user will reveal only the needed information without disclosing any internal system error details.
  • Security exception details are to be audited and monitored periodically.

Configuration Parameters Management Requirements

  • The web application configuration file must encrypt sensitive database connections settings and other sensitive application settings.
  • Passwords must not be hard-coded in line code.
  • Initialization and disposal of global variables need to be carefully and explicitly monitored.
  • Application and/or Session OnStart and OnEnd events must include protection of configuration information as a safeguard against disclosure threats

Operational Requirements

  • Cryptographic keys that are shared between applications should be protected and maintained using strict access controls.
  • Data backups and replications must be protected in secure logs with least privilege implemented.
  • Patching of software must follow the enterprise patch management process and changes to production environments must be done only after all necessary approvals have been granted.
  • Discovered vulnerabilities in the software, that can impact the business and the brand, must be addressed and fixed as soon as possible, after being thoroughly tested in a simulated environment.
  • Incident management process should be followed to handle security incidents and root cause of the incidents must be identified.
  • The software must be continuously monitored to ensure that it is not susceptible to emerging threats.

Deployment Environment Requirements

  • Will the software be deployed in an Internet, Extranet or intranet environment?
  • Will the software be hosted in a Demilitarized Zone (DMZ)?
  • What ports and protocols are available for use?
  • What privileges will be allowed in the production environment?
  • Will the software be transmitting sensitive or confidential information?
  • Will the software be load balanced and how is clustering architected?
  • Will the software be deployed in a web farm environment?
  • Will the software need to support single sign-on (SSO) authentication?
  • Can we leverage existing operating system event logging for auditing purposes?

Archiving Requirements

  • Where will the data or information be stored?
  • Will it be in a transactional system that is remote and online or will it be in offline storage media?
  • How much space do we need in the archival system?
  • How do we ensure that the media is not re-writable? For example, it is better to store archives in Read-Only media instead of ReadWrite media.
  • How fast will we need to be able to retrieve from archives when needed? This will not only help in answering the online or offline storage location question but also help with determining the type of media to use. For example, for a situation when fast retrieval of archived data is necessary, archives in tape media is not advisable because retrieval is sequential and time consuming in tape media.
  • How long will we need to store the archives for?
  • Is there a regulatory requirement to store the data for a set period of time?
  • Is our archival retention policy contradictory to any compliance or regulatory requirements?
  • In what format will the data or information be stored? Clear text or cipher text?
  • If the data or information is stored in cipher text, how is this accomplish and are there management processes in place that will ensure proper retrieval?
  • How will these archives themselves be protected?

Anti-Piracy Requirements

  • The software must be digitally signed to protect against tampering and reverse engineering.
  • The code must be obfuscated, if feasible, to deter the duplication of code.
  • License keys must not be statically hard-coded in the software binaries as they can be disclosed by debugging and disassembly.
  • License verification checks must be dynamic, preferably with phone-home mechanisms and not be dependent on factors that the end-user can change.

Surveys

  • What kind of data will be processed, transmitted or stored by the software?
  • Is the data highly sensitive or confidential in nature?
  • Will the software handle personally identifiable information or privacy related information?
  • Who are all the users who will be allowed to make alterations and will they need to be audited and monitored?
  • What is the maximum tolerable downtime for the software?
  • How quickly should the software be able to recover and restore to normal operations when disrupted?
  • Is there a need for single sign-on authentication?
  • What are the roles of users that need to be established and what privileges and rights will each role have?
  • What are the set of error messages and conditions that you would need the software to handle when an error occurs?