Are you someone (A DBA, Developer, etc) that connects to SQL Server to use data? You probably hear a lot about how protected your database can be when at rest. But what about when you connect to SQL and start running some queries? Using a simple hacking technique we will dig into some packets on our network and see what's in them. You may be shocked! Then we will create a self-signed SSL certificate, use it to encrypt our connections on the SQL Server, and see the actual changes in the packet as hackers would.
Demo scripts and processes not included in great detail with the slide deck. Some presentation notes are included.
4. How safe is your data?
Hacking / Cracking
• Modifying computer hardware or software
• Accomplish goals outside of original purpose
Measures taken to protect your data
• Primarily at rest
• In motion over the network
• Not always the case
5. Easy to get tools
RawCap
• Command line tool
• Run from USB
• Captures packets into a file for reference later
WireShark
• GUI
• Captures packets as well
• Reads other capture files
Lots of others out there
8. SSL
Definition
• Secure Socket Layer
• Standard security technology
• Provide communication security over network
• Encrypts data flowing between parties
• Primarily prevent eavesdropping and tampering
9. How SSL Works
1. Client attempts to connect to server
2. Server send client copy of certificate
3. Client confirms trust
4. Server sends back acknowledgement to start SSL
Session
5. Encrypted data shared between client and server
11. Secure Your SQL Server
Connection
1. Create / Obtain SSL Certificate
2. Grant permissions to use certificate
3. Enable SSL in SQL Server
4. Connect
13. No single solution
Data in motion
• SSL – encrypt connections
• File encryption tools
Data at rest
• TDE
• Column level encryption
14. Review
By default connections are not encrypted
• Need to setup SSL (self signed minimum)
• Requires restart
• Encrypts data being transmitted
No one solution
• Protect data in transit
• Protect data at rest
• Separation of duties
Regular SQL Server setup
No encrypted connections setup
No network encryption setup
Show 3 connections
1) SSMS login and simple query
2) capture with rawcap – view with wireshark
3) show values in plain text sent & returned
4) Use Excel – establish connection and don’t even put data in spreadsheet – show values
5) back to SSMS – connect and pull an encrypted value through – once without key open, once with key open
Purchased from certificate authority
Research companies, check references, assured identity
Encrypt a message with the server's public key (encrypt only), send it, and if the server can tell you what it originally said, it just proved that it got the private key without revealing the key.
Process –
Client attempts to connect to server (server has private key and personal certificate)
Server sends client copy of certificate
Client checks that it is trusted, if so confirm back to server with message encrypted by public key
Server sends back a digitally signed acknowledgement decrypted by private key to start SSL encrypted session
Encrypted data shared between client and server.
Connec tto woxemo vm machine
Show IIS self signed certificate creation process
Grant permission to SQL Service account to use certificate
Set certificate and restart SQL
Set enforce encryption in protocol to ‘yes’
Connect and sniff packets as in previous demo to see if now protected
Show how turning the yes to no in enforce means that it is optional, not by default.
Yes ensured the connection has to be encrypted
You can’t just protect data at rest, nor can you just protect data in motion.
Primary focus of many places is data in motion
Anthem stated: Our state of the art system protected the data – in motion – they did not encrypt it when at rest. All plain text.
Because HIPAA said they didn’t have to.
Think about that. A large company with private information decided on minimal compliance rather than minimal risk.