Securing applications it the API-first era can be an uphill battle. As development accelerates, accountability becomes unclear, and getting controls to operate becomes a challenge in itself. It’s time that we rethink our application security strategies to reflect new priorities, principles and processes in the API-first era. Securing tomorrow’s applications begins with assessing the business risks today.
The trends and risks shaping today’s applications
As the world continues to become more and more interconnected via devices — and the APIs that connect them — individuals are growing accustomed to the frictionless experience that they provide. While this frictionless reality is doubtlessly more user-friendly, i.e., faster and more convenient, it also requires a trade-off. This convenience demands openness, and openness is a risk when it comes to cybersecurity.
According to Sidney Gottesman, Mastercard’s SVP for Security Innovation, the above situation leads to one of the biggest trends shaping the security posture for today’s applications: A crisis of trust between individuals and the applications they use.
A second major trend is that of the supply chain. Simply handling your own risks isn’t enough, as attacks increasingly penetrate internal systems via 3rd party, vendor-supplied components. In digital products and even connected hardware products, supply chains are now composed of different services bundled together in the final product through APIs, creating a new type of integration risk rooted in the supply chain.
If the recent Colonial Pipeline and JBS attacks indicate anything, it’s that another major trend is the abundance of malicious actors, both at the individual and state level. Businesses must now assume that sooner, rather than later, they will be attacked and must be prepared.
Abundance of data can not be ignored. Enterprises are storing, managing, and enabling access to so much data, making the application layer (and APIs) more attractive to attackers. Increasing regulations aimed at improving the security postures of both public and private enterprises also get a special spot in the landscape of security trends.
Application security isn’t what it used to be
80% of enterprises currently allow external access to data and functionality via APIs, according to a recent industry survey published by Imvision, looking into the current state of API use and adoption among leading enterprises. The results are in line with other research on the topic and conclude that enterprises are much more open than they used to be just a few years back – and growing.
But this means that application security has moved beyond its “doorman” status of asking “who’s allowed in?” Nowadays, application security should assume that users are already inside the application and focus on asking, “what do we allow them to do?”, “what’s the expected usage?” and “how do we stop undesirable behavior?”.
According to Rob Cuddy, the Global Application Security Evangelist at HCL, the fundamental shift enterprises must make in their approach to application security is that securing the application perimeter from external penetration simply doesn’t make sense in the era of APIs.
Building layers of security around the application won’t work when the application is exposed via APIs. Instead, a new inside-out approach is required. This new approach assumes application penetration in service of the user, but puts protective mechanisms in place in case that the actor is malicious.
Learn more on how security professionals are rethinking application security
If you ask developers, they’d tell you that security was there all along, but now it’s become critical. However, it’s not an issue of adding new tools or automations, but rather a matter of making a fundamental shift in people, processes, and culture.
In the race for superfast agile deliveries, many enterprises are adopting a DevSecOps approach that mandates the integration of security practices within the development lifecycle. But while many are talking about doing it, only about half are actually doing something about it – meaning, actually having a full lifecycle API security in place.
Managing security among disparate teams is no easy task
At Allegiant Airlines, Chief Information Security Officer Rob Hornbuckle is leading an interesting initiative to improve awareness, visibility, and collaboration across teams and the development lifecycle.
To develop and maintain their customer-facing applications, they have 10 persistent development teams at any given time. However, orchestrating security among disparate teams is no walk in the park. It requires substantial visibility and a culture shift that encourages initiative and responsibility-taking.
To keep security at the forefront, they established a security champion program that puts two people on every team with the responsibility for ensuring certain security standards during development. These champions help the rest of the team drive knowledge and communication throughout the entire system.
This program empowers visibility into application security at the organizational level via monthly meetings that focus on everything that’s happening with security within the different application programming groups. These meetings enable the organization to provide metrics regarding the overall security health achieved by different teams overtime to help gain buy-in from senior executives and board members.
Visibility, or: “Being able to identify what needs to be fixed first”
With many enterprises using dozens, if not hundreds or more, different security tools addressing different systems, CISOs are challenged to understand what is of critical importance, so they can effectively prioritize vulnerabilities to mitigate risk.
But just because a server is unpatched doesn’t necessarily mean that it poses a true business risk. What’s required is not only visibility into vulnerabilities, but rather into the exposure it creates and the potential business impact in case of a breach.
To truly be able to associate the business risk with a vulnerability, Rob Hornbuckle believes that executive management needs both a solid understanding of application programming, as well as formidable knowledge of the inner workings of an organization’s business model. This enables them to prioritize mitigation in accordance with the true business impact of a potential breach on their unique business model.
Even if a specific vulnerability was able to disrupt operations at Colonial Pipeline, for example, it doesn’t mean that that same vulnerability holds any risk to another organization’s bottom line, especially if their business model is different. The most important assets to protect are those services and applications that expose critical business functions.
Developing a view of application risks within the context of enterprise risk management
Rallying the organization around security is no easy task, especially when their input – as valuable and important as may be – often creates delays and adds work to harried development teams. Ensuring that all levels of the organization understand the importance of the security team is a critical step in implementing secure development processes.
At BNP Paribas, the Global Head of Technology Risk Intelligence Sandip Wadje points out that making it easy for the organization to understand just how big their internal and external attack surfaces are and exactly which critical business functions are exposed, is paramount.
The first step is discovery – knowing what you have, how it’s used, why it exists. While this step is pretty straightforward, in the second step, governance, enterprises should seek to understand which steps they’re taking in terms of application development, maintenance and ongoing monitoring. Organizations must ensure that they have either a centralized governance committee or a 3rd party technology risk team to oversee internal organization security measures.
The third stage is that of assurance regarding ongoing security measures. Ongoing security monitoring that continuously analyzes new vulnerabilities as they’re discovered significantly reduces risks, as exploited vulnerabilities are often those that weren’t known to the organization.
Finally, resilience is another key capability to develop. Putting in place concrete procedures for incident response and reducing exposure is essential in the case that vulnerabilities have been exploited. As many organizations are already using different security solutions, ensuring effective use of these solutions in protecting critical business applications is key.
Learn more on how to make your security team a necessity in the API-first era.
Take this example: at BNP Paribas, the security team created a blueprint of different applications to understand how each one was impacted by the transition to the cloud. This blueprint is used by executive management to empower a view of the different workloads that could be safely migrated to the cloud.
They then created governance around it, both at the corporate group level, which focused on strategy, and at the operational level, which focused on ongoing monitoring assurance. Their next step was to create an API steering committee to prioritize services in terms of their ability to monetize data. Finally, they set up a 3rd party risk management program and included important internal stakeholders to develop their application security strategy.
The surprising upside of security regulations
Much like individuals, teams also have a reputation. For security teams, it is highly important to ensure that over time they aren’t viewed as a nuisance getting in the way of speedy deliveries but rather as a business enabler. This is where regulations can actually go a long way in ensuring that this isn’t the case.
By conditioning the launch of new initiatives on adherence to security, safety, and compliance measures, security teams become a necessity. Once security teams clearly draw lines between regulations, the vulnerabilities they discover, and the business impact, development teams will stop seeing them as a nuisance.
This elevates security to a strategic business enabler and even a competitive differentiator.
At Mastercard, for example, under the leadership of a CEO that has been focused on security from the get go, their corporate security team is at the heart of their business model and provides security services to all of their customers and to the ecosystem at large.
Summary
In the API-era, organizations must rethink their security posture. Trends like the crisis of confidence, supply chain interconnectedness, regulations, and the increasing number of malicious actors dictate the shift to an inside-out approach in terms of cybersecurity.
With more and more enterprises allowing users to access data and functionality through APIs, the security perspective must change from restricting access to better controls and permissions.
To get started, organizations must first ensure clear visibility of vulnerabilities and the ability to prioritize according to business impact. Ensuring that the entire organization understands the threats and risks posed to their critical business processes is also key.
Establishing formal processes, including discovery, assurance, ongoing monitoring, and resilience, and finally, changing the view of security teams from a nuisance to a necessity is critical to shipping secure products.
*** This article is based on the first session of the executive education program by Imvision.