Yes, that’s a vain attempt at an API joke and not your browser having issues. I wanted to draft this post to shed some light on why I chose to leave Gartner and evangelize API security with Salt Security. I’ve tried to keep the TL;DR to a minimum and have a brief ask of you at the end.
Why Leave Gartner?
Many might not know what analyst life entails, or how it differs from technical support, engineering and consultancy. At a high level, the work includes:
- Technical research and writing
- Client inquiry calls which take many forms including Q&A, talking through published research, providing document reviews and reviewing architecture
- Presentations and events participation in physical and virtual formats
Gartner clients include both vendors or end user organizations. I was an analyst within Gartner for Technical Professionals, which provides research and advisory services for technical professionals. This broad category includes developers, engineers, enterprise architects, security architects, security analysts and other roles seeking advice on their security strategies and technical challenges. Leadership roles such as managers, directors, VPs, and CxO seeking to validate something their engineers or suppliers are telling them also look to GTP. As an analyst, I talked to organizations of all sizes, across verticals and sectors. My coverage area initially was application security, but over the years my coverage expanded into areas of infrastructure security and cloud security. That expansion was by virtue of how IT and DevOps initiatives have evolved, in turn impacting how organizations build, integrate and deploy modern applications.
Technical challenges at a high level often appear similar, but every organization brings uniqueness with its structure, processes and technology stack choices. The intersection of technology evolution and environment complexity is a sweet spot that holds immense appeal to the engineering and analyst mindset. You have to be a jack of many trades but also a master of them. It also requires a wide array of soft skills. Analyst work is grueling but rewarding. The comradery one forms with fellow analysts is difficult to put into words, and it was an amazing experience to be part of the Gartner think tank.
This isn’t a plug for Gartner though, so let me get to the heart of my decision to leave. Simply speaking, I resigned as an analyst so that I could have a broader reach in the IT and security community. As much as I felt like I was helping people from all different roles and organization types, and Gartner’s client base is unmatched, there were times where I wanted to share my insights and thought leadership more publicly. That resonated even more so when there was an incident or breach resulting from ignorance to a problem covered in published Gartner research or presentations.
Why Focus on API Security?
APIs and matters related to securing them is a combination of many IT disciplines and security domains. At a minimum, this includes application development, enterprise architecture, identity and access management, network engineering, network security, application security and data security. Cloud engineering and cloud security also quickly enter the equation by virtue of data center consolidations and DevOps initiatives.
Historically, practitioners might view APIs as simple data connections which can be easily restricted at a network perimeter or something contained within an application. Reality is something much different though, where APIs form the heart of many applications. One API may power functionality within hundreds of applications, and a given application may consist of hundreds of APIs depending on its design. APIs are also front and center in the world of cloud-native design.
If your organization is acquiring, integrating or building applications, you have APIs. If your organization is gathering and exchanging data with customers or business partners, you have APIs. These APIs must be protected in order to detect and mitigate incidents and breaches. In our increasingly connected and automated world, APIs can also present privacy and safety issues beyond just traditional security vulnerabilities. Simply blocking access wholesale is a surefire way to create a production outage or impede business. Many APIs must be externally exposed if not open entirely to enable functionality and data exchange. Cloud adoption also quickly erodes the definitions of modern data centers and network perimeters, making traditional (network) security approaches infeasible.
Why Join Salt Security?
As an analyst, I witnessed countless vendor pitches and technical demos. It was an interesting part of the job and sometimes useful for research, but it can also be mind-numbing at times depending who’s presenting and how. Some vendors fully grasp the problem space and some don’t. Others want to explain a problem at length, failing to acknowledge the analyst has likely heard it hundreds of times over or written exhaustively on the subject. Still others may just want to get mentioned in research or obtain certain positioning in a product comparison. Side note: if you care to read further on the world of vendor briefings, feel free to check out Anton Chuvakin’s posts on the matter. It’s worth a read, particularly if you are a vendor. I was fortunate in my coverage area of application security that more vendors “got it” than not.
Salt Security is in the camp of vendors that “gets it.” They understand the many challenges and security issues that arise with APIs in application design and systems integration. They also understand how practitioners are trying to tackle the problems, even when adequate tooling may have been historically lacking. Since 2016, Salt Security has been busy developing and evolving an offering to address the many security pitfalls that come with the territory of creating and integrating APIs. They’ve created a solution that seeks to address full lifecycle API security rather than just one aspect. It’s also an elegant solution that can integrate into an organization’s many existing proxies such as ADCs, API gateways, NLBs and WAFs instead of requiring deployment of new proxies.
I have confidence in Salt Security’s offering and also the vision of its leadership. Salt Security has an amazing team with lots of brilliant minds on many fronts. They’ve given me freedom to share my insights and guidance with the broader community. I’ll be able to author and present in many formats about API security and not just pitch a product, though I’ll likely still advise you on how our tech can help matters. 😁🧂
The Future and Questions for You
As I settle into this role of technical evangelism and brainstorm ideas for content, I’d love to hear from you regarding what you’d like to see. You may already have suggestions, but if not, some initial questions include:
- What types of content would you like to see from me and Salt Security?
- What mediums do you prefer?
- What API security challenges are you struggling with?
- In what areas of API security do you think technical guidance is lacking?
- What have you seen in industry that works and that you’d like to see more of?