Taking a gander at the security landscape
For example, the first thing I noticed was that my proximity access badge was blank: no picture, no name, no recognizable icon to indicate that I'm an employee. I mentioned this to the people in human resources, but the concept of a personalized access badge seemed foreign to them. So I told them about something that had happened years ago at another company that used blank access badges. An intruder got hold of one, then, claiming he was a new IT desktop support staffer, came along and walked out with all the unsecured laptops he could carry. The stolen badge, looking like all the other badges issued at that company, told the people he encountered as he gathered up his haul absolutely nothing.
I also found in my new company doors that don't close properly and a data center door that is secured with a key rather than a proximity badge and biometrics. There are cameras at the exit doors and in the lobby, but no one is monitoring the video feed, and the recordings aren't retained according to a consistent plan. But though it was easy to find ways that physical security was lacking, my real concentration has to be information security. And there's plenty there to keep me busy too.
A good place to start is at the core of what this company does: writing software that is made available to customers via the cloud and Web browsers. We make our application programming interfaces (API) freely available to our customers so they can extend the functionality of our software by using Web services to integrate their own or third-party applications with our software products. For example, a customer might want to expose Salesforce data within our application, or add Chatter, a chat collaboration tool, so that their chat communications appear within our application.
Our API is what is called a REST (representational state transfer) API. When customers want to integrate another app with our software, they install the API on their server. Then the API authenticates to our application to either get data out or put data in. The way the API authenticates is similar to a person authenticating, and some of the same security concerns exist. Strong authentication, authorization, encryption and data validation are just some of the security controls that need to be in place. And I wanted to know if they were in place.
In reviewing several of the configurations that customers have in place, I noticed, for example, that many API integrations weren't restricted by IP address. I'm a big proponent of the rule of least privilege, and I make no exception when it comes to APIs. If our API code exists on a customer's servers, then only those servers should be allowed to make an API call to our application; any other IP address should be locked out. This is a very simple configuration, very similar to what we do for user accounts.
Another problem that I found concerned Web services accounts that were tied to a person. Web services accounts should be tied to an independent system account, not a person. People leave, and when they do, their accounts should be deleted. You've got a problem if the deletion of one of those accounts affects the API integration.
My review did turn up a bright spot: Encryption in transit isn't an issue for us, since we force all connections over HTTPS, also called SSL Everywhere.
By the way, if you're interested in assessing the security of API or Web services calls in your company, there are many resources on the Internet that provide a wealth of information. My favorite is one published by the Open Web Application Security Project (OWASP). I also recommend hiring a trusted third party to review any developed code and architecture to ensure that you're using this technology in a secure manner, since there's potential for big trouble if you're not.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Click here for more security articles.