Disconnecting Auditing

  • Comments posted to this topic are about the item Disconnecting Auditing

  • If I was starting from a blank state with structures of organisations - I'd generally tend towards divisional setups with depending on the amount of work DBAs tied to individual divisions. I would also put a DBA in the audit section who was not only tasked with monitoring fraudulent wreckless or incompetent database management but also spreading good practice and monitoring backups.

    I would hope the slight tension between the audit dba and the section dbas would encourage enough competition to maintain good corporate governance going forward.

    I'm not a great fan of limiting network privileges except for the most personal of data I think any improvement on perceived security is at the expense of flexibility and efficient management which in the long term leads to ignorance and incompetence which can be just as expensive as fraud.

  • I totally agree that there needs to be a complete disconnect between audit repositories and the IT administration privileges. Perhaps auditing repositories should be read only bins of data that should be able to archive data but only if you jump through hoops to do it (the equivalent of the two key launch system - no I have never seen this in real life but I am using it only as a simple metaphor for a multiple person task).

    Perhaps it would be best if there was a standard which could enable the configuring by administrators but as soon as it is configured, there is no way to alter the configuration without the change being audited. It could be based on open standards with plugins available for systems such as SQL Server or generic modules (in the .NET world, assemblies) for bespoke applications. There is also a place for dummy audit repositories for development environments.

    In the end, you want IT to be able to deploy, maintain and configure the whole IT system, however, this is one area where ideally IT cannot control the data.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • A DBA doesn't necessarily need to be a local admin on the Windows server, and depending on their daily responsibilities, a DBA doesn't need to be a member of the sysadmin role in SQL Server either. For example, there are special server level roles for things like managing backups, bulk loading, or creating databases.

    Just for piece of mind, one solution would be to have an external process running on another server (for which the SQL Server admin has no control), that pings the SQL Server instance every couple of minutes, checking the status of the audit trace, running a delta check on server options and permissions, and also pulling across a copy of the audit log.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

  • In larger organizations that might work. However in the US, most companies are too small to do this, if for no other reason than they don't want to spend the money.

    Dave

  • djackson 22568 (8/18/2014)


    In larger organizations that might work. However in the US, most companies are too small to do this, if for no other reason than they don't want to spend the money.

    All entities should analyze the risk of an insecurity and evaluate the costs accordingly.

  • Gary Varga (8/18/2014)


    (the equivalent of the two key launch system - no I have never seen this in real life but I am using it only as a simple metaphor for a multiple person task).

    The term you are looking for is two person integrity, TPI. TPI provides substantial security because, while you might find a crook anywhere, the likelihood of finding two crooks in the exact same location are miniscule. TPI systems are commonplace.

  • GeorgeCopeland (8/18/2014)


    Gary Varga (8/18/2014)


    (the equivalent of the two key launch system - no I have never seen this in real life but I am using it only as a simple metaphor for a multiple person task).

    The term you are looking for is two person integrity, TPI. TPI provides substantial security because, while you might find a crook anywhere, the likelihood of finding two crooks in the exact same location are miniscule. TPI systems are commonplace.

    Thanks George.

    TPI systems should be the only way to modify audit data. All audit alterations, including configuration changes and removal should only occur after the attempt has been confirmed as audited.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • GeorgeCopeland (8/18/2014)


    djackson 22568 (8/18/2014)


    In larger organizations that might work. However in the US, most companies are too small to do this, if for no other reason than they don't want to spend the money.

    All entities should analyze the risk of an insecurity and evaluate the costs accordingly.

    Should? Yes. Read my point about not wanting to spend the money.

    Dave

  • We actually have a dedicated auditing team. Audits are pulled for every system on a routine basis and the team reviews them, independent of the users and the admins. That said, we are a government organization dealing with classified information, so the requirement for all this is spelled out in regulations. i.e. we don't have a choice but to do it this way.

  • djackson 22568 (8/18/2014)


    Should? Yes. Read my point about not wanting to spend the money.

    My point is that their want might be different if they understand the risks they are running.

  • GeorgeCopeland (8/19/2014)


    djackson 22568 (8/18/2014)


    Should? Yes. Read my point about not wanting to spend the money.

    My point is that their want might be different if they understand the risks they are running.

    I would hope so, but too many businesses decide differently. Target ABSOLUTELY KNEW they had an issue and chose sales over safety! They are just one example.

    Dave

  • I envision the role of an Auditor DBA, where they have rights on the Audit Objects and that's all. Regular DBA's are denied access to the Audit system. It's a perfect use case for User Defined Server Roles. But the biggest problem is education. Most of the auditor/security professionals I have run across know next to nothing about SQL Server. And the point was also brought up about smaller organizations not having the resources for proper Separation of Duties. I agree that is a problem for which there may not be a solution.

  • Craig Purnell (8/21/2014)


    Most of the auditor/security professionals I have run across know next to nothing about SQL Server.

    SQL Server is a well known and obvious point of attack. There is no excuse for such ignorance.

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply