This post will be part 1 of 3 for my ultimate guide to API security best practices series. In this post, I will be discussing the current concerns IT decision makers have in regards to their current digital assets.
Part 2 will address the need for keeping data private and protecting it from being compromised while making it accessible at all times.
Learn how to align security and agility
In some organizations, the Chief Information Security Officer (CISO) has earned a reputation inside of IT as a blocker or a hindrance to innovation. Some CISOs have even be referred to as the ‘Queen (or King) of No.’ Why? Because despite the massive amounts of attention being paid to security in the media, with Target, Apple, Nissan, and Twitter all making the news recently for their security failures, security is still considered an afterthought in most IT projects. As a result, by the time security professionals get involved in project delivery, they have no choice but to flag security gaps that often require impractical redesign — resulting in project delays at best and cancellation at worst.
In a previous post, I explained the reasons why pure SOA, despite being a powerful architectural paradigm with many benefits, could fall short. Building on that narrative, I will provide in this post guiding principles to help you create a modern integration strategy – one that enables digital transformation, supports the API economy and is suitable for the pace of change required to build an application network.
Anypoint Platform TLS 1.0 Deprecation
In an effort to ensure the highest levels of security for our customers, and in response to the PCI-DSS 3.1 standard, MuleSoft has begun the process of removing TLS v1.0, and replacing with TLS v1.2 as the default encryption protocol for inbound and outbound connections to Anypoint Platform.
Why are you doing this?
As you might have read, Mule 3.8 includes a number of improvements regarding TLS. In this post, we will analyze the TLS environment prior to this release and explore all of the new enhancements in detail so that you can start taking advantage of them.
We recently introduced our HowTo blog series, which is designed to present simple use-case tutorials to help you as you evaluate Mulesoft’s Anypoint platform. In this blog post, we show how an organization can use Anypoint Platform to communicate with their partners using a secure file-based solution.
The January 2015 release of CloudHub features several key upgrades to our infrastructure. With this release, customers will be able to run more applications per vCore (10 per vCore – up from the current limit of 4), and will also be able to run more compute and memory intensive applications – which consume up to 4 vCores in one instance. We are also releasing a new security feature – data encryption for persistent queues, which will help customers with their security and compliance needs.
More Applications per vCore, and Support for Bigger Applications
Starting with the January 2015 release, customer applications running on CloudHub will have a bigger palette of worker sizes to choose from. Currently, a customer application has a choice of 3 worker sizes – Shared, Regular, or Double, representing 1/4th of a vCore, 1 vCore, and 2 vCore capacities respectively. Starting February 7, applications running on CloudHub will have 5 different worker sizes to choose from, with the compute and memory capacities described in the following table:
|New Worker Sizes
||500 MB Mem
||1 GB Mem
||1.5 GB Mem
||3.5 GB Mem
||7.5 GB Mem
Securing an API in Anypoint Platform is easy. In a previous post we showed how Anypoint Platform for APIs allows you to fully protect your API. We concluded then that the combination of HTTPS and OAuth 2.0 are a rule-of-thumb best practice for Web API security. In this post, we’ll take a deeper dive into the makeup of a security configuration in Anypoint Platform and explore in more detail the areas of Basic Authentication and OAuth2 Authorization in the context of Identity Management. We’ll also give you some pointers about when and how to use these two standards.
Central to authentication in Mule is the Security Manager. This is the bridge between standard mule configuration and Spring Security beans. In the example we build in this blog, we will use Spring Security to authenticate credentials against an LDAP server. We suggest you read the Spring Documentation on this topic if you want to delve further.
Trust no one! Most security issues comes from assuming that no bad person is going to tamper with your input data. We usually pay more attention to it when processing the most common inputs, such as an HTTP request or some argument that’s going into an SQL query. But we usually don’t pay much attention to other types of resources that are also vulnerable to malicious thinking – such as an XML file.
External Entities are an XML feature which allow you to embedded an external source into your document. For example, let’s suppose that your application responds to queries using an XML schema, which contains a disclaimer footer. Your legal department is prone to changing the wording on it so it probably makes sense to take it from an external file, so that your templates (which are part of your deployed source code) are not modified. Such templates could look like this:
Last month the massive Heartbleed security vulnerability was exposed. Three weeks later a security flaw in Microsoft Internet Explorer was revealed. It seems as though every few months there is news of a security breach or vulnerability. As more and more business is done online, in the cloud and through SaaS providers, how can you be sure the applications you and your business use are safe? Using the Heartbleed vulnerability as a case study, this article will examine what went wrong, as well as what you should expect from a SaaS provider, before, during and after a security event.
What is Heartbleed?
Heartbleed is the commonly recognized name of an exposure identified in a critical Internet security software package called OpenSSL, the most common transmission encryption software package used by Internet servers worldwide. This vulnerability allows an attacker to craft keepalive messages in such a way as to force a server disclose its short-term memory space. Since a server’s memory often contains personal, confidential information, such as user passwords or credit card numbers, the attacker could obtain that information. More severely, the server may also inadvertently disclose to the attacker its own private encryption key, which then allows the attacker to subsequently listen to all communications with that server, even without using the Heartbleed vulnerability. The nature of this attack is such that it leaves no traces, and is practically invisible to common detection mechanisms (although now that it has been exposed, signatures for it are becoming available for popular intrusion detection software).