Why is the security team still laughing at your functional spec?

You cranked out your best functional specification ever for your Internet web application’s security. It has staggering details about what roles exist for the application and what operations each user can do in each role. Every piece of data in the system has information about what each role can do with it and each user’s actions are logged for auditing. But still when you request sign-off from the security review team you still get that same deep, deep sigh. What could possibly be missing?

1. The Internet – Anything displayed to user the user can copy and share to the world. Anything the user can download they can post on the Internet themselves. Are you sure you trust your users with everything you provide access to through the site? If not, remove it.

2. User Empowerment - What can the user get the application to do for them? If the application sends e-mail from your company address (maybe you let users invite other users), what prevents users from leveraging your application to send spam or annoying e-mails to people? Does all data customers enter get reviewed before it is displayed to other users? If not, how much can malicious users damage your company reputation by misbehaving?

3. Authentication Authority – What mechanism will customers use to authenticate with the application? Are you going to take your business unit down the unpleasant road of creating accounts for customers and helping them reset their password? If so, how much does it cost, what criteria is enough to reset a password and how does the customer do it?

4. Provisioning - How do you make sure the users invited to use the application are the users which get access to the application? If the wrong customer gets provisioned in a role, all your work to say who can do what is for naught. If your business already has a single sign-on solution, how do users with existing accounts and new customers get provisioned? One option is to create one access code for each user and let new users create accounts automatically. The user is sent the access code in a safe way and must authenticate (might involve creating a new account) and enter the access code. Once used, the access code is destroyed after associating the customer information from the access code to the account.

5. User Lifecycle – Every project has that happy phase where new users come, new features appear and management gets excited and showers you with gifts. But what about later? When do users get removed from the system? For example, do you revoke all user access every quarter and make everyone reapply? This is a poor user experience, but if you want to collect accurate marketing data about customers during registration it is great to have fresh users. Never trust the customer to let you know who they are. What information do you use to decide to remove customers? Is it information the customer entered or information your team stored when you invited the user to use the application? If your users are from business partners, how does a user get removed if they leave their company and how do you even know they left?

Remember, you are the expert for your application. Do not expect the security team to uncover anything on your schedule. Work with them and find out what they are looking, get feedback and learn how they think. Your projects will run so much smoother with you raising the issues, resolving them and confirming the resolution with the security team. Maybe they won’t laugh at your next release; but instead give you that broad grin of satisfied respect.

Comments

• Anonymous
  February 05, 2007
  Amen to that! I've worked on a lot of web apps and I've only been brought in once to comment on the security, or even the functionality, of a new product or feature.  As a result, there have been a number of times where late nights were needed to change functionality or operations was overruled and poor practice was implemented.