Learn the best practices for developing a security awareness training program that is engaging. Engaging awareness programs have been shown to change more users’ behavior and are seen as an asset for your organization instead of annoyance.
We all know that PCI-DSS is one of the toughest compliances/certifications to hold, but organizations that seek to be PCI-DSS compliant can greatly benefit if they incorporate a SIEM solution around the Card Holder Data Environment (CDE). In this article, we will learn how the SIEM solution can be leveraged to satisfy a majority of PCI-DSS requirements.
The PCI-DSS major requirement is continuous monitoring of the security controls that are put in the CDE. Organizations should deploy an existing, or choose a new, SIEM solution but make sure that it has the capability to collect from all of the organization’s security controls.
Note: It is an important point that the organization should note that SIEM should never be configured to collect sensitive data in plain format. In the first place, PCI-DSS does not allow storing cardholder data in raw form. It should always be stored in encrypted form. However, from the SIEM perspective, all the sensitive data should be masked before being logged inside the SIEM solution as it has accessibility to all the analysts/investigators/engineers/admins etc.
Let’s start with perimeter security. PCI DSS wants the organization to monitor all the network connections and changes made to firewall and router configurations. The standard has even taken into account properly securing the DMZ, as it is the stop shop for all the connection between the internal network and the untrusted network. In addition, the organization should not only monitor inbound traffic but also outbound traffic from the CDE to the Internet. These requirements are discussed in great detail as 1.1.1, 1.2.1, 1.1.6, 1.3.1, 1.3.2, 1.3.6.
Solution with SIEM: The first thing the organization should do is to collect logs from all perimeter security devices, such as firewalls, routers, and IDS/IPS. Then the organization should adopt the following practices to tackle perimeter security requirements of PCI-DSS:
- Organizations should develop SIEM use cases to detect all the unauthorized network connections to/from an organization’s IT assets. For removing the false positives from this use case, correlate the results of unauthorized access with the change management process to remove any synch up issue with any change allowed.
- Organizations should watch for insecure protocols, services and ports opened on terminal devices.
SIEM use case to check how traffic is flowing across the DMZ to/from the internal but publicly accessible services, etc. This can be implemented by implemented by configuring flows monitoring. Analyze the flows data and check out for inbound and outbound traffic not destined for legitimate servers.
Manage User Identity
PCI-DSS places great emphasis on managing users’ identities, such as addition, modification, and deletion of user IDs credentials. In addition, there should be a monitoring check related to access by terminated users. PCI-DSS also took into account monitoring vendor IDs, guest accounts etc. These requirements are listed as requirements 8.1.2, 10.2.5, 12.5.4, 8.1.3, 8.1.4, 8.1.5, 8.1.6, 10.2.4.
Solution with SIEM: This is the most overlooked aspect by many organizations and thus most difficult to maintain. However, organizations should maintain these checks with SIEM as below:
Develop SIEM use case for any event that results in addition, deletion, and modification of user IDs, credentials, and other identifier objects. For example :
- EventID: 4720 – User Creation
- EventID: 4726 – User Deletion
- EventID: 5136 – User Details modification
- Strictly monitor all authentication events made by terminated users.
- Monitor access from any activity related to dormant accounts.
- Monitoring invalid access attempts for example by monitoring EventID 4625 in Windows and /var/log/secure file string such as “authentication failed”. A possible query for this use case in Splunk is “sourcetype=”WinEventLog:Security” (EventCode=4625 AND “Audit Failure”) NOT (User_Name=”*$” OR Account_Name=”*$”) NOT Failure_Code=0x19 | stats count by Account_Name | where count > 2″ .
End Point Security
End point security is also a core area to rexamine when monitoring PCI DSS. PCI-DSS has some grueling requirements for end point host security. All the unnecessary services, scripts should be disabled on the endpoint host. In addition, PCI-DSS emphasizes the use of antivirus solutions on the host. These solutions need not only to be deployed but should also be maintained and fully patched. This may look simple but because of lack of baseline documentation, this becomes very difficult for organizations to maintain. These requirements are stated as 2.2.5, 5.1, 5.2, and 5.3. However, SIEM can be leveraged for this:
- Make sure that antivirus logs are collected by the SIEM solution. Then look out for QID that says “protection disabled” in the logs.
- A reference list can be made which includes all the insecure ports, services etc. while a search runs.
- Third party feeds should be integrated, which will also detect any port/protocols and services known for vulnerabilities.
- Search antivirus logs for “QID” related to OLD DATABASE or OLD SIGNATURE. Please note that different AV vendors will have different strings explain this QID.
PCI-DSS has some auditing requirements, which can also be attained through SIEM solutions. When PCI-DSS discusses auditing, the scope is limited to the cardholder environment. This involves auditing the root or administrative privileges, as well as creation and deletion of system level objects. More importantly, PCI-DSS also looks for any interference with the logs themselves. For these auditing requirements, SIEM can help as:
- Systems logs should be collected and all access with any individual with root or admin privileges.
- Enable auditing on the audit files and check for the access related events.
- Alert when system-level objects, such as database, tables or stored procedures are created or deleted. For this, Enable auditing, search for the events related to creation and deletion of system-level objects, and then include those events in the rule.
- Alert when audit services are stopped on a compliance host.
Please note that these are not the only requirements that can be handled with SIEM but these are some of the straightforward ones.