Credit: U.S. Army
Looking around at how things are done at my new company, it's pretty easy for me to find security problems lurking virtually everywhere.
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.
Sign up for CIO Asia eNewsletters.