Featured

Identity Divorces Security…Again—The Oracle Edition

By | Date posted: November 14, 2017

Oracle recently released a Security Alert Advisory regarding a newly identified – and soon thereafter patched – vulnerability within Oracle’s Identity Manager, a user identity validation tool for granting access to enterprise systems.

The bug referred to by Threatpost’s Michael Mimoso as one that’s “as bad as it gets,” scored a 10 on the CVSS score – the highest severity possible. As explained via NIST’s National Vulnerability Database, the vulnerability is “easily exploitable” and “can result in a takeover of Oracle Identity Manager.”

Read more

Forum Systems Joins AFCEA Community

By | Date posted: October 11, 2017

Since 1946, AFCEA has been bringing together industry experts and government agencies to provide a forum for collaboration that better aligns technology and strategy with the needs of our government and military. AFCEA is widely recognized as a hub for industry innovation and thought leadership, and Forum Systems is excited to announce that we’ve joined the non-profit international organization as an official member.

Read more

Forum Sentry API Security Gateway protects all customers against Apache OptionsBleed

By | Date posted: September 22, 2017

Apache Optionsbleed is yet another vulnerability in an ever-growing list of threats targeting REST-based back-end applications aimed at compromising server memory.  In this case, it is Apache’s https program can be compromised by using HTTP method OPTIONS as described here:

– https://nakedsecurity.sophos.com/2017/09/19/apache-optionsbleed-vulnerability-what-you-need-to-know/
– https://arstechnica.com/information-technology/2017/09/apache-bug-leaks-contents-of-server-memory-for-all-to-see-patch-now/

Forum Sentry protects against this attack as one of the many API threat vectors that Sentry protects against.  This particular threat vector was detailed as #3 in our “Top 10 API Threats” list.  The HTTP method is heavily utilized in REST-based apps and services where commonly used HTTP methods such as POST, GET, PUT and DELETE for CRUD (Create Read Update Delete) services.   Forum Sentry API Security policies restrict the methods allowed to be used.  Additionally, these restrictions can be user-specific with granular authorization that can be applied to any HTTP method.

Forum Sentry protected 100% of its customers from Heartbleed, and today protects 100% of its customers from this latest OptionsBleed vulnerability.

Click here to learn more about how Forum Sentry can protect your APIs

Instagram API Security – Too Little Too Late

By | Date posted: September 1, 2017

The Instagram API vulnerability was exposed via a REST API used by the Instagram Mobile App to perform a password reset.  By capturing the format that the Instagram App used to make the password reset, a brute force attack was then created to iterate permutations on this API to extract information about other users returned back in JSON format.

This attack was exposed because of the lack of API security mechanisms protecting the API. An Instagram spokesman told Fox News. “We fixed the bug swiftly and are running a thorough investigation.” Guess what, too little too late! With API breaches, the damage is done.

This is precisely why API Security should not be left solely in the hands of API developers. Developing secure APIs is certainly the right intent and approach, but there is simply no way that developers should be tasked with understanding and protecting against all of the security threat vectors that exist in the API realm. This would be akin to foregoing a corporate firewall, and instead just relying on your developers to prevent network attacks.

API breaches represent the continuing saga of cloud and mobile applications being exposed by API development toolkits that do not have inherent API security capabilities enabled. This is largely because API developers are not security specialists and API toolkits and API Management platforms are not security platforms. This increasing trend of API vulnerabilities will continue until the industry recognizes the need for API Security Gateway technology to protect their APIs. If you have a Web Application, you use a Web Application Firewall (WAF) to protect it, you don’t rely on your developers to protect the application. If you have an API, you use an API Security Gateway to protect it, you don’t rely on your developers for this.

The API Security wake-up call is growing louder each day, breach by breach.

API Security and MySQL — A match made in Hell

By | Date posted: August 30, 2017

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.”

Forum Systems Lauds Recognition of API Security in OWASP Top 10

By | Date posted: August 18, 2017

Longtime API Security Champion Praises OWASP Community for Listing “Underprotected APIs” in RC1; Sponsors Premier AppSec USA 2017 Conference

BOSTON, August 21, 2017 – Forum Systems Inc., a pioneer in API security technology, today celebrated the Open Web Application Security Project (OWASP) community for including ‘Underprotected APIs’ in the OWASP Top 10 – 2017 RC1 list of most critical web application security risks.

Read more

Four Pillars of API Security

By | Date posted:

API Security is complex! Vendors like Forum Systems, IBM, CA and Axway have invested almost 2 decades of engineering effort and significant capital in building API Security stacks to lockdown APIs. The API Security stack diagram shown below is essential for rapidly locking down APIs. In this article, we review “The Four Pillars of API Security” — SSL, Identity, Content Validation and Architecture.

API Security Stack

Before addressing the Four Pillars of API Security, it is essential to recognize that a robust PKI is a must for enterprise-grade API Security. Without proper key life-cycle management, the API Security Pillars cannot be built.

Once a solid PKI foundation is in place, an organization can build API Security Pillars on this foundation. Without a robust PKI foundation to stand on, API security pillars will collapse. With a solid foundation and strong pillars, a corporation’s API attack surface area is significantly reduced. To deploy API Security, we recommend the following four pillars:

Read more