1. Some information on Powershell commands that can help
2. Most of the Powershell commands used in the gMSA post require the use of the Active Directory (AD) cmdlets. The AD Module for Windows Powershell is not installed by default on member servers.  Here is a quick method using Powershell to install this module on a server.  From a Powershell session, run the following command.  Note that you must be running the Powershell session as an administrator.  See this link for more details.

1. Use the following Powershell command to remove a Windows feature such as the AD Module if it is no longer desirable to have it on the server. See this link for more details.

1. The New-ADServiceAccount cmdlet is used to create new MSA’s and gMSA’s. Here are a few additional pointers to using this cmdlet as well as some of the parameters.  See this link for more details.
2. When creating a new MSA, use the -RestrictToSingleComputer parameter.  Without this parameter, the new account defaults to a gMSA.

1. One of the benefits of using MSA accounts is Service Principal Name (SPN) management.  MSA service accounts can automatically register a service’s SPN.  However, there may be issues that prevent the SPN from being registered.  If your environment is configured in such a way that SPN’s do not get registered, you can use the -ServicePrincipalNames parameter to register the SPN when the MSA is created.

1. Use Remove-ADServiceAccount to remove an MSA or gMSA from Active Directory.
2.  Note that this command only removes the managed service account from AD.  It does not remove the managed service account from any computers that use it.  See this link for more details.

1. The Install-ADServiceAccount cmdlet is used on the member server to install the MSA/gMSA on that server. See this link for more details.

1. To remove a managed service account from a server (not from AD, see Remove-ADServiceAccount above), use the Uninstall-ADServiceAccount cmdlet. See this link for more details.

Summary

Completely Off Topic

• If we are running SQL Server using an MSA or gMSA account, should we use an administrative account to run SSCM? 
• Will using an administrative account work well in all cases, even for a standard domain account? 
• Are there any special tasks required to enable Encrypted Connections when using gMSA accounts?

Prerequisite Assumptions

I tested with W12R2-S16.contoso.com as the DNS fqdn.

I tested with C1-S16-I01.contoso.com as the DNS fqdn.

Step-by-Step for a Stand-Alone Instance using an MSA account

Step-by-Step for a Failover Clustered Instance using a gMSA account

Summary

Completely Off Topic

• The traceflag can be turned on or off without a restart.
• The database will continue to keep an encryption_state of 2 in the sys.dm_database_encryption_keys with a percent complete of 0 while the traceflag is enabled. Keep in mind the database is not fully encrypted until that scan completes and the encryption_state has changed to 3.
• Data that hasn’t been encrypted yet, will not be encrypted until one of two things occur.

o   The page gets updated by way of normal transaction processing.   During that point, it will get encrypted

o   The traceflag is disabled and the scan is resumed.

• To resume the encryption scan, the traceflag must be disabled and then alter database <database name> set encryption on ran. Just disabling the traceflag will not resume the encryption scan.

• Monitor CPU utilization and ensure you workload can run. The encryption scan is running as a background process, but it will take some resources while it runs.
• Monitor transaction log usage with dbcc loginfo. When the virtual log files fill up and are active, the status flag will be set to 2.   While the encryption scanner is running, the transaction log can’t be truncated and have the VLFs marked back to 0 for reuse.   Once a significant number of virtual logs are marked with a status of 2, you may want to stop the encryption scanner using traceflag 5004 and then truncate the transaction log.
• Monitor for blocking as described by https://blogs.msdn.microsoft.com/psssql/2016/04/19/why-do-we-see-encryption_scan-locks-in-a-sql-server/. If blocking becomes too problematic, you can resolve this by setting the traceflag and stopping the encryption scanner.   However, you will have to finish the scan at a period where the impact is reduced.

• Always Encrypted provides a complete end to end encryption that protects data from client to server.   Administrators do not even have the ability to read encrypted data using this method.  See https://msdn.microsoft.com/en-us/library/mt163865.aspx
• Transparent Data Encryption (TDE) protects data at rest so that data can’t be removed from a system and restored somewhere else for review.   TDE is seamless to an application while protecting the underlying data.  TDE can also be used with external EKM solutions for key management.  See https://msdn.microsoft.com/en-us/library/bb934049.aspx
• Column Level Encryption has been around for quite some time and is a reliable method for encrypting specific columns of a database using strong encryption protocols.  Access to this data is controlled via encryption keys that a user must have access to.  See https://msdn.microsoft.com/en-us/library/ms179331.aspx
• Full over the wire encryption is fully supported on SQL Server.  SQL Server can use trusted certificates to encrypt data over the wire between client and server.   Even if full encryption isn’t used, login packets are encrypted.  SQL Server 2016 fully supports TLS 1.2 which makes it fully compliant with the PCI DSS specification.  https://technet.microsoft.com/en-us/library/ms189067(v=sql.105).aspx
• Dynamic Data Masking was introduced in SQL Server 2016 as a feature that limits the data exposed to end users by implementing masking processes that hide portions of sensitive data from the end user.  For example, the mask may only allow the last 4 digits of a social security number.   See https://msdn.microsoft.com/en-us/library/mt130841.aspx

Part 1

• Build & Maintain Secure Networks and Systems
• Protect Cardholder Data

Part 2

• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures

Part 3

• Monitor & Test Networks Regularly
• Maintain an Information Security Policy

Part 4

• Additional PCI DSS Requirements for Shared Hosting Providers
• Additional PCI Requirements for Entities using SSL/Early TLS

o   For example, each entity in a SQL Server system would have its own database with unique user IDs that access only that database for that entity.   Other entities would also have their own unique database with different user IDs that access the database. 

o   Application processes cannot be privileged users.

o   Each entity must only be able access files and filesystems that it owns.  

o   Entity’s user accounts cannot have access to shared system binaries.

o   Log data can only be viewed for an entity that owns and generated the log activity.

o   Restrictions must be in place to ensure that no single entity can consume all resources related to disk space, network bandwidth, memory, or CPU

o   Audit logs must be enabled for third-party applications.

o   Audit logs must be active by default.

o   Audit logs are available for the owning entity to review.

o   Audit log locations must be communicated to the owning entity.

Entities using SSL and TLS 1.0 must migrate their cryptographic protocols to stronger protocols.  This requirement does provide guidance around when these protocols must be removed from use.  SQL Server has upgraded its cryptographic protocols to use TLS 1.2.  See https://blogs.msdn.microsoft.com/markweberblog/2015/12/01/sql-server-support-for-pci-dss-3-1/

o   If exploits are found in the early versions of SSL or TLS 1.0, then the POS device will have to be reevaluated and possibly replaced/updated to avoid the risk.

Completely Off Topic:

Requirement 10: Track and monitor all access to network resources and cardholder data

o   Individual user access to PCI data

o   All actions taken by any administrative user

o   Any time audit data is accessed

o   Failed access attempts

o   Any identification or authorization changes

o   Any time the audit logs are started, stopped, or paused

o   Creation, modification and deletions of system level objects

o   User identification

o   Type of event

o   Date and time event occurred

o   Success or failure of event

o   Origination event

o   The name of the impacted, system, resource, data, or component

o   Time data must be protected

o   Time settings must originate from industry trusted sources

o   Audits should only be viewable by those who need to view them as a job function

o   Do not allow audit trails to have unauthorized modifications

o   Backup audit trails to a central log server or media that is difficult to alter

o   Write external facing technologies onto a secure log server or media device

o   Use file integrity or change detection software on logs to ensure that log data cannot be changed

o   Review logs and security events for all PCI components for suspicious activity.

o   All security events

o   Logs of all PCI system components

o   Logs of all PCI components that perform security functions

o   Firewalls

o   IDS/IPS

o   FIM

o   Anti-virus

o   Physical access controls

o   Logical access controls

o   Audit logging mechanisms

o   Segmentation controls (if used)

o   Restoring security functions

o   Identifying and documenting the duration (date and time start to end) of the security failure

o   Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause

o   Identifying and addressing any security issues that arose during the failure

o   Performing a risk assessment to determine whether further actions are required as a result of the security failure

o   Implementing controls to prevent cause of failure from reoccurring

o   Resuming monitoring of security controls

o   Maintain a fully documented inventory of authorized wireless access points. 

o   Create operational incident management response procedures for when unauthorized access points are detected.

o   Addition of new system components (Additional components such as SSRS or SSAS are enabled on a PCI system or the usages of SQL Server Engine features such as addition of service broker, linked servers, AlwaysOn Availability Groups)

o   Changes in the network structure

o   Changes to firewalls or firewall rules - https://technet.microsoft.com/en-us/library/cc754274(v=ws.11).aspx

o   Software upgrades to existing infrastructure – This includes SQL Server Service Packs and Cumulative Updates

o   Quarterly have an approved external vendor perform vulnerability scans.  If items are detected, resolve them and rescan until all outstanding issues are fixed.

o   Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)

o   Includes coverage for the entire PCI infrastructure perimeter and critical systems

o   Includes testing from both inside and outside the network.  Must be performed at a minimum annually or if a significant change is made to the infrastructure or application.

o   Includes testing to validate any segmentation and scope-reduction controls

o   Defines application-layer penetration tests.

o   Defines network-layer penetration tests to include components that support network functions as well as operating systems

o   Includes review and consideration of threats and vulnerabilities experienced in the last 12 months

o   Specifies retention of penetration testing results and remediation activities results.

o   Any vulnerabilities found must be corrected and penetration testing repeated until all identified vulnerabilities are remediated

o   While not called out specifically in the PCI specification, it is best practice to periodically test the procedures for managing encryption.  This includes

Performing regular disaster recovery drills to test that the encryption management processes work.  Document the name of the individuals performing the test along with any test output as validation that the testing was successful.

o   The security policy must be reviewed and updated at a minimum annually.

o   Performed annually or to significant PCI environment changes

o   Identifies critical components, threats, and risks

o   For each threat or risk, there must be a formal documented analysis

o   Usage must be formally approved though a documented approval process.

o   Authentication for use of the related PCI infrastructure and data.

o   A list of all PCI devices and infrastructure with personnel who has access.

o   A process for determining the owner, contact information, and purpose for a PCI related device.

o   Acceptable usage of PCI infrastructure and data

o   A list of approved network locations for PCI infrastructure, PCI data, and access to that data.

o   A list of approved products, software, and devices

o   Automatic disconnect of remote access sessions after a period of activity.

o   Remote access should only be provided to partners or vendors for the period of time in which access is required.  The access should be deactivated after the need for access is completed.

o   For individuals accessing PCI systems or components, copying, modifying, or storing PCI data on devices or removable media that are not approved must be prohibited.

o   Create, document, distribute, and enforce security policies and processes.

o   Monitor and analyze security alerts

o   Manage the security incident response process and escalations for all security related situations.

o   Administrate user accounts.

o   Monitor and control all access to PCI related data.

o   A list of MSPs that must include a description of the service they provide

o   Maintain all written agreements with MSPs.  Written agreements must include wording that is clear that the MSP is responsible for the security of PCI data in their possession, under their control, or part of their access.

o   All engagements with MSPs must have adequate due diligence prior to entering into the engagement.

o   All MSPs compliance must be formally reviewed at a minimum annually.

o   Document which PCI requirements are managed by the company and which ones are managed by the MSP.

o   If there are additional requirements for an MSP, those requirements must be acknowledged in writing by the MSP.

o   Roles, responsibilities, contact, and communication strategies in the event of a compromise. 

o   Specific procedures

o   Business recovery and continuity processes

o   Data backup and recovery procedures

o   Identification of legal requirements for disclosing a PCI data compromise.

o   Individuals responsible for coverage for all system components during the implementation of an incident

o   Reference or inclusion of incident response procedures from the payment brands.

o   Review and test the plan at a minimum annually.

o   Identify personnel who are available 24/7/365 to respond to alerts.

o   Provide training to staff in the event of an incident

o   Include all alerts from PCI monitoring systems

o   Create a process to modify and update the incident response plan as business needs evolve and the PCI system changes

o   Develop an RCA process that identifies gaps that least to the incident and identifies lessons learned that can be implemented to prevent future incidents.

o   Starting January 31, 2018, all service providers must

o   Starting January 31, 2018, all service providers must

Completely Off Topic:

Terms Used in This Post

• I/O – Input/output
• SSAS – SQL Server Analysis Services
• SSRS – SQL Server Reporting Services

Requirement 5: Deploy antivirus software on all system commonly affected by malicious software

Requirement 6: Develop and maintain secure systems and applications

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.

o   Developers must be trained annually in secure coding techniques

o   Address SQL and OS command injection

o   Avoid buffer overflows in software systems

o   Prevent insecure cryptographic storage

o   Do not allow error messages to disclose information

o   Avoid cross site scripting

o   Prevent improper access control

o   Avoid cross site request forgery in web services

Requirement 7: Restrict access to cardholder data by business need to know

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.

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.

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

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

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:

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.

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

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.

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.

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

Requirement 9: Restrict physical access to cardholder data

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.

o   Identifying onsite personnel and visitors visually

o   Changes to access requirements

o   Remove access to terminated personnel or individuals with expired identification credentials.

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.

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

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

o   Maintain inventory logs of all media and conduct inventories at least once per year.

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

o   Maintain lists of devices that are current

o   Devices must be checked for tampering regularly

o   Individuals inspecting devices for tampering should include

o   Ensure security policies and operations procedures are documented, well known, and maintained by all individuals working with PCI data.

Completely Off Topic:

Grant Carter is a Senior Premier Field Engineer for Microsoft based in Boise, Idaho. 

• DMZ – Demilitarized zone often referred to as a perimeter network
• TLS – Transport Layer Security
• SSL – Secure Sockets Layer
• PAN – Primary Account Number
• PIN – Personal Identification Number
• EKM – Extensible Key Managment

Build & Maintain Secure Networks & Systems

Requirement 1: Install & maintain firewall configuration to protect cardholder data.

• Only servers and clients that should communicate are allowed to communicate. Other systems should be blocked.

o   Only the ports necessary to operate the SQL Server should be opened.

o   Firewall rules need to be approved and tested before being implemented.

o   Network diagrams should identify all connections between the PCI environment and other networks.

o   Identify and document all data flow from the PCI SQL Server to other systems and networks.

o   Firewalls should exist at each internet connection and between any DMZ an the internal network

o   All personnel who maintain network security for the SQL Server needs to be identified and their role for maintaining network security documented and tested.

o   Business justification for the use of services, protocols, & ports should be documented.  If any of these items be deemed insecure but necessary to run the business, the risks associated with using them needs to be clearly documented.

o   Review firewall rules every 6 months.  Should rules need to be adjusted or updated, any documentation should be modified to reflect the adjustment.

o   Review and monitor operational logs for unauthorized access and respond immediately should unauthorized access take place.

• Restrict connections between the PCI data environment and untrusted networks.

o   Deny all traffic that isn’t related to the processing of PCI data and only allow traffic that is necessary for data processing.

o   Secure any firewall configuration file so that unauthorized sources can’t examine the network configuration.

o   Synchronize configurations with what is running or active on router and firewall devices.  Sometimes configuration changes are made but are not actually implemented to run on the device.

o   Install perimeter firewalls between all wireless networks and the PCI data environment.

• Do not allow public access to the public internet for any system in the cardholder environment.

o   Implement a DMZ to limit inbound traffic to only allow authorized services, protocols, and ports

o   Limit internet traffic to IP address inside the DMZ.

o   Implement anti-spoofing technology.

o   Outbound traffic from the PCI environment to the internet should be blocked

o   All components that store PCI data should be located internally and not in a DMZ or untrusted network.

o   Do not disclose private IP addresses or SQL Server port numbers.

o   Consider hiding the SQL Server instance from discovery via the SQL Browser service.  See https://msdn.microsoft.com/en-us/library/ms179327.aspx.

• Install firewall software on any portable computing device including employee, vendor, or company owned devices.
• All security policies and standard operating procedures should be well documented and are available to all people who are responsible for designing and operating PCI systems.

Requirement 2: Do not use vendor supplied defaults for system passwords and other security parameters

• Always change vendor supplied passwords and defaults.

o   Consider renaming the sa account to something other than sa.  See Disabling or Renaming the Built-in sa Account in https://technet.microsoft.com/en-us/library/cc966485.aspx

o   Change the sa password often to something extremely complex.

o   If possible, disable the sa account and use Windows authentication if at all possible.

o   Review all vendor provided accounts to ensure they follow a password policy and that the password has been changed to something that is not the default service account.

o   For wireless environments connected to or transmitting PCI data, any vendor default must be changed

• Develop configuration standards for all components that make up the PCI system.

o   Consider implementing well known secure industry configuration standards as part of your corporate standard.

o   Segregate functions between different services so that multiple services with mixed levels of security will not have to exist on the same infrastructure.

o   Enable only necessary services, protocols, and ports that are required to process PCI data.

o   Turn off any unnecessary services, scripts, or features to reduce the surface area.

o   Implement additional security features for any service, protocol, or port that is deemed insecure.

o   Configure security parameters to prevent misuse, either accidental or intentional.

• Encrypt all non-console communication using strong cryptography protocols

o   SQL Server communication should not include TLS 1.0 or below.  TLS 1.2 is fully supported in SQL Server 2008 SP4 and greater.  Any SQL Server service older than SQL Server 2008 is now unsupported and TLS 1.2 support does not exist.  Please see https://blogs.msdn.microsoft.com/markweberblog/2015/12/01/sql-server-support-for-pci-dss-3-1/ for full details on the TLS 1.2 implementation for SQL Server.

o   Maintain an inventory of system components that are in scope for PCI compliance.

o   Security policies and procedures for managing all security parameters should be documented, used, and known by all parties who design and manage the PCI systems

o   Hosting providers that provide shared environments on the same infrastructure must protect each client’s PCI data and not allow for unsecure configurations which could allow one client’s data be exposed to another client.  An example of the might be something like using the same encryption key for multiple clients or allowing the same user to access both client’s data.

Protect Cardholder Data

Requirement 3: Protect stored cardholder data

• Keep card holder data storage to a minimum by implementing data retention and disposal policies and procedures.

o   Keep the data only as long as you need for business or legal requirements.   Many data breaches steal data from records that provide no business value.  By limiting the amount of data stored, should a data breach occur, the scope of the breach will be limited and exposure reduced.

o   Develop processes for data purges.  Test those processes and ensure they purge all non-essential data in a timely fashion.

o   PCI DSS requires a quarterly process to identify and purge data that exceeds the retention period defined by business or legal requirements.   All locations that can hold cardholder data must be considered n these processes.   This includes databases, database backups, log files, application files, and application logs.

• Do not store sensitive authentication data after authorization (even if encrypted). All data that performs payment card authentication can be full contents of any track (from the magnetic strip), cardholders name, expiration date, card validation codes, pins or other data that can be used to aid in the misuse of card data is prohibited in a PCI DSS compliant system.   All authentication procedures must be reviewed periodically and validated that no authentication data is being stored.  The only exception to the rule about storing authentication data is for card issuers.  Issuing services can store this data as long as they have a business justification and have validated systems that store that data securely.

o   Ensure databases that must be PCI compliant do not store this data

o   Validate processes that handle this data do not store this data in log files, application files, or databases

• Mask the personal account number (PAN) with the following requirements

o   The first 6 digits

o   The last 4 digits

o   Anyone with access to the unmasked data must have a business requirement to do so.

o   PANs must be masked for screen display, printed paper, and electronic transmission such as email or text messaging.

o   SQL Server’s dynamic masking feature aids in meeting this masking requirement.  Also application design using views can be utilized to mask data from people who should not have access to this data.

o   The PAN must be rendered unreadable anywhere it is stored.

• When storing the PAN in SQL Server, using column level encryption will meet this requirement. See https://msdn.microsoft.com/en-us/library/ms179331.aspx for how to implement column level encryption.

o   Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse

• Encryption keys and certificates used to encrypt data must be backed up and protected independently of the data. See https://msdn.microsoft.com/en-us/library/bb964742.aspx for more details on how to protect encrypted columns and database in the event of recovery.
• All keys should be stored independently of databases files and database backup files.
• Access to keys and key backups should only be allowed to individuals who have a need for them.
• Periodic key rotation policies should be followed.
• If a key should become jeopardized, regenerate the encryption key immediately
• Consider the use of an extensible key management solution (EKM) for key management. https://msdn.microsoft.com/en-us/library/bb895340.aspx

o   Document the details of all cryptographic implementations: Include protocols, algorithms, and EKM solutions.  This detail is a best practice until January 31, 2018, but to be PCI compliant after that, this step is required.

o   One or more of the following must be used to store private keys used in PCI systems

• Protect private keys used with PCI data with key encrypting keys that are as strong or stronger than the key protecting the card hold data
• Store in a secure cryptographic module such as a hardware security module
• At least 2 full length key components or key shares.

o   Keep keys in the fewest number of possible locations to reduce the risk of exposing keys.

o   All key management processes must be documented and validated

• Validate encryption algorithms and protocols used to encrypt data must meet strength requirements
• Validate key distribution processes meet requirements
• Validate encryption solutions store the keys securely with protections against unauthorized access.
• Document and validate key expirations periods and key rotation practices are in use.
• Document processes for the replacement of keys that are weak or compromised. Validate the processes are followed.  SQL Server keys can be regenerated as part of a rotation strategy.
• Key management processes should not accept and use keys from unauthorized sources. Only authorized processes to generate and use keys should be accepted.

o   Processes and policies that are in place to protected PCI data must be documented and used by all parties.  Any updates to these policies or processes must be known by all parties immediately when those changes are implemented.

• Performing regular disaster recovery drills to test that the encryption management processes work. 
• Document the name of the individuals performing the test along with any test output as validation that the testing was successful.

Requirement 4: Encrypt the transmission of cardholder data across open, public networks

• Use strong cryptographic and security protocols for the transmission of PCI data across public networks.

o   By June 30, 2018 all applications using SSL or early TLS versions must cease.

o   Before June 30, 2018 all applications using SSL or early TLS versions must have risk mitigation plans in place.

o   SQL Server now supports TLS 1.2 -  https://blogs.msdn.microsoft.com/markweberblog/2015/12/01/sql-server-support-for-pci-dss-3-1/

o   Use trusted keys from trusted sources

o   Use strong protocols and algorithms for keys.

• Do not send unencrypted PANs across using messaging technologies such as email.
• Ensure all security policies and operational procedures related to the transmission of PCI data are documented and in use by all individuals who handle PCI data. Ensure updates policies or procedures become known by all individuals who handle PIC data

Completely Off Topic:

• Each service should be using a different service account (to prevent the compromise of all services using the same service account if one service account is compromised).
• Each service account should have its passwords managed in accordance with domain account policies (changing every 90 days for example)

1. By automating the process within Active Directory for the password management. Passwords are very complex and changed automatically as often as desired (by default every 30 days). The passwords are cryptographically random and 240 bytes long. In addition, they cannot be used to interactively logon. Nor can they be locked out.
2. There is also no longer a need to restart the SQL Server service after a service account password reset, which prevents downtime, etc.

Prerequisites

• If deploying a Windows Server 2012 R2 DC, be aware of the following hotfix that resolves a problem with connecting after a password change: https://support.microsoft.com/en-us/kb/2998082
• There are more details on prerequisites located here: https://technet.microsoft.com/en-us/library/jj128431.aspx#BKMK_gMSA_Req

• See https://technet.microsoft.com/en-us/library/jj128430.aspx for details and steps
• Note that there is a 10 hour lag between the time the KDS root key is created and the time a gMSA can be created. This is to allow full replication between the Windows Server 2012 DC’s in order to allow password retrieval to work as necessary.
• There are steps at the above reference to allow the use of the root key immediately for testing purposes.
• This requires a 64-bit environment, but only has to be done on one Windows Server 2012 R2 DC.

gMSA Implementation for SQL Server 2016

1. Create a Global Security Group in Active Directory Users and Computers.

• This step is actually optional, but it allows for easier management of the necessary rights required to use the gMSA for the member servers.
• Note also that there will be a reboot requirement for the member servers added to this Security Group.

• Enter a Group Name, Group scope should be Global and Group type is Security. In this demo, we will use SQLServers
• Open the newly created Security Group by double clicking on it and go to the Members tab. Or right click on the Security Group and go to Properties then the Members tab.

• Click Add and add the domain member servers that will be hosting the SQL Server instances that will be using the gMSA. In this demo, I added all of the member servers that will be running SQL Server:

2. Create the gMSA account

• This must be done with a PowerShell script in a PowerShell session that also has the Windows Server 2012 AD cmdlets available (it does not need to be done on a DC). See https://technet.microsoft.com/en-us/library/dd378937(v=ws.10).aspx for guidance on installing the AD Powershell module.
• The command that creates the gMSA will also grant the right to retrieve the accounts password to the members of the Security Group created earlier
• This is the PowerShell command used:

New-ADServiceAccount -name gMSAsqlservice -DNSHostName gMSAsqlservice.contoso.com -PrincipalsAllowedToRetrieveManagedPassword SQLServers

3. Configure and validate the gMSA service account on the member servers.

• This is a step that might not need to be done: the accounts may already be configured on the member servers when they were rebooted. However, the steps are quite quick and the validation of the account should be considered necessary. These commands also require the AD module for Powershell.
• To configure the gMSA account, run the following PowerShell command on the member server: Install-ADServiceAccount gMSAsqlservice
• To validate the gMSA account, run the following PowerShell command on the member server: Test-ADServiceAccount gMSAsqlservice
  • This should return True.

4. Configure SQL Server to use the gMSA service account

• Start SQL Server Configuration Manager
• Under SQL Server Services, right click the instance of SQL Server you want to assign the service account to and go to Properties
• In Log On tab, choose “This account”.
• In Account Name enter the domain account and include a “$” after the gMSA name:
  • contoso\gMSAsqlservice$
  • The “$” may automatically be added for you.
  • Do not enter a Password, it will be retrieved automatically from AD.
• Start or Restart the SQL Server service

Using gMSA accounts during SQL Server 2016 installation

Returning to Non-gMSA Service Accounts

Summary

Completely Off Topic

The Payment Card Industry Data Security Standard (PCI DSS) was created to describe and enforce data standards and processes for the secure processing of payment cards.  PCI DSS provides technical requirements for protecting data used in card payments.  PCI DSS 3.1 is the most recent revision of this industry standard.  The standard for this revision can be located at https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

TLS or Transport Layer Security (https://en.wikipedia.org/wiki/Transport_Layer_Security) are cryptographic protocols that allow computer communications over a network to remain secure.  As of February 2016, TLS 1.2 is the most recent production use of this protocol and is considered currently the most secure.

The PCI DSS 3.1 standard requires that the use of strong cryptography protocols must be used.  SSL and TLS versions 1.0 and 1.1 are not considered strong cryptography and can no longer be used after June 30, 2016 in systems that must meet PCI DSS 3.1 standards.  TLS 1.2 becomes the de facto standard to achieve PCI DSS 3.1 compliance.

Microsoft SQL Server supported the TLS 1.0 protocol until the SQL Server 2012 Service Pack 2 Cumulative Update 6 or SQL Server 2014 Service Pack 1 Cumulative Update 1 updates.  Please note there is a known issue in CU1 release of SQL 2014 that is scheduled to be fixed in February 2016.  In January 2016, support for TLS 1.2 was added to SQL Server 2008R2 and SQL Server 2008 via a hotfix documented at https://support.microsoft.com/en-us/kb/3135244.    Support for TLS 1.2 will not be backported to SQL Server 2005, 2008, or 2008R2.

The key to making TLS 1.2 work, is that both the server and the client have to be patched to a level that will allow both to communicate using the TLS 1.2 protocol.   If either side of the conversation isn't properly patched, then the communication will fail and connecting and communicating with SQL Server from a client machine will not work.  This article describes how to get TLS 1.2 working with SQL Server, SQL Native Client, and SQL Server Management Studio.

TLS 1.2 is supported in the following Operating Systems (https://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx)

• Windows 7
• Windows 8
• Windows 8.1
• Windows 10
• Windows Server 2008R2
• Windows Server 2012
• Windows Server 2012R2

SQL Server Supports TLS 1.2 in the following versions (https://support.microsoft.com/en-us/kb/3052404)

• SQL Server 2012 Service Pack 2 Cumulative Update 6 or greater -  https://support.microsoft.com/en-us/kb/3052468
• SQL Server 2014 Service Pack 1 Cumulative Update 1 or greater - https://support.microsoft.com/en-us/kb/3067839
• (If using AlwaysOn or DB Mirroring, check out https://support.microsoft.com/en-us/kb/3135852)
• SQL Server 2014 RTM Cumulative Update 8 or greater - https://support.microsoft.com/en-us/kb/3067836

SQL Server Native Access Client (SNAC) and SQL Server Management Studio .Net updates are located at:

• .Net 4.6 for SSMS to work with TLS 1.2 - https://www.microsoft.com/en-us/download/details.aspx?id=48130
• .Net Framework 4.5.2 rollup
• Hotfix rollup 3099845 for the .NET Framework 4.5.2, 4.5.1, and 4.5
• Hotfix rollup 3099844 for the .NET Framework 4.5.2, 4.5.1, and 4.5 on Windows
• Hotfix rollup 3099842 for the .NET Framework 4.5.2 and the .NET Framework 4.5.1 on Windows
• ADO.net – SQL Client (.Net framework 4.0) - Hotfix rollup 3106994 for the .NET Framework 4.0 in Windows
• ADO.net – SQLClient (.Net framework 3.5/.Net Framework 2.0SP2)
• Hotfix rollup 3106990 for the .NET Framework 2.0 SP2 in Windows Server 2008 SP2 and Windows Vista SP2
• Hotfix rollup 3106991 for the .NET Framework 2.0 SP2 in Windows Server 2008 R2 SP1 and Windows 7 SP1
• Hotfix rollup 3106992 for the .NET Framework 2.0 SP2 on Windows Server 2012 and Windows 8
• Hotfix rollup 3106993 for the .NET Framework 2.0 SP2 in Windows Server 2012 R2 and Windows 8.1
• SQL Server 2012 SP2 CU6 SNAC update - https://support.microsoft.com/en-us/kb/3052468
• SQL Server 2014 SP1 CU1 SNAC update - https://support.microsoft.com/en-us/kb/3067839
• SQL Server 2014 RTM Cumulative Update 8 SNAC update - https://support.microsoft.com/en-us/kb/3067836
• Microsoft ODBC Driver for SQL Server - https://www.microsoft.com/en-us/download/details.aspx?id=36434
• JDBC 6.0, 4.1, and 4.2 - https://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=11774

Steps To Get SQL Server Encryption Working:

Follow the steps outlined at https://msdn.microsoft.com/en-us/library/ms191192(v=sql.110).aspx to enable encryption on the SQL Server.

Steps to Get TLS 1.2 working with SQL Server

On The Server Side:

Apply one of the following cumulative updates.

1. SQL Server 2012 Service Pack 2 Cumulative Update 6 or greater -  https://support.microsoft.com/en-us/kb/3052468
2. SQL Server 2014 Service Pack 1 Cumulative Update 1 or greater - https://support.microsoft.com/en-us/kb/3067839
3. SQL Server 2014 RTM Cumulative Update 8 or greater - https://support.microsoft.com/en-us/kb/3067836

Steps to Disable TLS 1.0, TLS 1.1, SSL 2.0, and SSL 3.0  (Optional Step.  Complete to comply with PCI DSS 3.1 most strictly)

The PCI DSS 3.1 standard states that use of all SSL and early TLS protocols must be discontinued by June 30, 2016.   This step will disable those protocols on the Server and ensure that communication to the server must be done using TLS 1.2. 

NOTE WELL: Doing this will break communication with all clients that haven’t been patched to support TLS 1.2.   Implementing this could cause issues with connectivity with those clients.  Please be aware of this before disabling these protocols.

Test very thoroughly in a non-production environment before production deployment. 

Please check with any third party driver provider to ensure that their drivers will support the TLS 1.2 standard before implementing.

1. Because making registry changes involves risk, it is important that before making any changes to your registry as outlined in the KBs in the following step, please make sure you back up your registry by following the procedure outlined at https://support.microsoft.com/en-us/kb/322756. 
2. Follow the following KB articles for instructions on how to disable certain cryptographic algorithms.  https://support.microsoft.com/en-us/kb/245030 or https://support.microsoft.com/en-us/kb/187498
3. Reboot the server once the registry changes have been made.  All SQL clients that do not have the TLS 1.2 updates will not be able to connect to the server.
4. If encrypted communications have been enforced on the server, then SQL Server management studio will not work until a .net 4.6 upgrade is deployed to the server.  You will have to stop SQL Server and SQL Agent while you install the framework.  To Make SSMS use TLS 1.2, you need to install .net framework 4.6 on the client
   machine which can be obtained from the following link.  https://www.microsoft.com/en-us/download/details.aspx?id=48130

On The Client Side

Patch SQL Native client to one of the following versions:
1. SQL Server 2012 Service Pack 2 Cumulative Update 6 or greater -  https://support.microsoft.com/en-us/kb/3052468
2. SQL Server 2014 Service Pack 1 Cumulative Update 1 or greater - https://support.microsoft.com/en-us/kb/3067839
3. SQL Server 2008R2 SP3 Hotfix (10.50.6537) - https://support.microsoft.com/en-us/hotfix/kbhotfix?kbnum=3098860&kbln=en-us
4. SQL Server 2008 SP4 (10.00.6543) - https://support.microsoft.com/en-us/hotfix/kbhotfix?kbnum=3098860&kbln=en-us

 NOTE: The tools that use the native client or ODBC should use TLS 1.2 once the previous step is completed, however, SQL Server Management Studio (SSMS) will not use TLS 1.2 even if the SQL Native Client is patched.  Network traces will show it still using TLS 1.0.  To Make SSMS use TLS 1.2, you need to install .net framework 4.6 on the client machine which can be obtained from the following link: https://www.microsoft.com/en-us/download/details.aspx?id=48130

Completely Off Topic:

Obscure Item of History

On December 8, 1941, President Franklin Roosevelt delivered his famous “Infamy” speech in the Capitol Building in Washington.  The Secret Service was concerned about an assassination attempt on his life.  They chose to drive him to the capitol in a 1928 Cadillac 341A Town Sedan originally owned by Al Capone because it had been heavily armored by the gangster.   Source: https://en.wikipedia.org/wiki/Presidential_state_car_%28United_States%29

   
  
  
  
  
Grant Carter is a Senior Premier Field Engineer for Microsoft based in Boise, Idaho.  Grant has been working with SQL Server since SQL Server 2000. 

EMail: Grant.Carter@microsoft.com