Operations

OWASP SAMM 2.2.0 – Operations

1.Kravtext (engelskt original)#

The Operations Business Function encompasses those activities necessary to ensure confidentiality, integrity, and availability are maintained throughout the operational lifetime of an application and its associated data. Increased maturity with regard to this Business Function provides greater assurance that the organization is resilient in the face of operational disruptions, and responsive to changes in the operational landscape.

Incident Management (IM)#

Once your organization has applications in operation, you are likely to face security incidents. In this model, we define a security incident as a breach, or the threat of an imminent breach, of at least one asset’s security goals, whether due to malicious or negligent behavior. Examples of security incidents might include: a successful Denial of Service (DoS) attack against a cloud application, an application user accessing private data of another by abusing a security vulnerability, or an attacker modifying application source code. The Incident Management (IM) practice focuses on dealing with these in your organization.

Historically, many security incidents have been detected months, or even years, after the initial breach. During the “dwell time” before an incident is detected, significant damage can occur, increasing the difficulty of recovery. Our first activity stream, Incident Detection, focuses on decreasing that dwell time.

Once you have identified that you are suffering from a security incident, it’s essential to respond in a disciplined, thorough manner to limit the damage, and return to normal operations as efficiently as possible. This is the focus of our second stream.

Stream A – Incident Detection

Incident Detection refers to the process of determining whether an identified security-relevant event is, in fact, a security incident. The activities in this stream focus on the organization’s ability to identify security incidents when they occur, and to initiate appropriate incident response activities.

Level 1: Use best-effort incident detection — Use available log data to perform best-effort detection of possible security incidents.
Level 2: Define an incident detection process — Follow an established, well-documented process for incident detection, with emphasis on automated log evaluation.
Level 3: Improve the incident detection process — Use a proactively managed process for detection of incidents.

Stream B – Incident Response

Incident Response starts the moment you acknowledge and verify the existence of a security incident. Your goal is to act in a coordinated and efficient way so that further damage is limited as much as possible. The activities in this stream focus on the organization’s ability to respond appropriately and effectively to reported security incidents.

Level 1: Create an incident response plan — Identify roles and responsibilities for incident response.
Level 2: Define an incident response process — Establish a formal incident response process and ensure staff are properly trained in performing their roles.
Level 3: Establish an incident response team — Employ a dedicated, well-trained incident response team.

Environment Management (EM)#

The organization’s work on application security doesn’t end once the application becomes operational. New security features and patches are regularly released for the various elements of the technology stack you’re using, until they become obsolete or are no longer supported.

Most of the technologies in any application stack are not secure by default. This is frequently intentional, to enhance backwards compatibility or ease of setup. For this reason, ensuring the secure operation of the organization’s technology stack requires the consistent application of secure baseline configurations to all components. The Environment Management (EM) practice focuses on keeping your environment clean and secure.

Vulnerabilities are discovered throughout the lifecycles of the technologies on which your organization relies, and new versions addressing them are released on various schedules. This makes it essential to monitor vulnerability reports and perform orderly, timely patching across all affected systems.

Stream A – Configuration Hardening

The activities in this stream focus on the organization’s management of security-related configurations in all elements of the technology stack. The emphasis is on those elements (e.g., operating systems, containers, frameworks, services, appliances, and libraries) obtained from third parties, because their architecture and design are not under the organization’s control.

Level 1: Use best-effort hardening — Perform best-effort hardening of configurations, based on readily available information.
Level 2: Establish hardening baselines — Perform consistent hardening of configurations, following established baselines and guidance.
Level 3: Perform continuous configuration monitoring — Actively monitor configurations for non-conformance to baselines, and handle detected occurrences as security defects.

Stream B – Patching and Updating

The activities in this stream focus on the organization’s handling of patches and updates for all elements of the technology stack. For software developed by the organization, these activities are concerned with delivering patches and updates to customers, as well as applying them to organization-managed solutions (e.g., software as a service). For third-party elements, these activities are concerned with the organization’s timely application of updates and patches received.

Level 1: Practice best-effort patching — Perform best-effort patching of system and application components.
Level 2: Formalize patch management — Perform regular patching of system and application components, across the full stack. Ensure timely delivery of patches to customers.
Level 3: Enforce timely patch management — Actively monitor update status and manage missing patches as security defects. Proactively obtain vulnerability and update information for components.

Operational Management (OM)#

The Operational Management (OM) practice focuses on activities to ensure security is maintained throughout operational support functions. Although these functions are not performed directly by an application, the overall security of the application and its data depends on their proper performance. Deploying an application on an unsupported operating system with unpatched vulnerabilities, or failing to store backup media securely, can make the protections built into that application irrelevant.

The functions covered by this practice include, but are not limited to: system provisioning, administration, and decommissioning; database provisioning and administration; and data backup, restore, and archival.

Stream A – Data Protection

The activities in this stream focus on ensuring the organization properly protects data in all aspects of their creation, handling, storage, and processing.

Level 1: Organize basic data protections — Implement basic data protection practices.
Level 2: Establish a data catalog — Develop data catalog and establish data protection policy.
Level 3: Respond to data breaches — Automate detection of policy non-compliance, and audit compliance periodically. Regularly review and update to data catalog and data protection policy.

Stream B – System Decommissioning / Legacy Management

From the perspective of the organization as a consumer of resources, the activities in this stream focus on the identification, management, and tracking of systems, applications, application dependencies, and services that are no longer used, have reached end of life, or are no longer actively developed or supported. Removal of unused systems and services improves manageability of the environment and reduces the organization’s attack surface, while affording direct and indirect cost savings (e.g., reduced license count, reduced logging volume, or reduced analyst effort).

Level 1: Identify unused applications — Decommission unused applications and services as identified. Manage customer upgrades/migrations individually.
Level 2: Formalize decommissioning process — Develop repeatable decommissioning processes for unused systems/services, and for migration from legacy dependencies. Manage legacy migration roadmaps for customers.
Level 3: Review application lifecycle state regularly — Proactively manage migration roadmaps, for both unsupported end-of-life dependencies, and legacy versions of delivered software.