Wednesday, October 04, 2006

Don’t Let Security be a Deterrent to DBA Outsourcing

If I got a dollar for each time an IT Manager in a medium-sized company says “we like the offering, but our security policies prevent us from outsourcing our database support…”, I would have hundreds of dollar bills stashed in my pockets! Most recently, I heard this from an experienced DBA Manager for a company in the entertainment industry. That made me wonder – many of the goliaths in the financial services industry, including large credit card processors, insurance providers and banks (with the notable exception of JP Morgan Chase that actually backsourced their IT services from IBM; see http://www.cio.com/archive/090105/whiplash.html?action=print) rely every day on outsourced IT services, so why is this a problem for a company in the entertainment business?

Maybe since the other organizations are much larger, they have the financial and professional clout to invest in the outsourcing relationship (or make the vendor pay for dedicated redundant leased lines, specialized staff, etc.) to get their security concerns addressed and it’s the small and medium sized businesses (SMB) that encounter this problem.

But regardless of company size, I just don’t believe that security should be a deterrent to outsourcing. If good security policies are followed by a company and enforced by the outsourcing partner, the company can avail all the benefits of outsourcing without fear of compromising security. The DBA outsourcing industry has matured to offer numerous advantages and some of the better known companies in this space seem committed to addressing their customers’ diverse security requirements.

In my experience, three primary areas come into play to ensure the outsourcing vendor is not going to jeopardize your environment:
· Confidentiality agreements.
· Secure environment for the outsourcer to log in and work, regardless of where they are working from (in-house, from their houses or from their remote office). Make key security requirements part of the overall service level agreement.
· A tamper-proof multi-level audit trail.

A good vendor will walk you through these in detail and usually, will bring these tools and templates with them.

In the case of the confidentiality agreements, look at the confidentiality clauses in your standard employment agreement that an in-house DBA (employee) would sign, and ensure that the vendor agreement is a super-set of that agreement. (After all, every company out there trusts certain employees sufficiently to let them access their mission-critical systems and data.)

In terms of providing a secure environment, larger companies with the financial resources may request for dedicated leased lines prior to commencing work. However most security issues can be kept at bay by following good security practices internally, auditing the vendor to ensure they have similar or better policies and having a good VPN solution with a key-fob for any remote access that may be necessary. When it comes to remote access, regardless of your outsourcing philosophy, you need good policies to allow even your internal personnel to work from their houses, especially during off-hours. Ask your vendor for their security policy manual. If required, hire a third-party security consultant (or use your internal sys/network admin, if you have one and if he/she is well-versed with infrastructural security requirements) to look for any gaps in their policies. (The following site has links to some real useful security-related publications pertaining to industry standards: http://www.csrc.nist.gov/publications/nistpubs.) Ensure the vendor agrees to address any significant gaps prior to commencing work. Once that is done, have an audit done at the vendor’s site to ensure they indeed implement everything they mention in their policy manual and all gaps have been dealt with.

If required, you could even segregate DBA work such that vendor personnel cannot access any raw data in the database. Any work that requires access to data can be routed through internal personnel/managers. In the case of certain databases (like Oracle), it is also possible to control this at a granular level by granting privileges to carry out physical DBA tasks (sysoper) without access to everything (sysdba) or specifically, user data within the database.

Lastly, a good audit trail needs to be maintained both within and outside the database (at the operating system and network level) so events such as login times, userids, etc. can be checked and correlated when required. Ideally, rather than just waiting for violations to show up and then investigating the root cause, it is advisable to set up events within the audit software to look for violation patterns and take appropriate automated actions including sending out alerts. For database-level auditing, there are multiple tools that accomplish various things – some of these do not even require native database auditing to be turned on. Depending on the tool, they sniff SQL statements over the network, latch on the shared memory and/or periodically capture database activity and alert on problem signatures. All of these are effective methods to keep an eye on your environment and ensure the vendor is complying with your policies.

In addition to these, if your business requires it, you can also make other requests of your outsourcing partner such as not to use offshore resources to work in your environment and so on. Experienced vendors would already be familiar with such requests and may have special packages to accommodate them (often at a premium; but that premium may be well worth it if the overall costs are still significant lower and at better quality than doing it yourself and to be able to sleep at night).

1 comment:

Anonymous said...

Who can help me with .httpaccess ?
where i can fined full information about .httpaccess file syntaxis?