Strategy 3: Give the SOC the Authority to Do Its Job

SOC’s ability to assert authority must either be through written authority or inherited the parent organization. In our third strategy, we address:

1. what authorities the SOC needs
2. what organizational alignment will best aid the CND mission.

Written Authorities

Charter Authority

An effective SOC should have a charter and set of authorities signed by constituency executive(s) in order to press for the resources and cooperation needed to execute its mission.

Lowest Tier SOC

• To function as the operational center and head of cyber intrusion monitoring, defense, and incident response for the constituency
• Within its constituency, the authorities to:
  • Deploy, operate, and maintain active and passive monitoring capabilities, both on the network and on end hosts Proactively and reactively scan hosts and networks for network mapping, security configuration, and vulnerability/patch status
  • With SOC line manager approval, coordinate or directly apply countermeasures (including the termination of network resources) against systems and user accounts involved in an incident, in coordination with system and network owners
  • Respond directly to confirmed incidents, in cooperation with appropriate parties, possibly including reporting outside of their management chain to entities such as the CIO or CEO, if necessary
  • Gather, retain, and analyze artifacts such as audit log data, media images (hard drive, removable media, etc.), and traffic captures from constituency IT system to facilitate incident analysis on both an ad hoc and sustained basis, recognizing any handling caveats derived from applicable laws, regulations, policies, or statutes.
• To be recognized by help desk staff, ISSMs, ISSOs, and IT support staff when reporting, diagnosing, analyzing, or responding to misconfiguration issues, outages, incidents, or other problems that the SOC needs external support to resolve
• To architect, acquire, engineer, integrate, operate, and maintain monitoring systems and the SOC enclave
• To exercise control over funding for tool engineering, maintenance, staffing, and operational costs
• To support any other capabilities it intends to offer, such as security awareness building, cybersecurity education/training, audit collection, or insider threat monitoring.

Central Coordination SOC

• Serve as an entity that is operationally superior to subordinate SOCs

Other Enabling Policies

The SOC should consider influencing or providing comment on these policies or seeing that they are created,
if they do not already exist:

• User consent to monitoring: Giving the SOC and auditors the unambiguous ability to monitor and retain any and all activity on all systems and networks in the constituency
• Acceptable use policy: IT system usage rules of behavior, including restrictions on Internet and social media website use and authorized software on constituency systems
• Privacy and sensitive data handling policies: Instructions for managing and protecting the types of information flowing across the monitored network, including personal, health, financial, and national security information
• Internally permitted ports and protocols: Enumeration of the ports and protocols allowed within the constituency, across the core, and through enclave boundaries
• Externally permitted ports and protocols: Enumeration of ports and protocols allowed by devices through external boundaries such as through a demilitarized zone (DMZ), to business partners and to the Internet
• Host naming conventions: Describing conventions for naming and understanding the basic type and role of IT assets on the basis of their DNS record
• Other IT configuration and compliance policy: Everything from password complexity to how systems should be hardened and configured
• Bring your own device and mobile policies (if applicable): Rules that govern how employees may interface with constituency networks, applications, and data with personally owned IT equipment and mobile devices
• Approved OSes, applications, and system images: The general approved list of OSes, applications, and system baselines for hosts of each type—desktops, laptops, servers, routers/switches, and appliances
• Authorized third-party scanning: Rules for notifying the SOC when another organization wishes to perform scanning activity such as for vulnerabilities or network discovery
• Audit policy: High-level description of the event types that must be captured on which system types, how long the data must be retained, who is responsible for reviewing the data, and who is responsible for collecting and retaining the data with recognition of the performance impact value of the data gathered
• Roles and responsibilities of other organizations with respect to incident response: Most notably those bolded in Appendix A
  Written service level agreements (SLAs) where applicable:
  • Network capacity and availability requirements
  • Contingency planning if contracted network services fail
  • Network outage (incident) alerts and restoration and escalation/reporting times
  • Security incident alerts and remediation procedures and escalation/reporting times
  • Clear understanding of each party’s responsibilities for implementing, operating, and maintaining the security controls or mechanisms that must be applied to the network services being purchased.
• Legal policies: Concerning classifications of information, privacy, information retention, evidence admissibility, and testifying during investigations and prosecutions of incidents.

Regardless of organizational placement, a SOC often feels like the ugly duckling. This compels the SOC to regularly
connect with partner organizations and clearly articulate its role and value.

In order to support a healthy constituency, NOC and SOC functions should be viewed as equal partners, rather than one subordinate to the other.