PCI DSS 32 and SQL Server - By Grant Carter Part 2: Antivirus and Coding
PCI DSS 3.2 and SQL Server - Part 2
Terms Used in This Post
- I/O – Input/output
- SSAS – SQL Server Analysis Services
- SSRS – SQL Server Reporting Services
Maintain a Vulnerability Management Program
Requirement 5: Deploy antivirus software on all system commonly affected by malicious software
Monitoring SQL Server for viruses is an action that can have a significant negative impact if it isn’t done properly. Antivirus programs typically install filter drivers in the Windows I/O path. If these drives aren’t instructed to not inspect SQL Server related activities, significant performance or reliability issues can arise.
Microsoft documents how to run antivirus programs on machines hosting SQL Server. The documentation can be found at https://support.microsoft.com/en-us/kb/309422. Testing antivirus and antivirus exclusions before deploying to a PCI DSS environment is crucial to ensure the performance and reliability of the system.
Some virus scanning processes also monitor executables. Not only are excluding the file locations mentioned in the above article important, but also excluding the appropriate executables is important to ensure SQL Server can perform and be reliable when the antivirus program runs.
Operationally, it is important to ensure antivirus definitions and executables are updated frequently with the most recent signatures. It is important to monitor and identify any malicious activity that the antivirus encounters. And that immediate response processes are in place to deal with any detected virus infection. Review software logs to ensure antivirus is functioning as planned and that updates are being applied.
Requirement 6: Develop and maintain secure systems and applications
While SQL Server is one of the most secure platforms in the world, it is important to protect PCI SQL Servers and other PCI software and hardware systems from unauthorized access by ensuring systems are patched with the latest software. The PCI standard provides guidance as to what the requirements are for developing and maintaining secure systems.
Create a process to discover security vulnerabilities using external sources of information. For each discovered vulnerability, assign a ranking in terms of criticality of the weakness. The process should also dictate what the response to that particular item is. For example, all critical vulnerabilities must be patched as soon as possible.
Microsoft has created a security bulletin system for patching software https://technet.microsoft.com/en-us/security/bulletins.aspx. The rating of this system is documented at https://technet.microsoft.com/en-us/security/gg309177.aspx. Using this rating system, Microsoft provides guidance as to how to respond based on the criticality rating of the individual patch.
Install any identified patches in accordance to the documented timeframe depending on the rating severity. For highly critical patches, PCI DSS states that they must be implemented within one moth of release.
Include security considerations in the design of software systems that process PCI data. Security must be considering in the entire design lifecycle of the software. Examine all design, development, testing and operations documents to ensure sensitive data is handled appropriately.
Review code prior to release to production to ensure any potential coding vulnerabilities are identified and removed. For SQL Server this includes reviewing database scripts, security grants, revokes, and denies. Protecting code against possible SQL ejection attacks and ensuring that database queries execute with the least required privilege.
· Follow change control process for all system components. This includes:
o Rolling changes through separate development and testing environments
o Development and test environments must be separated from production environments with different access.
o Ensure separation of duties between code testers and people to deploy to production.
o Real production data cannot be used for testing
o Test data does not get deployed to production
o All procedures related to change control and release management are documented and followed.
Impact of change must be documented
Changes must be approved
Testing must prove that changes to not impact system security
Back out procedures must be developed to roll back any change that fails
· Procedures must address common coding flaws
o Developers must be trained annually in secure coding techniques
o Address SQL and OS command injection
· Common ways to prevent SQL injection attacks
· Constrain and sanitize input data.
· Use type-safe parameters for SQL data access. Stored procedures are parameterized and are a common way to prevent SQL injection attacks.
· Use accounts with restricted permissions. For example, use an account that can only run stored procedures and can’t select directly from SQL tables.
· Do not disclose database error information to the end user. By doing this, database information isn’t passed back so the end user can see the names of servers, databases, tables.
o Avoid buffer overflows in software systems
o Prevent insecure cryptographic storage
· Use strong algorithms and protocols. For SQL Server ensure all database systems have the TLS 1.2 hotfixes applied. Ensure all database clients are TLS 1.2 compatible.
o Do not allow error messages to disclose information
o Avoid cross site scripting
o Prevent improper access control
· Ensure users are authenticated
· Sanitize the input of any SQL database query to prevent injection attack
· Do not expose internal object names such as database, schema, or object names to end users.
· Prevent directory traversal in web sites
o Avoid cross site request forgery in web services
· For public facing web apps, address new threads in an ongoing basis. This can be accomplished by installing automated intrusion detection systems or firewalls that continually check traffic.
· All security policies and procedures must be known to staff developing, operating, and maintaining PCI information systems. Any change to these processes must also be documented and made known to all staff.
Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need to know
· Limit access to systems and PCI data to individuals who must have access to perform their job
o Define the access needed for each role that manages, handles, or processes PCI data. In SQL Server define data access roles and grant the minimum permissions necessary to those roles. Do not grant permissions to individuals as individuals could change roles and as a result, access requirements would change. Granting access to individuals increases the risk that unnecessary access would be retained if an individual changes their role.
o Limit system role privileges such as sysadmin permissions to individuals who need them. Individuals needing data access do not require these elevated permissions and those permissions should not be granted to them.
o Limit access to the least amount of privilege to perform the job.
o Require documented approvals before an individual is granted privilege to PCI data.
· Establish access control systems that by default deny access to PCI data unless permission is explicitly granted.
o Deny permissions to PCI user data and systems by default. https://msdn.microsoft.com/en-us/library/ms188338.aspx
o This applies to all system components. Protecting the database is important, but access to the systems, backup systems, filesystems, or other components must also be implemented.
o Assign privilege to PCI data and PCI systems based on job function.
· Security policies must be well documented, published and well known by all parties that process, manage, or develop for PCI systems.
o These policies and procedures must be continually updated to reflect changes and those changes must be updated to all individuals who have a need to know them.
Requirement 8: Identify and authenticate access to system components
· Implement policies and procedures that enforce correct user identification management for non-consumer users and administrators on all PCI system components.
o All users must have a unique ID that can identify their access to PCI systems and data
o Processes must be developed to control the addition, deletion, or modification of user IDs and credentials.
o Immediately remove access from users who have left the company in conjunction with documented security policy.
o Disable or remove user accounts which have been inactive for 90 days
o Manage ID’s used by third parties to process, support, or maintain systems that are PCI systems
· User IDs must be disabled at all times except for the periods where access is needed. https://msdn.microsoft.com/en-us/library/ms189828.aspx
· User IDs must be audited when in use
o User access attempts must be limited to six attempts and User ID must be blocked afterwards.
o Lockout duration must be no shorter than 30 minutes before the User ID is re-enabled.
o Sessions idle for 15 minutes must require the user to re-authenticate to obtain access to the PCI system or components. Example code for terminating idle SQL Server sessions can be found at https://gallery.technet.microsoft.com/scriptcenter/How-to-kill-SQL-Server-a33476b7
o Non-consumer users must authenticate using at least one of the following:
· Something you know, such as a password or passphrase
· Something you have, such as a token device or smart card
· Something you are, such as a biometric.
o All login information must use strong cryptography to make credential information unreadable during transmissions and storage. See https://msdn.microsoft.com/en-us/library/ms189067%28SQL.90%29.aspx?f=255&MSPPError=-2147217396 and https://msdn.microsoft.com/en-us/library/ms189751.aspx for how the login credentials are encrypted and passed encrypted over the network for SQL Server
o Verify user identity before modifying authentication credentials.
o Passwords must have the following requirements. See https://msdn.microsoft.com/en-us/library/ms161959.aspx for more details on how to enforce complexity requirements for SQL Server authenticated logins.
· Have a minimum length of seven characters
· Contain both numeric and alphabetic characters
o Change passwords at least once every ninety days. See https://msdn.microsoft.com/en-us/library/ms161959.aspx for details for setting password expiration for SQL Server authenticated logins.
o Do not allow users to reuse passwords within 4 password changes. See https://msdn.microsoft.com/en-us/library/ms161959.aspx for policy enforcement of password history for SQL Server authenticated logins
· All individual non-console access and remote access must use multi-factor authentication. Requirement will be enforced starting January 31, 2018.
· For all remote work, multi-factor authentication for both user and administrator work must be implemented if the sessions originate outside of the network the PCI system resides on.
· Document, communicate, and maintain documentation of policies and procedures as related to
o Criteria for selecting strong authentication credentials
o Guidance on how users should protect their credentials
o Policies on how not to reuse passwords
o Policies on changing passwords should one become compromised.
· Do not use generic or shared accounts to access or maintain data systems that hold PCI data.
· If other authentication mechanisms are used,
o Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts.
o Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access.
· All databases access to PCI related systems is restricted to
o All user access to, user queries of, and user actions on databases are through programmatic methods.
o Only database administrators have the ability to directly access or query databases.
o Application IDs for database applications can only be used by the applications (and not by individual users or other
· All security policies and procedures are documented, in use and well known by all parties impacted by the policies and procedures.
Requirement 9: Restrict physical access to cardholder data
· Use facility controls to limit and monitor physical access to PCI related information systems
o Use cameras, access control measures, or both to monitor access. Store the data for at least 23 months or for periods dictated by law
o Limit access to networks accessible by publicly available network jacks.
o Restrict access to wireless access points, gateways, hand held devices or other networking hardware and communications lines.
· Procedures and processes must be developed to determine if individuals are personnel or visitors. This must include:
o Identifying onsite personnel and visitors visually
o Changes to access requirements
o Remove access to terminated personnel or individuals with expired identification credentials.
· Control physical access for onsite personnel to sensitive areas
o Sensitive areas should only allow access to individuals with a job functions that requires access.
o Access to sensitive areas is removed if individual has a role change or job termination that would impact the level of access needed.
· Implement processes to identify and authorize visitors
o Visitors must be authorized before entering
o Visitors must be escorted at all times in areas where PCI data is processed or maintained
o Visitors must surrender identification credentials before leaving the facility or at the date of expiration of the credentials
o Visitor logs should be used to maintain a physical audit trail of visitor activity. These logs must be maintained for three months unless local law states otherwise
· All PCI media must be physically secured. This includes any offsite backup locations.
· Maintain strict control over the internal or external distribution of any kind of media
o Classify media so its sensitivity can be easily determined
o If media must be transported, use secure courier or deliver methods that can be tracked
o Management must approve any media that is moved from a secure area
· Maintain strict control over the storage and accessibility of media
o Maintain inventory logs of all media and conduct inventories at least once per year.
· Destroy media when it is no longer in use
o Shred, incinerate, or pulp hard copy material so that PCI data cannot be reconstructed in secure containers.
o Render all electronic media unusable and unrecoverable to prevent PCI data from being reconstructed
· Protect all devices that collect payment card data via physical interaction with the card from tampering or substitution
o Maintain lists of devices that are current
· Make, model of device
· Location of device (for example, the address of the site or facility where the device is located)
· Device serial number or other method of unique identification.
o Devices must be checked for tampering regularly
o Individuals inspecting devices for tampering should include
· Verify any third party maintenance personnel before grant them access to troubleshoot or repair devices
· Do not install or replace devices without verifications
· If individuals are acting suspicious, report that behavior using the appropriate protocol outlined in the operations security policies and procedures.
o Ensure security policies and operations procedures are documented, well known, and maintained by all individuals working with PCI data.
Completely Off Topic:
Obscure Item of History
Kutol Wallpaper Cleaner was created in Cincinnati, Ohio by Noah McVicker. The putty removed coal soot from wallpaper. Americans switch from burning coal to using natural gas and electricity so the demand for the product dropped. Another use for the product was discovered and it became a toy under the name of “Play-Doh” in 1956.
Grant Carter is a Senior Premier Field Engineer for Microsoft based in Boise, Idaho.
Email: grant.carter@microsoft.com