Tag: security

  • Who’s Touching My Database

    Abstract:

    As databases become more critical to the operation of our organizations, we are being asked to audit and report on access to both data and the configuration of our systems. SQL Server has a number of features that can help you comprehensively audit your system, including SQL Audit, Extended Events and the default trace. Come learn how you can configure and incorporate detailed auditing into your reporting to management.

    Level: 200 – Should have some basic knowledge of SQL Server, database security, and T-SQL.

    Demos:

    • Using Logon Triggers
    • Looking at the default trace
    • Using SQL Audit to track logins
    • Using Extended Events to track logins
    • Checking permissions at the server and database level
    • Watching database activity using DML triggers
    • Watching database activity using SQL Audit
    • Watching database activity using Extended Events

    Downloads:

  • Coming Attacks

    The pieces by Bruce Schneier related to security are fascinating. One of his latest posts looks at potential coming attacks to our Internet infrastructure, which could potentially take down parts of the worldwide network. Whether you think this is a valid concern or not, it bears thinking through the issue a bit. If something did happen, your organization could be affected.

    Imagine what would happen to your production sites if they, or their clients, couldn’t resolve a DNS address. Or if there was a DDOS against your domain, perhaps just as a test by attackers to see where you might be vulnerable. What would be your response? For most of us, there isn’t much we could do, but I’m sure your management would want some answer, so do you have a way to respond? Would you worry if there were a targeted attack against your database servers using SQL Injection, cross site scripting, or some other technique?

    What about your development efforts? So many people have started to use services like Slack, Trello, cloud hosting of repositories and more. Could you continue to develop software if the Internet went down for your company? I’ve certainly thought about this for my work, and some things would be off-line, and I could have potential scheduling issues. However, I don’t work on mission critical systems, so I could work on something off-line and push production schedules by a day or two.

    Certainly control systems, embedded systems, and more are vulnerable to these types of attacks. If they depend on data, could they be attacked with fake or compromised data? I hope that some of these companies that have critical system, get serious about security in the event that an attack is targeted at their infrastructure. I don’t know if that will happen, and I really hope not. The Internet is a wonderful, collaborative resource, and will be for a long time if the criminals don’t fundamentally ruin our trust in it.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and Libsyn .

  • The Danger of xp_cmdshell

    Securing a computer is a challenge. There are all sorts of potential issues in every platform, and ensuring safety for your data can be less a reflection of your ability and more the good fortune there isn’t a focused effort to attack your systems. However, we certainly also face issues with inside users, many of which may make mistakes that are accidental more than malicious. It’s for these reasons that we look for secure by default applications and a reduced surface area for any system.

    Many people refuse to turn on xp_cmdshell as an option for scripting in SQL Server. This is disabled by default, and quite a few DBAs are glad of this setting. However, there are plenty of people that think xp_cmdshell isn’t a big security risk. There are certainly ways to mitigate the usage by non-privileged users, and this can be a tool that is very handy for accomplishing work without a lot of development time.

    This week, as security issues become more important to us all, I’m curious how you feel.

    Do you think xp_cmdshell is dangerous?

    I have to admit that I’m torn. I don’t think this inherently dangerous. It does open up some attack vectors, but the last few versions of SQL Server have allowed some limitations, so I would enable this if needed to solve some issues without too many concerns. However, I wonder if many of you feel the same way.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and Mevio .

  • Encryption Keys Matter

    Perhaps the importance of protecting encryption keys is even greater than we realize. It appears that the NSA and the US Government have been able to read encrypted traffic for some time on the Internet, perhaps for most of the last decade. There was an exploit in Cisco PIX routers, which I’ve used in many companies, that allowed the NSA to gain the encryption keys used by VPN traffic. In fact, it is likely the NSA could actually penetrate the networks on either end of the VPN with those keys.

    Some of you may be against back doors for governments in encryption products, and some of you may be for allowing governments access with legal protections. However, the most disturbing part of this for me is that no organization knew their communications, supposedly secure, were being intercepted and read. The nature of the digital world is that exploits can copy information without the holders of that information being aware of the effort. This is much harder with physical items, where the movement of an object from one person to the next is easily noticed.

    One of the very difficult things with protecting the data in our databases is trying to understand when someone has actually retreived information they shouldn’t. This is much more difficult than just tracking changes to data, which is more straightforward. We have auditing mechanisms that easily track changes to data, though most of us don’t have this set up or configured to catch all changes. In practice, that might be good enough to prevent data quality issues, but it doesn’t necessarily protect data from read disclosure.

    Monitoring what information is accessed is far harder than tracking changes. Do you know if someone in Sales is accessing a single row with customer details or the sensitive information for all customers? Can you tell when a request is legitimate for an application or if there’s an unusual query that might be seeking massive amount of data for download? Those are hard questions, and ones that I think can only be handled by a large amount of activity monitoring along with machine learning assistance to look for patterns in user activity. Other features like Row Level Security can help limit the inadvertent mistakes made by developers or users, but not necessarily prevent a single user, especially a malicious user, from querying information.

    Apart from the activity issues, we should ensure that where it is possible, we should be using encryption to prevent accidental disclosures outside of our applications. I think Always Encrypted has possibilities for the database, but the key management for this, as well as key management for VPNs, disk encryption, and other protection mechanisms, needs both more maturity and the open disclosure to prevent back doors from being included in products. We also need more maturity in our software development that takes the implementation and protection of encryption mechanisms seriously.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Mevio .