Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats //

Vulnerability Management

4/3/2014
06:00 AM
Ravi Ithal
Ravi Ithal
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

API-First: 3 Steps For Building Secure Cloud Apps

When it comes to protecting data traveling to and from the cloud, today's choices are daunting. Here are three steps for making the application programming interface your new best friend.

What’s the best way to secure traffic to the cloud? It’s a question I get asked regularly by CEOs and technical founders of cloud startups. A typical observation: "First it was TCP. Then HTTP became the new TCP. Now APIs are the new HTTP." 

To be sure, today’s choices are confusing when it comes to security, cloud, and application programming interfaces (APIs). But, at the risk of making cloud security even more complicated,  I’d argue that the most secure way to manage traffic to the cloud is to take an "API-first" approach when building a new app. 

If you think about it, this is a pretty straightforward concept. Any interaction between a datacenter component (or any component for that matter) can be thought of as an API -- a web server talking to a database server, a web server's REST APIs talking to an API a client is using, or even a DNS protocol talking to the authoritative DNS server you’re hosting. 

From a security angle, pretty much any attack must happen over APIs, whether you’re talking about a database server compromised by a SQL injection attack, or a web server breached through a crafted REST request, or a DNS server DDoS'd by a concerted attack using the DNS protocol. If you don't know what those paths to interaction are, you will either underestimate or overestimate the threat. If you underestimate, you are wide open for an attack, and if you overestimate, you will just add more complexity to your security infrastructure, which can be both risky and costly.

To address this dilemma, I suggest three steps:

Step No. 1: Minimize the number of API end-points. This step will make securing end-points tractable in the long run. You will first need to identify and tabulate each API. Sometimes you can "normalize" end-points, which achieves the same goal of reducing them. For example, if a farm of web servers exposes the same REST API, you know they can all be secured the same way. Or, if a web server is exposed in REST API end-points that support the GET method, it’s easy to use a custom web application firewall to make sure that a POST call never gets through. In fact, whenever I hear a developer say, "That’s easy. We’ll just expose another API," the hair on the back of my neck starts to stand up!

It’s also important to keep in mind the security consequences of the end-points you’re exposing. Work closely with your network architect to make sure they’re indeed protectable. For example, using a syslog port to get data from a customer is a big no-no because, practically speaking, if you expose port 53 to the Internet, it is (practically) impossible to authenticate a sender. 

Step No. 2:  Isolate components with clearly defined APIs between them. Why is this important? Once APIs are defined, the threat surface is easier to define and protect. You could even go so far as to isolate at the network or OS level. This means separating VMs or containers to make sure all resources are isolated, VLANs to make sure other hosts are not discoverable, and firewall filters to make sure only expected traffic flows between hosts. And now for your "do not try this at home disclaimer:" Attempt the latter two only if you really know what you’re doing, as they can quickly become an operational nightmare.

Step No. 3: Come up with a security strategy at the application level first. Then, for each exposed API end-point, add network security infrastructure as needed. At one extreme, you can choose just to protect the Internet-facing APIs, which allows ease of ongoing operations. At the other, choose to isolate all components and protect all APIs. This allows resiliency of the security infrastructure; if one server is compromised, the attacker cannot immediately get access to all of the other hosts. S/he has to find another vulnerability in one of the exposed APIs before taking over another connected server. 

I’m not saying this approach is foolproof, but it certainly would require more than a credit card and Internet connection to get the number of zero-day vulnerabilities needed to break in and carry out the attack unnoticed. While the latter (protecting all APIs) is preferred, it's not very practical in many scenarios as it can create operational headaches as well as impact the scalability of the security infrastructure itself. 

The hardest part of all of this will be to come up with scaling strategies for the protection mechanisms themselves. But it’s the lesser of two evils and a much more manageable problem than having to repurpose existing infrastructure.

Now it’s your turn. What would you add to this list for protecting APIs? And what are your favorite strategies for scaling security?

Ravi Ithal helped build the world's first app- and user-aware next-generation firewall at Palo Alto Networks. He has held several key roles at Juniper Networks and Cisco Systems. View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
4/7/2014 | 12:51:21 PM
Re: "API-first" -- how prevalent, how difficult?
If a team can overcome the obstacles, they can enjoy lower TCO (less equipment, fewer personnel for operations) and a much more pleasant workday (which all my NOC/SOC friends will appreciate).


That sounds like a "BIG IF," Ravi and Jason. Are there are any trends that you see that are pushing NOC/SOCs in that direction? Is it driven primarly by cloud adoption?
JasonSachowski
50%
50%
JasonSachowski,
User Rank: Author
4/4/2014 | 2:55:17 PM
Re: "API-first" -- how prevalent, how difficult?
There is definitely an advantage in focusing security controls at the application level first.  This goes back to the hard question of when will we determine that all network, and for that matter all devices, should be treated as hostile? 

Focusing on data-centric security models is a great way to reduce our attack-surface and be in a better position to protect critical assets.
RaviIthal
50%
50%
RaviIthal,
User Rank: Apprentice
4/3/2014 | 8:37:59 PM
Re: "API-first" -- how prevalent, how difficult?
Traditionally, securing networks has been either a brute-force approach or an afterthought. Newer cloud infrastructure as a service vendors are thinking along the API lines mentioned in the post. In practice, network security admins tend to err on the side of caution and end up deploying more big iron than necessary.

The practicality of API-first approach to network security boils down to how complex the APIs are. The more complex the APIs and interactions, the less likely it'll payoff to analyze. This Complexity is one of the biggest obstacles and hence the need to minimize APIs.

If a team can overcome the obstacles, they can enjoy lower TCO (less equipment, fewer personnel for operations) and a much more pleasant workday (which all my NOC/SOC friends will appreciate).
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
4/3/2014 | 3:14:23 PM
"API-first" -- how prevalent, how difficult?
"API-first" is an interesting approach, Ravi. But how prevalent a strategy is it and how difficult and practial is it to implement. What d you think are the biggest obstacles and what are the biggest gains?
SOC 2s & Third-Party Assessments: How to Prevent Them from Being Used in a Data Breach Lawsuit
Beth Burgin Waller, Chair, Cybersecurity & Data Privacy Practice , Woods Rogers PLC,  12/5/2019
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Our Endpoint Protection system is a little outdated... 
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19604
PUBLISHED: 2019-12-11
Arbitrary command execution is possible in Git before 2.20.2, 2.21.x before 2.21.1, 2.22.x before 2.22.2, 2.23.x before 2.23.1, and 2.24.x before 2.24.1 because a "git submodule update" operation can run commands found in the .gitmodules file of a malicious repository.
CVE-2019-14861
PUBLISHED: 2019-12-10
All Samba versions 4.x.x before 4.9.17, 4.10.x before 4.10.11 and 4.11.x before 4.11.3 have an issue, where the (poorly named) dnsserver RPC pipe provides administrative facilities to modify DNS records and zones. Samba, when acting as an AD DC, stores DNS records in LDAP. In AD, the default permiss...
CVE-2019-14870
PUBLISHED: 2019-12-10
All Samba versions 4.x.x before 4.9.17, 4.10.x before 4.10.11 and 4.11.x before 4.11.3 have an issue, where the S4U (MS-SFU) Kerberos delegation model includes a feature allowing for a subset of clients to be opted out of constrained delegation in any way, either S4U2Self or regular Kerberos authent...
CVE-2019-14889
PUBLISHED: 2019-12-10
A flaw was found with the libssh API function ssh_scp_new() in versions before 0.9.3 and before 0.8.8. When the libssh SCP client connects to a server, the scp command, which includes a user-provided path, is executed on the server-side. In case the library is used in a way where users can influence...
CVE-2019-1484
PUBLISHED: 2019-12-10
A remote code execution vulnerability exists when Microsoft Windows OLE fails to properly validate user input, aka 'Windows OLE Remote Code Execution Vulnerability'.