Internal Controls

  • Comments posted to this topic are about the item Internal Controls

  • In my current (and some of the previous) company we definitely have audit controls.
    Not in all systems (yet) but at least on the core ones.
    so every time someone retrieves a customer related record a log entry is added to a audit table on the system in question. 
    standard logging includes detail of the user querying the record (userid, workstation, datetime, application) as well as the primary key of the entity being viewed.
    And obviously any data change is also recorded in full detail (or nearly full in cases where some details are of no importance).

  • I would be curious to know from those who have audit controls whether they are something formally recognised and supported.  I know of DBAs who maintain a log of queries that are run against a particular system but more from the point of view of identifying opportunities to tune the DB. 
    GDPR dictates that we take all reasonable measures to keep data safe and that does include knowing who accesses PII data.  It is mandated in law.

  • Our company keeps an audit trail for particularly sensitive tables' read accesses, but the sheer size of logging every single read-access would quickly fill more hard drives than could physically fit on the planet! Especially if you wanted the logs kept for 7 years like other financial transaction data.

    A much more practical alternative would be a white list of access IP addresses that forbade access by anyone else. However, preventing that list from being altered by hackers (and/or having the logs erased by the same hackers) is still a deal breaker in absolute terms.

    Remember, the defense has to be perfect, the attacker only needs one flaw!

    Bureaucrats be damned, GDPR in literal terms is simply not possible. Their dreams of a digital panopticon are not only a nightmare for the rest of us, they're simply impossible because of the laws of physics. (Thank God).

    Now, I'm not saying companies shouldn't protect users data--but the best defense against any attack is not existing to be attacked in the first place. 🙂 

  • First, you need encryption, more encryption, and then encryption again. The guys who rack, stack, and backup the data don't need to decrypt (much less query) the databases at all. The developers don't need access to real data. The data analysts only need access to a narrow scope of data elements and subset of records depending on what project they are working on at the moment. Really, they should be working with aggregated data. Even in an organization as large and data centric as Twitter, there should be a relatively small and highly selective number of folks in IT who can actually query the full data profile on a specific individual, and these folks should be working with a special tool that uses auditing and restrictions, not an ad-hoc sql command prompt.

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

  • I think this is something that we should be looking at more and more. Some of this should be built in and made easy. For instance it should be possible to tell the SQL server to log every command issued. Of course that could create a glut of logs that are hard to comb through - but solving the problem of finding which commands you care about would become somewhat routine with practice in most cases.(This may be easy, but I am more developer than DBA)

    It has been many years, but I used to work with a group of doctor's offices and found their lack of logging on Electronic Medical Records rather shocking. Unless the record was marked sensitive there was no logging for simply looking. And they didn't seem to have any means of routing watching for actions. As we rolled the system out to many offices there was a cycle which was interesting. First they would give me permissions with trust that I would only use test accounts to test various functions. Then they would revoke all access. Then they would go back as the pain of making a medical person check became too great. Back and forth.

  • Perhaps the data science teams at companies like Twitter and FaceBook should turn their analytical skills inward and start asking questions like: "Why is employee #2922 suddenly interested in querying profile data about Saudi Arabian journalists?".

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

Viewing 7 posts - 1 through 6 (of 6 total)

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