Self-Service Operations Solves Security and Compliance Problems

Security and compliance are different disciplines that share a common foundation of risk and control. They aim to minimize the risk to the company by ensuring that the proper controls are in place.

Self-service has traditionally had a risky reputation because it was seen as a code word for loosening controls. "Here is your ssh key, sudo privileges, copies of scripts... good luck" could be rightfully viewed as reckless.

But things have changed.

Self-Service Operations is a vastly improved approach because it gives Dev and Ops the freedom and flexibility they need while increasing the control and visibility that Security and Compliance need.


Delivering Self-Service and Making Security and Compliance Happy

From the perspective of an engineer trying to get their job done, the benefits of self-service are clear. Self-service reduces the amount of time they have to spend waiting on colleagues to do something for them. In reverse, self-service also cuts down on the amount they are interrupted by colleagues who need something from them.

When you put a Self-Service Operations platform into place, you are inserting a layer of control between your lower-level automation (scripts, tools, APIs) and those who need to use that automation to get things done.


From the perspective of those engineers or analysts trying to get things done, that self-service layer lets them quickly create and share standard operating procedures. The platform's features are there to improve usability and make it easier to collaborate — like knowing about the underlying infrastructure, error handling, or being able to validate/constrain user input.

Now let's look at it from the perspective of the security or compliance team. Those same features that allowed the engineers to create self-service also allow for improved controls. You know who wrote the job, who ran the job, exactly what the job called (tools, scripts, commands, APIs, etc.), where it ran, and what happened.

That is a lot more than what they know from the traditional workflow of someone gets a ticket, goes and does something, and then updates the ticket with a description of what they did.


From either the perspective of the engineer trying to get something done or the security and compliance teams trying to reduce risk, both are getting what they want. Life with Self-Service Operations is better than it was before.


Steps to Getting Security and Compliance Onboard with Self-Service Operations

1. Setup a POC that doesn't cross security boundaries or trigger compliance concerns
Start by setting up self-service for a small set of tasks that are within the same team or teams with similar privileges. For example, pick tasks that are both requested by and performed within your trusted operations team. Perhaps it's a restart or triage procedure that happens regularly.

The self-service will help those teams work quickly and improve their internal collaboration, but it won't cross boundaries that cause security or compliance concerns.

2. Invite your security and compliance colleagues to study the POC
Show off the controls that your Self-Service Operations platform can provide them. Show then the access control capabilities. Show them how you can constrain and validate user input. Show then how you can encrypt keys and passwords. And then, most importantly, explain how you can securely repeat the self-service model throughout the company.

3.Pick an initial use case that fulfills an organizational desire or pain
Draft off of another initiative or solve a long-standing pain point. For example, you can focus on a DevOps initiative that is pushing for Developers to be able to run health checks or restarts in production.

Or you could pick something that has always annoyed your colleagues. I recently saw an insurance company create its first self-service job as a way for L1 support teams to remove a record-level database lock. A bug was causing the lock and it and happened several times a week (each one requiring an escalation to an overworked DBA team), and there was no Dev budget to fix the bug (the offending app was scheduled to be replaced).

In any case, it is often best to keep the first use limited to something(s) that is well known. Allow for your colleagues to see the value, feel good about tackling a known problem, and get comfortable with how Self-Service Operations works.