The worst time to find out your company doesn’t have adequate access controls is when everything is on fire. The worst thing that can happen during an incident is that your development and operations teams are blocked from solving the problem.
That’s why having adequate identity access management (IAM) policies in place – which include both authorization (AuthZ) and authentication (AuthN) – is especially critical when it comes to your incident management tooling.
The difference between authentication and authorization
These two terms sound similar but they are distinct concepts, and your company needs to deal with both to ensure the security of your applications. To avoid confusion, it can be helpful to refer to authorization as “permissions” more clearly distinguishing it from authentication.
Authentication is the first step – without it, the next step of managing permissions is pointless. Authentication involves verifying someone is who they say they are. Think about it as a bouncer at a VIP event checking IDs – they are the first buffer between the outside world and the inside. If your name is on the list and is verified by the ID, then you are allowed in.
During an incident, where part of the challenge is making sure the right people are brought into the situation to remediate the issue, it’s crucial that folks who need to make moves can do so without unnecessary bottlenecks and friction. If a developer has to wait until they hear back from the security team to unblock them, precious time is wasted as the application is down or a customer is affected.
Managing permissions is the next step in the process. Once someone is verified and inside, what are they allowed to do? Are they cooks who should be allowed in the kitchen? Are they patrons who should only be allowed at the tables? Are they live band members and should have access to the green room? Just because someone is accepted into the party it doesn’t mean that it’s appropriate for them to have complete access to every part of the venue.
The same thing is true for applications. People need the appropriate levels of access and permissions within the application to do what they need to do and what they are supposed to do, without the risk of abusing the system. As we all know, there are malicious actors even within companies, so it’s critical for the health of your business that there are guardrails and parameters. Even well-intentioned folks can make mistakes, which can be devastating when dealing with security and customer-sensitive data.
It’s the role of security teams to work together with platform teams to ensure that the appropriate access controls are in place. That way, everything can operate smoothly when an incident occurs, and the issue can be resolved without unnecessary chaos. You don’t want to be in a situation where access is granted off the cuff or where someone should already have access and doesn’t.
Managing access control at scale
Ensuring the right safeguards are in place around who can access which information becomes increasingly challenging as the amount of people and the granularity of access-controlled data increase. This is where SCIM (system for cross-domain identity management) comes in.
SCIM automates the process of creating, updating, and deleting user accounts. This is especially useful in large organizations or those that use many cloud services, as it saves a time and effort that would otherwise be spent manually managing accounts. By using a standardized protocol, SCIM ensures that user information and permissions are consistent across different systems.
This helps reduce errors and ensure that security policies are applied uniformly and instantly when, for example, you are adding a new employee or remove an ex-employee from all systems. This rapid update across systems helps maintain security and operational efficiency.
Considerations for incident management
Whatever incident management solution you choose, you need to ensure that it offers the ability to manage permissions at scale so you can control who accesses incident information and when they access it. Key features include:
- Group permissions support for SSO, SAML, SCIM
- The ability to create and manage private incidents
- RBAC across incident roles, services, teams, components and more
- Ability to manage multiple organizations to ensure guardrails between organizations when needed
Attention to enterprise security concerns varies widely across vendors, so asking for specifics about these critical features is key.