Audit , Cybersecurity , Governance

SOCs: Focus on Outcome, Not Process

IG: NRC Should Redefine Contract to Outsource Security Operation Centers
SOCs: Focus on Outcome, Not Process

Organizations, in defining the goals of their security operation centers administered by contractors, should focus on outcomes and not processes.

See Also: Secure Access in a Hybrid IT World

That's a conclusion of an inspector general's audit of the Nuclear Regulatory Commission issued earlier this month, which experts say also applies to other government agencies and businesses.

Like many organizations in and out of government, the NRC outsources to a third-party contractor - in this case, Dell Federal Services - operation of its SOC, which monitors its information networks for suspicious activity. The inspector general says a major problem with the approach the NRC takes is that the agency, in its contracts, defines processes the contractor should follow and not the IT security outcomes it seeks.

Defining Goals, Metrics

"Although the contract performance criteria are aligned with National Institute of Standards and Technology and NRC internal guidance, the contract does not clearly define SOC performance goals and metrics that can be used to determine whether agency needs are being met," Stephen Dingbaum, NRC assistant inspector general for audits, writes in a report dated Jan. 11.

It's a common problem many enterprises face, says Mischel Kwon, former director of the U.S. Computer Emergency Readiness Team, noting that organizations often delineate the processes SOC contractors should follow rather than identify and analyze the threats faced by an organization.

Former U.S.-CERT Director Mischel Kwon contrasts outcome vs. process approach to governing security operation centers.

Many enterprises' SOC contracts were written years ago, and reflect a remnant of a past mindset, when many organizations viewed their SOCs as a way to identify and eradicate malware rather than using threat intelligence and other tools to understand the assailants' tactics and develop defenses against attacks, says Kwon, who operates her own eponymous IT security consultancy.

"Our adversaries don't follow a playbook and say, 'We're going to attack a network today,'" Kwon says. "They're obviously nimble and moving and we have learned that our SOCs also have to be nimble and move."

Sam Visner, senior vice president for cybersecurity at the professional services firm ICF International, analogizes enterprises defining outcomes versus establishing processes to a motorist buying a car. "You want a car that goes 100 mph, that's an outcome; you want a car that stops in a certain distance, that's an outcome," Visner says, adding that some car buyers would request an engine and brakes of specific sizes. "Why would you do that? If you're a car geek, that's fine. But a government agency that doesn't have cyber as a primary mission, shouldn't try to be a cyber geek."

Instead, Visner says, an enterprise should define the outcome it seeks and hire a contractor that has the processes in place to achieve those goals.

Muddling Execution of a SOC

The NRC IG also points out other circumstances that muddles the execution of a functional SOC. Dingbaum, in the audit, says cybersecurity specialists manning the SOC and NRC staffers expressed differing expectations of SOC roles and responsibilities.

For example, the IG report says, some stakeholders expect more detailed analysis from the SOC, and raised concerns about the timeliness of data provided for purposes such as quarterly Federal Information Security Modernization Act reporting. Conversely, the audit reveals, SOC staff raised concerns about data requests and the level of support required by stakeholders who have access to the SOC's network analytic tools. Stakeholders also expect that roles could be better defined to clarify responsibilities, such as who should notify affected users when an incident occurs.

Why does this occur? The IG says NRC created two organizations in 2007 to differentiate computer security oversight from operations, yet failed at the time to differentiate the new organizations' respective roles and responsibilities. "This lack of clarity is reflected in the current contract, which contains generic language regarding support for stakeholder information requests but does not provide detailed guidance on the nature and extent of support required," Dingbaum says.

IG Recommendations

The IG recommends the NRC's executive director for operations:

  • Revise information technology service contract requirements to include SOC-specific performance objectives and define SOC functional requirements;
  • Define in policy SOC functions and support obligations to NRC stakeholders, with emphasis on information reporting and technical support requirements; and
  • Revise the information technology services contract to align with agency policy defining SOC functions and support obligations to NRC stakeholders.

"The IG audit's conclusion was not so much that the SOC does not meet agency needs, but that the agency's current IT support contract does not adequately define required cybersecurity monitoring activities and performance objectives, making it difficult to assess the SOC's performance adequately," NRC spokesman David McIntyre says.

McIntyre says the NRC is preparing to issue a new procurement solicitation in the coming months with improved operational contract requirements and performance metrics for a new IT services support contract.

About the Author

Eric Chabrow

Eric Chabrow

Host & Producer, ISMG Security Report; Executive Editor, GovInfoSecurity & InfoRiskToday

Chabrow hosts and produces the semi-weekly podcast ISMG Security Report and oversees ISMG's GovInfoSecurity and InfoRiskToday. He's a veteran multimedia journalist who has covered information technology, government and business.

Around the Network