Security Operations Fundamentals and Guidance

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. 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 , 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 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.

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.

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.

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 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.

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.

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.

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.

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.

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 , 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; and provide methods that improve the ability of operators to resolve security incidents.

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, 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. 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. provides additional guidance on digital forensics, including logging requirements, management and protection.

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.

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. 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" .

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" 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.

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. 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.

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 . 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.

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.

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.

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.

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 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. 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. 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. 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 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.

Operational Considerations This document focuses primarily on operational considerations in addition to .

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. 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 . 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 . As per , 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.

IANA Considerations This document has no IANA actions.