SCADASEC – a Security Trust Groups in for the Industry

Posted on
https://unsplash.com/photos/hFj0X0pwan4

SCADASEC is a community created ~2004 to mirror the success of the Internet Backbone’s Security Trust Group (NSP-SEC). SCADASEC focuses on “security discussions, trends, and overall discussions pertaining to critical infrastructure protection (CIP) and SCADA/control systems security.”

Over the years, the information shared, joint action, threat updates, consultation, and collective action have been critical to securing critical industrial infrastructure. Today, SCADASEC is one of many ICT-focused security trust groups (talk to your peers for other examples).  SCADASEC’s +20-year longevity offers a community of wisdom and experience.  

If you are a security/resiliency professional in industrial control systems (ICS), Supervisory Control and Data Acquisition, or related areas, reach out and apply to the SCADASEC community: https://groups.io/g/scadasec/

But wait … what are “security trust groups.”  

What are Security Trust Groups? 

Security trust groups were validating effectiveness by 2004. Security trust groups are TLP: AMBER or TLP: RED communities that come together to focus on a security mission. Their mission would have a purpose:

  • Collective Defence: The trust groups could be working together to defend themselves. Collective defense does work. Peers from different parts of the industry share what works for them in a safe space, knowing the techniques will not leak out to the threat actors.
  • Collective Investigations: Many threat actors hit multiple targets. These threat actors would use malware, APT tools, and other TTPs. Security Trust Groups are often created to investigate the threat actor, help each other push back, and sometimes instigate law enforcement actions.
  • Collective Suppression: Suppressing DDoS botnets was one of the first practical security trust group impacts. NSP-SEC was one of the first security trust groups to pull down Botnet Command and Control (C&C). The teams focused on “takedowns” split off the better focus on Botnet takedowns and kept NSP-SEC focused on ISP Backbone resiliency. 
  • Collective Vulnerability Remediation: “SNMP Protos” was one of the most dangerous security vulnerabilities in the history of the Internet (one single SNMP UDP packet would core dump most devices connected to the Internet). The Forum of Incident Response and Security Teams (FIRST) supervised an extended security trust group to get fixes developed, tested, and deployed. The vulnerability stayed “TLP: RED” inside that trusted group for over nine months. It all fell apart once trust was broken by the US Government started “leaking” the information. The SNMP Protos Security Trust Group then shifted to “Collective Internet Incident Response,” rapidly informing organizations as fast as possible. 
  • Collective Internet Incident Response: One phone call from Merike Kaeo kaeo@merike.com in 2007 to activate a rapid global response to the DDoS attacks against Estonia. Merike knew all about the work of ISP Backbone security group NSP-SEC. One phone call to Barry Greene triggered an alert to the NSP-SEC community. That community then jumped on their networks and joined the battle.

Building a trusted community with a focused collective mission is a theme with security trust groups. The “weave of trust” is built on the confidentiality expectations used with the Traffic Light Protocol (TLP). Breaking trust unravels the community weave, hurts the community, and has consequences for the individual who broke trust.

Here are some further readings on Security Trust Groups and how you can curate your own: