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.
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 threat landscape arrayed against them.
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
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.
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.
Chief Executive Officer, Chairman, and Co-Founder
Click on the link below and download the PDF of this one pager.
DownloadSecure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
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.
Table of contents
Chief Executive Officer, Chairman, and Co-Founder
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.