Justin Bieber and Selena Gomez ramp up on API Security

When your ex-girlfriend's Instagram gets hacked through an API security breach, and your risque pictures go viral, you rapidly try to understand the root cause of this breach and commit to becoming an API security expert.

Maybe that is expecting too much from Justin Bieber and Selena Gomez, however, it should be something that should make API security concerns viral and mainstream. Initially, the API security breach was purportedly limited to "high-profile" users ala Gomez, et. al.

The latest report shows that database of over 10,000 users may have been exposed and potentially over 6 million users' data scraped for sale @ $10/query. For details see:

Site sells Instagram users’ phone and e-mail details, $10 a search

Technical Details: Here are the steps that the hackers may have taken for this API Security Breach:

1.  Pick outdated Instagram mobile app version 8.5.1
2.  Create a valid Instagram account
3.  Select password-reset option.
4.  Use web-proxy servers to act like the mobile app calling the Instagram Servers.
5.  Modify the request at the web-proxy with the user id of the celebrity.
6.  The Instagram server would send a JSON-formatted response with personal information.

For this particular attack, it seems like a legitimate user session is first established. Then a password-reset request with a user id other than the initial user is sent to the Instagram server that leaks the *impersonated* user's email address and phone number via a JSON response. I wondered why a password reset would send this data in a JSON response - perhaps because the mobile-app validates it against what it has stored internally on the smart phone. The web-proxy in the middle doesn't care about this validation. Had JSON Web Encryption (JWE) been enabled on the JSON response, the web-proxy-in-the-middle attack would have only seen the encrypted data.

API Security and MySQL -- A match made in Hell

What do API Security and MySQL have in common? Not much one hopes, especially if you are responsible for implementing enterprise-wide API Security. When picking any security product, particularly an API Security Gateway, an enterprise should carefully evaluate the architecture and components of the product that it's purchasing. If the components such as Operating System, PKI security stack and policy storage mechanisms are not secure, then an enterprise is increasing its API attack surface area rather than mitigating it through an API Security Gateway. And please don't have your security policies stored in a database such as MySQL -- a prime target for hackers. If you security policies are stolen, your entire enterprise API ecosystem is compromised. Alexei Balaganski's article -- "The Cargo Cult of Cybersecurity" -- critiques our false sense of security. We spend billions of dollars (120 Billion in 2017) on cybersecurity products that are poorly developed, improperly or never deployed, and rarely tested by a third party. By doing so, we are creating a false sense of security. Here is an excerpt from Alexei's article:

However, the exact reason for my today’s rant is somewhat different and, in my opinion, even more troubling. While reading the documentation for a security-related product of one reputable vendor, I’ve realized that it uses an external MySQL database to store its configuration. That got me thinking: a security product is sold with a promise to add a layer of protection around an existing business application with known vulnerabilities. However, this security product itself relies on another application with known vulnerabilities (MySQL isn’t exactly known for its security) to fulfill its basic functions. Is the resulting architecture even a tiny bit more secure? Not at all – due to added complexity it’s in fact even more open to malicious attacks.

For complete article, see: The Cargo Cult of Cybersecurity."

Buy vs. Build: API Security Solutions

Three factors that will help determine the best approach for your organization

In the world of application security, there are numerous options in the marketplace for both buying and building.  Purchasing a centralized API security solution isn’t cheap but it can be less expensive than building your own, depending on your situation.  In this blog post, we will look at three critical factors that will help you determine which API security solution is best for you.

The number of API security policies needed

This might seem obvious but the number of security policies needed is one of the easiest factors to help determine which option is best for your company.  The math is pretty simple, the more applications you develop, the more security policies you will need. And, the more security policies needed, the longer it will take to code them.  Configuring a security policy through a centralized API Security system takes much less time than building it from scratch.  The key is to figure out the threshold where it makes more sense to buy instead of building them yourself.

It’s also important to consider your product road map.  Are you planning to dramatically increase the number of applications being developed?  That will likely influence your decision.

The nature and use of your applications

How many of your applications will be integrating with other applications? Are those other applications internal or external?  The ease of creating integrated applications has allowed developers to quickly build rich and powerful programs but it also increases an application’s exposure to breaches and other security risks.

It’s important for organizations to look at the type of information that is at risk and what are the consequences if their application is breached.  For example, a company that stores PII (Personally Identifiable Information) in their application should be much more cautious than an online forum that stores email addresses and usernames.  The company that stores PII should see a lot more value in a centralized API security solution and would likely work with an outside vendor rather than building and maintaining the policies in house.

Resources & Timing

Let’s say you wanted to code your own security policies, does your development team have the necessary skill set and bandwidth?  How long will it take them to define and code the API security policies?  Building will probably require a project manager or product manager to lead the process.  If you ask any seasoned product manager or developer, defining and building usually takes longer than originally anticipated.  Hiring new team members also takes time and money - finding the right people isn’t easy!  There’s an opportunity cost to be evaluated when looking at the time it takes to properly staff and build vs. working with a vendor but we will go over that in a future blog post.

Organizations also need to consider the cost of maintenance: is your organization willing to dedicate someone’s time to updating and maintaining your in-house security policies? If you saved time by hiring contractors to build the security policies, are you willing to keep them on staff to keep up with the maintenance?

With any major infrastructure decision, there are pros and cons to each side. What’s important is to look at both sides and decide what’s best for your company. These topics and criteria are some of the main items that need to be considered.  If you’ve gone through this process, share in the comments what other factors should be included in the buy vs. build analysis?