The secret formula for solving the dev-sec tug of war over API security
A team is commonly defined as a group of individuals working together towards a shared goal, like winning a championship. In the workplace, this shared goal could be as complex as taking over a market, or as simple as completing a task on time. But in many cases, instead of collaborating to achieve this shared goal, teams get in each other’s way, resulting in subpar deliveries.
Why is that? Sometimes it’s because of miscommunication, sometimes mistrust; but it’s always misalignment.
The conflict of interest between Dev and Sec teams
The way things are done in the business world is changing rapidly. Increased competition and a crowded marketplace have significantly accelerated the pace of development in recent years. To prevail in the new digital business reality, organizations must embrace new agile methodologies that focus on fast deliveries, often using new technologies that speed up development. APIs are one such major enabler of speed.
One of the main benefits of Application Programming Interfaces (APIs) is their contribution to speeding up deliveries: enabling developers to easily upgrade their own products with external capabilities or enabling them to go to market faster by integrating into other 3rd party products. Just imagine how late to market Uber might have been if it had to develop its own map capability instead of plugging in the Google Maps API.
But faster isn’t always better.
Security teams, on the other hand, often have goals that conflict with the ‘full steam ahead’ approach of the agile dev teams working on the APIs. While dev focuses on getting APIs out of the pipeline as fast as possible, security teams are geared towards testing for vulnerabilities and sending dev’s deliveries back to fix flaws and security bugs.
The inherent tension between these two teams is a perfect example of how teams with shared business goals can be at odds. Although both teams want to deliver innovative solutions, build great products, and increase market share, they approach it differently: one wants things to go faster, the other safer. Dev favors speed, sec favors caution.
Can’t we all just get along?
The logic is simple: by tackling security early on in the development process, dev is forced to deal with security issues before they can move to production. Teams are unified, goals are shared and KPIs become collaborative.
Oceans of words – blogs, whitepapers, presentations, even some books – have been written on the need to cultivate synergy between security and dev teams. Some advocate for establishing DevSecOps, others to setting up processes that Shift Left. The underlying sentiment, however, is basically the same – the gap is deeply rooted and requires major cultural and structural changes.
The problem? It doesn’t account for differing KPIs as the responsibility for threat prevention is solely on the security team, while dev is focused on meeting deadlines.
Putting trust back into Zero Trust
Have you ever dreamed about what it’s like to be a Formula 1 driver?
Today’s F1 cars are spectacular machines, beautifully balancing speed and safety. Made any safer, they would be slower; they can be made faster by reducing safety features. There’s a delicate balance simply because the car’s design and architecture is optimized for neither speed nor safety. It is optimized to be trusted to keep the driver alive in case of a crash. The engineering team focuses on the driver’s safety, not the car’s.
The difference is staggering.
An organization lives or dies by the reputation of its brand. With the business world undergoing a rapid digital transformation, clients’ trust is everything. If the brand is seen as untrustworthy, for example, because of a successful cyberattack on their APIs, years of reputation-building efforts can be destroyed in mere days. That’s why 72% of executives claim that the cybersecurity issues are discussed in every board meeting.
Instead of faster shipping or safer shipping, the shared goal of dev and sec should be trusted shipping. It’s never really about the application, but about the value, it generates to someone else, be it a person or another business. By focusing on the driver instead of the car, dev and sec can align their efforts. It can no longer be the sole responsibility of either the security or dev teams, but rather an organization-wide effort that unites all personnel.
So what does it actually mean to ‘ship trusted’?
Well, it depends. Every industry, every business model, every company is different. But the essence is the same: setting KPIs that focus on the end consumer’s experience, mitigating vulnerabilities that can undermine trust. For example, vulnerabilities to PII data: By including the protection of PII data in the KPIs, alignment can be achieved in what really matters.
This approach will reduce the back-and-forth between security and dev teams which occurs when security is only initiated at the end of the dev cycle — or worse when the API is in production. All APIs — including internal ones — should be treated as though they are external-facing endpoints and undergo continuous testing cycles.
Automation platforms offer a solution to the current situation. They identify anomalies in the development cycle, allowing CISOs to effortlessly manage API security throughout development. There’s shared visibility into what really matters.
By integrating security from dev all the way to production through new, automated platforms, responsibility for security is shared throughout the organization. Teams are automatically notified of vulnerabilities and can fix them during development. This approach saves precious time and significantly lowers the risk of vulnerabilities creeping into production. The future of API security is automated and distributed throughout the organization.
*** This is a Security Bloggers Network syndicated blog from Imvision Blog authored by Omer Primor. Read the original post at: https://blog.imvision.ai/the-secret-formula-for-solving-the-dev-sec-tug-of-war-over-api-security
