Q&A with Josh Tessaro, Thirdera

Josh Tessaro is practice manager at Thindera. We caught up with him to talk SecOps: understanding the benefits, overcoming difficulties and its place in cyber security.

What is SecOps?

SecOps (or Security Operations) includes all the people, processes and technology involved in running a business in an efficient and secure way. This consists of planning, design, implementation, preventative maintenance, monitoring and response.

How are enterprise CIOs addressing SecOps today?

CIOs frequently take a tool-first approach to security, often-times to the detriment of the other two key dimensions: People and Process.

As organizations become more technology dependent and more attack vectors become available, many are purchasing and implementing a new tool for each threat. The resulting technology stack contains firewalls, endpoint detection and response solutions (EDR), Data Loss Prevention solutions (DLP), Network Access Control (NAC), and on and on.

Members of the infrastructure technology team are assigned to design and maintain these security solutions on top of existing responsibilities and a group of security support personnel, or a Security Operations Center (SOC) is assigned to triage issues that come in from the security tools.

Over time, as more security gaps are found, additional tools are purchased and implemented, and more people are added to the SOC as more bandwidth is required to monitor and respond to all the security tools.

What problems do they run into with this approach?

There are so many niche security areas that need specialized solutions that many mid-to-large size companies have 15-40 tools in their main security stack and as many as 80 when you consider the entire technology landscape.

Automated data aggregation and enrichment is critical to quickly sort the real threats from the noise and correctly address the most critical items first. When an issue is reported to the SOC, a SOC analyst may have to log into 6-10 different systems to collect information and cross reference data just to determine if the alert is real (malicious) or a false-positive. This swivel-chair exercise adds significant time to the analysis process and greatly hampers a team’s response time and overall throughput.

Additionally, the larger variety of alerts requires a larger variety of response plans (or playbooks), further adding to the complexity of the program.

The lack of a centralized location (a “Control Tower”) to manage the aggregation and enrichment of alerts as well as organize the expanded team of people and increased complexity of processes cripples the potential of many modern security teams.

What are some best practices for solving these problems?

Pay just as much attention to investments in process as you do to technology. The more tech we have the more we need to plan for ways to aggregate all that data and make it intelligent. A Security Incident Event Management (SIEM) solution is critical to aggregate all the data from the disparate sources.

But aggregation is not enough, we must filter through the thousands of alerts and find the threats that matter.  It is critical to build a security “Control Tower” that gives equal consideration to the processes and the technology, consolidating events from your SIEM into a single system of action, that enables the people to address security threats quickly and efficiently.

What advice do you have for CIOs who struggle with SecOps?

Keep the end goal in mind.

The ultimate objective of a security program is to prevent as many threats as possible and then define a process to enable your security teams to take quick and correct action. This means that enabling and empowering the people with efficient technology that aggregates and enriches data and well-defined processes that provide guidance and remove confusion should be the goal.

What’s the relationship between SecOps and DevSecOps?

It used to be that SecOps was the practice of securing an environment consisting of industry standard, purchased hardware and software with systems designed for that purpose. However, this is changing, and more and more companies in all industries have large development teams building applications for their business. This means that a large security concern is the applications you are developing in house, and this risk must be recognized and addressed as part of the development lifecycle.