Tuesday, 21 December 2010

This is the second of a two part article intended to provide a backgrounder in understanding the PCI DSS. See Part 1 for the following
• What is it, and why is it important?
• The 12 Point PCI DSS
• So who exactly is subject to the PCI DSS?
Sounds like a lot of work and expense - what is the cost justification for the PCI DSS?

Trying to understand the actual cost of payment card fraud is not straightforward - by their very nature, fraudulent transactions are hidden.
Visa Europe report a level of fraud around 6 cents for every 100 spent. It is important to realize that this is the cost of fraud for Visa Europe itself (as opposed to the total cost associated with card fraud which would include lawsuit costs between merchants, acquirers and issuers). All the same, in 2009, those cards were used to make purchases and cash withdrawals to the value of more than 1.3 trillion. Doing the math, this would place an estimate on the cost of fraud to be 780M - just for Europe, and just for Visa.

In order to extrapolate these numbers, based on Visa Inc. Q1 FY 2010 earnings statement, Visa's global network processed payments totaling $4.4 trillion. Assuming Visa held a 38.3% market share of the credit card marketplace and 60.7% of the debit card market, the total value of payment card transactions for the world would be around $8.5 trillion.

If Visa's notional 6 cents for every dollar formula was applied, this would give an estimated value of fraud for the global payment card market of $5.1 billion - although again, this is purely for the card companies themselves.
Compare this figure with other sources that suggest the overall cost of UK Plastic card fraud was nearly £610m in 2008, an increase of more 14% over 2007 (figures published by APACS, the UK Payment Industry). Extrapolating this number at the same 14% per annum increase would give a 2010 figure of over £730M (approx. $1.2 Billion) just for the UK. Figures from the UK Card Association claim card fraud reduced by 20% in their most recent figures, based on January to June 2010 so these figures may be lower than estimated.

Global estimates for the cost of Online fraud - including identity theft and all payment-card abuse and organized crime - reached around $78bn last year (according to research house Global Uncertainties). If you are reading this as a Card Merchant though, the figures that will be more interesting for you are what the potential costs for you are. For Visa members, failure to report any suspected or confirmed loss of transaction data the member will be subject to a penalty of $100,000 per incident, rising to $500,000 depending on the scale and seriousness of the breach. Regarding remediation costs, most estimates cost this at between $90 and $302 per record.

The cost of compliance may also increase by way of making a compromised Tier 2, 3 or 4 merchant subject to Tier 1 merchant PCI DSS requirements, with the more stringent auditing process being required.
The absolute penalty for a payment brand is to disqualify a merchant from being able to process card transactions.

It is worth mentioning that in one of the few publicized breaches, Heartland Payment Systems (corporate.visa.com/media-center/press-releases/press974.jsp) are agreeing to pay $60M in compensation to card issuers that have suffered losses as a result of the criminal breach of Heartland's systems. The loss of customer trust and the corporate shame of being exposed as an organization that has compromised their customers' personal data could ultimately be far more expensive.

What happens in the event of us being breached?
Visa provides the following Steps for 'compromised entities'
1. Immediately contain and limit the exposure. Prevent further loss of data by conducting a thorough investigation of the suspected or confirmed compromise of information.
2. Alert all necessary parties immediately. Including
• Your internal information security group and incident response team.
• Your merchant bank.
• Visa Fraud Investigations and Incident Management group
• Your local office of the United States Secret Service
3. Provide all compromised Visa, Interlink, and Plus accounts to your merchant bank within 10 business days
4. Within 3 business days of the reported compromise, provide an Incident Report document to your merchant bank

Is PCI-DSS Compliance Required by Law?
The Minnesota Plastic Card Security law doesn't make PCI a legal requirement but it does mandate that companies storing credit card information that subsequently suffer a breach will need to reimburse the card issuer for any costs associated with the breach. In other words, it reinforces a key PCI requirement rather than legislating for it.

Similarly, Nevada has the Security of Personal Information Law and the Nevada Senate Bill 227 in which SB 227 Amendment specifically states a requirement to comply with the PCI-DSS.
Also, The Washington House Bill 1149 (Effective Jul 01, 2010) "recognizes that data breaches of credit and debit card information contribute to identity theft and fraud and can be costly to consumers."
Massachusetts is introducing 201 CMR 17.00 which seemingly borrows heavily from the PCI DSS.
Several other states are making attempts to enforce PCI DSS-aligned legislation such as Texas, California, Illinois and Connecticut.
Beyond these specific examples of PCI DSS-aligned laws the overwhelming majority of US states, Puerto Rico and the Virgin Islands have legislation that requires disclosure of data breaches.

Summary
Understanding the PCI DSS and how to implement it for your organization will take time, care and attention but many of the measures required can be automated and simplified using contemporary software technology.

What is it, and why is it important?

The PCI DSS was formulated by the payment card companies such as Visa and MasterCard in response to the growing number of instances of theft and misuse of payment card details. The first version of the PCI DSS was released in December 2004 and mandates a wide range of measures required to ensure the protection of payment card data.

The measures are summarized in the 12 section PCI DSS but a high-level overview can be broken down into 3 main areas

IT Security Best Practices (masking of card data within applications, configuration ‘hardening’, regular updates to password and security keys, regular vulnerability scans and penetration tests , review of all security and audit logs)

General Security Best practices (such as physical building security measures and personnel awareness of IT Security measures)

Today, the PCI Security Standards Council has been established by the major payment card brands and is the body “responsible for the development, management, education, and awareness of the PCI Security Standards”.

So who exactly is subject to the PCI DSS?

Regardless of what the tangible cost of payment card fraud actually is, there is no alternative for any card merchant but to comply with the PCI DSS. However, the burden of proving your compliance with the standard does vary according to the volume of transactions being processed.

Any merchant storing, processing or transmitting Primary Account Numbers (PAN) must comply with the PCI DSS.

Processing is often one of the key qualifiers in that, a PC used to access a secure on-line payment portal can still be defined as ‘within scope’ of the PCI DSS which means even small organizations are still subject to the PCI DSS. For instance, card ‘skimming’ techniques are widespread, generally targeting the card reader or PIN entry device, or via software installed on the PC making the transaction.

The PAN must be rendered unreadable while the Cardholder Name, Service Code and Expiration date can be stored in readable format.

Card data that absolutely must not be stored comprises

the Track 1 and Track 2 data (all the cardholder and card data is stored within two tracks on the card magnetic stripe and chip embedded on chip and pin cards)

the Card Verification Value (CVV – typically the three digits printed onto the card signature strip) and of course

the PIN data (the card PIN number used to authorize a transaction on a Chip and PIN card)

All card transactions represent a risk, including ecommerce transactions. For Visa Merchants,

Level 1 - Merchants processing more than 6 million transactions annually are required to have an on-site PCI Data Security Assessment and quarterly network scans. On-site assessments may be completed internally or by an outside Qualified Security Assessor or QSA.

Level 4 Merchants process less than 20,000 e-commerce transactions annually and all merchants across channel up to 1,000,000 VISA transactions annually and are required to complete an annual self assessment and annual security scans.

See Part 2 of this article for the following

Sounds like a lot of work and expense – what is the cost justification for the PCI DSS?

What happens in the event of us being breached?Is PCI-DSS Compliance Required by Law?

Retail is a business sector that always works on tight margins and cost control for anyIT investment is subject to close scrutiny with value for money and return on investmentcarefully assessed.

There are seldom any shortcuts when it comes to security, especially when under PCI DSS Validation Requirements, Tier 1 Merchants (those transacting more than 6 million transactions each year) must be independently audited for compliance with the standard by an authorized Qualified Security Assessor (QSA).

AF Blakemore needed to balance the need to fully observe all sections of the PCI DSSmandate, while maintaining the highest levels of security and integrity of IT Systems,whilst at the same time minimizing expenditure and resource requirements - this is where NNT have been able to help.

Using built-in PCI DSS device hardening templates and continuous configuration statetracking ensures that EPoS and Back Office servers remain ‘hardened’ at all times. Crucially, this means that in terms of their PCI DSS vulnerability scanning obligations, AFB need only scan a small percentage of store sites, saving money and time without any compromise to security.

Jim Curtis concludes “We have easily saved in excess of £200K a year this way”

Why is this important? The principal benefit of using FIM technology is to ensure that malicious code has not been embedded within critical application and operating system files. The insertion of a ‘backdoor’ or Trojan into core program files is one of the more audacious and elegant forms of hacking, and also one of the most dangerous.

The PCI DSS (Payment Card Industry Data Security Standard) specifies the following “Deploy file-integrity monitoring software 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” and also that for log files “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)”.

Contemporary compliance management technology will provide pre-defined templates for all folders and files that should be tracked for File-Integrity, also allowing you to specify additional program folders and files unique to your environment, for instance, your core business applications.

File Integrity Monitoring technology conducts an initial inventory of all filesystems specified and ‘fingerprints’ all files using secure hashing technology, generating a unique checksum for each file. The system will then audit all files being tracked on a scheduled basis every 24 hours (even though the PCI DSS calls only for weekly checks) with any changes, additions, deletions or modifications being reported to you.

The latest generation of File Integrity Monitoring software also operate in a ‘live tracking’ mode for ultra-secure environments where file changes are detected and reported in real-time.

Other options to consider are to track and identify actual changes to file contents, useful when tracking configuration files to provide you with a complete audit trail of change history. The latest version of NNT Change Tracker includes a File Content Tracker – this can be applied to any form of files such as text, xml, php, javascript, aspnet etc

Tuesday, 7 December 2010

What is it, and why is it important?
The Payment Card Industry Data Security Standard was designed as a comprehensive list of best practice measures and processes for handling, processing, storing and transmitting payment card data.

The PCI DSS was formulated by the payment card companies such as Visa and MasterCard in response to the growing number of instances of theft and misuse of payment card details. The first version of the PCI DSS was released in December 2004 and mandates a wide range of measures required to ensure the protection of payment card data.

The measures are summarized in the 12 section PCI DSS but a high-level overview can be broken down into 3 main areas
• Active Technological Security Measures (firewalls, intrusion detection systems, anti-virus, file-integrity monitoring, data encryption)
• IT Security Best Practices (masking of card data within applications, configuration 'hardening', regular updates to password and security keys, regular vulnerability scans and penetration tests, review of all security and audit logs)
• General Security Best practices (such as physical building security measures and personnel awareness of IT Security measures)
Today, the PCI Security Standards Council has been established by the major payment card brands and is the body "responsible for the development, management, education, and awareness of the PCI Security Standards".

The 12 Point PCI DSS
The latest version of the PCI DSS is Version 2.0. It retains the same 12 Core requirements as previous versions of the standard, which in turn branch into more than 250 controls - the full standard can be accessed at pcisecuritystandards.org but the following is a summarized 'plain English' version
1. Use a firewall - typically the core 'Card Data Processing' systems are segregated from the Corporate Network using an internal firewall in addition to any external internet-facing firewall2. Secure system access through configuration hardening - use non-default passwords, SSL/TLS and SSH for any system access, disable unnecessary services and protocols to minimize accessibility3. Use masking and encryption of cardholder data to ensure that data is unreadable if stolen, but only ever store as little data as possible 4. Use encryption for any cardholder data when being transferred over public networks 5. Use anti-virus software, regularly updated 6. Increase the inherent security of all systems through configuration hardening i.e. remove known vulnerabilities through patching and configuration settings 7. Use Identity and Access Management controls to minimize access to cardholder data system on a strict 'need to know' basis 8. Assign a unique ID to each user and enforce strong authentication 9. Lock your doors - utilize physical security measures to restrict access to systems such as door locks, badge readers and video cameras 10. Track and monitor all access to all network resources and cardholder data - centrally backup event and audit log trails, especially for logons 11. Get a Vulnerability Scan and Penetration Test by an Approved Scanning Vendor performed every 3 months and after nay significant network change. Use file-integrity monitoring to protect critical system and configuration files 12. Adopt an Information Security Policy to ensure there is an appreciation of the PCI DSS objectives by all employees and contractors

So who exactly is subject to the PCI DSS?
Regardless of what the tangible cost of payment card fraud actually is, there is no alternative for any card merchant but to comply with the PCI DSS. However, the burden of proving your compliance with the standard does vary according to the volume of transactions being processed.
Any merchant storing, processing or transmitting Primary Account Numbers (PAN) must comply with the PCI DSS.
Processing is often one of the key qualifiers in that, a PC used to access a secure on-line payment portal can still be defined as 'within scope' of the PCI DSS which means even small organizations are still subject to the PCI DSS. For instance, card 'skimming' techniques are widespread, generally targeting the card reader or PIN entry device, or via software installed on the PC making the transaction.
The PAN must be rendered unreadable while the Cardholder Name, Service Code and Expiration date can be stored in readable format.

Card data that absolutely must not be stored comprises • the Track 1 and Track 2 data (all the cardholder and card data is stored within two tracks on the card magnetic stripe and chip embedded on chip and pin cards)• the Card Verification Value (CVV - typically the three digits printed onto the card signature strip) and of course• the PIN data (the card PIN number used to authorize a transaction on a Chip and PIN card)

All card transactions represent a risk, including ecommerce transactions. For Visa Merchants, Level 1 - Merchants processing more than 6 million transactions annually are required to have an on-site PCI Data Security Assessment and quarterly network scans. On-site assessments may be completed internally or by an outside Qualified Security Assessor or QSA.Level 2 - Merchants processing 1 million to 5,999,999 transactions annually are required to complete a Self-Assessment and perform quarterly network scans.Level 3 - Merchants processing 20,000 to 1,000,000 e-commerce transactions annually are required to complete a Self-Assessment and perform quarterly network scans.Level 4 Merchants process less than 20,000 e-commerce transactions annually and all merchants across channel up to 1,000,000 VISA transactions annually and are required to complete an annual self assessment and annual security scans.

Saturday, 13 November 2010

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 -

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"

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.

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

Monday, 1 November 2010

This article has been produced to assist anyone concerned with ensuring their organization can meet PCI DSS obligations for event log management - "PCI DSS Section 10.2 Implement automated audit trails for all system components..."

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. 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.

File-Integrity Monitoring and Vulnerability Scanning
While we are on the subject of deployment of agents to platforms for event log monitoring, it is worth considering the other dimensions of the PCI DSS, namely file-integrity monitoring and vulnerability scanning/assessment.

Both of these functions can be addressed using an agent on board your servers and workstations. File-Integrity monitoring (see section 11.5 of the PCI DSS) is necessary to ensure key program and operating system files are not infiltrated by Trojans or other malware, and that 'backdoor' code is not inserted within applications. File-Integrity Monitoring should be deployed to all PCs and Epos systems, Windows Servers, Unix and Linux hosts.

Vulnerability Scanning is a further element of the PCI DSS and requires all devices to be scanned regularly for the presence of security vulnerabilities. The key benefit of an agent based approach is that vulnerability scans can be performed continuously and any configuration changes rendering your PCs/Epos/Servers less secure or less 'hardened' will be identified and alerted to you. The agent will need valid PCI Security Settings/Vulnerability Assessment/PCI Hardening Checklists to be applied.

Event Log Backup to a Centralized Server
Once assembled, the Audit trail history must be backed up in a way that is "difficult to alter". Traditionally, write-once media has been used to ensure event histories cannot be altered but most centralized log server solutions now employ file-integrity monitoring as a means of detecting any attempt to change or edit the event log backup.

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.

Wednesday, 29 September 2010

The security standard calls for a broad range of security measures, but beyond the use of firewalling, intrusion protection systems and anti-virus software, the understanding of the requirements and responsibilities of the merchant are very often poorly understood.

This guide simplifies the scope of the balance of PCI DSS measures to just four areas.
- File Integrity monitoring
- Event Log centralization
- Security Vulnerability scanning for device hardening
- Change Management process
Understanding and implementing measures to address these four areas will make any QSA happy and get you compliant - and keep you compliant - in no time at all.

File Integrity Monitoring
As a mandated dimension of the PCI DSS, FIM verifies that program and operating system files have not been compromised.

Why is this important? The principal benefit of using FIM technology is to ensure that malicious code has not been embedded within critical application and operating system files. The insertion of a 'backdoor' or Trojan into core program files is one of the more audacious and elegant forms of hacking, and also one of the most dangerous.

The PCI DSS (Payment Card Industry Data Security Standard) specifies the following "Deploy file-integrity monitoring software 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" and also that for log files "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)".
Contemporary compliance management technology will provide pre-defined templates for all folders and files that should be tracked for File-Integrity, also allowing you to specify additional program folders and files unique to your environment, for instance, your core business applications.

File Integrity Monitoring technology conducts an initial inventory of all filesystems specified and 'fingerprints' all files using secure hashing technology, generating a unique checksum for each file. The system will then audit all files being tracked on a scheduled basis every 24 hours (even though the PCI DSS calls only for weekly checks) with any changes, additions, deletions or modifications being reported to you.
The latest generation of File Integrity Monitoring software also operate in a 'live tracking' mode for ultra-secure environments where file changes are detected and reported in real-time.

Other options to consider are to track and identify actual changes to file contents, useful when tracking configuration files to provide you with a complete audit trail of change history - this can be applied to any form of files such as text and xml.

Continuous Vulnerability Scanning
All security standards and Corporate Governance Compliance Policies such as PCI DSS, GCSx CoCo, SOX (Sarbanes Oxley), NERC CIP, HIPAA, HITECH, ISO27000 and FISMA require Windows and Unix Servers, workstations, and firewalls, routers and switches to be secure in order that they protect and secure confidential data.

'Hardening' a device requires known security 'vulnerabilities' to be eliminated or mitigated. A vulnerability is any weakness or flaw in the software design, implementation or administration of a system that provides a mechanism for a threat to exploit the weakness of a system or process. For the PCI DSS, it is a requirement that all 'within scope' sites are scanned for vulnerabilities every quarter. This gets expensive in a large scale, multi-site estates, as well as being a time-consuming management overhead.

Perhaps the biggest issue is that the results of any scan are only accurate at the time of the scan - any configuration changes made after the scan could render devices vulnerable and in a worst case scenario, devices could be left vulnerable to attack for a 3 month period. The ideal solution is to continuously track configuration changes. This is the only real way to guarantee the security of your IT estate is maintained. Using continuous configuration tracking technology allows you at any time to see the Compliance Score of any server and which settings need to be changed to re-harden the config. Any changes made should be reported, including Planned Changes which should also be reconciled with the original Request For Change or RFC record.

Secure, Centralized Event Log Management
Log analysis is a key weapon in the fight against any cyberattack. By gathering logs from all unix and windows servers, applications and databases, firewalls and routers, the method and pattern of an attack can be understood. Identifying the method and source of any attack allows preventative measures to be continually improved. This is why all security policies place log retention at their core. PCI DSS compliance requires logs to be gathered and reviewed daily, and retained for at least one year. Similarly for GCSx Code of Connection or CoCo compliance - Audit logs recording user activities, exceptions and information security events are to be retained for at least 6 months.

For any compliance initiative, it will be necessary to gather logs from all
- Network Devices
- Windows, Unix and Linux servers
- Firewall or IPS and IDS devices, Email and Web Servers
- Database and Application servers - even IBM Mainframes
- All other potentially useful sources of log information

Although the scope of most compliance standards will be largely satisfied at this stage, far greater value can be extracted from Centralizing Event Logs. Contemporary event and audit log management technology ensures all event logs are analyzed and correlated automatically, applying a comprehensive series of rules pertinent to any Security or Governance policy. Any breach of compliance will be alerted immediately allowing pre-emptive action to be taken before a problem arises. The best log management solutions provide pre-defined rules templates, allowing you to be in control of compliance straight out of the box.

The following is a checklist of features available in today's best log management software -
- All Security and Governance Policies supported via pre-packed Compliance Rule Templates
- Real Time Security Warnings i.e. violation of file integrity monitoring rules
- PCI DSS and GCSx Code of Connection supported 'out of the box'
- Web-based Dashboard and integration with Servicedesk as standard
- Powerful, keyword-based Event Log mining across any combination of devices and applications
- Complete solution for all Security Information and Event Management (SIEM) requirements
The latest generation of centralized log server software allows you to focus on true exceptions and important events by masking off the sometimes overwhelming flood of logs. Use the pre-built Compliance Templates and build your own keyword and logic-based correlation rules, allowing you to manage what really matters to your organization from a security and compliance standpoint.

Change and Configuration Management
ITIL Best Practises identify Change Management as one of the key, central processes that should be understood and assimilated into an IT Service Delivery operation. Change Management as a process is intended to ensure that when changes are made, they are first verified as being completely necessary and adding some value to the organization, and if so, that changes are then well planned, documented and clearly communicated to ensure any potential negative impact from the change is understood and eliminated or minimized. The entire experience and knowledge of the enterprise is harnessed and greater efficiencies can be gained from 'one visit' fixes - i.e. a number of required changes can all be delivered during one planned maintenance window. A well maintained Configuration Management Database (CMDB) will often be used as a means of better understanding the 'downstream' effects of changes and or their impact on a number of critical business services.

Crucially for any organization subject to Corporate Governance-driven security standards, changes to any IT system can affect its security. Installing application updates may introduce new vulnerabilities and making any configuration change may also render systems less secure and more prone to a security breach. The latest change and configuration management software tracks all changes to your infrastructure, exposing all unplanned changes and reporting clearly on the intended - and uniquely, the actual outcome - of any planned change. All network device configurations are automatically and securely backed up, with the option to remediate any unauthorized configuration change. Server configurations are tracked against either pre-defined security policies or your own personalized policy, with any deviations highlighted.
And once firewalls, servers, workstations, switches and routers are all in a compliant state, you need to ensure they remain that way. The only way to do this is to automatically verify configuration settings on a regular basis. Why? Because unplanned, undocumented changes will always be made while somebody has the admin rights to do so - legal or otherwise! The configuration change tracking solution will alert you when any unplanned changes are detected as well as keeping an audit trail of planned changes, reconciled with the request for change details.

This provides a unique 'Closed-Loop Change-Management Safety Net' - when changes need to be made to a device it is vital to ensure that changes are approved and documented - we make this easy and straightforward, reconciling all changes made with the RFC or Change Approval record. An open API allows integration with most service/help desks or other change management systems to establish a link between the change approval process and the actual changes that are made.

Sunday, 19 September 2010

This will be useful for anyone who is tasked with ensuring their organisation is compliant with the PCI DSS, or anyone just interested in learning more about this subject.

NNT Customers include retailers such as UK-wide retailer Spar, but also organisations as diverse as an on-line gaming company and a worldwide Christian ministry. The fact is that any organisation handling payment card transactions will need to put security measures and procedures in place to safeguard cardholder and card data.

This webinar will explain in plain English the measures required in order to simply and cost-effectively navigate a PCI audit and focus on some of the areas which any QSA will tell you are usually among the more challenging such as

We will show you some new concepts such as “Closed-Loop Change Management” and the “Change Management Safety net”

During the session we will share our experience of working with some of our customers and their PCI challenges, and illustrate key points using a live demo system.

Register via this link now and for more information regarding PCI DSS compliance visit http://www.nnt.co/nnt-change-tracker-enterprise-for-retailers-and-other-organizations-handling-payment-card-transactions.html