The CIA triad (Confidentiality, Integrity, Availability) is a fundamental building block of modern cybersecurity. It highlights three pillars that help to model the security of technology systems. I often find that the availability aspect of the model takes up a trivial amount of headspace for both developers and security engineers.
Now, when I say that the "A" in the CIA triad is often neglected, you probably think I'm talking about firewalls, WAFs, and other tools to protect systems from outside attacks. We usually do a great job with these tools, and are cognizant of attacks on application availability from the dangers of the internet. Instead, what I want to touch on is our ability to readily allow the legitimate users of our systems and applications to use them.
The systems we protect are pretty useless if they're not made available to the people who need to use them. There's a saying often touted about how the only truly secure server is one that's locked away in a cage and never connected to anything. Unfortunately, that doesn't make for a particularly useful server.
A common example of a hindrance to availability is the lengthy onboarding and approval processes that I have frequently seen as a consultant. These approval processes are often lengthy, taking multiple days to get the access I need to do my job. They burn money and frustrate people trying to do their jobs.
Of course I'm not saying that we need to do away with access approval processes, onboarding, data visibility, and other common governance controls. However, I do think there are some steps we can take to make systems and data more easily available for users while still maintaining a reasonable level of security.
Data Classification
How are you supposed to make data available when you don't know what it is? And, for that matter, how are you supposed to protect your data when you don't know what it is?
I can't count the amount of times I've started working somewhere and they inconsistently apply their data classification strategy, aren't familiar or up-to-date with it, aren't monitoring its usage, or don't have a data classification strategy at all.
One of the most important parts of an access strategy is understanding what you're giving users access to and what you're protecting. When we aren't informed about our data, we can't reliability establish controls or policies to protect it. We can't track where sensitive data is or remember how it's protected.
Furthermore, if we as cybersecurity professionals can't stay on top of that, how can we expect possibly expect developers or admins to keep track of it?
Approvers
Access must inevitably be approved by someone. It's important to have approvers well defined and documented for roles and other types of permissions. However, I've unfortunately seen (and been a contributor to) countless cases where it isn't. Cut to me (and colleagues) spending inordinate amounts of time searching for who I need to ask to approve new access.
Further contributing to the problem is often a lack of secondary approvers. The obvious issue with this is that when an approver is sick or on vacation, they'll of course be unavailable to approve the requester's access, leading to delays. It can also become a pain point if they are bogged down with work on a particular day or week, or if they miss an approval email. This issue is probably the one I've seen most frequently, and the most effective way to avoid it is to plan ahead when permissions are first being setup (better late than never, though).
A lack of proper notifications, a lack of understanding of the process from approvers, and marooned permission sets from people that have left an organization are a few other issues.
Remember that a lack of a well thought out approval process always slows down user onboarding or access changes, frustrate users, and hamper productivity.
Well documented permissions
I touched on this with approvers, but another problem that I see is not being able to tell what a role, group, or attribute gives access to.
When we don't know what access something gives, we risk giving people too much permission (or not enough). Least privilege applies not only to how we craft access, but also to how we give it out.
Once again, the best time to document access is during role, group, or attribute creation, but if that never happened make sure to set aside some time to tackle it as part of technical debt. Remember to reevaluate your documentation over time. Out of date documentation can sometimes be more harmful than no documentation at all.
Diving into AWS for a moment, this same problem applies to resource-based policies (if you don't know what those are check out this documentation). As great as they are, poorly understood resource-based policies can lead to a lot of confusion when troubleshooting or deciding what access to give someone.
Priorities
For some systems, the most important aspect of the CIA triad is availability. While the system or application owner may not want the data inside leaking out, it may be a larger hindrance if legitimate users experience delays or difficulty in accessing that data. Sometimes ease of access is the priority and we as security experts have to be aware and understanding of that. We have to do a better job of sympathizing with that priority and comprising in other aspects to meet the priorities of the system or application, when applicable.
Ending Thoughts
Even as someone who regularly implements and evaluates these things, it's easy to forget one or more important aspects of access control such as the availability pillar. Taking a step back and talking to another engineer or user and trying to see from their perspective is a great way to realign ourselves and understand a system in a way we hadn't considered before.