Security Operations Fundamentals and Guidance
draft-parsons-opsawg-security-operations-02

TBD                                                           M. Parsons
Internet-Draft                                               F. Driscoll
Intended status: Informational         UK National Cyber Security Centre
Expires: 13 March 2027                                  9 September 2026

             Security Operations Fundamentals and Guidance
              draft-parsons-opsawg-security-operations-02

Abstract

   Security operators are responsible for detecting malicious activity,
   responding to threats and defending their networks and systems from
   cyber attacks.  Security operations are commonly entwined with other
   operational and management priorities to ensure that both security
   and operational priorities are considered holistically.

   With security operators being a crucial part of operation, management
   and security of the network, it is valuable to give consideration to
   them during the design of new protocols.  This document builds upon
   draft-ietf-opsawg-rfc5706bis, describing the fundamentals of security
   operations to provide a foundation for considerations for protocol
   design and guidance.  This document also describes how security
   operations considerations can be most usefully included in other IETF
   documents.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-parsons-opsawg-security-
   operations/.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

Parsons & Driscoll        Expires 13 March 2027                 [Page 1]
Internet-Draft             Security Operations            September 2026

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 13 March 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Responsibilities of Security Operators  . . . . . . . . . . .   5
     2.1.  Threat Intelligence . . . . . . . . . . . . . . . . . . .   5
     2.2.  Security Monitoring . . . . . . . . . . . . . . . . . . .   5
     2.3.  Incident Response . . . . . . . . . . . . . . . . . . . .   6
   3.  Artefact Requirements . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Asset Management  . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Identity and Access Management  . . . . . . . . . . . . .   7
     3.3.  Indictors of Compromise . . . . . . . . . . . . . . . . .   8
     3.4.  Digital Forensics and Logging . . . . . . . . . . . . . .   8
   4.  Tooling Requirements  . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Collection  . . . . . . . . . . . . . . . . . . . . . . .   9
     4.2.  Detection . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.3.  Investigation . . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Response  . . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Additional Benefits of Security Operations  . . . . . . . . .  12
     5.1.  Vulnerability management  . . . . . . . . . . . . . . . .  12
     5.2.  Threat Modelling and Architecture Review  . . . . . . . .  12
   6.  Security Operation Considerations . . . . . . . . . . . . . .  12
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. Informative References  . . . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

Parsons & Driscoll        Expires 13 March 2027                 [Page 2]
Internet-Draft             Security Operations            September 2026

1.  Introduction

   Security operations are a crucial part of both the security and
   management of a network, enterprise or system.  Security operators
   work to not only prevent cyber attacks but also to identify, limit
   the impact of and recover from attacks that bypass preventative
   security controls, through monitoring and responding to threats as
   part of day-to-day operation.

   The approach, tools and day-to-day work of security operators is
   deeply tied together with the protocols that run over their networks
   and are used by attackers and defenders.  As such, it is valuable to
   provide security operators with guidance to address any changes that
   may affect ability to detect and respond to threats when deploying a
   new protocol.  This document describes describes the role and
   responsibilities of security operators, to support authors of other
   IETF documents in understanding how they might be impacted by new
   protocols and new protocol features.  It provides advice on how to
   document these impacts and how to include guidance on deployment or
   operation in IETF documents.  This early guidance is particularly
   valuable as retrofitting mechanisms can be difficult and any impact
   may risk both the operational efficiency and security of the network.

   Security operations are commonly run from a Security Operations
   Centre (SOC): a centralised team or function that includes both cyber
   security analysts and operational engineers to protect and defend the
   network.  Many different types of organisations will have a SOC,
   particularly those that manage sensitive data, or provide a critical
   service.  A SOC is distinguished from a Network Operations Centre
   (NOC) by its function.  While a SOC is responsible for protecting an
   organisation from and responding to cyber attacks, a NOC is
   responsible for ensuring that network performance is maintained
   during normal business.

   Those who work in security operations may have many different roles
   or job titles including, but not limited to, cyber security analyst,
   incident responder, security engineer and security operations
   manager.  In this document the term security operator is used to
   cover all roles in security operations.

   Security operators improve the security of the network through a
   broad range of functions.  These range from pre-emptive threat
   intelligence and knowledge building, through continuous network
   management and monitoring for suspicious activity, responding to
   incidents and defending the network during an attack, and recovery of
   the system to a secure state following an incident.

Parsons & Driscoll        Expires 13 March 2027                 [Page 3]
Internet-Draft             Security Operations            September 2026

   One organisational model is for operational and security
   responsibilities to be managed by separate teams with distinct
   objectives: security teams focusing on identifying and mitigating
   cyber security threats, and operational teams prioritising
   availability, performance, and the overall efficiency of network
   services.  This model can have advantages, for example in enabling
   separation of duties.  However, complete separation can also lead to
   conflicting priorities and outcomes.  For example, security or
   compliance requirements could delay the deployment of new services,
   while operational and efficiency requirements could inadvertently
   introduce weaknesses that increase security risks.

   The term SecOps [SECOPS], is commonly used to define an approach to
   combine operational and security teams, tools and processes to ensure
   both the protection and reliable operation of networks.  As cyber
   security threats continue to increase in both frequency and scale, a
   more integrated and coordinated approach is often necessary.  When
   security processes are siloed from operational processes, it can be
   challenging to adapt to emerging threats in a timely manner, and both
   security and network performance may be negatively impacted.
   Embedding security practices directly into operation and management,
   rather than as a bolt-on, is often necessary for security, hence
   security operations are an integral part of the operation and
   management of many environments and enterprises.  In this model the
   NOC and SOC may be one function, focused on both network performance
   and security, although this is not required.  The SecOps approach
   considers the system as a whole in order to achieve both security and
   operational goals.

   As such, security operations should be considered during the design
   of new protocols.  This document outlines the key fundamentals of
   security operations to supplement the guidance provided in
   [I-D.ietf-opsawg-rfc5706bis] to support protocol designers.This
   document provides fundamentals but is not exhaustive; protocol
   designers are encouraged to work with security operators during
   development and review.  While not the focus of this document,
   security operators are often well-placed to provide insight into use
   and abuse of existing protocols, including identifying novel command-
   and-control channels, tunnelling, and features abused for evasion.
   This information can then be fed back to protocol designers to inform
   the design of updated protocols or new security features.

Parsons & Driscoll        Expires 13 March 2027                 [Page 4]
Internet-Draft             Security Operations            September 2026

2.  Responsibilities of Security Operators

   Security operators have key responsibilities to ensure the security
   of their network, which can be broken down into the categories below.
   During the design of new protocols, it may be useful to take these
   responsibilities into account to reduce or highlight any potential
   adverse impact of deployment on security operations.  Different
   organisations will consider different functions and roles as part of
   their security operations team, so these categories will not apply to
   all organisations.

2.1.  Threat Intelligence

   Threat Intelligence (TI) is a term used to refer to the knowledge of
   cyber attackers' activities.  This may include an understanding of a
   threat actor's motivations, in-depth technical descriptions, and
   indicators of an attacker's activities.  Security operators can both
   produce their own Threat Intelligence and consume it from other
   sources to stay ahead of new attacker techniques.  Building Threat
   Intelligence includes the collection, analysis and dissemination of
   information about possible cyber security threats.  Security
   operators are responsible for developing their understanding of
   threat actor capabilities, tools and techniques in order to plan
   ahead to mitigate and respond to potential threats.  They also ensure
   Threat Intelligence information is deployed across their network to
   support detection of malicious activity.  Effective deployment of
   Threat Intelligence contributes not only to the security of the
   networks under the operators' responsibility but also strengthens the
   broader security community by enabling shared awareness of evolving
   threats.

2.2.  Security Monitoring

   Security operators are responsible for monitoring all parts of the
   environment that they are protecting and managing including any
   infrastructure, network traffic, endpoints, data flows and log
   sources.  The objective of this monitoring is to establish a baseline
   of normal activity and identify deviations that may indicate
   malicious activity.  It is essential that this monitoring is
   continuous as advanced actors frequently "dwell" in the network to
   evade immediate detection and conduct malicious activity at known
   operational downtimes to reduce the likelihood of being observed by
   security operators.  In addition to reactive monitoring, security
   operators perform proactive "threat hunting".  Rather than awaiting
   alerts generated by security tooling, threat hunting involves
   targeted analysis of the network and investigation to identify
   previously unknown indicators of malicious activity.  Based on the
   Threat Intelligence responsibility, security operators are

Parsons & Driscoll        Expires 13 March 2027                 [Page 5]
Internet-Draft             Security Operations            September 2026

   responsible for developing their capability to detect attackers,
   through developing and using tooling, which will involve engineering
   and operational experts to ensure this capability is maintained and
   improved.

2.3.  Incident Response

   Security operators are responsible for responding to cyber security
   incidents should the network be targeted by a cyber attack.  Such
   attacks can have significant impact, and a key part of a security
   operator's role is to design, implement and update an incident
   response plan to minimise the impact and help normal operations
   resume as quickly as possible.  Through effective security
   monitoring, security operators discover potential suspicious
   activity, and it is their responsibility to investigate this and
   determine whether the activity is malicious.  In the event of
   confirming such an attack on the network, the security operators will
   follow their plan to conduct rapid response to defend against the
   attack, reduce its impact and return the network to a secure and
   operational state.  Following the resolution of an incident, security
   operators also conduct post incident analysis to understand the
   impact, for example if any data breaches occurred, and may perform a
   root-cause analysis to prevent similar attacks in future.

3.  Artefact Requirements

   This section outlines some of the fundamental artefacts that are used
   by security operators to support the security and operation of the
   network.

   With increasingly complex cyber threats, and to support both
   operational and security objectives, it is important that security
   operators have multiple opportunities to detect malicious activity at
   different parts of the network and to account for different points of
   failure.  Thus, network defence techniques often use multiple layers
   of defence with several different mitigations at each layer - a
   concept referred to as "defence-in-depth".  This approach can apply
   to considering security at different parts of the network, for
   example detecting activity at the network edge and on endpoints, and
   security operators also apply network level controls to separate
   traffic to support their security monitoring responsibilities.
   Security operators rely upon artefacts from a variety of sources to
   achieve their goals.

Parsons & Driscoll        Expires 13 March 2027                 [Page 6]
Internet-Draft             Security Operations            September 2026

3.1.  Asset Management

   Defence and management of an environment relies on knowing what
   hardware and software assets have access to, or are installed on, a
   network or system.  An accurate inventory is necessary to manage the
   security of an organisation's assets, to ensure that unauthorised
   devices are not present on the system and to understand how an
   organisation may be impacted by a cyber incident.

   The term "Shadow IT" is often used to refer to assets that are not
   accounted for.  This can include devices which are not officially
   onboarded or are misconfigured, but also includes services, tools and
   accounts with access to the system.  Shadow IT may introduce threats
   to the security of the system as protections and controls put in
   place may be ineffective.

   In modern environments and networks, particularly the cloud, assets
   may not be static.  Therefore, approaches that take into account the
   dynamic and ephemeral nature of resources are required to distinguish
   between legitimate auto-scaling and malicious activity.

   A good asset management approach will use tools to scan the
   environment for new, modified or removed assets on a regular or
   continuous basis.  It should maintain an authoritative and accurate
   repository of information, which should be made accessible to
   security operators.  It could use a variety of data sources including
   procurement records, mobile device management and logging platforms.
   Security operators are most likely to use asset management systems to
   identify devices or software that should not be on the system, as
   well as to identify legitimate assets that need to be protected as
   part of a cyber incident.

3.2.  Identity and Access Management

   Protecting against cyber threats also relies on understanding and
   managing who and what should have access to data, systems and
   services, as well as monitoring access.  Identity and access
   management (IAM) is necessary to distinguish legitimate access from
   an attack.

   A good IAM approach should include logging and monitoring of
   authentication and authorisation events.  These logs should be
   safeguarded against tampering, with inbuilt alerts for suspicious
   behaviour.  These could include login attempts that fail the second
   step of multi-factor authentication (MFA), brute-forcing of
   passwords, and attempts from unexpected locations or devices.
   Activity from high-privilege accounts (e.g. admin accounts) should be
   monitored with particular attention.

Parsons & Driscoll        Expires 13 March 2027                 [Page 7]
Internet-Draft             Security Operations            September 2026

3.3.  Indictors of Compromise

   The identification of Indicators of Compromise (IoCs) is relied upon
   by security operators to identify and defend against malicious
   activity on the network and endpoints that they are responsible for.
   As outlined in [RFC9424], IoCs are observable artefacts relating to a
   cyber threat actor or their activities, such as their tactics,
   techniques, procedures (TTPs), or tooling and attack infrastructure.
   Examples of IoCs include hash values of known malicious files or
   executables, IP addresses or domain names associated with malicious
   traffic or software and tooling used by attackers.  These artefacts
   could be network based, such as information about Command and Control
   (C2) infrastructure embedded in network protocols, endpoint based,
   such as suspicious files or software, or behaviour based such as
   irregular account or access activity.

   These artefacts can be observed on the network or at hosts and
   endpoints, including infrastructure, services and applications.  They
   help security operators to proactively block malicious activity,
   whether that be blocking traffic or preventing code execution at a
   point in the network.  IoCs support Incident Response as they are
   crucial in determining whether an attack has taken place.  Similarly,
   they can be used to link discovered suspicious activity to a known
   attackers, which enables further investigation and mitigations to be
   put in place.  Having IoCs deployed to various security control
   points across a system supports a defence-in-depth approach which
   should be used by security operators.

   Security operators not only discover, use and deploy IoCs in the
   systems that they are responsible for, but also consume and share
   IoCs with the wider security community to increase wider
   understanding of emerging cyber threats.  Sharing of IoCs requires
   interoperable and standardised formats; [RFC7970] and
   [I-D.draft-grimminck-safe-ioc-sharing] provide methods that improve
   the ability of operators to resolve security incidents.

3.4.  Digital Forensics and Logging

   Alongside deployment of IoCs to detect and reduce the effects of
   compromise, security operators require digital forensics from the
   network, endpoints, hosts and applicationsto enable effective
   incident response or threat hunting.  For example, details of
   authentication or authorization events, network traffic or endpoint-
   detection events can be found in logs.

   It is important to use a range of log sources, as each log source
   will give a different view of attacker activity to build a full
   picture and enable effective defensive mitigations.  For example,

Parsons & Driscoll        Expires 13 March 2027                 [Page 8]
Internet-Draft             Security Operations            September 2026

   authentication logs provide details when adversaries attempt to gain
   unauthorised access to systems, DNS logs can provide the first
   indications of a compromise device, and anti-malware software logs
   help to identify specific attacker capabilities.  [NIST_800-81]
   contains more information on the use of DNS for threat intelligence.

   In some cases, additional context will be valuable for security
   operators to be able to use log data.  When security alerts require
   additional investigation, logs including surrounding context greatly
   increase the efficiency of response.  For example, details of who
   made a change may help an operator investigating an incident to know
   which authority made it and thus identify a misconfiguration from a
   genuine attack.

   Understanding and interpreting log sources is not always
   straightforward, so security operators typically use log analytic
   techniques to index, enrich and query log data and thus take
   effective action.

   Security operators, through their Threat Intelligence insight play a
   role in threat modelling which enables effective identification of
   valuable log sources.  Security operators are responsible for
   ensuring that logging processes and data are secured effectively.

   [DIGITAL_FORENSICS] provides additional guidance on digital
   forensics, including logging requirements, management and protection.

4.  Tooling Requirements

   Changes to protocols may require changes to how a security operator
   fulfils their role, including potential changes to tooling.  Such
   changes may also affect how safely and effectively such tools,
   including automated tools, can be used.  This should be highlighted
   when writing protocol specifications.  To assess this, the following
   section outlines how security operators use tools to carry out the
   different aspects of their role, which could be considered in
   protocol development.

4.1.  Collection

   Security operators use a range of tooling to collect information
   about the environment that they are protecting.  Having comprehensive
   observability can provide foundational data needed to facilitate the
   functions security operators are required to fulfil.  Data from one
   system or tool typically does not provide enough detail for security
   operators to assess and defend against complex attacks.

Parsons & Driscoll        Expires 13 March 2027                 [Page 9]
Internet-Draft             Security Operations            September 2026

   Collection tooling can be deployed to understand activity on
   endpoints, such as workstations, laptops or phones or workloads in
   cloud environments.  This is complemented by tooling to provide
   information regarding network data and traffic flows to identify
   suspicious patterns.  The principle of collecting information at
   various points of the environment is fundamental, as it offers the
   ability to detect threats would otherwise go unnoticed, for example
   an attacker moving laterally through the network would be hard to
   spot with just endpoint data.  Both encrypted and unencrypted data
   may be collected and stored and this can include both content and
   metadata.  Collected data is referred to as "events", which are
   defined by as "any observable occurrence in a network or information
   system" [NIST-EVENT].

4.2.  Detection

   Once data has been collected, security operators use a combination of
   these events (from the network and from endpoints) and threat
   intelligence to identify potential attacks.  Typically, this analysis
   is not possible manually, so security operators rely on automatic
   tooling, such as a SIEM (Security Information and Event Management),
   to correlate, enrich and analyse this information.  Security
   operators use data from collection tooling to establish a baseline of
   normal behaviour patterns.  They generate security rules to identify
   deviations from this baseline or other suspicious activity.
   Automation tools then use these rules to trigger alerts for security
   operators to investigate.  These rules require effective management,
   as false positive may lead to "alert fatigue", where frequent alerts
   may be ignored, raising the risk of real compromises being missed.
   Once alerts have been generated, they need to be triaged to identify
   those that are highest priority to investigate.

   A challenge that security operators face is the increase in cyber
   threat actors deploying "living off the land" [LOTL] techniques, so
   that their activity does not appear malicious and thus is often not
   identified by a single tool.  A comprehensive view and detailed
   analysis of events from across the system is needed to prevent
   security and privacy breaches.

4.3.  Investigation

   Once an event has been triaged and identified as high priority,
   security operators will further investigate this activity to
   understand the risk and defend against the potential attack.  This
   will often take place within an Incident Management System (IMS),
   which tracks incidents and outcomes.  This may be part of the SIEM or
   may be a separate tool.

Parsons & Driscoll        Expires 13 March 2027                [Page 10]
Internet-Draft             Security Operations            September 2026

   Security operators may use "playbooks" to support these
   investigations.  These will provide a list of steps to take for
   investigating common types of alerts, to ensure that investigations
   are thorough and repeatable.  Tools may enforce use of these
   playbooks so that the steps must be completed, or are automatically
   completed, before the investigation can be closed.

   Security operators rely upon tools such as Protocol Dissectors to
   parse and interpret individual network protocols.  Dissecting
   protocols across network layers allows security operators to
   understand, analyse and filter traffic on their system so they can
   detect and defend against attacks.  Dissectors support the
   identification of suspicious behaviour and malicious traffic that
   would otherwise be hidden within regular network traffic.  These
   tools also support forensic investigation after an attack to
   understand how an attacker gained access and prevent this in future.

4.4.  Response

   If an investigation identifies an attack or other security incident,
   security operators need to prevent further damage and restore the
   network to a safe state.

   This can be done with tools deployed at various parts of the network,
   for example tooling on the endpoints allows security operators to not
   only monitor and identify threats, but also respond to them by
   isolating potentially compromised devices from the network in order
   to prevent a cyber threat actor's next stages of attack.  Similarly,
   network-based detection tooling often also offers the ability to
   respond to threats by blocking malicious traffic once it has been
   identified.

   As with detection, triage and investigation, security operators
   increasingly rely on the ability to automate routine security and
   operational tasks to improve efficiency of response, for example
   using Security Orchestration, Automation, and Response (SOAR) tooling
   [IBM-SOAR].  Based on threat related data that is collected, tools
   are used to automate response without human intervention, based on
   predefined playbooks.  These playbooks are designed by security
   operators with both incident response and operational priorities in
   mind.  This automation is important for security operators who
   experience an overwhelming volume of threats and would otherwise be
   unable to defend their networks.

Parsons & Driscoll        Expires 13 March 2027                [Page 11]
Internet-Draft             Security Operations            September 2026

5.  Additional Benefits of Security Operations

   Whilst the core responsibilities of security operators are outlined
   above, they may be well placed to support other important security
   functions.

5.1.  Vulnerability management

   Security operators are well positioned to proactively find
   vulnerabilities in the systems and infrastructure that they are
   responsible for.  As part of their investigations security operators
   may conduct vulnerability scanning and security assessments and thus
   be able to triage and report priority issues to system owners who are
   responsible for patch management.  This helps to mitigate security
   issues found before they can be exploited by cyber threat actors.
   This patching and remediation is an example where the joining of
   security and operational teams has particular value as patch
   management may involve prioritisation based on impact, risk and
   deployment considerations.  When designing new protocols,
   consideration should be given to enabling efficient patching, for
   example supporting cheap and fast connection handoffs and
   reconnections to enable services to be brought down, updated and re-
   established quickly and efficiently.

5.2.  Threat Modelling and Architecture Review

   With their unique position, security operators are well placed to
   support wider security teams in developing the required security
   posture for their network.  Blending insight from Threat Intelligence
   with a deep understanding of the operational aspects of the network,
   security operators can work with design teams to ensure their
   priorities are supported.  This perspective of current cyber threats,
   particularly how existing protocols are use and misused, and
   operational experience can also be considered in protocol
   development.

6.  Security Operation Considerations

   The previous sections outline what security operations is, and the
   artefacts and tooling that it relies upon.  During the design and
   development of protocols, it is valuable to consider how security
   operators could be impacted by changes and mitigate such impact if
   possible.  If they cannot be mitigated, then clearly documenting such
   considerations will aid security operators if and when the new
   protocol is deployed.  Different organisations and systems may have
   different requirements, priorities and risks, so relevant
   considerations will depend on the context.  For example, telecom
   operators may require increased focus on scale and throughput when

Parsons & Driscoll        Expires 13 March 2027                [Page 12]
Internet-Draft             Security Operations            September 2026

   compared to enterprise scenarios.

   New protocols may have implications for the types, locations or
   availability of IoCs and it is important for security operators to
   understand these implications in order to continue to effectively
   monitor for malicious activity.  To support this, protocol designers
   could document which observable artefacts remain available to
   defenders, which indicators can no longer be observed and whether new
   artefacts are introduced that could support detection, investigation
   or incident response.

   Similarly, consideration should be given to how a new protocol or a
   change to a protocol may impact attackers' capabilities, such as
   Command and Control (C2) communications, network traversal or
   facilitation of exfiltration of data from the network.  Where there
   are new or different opportunities for performing such malicious
   activity or where current defence techniques are prevented, it is
   important that this is captured to inform security operations and
   mitigated where possible to ensure their Threat Intelligence function
   can be fulfilled.  [MITRE_ATTACK] provides a a knowledge base of
   attacker techniques which may be useful for assessing how a protocol
   impacts such capabilities.  Protocol designers are encouraged to work
   with security operators and other cyber security experts for support
   during protocol design.

   One indicator of malicious activity that security operators use is to
   consider traffic levels and traffic patterns in order to identify
   suspicious activity or to defend against malicious distributed
   denial-of-service (DDoS) attacks.  Mitigations should be included or
   threats documented if new protocols could be used to create DDoS
   attacks, for example amplification attacks in DNS or NTP.  [RFC4732]
   provides further considerations for protocol designers with regards
   to denial-of-service.

   As outlined above, security operations rely on a variety of log
   sources enable effective incident response or threat hunting.  If a
   new protocol changes the properties or topology of the network, this
   may impact the requirement for digital forensics.  Whilst not a
   complete solution, considering logging during protocol design is a
   positive mechanism to support security operators.
   [I-D.ietf-quic-qlog-main-schema] is an example of structured logging
   for network protocols, which was designed to be extensible for
   different scenarios and to avoid fragmentated, non-standardised
   formats being created independently.

   Protocol designers and implementers have expertise in the possible
   errors or abnormal conditions can occur in the running of the
   protocol.  Where possible, detectable error conditions should be

Parsons & Driscoll        Expires 13 March 2027                [Page 13]
Internet-Draft             Security Operations            September 2026

   documented to support security operators to respond effectively.
   This documentation could include possible error conditions along with
   recommendations about how they can be detected and which fields
   should be logged.

   Impact on tooling should be considered.  Updating and augmenting
   existing tools is expected when the network is upgraded or new
   functionality is deployed, but having to completely rebuild such
   tooling will greatly reduce the effectiveness of security operators.
   A mitigation for this may be to consider designing flexibility for
   future versions and extensions into protocols so that code can be
   easily written to handle, identify and differentiate between protocol
   versions.  As well as the impact on efficacy of a tool, protocol
   designers should consider the impact of a design on the ability to
   audit and validate actions taken or observations made by a tool.

   In general, where protocols are being updated or replaced,
   consideration should be given to the current techniques employed by
   security operators who use the deployed protocol.  This should
   include the techniques, tooling and corresponding infrastructure used
   to provide security and effective operation of the network.  Where
   possible, these practices should remain consistent, or mitigations or
   documentation included to ensure security operations are not
   adversely affected.

7.  Operational Considerations

   This document focuses primarily on operational considerations in
   addition to [I-D.ietf-opsawg-rfc5706bis] .

8.  Security Considerations

   This document supports improving security by helping protocol
   designers consider security operators and their effort to mitigate
   cyber threats.  It focused on the operational aspects, rather than
   the security of the protocols.

Parsons & Driscoll        Expires 13 March 2027                [Page 14]
Internet-Draft             Security Operations            September 2026

   Security operators have access to sensitive data, which is critical
   to protect for the security and privacy of the network.  It is
   important that such data is suitably secured and that appropriate
   controls are in place to enforce this, for example ensuring security
   operations data is segregated from the rest of the network, security
   operations tools and actions audited, and logs and forensic data
   securely stored and access controlled.  Protocol designers may need
   to consider both security observability and appropriate handling of
   sensitive data when designing operational artefacts or logging
   mechanisms.  Additional legal and governance requirements are often
   raised on security operators to ensure that such access is only being
   used for the intended purpose and thus benefiting the security of the
   system.

   Some security operator techniques take place on unencrypted traffic,
   for example HTTPS inspection [HTTPS-inspection].  This is where an
   organisation breaks the encryption on TLS traffic on their own
   network, on traffic it is authorised to inspect, to check the content
   for malware or identify attacks.  Techniques such as this as likely
   to have a better chance of blocking attacks than inspection of
   encrypted traffic, but if done incorrectly they can create security
   vulnerabilities.  More on the impact of encryption on operators is
   covered in [RFC8404].

   As per [RFC6973], it is important to consider privacy of users of the
   system and its relation to effective security operations.  There may
   be tensions when making choices between effective security operations
   and complete privacy during protocol design and deployment.  Security
   operators benefit from a detailed understanding of activity on the
   network in order to identify and respond to cyber attacks and this
   may be at odds with minimising information to increase user privacy.
   In contrast, effective security operations can prevent malicious
   actors from accessing and exfiltrating user data, thus improving
   privacy.  The necessary amount of observability for user privacy and
   security will depend on the context and the system.  Protocol design
   choices should be documented so implementers and users can make
   informed decisions in order to maximise both security and privacy
   properties.

9.  IANA Considerations

   This document has no IANA actions.

10.  Informative References

Parsons & Driscoll        Expires 13 March 2027                [Page 15]
Internet-Draft             Security Operations            September 2026

   [DIGITAL_FORENSICS]
              "Guidance on digital forensics", February 2025,
              <https://www.ncsc.gov.uk/guidance/guidance-on-digital-
              forensics-protective-monitoring>.

   [HTTPS-inspection]
              "What is HTTPS inspection?", September 2026,
              <https://www.cloudflare.com/learning/security/what-is-
              https-inspection/>.

   [I-D.draft-grimminck-safe-ioc-sharing]
              Grimminck, S., "Safe and Reversible Sharing of Malicious
              URLs and Indicators", Work in Progress, Internet-Draft,
              draft-grimminck-safe-ioc-sharing-13, 3 September 2026,
              <https://datatracker.ietf.org/doc/html/draft-grimminck-
              safe-ioc-sharing-13>.

   [I-D.ietf-opsawg-rfc5706bis]
              Claise, B., Clarke, J., Farrel, A., Barguil, S.,
              Pignataro, C., and R. Chen, "Guidelines for Considering
              Operations and Management in IETF Specifications", Work in
              Progress, Internet-Draft, draft-ietf-opsawg-rfc5706bis-07,
              7 September 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-opsawg-rfc5706bis-07>.

   [I-D.ietf-quic-qlog-main-schema]
              Marx, R., Niccolini, L., Seemann, M., and L. Pardue,
              "qlog: Structured Logging for Network Protocols", Work in
              Progress, Internet-Draft, draft-ietf-quic-qlog-main-
              schema-14, 6 July 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-quic-
              qlog-main-schema-14>.

   [IBM-SOAR] "What is SOAR?", May 2026,
              <https://www.ibm.com/think/topics/security-orchestration-
              automation-response>.

   [LOTL]     "Identifying and Mitigating Living Off the Land
              Techniques", March 2025,
              <https://www.cisa.gov/sites/default/files/2025-03/Joint-
              Guidance-Identifying-and-Mitigating-LOTL508.pdf>.

   [MITRE_ATTACK]
              "MITRE ATT&CK", May 2026, <https://attack.mitre.org/>.

   [NIST-EVENT]
              "NIST Computer Security Resource Center", September 2026,
              <https://csrc.nist.gov/glossary/term/event>.

Parsons & Driscoll        Expires 13 March 2027                [Page 16]
Internet-Draft             Security Operations            September 2026

   [NIST_800-81]
              "Secure DNS Deployment Guide", March 2026,
              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-81r3.pdf>.

   [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
              Denial-of-Service Considerations", RFC 4732,
              DOI 10.17487/RFC4732, December 2006,
              <https://www.rfc-editor.org/rfc/rfc4732>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/rfc/rfc6973>.

   [RFC7970]  Danyliw, R., "The Incident Object Description Exchange
              Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
              November 2016, <https://www.rfc-editor.org/rfc/rfc7970>.

   [RFC8404]  Moriarty, K., Ed. and A. Morton, Ed., "Effects of
              Pervasive Encryption on Operators", RFC 8404,
              DOI 10.17487/RFC8404, July 2018,
              <https://www.rfc-editor.org/rfc/rfc8404>.

   [RFC9424]  Paine, K., Whitehouse, O., Sellwood, J., and A. Shaw,
              "Indicators of Compromise (IoCs) and Their Role in Attack
              Defence", RFC 9424, DOI 10.17487/RFC9424, August 2023,
              <https://www.rfc-editor.org/rfc/rfc9424>.

   [SECOPS]   "NICCS Glossary", February 2026,
              <https://niccs.cisa.gov/resources/glossary>.

Acknowledgments

Authors' Addresses

   Michael Parsons
   UK National Cyber Security Centre
   Email: michael.p1@ncsc.gov.uk

   Florence Driscoll
   UK National Cyber Security Centre
   Email: florence.d@ncsc.gov.uk

Parsons & Driscoll        Expires 13 March 2027                [Page 17]