When startups scale, they can lose some of the charm that attracted early, passionate employees.
The company is moving slower and they’re moving more slowly with it. They used to be able to pop into 1Password and get the credentials they needed for a given app. Now, they need to file a ticket and wait before they can get the access they need.
Access management, in the name of security, starts to limit employees from getting their work done.
Some companies might consider that a worthwhile sacrifice but agility is often traded, perversely, for security theater–the result being a slower, less secure, less engaging company.
The path toward bureaucracy feels inevitable but with the right approach and the right tools, companies can automate approval systems and provide self-service access.
In this article, I'll walk through the stages of evolution as access management systems change over time and explain how companies can provide access management systems that are both more secure and more agile.
Once companies employ more than the founders, they tend to adopt password-sharing services like 1Password or LastPass. With these services, companies can generate strong passwords and store them in a centralized place all employees can access.
Pros:
All a developer in the flow needs to do is turn to 1Password, search the application or system they need to access and copy and paste the password. It’s a pretty seamless experience from needing access to finding credentials to inputting credentials and returning to flow.
CareClinic, for example, a healthcare startup, uses 1Password to manage a growing team. In its customer story with 1Password, CareClinic explains that they “constantly have new engineers joining [their] company as [they] go through a period of strong growth” and 1Password emphasizes that they “take care of their password management so they can continue to grow.”
The focus, as with my startups using password management tools, is to achieve some level of access security without interrupting growth.
Cons:
Password sharing quickly becomes insecure and unwieldy at scale. Eventually, companies will want to guard access, to put it behind at least one layer of approval. The philosophy changes from anarchy to maturity, from default granting access to default denying access.
At this stage, most forms of access management share some basic similarities: Users file a request via ticket, and tickets are routed to a central team that grants approval one ticket at a time.
Pros:
In this stage, the flow of access shifts from open to bottlenecked. A bottleneck creates space to monitor and inspect requests. If there’s a queue of tickets, IT teams can scrutinize who is requesting access, what they’re requesting access to, and why.
On an immediate level, this means you can identify some basic patterns – all developers, for example, might eventually request access to a given app, so you could grant them access on day one. But you can also start auditing who asked for access to a particular service and who granted that access if and when a breach occurs.
Cons:
… while a bottleneck enables scrutiny, a bottleneck is also, well, a bottleneck. If employees are hired in batches–say, once a month at the beginning of the month–then IT teams can end up overwhelmed with access requests.
Depending on the quality and size of the IT team, as well as their availability and busyness, approval can be impressively fast or disappointingly slow. And while a bottleneck enables scrutiny, a bottleneck is also, well, a bottleneck. If employees are hired in batches–say, once a month at the beginning of the month–then IT teams can end up overwhelmed with access requests.
Ticket-based access control is especially problematic for companies implementing DevOps systems because this system blocks development work with IT approval and creates a bottleneck between access requests and access approval.
By the third stage, companies have effectively traded speed for security theater, slowing themselves down for the sake of feeling more secure. It’s one reason why even major, well-funded companies continue to suffer breaches.
After companies have suffered one or more breaches, or been scared by breaches in adjacent companies, they often add layers and layers of scrutiny to their approval processes. Approval takes longer to get and access becomes a more likely delay. The tradeoff, theoretically, is greater security for the company. But the theory doesn’t always bear out.
Pros:
The primary advantage of bureaucracy is the primary advantage of maturity: You’re still more secure than if you were password sharing. Beyond that, however, the advantages are scarce.
One advantage might be the feeling of more security, the intuitive sense that if it takes so long to get and grant access, then scrutiny must be present. A breach feels less likely simply because it takes so long for employees to be granted access. It’s a tempting fallacy.
Cons:
Similarly, the same disadvantages from the second stage apply to the third stage but now the disadvantages are more severe. If employees complained about delays before, they’re almost certainly complaining about them now. Instead of disrupted hours or days, there might be disrupted weeks.
And while the growth of the company might have entailed a growth in the IT team, the growth of IT likely isn’t parallel to the growth of executives, directors, and other leaders–all of whom might have the real, final say in access approval. Just as in the last stage, access depends on a chain of approvers and the communication delays between them–but now, there are many more links in the chain.
As companies grow and become bigger targets, attacks tend to become more likely, meaning that your company’s ability to react to an attack is as important as your ability to prevent an attack.
Eventually, there’s a drop in speed that starts to, ironically, affect security. As companies grow and become bigger targets, attacks tend to become more likely, meaning that your company’s ability to react to an attack is as important as your ability to prevent an attack.
Research from SlashData, illustrates this point, with their study showing that only one-third of organizations can resolve security exploits within one day. When companies are large, attacks are inevitable and exploits likely, so the ability to react becomes as important as the ability to prevent.
The most devastating breaches are also rarely the result of one brilliant attack but are instead the result of attackers discovering a chink in the armor and moving laterally across vulnerabilities. A bureaucratic access management system then has the appearance of strength belied by a brittle reality. Once attackers break down your defenses, speed is the best way to reduce damage, and bureaucracy hampers speed.
By the third stage, companies have effectively traded speed for security theater, slowing themselves down for the sake of feeling more secure. It’s one reason why even major, well-funded companies continue to suffer breaches.
No founder dreams of bureaucracy and yet it seems almost inevitable. We can see this every day as developers help build a startup into a major company and then leave to work at another startup. There are many reasons for these decisions but among them are the pace and the level of impact one is allowed to have with minimal permission.
The central fallacy is that the upside of bureaucracy seems obvious, whereas the downsides are unseen or discounted. As Paul Graham put it, “No one who introduces measures that make a company more bureaucratic ever seems to realize they're doing it. All they see is the upside.”
Bureaucracy is never added in one fell swoop. Instead, layers of rules are added in one by one and for each rule, a cost-benefit analysis is made that tends to emphasize the benefits–in this case, added security–and discounts, if noticed at all, the costs–in this case, decreased speed as well as the opportunity cost of not considering other paths.
As always, it’s worth looking at incentives. Breaches have never been a good thing for companies, of course. There is the sheer monetary cost as well as the reputation damage, but as execs start finding themselves hauled in front of Congress (see Uber), the incentive to add layers of security only gets stronger.
The trouble is that if companies don’t think carefully about what actually creates security, they can default to bureaucracy and security theater. In their efforts to become more secure, companies can incur big speed and convenience costs for the sake of marginal (at best) security improvements.
The end result is a behemoth of a company that few developers want to work for, one that tricks itself into feeling secure but then can’t react quickly when a breach happens. Companies get taller and taller, only to make their inevitable fall harder.
The goal [of self-service access management] isn’t to dismantle the rules and return to anarchy, but to introduce automation that eliminates the bottleneck at the center of the bureaucratic machine.
Paul Graham offers a discomforting path out of this fate: “There is a mechanism for ensuring that the median company isn't too bureaucratic: startups. Companies never become less bureaucratic, but they do get killed by startups that haven't become bureaucratic yet, which amounts to the same thing.” This solution isn’t particularly thrilling when you’re trying to grow your business.
Thankfully, there’s another path: self-service access management. The idea feels like a contradiction in terms but it’s another step in the long-running trend to make more resources self-service. The goal isn’t to dismantle the rules and return to anarchy, but to introduce automation that eliminates the bottleneck at the center of the bureaucratic machine.
Self-service access systems automatically route approvals based on risk–either automatically approving obvious and otherwise pre-approved requests or routing access requests to IT teams and relevant managers.
The approval workload is then distributed, ensuring no one team is overloaded and that every request is filed to the person who’s best able to scrutinize it.
There’s a shift, then, from the IT team pushing and pulling the actual access approval levers, toward the IT team managing and monitoring a largely automated access approval system. IT designs and observes the approval workflow rather than doing all the manual work themselves, enabling them to spend less time on obvious approvals and more time on riskier requests.
Like a platform team, IT works like an internal vendor, building and providing an access approval product that they can iterate on over time. A self-service approval access system works faster than a bureaucratic system and achieves greater security. Companies can use self-service access to reduce the default scope of access that everyone has and make it harder for attackers to make lateral moves.
And, with a bedrock of automation to support them, development and security teams can move faster if an attacker does achieve a breach–preventing the attacker from causing as much damage as they would have otherwise been able to.
Self-service access management takes scalability as a first principle. The traditional three stages feel inevitable because scalability is not usually taken into account. Instead, companies add bureaucracy layer by layer and make the resulting sacrifices each time, all without considering that a separate path might be possible.
