In part 1 of this series, I discussed the importance of physical security related to SaaS-based applications. The focus was primarily on the data centre, processes and compliance. 

Part 2 of this series deals with application security. Before I discuss the security aspects of an application over the web (better known as a SaaS application), let me first describe what I'm referring to as the "application".  Generally speaking, an application is the part of the service that you can see and interact with.  In IGLOO's case, our users interact with our community application using many methods:

1. Web Application
2. Desktop Tools
3. Mobile Devices
4. Our API (application programming interface)

All of these application interfaces must be secure. In this blog, I'll survey the landscape of various aspects of application security and examples of how they're addressed - it's a big subject so I'll mostly cover web applications.

When a web user is coming to the "front door" of a security minded web application, the application must first assure that the user is who he/she says they are.  Obviously, failing to have sufficient locks on the front door of the application can lead to data loss or, perhaps worse, the ability for a user to impersonate another. 

Some assurances that the front door of the application is secure include:

• A username and password, this is a minimum, and yet quite good way of securing a system.  As a matter of policy or built into the application, you should be enforcing the use of strong passwords (http://www.microsoft.com/protect/fraud/passwords/create.aspx).
• Since passwords can be "sniffed" by hackers watching your network, make sure the web application never transmits passwords over the internet in their original (or "clear") form; the application should use SSL or some other accepted mechanism to hide your password from onlookers on the web.
• Integration with your corporate directory system such as Microsoft's Active Directory or LDAP.  Linking your web application's username/password to your corporate directory will allow your corporate IT password policies to be utilized in the web application and, since your users will use the same credentials in the web application as on their local desktops, you'll get fewer forgotten passwords.
• Use of some type of "two factor authentication" (http://en.wikipedia.org/wiki/Two-factor_authentication).  For web applications, the most common of type is the use of a hardware token that displays a randomly generated and continuously changing authentication code.

Once a web user is authenticated and gets past the application's front door, you'll want to ensure that the user can see and act on only the content that they are permitted to. Most applications have some type of permission system, generally stated, that is used to segregate the access of content and functionality to a select group of users.  There's certainly a lot to talk about when it comes to permissions, stretching all the way from the concept of roles to your entire information taxonomy. Here's just a few points to remember:

• Choose a flexible AND simple system - your initial needs may be simple but they'll likely grow, make sure the permission system can accommodate some out-of-the-box thinking.
• Manage groups of actions and users by role - again, this can get complex but in order to make management less of a headache, make sure you can group users or functionality into "roles".

In my opinion, the topic of application security also includes accountability.  Even if all the locks and permissions are in place, you may still a need to find out what actions were performed on content, by whom, and when.  Make sure that the web application you choose records all access to content and all changes to content in an audit log, preferably a log that can be broken up into manageable chunks, for example a log for each piece of content.

One last thing, because you've chosen a web application, your users can access and interact with the application anywhere in the world, including some relatively unsafe places like internet cafés.  Make sure your users are trained to log off of the application when they're not using it or even when they get out of their seat, better yet, choose a web application that logs the user out after a period of inactivity.

Stay tuned for the next article in this series, in which I'll tackle the issues around network security.