Voice of the DBA

Tag: security

  • Do You Need A Safe Word?

    Should we implement "safe words"?

    I read this Forbes piece on the hacker “Kayla”, which led me to this correspondence posted when she (or he) hacked HBGary Federal. The transcript of emails is rather amazing  and a little scary. She manages to get access to the servers through a clever bit of social engineering against a security specialist.

    The whole plot depends on access to a person’s email account, but that’s entirely possible. Imagine creating a distraction and then stealing a target’s smartphone. Done cleverly, a busy executive or IT worker might think they lost the phone and spend time trying to track it down. Meanwhile a hacker has access to their email, sending who knows what messages out.

    As system administrators, or anyone with privileged access to systems or data, should we assume that an email request from a person for a password reset, or an access request to additional privileges is genuine? My thought is that we might not want to “trust” these systems and instead, implement some other type of verification method along with this trusted access. Perhaps we ought to call the person and verify the request if we know their voice, or require them to present their request in person. At one place I worked, we used to require someone to personally come to the IT office unless we were sure we knew that person’s voice. That’s not a perfect solution, but it could help increase security.

    Maybe we need a safe word for each privileged account. It could be a word we request from the user when they ask, or maybe it is an uncommon word that has to be worked into the request to help verify the end user’s identity. Ideally we would just feed the message into some system that would authenticate it, rather than allowing a technician to manually verify the safe word from some store of words.

    Security is hard, but and none of my suggestions is perfect, but as there are more and more script kiddies, hackers, and social engineering professionals, perhaps a little paranoia is a good thing. Perhaps making it hard to gain addition access, especially privileged access, is a good idea.

    Steve Jones

    The Voice of the DBA Podcasts

  • DBA Concerns

    Security is everywhere, or is it?

    I ran across a survey of Oracle DBAs that examined their concerns about security that I found it very interesting. Considering how much data from companies and governments supposedly resides in Oracle databases, it’s shocking to see how large a percentage of the DBAs don’t know or understand what security measures are being used in some cases. It’s also surprising to see that so many of the threats these DBAs perceive are internal threats or problems with a lack of some sort of process.

    It makes me wonder if a survey of SQL Server DBAs would be any different.

    My guess is that it would not. SQL Server would have a good percentage of people that don’t encrypt data, a good percentage that don’t apply patches or don’t know what processes are being used to secure and protect data. I would expect that a lack of process, lack of priority from management, and other internal threats would be concerns as well.

    As DBAs, I think that the integrity of the data we deal with is paramount. We must comply to our own version of the ACID principles for databases by ensuring that data is secure, available, intact, and recoverable in the event of a disaster. If we cannot guarantee the safety of the data, we aren’t very good custodians.

    The best data professionals I know leave nothing to chance. They don’t depend on their own skills or memory. They implement a process everywhere they can, and automate these processes as much as possible to ensure they are followed. As you learn how your environment should function, use code to assure yourself that the processes are followed. Then use other tools available to verify those processes are actually running correctly.

    The best DBAs aren’t necessarily smarter, or more talented than anyone else. They’re often just more methodical and focused, ensuring that the work that needs to be done, gets done. Usually by coding the server to handle most things on its own.

    Steve Jones

    The Voice of the DBA Podcasts

  • SQL Server Truncate Table Permissions

    I saw a note recently where someone asked what permissions were needed for a user to execute TRUNCATE TABLE. In previous versions we needed ownership of the table or DBO level permissions. I had thought this was changed in SQL 2005 to require just the CONTROL permission.

    However when I checked the TRUNCATE Books Online page, I found this: The minimum permission required is ALTER on table_name. TRUNCATE TABLE permissions default to the table owner, members of the sysadmin fixed server role, and the db_owner and db_ddladmin fixed database roles, and are not transferable. However, you can incorporate the TRUNCATE TABLE statement within a module, such as a stored procedure, and grant appropriate permissions to the module using the EXECUTE AS clause.

    Alter permissions is the minimum?!?!!?

    That sounded fishy, so I did this. First I created a new user, with no permissions other than public. My user was, appropriately, MyTestUser.

    Next I created a table and granted permissions:

    CREATE TABLE TRLC 
(
  est_no varchar(10) default ' '
, right_no int default 0
)
GO

INSERT TRLC SELECT 'Test', 1

GRANT CONTROL ON TRLC TO MyTestUser

    I then opened up another Query Window and changed the connection to use MyTestUser. This user only had CONTROL permissions and nothing else. A quick test showed that this user could indeed clear out the table. This:

    TRUNCATE TABLE dbo.TRLC

    executed without error.

    I think Books Online needs an update, and I’ll submit a note to that team to clarify this.

  • Bad IT People

    Know Your Enemy – A tenet of IT Security

    It’s going to happen. Someone, somewhere, is going to deliberately compromise security and abuse their position as an administrator. Hopefully it doesn’t happen at your company, but the longer you are in IT, the better chance you have of being around when a “security DR event” occurs.

    This article talks about IT people going bad, and it happens more often than we hear about. Many companies don’t want to disclose these types of events, and it’s possible one happened in your organization already.

    This is nothing new. In every industry in which I’ve worked there have been people that take advantage of loopholes in systems and processes to engage in criminal activity. I have had liquor stolen from bars and lumber from a warehouse. We can’t prevent all of these activities, and companies know this. Usually there is a line in your accounting system that marks these losses as some cost of doing business.

    As with many external hacking issues, companies are likely to try and prevent anyone from finding out about these activities outside of the company. That’s not a great solution for anyone, since often these employees are let go and hired by the next company who has no idea what the person they just hired has done.

    You shouldn’t participate in these activities, and you ought to turn in those that do. However I know many people find that harder to do when confronted by this situation. At the very least, if you turn a blind eye, don’t help prolong a bad IT person’s career in this business. Don’t give them any sort of recommendation, and don’t include them in your personal network in any way.

    Steve Jones

    The Voice of the DBA Podcasts