For financial institutions authentication, determining whether someone who is who they say they are when entering into a system, is really important since the people logging on are dealing with other people’s money and very sensitive personal information. Authentication is a key way in which financial institutions maintain security, which is a top priority as
For financial institutions authentication, determining whether someone who is who they say they are when entering into a system, is really important since the people logging on are dealing with other people’s money and very sensitive personal information. Authentication is a key way in which financial institutions maintain security, which is a top priority as breaches are very costly. A recent survey by PwC found that 45% of financial services organisations had been hit by cyber-attacks, compared to 17% of other types of firms and institutions. Therefore despite being at the brunt of attacks, financial institutions need to do all they can to ensure breaches do not occur, in order to maintain the trust of their customers.
Financial institutions normally have experienced a haphazard and organic growth of systems to run their business, so often they end up with a widely diverse and un-unified mix of systems that users must log into – resulting in lots of passwords, very cumbersome provisioning processes, and tons of IT involvement to grant people the access they need. Authentication is the lynchpin for security and if different applications and systems authenticate in different ways, generally there will be a higher risk because whilst one system may be very strong, another may be weaker. Usually efforts made to alleviate the problem either reduce productivity, making it more difficult to authenticate to ensure security, or reduce security, making it easy to authenticate and therefore easier for someone to steal the credentials. The real problem financial institutions face then is a lack of unity, lack of consistency, and difficulty managing the complexity of securing highly diverse environments and user populations.
Authentication then is a huge issue for financial institutions not just in that it costs a huge amount. For example, one large bank is known to have spent up to $1M a month in IT costs to reset passwords for its retail tellers. Yet it is also an issue as financial institutions rely on authentication to maintain security which keeps their corporate reputation upstanding and ultimately keeps them in business.
The problem they face is that people forget their passwords all the time, yet a breach of a user password is still a major issue for security. In the above scenario each retail teller had access to about 12 different systems and each one had a different password, so this meant they often forgot one or more password and needed to call IT for help.
In addition, financial institutions need to use stronger authentication for certain financial transactions than what would normally be in place for regular transactions. Therefore certain users, applications and transactions require second factor authentication which means more calls to IT for help. Despite this the increased security offered by this approach means second factor authentication is becoming increasingly prevalent in financial institutions.
However, this is usually very difficult to achieve and often serves to make customers and employees’ lives miserable with mandatory strong passwords, and two factor authentication. The catch 22 is that whilst customers want ease of use, they also want security and unfortunately for financial institutions to achieve top security, ease of use is not part of the equation.
There are things that can be done to alleviate the problem and simplify the process. Firstly, leveraging the secure and unified authentication capabilities of Active Directory (AD) and extending it to other applications can help reduce calls to helpdesks. Secondly, implementing targeted multifactor authentication – for example for users logging in remotely, accessing specific systems, or performing specific highly sensitive tasks – can go a long way to mitigating the password problem, without a sweeping change in in user behavior. Thirdly, a good password policy and consistent enforcement is key and single sign-on is even better as no matter how good your policy is, if a user must have 20 passwords, all with high complexity rules, they are inevitably going to write them down – and that creates a risk. Finally, basing as much authentication as possible on AD by far offers the biggest bang for the buck. Everyone has AD and AD has an innately secure authentication method. It is also usually the first authentication activity performed each day by an employee.
Newer approaches look at other options such as “step-up authentication,” which is where you add context to the authentication transaction so rather than simply requiring a username and password in all situations, you can vary the level of authentication required based on the situation surrounding the authentication transaction. For example, if a user is on premise, using a company controlled device, to get to the resources that he or she typically accesses to do their job, you are only required to enter a username and password. However, as the risk level increases you can add additional “factors” of authentication. For example, if it’s after hours, the user is coming in remotely from a personal device, and is requesting access to something that they normally don’t access – you require a two-factor authentication before you let them access the resources, or if you could choose to deny the access altogether.
For financial institutions then authentication is a crucial for security and there are numerous things that can be done to make the process secure and also easy to use. The next step is then to look at once someone has authenticated how do you ensure that what they are doing is authorised, as in banks you need to strictly control what people have access to.
By Todd Peterson, IAM Evangelist, Dell Software