Working with a number of SOCs, our founders learned some lessons that we’ve embodied into the Cydarm platform, to help SOCs do better, faster.
The Cyber SOC or Security Operations Centre is not like other business and IT functions because it is adversarial. And it has to be in response to opponents that use espionage, denial of service, destruction, or exposure of sensitive information to achieve their goals.
This creates an imperative for speed of action, at the same time that it necessitates handling sometimes sensitive information.
The tension between “urgent need to share” and “need to know”
During an incident, the SOC needs to urgently collaborate with and report to various internal and external stakeholders. These include executives, IT, cyber insurers, contracted IR experts, auditors, regulators, a PR firm and so on.
These stakeholders being at different levels of trust creates a challenge.
Faced with the sudden and urgent need to collaborate, organisations realise they are just not set up to manage the tension between “Need to Share” versus “Need to Know”. The risk of oversharing can cause management and legal advisors to try funnelling collaboration through a manual review process, impacting response time.
Large SOCs tell us that even in ordinary times they waste hours manually “Copy and Pasting” to create reports. But during a crisis, having the added burden of working out what to redact by audience or sensitivity can create friction, and risks paralysis.
For example, in Incident Reports to executives, you don’t want to include deeper technical detail or comments that will just confuse or distract them from the big picture.
More critically – consider an Insider Threat situation – sharing notes or actions that betray your Key Hypotheses, or Root Cause or plans for Mitigating Actions creates further risks.
The ABAC difference in approach
Information security (infosec) professionals are quite familiar with the role-based access control (RBAC) model due to the widespread implementation in different information systems. Despite its popularity, there are some drawbacks to this model.
In a large and complex organisation, the use of this access control model has led to role explosion since permissions can only be assigned to user roles, not to objects and actions. In order to meet the different security policy requirements of this large organisation, several user roles must first be defined.
By contrast, Cydarm’s ABAC or Attribute-Based Access Control model provides flexibility in terms of immediate policy creation based on evaluation of attributes. The ability to grant access based on attributes of the system components, instead of basing it on user role, helps an organisation to quickly describe a business rule of any complexity.
ABAC implements authorisation based on the concepts of subjects, objects, and actions. A subject can be a user or a resource that can perform an action in the system. An object refers to any resource on the system that can be accessed by a subject. Objects include API endpoints as well as individual data objects accessed via the API. An action is an operation that a subject attempts to perform on an object. The administrator of the system may set access control policies on objects to determine whether a given user can perform an attempted action.
The ABAC model used by Cydarm allows an organisation to achieve the required level of collaboration while preserving the need-to-know principle.
Complementing this is the concept of “Significance Levels”
Creating incident reports is a major time waster for SOCs – a lot of that is due to manual cutting and pasting data in – but also having to consider what to leave out.
To help SOCs go faster and keep stakeholders focussed and “in their lane”, Cydarm also supports the concept of “Significance Levels”.
This means the Analyst can quickly classify items by Significance or importance such as “Summary of Incident”, “Decision Point” “Major Finding”, “Confirmed Indicator” “Internal Comment” and so on.
At any time, the SOC can generate a detailed Incident Timeline report, and here’s where the above capabilities come together to make life really easy:
- The more Recipient Groups are selected, the wider the required report distribution. So the ABAC model kicks in and auto-redacts inclusions by applying the “Need to Know” principle – only data allowed to be seen by ALL those Recipient Groups is included.
- Conversely if you reduce the number of Recipient Groups to just more senior or privileged staff, then more sensitive data is auto-added back into the report
- At the same time, the SOC staffer can check boxes to decide what “Significance Levels” to include. Therefore whole classes of detail can be left out that might be extraneous or distracting to execs and other stakeholders.
Just like having good brakes on a race car gives you the confidence to hit the corners faster, knowing you have this capability that you can use at a push of a button, allows the response team to go faster, and enable a successful response.