Posts Tagged ‘PCI DSS’

The Death of SSL?

Posted: April 29, 2015 by Virendra Yaduvanshi in Database Administrator
Tags: , , , , , , , , ,
0

A vulnerability discovered recently could prove to be the final nail in SSL’s (Secure Socket Layer) coffin. The latest vulnerability to hit SSL, called ‘Factoring attack on RSA-EXPORT Keys’ (or FREAK), is claims to breach as many as 36 percent of all websites trusted by browsers. According to reports, several highly ranked websites, including the likes of FBI and NSA, are vulnerable to the flaw. Microsoft has confirmed that all versions of Windows, which have the implementation of SSL/TLS, are vulnerable to FREAK. This implies that if an enterprise is using Windows operating system, an attack on the network can force all software that uses the Windows Secure Channel component to install weak encryption on the Internet. Although widely adopted, SSL has had a chequered history. Discovered as a means to enable secure transmission between two points, SSL was quickly adopted by the industry to ensure secure data transmission. However, SSL was continually bogged down by vulnerabilities. SSL 2.0 was open to length extension attacks, had no protection for the handshake, and was vulnerable to truncation attacks. When 2.0 version gave way to SSL 3.0 that too had several flaws. In October 2014, researchers from Google identified a flaw in the design of SSL 3.0, which exposed it to a padding attack. Called POODLE, (an acronym for Padding Oracle on Downgraded Legacy Encryption), the attack required only 256 SSL requests to disclose one byte of encrypted information. It was also at the receiving end of Heart bleed bug. Given the large number of flaws in SSL, the PCI SSC (Payment Card Industry Security Standards Council) recently came out with a special bulletin that called for imminent amendments to the PA-DSS (Payment Application Data Security Standard) and PCI DSS (Payment Card Industry Data Security Standard). The bulleting warned the payment card industry members that SSL could no longer be relied upon for data protection. To overcome the shortcomings of SSL, a new protocol called Transport Layer Security (TLS) has come to the fore. Based on open standard, it is not only more extensible but also ensures support in the future. Also, TLS is scalable enough to secure connections on client’s side that have only SSL. The bottom line is that enterprise information technology practitioners can no longer bank on SSL 3.0 for ensuring privacy and protection of your data. It is time you ensured that your websites and browsers moved away from SSL to leverage more modern and state-of-the art security protocols like TLS. Meanwhile, to counter FREAK, OpenSSL has published a patch. Other vendors too are in the midst of issuing patches for plugging the vulnerability.

Source : ITNEXT

SQL Server HARDENING best practices after Installation

Posted: February 6, 2015 by Virendra Yaduvanshi in Database Administrator
Tags: , , , , , , , ,
1

Hi Guys, Now days Payment Card Industry Data Security Standards (PCI DSS) is a preventative standard intended to reduce the risk of payment card fraud and information theft. As per my views after SQL server installation on Production Box, I hope below settings should be set using SP_CONFIGURE as,

  • The ‘Ad Hoc Distributed Queries’ Server Configuration Option should be set to ‘0’
  • The ‘CLR Enabled’ Server Configuration Option should be set to ‘0’
  • The ‘Cross DB Ownership Chaining’ Server Configuration Option should be set to ‘0’
  • The ‘Database Mail XPs’ Server Configuration Option should be set to ‘0’.
  • The ‘Ole Automation Procedures’ Server Configuration Option should be set to ‘0’
  • The ‘Remote Access’ Server Configuration Option should be set to ‘0’
  • The ‘Remote Admin Connections’ Server Configuration Option should be set to ‘0’.
  • The ‘Scan For Startup Procs’ Server Configuration Option should be set to ‘0’.
  • The ‘SQL Mail XPs’ Server Configuration Option should be set to ‘0’
  • The ‘Trustworthy’ Database Property should be set to Off
  • Unnecessary SQL Server Protocols should be disabled.
  • SQL Server should be configured to use non-standard ports
  • The ‘Hide Instance’ option should be set to ‘Yes’ for production SQL Server instances.
  • Non-clustered SQL Server instances within production environments should be

    designated as hidden to prevent advertisement by the SQL Server Browser service.

  • The ‘sa’ login account should be disabled or renamed.

Extended Stored Procedures

The following extended stored procedures should not be used by any application or maintenance script.

  • Execute on ‘xp_availablemedia’ to PUBLIC should be revoked.
  • The ‘xp_cmdshell’ option should be set to disabled
  • Execute on ‘xp_dirtree’ to PUBLIC should be revoked.
  • Execute on ‘xp_enumgroups’ to PUBLIC should be revoked.
  • Execute on ‘xp_fixeddrives’ to PUBLIC should be revoked.
  • Execute on ‘xp_servicecontrol’ to PUBLIC should be revoked.
  • Execute on ‘xp_subdirs’ set to PUBLIC should be revoked.
  • Execute on ‘xp_regaddmultistring’ to PUBLIC should be revoked.
  • Execute on ‘xp_regdeletekey’ to PUBLIC should be revoked.
  • Execute on ‘xp_regdeletevalue’ to PUBLIC should be revoked
  • Execute on ‘xp_regenumvalues’ to PUBLIC should be revoked.
  • Execute on ‘xp_regremovemultistring’ to PUBLIC should be revoked
  • Execute on ‘xp_regwrite’ to PUBLIC should be revoked
  • Execute on ‘xp_regread’ to PUBLIC should be revoked.

Authentication and Authorization

  • The ‘Server Authentication’ Property should be set to Windows Authentication mode
  • CONNECT permissions on the ‘guest user’ should be revoked within all SQL Server databases excluding the master, msdb and tempdb

  • Orphaned Users should be dropped from SQL Server database. A database user for which the corresponding SQL Server login is undefined or is incorrectly defined on a server instance cannot log in to the instance and is referred to as orphaned and should be removed.

Password Policies

  • The ‘MUST_CHANGE’ Option should be set to ‘ON’ for all SQL authenticated logins
  • The ‘CHECK_EXPIRATION’ Option should be set to ‘ON’ for all SQL authenticated logins within the ‘Sysadmin’ Role

  • The ‘CHECK_POLICY’ Option should be set to ‘ON’ for all SQL authenticated logins

  • Auditing and Logging
  • The ‘Maximum number of error log files’ setting should be set to greater than or equal to 12.
  • The ‘Default Trace Enabled’ Server Configuration option should be set to 1.
  • ‘Login Auditing’ to both failed and successful logins

 

Thanks for Reading, Keep smiling, keep learning

Top Tips to Maintain the Security of Database Environment

Posted: December 5, 2014 by Virendra Yaduvanshi in Database Administrator
Tags: , , , , ,
0

It’s very difficult to be confident about the security of database environment? Because databases may contain sensitive or regulated information, critical applications or stored functions, ensuring database security is undoubtedly a number one priority. And with a number of users viewing and accessing the data, how about all those “who-what-when-where” details that might be hidden from your radar?

The increasing pressure of compliance regulations and security policies makes the deployment of high-level database protection a must-have for any organization. However, it’s generally observed, in almost 90% of cases, unnoticed changes to database configurations result in outages and security breaches.

For those looking for ways to advance database security, here are 5 SQL Server best practices to maintain database security and streamline compliance.

Tip 1: Minimize SQL server exposure and do not leave any “open doors”

We can take the first step to minimize security risks for SQL Server even before your installation is complete and fully configured. Install only required components. In the first place, when configuring your installation, remember the principle of least privilege. Running SQL Server services under an account with local Windows administrative privileges is not a good idea. In case a violator gains possession of such an account with extended privileges, the probability of unwanted outcomes increases. The risk of overall exposure can be minimized if you use a domain account with minimum required privileges instead.

It stands to reason to avoid using the default settings. Rename or disable the default system account for server administration after installation. The same is applicable to naming SQL Server instances instead of using the default instances. Changing the SQL Server port number, which is 1433 by default, will also help you minimize service and data exposure, and so will hiding SQL Server instances and/or disabling the SQL Server Browser service.

Also, do not leave anything unattended. Disable and remove everything which do not use, any unnecessary services or databases from production servers, for example, and sample or test data we may have used to verify successful installation.

Tip 2: Control who can access SQL server and how

When thinking about a user and service accounts authentication, be mindful of establishing user accountability and avoid misuse of privileged accounts. When we can choose between integrated (Windows) authentication and built-in SQL Server authentication, choose the first option whenever it is possible. Integrated authentication encrypts messages to validate users, while built-in authentication passes SQL Server logins and passwords across the network and keeps them unprotected. If you have to use built-in SQL Server authentication for application compatibility, make sure you have ensured a strong password policy.

Again, never use shared user accounts for administrators. A SQL Server administrators should have dedicated accounts with no administrative privileges in other systems. Also, make sure that each admin is using a personal user account. The same recommendation works for applications. Creating separate service accounts with descriptive names for each application that works with SQL is among security best practices

Tip 3: Plan database ownership and data security in advance

Start by identifying the needed level of protection and encryption for each database. This is an important issue when you have to deal with securing sensitive data, such as credit card numbers or patient health information, which is also a staple requirement to meet PCI or HIPAA compliance regulations. Having ensured complete visibility into what is happening across your databases, you strengthen security and streamline compliance by reducing the risk of missing suspicious activities.

When creating a database, make sure that you get all the necessary information about data confidentiality. Do not forget to assign distinct database owners, meaning that the same login should not be applied across all databases. In order to mitigate future risks, establish the same process for new database requests and approvals as well as for database retention.

Protecting database files on disk from unauthorized access and copying in real-time is highly recommended and can be done by leveraging database-level encryption with the Transparent Database Encryption (TDE) feature. In case you need to keep data encrypted in memory (until it is actively decrypted), and/or if we need to give granular users specific access to certain column or cell values, it is recommended that use cell-level encryption.

Tip 4: Regularly patch your SQL servers

The list of security best practices would not be complete without mentioning the need for proper patch management. Because attackers are actively looking for new security flaws in IT systems, and new malware and viruses appear every day, establishing proper patch management of your SQL servers should be among mandatory security practices.

A timely deployment of current versions of SQL service packs, cumulative updates and critical security hotfixes will advance the stability of database performance. It is also necessary to pay attention to regular updating of the underlying Windows Server operating system and any supporting applications, such as antivirus applications, as well.

Tip 5: Keep track of what’s going on

Finally, establishing accountability in many respects means staying up-to-date with configuration changes and user activity. This is an ongoing process of maintaining the actual state of security policies to make sure that all changes are authorized and documented.

Note: Always keep in mind that security is not a state – it is a process. Monitoring, alerting and reporting on changes must become a part of the entire data lifecycle.

Native audit logs allow us, to some extent, to check recent activities and changes affecting security, but obtaining an older view of changes made far long ago can be a challenge. Much excessive information is saved, and as a result logs very often do not contain the required data. On the contrary, change auditing can help detect unauthorized and malicious changes at early stages or show you the historical data, all of which help prevent data breaches and system downtime.

Security Requires a Thoughtful Policy : Try implementing continuous auditing to protect database environment against internal and external threats by ensuring complete visibility across databases

Happy Reading !

Recourse : dbta.com