Showing posts with label nnt change tracker. Show all posts
Showing posts with label nnt change tracker. Show all posts

Saturday, 13 November 2010

PCI DSS Section 10 - Backup event logs centrally

There are typically two concerns that need to be addressed - first, "what is the best way to gather and centralize event logs?" And second, "what do we need to do with the event logs once we have them stored centrally? (And how will we cope with the volume?)"

To the letter of the PCI DSS, you are obliged to make use of event and audit logs in order to track user activity for any device within scope i.e. all devices which either 'touch' cardholder data or have access to cardholder data processing systems. The full heading of the Log Tracking section of the PCI DSS is as follows -

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

Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult without system activity logs.

Given that many PCI DSS estates will be geographically widespread it is always a good idea to use some means of centralizing log messages, however, you are obliged to take this route anyway if you read section 10.5.3 of the PCI DSS -

"Promptly back up audit trail files to a centralized log server or media that is difficult to alter"

The first obstacle to overcome is the gathering of event logs. Unix and Linux hosts can utilize their native syslogd capability, but Windows servers will need to use a third party Windows Sylog agent to transfer Windows Event Logs via syslog - you can download a free copy of our Log Tracker Agent via this link.

This will ensure all event log messages form Windows servers are backed up centrally in accordance with the PCI DSS standard. Similarly, Oracle and SQL Server based applications will also require a Syslog Agent to extract log entries for forwarding to the central syslog server. Similarly, IBM z/OS mainframe or AS/400 systems will also need platform-specific agent technology to ensure event logs are backed up.

Of course, Firewalls and Intrusion Protection/Detection System (IPS/IDS), as well as the majority of switches and routers all natively generate syslog messages.

So in terms of our two initial questions, we have fully covered the first, but what about the next logical question of 'What do we do with - and how do we cope with - the event logs gathered?'

"PCI DSS Section 10.6 Review logs for all system components at least daily"

This is the part of the standard that causes most concern. If you consider the volume of event logs that may be generated by a typical firewall this can be significant, but if you are managing a retail estate of 800 stores with 7,500 devices within scope of the PCI DSS, the task of reviewing logs from devices is going to be impossible to achieve. This may be a good time to consider some automation of the process...?

The Security Information and Event Management or SIEM market as defined by Gartner covers the advanced generation of solutions that harvest audit and event logs, and then parse or interpret the events e.g. store events by device, event type and severity, and analyze the details within event logs as they are stored. In fact, the PCI DSS recognizes the potential value of this kind of technology

"Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6 of the PCI DSS"

SIEM technology allows event logs to be automatically and intelligently managed such that only genuinely serious security events are alerted. The best SIEM technology can distinguish between true hacker activity running a 'brute force' attack and a user who has simply forgotten their password and is repeatedly trying to access their account. Naturally there is an amount of customization required for each environment as every organization's network, systems, applications and usage patterns are unique as are the corresponding event log volumes and types.

The PCI Event log management process can be approached in three stages, ensuring that there is a straightforward progression through becoming compliant with the PCI DSS standard and becoming fully in control of your PCI Estate. The tree phases will assist you in understanding how your PCI Estate functions normally and, as a result, placing all genuine security threats into the spotlight.

1. GATHER - Implement the SIEM system and gather all event logs centrally - the SIEM technology will provide a keyword index of all events, reported by device type, event severity and even with just the basic, pre-defined rules applied, the volumes of logs by type can be established. You need to get familiar with the types of event log messages being collected and what 'good' looks like for your estate.

2. PROFILE - Refinement of event type identification and thresholds - once an initial baselining period has been completed we can then customize rules and thresholds to meet the profile of your estate, with the aim of establishing a profiled, 'steady-state' view of event types and volumes. Even though all logs must be gathered and retained for the PCI DSS, there is a large proportion of events which aren't significant on a day-to-day basis and the aim is to de-emphasize these in order to promote focus on those events which are significant.

3. FOCUS - simple thresholding for event types is adequate for some significant security events, such as anti-virus alerts or IPS signature detections, but for other security events it is necessary to correlate and pattern-match combinations and sequences of event. SIEM only becomes valuable when it is notifying you of a manageable number of significant security events.

It is important to note that even when certain events are being de-emphasized, these are still being retained in line with the PCI DSS guidelines which are to retain logs for 12 months. At least 3 months of event logs must be in an on-line, searchable format for at least 3 months, and archived for 12 months.

Again, the archived and on-line log repositories must be protected from any editing or tampering so write-once media and file integrity monitoring must be used to preserve log file integrity.

It's much easier to see it in practise than read about it so please get in touch for a quick overview by webex - mail a request to info@newnettechnologies.com or go to http://www.newnettechnologies.com/contact-us.html


Friday, 23 July 2010

The Top Ten of Server Change and Configuration Management

The concept of a Server Change and Configuration Management Policy is simple - define what 'good' IT service looks like, then maintain your Server estate in this state.
It is vitally important to keep in check all relevant servers configuration settings, performance metrics and application response times that together govern the quality and consistency of delivered IT service levels to the business.

However, while it is obvious that governing the performance and health of your servers is important, the need to ensure your servers are compliant with security and external corporate governance legislations is now equally necessary.

Corporate Governance policies such as Sarbanes Oxley (SOX), GLBA, NERC, PCI DSS, HIPAA, MiFID, SAS 70, and Basel II have all been introduced to ensure minimum levels of security and integrity are maintained for company financial information and any stored personal details of customers.
Your Servicedesk or Helpdesk system has a role to play, typically playing an integral role in any ITIL Change and Configuration Management Process, providing reconciliation data for any planned changes to any configuration item, including servers.

The Top Ten of Server Configuration Management
1. Server Performance Management - Measure and control all parameters affecting IT Service Delivery, including configuration settings, server health and user experience
2. Server Compliance Audits - Take steps to automate the audit of your server estate in order to provide auditors with accurate details of all security and access controls for compliance with all Corporate Governance legislations, such as PCI DSS, SOX, GLBA, NERC, HIPAA, MiFID, SAS 70, Basel II
3. Virtualization - when virtualising servers in order to facilitate datacentre moves, service continuity provision and to reduce running costs, remember that you are also introducing another layer of configuration management at the VM Host level that must equally be audited to ensure it is compliant with corporate governance policies
4. Compare 'one server to many' and pinpoint all differences between a 'policy compliant' (i.e. 'working') server and those that aren't -all key changes and deviations will be instantly identified and reported
5. Software Inventory Management - A Configuration Management solution should cover Server inventory management, server asset management, server performance management and server configuration management
6. Server Security Management - Best practise is to limit the User Accounts to the minimum and restrict access to Administrator accounts with Admin privileges but you also need to regularly check that Server User Accounts have not been modified, added or changed
7. Server File system Management - a key aspect of PCI DSS and other corporate governance policies is that core filesystem attributes have their integrity maintained, for instance, the Win32 folder should not be changed or modified and it is vital to regularly check this
8. Registry Settings - as the core repository of Server Configuration Settings, any Registry changes must be logged and analysed
9. Running Processes and Services/Service States - build a whitelist and blacklist of authorised/unauthorized process and services, together with any mandatory 'must run' or illegal 'never run' processes and services
10. Server Application Configuration Management - Together with the Windows Server Operating System, key server applications such as SQL Server, IIS, Exchange, Active Directory and Oracle all have numerous and complex configuration settings which also need to be audited for compliance with your configuration management policy

All the above change and configuration management tasks can be automated using change and configuration management software solutions, the best of which will cover servers together with change and configuration management of your desktop PCs and all network devices such as firewalls, switches and routers.