5 Tips for Managing Security for APIs

Creating APIs for your SaaS products provides invaluable benefits to your customers, allowing developers to plug into your resources and bring their products to market more quickly and efficiently than ever before. An API also allows you to integrate easily with other SaaS organizations, expanding your range of functionality to offer customers new features, increase your inherent value as a provider, and gain a competitive edge in the marketplace.

As with most beneficial technology, however, APIs are not without their risks. Exposing your APIs can leave you vulnerable to theft of API keys, a fairly easy way for cybercriminals to carry out denial of service attacks if you haven’t implemented the right security measures. These attacks overwhelm your server with data requests, crippling the availability of your product, and even costing you money, should the attackers demand a ransom.

At Threat Stack, we recently released Version 2 of our REST API, which serves as a way for customers to connect to our organization and extract critical information around security concerns in their environments. With Version 2, we have incorporated updates to meet industry best practices and to better protect ourselves and our customers’ data. Drawing on this experience, we have outlined below the ways in which you as a SaaS company can better manage security for your own APIs. Read more “5 Tips for Managing Security for APIs”

High Visibility Ahead: Building and Using Orchestration to Set Security Priorities

At Threat Stack, we use our own intrusion detection platform to protect Threat Stack. This gives us critical visibility into security events and alerts tied to our AWS infrastructure and instances, an all too popular target. But our infrastructure extends beyond AWS into additional vendor-managed solutions such as Cloudflare, SalesForce, corporate email, and others. So a key question is: How can we not only monitor those platforms, but also use the data from these logs to drive security priorities?

With that in mind, we set out to create a new custom internal app that can receive, store, and perform actions on information from all of these different sources. We opted to build this internal pipeline (some would call this security orchestration) instead of buying an off-the-shelf product because our security team indexes so highly on engineering and programming. We felt we could take an event-driven framework in a language we all knew and easily extend it to meet our needs, incorporating our internal detection and automated response frameworks, a choice we would not have made if our team or organization looked different. Read more “High Visibility Ahead: Building and Using Orchestration to Set Security Priorities”