Rethinking Software in the Organizational Hierarchy

A version of this article appeared in Dark Reading. It has been updated and syndicated here.

‍

Everyone at some point in their career has probably seen one of those operational reporting or hierarchy charts that define who reports to who 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. And then the lines of authority continue up and down the company structure. Who hasn’t looked at one of those charts to try and find their personal little block nestled inside somewhere?

It's little wonder that humans are so fascinated by hierarchy and structure. It’s what has historically kept us alive as a species for so long, even back in ancient times when we faced a very dangerous world. We were never the strongest or the fastest creatures, but we worked well together in teams, with everyone knowing their place and their responsibility in keeping our family, tribe or group together, alive and thriving. The modern org chart is actually an extension of those times and that ancient success.

But 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 of 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? But the threat landscape that our applications and programs are confronting these days is not unlike the dangerous environment our ancient human relatives faced long ago. 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 and Software Reach an All-Time High

To understand the need for creating better organizational hierarchies for software, it’s important to first understand the threat landscape. Attackers these days, and the bots and automation-driven software that works for them, are constantly scanning for any slip-up in defenses to exploit. And while phishing and other attacks against humans are still being launched, the most skilled hackers have shifted the majority of their efforts over to attacking software.

And while all software is being targeted, the most successful attacks are being made against application programming interfaces, or APIs. Those unassuming APIs are tiny pieces of software used by developers to perform a variety of small but important tasks for their apps and programs. 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 job or 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, and often aren’t nearly as regulated. 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), which tracks cyberattack patterns. 

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 computer 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.
‍

Do you want to elevate your development team? Navigate API security issues and more with our agile learning platform and developer-first security tools.