A Practical Guide to Security in Your Shop a.k.a. Not Every Nail Needs a Hammer

By Vinay Pai
published: Wednesday, August 27 2008

When IT folks, hear the words "security" and "compliance," they dash into the nearest phone booth and emerge in superhero garb, ready to defend us from the bad guys. Developers, on the other hand, usually run for cover, because they know that security comes with an ever-more-restrictive set of processes, rules, and intrusive tools.

In my current role as the VP of Product Development at PayCycle, I have responsibility for development, QA, and IT. Normally, IT reports through G&A. However, since PayCycle is a SaaS shop, the production environment and development environments need to be closely aligned. Hence, IT is part of PD. Although I'm a developer at heart, I need to think about the business and minimize any financial exposure from security breaches.

Over the years, I've developed a very practical approach to security that has served me well through various roles in different business environments. Security should be approached with a business perspective first and a technology perspective second. Don't get me wrong. Technology plays a key role in maintaining security. However, security is about risk mitigation, and you should ask yourself two key questions:

• What is my exposure in the event of a security breach? Think in terms of lost productivity or financial liability. I personally like thinking in terms of financial liability, because it's hard to argue with real dollars.

• What's it going to cost me to implement this security policy? Think in terms of the initial implementation cost as well as the ongoing cost to your operation.

Let's look at three different environments: (1) a development environment, (2) a production environment, and (3) a mobile device, such as the iPhone.

A development environment generally consists of source code that contains your company's intellectual property and third-party tools required to build and test your product. All of this may be local to a laptop, or some parts of the environment, such as the database server, may reside on a server or on a VM running hosted on a server. Developers are gated by the speed at which they can write code, compile code, and debug code. Developers don't need actual customer data; they can work with "fake data" that resembles real customer data.  In the event of a security breach, your company's source code can fall into the wrong hands, but no customer data should be compromised. Standard intellectual property laws, including patents, copyright, and trade-secret laws, are your defense here. Adding excessive security controls reduces your development team's efficiency at writing code during the daily code-compile-debug cycle.

Your production environment holds not only your company's product but that most prized possession-your customer's data. In the event of a security breach, your liability can easily run into the millions of dollars. If customer data is compromised, you can be required to purchase credit protection, which can cost $150 per customer. That's $1.5 million for every 10,000 customers. Yikes! Any security you add only slows down production deployments, which only happen a few times per week. Restricting production access and adding additional security technology makes great sense for your production environment based on the risk exposure and the additional tax on an infrequent activity. I can't go into details about our production environment for obvious security reasons, but you should really go all out with building your moat, stocking it with alligators, and having hot oil ready to pour down your castle's walls.

And finally, we have our good friend, the mobile device or smart phone. You can read your e-mail and surf the web from your phone, but that's about it. There's no reason to have source code or customer data on that little device. It's all about staying in touch with the mother ship-not compiling code from the bleachers during your kid's soccer game. (You would just use your laptop for that.) So how much security do you really need for that mobile device? Phones can be deactivated remotely by the cell phone company, and most IT departments can remotely erase the contents of a mobile device. So, you should keep things simple on your mobile device. There's no need for a pin or lock code that's needed every time you access your e-mail. Just go with the standard features on the phone. If the phone's lost, it can be quickly deactivated.

If you take a "one size fits all" approach to security in your enterprise, you'll find that you can aggravate users while reducing productivity. Instead, think about the risk exposure and the incremental cost in different environments within your shop. Tailor your security policy accordingly. You'll find that you can have happy, productive users while safely securing your business.

Related Links:

PayCycle , The VMs are Greener on the Other Side of the Fence