Rethink 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 in an organization. Sometimes simply called an org chart, it’s a useful tool for letting people know who works for them and who their bosses are. For example, in a typical organization chart, the leader 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 these paintings to try to find their personal little pad tucked away somewhere inside?
There is one thing that almost all org charts have in common, regardless of company size or other factors. For the most part, all of the building blocks in these cards represent humans or groups of humans. We’re not at the point where machines are able to oversee humans, so for now, flowcharts are a purely human affair. But does our software also need an organizational hierarchy?
Of course, I’m not suggesting that we add software to our company’s flowcharts. Nobody wants to have an app for a boss. How could you even ask them for a raise? However, by helping to define responsibilities for our applications and software within a tight hierarchy and enforcing these policies with least privilege, we can ensure that our applications and software also survive and thrive despite the devastating threat landscape that oppose them.
Attacks against applications and software reach an all-time high
Today’s attackers, and the bots and automated software that work for them, are constantly looking for any errors in the defenses to exploit. While all software is targeted, the most damaging attacks are 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 over-authorized for their functions. Developers tend to grant them lots of permissions so that they can, for example, continue to operate even if the program they are helping to manage continues to grow and change. But that means that if an attacker compromises them, they get much more than access rights to, say, a piece of a specific database. They can even capture quasi-administrator rights to an entire network.
It’s no wonder that several security research firms claim that the overwhelming majority of credential theft attacks today are against software such as APIs. Akamai puts that number at 75% of the total, while Gartner also says vulnerabilities involving APIs have become the most common attack vector. And the latest report from Salt Labs shows that attacks against APIs have increased by almost 700% compared to last year.
Creation of a flowchart for the software
One of the ways enterprises combat credential theft threats is by enforcing least privilege or even zero trust within their networks. This limits users to barely being given enough permissions to complete their tasks. This access is often further restricted by factors such as time and location. This way, even if a credential theft attack succeeds, it won’t do the attacker much good because they will only be allowed to perform limited functions for a short 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, but often aren’t as supervised. This is one of the reasons why faulty 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 simply to apply least privilege to software. But it is much more difficult to set up. First, developers need to be aware of the dangers. And then, in the future, APIs and other software should be formally placed, or at least considered, as part of a flowchart within the network where they will reside. For example, if an API is supposed to retrieve real-time flight data as part of a reservation application, there’s no reason it should also connect to payroll or finance systems. On the software flowchart, there would be no straight or even dotted lines connecting these systems.
It’s probably unrealistic for developers to create a flowchart showing the thousands or even millions of APIs operating in their organization. But being aware of the danger they pose and limiting their permissions to what they need to do their jobs will go a long way to stopping the widespread credential theft attacks that everyone is facing these days. It starts with awareness and ends with treating APIs and software with the same scrutiny as human users.