In new security organizations, security team members often tackle tasks “ad-hoc” in response to an immediate need or a fire that needs putting out. But eventually, these security tasks evolve into repeatable processes. As your team scales, security processes provide clarity to junior team members and help leadership measure effectiveness.

Creating well-designed security processes is a challenge in both small and large teams. Small teams are often looking to just build out a dedicated security capability, whereas large teams are typically burdened by complexity in IT, legacy tools and systems, and organizational structures. (BTW, We have a for teams of all sizes on creating more effective security processes)

Let’s talk about some of these challenges and how they can be addressed.

1. Lack of Strategic Planning When Prioritizing or Designing Processes

Signal
Your security team is constantly bottlenecked or worse: fails to respond effectively to intrusions because their time is being spent elsewhere.

Example
A security team makes the decision to build an internal threat intelligence capability when the biggest threat to the business is phishing (and there is no process for reporting, investigating, and responding to phishing attempts).

Solution
Deciding which processes to implement first can be hard.  For organizations that do not have strategic security skills internally, consider contracting a security architect or part-time CSO to help plan a security roadmap.

2. Implementing the Wrong Processes and Tools

Signal
Your processes (and tools) slow down instead of accelerating productivity, or create friction between the security team and the operation of the business.

Example
To improve code quality, a small company decides to implement a security code review process - but this process requires a security team member to perform a tedious, manual review of any code or architecture changes before they are released.  This creates tension between the product and security teams, making them resistant to collaboration in the future.

Solution
Teams should design security processes thoughtfully according to risk. Where possible, security orchestration and automation should be used to reduce the burden on teams and minimize impact on business functions.  In addition, by delegating certain security tasks to teams outside of security (through training and providing process guidelines), you can scale the security work needed to protect the business.

3. Processes Don’t Scale with Information Overload

Signal
Your processes and tools work well at small scale, but get unwieldy fast when the scope grows, especially with respect to security monitoring.

Example
The average enterprise in North America deals with 10,000 security alerts on any given day. This number can be as high as 150,000 in the noisiest networks. Perhaps you implemented an alert triage policy (must triage all high severity alerts within 30 minutes) when you only were receiving 50 such alerts per day, but now your organization deals with thousands. This means your security team is now spending a great part of their day in an event console instead of in other tasks that need attention.

Solution
When it comes to security monitoring processes and tools, constantly evaluate whether or not these meet the scale of the organization the security team is protecting.

4. Stale Processes That Were Once Efficient Are Now Onerous

Signal
Your team used to spend X minutes or hours a week doing Y, but now they can’t get to crucial security roadmap items because their time is monopolized by lower priority tasks.

Example
Whenever suspicious malware C2 (command and control) channels are  identified, the security team manually blackholes the DNS on the server by logging in and inputting the domain blocks by hand. This works fine when you see this happen a few times a day or less; when you are dealing with hundreds of new potential infections it becomes a huge headache.

Solution
Processes have a life span. If you aren’t continually evaluating and improving your processes, something that worked well for you a few months ago could become a major incident response bottleneck. Measure where your team spends their time, how fast you can respond to threats, and refine processes and add automation accordingly.

5. Your Team is Overwhelmed by Increasing Complexity

Signal
You started off with a homogenous environment and a few tools to protect them.  With growth and acquisition, your company’s environment has exploded, and your team now has tens or hundreds (!) of security tools - - and it’s hard to measure which ones are really providing value vs legacy tools that are no longer needed.

Example
You had a hardening process that worked well when there was one type of web application to protect.  But now that there are hundreds of apps across tens of organizations with different architectures and cloud platforms, you are using many types of tools (several web application firewalls, host intrusion detection vendors, and more) -- and it’s hard to coordinate changes like software and signature updates across them all.

Solution
A security orchestration platform can provide a great way to automate the management across a lot of these tools, and implementing some kind of orchestration early on is a big win as your team grows.

6. Poorly Formed (or non-existent) Incident Response Process

Signal
When a potential breach is detected, your team finds themselves scrambling to identify the right players to investigate and respond to the incident. You end up not having the right people involved, or pulling in too many people (distracting them from other tasks). Worse, you debate about exactly what needs to be done (from forensics to containment tasks to notifications) while the clock ticks with an attacker inside the network.

Solution
Prepare an incident response plan ahead of a major incident. There are many great resources on implementing an incident response plan, but the art is designing one that is appropriate for your organization at its current scale level. When your org is small, consider a plan to bring in specialized resources as needed, quickly (e.g. having a relationship with an incident response firm ‘on retainer’ you can call).

In Conclusion

When it comes to implementing processes, work from the top down: measure where there are bottlenecks and gaps in efficiency and quality, and identify the ‘right’ amount of process to apply and the resources you need to do it.

Be proactive not just about implementing processes, but also updating them. As companies grow, it may be hard to rip out legacy workflows and tools for new ones.