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.

 

 

OSSEC INSTALLATION

STEP 1:

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:      - 8.8.8.8      - 8.8.4.4    - 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:

Leave a Reply

Your email address will not be published. Required fields are marked *