With the continuous expansion of Web-based applications comes the inevitable proliferation of worms and viruses seeking to exploit their vulnerabilities. Worms often attempt to use weaknesses in applications to harvest data, such as personal information and username and password combinations, and send it via the Internet to a centralized repository. Once in such a repository, the data can be sold or used in a variety of illicit activities, including spam propagation, illegal credit card use and identity theft.
There are, however, some ways information security pros can use access management technology to reduce the likelihood of Web application infection, as well as reap some additional benefits that come with these security measures.
In particular, I recommend implementing single sign-on (SSO) and single sign-off for Web access control. Let's look at how to implement SSO for Web applications and the benefits of doing so.
Single sign-on falls right in with the t...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
echnologies commonly employed in an IAM program. SSO is a way to authenticate a user to a variety of disparate systems through a single set of credentials. When the user logs on to a client or terminal using his or her SSO-based username and password, the system validates that user's authenticity and logs in to the underlying systems with a username and password unknown to the end user. The passwords to the underlying applications can be more complex than typical passwords, since the end user doesn't have to know or remember them. This also prevents the user from logging directly into the applications: Because they don't know the passwords for the individual applications, access to all network resources is governed by the SSO system.
The SSO paradigm offers a number of benefits for users as well as for overall organizational information security. Among those benefits are that users must remember only one password, the password requirements for the applications can be complex and their passwords can change frequently without the end user's knowledge, and there is a centralized place to lock the end user out of all the applications if need be.
The downside is that if the end user's SSO password is compromised, it will allow access to all the applications leveraging SSO. Fortunately, this risk can be mitigated by requiring two-factor or multifactor authentication.
What is two-factor or multifactor authentication, how does it tie in to SSO, and how does it help secure Web applications? Two-factor authentication uses two variables known to the user to verify his or her identity. True multifactor authentication typically requires at least two of the following three groups: something you know, such as a password; something you have, like a token or encryption key, or something you are, namely a unique physical characteristic of a person, such as an iris pattern or fingerprint. Using two of these three authenticator types makes it much harder to impersonate an individual, giving the application owner more assurance of a user's true identity. If the company has multiple Web applications, SSO with two-factor authentication can be implemented as the authentication mechanism for all of them.
In addition to preventing unauthorized users from accessing sensitive applications and data, SSO can prevent malicious code infections as well. For instance, worms are thwarted by two-factor SSO because while it is possible to harvest a password, they can't harvest one of the other key pieces of information, such as a fingerprint or token. They also can't harvest the complex application-specific passwords because the user never knows them or types them in.
Implementing SSO for Web-based applications starts by identifying the current authentication technologies being used. For each type of application and authentication method being employed, an agent or adapter must be set up per the guidelines of the SSO framework. These adapters sign on to the applications on the user's behalf and are governed by policies. The rules for password complexity, expiration and history must be included in the policies.
Because this process as described is specific to Web-based applications, there is also the added complexity of implementing the technology in your company's DMZ. This is required because users from the outside world should not be able to access any part of the network without first being authenticated.
Although implementation requires a significant amount of up-front analysis and carefully laid out delivery strategy to minimize the effect on customers or users, the benefits to them, to the application support personnel and to the organization's security posture may make it well worth the effort.
About the author:
David Griffeth is the Vice President of Business Line Integration and Reporting at RBS Citizens Bank, a financial institution that is one of the 10 largest commercial banking companies in the United States ranked by assets and deposits. As part of his responsibilities, David manages the Enterprise Identity and Access Management group and is charged with supporting the bank's growth model while maintaining compliance with several regulatory bodies. Prior to his current position, David consulted on major information risk management projects with large companies such as Fidelity Investments and CIGNA. David earned a bachelor's degree in computer science from Framingham State College and holds several certifications including CISSP and CISA.
