From the Blogosphere
Secure Your API… Like a Castle By @MHeusser | @DevOpsSummit #API #DevOps
If our organization is a castle, then the API is the unique services that people can employ
By: SmartBear Blog
Aug. 7, 2015 09:00 AM
Secure Your API...Like a Castle
It's been three years since I compared medieval security to web security, and a few things have happened. Mobile and wireless have evolved as the dominant platforms, while the life between personal computing and business computing has continued to fray. And, of course, thanks to web services, the web-delivered API now dominates the connected world.
It's time to take a second look, focusing on the API. That is, if our organization is a castle, then the API is the unique services that people can employ, both inside the castle (cooking the food, cleaning the stalls for the horses) and outside, replenishing supplies, or bringing books in and out. While the first and most obvious division that comes to mind is internal or external, we'd like to take a step back and mention threat modeling - through the eyes of a viscount.
It Starts with the Threats to an API ... Err, to the Castle.
Again, today we're looking at the services those castles give - so is there really any security threat on the food service inside the castle?
Only if someone might have reason to poison the king.
Back to the 21st Century
If you don't have a formalized threat model of your system, building one does not have to be a massive undertaking.
Let's talk about that front gate
While most companies look at encryption, not enough consider authentication - how the system recognizes the user. Basic authentication sends the same user/password combination as part of every request, while session management assigns a session id, a unique key, only once when login is required. If an attacker has a valid session id (either by snooping on one machine or having a valid login and looking to abuse the system) they can try a technique called session hijacking, where the attacker attempts random session id's of similar form to the original - until something works.
Don't roll your own security, use something off the shelf
When it comes to encryption, decryption, and authentication, if you don't use off-the-shelf components, at least make sure you have a reason why. When it comes time to maintain a legacy API, take another look at the security methods in place.
You might not have funds to rebuild the castle, but adding a pot of boiling oil at the top might help. You can check out Secure Pro here, which is SmartBear's API security solution.
Consider Internal APIs as if they were external
Before standing up that server, give it a second thought. Once security architect I interviewed pointed out that just because an API is designed to not go external does not mean it will never go external. I can bear witness to that, having developed a web application that allowed external customers to schedule meetings with our employees, extending a Microsoft Outlook API to the outside world.
The second problem with ignoring security on internal APIs is that it missed the idea of defense in depth. My friend the architect put it this way: "I don't think firewalls can be trusted anymore. They are a good layer of protection, but in security we talk about defense in depth. The castle has a moat but it also has a wall, a portcullis and arrow slits. When you think about it, most internals systems are just a firewall and a network hop away from being exposed to the internet."
Putting It All Together
Consider a salesperson who is leaving the company but staying in the industry. Forty years ago, stealing a rolodex was a lot of work. Twenty years ago, he'd have to print out a customer list, which would be visible. Today we are busy writing the API to let him get the data the day before he turns in his resignation. And, sadly, unlike the guards in a real castle, computers and databases are unlikely to mention a strange series of requests to the captain of the guard.
Today we scratched the surface of API security with authorization and transport security. Securing the end-points, and training for social engineering are probably next. Start with threat modeling.
Finally remember, this: An API that can make its way onto the internet, probably will.
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week