Are we measuring Blue and Red right?

in

In security many people see solutions of problem as a whole, all or nothing. Many times even worst they see the security as a hindrance to the delivery of a project or even day to day actions. Even internally in some organization with the size and level of maturity of having both a Red and Blue team you have rivalry between both. In this blog post I would like to cover my idea on how we should think when measuring the performance of the internals sub teams inside of security. Some of this ideas can be even expanded later to how the team can interact with the DevOps, Support, Sales, Finance and other teams in the organization if there is a possibility to unify the metrics to provide a series or high level or single goal for the organization as a whole.

I have been blessed by having friends and customers who run both good teams or have learned and adapted to become one, pushing for change in their organizations. I have learned a lot from all of them as well from my own experiences that no matter what type of work we do or organization we are part of we will behave and adapt based on how we are measured and rewarded in the organization. When it comes to Blue and Red teams we have to take this in to account so as to not cripple the team from a management perspective by setting and measuring the wrong goals on each. Some typical ways we see this are:

Pushing Competition and Rivalry

I have seen in some orgs where blue and red do not share info it is an ever constant competition of red finding flaws and blue blocking them and trying to fix the previous ones.

Bad Red Metrics:

  • Bypass of controls is success and the oposite a failure of their tasks.
  • Only required to provide a report on the actions taken to achieve successful compromise.

Bad Blue Metrics

  • Blocking a red team attack is success and opsite a failure
  • No detection of any or all red team activities is considered a failure.

Bad metrics are those where reassure the success of one team based on the failure of another. These leads to both teams not sharing information of techniques, processes and stagnate growth of the technical skills of both team. Even worst having both teams at odds with each other breaks the purpose of having them wish is to improve the security through the collective work of both of them.

Good Red Metrics:

  • Study and analyze new attack techniques and vulnerabilities as they surface using the researched information current activities and also providing knowledge transfer on how they are executed, impact and IOCs of each to the blue team and general IT staff on a regular basis..
  • In case of security control bypass work with blue team on how the control was compromised, mitigations and how to monitor for the techniques used.
  • Work with blue team on the testing of the monitoring and detection controls and incident response procedures.
  • Work with blue in the establishing of guidelines and updating of existing ones.

Good Blue Metrics:

  • Work with red team in developing detection for techniques used that provided risk or compromise to infrastructure.
  • Work with blue and IT teams in configuration improvements to mitigate new and existing risks based on red team research.
  • Update techniques for the hunting of possible intruders on current infrastructure. Detection of an actual breach would collect after handling of such the techniques, procedures and tools used so as to share with the read team to be included in the regular testing of exiting security controls.

By changing the metrics we now create a self maintaining loop where read team is forced to expand and learn new techniques to compromise the security of the environment and works together with blue team in maintaining a high level of situational awareness of the IT environment. Blue team is pushed to hunt for possible compromises and by the interaction with read tunes and adapts existing control to emerging threats.

Bad use of Resources

One common mistake in my opinion that I see quiete a lot is where the Blue/Red have IT maintenance roles that removes focus from the detection, mitigation and control of the ever changing security landscape. Common tasks I have see have been that Blue is responsible for:

  • Patch Management
  • Software deployment
  • Antivirus Update
  • Firewall administration
  • Group Policy creation and administration

This tasks take valuable skilled resources from other tasks that they can be executing to provide greater value to the overall security posture of the environment. They should aid in the testing of some of those tasks by performing automated authenticated vulnerability assessment by checking for missing patches or badly configured solutions but not be the ones in charge of the deployment of them but focus on assuming beach finding possible compromises inside the network by always be hunting for it.

Conclusion

Each organization is unique in its number of resources and skill sets but all should strive to set the proper metrics that will push each team to work together, share information and improve as a result their overall proficiency and skills as a base. There is also more to this like choosing the people with the right soft skills and egos that will break the dynamic by bad communication or lack of it.