PCI DDS Compliance v 3.0

If you’re dealing with any form of payment card data, starting on January 2015, security audits will need to prove PCI 3.0 compliance. Banks, card brands and regulators are stepping up action in the face of recent significant breaches in name brand companies. If you are running the unsupported open source agent for event logging, you will most likely fail your audit as they do not address several key aspects of the PCI DSS V3.0 audit requirements:

1. There is no technical, product, vendor or customer support – i.e. you are on an unsupported security tool/platform.
2. More than half of the critical event log data is in the custom event logs which are not processed by the open source agents, allowing forensic evidence to be lost.**
3. Best Practices, such as event data encryption, TCP protocols and caching in case of network outages or spikes, are not available.
To take a crucial step towards compliance, we encourage you to try the Snare Enterprise Agents, which are used by the world’s leading organizations and enterprises in finance, defense, e-commerce and retail.

Snare Enterprise Agents assist with PCI DSS compliance by collecting all applicable event logs out-of-the-Box.  To learn how the Snare Enterprise agent is used to address PCI, click on PCI DSS Best Practices with Snare Enterprise Agents.

For Snare Server, sample PCI objectives may be loaded. To do this go to SYSTEM\Administrative Tools\Snare Server Configuration Wizard\ and navigate to the section on additional objectives near the bottom of the list.  Select the last option which will import from the local system. Once loaded you will now have the extra objectives in the Reports Menu under Compliance Pack, in there are: NISPOM, SOX and PCI.  From there you can copy/clone these objectives and customise to suit your needs.

 

** Warning about Open Source logging: You risk missing more than half of your critical logs

The Open Source agents will not stand up to compliance or auditing standards (e.g. PCI), with more than half of the critical logs not being captured, including privileged user activity, system and Group Policy changes, dhcp logs, system time changes, host firewall policy changes and access logs, terminal service access, and print logs, just to name a few. Therefore, using open source versions will risk failing audits and will not be able to detect all serious malicious attacks or unauthorized changes on your systems. This can lead to loss of customer data, major brand damage and significant financial penalties depending upon which standard has been failed and the degree of damage caused. There are approximately 70 system event logs which you will not collect details from.

/by

Fear not, Snare is not affected by POODLE

The POODLE attack (which stands for “Padding Oracle On Downgraded Legacy Encryption”) is a man-in-the-middle exploit which takes advantage of Internet and security software clients’ fallback to SSL 3.0.

The Snare Agents are not affected by POODLE as it requires a cookie injection from the client and Snare does not use cookies for our connections.

Since it’s a client side attack, and would need some man-in-the-middle attack on the internal network which is low risk, and given most Snare Servers are on restricted networks, then it is low risk.

For additional information review US-CERT TA14-290A.

/by

The Bash vulnerability and how it affects the Snare product suite

All versions of the Snare Server prior to v6.3.5 are running a vulnerable version of Bash, known as the Shellshock vulnerability (CVE-2014-6271, CVE-2014-7169, CVE-2014-7187, CVE-2014-7186) (http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-7169.html). If you are running a previous version, it is recommended that you upgrade your Snare Server to version 6.3.5 (released 29-SEP-2014) as soon as possible to ensure that your server is not affected by this vulnerability.

The risk level of vulnerable versions is low, as the Snare Server web server is not running a vulnerable server configuration, although other components (such as SSH) may have opened up the possibility for abuse. An ssh connection to a Snare Server will still require the authentication to be valid for the connecting user in attempting the exploit. Given a Snare Server command line access is usually restricted to the admin users only this issue would be a low risk activity. If customers have other users that have command line access to their Snare Servers then the likelihood of an attack is much greater. As per normal security practices all admin console access (web and SSH) to the Snare Server should be restricted to only users who require access as part of their job function.

v4 and v5 Snare Servers: For these customers who are unable to upgrade to v6, we recommend auditing your access controls to ensure only authorised access to the Snare Server. A hot fix is available for v4 and v5 Snare Servers. Please download from the Secure Area. A document on the hot fix is available here. If you cannot access the Secure Area then please see your Snare representative for support.

Please note that all Snare Agents are NOT affected by this Bash vulnerability.

/by