by Robert Buda | Jan 31, 2020 | Best Practices, Cloud, Database Security, Uncategorized
In response to the recent Capital One data breach, where a hacker exploited a misconfigured open-source Web Application Firewall hosted within Amazon Web Services (AWS), the Amazon CTO reminded customers that they must secure their own data when housed on AWS infrastructure.
This seems obvious, but it is a very important point.
When you move your data into AWS or any cloud provider, because it is not in our your data centers, and because you often no longer employ full-time people to manage the server hardware and software that house that data, you might get the feeling that someone else is managing our data just as carefully as our own staff once did.
That may be true for some dimensions of data management. For example, the cloud provider is responsible for making sure that the hardware stays up and running. Likewise, when you use software as a service (SaaS) or platform as a service (PaaS), the service provider is responsible for making sure that the application software and/or operating system stays up and running. In the case of infrastructure as a service (IaaS) offerings, the customer is still responsible for the latter two functions.
But in all the above cases, the customer is ultimately responsible for the security of their own data. The AWS security documentation describes it this way:
-
- Security of the cloud – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the AWS Compliance Programs. To learn about the compliance programs that apply to Amazon EC2, see AWS Services in Scope by Compliance Program.
- Security in the cloud – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations.
The key takeaway is that if you have your data in any cloud service, you must be as rigorous in securing that data as if it were in your own data center—and in some cases even more so.
Following are some key things to think about when moving your data into the cloud. These are the same considerations you need to focus on when keeping your data in-house. Some of these concerns only apply to IaaS in the cloud, while others are relevant to all cloud service scenarios.
-
- Is the underlying storage configured properly so that only the database software, application software and authorized users can access it?
- Is the data encrypted both at rest and in transit?
- Is proper authentication in place for the application or database, to ensure that only proper users can gain access to the system?
- Is proper authorization in place for the application or database, such that data is exposed only to the proper users?
- Is the network configured properly to reduce the surface area vulnerable to attack?
These considerations are not new. In fact, our Database Security Roadmap, initially created primarily with on-premises systems in mind, is still completely relevant with cloud technology.
Download the roadmap to make sure you have all the bases covered.
by Robert Buda | Nov 25, 2019 | Database Security, SQL Server
These days it’s only a matter of time before our firewalls or access controls are breached. Then what?
In a multi-tiered security strategy, data encryption is a critical next line of defense. Data encryption is also mandated by a number of widely applicable regulations, including PCI-DSS and GDPR.
Fortunately for SQL Server users, Microsoft has developed a range of capabilities that enable you to encrypt database files at rest, in transit, in backups, when being accessed and even “always.” This post will give you an overview the five types of encryption that SQL Server offers.
SSL Transport Encryption For Data In Transit
Similar to how web applications secure traffic between the server and the browser, you can configure SQL Server to use Secure Sockets Layer (SSL) to encrypt data in transit between the server and the client.
This capability is available across all supported versions and all editions of SQL Server. It’s a great way to thwart so-called “man in the middle”/proxy attacks because it makes network traffic almost impossible to read.
For more information, including how to install a certification a SQL Server to support SSL, see this Microsoft Support page.
Backup Encryption
SQL Server allows you to encrypt SQL backups at the whole file level. Available for both Standard and Enterprise editions in SQL Server 2014 and newer, this is a powerful security measure as it protects backups even at offsite locations.
This feature gives you a choice of encryption algorithms and can use either a certificate or asymmetric key. You can also use backup encryption and Transparent Data Encryption (TDE, see below) at the same time (but with separate certificates/keys).
For more information on implementing cell-level encryption, see this Microsoft Docs page.
Transparent Data Encryption (TDE)
Available since SQL Server 2008 for Enterprise editions only, TDE lets you encrypt SQL data “at rest” within the files on disk. This protects the physical media—including the entire database, log files and any backups or snapshots—from being read in the event of unauthorized access to the media. (Data in unencrypted files can be accessed simply by restoring the files to another server.)
TDE is “transparent” in the sense that no changes are required for client or server applications to use a TDE-encrypted database. When SQL Server mounts an encrypted data file, it uses a database encryption key (DEK) to decrypt the data during use and then re-encrypts it again before writing it back to the file. A limitation of this approach is that data encrypted with TDE is unencrypted and potentially vulnerable both in memory and over the network.
For more information on implementing TDE see this Microsoft Docs page.
Cell-Level Encryption
SQL Server’s Cell-Level Encryption lets you encrypt specific columns within a database that contain sensitive data; e.g., credit card numbers, social security numbers, passwords, etc. This feature is available in all SQL Server editions.
Unlike with TDE, when data encrypted with Cell-Level Encryption is selected in a query, it remains encrypted by default, even in memory. However, all it takes to decrypt it is a call to the decryptbykey function in the query. Further, the need to use a function call for decryption means code changes in existing applications and queries.
For more information on implementing cell-level encryption, see this Microsoft Docs page.
Always Encrypted
Always Encrypted is a new (since SQL Server 2016) way to do column-level encryption for client applications using up-to-date data libraries. Always Encrypted encrypts data transparently at the client via the data connection layer, with no code changes required (though it requires a driver on client systems).
Data thus secured remains encrypted in transit, in memory and at rest—making it the only option for securing data from misuse by even the most privileged SQL users, like sysadmins. This makes it a good choice for applications that require separation of data owners and managers.
However, since SQL Server isn’t doing the encrypting, many functions won’t work with this approach. In particular, you can’t sort, index, look for string fragments or do calculations on data that’s encrypted.
For more information on implementing cell-level encryption, see this Microsoft Docs page.
In Conclusion
Microsoft has a strong focus on security, and this is evident in the wide range of options available to SQL Server users. But every organization’s needs are different, and there is no one-size-fits-all approach to implementing SQL Server encryption. Your SQL Server version and licensing scenario, application requirements, business processes, performance needs, regulatory environment and security risk profile will all impact your path to implementing encryption.
For expert guidance on how best to implement encryption in your database environment, including help with configuration and key management, contact Buda Consulting.
by Robert Buda | Nov 14, 2019 | Best Practices, Database Security, Uncategorized
You are going away on a much-needed vacation to Aruba. You will only be gone for a week. But you understand the importance of security, so you make sure you lock the windows and doors. You put the lights on a timer so would-be thieves think there is some activity in the house. You cancel the newspaper so they won’t be piling up outside and you ask your neighbor to watch the house in case he sees anything unusual.
Before you leave, you go to the bedroom where you keep the safe. All of your important papers are in there, and that watch that Dad left you, and your wife’s favorite earrings. Oh, and that brooch from Grandma. Not really your wife’s style but she would never part with it because Grandma was her favorite.
The Complacency
You grab some cash and the passports out of the safe, and you start to lock it up… But whenever you close it up, it is always such a pain to remember the combination, and you have to turn that knob so many times before you get it right. Besides, you locked all the doors and windows, and you have your neighbor watching the house. The perimeter is secure. So is there really any need to lock the safe?
The Dog
You have made arrangements for your nephew Tommy to walk your yellow lab Miles while you are gone. Tommy is such a fine young man and always willing to help.
The Double Trouble
Tommy hits a double down the first base line the day after you leave and breaks his ankle sliding into second. Tommy asks his friend Joey to walk Miles for him, because it’s hard to walk a dog on crutches.
He hasn’t mentioned it to Tommy, but Joey has been losing at the poker table lately. He borrowed a couple of thousand from that guy Rocco down the street, and took it to the tables thinking his luck would turn around. But now he’s just deeper in debt, and he doesn’t know how he will ever pay back that much money.
The Loss
When Joey opens your front door with Tommy’s key, he walks in and sees the beautiful furnishings in your home. He walks upstairs and peeks in the bedroom. He sees the safe, walks over and tries the handle. He thinks “How lucky am I?” as the door swings open. Seeing all of the cash that you left in the safe, Joey thinks, “If this money was really important to them, they would have locked the safe.” After grabbing the cash, the brooch and the watch catch his eye and he can’t help himself. He grabs it all and closes the safe, not worrying for the moment what happens when you get home. At least he can get Rocco off his back.
The Lesson
Of course, you would never really do this! You would be crazy to leave valuables in an open safe just because you locked your windows and doors. You know that securing the perimeter is not good enough. Right?
But this is exactly what many IT groups are doing every day. They spend lots of time and money securing their network’s perimeter. But they neglect the security of the safe holding all of their jewels—the database.
By strongly securing the database (locking the safe), you can protect your data assets from bad actors who get through the perimeter security. This may be hackers who break things for fun, criminals intent on gathering data they can sell or exploit, or disgruntled employees who didn’t even have to break through the perimeter in the first place.
The Action Plan
Don’t leave your safe open! Your database has many vulnerabilities just waiting for a guy like Joey to find. Have a thorough security assessment performed today, take action, and make sure Joey goes home empty-handed.
by Robert Buda | Oct 29, 2019 | Best Practices, Database Patch News, database patching, Database Security, MySQL, Oracle, Oracle DBA, SQL Server, Uncategorized
Welcome to Database Patch News, Buda Consulting’s monthly newsletter of current patch information for Oracle and Microsoft SQL Server. Here you’ll find information on available patches—including security patches—and desupported versions made available during the past month.
Why should you care about patching vulnerabilities and bugs? Two big reasons:
- Unpatched systems are a top cyber attack target. Patch releases literally advertise vulnerabilities to the hacker community. The longer you wait to patch, the greater your security risk.
- Along with running a supported database version, applying the latest patches ensures that you can get support from the vendor in case of an issue. Patching also helps eliminate downtime and lost productivity associated with bugs.
Here are the latest patch updates for Oracle and SQL Server:
Oracle Patches:
Oct 15 2019 Quarterly Patch Updates:
19c – Release Update 19.5 available
18c – Release Update 18.8 available
12.2.0.1 – OCT 2019 RELEASE UPDATE 12.2.0.1.191015 available.
Regular support ends Mar 2023 and extended support ends Mar 2026.
12.1.0.2 – Currently in extended support.
The last freely available patch was July 2019 for 12.1.0.2. The Oct 15 2019 Patch Set Update (PSU) is available but may require extended support purchase to access it. Patches will be release until July 2021 for this version. PSU 12.1.0.2.191015 is available.
11.2.0.4 – Entered extended support in December 2017
The last free available patch was October 2018 for 11.2.0.4. PSU 11.2.0.4.191015 is available but may require clients purchase extended support to access it.
SQL Server Patches:
SQL Server 2017 incremental servicing model (ISM)
CU17 (Latest build)—Released October 08, 2019
SQL Server 2016 Service Pack 2
Release date: April 24, 2018
SQL Server 2014 Service Pack 3 Cumulative update 4
Release date: July 29, 2019
SQL Server 2014 Service Pack 2 Cumulative update 18
Release date: July 29, 2019
by Robert Buda | Mar 16, 2018 | Database Security
Shrink Your Sensitive Data Footprint
Protecting data is hard. Knowing for sure that you have identified and mitigated every vulnerability takes a lot of work and constant vigilance. The more servers you have to harden, the more databases you have to protect, the more work it is, and the more likely you will leave a hole somewhere. So it makes sense to reduce your sensitive data footprint as much as possible.
Data Masking
The concept of data masking has been around for a long time, but we have found that many companies don’t yet use it in their development environments. By having full production data sets in dev and QA environments, we needlessly expand our sensitive data footprint and add significant vulnerability.
Think about it, our development environments are the least protected of all of our systems, and they are the most exposed. Developers frequently have full access to all the data in the development environment, and even have the ability to extract data, typically loading subsets of it into their own, even less protected, systems, in order to do local development and testing. Many companies are now using cloud technology for development environments as well, which are outside of their corporate firewalls, adding even more risk.
This significant risk is relatively easily mitigated by masking all data in development and QA environments.
How it works
Typically, data masking vendors will have a tool that enables the discovery of sensitive data. Discovering this data is helpful even if you don’t plan to mask your data. The tools have default, expected, search patterns for sensitive data, and you can add your own as well if you feel that your system contains sensitive data that is not represented by the default patterns.
After discovering the data, you can specify a pattern or function that will be used to alter or obfuscate the data as it is stored in the database (or in the case of SQL Server, will alter it as it is extracted from the database). For example, you can choose to randomize the numbers within a phone number field in order to change the values but keep the formatting so development and testing can still be done using the data.
Data Masking offerings by Oracle and SQL Server
Oracle has a very robust Data Masking solution called Data Masking and Subsetting. It is not cheap but the cost is not significant compared to the costs associated with a data breach. And after you thoroughly mask the data, you no longer have to spend as much time and effort hardening the target environments, so the costs are further mitigated. It works by identifying and then masking data that will be placed into development environments. So the development environments never have the real data.
SQL server’s data masking offering, Dynamic Data Masking (DDM), masks data as it is retrieved by sql queries. This is less secure because the target databases do have the real data in them. Only users with unmask privileged users can view the real data but that does require additional security administration on the development environments. So while this is an improvement over having no masking, it is not as secure as using Oracle’s approach.
Third Party Data Masking Offerings
There are also third party tools for data masking such as DataVeil, which has a free version that includes some standard masking functions and a paid version that includes some more advanced masking functions. Data Veil works on both Oracle and SQL Server, as well as other databases.
Just Mask It
So the bottom line is that there are good options available for masking data in your development environments and doing so can significantly reduce your vulnerability to data leaks . With any of these tools, it will take a little work up front to discover and to determine the proper masking functions for the data, but once done, it can be re-applied easily each time you refresh your dev environments and it is definitely worth the effort.
If you know of any other great data masking tools please leave a comment. If you would like to chat about data masking or have any questions you can find us at www.budaconsulting.com.
