Tag Archives: PCI-DSS

PCI-DSS v3.1 Compliance with Zero cost

ossec-hidsWhat is OSSEC?

OSSEC is an Open Source Host-based Intrusion Detection System that performs log analysis, file integrity checking, policy monitoring, rootkit detection, real-time alerting.

Can I address PCI-DSS v3.1 requirements using OSSEC?

Yes. By Installing and Configuring OSSEC in the VPC, we can easily address the below PCI-DSS v3.1 requirements with zero cost.

PCI-DSS v3.1 requirements related to OSSEC

PCI DSS Requirements Testing Procedures Guidance
10.2 Implement automated audit trails for all system components to reconstruct the following events: 10.2 Through interviews of responsible personnel, observation of audit logs, and examination of audit log settings, perform the following:


Generating audit trails of suspect activities alerts the system administrator, sends data to other monitoring mechanisms (like intrusion detection systems), and provides a history trail for post-incident follow-up. Logging of the following events enables an organization to identify and trace potentially malicious activities


10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).


10.5.5 Examine system settings, monitored files, and results from monitoring activities to verify the use of file-integrity monitoring or change-detection software on logs.


File-integrity monitoring or change-detection systems check for changes to critical files, and notify when such changes are noted. For file-integrity monitoring purposes, an entity usually monitors files that don’t regularly change, but when changed indicate a possible compromise.


10.6.1 Review the following at least daily:

·  All security events

· Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

· Logs of all critical system components

· Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).


10.6.1.a Examine security policies and procedures to verify that procedures are defined for reviewing the following at least daily, either manually or via log tools:

·         All security events

·          Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

·         Logs of all critical system components

·         Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.)


Many breaches occur over days or months before being detected. Checking logs daily minimizes the amount of time and exposure of a potential breach.


Daily review of security events—for example, notifications or alerts that identify suspicious or anomalous activities—as well as logs from critical system components, and logs from systems that perform security functions, such as firewalls, IDS/IPS, file-integrity monitoring (FIM) systems, etc. is necessary to identify potential issues. Note that the determination of “security event” will vary for each organization and may include consideration for the type of technology, location, and function of the device. Organizations may also wish to maintain a baseline of “normal” traffic to help identify anomalous behavior.

10.6.1.b Observe processes and interview personnel to verify that the following are reviewed at least daily:

·  All security events

·  Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD

· Logs of all critical system components

· Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.).

11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.

Keep all intrusion-detection and prevention engines, baselines, and signatures up to date.

11.4.a Examine system configurations and network diagrams to verify that techniques (such as intrusion-detection systems and/or intrusion-prevention systems) are in place to monitor all traffic:

·  At the perimeter of the cardholder data environment

·  At critical points in the cardholder data environment.

Intrusion detection and/or intrusion prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools, Trojans, and other malware), and send alerts and/or stop the attempt as it happens. Without a proactive approach to unauthorized activity detection, attacks on (or misuse of) computer resources could go unnoticed in real time. Security alerts generated by these techniques should be monitored so that the attempted intrusions can be stopped.


11.4.b Examine system configurations and interview responsible personnel to confirm intrusion-detection and/or intrusion-prevention techniques alert personnel of suspected compromises.


11.4.c Examine IDS/IPS configurations and vendor documentation to verify intrusion-detection and/or intrusion-prevention techniques are configured, maintained, and updated per vendor instructions to ensure optimal protection.
11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Note: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change-detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

11.5.a Verify the use of a change-detection mechanism within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities.


Examples of files that should be monitored:

 · System executables

· Application executables

· Configuration and parameter files

· Centrally stored, historical or archived, log and audit files

· Additional critical files determined by entity (for example, through risk assessment or other means).


Change-detection solutions such as file-integrity monitoring (FIM) tools check for changes to critical files, and notify when such changes are detected. If not implemented properly and the output of the change-detection solution monitored, a malicious individual could alter configuration file contents, operating system programs, or application executables. Unauthorized changes, if undetected, could render existing security controls ineffective and/or result in cardholder data being stolen with no perceptible impact to normal processing.


11.5.b Verify the mechanism is configured to alert personnel to unauthorized modification of critical files, and to perform critical file comparisons at least weekly.


12.10.5 Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring systems.


12.10.5 Verify through observation and review of processes that monitoring and responding to alerts from security monitoring systems, including detection of unauthorized wireless access points, are covered in the incident response plan.


These monitoring systems are designed to focus on potential risk to data, are critical in taking quick action to prevent a breach, and must be included in the incident-response processes.





Install necessary package

apt-get update

apt-get install build-essential inotify-tools

Step 2 — Download and Verify OSSEC

wget -U ossec http://www.ossec.net/files/ossec-hids-2.8.1.tar.gz

Step 3 — Install OSSEC

OSSEC can be installed in serveragentlocal or hybrid mode. The below installation steps is meant for monitoring the instances where OSSEC agent is installed.

Before installation can start, we have to expand the file

tar -zxf ossec-hids-2.8.1.tar.gz
cd ossec-hids-2.8.1

To see the contents of the directory that you’re now in, use the ls command by typing:

ls –l

we have to see these files and directories:

drwxrwxr-x  4  4096 Sep  8 21:03 active-response
-rw-rw-r--  1   542 Sep  8 21:03 BUGS
-rw-rw-r--  1   289 Sep  8 21:03 CONFIG
drwxrwxr-x  6  4096 Sep  8 21:03 contrib
-rw-rw-r--  1  3196 Sep  8 21:03 CONTRIBUTORS
drwxrwxr-x  4  4096 Sep  8 21:03 doc
drwxrwxr-x  4  4096 Sep  8 21:03 etc
-rw-rw-r--  1  1848 Sep  8 21:03 INSTALL
-rwxrwxr-x  1 32019 Sep  8 21:03 install.sh
-rw-rw-r--  1 24710 Sep  8 21:03 LICENSE
-rw-rw-r--  1  1664 Sep  8 21:03 README.md
drwxrwxr-x 30  4096 Sep  8 21:03 src


To install OSSEC type the below command  ./install.sh Select language is English, press ENTER. Otherwise, type the two letters for your language and press ENTER.

(en/br/cn/de/el/es/fr/hu/it/jp/nl/pl/ru/sr/tr) [en]:

After selecting the language, you should see this:

OSSEC HIDS v2.8 Installation Script – http://www.ossec.net  You are about to start the installation process of the OSSEC HIDS. You must have a C compiler pre-installed in your system. If you have any questions or comments, please send an e-mail to dcid@ossec.net (or daniel.cid@gmail.com).   – System: Linux kuruji 3.13.0-36-generic  – User: root  – Host: kuruji   — Press ENTER to continue or Ctrl-C to abort. —

After pressing ENTER, you should get:

1- What kind of installation do you want (server, agent, local, hybrid or help)? local

Type local and press ENTER. You should get:

  - Local installation chosen. 2- Setting up the installation environment.   - Choose where to install the OSSEC HIDS [/var/ossec]:

Accept the default and press ENTER. After that, you’ll get:

    - Installation will be made at  /var/ossec . 3- Configuring the OSSEC HIDS.   - Do you want e-mail notification? (y/n) [y]:

Press ENTER.

  - What's your e-mail address? test@example.com

Type the email address where you want to receive notifications from OSSEC.

  - We found your SMTP server as: mail.example.com.  - Do you want to use it? (y/n) [y]: --- Using SMTP server:  mail.example.com.

Press ENTER unless you have specific SMTP server settings you want to use.

Now’s time to let OSSEC know what checks it should be running. In response to any prompt from the script, accept the default by pressing ENTER.

ENTER for the integrity check daemon.

- Do you want to run the integrity check daemon? (y/n) [y]: - Running syscheck (integrity check daemon).

ENTER for rootkit detection.

  - Do you want to run the rootkit detection engine? (y/n) [y]: - Running rootcheck (rootkit detection).

ENTER for active response.

  - Active response allows you to execute a specific command based on the events received.      Do you want to enable active response? (y/n) [y]:    Active response enabled.

Accept the defaults for firewall-drop response. Your output may show some IPv6 options – that’s fine.

  Do you want to enable the firewall-drop response? (y/n) [y]: - firewall-drop enabled (local) for levels >= 6    - Default white list for the active response:      -      -    - Do you want to add more IPs to the white list? (y/n)? [n]:

You may add your IP address here, but that’s not necessary.

OSSEC will now present a default list of files that it will monitor. Additional files can be added after installation, so press ENTER.

Step 4 — Start OSSEC

By default OSSEC is configured to start at boot, but the first time, you’ll have to start it manually.

If you want to check its current status, type:

/var/ossec/bin/ossec-control status

That tells you that none of OSSEC’s processes are running.

To start OSSEC, type:

/var/ossec/bin/ossec-control start

You should see it starting up:

Starting OSSEC HIDS v2.8 (by Trend Micro Inc.)…Started ossec-maild…Started ossec-execd…Started ossec-analysisd…Started ossec-logcollector…Started ossec-syscheckd…Started ossec-monitord…Completed.

If you check the status again, you should get confirmation that OSSEC is now running.

/var/ossec/bin/ossec-control status

This output shows that OSSEC is running:

ossec-monitord is running...ossec-logcollector is running...ossec-syscheckd is running...ossec-analysisd is running...ossec-maild is running...ossec-execd is running...

Right after starting OSSEC, you should get an email that reads like this:

OSSEC HIDS Notification.2014 Nov 30 11:15:38 Received From: ossec2->ossec-monitordRule: 502 fired (level 3) -> "Ossec server started."Portion of the log(s): ossec: Ossec started.

OSSEC is successfully Installed. We will see how to install and configure agents in the next post.







Share this:

What’s new in PCI-DSS v3.1 update

PCIPCI SSC has announced that the PCI DSS 3.1 update.

This update makes the following summary clarifications about the use of SSLv3 and TLS 1.0 in PCI relevant environments:

  • New implementations must use alternatives to SSL and early TLS.
  • Organizations with existing implementations of SSL and early TLS must have a risk mitigation and migration plan in place.
  • Prior to June 30, 2016, Approved Scanning Vendors (ASVs) may document receipt of an organizations risk mitigation and migration plan as an exception in the ASV Scan Report (in accordance with the ASV Program Guide).
  • Point of Sale (POS) or Point of Interaction (POI) devices that can be verified as not being susceptible to all known exploits of SSL and early TLS may continue to use these protocols as a security control after June 30, 2016.

April 15, 2015 brought us the much-anticipated release of the PCI DSS standard from the PCI Council.  As SSL and early TLS are no longer considered strong cryptography, this release describes how the industry is to move forward in regard to the use of SSL and early TLS versions and how current PCI DSS status is impacted.

The PCI DSS requirements that are directly affected by this update are:

  • Requirement 2.2.3: Implement additional security features for any required services, protocols, or daemons that are considered to be insecure;
  • Requirement 2.3: Encrypt all non-console administrative access using strong cryptography; and
  • Requirement 4.1: Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

Does this mean that if one has used SSL to address the above requirements, that one now fails these requirements?  No, it does not.  The updated standard allows for a timeframe in which SSL and early TLS can be phased out.  The updated standard specifies a deadline of June 30, 2016, after which SSL and early TLS must no longer be used.  However, a few caveats apply:

  • Prior to June 30, 2016, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
  • Effective immediately, new implementations must not use SSL and/or early TLS.
  • POS POI terminals (and the SSL/TLS termination points to which they connect) verified as not susceptible to any known exploits for SSL and/or early TLS may continue using these weaker protocols after June 30, 2016.

What are SSL and early TLS?

SSL v3.0 has existed for at least 15 years.  It was superseded by TLS v1.0 which was in turn replaced by TLS v1.1 and TLS 1.2.  The problem is that the application that supported SSL v3.0 and TLS v1.0 did not remove support for these protocol versions.  They simply added support for TLS v1.1 and later versions.  This was done to maintain backward compatibility with consumer web browsers, POS terminals, and legacy applications that may not have been upgraded to support TLS v1.1+ versions.  This was fine until exploits that could not be fixed were discovered in SSL and early TLS.  Therefore, for the purpose of the updated PCI DSS 3.1 standard, SSL is defined as any SSL v3.0 or earlier and early TLS is defined as TLS v1.0.

What is “new” versus “existing” implementation?

Understanding the difference is critical because an “existing” implementation may continue to use the insecure protocols up until June 30, 2016, while a “new” implementation may not.  According to supplemental guidance from the PCI SSC, an “existing” implementation is one where there is a pre-existing dependency or use of the vulnerable protocols (SSLv3.0/TLSv1.0), and a “new” implementation is one where there is no existing dependency on the use of the vulnerable protocols.

Practically speaking, if an organization currently uses SSLv3.0/TLSv1.0 and these weaker protocols are required to continue operations, then the organization may continue using these protocols. However, it is essential to consider each case individually.  Consider the following examples:

Example 1:  A payment gateway supports an API that accepts transactions from terminals or POS software communicating over SSLv3.0/TLSv1.0.  This payment gateway can continue to use these weaker protocols until June 30, 2016.  Even if the payment gateway provider builds a new API that supports a stronger version of TLS, weaker protocols can continue to be used until the June deadline as long as continued operations depend on supporting legacy software and terminals that rely on the weaker protocols.

Example 2:  A payment gateway provides access to a virtual terminal interface or to a management portal interface.  Since an end-user’s web browser is not considered a “pre-existing” dependency, this payment gateway cannot continue to support SSLv3.0/TLSv1.0 and must migrate to stronger protocols at once.

In fact, for those who operate an e-Commerce site or portal, it is mandatory to update immediately to more secure protocols unless sufficient evidence shows that the application or server software must continue to support weaker protocols.

If weaker protocols must continue to be used, an organization must develop a Risk Mitigation and Migration Plan.  Only by developing this plan can an organization that continues to use the weaker SSLv3.0/TLSv1.0 meet the current PCI DSS 3.1 requirements.  The plan must:

  • detail each scenario where insecure protocols are used;
  • define the existing risk reduction controls to prevent and detect attacks;
  • describe methods in place to monitor for new vulnerabilities associated with the insecure protocols;
  • describe change control methods to ensure that the insecure protocols are not allowed to be implemented into new environments; and
  • Outline how the environment will be migrated to meet the June 30, 2016 deadline.

Why are POI terminal deployments exempt?

Point of Interaction (POI) devices that support the weaker SSLv3.0/TLSv1.0 are not subject to the June 30, 2016 deadline.  Weaker protocols can continue to be used because POI devices are not as prone to known vulnerability exploits.  Exploits generally require that a device support multiple client side connections, JavaScript, cookies, or that the end-user software be a web browser.  Since POI devices do not operate in this manner, they are not as susceptible to known attack vectors.  In addition, the device communications adhere to specified message types that limit exposure to replay attacks.  However, should new vulnerabilities be discovered, this exemption for POI devices can readily disappear.

What action should I take going forward?

If possible, upgrade or configure systems that only use TLS 1.1 or greater and disable fall back support to lower protocols.  It is important to note that proper configuration of TLS 1.1 or greater is critical and is fully outlined in the NIST 800-52 rev1 publication.  A key requirement is ensuring proper cipher suites are utilized.  These cipher suites are critical for mitigating attack scenarios where weaker cipher suites are exploited.

If one must continue to use weaker protocols, then monitoring the use of these weaker protocols is critical.  IPS/IDS or other alerting technologies (reverse-proxies) can detect multiple requests for protocol downgrades and flag an attack attempt.  In addition, firewalls and other network access control devices can limit access to services that support weak protocols.

Migrating away from SSLv3/TLS1.0 is not an easy task.   Otherwise, new releases of the protocols would have promptly replaced the older protocols. Instead, migration is complex and difficult because of the ubiquitous nature of SSL. It is found in firewalls, routers, POS terminals and applications that communicate across networks. SSL dependency is far-reaching, as this protocol is also found in devices and applications that extend outside the payment industry.  Although updating to stronger protocols may be daunting and time-consuming, this migration is necessary to ensure compliance with updated PCI standards and ultimately, to have a stronger defense against unauthorized network intrusions

What is the risk?

SSL/TLS encrypts a channel between two endpoints (for example, between a web browser and web server) to provide privacy and reliability of data transmitted over the communications channel. Since the release of SSL v3.0, several vulnerabilities have been identified, most recently in late 2014 when researchers published details on a security vulnerability (CVE-2014-3566) that may allow attackers to extract data from secure connections. More commonly referred to as POODLE (Padding Oracle On Downgraded Legacy Encryption), this vulnerability is a man-in-the-middle attack where it’s possible to decrypt an encrypted message secured by SSL v3.0.

The SSL protocol (all versions) cannot be fixed; there are no known methods to remediate vulnerabilities such as POODLE. SSL and early TLS no longer meet the security needs of entities implementing strong cryptography to protect payment data over public or untrusted communications channels. Additionally, modern web browsers will begin prohibiting SSL connections in the very near future, preventing users of these browsers from accessing web servers that have not migrated to a more modern protocol

How does the presence of early TLS impact ASV scan results?

SSL v3.0 and early TLS contain a number of vulnerabilities, some of which currently result in a score of 4.3 on the CVSS (Common Vulnerability Scoring System). The CVSS is defined by NVD (National Vulnerability Database) and is the scoring system ASVs are required to use. Any Medium or High risk vulnerabilities (i.e. vulnerabilities with a CVSS of 4.0 or higher) must be corrected and the affected systems re-scanned after the corrections to show the issue has been addressed.

However, as there is no known way to remediate some of these vulnerabilities, the recommended mitigation is to migrate to a secure alternative as soon as possible. Entities that are unable to immediately migrate to a secure alternative should work with their ASV to document their particular scenario as follows:

  • Prior to June 30, 2016: Entities that have not completed their migration should provide the ASV with documented confirmation that they have implemented a Risk Mitigation and Migration Plan and are working to complete their migration by the required date. Receipt of this confirmation should be documented by the ASV as an exception under “Exceptions, False Positives, or Compensating Controls” in the ASV Scan Report Executive Summary.
  • After June 30, 2016: Entities that have not completely migrated away from SSL/early TLS will need to follow the Addressing Vulnerabilities with Compensating Controls process to verify the affected system is not susceptible to the particular vulnerabilities. For example, where SSL/early TLS is present but is not being used as a security control (e.g. is not being used to protect confidentiality of the communication).





Share this: