Rethinking Software in the Organizational Hierarchy

At some point in their career, everyone has probably seen one of those operational hierarchy charts that define who reports to whom at an organization. Sometimes just called an org chart, it's a useful tool to let people know who works for them, and who their bosses are. For example, in a typical org chart, the head of a coding group might report to the director of product development, who in turn reports to the vice president of innovation. Who hasn't looked at one of those charts to try and find their personal little block nestled inside somewhere?

There is one thing that almost every organizational chart has in common regardless of the size of the business or other factors. For the most part, all the building blocks on those charts represent humans or groups of humans. We are not at the point where machines are able to oversee humans, so for now, org charts are an exclusively human affair. But does our software also need an organizational hierarchy?

Of course, I am not suggesting that we add software to our company org charts. Nobody wants to have an app for a boss. How would you even ask them for a raise? However, by helping define the responsibilities of our apps and software within a tight hierarchy, and enforcing those policies with least privilege, we can make sure that our apps and software also survive and thrive despite the devastatingly rough threat landscape arrayed against them.

Attacks on Apps, Software Reach an All-Time High

Attackers these days, and the bots and automation-driven software that work for them, are constantly scanning for any slip-up in defenses to exploit. While all software is being targeted, the most damaging attacks are being made against application programming interfaces, or APIs. They are often flexible and unique, and sometimes even created on the fly as needed in the development process.

APIs are certainly flexible, but they are also often way over-permissioned for their functions. Developers tend to give them lots of permissions so that they can, for example, continue to function even as the program they are helping to manage continues to develop and change. But that means that if an attacker compromises them, then they get a lot more than just the rights to access, for example, one chunk of a specific database. They may even capture near-administrator rights to an entire network.

It's no wonder that several security research firms say the overwhelming majority of credential-stealing attacks today are being made against software like APIs. Akamai puts that number at 75% of the total, while Gartner also says that vulnerabilities involving APIs have become the most frequent attack vector. And the most recent Salt Labs report shows attacks against APIs rising by almost 700% compared with last year.

Creating an Org Chart for Software

One of the ways that organizations are fighting back against credential-stealing threats is by enforcing least privilege or even zero trust within their networks. This limits users to just receiving barely enough permissions in order to accomplish their tasks. That access is often further restricted by factors such as time and location. That way, even if a credential-stealing attack is successful, it won't do the attacker much good since they will only have permission to perform limited functions for a brief time.

Least privilege is a good defense, but is normally only applied to human users. We tend to forget that APIs also hold elevated privileges, yet often aren't nearly as supervised. That is one of the reasons why broken access control is now public enemy number one, according to the Open Web Application Security Project (OWASP).

It's easy to say that the solution to this critical problem is to simply apply least privilege to software. But it's a lot harder to implement. First, developers need to be made aware of the dangers. And then, moving forward, APIs and other software should either be officially placed, or at least envisioned, as part of an org chart within the network where it will reside. For example, if an API is supposed to grab real-time flight data as part of a booking application, then there is no reason why it should also be able to connect with payroll or finance systems. On the software org chart, there would be no direct or even dotted lines connecting those systems.

It's probably unrealistic for developers to actually create an org chart showing the thousands or even millions of APIs operating in their organization. But being aware of the danger that they pose, and restricting their permissions to just what they need to do their jobs will go a long way to stopping the rampant credential-stealing attacks that everyone is facing these days. It begins with awareness, and ends with treating APIs and software with the same scrutiny as human users.