Secure Mobile Device For Enterprise

With the introduction of cool mobile devices available for the corporate world, executives feel their existing blackberry out of fashion. For a while, blackberry devices ruled the corporate world for mobile communications. They are efficient and highly secure.

Blackberry security is still considered the gold standard for enterprise mobile communications. However, with generation Y taking over the corporate world, enterprise infrastructure have a hard time meeting their demand to have social networking and other mobile applications available on their mobile devices. RIM’s product is no more preferred; rather it is now one of the options that should be available to the corporate users.

There is also increasing demand among employees to use their personal mobile devices (individually liable) for enterprise use. They view pervasive wireless LAN (WLAN) and mobile cellular coverage as “must have” capabilities and consider smartphones as “must have” tools that would help integrate their personal and professional lives.

Until recently every enterprise had a web address advertised along with their products. Now, their applications are showing up in mobile device application (app) store and their mobile web addresses (example m.mycompany.com) are advertised along with their web address (example www.mycompany.com) increasing their competitiveness.

So how do we secure such diverse devices while making them available for corporate use?

Continue reading “Secure Mobile Device For Enterprise”

Password Management In An Enterprise

With the increase of various types of application in an enterprise, the nightmare of managing access to them increases. One of the major issues is how to manage passwords to multiple applications.

I would like to remember only one password for all applications in the enterprise instead of writing each one down whenever its time to change it. The frequency of changing the password may vary from application to application, so does the password rules.

If you look at it from the cost perspective, every call to help desk to manage password costs an estimated $25 – according to Help Desk Institute. So having a password doesn’t come cheap, especially when you have multiple applications at various domains. Imagine this cost coupled with the cost of maintaining the credentials at various applications.

So why not use a software like Bruce Schneier’s Password Safe (http://www.schneier.com/passsafe.html )? That type of software is good for personal use when I have the luxury of time to dig through my list of domains and their credentials. They are not good for an enterprise that is regulated by various statutory requirements. It still does not solve my pain of signing in to multiple applications.

How about Singe Sign On? According to experts in the field, not many enterprises were successful in implementing in this area with single sign on. With all the acquisitions and mergers, it is found better implemented at the divisional or business unit level. However a more realistic approach would be to have reduced sign on.

This is not an easy job for architects as they need to consider stronger authentication mechanisms based on risk policies while consolidating application and reducing the number of access challenges.

One of the major constraints to reduced sign on is the multiple identity and policy domains that exist in the enterprise. They can be handled by having a primary authentication point which will facilitate background authentication with other policy domains. A user is challenged by a single primary system, while that primary system takes care of authenticating with other system in the background without the user’s knowledge.

Some of the options in consolidating sign on are extending network operating system login and centralized LDAP. However, they do have their own limitations. For example, network operating system login cannot be extended to external users and there could be multiple LDAPs within the enterprise that need to be consolidated.

Implementations such as E-SSO where multiple logins can be integrated to one single system is preferred for reduced sign on, however it is a large undertaking and requires time. Similar is the case with federated authentication using protocols such as SAML.

One of the easiest and quick fix to manage this nightmare is to have a password management system. Whenever a user changes the password, it is synchronized with all applications and tools such as LDAP and Active Directory using the password management system. In this way, I have only one password, possibly one user-id, for accessing all system in the enterprise. This still does not reduce my multiple sign on, however it’s the right step in the right direction.

Protecting Clear Text Password

Passwords are the basic type of authentication in a system. They are easy to implement and also easy to attack. However, there are situations where you need to use a password to protect access to a resource. Its fine if an end user of system is providing the password directly to the system. Sometimes you need to store the password in a configuration file of a system. That’s where the dilemma starts. You have a scheduled SFTP process that needs a password to start. Do you keep the password in clear text or do you encrypt it? If you encrypt it, then how do you protect the key to encrypt and decrypt the password?

I would never suggest you to keep the password in clear text. Always have the password (in store) encrypted; symmetric encryption using 3 DES is preferred as it is efficient and will not tax the system resources. The keys can be stored in a key store. Any process or function in the system needs to have a password to access the key store to get the keys. So how do you protect the master key to the key store? Easy and economic way is to have the master password to the key store in a system configuration file that can be accessed only by the function or process that needs to know about it.

This is not a complete secure solution. However, we are introducing concept of security-in-depth where you are introducing layers of security to protect a resource. So when the scheduled job of SFTP needs to be kicked off, the process (or the job) first accesses the configuration file that contains the master password for the key store provided the process has the right privilege to access the configuration file. Once the process gets the master password, then it would decrypt the cipher text (encrypted password) to get the password to kick off the SFTP.