This discussion is archived
1 2 Previous Next 23 Replies Latest reply: Feb 25, 2013 11:52 PM by User477708-OC Go to original post RSS
  • 15. Re: Auditing DBAs
    EdStevens Guru
    Currently Being Moderated
    yxes2013 wrote:
    Hi all,
    <snip>

    I would not have revealed the nature of the data on a public forum. That in itself poses a security breach because you have now notified the world that you work on a system that would be very much worth hacking. If I worked for an organization that had a vested interest in your data, I would at this very moment be pulling out all the stops to backtrack your account and discover who you are and who you work for.

    You are worried about your DBA's but you yourself are a security risk.

    Think it can't happen? Several years ago I was involved in a discussion on comp.databases.oracle.server and someone seeking help with a connection problem posted his tnsnames without redacting the server name, which indicated he worked for the US military. I called him out on it and his reply was that it wasn't important and besides, he was behind a firewall, so no one could reach his system. That was like throwing red meat to the wolves and within 24 hours another participant posted the evidence that he had, indeed, breached the system. You can read the entire exchange [url http://groups.google.com/groups?hl=en&lr=&threadm=3D2D915D.52845DF3%40d2mail.de&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26q%3D.mil%26btnG%3DSearch%26meta%3Dgroup%253Dcomp.databases.oracle.server]here

    I want to protect the information from the DBA themselves or the developers, as they are the ones who have direct access on the table.
    Can you share me some of your experience or your processes that involves protection of critical info from users who have powerful privileges themselves?
    I see docs like auditing the audit table. But i want some actual process being used in production.


    Thanks a lot,

    zxy
  • 16. Re: Auditing DBAs
    EdStevens Guru
    Currently Being Moderated
    yxes2013 wrote:
    I thank you all :) ...so what I can do is trust the DBAs themselves. What if they were paid 1Milllion USD just to tag the blacklist as cleared, then when the blacklist was able to leave/enter the ports
    the DBA then return the tag to active so nothing has changed.
    that's one reason why when dealing with this kind of information you vet your staff very carefully and require the proper security clearance.
  • 17. Re: Auditing DBAs
    User477708-OC Journeyer
    Currently Being Moderated
    EdStevens wrote:
    yxes2013 wrote:
    I thank you all :) ...so what I can do is trust the DBAs themselves. What if they were paid 1Milllion USD just to tag the blacklist as cleared, then when the blacklist was able to leave/enter the ports
    the DBA then return the tag to active so nothing has changed.
    that's one reason why when dealing with this kind of information you vet your staff very carefully and require the proper security clearance.
    You have to trust the DBAs but also audit everything they do so while they have access to the data, so they can take if they want but someone else will know about it.

    Also
    1. I think you are not serious, there is no way anyone would publish the info you did online (although the above famous TNS case might prove me wrong there)
    2. The DBAs would have had to have security clearance to work there in which case theyre cleared for the data. If theyre not, they cant work there
    3. You have zero Oracle knowledge, why are you looking to implement anything, how can you verify it is correctly? you would need a DBA to put in correctly.
    4. If any of your seniors seen you posted what you did, and its real, do not expect to be in security work for much longer.
  • 18. Re: Auditing DBAs
    EdStevens Guru
    Currently Being Moderated
    961469 wrote:
    EdStevens wrote:
    yxes2013 wrote:
    I thank you all :) ...so what I can do is trust the DBAs themselves. What if they were paid 1Milllion USD just to tag the blacklist as cleared, then when the blacklist was able to leave/enter the ports
    the DBA then return the tag to active so nothing has changed.
    that's one reason why when dealing with this kind of information you vet your staff very carefully and require the proper security clearance.
    You have to trust the DBAs but also audit everything they do so while they have access to the data, so they can take if they want but someone else will know about it.

    Also
    1. I think you are not serious, there is no way anyone would publish the info you did online (although the above famous TNS case might prove me wrong there)
    2. The DBAs would have had to have security clearance to work there in which case theyre cleared for the data. If theyre not, they cant work there
    3. You have zero Oracle knowledge, why are you looking to implement anything, how can you verify it is correctly? you would need a DBA to put in correctly.
    4. If any of your seniors seen you posted what you did, and its real, do not expect to be in security work for much longer.
    I trust the above was directed to the OP in spite of the fact it was posted as a reply to me.
  • 19. Re: Auditing DBAs
    marksmithusa Journeyer
    Currently Being Moderated
    I hope the OP is using poetic license or using the TSA as an example of a critically secure system. I very much hope so. For one thing, if the OP WAS on such a critical database, they would have had it beaten into them that no mention of their work could be made public. Not only that, they would not be allowed outside access to this forum and they wouldn't be able to suggest to anyone that their position was a DBA, etc.

    As far as the original question goes:

    There is an element of trusting the DBA - if you don't trust the DBA with your data, why did you hire them? For the majority of systems, they have complete access to all the data. Obviously, data with national security implications, a DBA shouldn't expect anything except a 'trust but verify' or 'no lone zone' setup.

    Oracle has a couple of cost options which will allow to prevent the 'System DBA' from accessing certain data and/or accessing the auditing (Data Vault/Audit Vault). By configuring this, you are separating the role of the DBA and the 'Security Admin' whose purpose is to make sure the 'System DBA' cannot access or alter sensitive data.

    Of course, then you have to worry about who watches the new watchers (the 'Security Admin')? It's an endless circle and there isn't an easy answer to it.

    Mark
  • 20. Re: Auditing DBAs
    marksmithusa Journeyer
    Currently Being Moderated
    EdStevens wrote:
    Think it can't happen? Several years ago I was involved in a discussion on comp.databases.oracle.server and someone seeking help with a connection problem posted his tnsnames without redacting the server name, which indicated he worked for the US military. I called him out on it and his reply was that it wasn't important and besides, he was behind a firewall, so no one could reach his system. That was like throwing red meat to the wolves and within 24 hours another participant posted the evidence that he had, indeed, breached the system. You can read the entire exchange [url http://groups.google.com/groups?hl=en&lr=&threadm=3D2D915D.52845DF3%40d2mail.de&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26q%3D.mil%26btnG%3DSearch%26meta%3Dgroup%253Dcomp.databases.oracle.server]here
    This is just horrifying.
  • 21. Re: Auditing DBAs
    EdStevens Guru
    Currently Being Moderated
    marksmithusa wrote:
    I hope the OP is using poetic license or using the TSA as an example of a critically secure system.
    I hadn't considered the 'poetic license' angle. I certainly hope that was it.
    I very much hope so. For one thing, if the OP WAS on such a critical database, they would have had it beaten into them that no mention of their work could be made public. Not only that, they would not be allowed outside access to this forum and they wouldn't be able to suggest to anyone that their position was a DBA, etc.

    As far as the original question goes:

    There is an element of trusting the DBA - if you don't trust the DBA with your data, why did you hire them? For the majority of systems, they have complete access to all the data. Obviously, data with national security implications, a DBA shouldn't expect anything except a 'trust but verify' or 'no lone zone' setup.

    Oracle has a couple of cost options which will allow to prevent the 'System DBA' from accessing certain data and/or accessing the auditing (Data Vault/Audit Vault). By configuring this, you are separating the role of the DBA and the 'Security Admin' whose purpose is to make sure the 'System DBA' cannot access or alter sensitive data.

    Of course, then you have to worry about who watches the new watchers (the 'Security Admin')? It's an endless circle and there isn't an easy answer to it.
    That's always been why I look askew at Oracle's security tools to isolate even the the access of the DBA. True, they fill a legitimate need, but it would take a much more disciplined organization than any I've seen to implement it in such a way as to actually fulfill the requriement. Otherwise it falls back on the DBA to configure the tools that are supposed to lock him out. Kind of like giving a prisoner the key to his own cell ... "Hey, Ed, due to our security requirements, we have to hide certain data from you. We've bought this Oracle add-on to do that. Can you set it up for us?"

    ;-)
    Mark
  • 22. Re: Auditing DBAs
    marksmithusa Journeyer
    Currently Being Moderated
    EdStevens wrote:

    That's always been why I look askew at Oracle's security tools to isolate even the the access of the DBA. True, they fill a legitimate need, but it would take a much more disciplined organization than any I've seen to implement it in such a way as to actually fulfill the requriement. Otherwise it falls back on the DBA to configure the tools that are supposed to lock him out. Kind of like giving a prisoner the key to his own cell ... "Hey, Ed, due to our security requirements, we have to hide certain data from you. We've bought this Oracle add-on to do that. Can you set it up for us?"
    Well, yeah. Not only is it a cost option, you have to have DBA skills to implement it. Basically, Oracle are suggesting you pay for extra DBAs to act as 'Security Admins' AND the extra licensing. I'm sure that happens in this economy! Can you imagine how bored the Security Admin DBAs are?

    Or, just like at all the business I've seen it implemented, the DBAs are entrusted to wear both hats. 'Mark, you'll not look at this data, right?'. 'Nope. I'm too busy to look at that data, that's someone else's problem'

    I think I speak for most DBAs in saying that I try my best not to care what the data is, just as long as whoever should be able to is able to access it in a safe and performant manner. If you start thinking 'wow, if I make a typo here, 3m people won't get their SS payments today', it can completely screw with your head. If it's a Production system, then it has Production data. End of.
  • 23. Re: Auditing DBAs
    User477708-OC Journeyer
    Currently Being Moderated
    Ed: yes, aimed at OP.

    I was looking for a term to describe the initial story and if not serious how it may have been embellished and "poetic licence " is as good as any.
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points