The Natural Tension that Exists in the World of API Security
There are several areas of tension in the API Security world. Exposing data and processes needs to be balanced with permission and credentials. The speed of development might be challenged with consistent implementation and standards.
Companies around the world are more excited than ever about developing and exposing APIs to jump start digital transformation for their enterprise. But guess who is equally as excited about the rapid development of APIs – hackers! As enterprises continue to develop and expose APIs to spur digital transformation, APIs have become increasingly popular targets of hackers.
Hackers will continue to try to take advantage of system vulnerabilities, which is why enterprises should ensure that API security is a top priority. For your enterprise’s API security to be effective, it is important to plan for who has to be involved and what responsibilities each party plays.
The three principal entities that lead to top-notch API security
1. Information Security Group
2. API Developers
3. Enterprise Architects
The relationships between the three entities should be defined by the CIO in most cases. The primary benefit of having clearly assigned and defined roles and having players who understand their responsibilities is that cohesive relationships can be developed, and these relationships will ensure the elements for a comprehensive API security environment are in place. The relationships between the three entities should be defined by the CIO in most cases. The primary benefit of having clearly assigned and defined roles and having players who understand their responsibilities is building cohesive relationships and these relationships will ensure the elements for a comprehensive API security environment are in place.
Typically, API developers will report to the CTO, the InfoSec group will report to the CISO, and enterprise architects are likely to report to either the CIO or CTO.
If any of the roles are absent or the players fail to understand or properly execute their duties, there are likely to be gaps in your API security.
Roles and Responsibilities of the Information Security Group
The information security team is tasked with securing and protecting the enterprise’s data and systems. Its objectives, policies and processes center on locking down the system and protecting valuable data.
Roles and Responsibilities of API Developers in API Security
There tends to be a natural tension between API developers and information security teams because their goals and processes for handling data exist on opposite ends of the spectrum. API developers are focused on exposing data through APIs for reuse and utilizing existing APIs. The developers leverage enterprise data via API to produce digital value.
There is also usually a significant role to play for API developers within the areas of API governance and security.
Roles and Responsibilities of Enterprise Architects in API Security
Enterprise architects bridge the gap between the information security team and API Developers. They facilitate communication between both groups to gather sufficient information and insight to create API specifications and rules for governance.
Architects have to determine how API security fits into the overall security protocols of the enterprise and translate the requirements into the appropriate API architecture, ensuring that it is established, secure, but exposed. Additional responsibilities for Enterprise Architects include updating and modernizing APIs, and developing API security rules as the enterprise matures.
The Risk of not Defining API Security Roles and Responsibilities
An enterprise without clearly defined roles and ownership over APIs will lead to gaps in its API security management. This is because API developers, who are focused on functionality and agility when it comes to APIs, will attempt to take on security tasks. Lacking the proper expertise, guesswork becomes a standard part of the enterprise’s API security management, resulting in inconsistent management and insufficient security.
In the absence of enterprise architects, there can be a natural conflict between information security and API development teams just by the very definition of the roles each entity plays in the grand scheme of API development.
The two teams have very different, contrasting objectives: information security protects data, while API developers expose data. Additionally, information security personnel tend to lack information that could be shared from an enterprise architect that would lead to the ability to adequately protect APIs. Conversely, on the development side, security has not yet become a top priority for API development in many enterprises. Without enterprise architecture, there is a lack of unified communication and effective collaboration between the two parties.
This can have a cascading negative impact, resulting in inadequately designed APIs, a lack of API ownership, and an increase in the rework and maintenance costs needed to try to fix gaps in APIs. Without the proper definition of these roles, this ultimately leads to developing APIs that could be prone to attack by hackers.
For optimal API security within an enterprise, all three entities should be fulfilling their clearly defined roles and responsibilities. The absence of any one party, mainly the information security team or enterprise architects (API developers are always naturally necessary for developing APIs), results in the other party or parties assuming responsibilities for which they are ill-equipped to execute. If one or more roles are not present, organizations must take a serious look at either filling roles or training a team to fulfill all of these vital roles in API development.
ADOPTION & EXPANSION
+ Number of APIs
+ Business coverage
+ Number of contracted apps
+ API usage
+ API reuse
EFFICIENCY & COST SAVINGS
+ Number of APIs in each SDLC stage
+ Time spent in each SDLC stage
+ Cost and time to build an API
+ App development velocity
+ Number of launches per year
+ Number of defects
SECURITY & VULNERABILITIES
Time since the last version was published
Number of throttling issues
+ Time to onboard
+ Number of deployments
+ Number of incidents
+ Percentage of customers impacted. per incident
+ Time to resolve incidents