[BreachExchange] Three Ways of Looking at Security Operations

[Destry Winant]

https://www.securityweek.com/three-ways-looking-security-operations

The term “security operations” is often interpreted to be synonymous
with a security operations center (SOC). In fact, a web search on
security operations results mostly in links to SOC content. But that’s
a narrow view. How you view security operations will make a difference
in how fast your organization can deliver software and mitigate breach
damage. A bigger-picture view that includes IT operations is necessary
to address the agile threat environment that exists today.

The divide between security and operations

Let’s begin with a simple acknowledgement that conflict exists between
most IT security and operations teams. Whether it simmers beneath the
surface of thinly-veiled polite tolerance or involves the flipping of
furniture, or something in-between, the difference in priorities for
each team is bound to create tension. While IT security ultimately is
concerned with the confidentiality, integrity and availability of IT
services and information, IT operations focuses more on performance,
efficiency and availability.

We might be tempted to find common ground over availability, but even
this identical term is viewed through different lenses. The security
perspective focuses on countering intentional sabotage, while
operations seeks to mitigate accidental service disruption. The result
of this divide is overlapping organizations and tools in many
organizations, with conflict arising over the boundaries between them.

The three approaches to security operations

While the divide is almost universal, security must have an avenue to
affect change in the infrastructure and applications of the
organization in order to remediate vulnerabilities and respond to
attacks. The challenge is a blurring of lines between the authority,
responsibility and accountability for implementing change.

The approach taken by many organizations can be grossly organized into
three categories.

1. Security administration – The everyday activities performed by IT
security in support of its responsibilities. These can include the
implementation and maintenance of policies and controls, threat
analysis, compliance assessments, and security monitoring and incident
investigation from a SOC or similar structure. These operational
activities are clearly in the security domain, and while they will
intersect with operations (for example, enabling log collection on a
server) there is usually less grey area on who is the authority.

2. Secure ops frenemies – The necessary collaboration that must occur
between IT security and operations. Every organization handles this a
little differently, and ideally, there is documentation that clearly
defines who provides management of credentials and access, who changes
rules on the firewalls, and who patches servers to eliminate a
vulnerability, as examples. Where things get contentious is when
timeframe and priorities differ. If a security organization detects
the exfiltration of data from a database, they often must rely on
operations to shut it down. Operations may be reluctant to do so if
that database supports a mission-critical service for the business.

3. DevSecOps – As more enterprises adopt DevOps practices, there is a
greater integration of developers and operations teams in planning,
building, testing, deploying and maintaining code in production to
accelerate release velocity. As bottlenecks or “constraints” are
removed, security is gaining the spotlight, and often not in a good
way. Security testing, when performed at the end of a development
cycle, can identify code that is insecure, but is also then costly to
change. So there is a movement to “shift left” security testing by
including it earlier in the cycle, which is helpful for developers,
but operations/security integration continues to be unaddressed. It
remains to be seen if DevOps, which is developer focused, shifts its
center of gravity more towards operations, and in doing so, helps to
bridge security and operations.

Which approach is correct?

The correct answer, of course, is the one that supports the business
need for speed of software delivery, and the confidentiality,
integrity and availability of services and data. That means that all
three approaches must be covered, but they need improvement. The
greatest potential for improvement comes from the interaction between
security and operations teams.

One of the keys to the success of DevOps is the automation of handoffs
between steps in the toolchain that allows for the continuous delivery
of code. That kind of orchestration is sorely needed to bridge the
divide between security and operations tools. The political and
budgetary walls that exist between these organizations are unlikely to
be dissolved, and there is no good reason to force full integration or
cross-use of all tools. But connections and automation made for
specific activities can address the most pressing concerns.

For example, your SIEM platform may be able to initiate tickets in a
service desk tool. Automated processes in the service desk can then be
triggered to perform a remediation action that IT operations has
approved. This reduces the workload on both the security and
operations teams and can enable a feedback loop for continuous
improvement that will also support mutual trust.

That trust, leading to cooperation, is sorely needed in a time when
security threats are innovating faster than the enterprise can keep
pace. The greater the partnership between security and operations, the
better the chance your organization can deliver software faster and
minimize breach damage.