Think Money offers lessons in meeting financial compliance regulations

Think Money Ltd, based in Salford Quays near Manchester, offers a range of financial services including insurance, mortgage advice and debt management. Founded in 1993, the company employs more than 800 employees and has been listed in the Sunday Times' "Best 100 Companies to Work for" for the past five years.

@75608Handling the financial details of hundreds of thousands of customers, Think Money is subject to strict regulation by the Financial Services Authority and needs to comply with other regulations such as the Data Protection Act and the Payment Card Industry Data Security Standard (PCI DSS).

In order to meet financial compliance regulations and boost security, the company has recently implemented DbProtect, a database security management product from Application Security Inc. One major benefit of the product is to monitor the actions of privileged users, such as database administrators and systems administrators.

In this interview, Lee Ward, information security manager of Think Money, explains the background to the project and outlines the benefits.

What security challenges has your organisation faced, and what regulations are you subject to?
We are subject, of course, to the Data Protection Act, to PCI DSS, and we are on our way to achieving ISO 27001. We have a specific focus upon PCI DSS, but we were using these requirements as a blueprint for building a secure business across all information sources, not just [those making use of] the card data.

Like many businesses, a year ago, we weren't happy with the methods we used to inspect who really had access to data and database objects, or how that information was being used. We knew who our power users were -- the developers, DBAs, IT admins -- and could quickly gather information about them, but we felt that we needed stronger control processes. For example, we didn't really know if a developer with access to low privilege accounts was incorrectly elevated during a software release.

You can run a scanning tool like those from AppSec and, within just a few minutes, it's a revelation how many different ways a single power user can access data. For every well-known and understood route into a database, there is a forgotten legacy route, an undocumented test route, an emergency recovery route and previously unidentified nested privileges. And for all those routes into a production system, you've got all the same problems on your development, user acceptance testing and business continuity environments. How did you manage security beforehand, and what was the reason for you to select a database security product?
A big difference is the segregation of duties we have achieved with the appointment of a dedicated information security officer. Previously, many of the auditing activities were carried out within the team or department that was subject to the audit. Today we have a distinct separation; we can protect all the log files and audit information should any DBA find reason to be malicious. We haven't changed any of the intra-department auditing activity, however, since these processes are the best place to catch accidental problems. Instead, we've supplemented the DBAs with a second and independent layer of checks. And the introduction of database security tools also allows a non-DBA to audit database activity and permits them to flag something which may warrant closer inspection. Did you review any other products before choosing AppSec? Can you say which?
Yes, we had a shortlist of four other products. What was the reasoning for your decision to select AppSec for database security? Price, service, functionality? Did you look at reference sites and talk to other users?
From the outset, Application Security Inc. made an effort to listen to our needs before presuming to have the answer. And then, when they did demonstrate their products to us, they used realistic examples of just the type of thing we needed to see. It wasn't a case that their product could deliver everything we needed, but it addressed more of the key requirements than most other products we considered: user rights assignment, real time usage auditing, discovery and vulnerability scanning.

Furthermore, AppSec encouraged critique of the product and appeared genuinely keen to listen to our feedback for improvements or new features. We are already looking forward to a new integration of the AppDetective User Rights Review module, which promises to give us an easier interface for reporting and managing access control. What was the reason for you to select a database security product?
We have adopted a defence-in-depth strategy and the data is the kernel in the middle of the shell. The perimeter is well defined and easily protected with off-the-shelf products: firewalls, IPS, etc. Similarly, we have tools to monitor changes to the Active Directory groups, but we didn't know what those groups looked like in terms of access to data. We also had poor visibility of how the data was been accessed, for instance, should a mortgage advisor be running a query to return multiple customer details? Or why is the DBA accessing the database from an unknown IP address? A database security product can help an organisation understand and then protect these processes. How has DbProtect helped Think Money? Please give some information about the implementation.
The initial discovery and vulnerability process was the first important step towards developing a security improvement plan. Not until we had this information could we provide achievable price and time estimates for our PCI DSS projects. After this initial discovery phase, we used DbProtect to really get a grip on user access control, peeling back the various nested privileges and constructing a more rational segregation of duties through application of roles. We now have 'at-a-glance' assurance that our database infrastructure is compliant to the requirements defined by PCI DSS. We have immediate notice of any significant changes to the database and I can correlate this with software release and change control information to identify unauthorised changes.

The product continues to help us; for instance, last week we implemented a new audit that will record who is using the built-in "DecryptByKey" and "DecryptByCert" Transact-SQL functions. Then, once we were familiar with how the functions should be executed in normal behaviour, I was able to create alerts for anything suspicious, such as non-service accounts or out-of-hours execution.

We installed DbProtect into our test environment first, since the software needed the latest .NET components. The process was straightforward and without major incident. Installing the software is only the beginning; we have spent several weeks slowly increasing the number of network scans and the depth of vulnerability testing. We also ramp up real-time auditing on each database slowly so as not to take processing resource away from MS SQL. So far, DbProtect has shown a very small footprint.

As with all security products, you can very quickly become overwhelmed by data. In this regard, DbProtect is a little different and offers the usual presentation of information, namely pdf and spreadsheets. It does offer flexible and granular assignment of risk to both database activities and vulnerabilities, but it remains your task as an experienced Security Officer to understand how an activity or weakness can expose your particular organization. Has the implementation of a database security management product made your job any easier?
PCI DSS compliance defines a number of security controls on database access and maintenance including: end-to-end accountability of all access to card data, strong user access controls, managed change control, secure configurations and vulnerability testing. Without a database security, audit and compliance tool, we would need to employ at least one full-time DBA/security expert and that, of course, would introduce its own security problems [namely potential for error and rogue behaviour]. Looking back on your project, what advice would you give to another company with similar business requirements? Is there anything you would have done differently, given your experience?
Engage with your security teams early and plan security into the requirements and development stages. Every object definition should include security considerations such as owner, access rights and audit requirements from its conception. If it's too late for that, then you want to be very confident in your disaster recovery facilities before you plan to install .NET on a business critical server. .NET can be treacherous to work with. It is a complicated component framework that can be implicated in the delivery of many different software applications and even the operating system. Often this dependency is poorly documented by vendors so performing an upgrade never seems to be exactly the same twice. Before changing .NET, you must be confident in your rollback position if it turns for the worse.

Read more on Application security and coding requirements