Salt Security Adds Governance Engine to API Security Platform
Salt Security today added a posture governance engine to its platform for securing application programming interfaces (APIs) that makes it possible to define and enforce implementation standards.
As part of this effort, the company is also providing cybersecurity teams with pre-packaged templates to create and manage API rules. Salt Security is also now making available consulting services to help organizations define the best practices needed to enforce those controls.
In addition, the company added additional filtering and querying capabilities to determine the purpose of the API, usage patterns and any potential risks by analyzing behaviors involving API events.
Salt Security also added an ability to enrich data to improve analytics along with integrations to consume data from application security testing platforms and export data to IT analytics platforms such as Splunk.
Finally, Salt Security has enhanced its role-based access controls (RBACs), improved integrations with corporate identity systems, enhanced system health management and audit controls and extended its data collection and data protection mechanisms.
Nick Rago, field CTO for Salt Security, said these additions to the platform will make it simpler for cybersecurity teams to both secure and govern APIs at scale at a time when there is little consistency in terms of how organizations build and deploy them. As new APIs are deployed, a data lake that Salt Security has integrated with its posture engine is continuously updated by machine learning algorithms.
Beyond just being able to discover APIs that need to be secured, cybersecurity teams are now being tasked with implementing controls that prevent vulnerable APIs from being exposed in the first place, he added.
API security has become a higher priority because just about every digital business transformation initiative revolves around APIs. A recent Salt Labs State of API Security Report, however, finds 94% of organizations experienced security problems in production APIs in the past year, with 59% having experienced application rollout delays because of security issues involving APIs.
The issue many organizations are encountering when it comes to API security is that it’s not always clear who is responsible for it. Developers routinely create APIs to share data, but they typically don’t have a lot of cybersecurity expertise, so there’s plenty of opportunity for mistakes to be made that enable cybercriminals to exfiltrate data.
Many cybersecurity teams, unfortunately, don’t tend to have much visibility into how these APIs are being created and deployed. As a result, all these APIs are, in effect, unsecured endpoints. Fortunately, the bulk of these APIs are internally facing, so the immediate crux of the issue is the security of the APIs that are externally accessible. While there are fewer of these APIs, cybersecurity teams should not overlook the security of internally facing APIs. It doesn’t take much for development teams to make an internal API accessible to external users, so what may seem secure enough today can tomorrow become a very big issue when some business unit decides to, for whatever reason, make an existing API accessible to some entity outside the company.
In theory, at least, developers are assuming more responsibility for API security as part of the general shift left of responsibility for application security via the adoption of DevSecOps best practices. The challenge is organizations are now routinely deploying thousands of APIs, which means the probability there will be a security incident involving APIs in the coming year is all but certain.
