NNT Security and Compliance Blog

The Ever-changing DLL Hunt – Why Do 'lsprst7.dll' And 'sysprs7.dll' Continually Change?

2011-10-02T06:45:00.000-07:00

File Integrity Monitoring - What really happens on your server when you're not looking?

Once our customers start using file integrity monitoring technology as part of a PCI Compliance or other security governance initiative there is often a realization of ‘What the eye doesn't see, the heart doesn't grieve over’

For instance, who knew there were that many file changes associated with a windows update?

We have recently dealt with an interesting project for a Passenger Ferry Operator. After we had been running Change Tracker file integrity monitoring for a few days they noticed repeated, frequent but irregular changes being reported to a couple of DLL files - 'lsprst7.dll' and 'sysprs7.dll', with two associated files 'lsprst7.tgz' and 'sysprs7.tgz'. These reside within the Windows\System32 and/or the SysWOW64 folders

Our customer contact did some research via Google but, despite finding other records of searches for the identity of these files and the reason for the frequent changes (with the trail leading to an Adobe forum thread), no explanation could be found.

A process of elimination exercise to identify the role of the files was suggested – delete the files and see which application breaks, or progressively remove programs from the server and see which one removes the DLLs in question?

It is counterintuitive for DLL files to change and you would be rightly suspicious if you saw this happening on a server. Concerns over mutating malware and polymorphic viruses began to circle.

What's the Solution?

In this instance, thankfully there is a perfectly logical explanation. The files are License Server components for SafeNet ‘Solve’ software (Solve is supplied by The Logic Group, and it provides card holder data encryption for the EPoS software used by this customer) The DLLs are persistence files, used to help detect "Time Tempering" and they change every time the software is accessed and a license check is run.

There are other examples of license key files which regularly change that we are familiar with and although it is initially surprising and of concern to see system files changing, it is ultimately a positive thing.

How can you detect genuinely exceptional file changes if you don’t fully understand how your applications and servers behave under regular operating conditions? Only by employing forensic-level file integrity monitoring and analyzing the results can you begin to get intimate with what ‘good’ looks like, and in turn, what irregular – and potentially damaging - behavior looks like.

Want to analyze your server system file behaviors or implement PCI file integrity monitoring technology? Request a free trial or demonstration here

PCI Compliance Server Hardening doesn’t have to be Hard

2011-09-07T06:21:00.000-07:00

Harden Server Configuration to remove Vulnerabilities

“PCI DSS Version 2.0 Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters”

From the moment a server is powered up it becomes vulnerable to attack. Assuming that leaving your key application servers turned off is not an option it will be necessary to implement security measures advocated by the PCI DSS.

PCI Requirement 2 calls for configuration hardening of servers, EPoS PC’s and network devices. The headlines of the requirement call for removal of default usernames and passwords, and a need to stop any unnecessary services. However, beyond these initial measures there are a vast number of additional configuration setting changes recommended by ‘best practice’ authorities (such as SANS Institute, CIS and NIST) all of which help to mitigate security threats. If you haven’t already adopted a hardened configuration standard then any of these organizations can assist, although a good configuration auditing and config change tracking system will typically be pre-packed with a hardening checklist you can adopt. This type of system will automate not just the initial hardening assessment but will also do so on a continuous automatic basis so you can be alerted when any configuration drift occurs.

As with most elements of the PCI DSS Requirements, there are a number of checks and balances to provide evidence that adequate hardening measures have been applied. In common with the overall ethos of the PCI DSS, there is always a high degree of overlap to guarantee comprehensive coverage.

Similarly, event log management and file integrity monitoring measures will serve to provide additional checks to verify security measures have not been changed or compromised at all times.

Active Testing of PCI DSS Security Measures – Pen Testing and Vulnerability Scanning

PCI Requirement 11 covers Penetration Testing and Vulnerability Scanning – we’ll discuss these in turn.

Pen Testing / Penetration Testing

Any internet facing devices are exposed to somewhere in excess of 2 billion potential hackers (source: ITU website – ‘Key Facts’) and while firewalls and intrusion detection technologies help to allow good users in and keep bad traffic out, the fact remains that an ‘open’ website is always going to be vulnerable to attack. Penetration testing takes the form of an active assessment of whether the internet facing devices and servers can be compromised. Typically a ‘blended’ approach is used combining automated, scripted scans and tests for common hacking vectors with manually orchestrated hacking techniques.

Vulnerability Scanning / ASV Scans

Whereas a Pen Test is for externally accessible devices, internal network connected devices are tested using an ASV scan (ASV is a PCI Security Council term for any organization or individual who has been validated as an Approved Scanning Vendor). This kind of internal vulnerability assessment is known as a Vulnerability Scan.

This is typically a more intensive active assessment for devices than a Pen Test, assessing operating system and application patching levels. Again the ASV vulnerability scan can be either fully automated using an on-site appliance or take a blended approach, part-automatic-part-manually orchestrated.

PCI DSS Hardening Methodologies – How do I harden my Server?

For Windows servers, numerous security features and best practice measures are implemented via the server’s Local Security Policy. Group Policy can be used as a convenient way to update the Security Policy of multiple devices in bulk, but of course one common way to enhance security is to isolate servers from a domain to allow precise ‘hand-picked’ access permissions, in which case the Local Security Policy will need to be configured directly.

In addition, unnecessary services should be disabled, built-in accounts should be renamed and passwords changed from defaults, drive and folder permissions should be restricted – the list of actual and potential vulnerabilities is extensive and always growing.

It should be mentioned that there is a whole other area of vulnerability management relating to patches and application updates. Whilst these all carry the potential to be just as harmful as configuration-based vulnerabilities, patch or application-based vulnerabilities are inherently easier to manage, given that Windows Updates and major applications all have automated, self-updating capabilities. Furthermore, operating system and application-based vulnerabilities can be remediated – that is to say, eliminated permanently – as opposed to configuration-based vulnerabilities which can only ever be mitigated. In other words, configuration-based vulnerabilities can be just as easily re-introduced at any time as they are to remove in the first place.

Summary

In conclusion, this is yet another area of the PCI DSS that is ideally handled using intelligent, automated technology. The best products available combine comprehensive ‘best practice’ security policy and hardening checklists with continuous vulnerability assessments. Any configuration drift is identified immediately and alerted, while summary reports can be produced to give an ‘at a glance’ reassurance that nothing has changed.

The active role of a continuous configuration change tracking technology can also be used as a vantage point to implement file integrity monitoring too, guaranteeing system and application files do not change and that malware cannot be introduced onto the server without detection. Likewise, SIM, SIEM (Security Information and Event Management) or plain old Event Log Management technology also provides a full audit trail of security events for in scope devices.

The good news is you don’t need to turn off your servers just to keep them secure.

Documentation Of PCI Compliance Processes? No Thanks! How Logging And FIM technologies Can Augment (Or Replace) Process And Procedure

2011-08-07T05:48:00.000-07:00

Small Company PCI Compliance

For many Merchants subject to the PCI DSS, September is always a significant deadline for proving that compliance with the security measures of the PCI DSS has been met.

Unless you are a Tier 1 merchant (transacting in excess of 6 million card sales each year) and being audited by a PCI Security Standards Council QSA (Qualified Security Assessor) then you will be using the Self-Assessment route. SAQ D is the most commonly used Self Assessment Questionnaire for medium to large scale merchants.

Regardless of which type of Merchant your organization is classified as, the issues are firstly to put measures in place to meet compliance with the requirements, (so either install some security technology, e.g. a file integrity monitor, or define and document security procedures), and secondly, to prove that the measures are effective.

For smaller merchants, processes are typically not documented because there has previously been no need to do so. It stands to reason that for a small-scale IT Department, processes are commensurately simple to explain and operate, and as such, wont have needed to be documented. This being the case, however, it could also be argued that the documentation of processes, and proving that they work, is also very simple.

For instance, the change management process may be as simple as ‘if any of us need to make a change, we discuss it or just send an email to the others for their information, then enter details onto a shared spreadsheet document’.

Clearly there is ample potential for human error in a process like this and for an ‘inside man’ hack to be perpetrated, even if the risk is low and the subsequent identification of the perpetrator straightforward.

So in this case, documenting the process is easy, but proving that it is infallible is another matter. There are too many scenarios where the process can fail, principally due to human error, but this also makes it inadequate as a means of ensuring changes cannot be made without detection. This is why many small companies lose sleep over PCI Compliance, worrying how far measures need to be taken and just how much security is enough?

Process Checks and Balances – Automated

PCI DSS Requirement 10 mandates the logging of all significant security events from the PCI estate, while PCI DSS Requirement 11.5 mandates the use of File-Integrity Monitoring technology. For many organizations taking a ‘checkbox’ approach to PCI Compliance, the implementation of both technologies is seen as just another hassle to get through for the sake of the PCI DSS.

However, take a step back and look at the PCI DSS as a whole. The emphasis is on good security measures with sound best practices. In other words, for each dimension of security advocated by the PCI DSS there is a need to document and test related processes.

It therefore becomes clear that logging and FIM are not just overlay technologies to plug gaps left by the firewalling, hardening and antivirus measures, but integral means of verifying that your net security stance is effective.

Any file change or configuration change reported should be investigated and verified then acknowledged as an approved change. The process is automated, but simple and robust.

Similarly, a new account or privilege being assigned will be reported via your log management system, prompting an investigation and ultimately a record of the acknowledgment.

As such, implementation of event log management and file integrity checker technologies can actually provide the processes needed for PCI DSS compliance. You could have a whole shelf full of change management processes and procedures, or alternatively, simply refer to your log management and FIM reporting system.

If you want to short-cut boring documentation of processes for PCI compliance then talk to us about how we can help - support@nntws.com

The PCI DSS is well thought out, utterly comprehensive but man - it’s big!

2011-07-06T00:55:00.000-07:00

Where do you start with PCI Compliance?

It is a vast expanse of best practice security measures, not at all easy to understand, and even less easy to apply to your personal situation. The headlines are as follows

12 Requirements
but 230 sub-requirements
and some estimates of 650 detail points

The PCI DSS in 2011 still remains an ongoing challenge for the overwhelming majority of PCI Merchants. Feedback we have had from working with a number of casino resorts, theme parks, ferry services and call centers over the past few months makes interesting reading for any other PCI Merchant wanting advice about PCI compliance.

Typically, one in every two Tier 2 and Tier 3 Merchants admit they do not understand the requirements of the PCI DSS. If you are either still working on implementing compliance measures identified in pre-audit surveys, or are not compliant and doing nothing about it, or are leaving everything to the last minute, don’t be too hard on yourself - nine out of ten Merchants are at the same stage.

In fact, it is fine to have a phased, prioritized approach and the PCI DSS Council fully recommend this strategy, mindful that Rome wasn’t built in a day.

Prioritizing PCI Compliance Measures

With so much ground to cover, prioritizing measures is a must, and indeed the recently released ‘Prioritized Approach for PCI DSS Version 2.0’ from the PCI Security Standards council website is an essential document for anyone working out where to start with assessing

Although the PCI DSS is sectioned loosely around twelve headline Requirements in terms of technologies (Firewalling, Anti-Virus, Logging and Audit Trails, File Integrity Monitoring, Device Hardening and Card Data Encryption) - and procedures and processes (physical security, education of staff, development and testing procedures, change management), you soon realize that there are threads that run horizontally through all requirements.

If you consider Requirement 1 of the PCI DSS, this is oriented around the need for a firewall and a fundamentally secure network design. However, you quickly end up with a secondary list of questions and queries. Do we need a diagramming tool? Do we need to automate the monitoring of firewall rule changes? (Incidentally, this is a task easily done using a good file integrity monitoring product) What is our Change Management Process? Is it documented

In this respect there is potentially a good argument for the creation of other versions of the PCI DSS oriented around procedural dimensions, such as password policies for all disciplines and devices, or change management for all disciplines and devices, and so on. Whilst the Prioritized Approach gives a good framework for planning and measuring progress, it is strongly advised that you also look up at every step and see which other requirements can be taken care of by the same measure being implemented. For example, file integrity monitoring is only specifically mentioned in Requirement 11.5, however, good FIM software solutions will underpin Requirement 1, requirement 2, and requirements 3, 4,5,6,7,8,10, and 12.

The general advice is that, even though it is very daunting, if you can get ‘intimate’ with the PCI DSS, both in spirit and in detail, then as with everything else in life, the better informed you are, the more in control you will be, and the less money and sweat will be wasted.

Summary

The PCI DSS may well challenge your pre-conceptions about what an Information Security Policy comprises - but there is plenty of help to draw upon.

In summary

Use vendor offers - a free trial of event log server software will allow you to see first-hand how much notice you are likely to be dealing with in your estate and how straightforward or otherwise an implementation might be before you spend any money
Use the PCI Security Standards Council website - tools like the Prioritized Approach spreadsheet will help breakdown the full PCI DSS into a more manageable series of steps and priorities
Look for quick wins and the best ‘bang for buck’ measures - implementing File Integrity Monitoring software for PCI compliance can take a big bite of the overall requirements and may be one of the simpler and affordable steps you take

What do you think? If you could give one piece of advice based on your own experience of PCI Compliance what would that be?

Retail Systems Forum Approaches - 'Complicated, Expensive and Time-Consuming – but the PCI DSS isn’t going away'

2011-05-06T03:31:00.000-07:00

Just 2 weeks now until this year's Retail Systems Forum being held at Microsoft's UK HQ in Reading - see http://www.retailsystemsforum.co.uk/

NNT are presenting one of the sessions -'Complicated, Expensive and Time-Consuming – but the PCI DSS isn’t going away'

The PCI DSS in 2011 – Attitudes and Opinions from Multi Channel retailers in the UK
Strategies available – what is working and what are others getting away with?
Common Sense or Technology?
Are the goalposts moving (or going to move)?

I have only just finished the presentation for the deadline so at least it is topical and up to date!

I am talking about some of the feedback we have had from PCI DSS customers over the past few months, such as

- Duck it! “The future is too unclear to make any investment...”

- Paralysis! “We don’t want to make mistakes like xyz...”

- Ignore it! “We don’t need to bother – we’ve been OK so far and we view the risks as low...”

- Go Slow! “We have kept some updated procedural stuff back and if we drip-feed this to the Bank over the next two quarters then we are covered for the next few months...”

How much does it cost to procrastinate, delay and ignore the requirements of the PCI DSS? Wouldn't it be a better use of resources to embrace the PCI DSS, understand its intentions and methods, then apply these to your organization? You need a security policy, so why not take the 'off the shelf' option on offer in the knowledge that this is a well-thought out, widely implemented and tested standard that works?

In all the instances referenced above, we ended up delivering solutions to the various PCI DSS requirements

- File Integrity Monitoring (PCI Requirement 11.5) essentially, this requires the PCI Merchant to keep tabs on any changes made to the configuration of firewalls, switches and routers in the network, ensure that windows operating system files and program files on EPoS devices and servers don't change, and to track any access to Card Data files

- Device Hardening (PCI Requirements 2,6,8,10 and 11) a configuration and set-up process for all servers, EPoS devices, PCs and network devices, whereby the 'built-in' weaknesses and vulnerabilities present are removed or minimized.

- Centralized Event Log Management (PCI Requirement 10) gives both a pro-active security monitoring capability and a full, 'forensic' audit trail to use in the event of a breach

- Change Management (PCI Requirements 1,2,6,8,10 and 11) underpins all PCI DSS requirements, in as much as once your PCI Estate is secure, you need to ensure you keep it that way, so reducing changes and for those that are made, make sure they are planned, documented and approved. Change Tracker reconciles changes that are made with details of the intended change

The RSF format is to not get too technical nor be product-oriented, so the presentation will shy away from even this level of detail.

I hope the event can be recorded and published on www.nntws.com for anyone who can't make the event in person.

Implement Logging for PCI DSS – A How to Guide

2011-03-29T04:43:00.000-07:00

Introduction

The PCI DSS Requirement 10 calls for a full audit trail of all activity for all devices and users, specifically requiring all event and audit logs to be gathered centrally and securely backed up.

The thinking here is twofold. Firstly, as a pro-active security measure, the PCI requirement that all logs are reviewed on a daily basis (yes – you did read that correctly – ALL logs DAILY - we shall return to this potentially overwhelming burden later...) requires the Security Team to become more intimate with the daily ‘business as usual’ workings of the network. This way, when a genuine security threat arises, it will be more easily detected through unusual events and activity patterns.

The second driver for logging all activity is to give a ‘black box’ recorded audit trail so that if a cybercrime is committed, a forensic analysis of the activity surrounding the security incident can be conducted. At best, the perpetrator and the extent of their wrongdoing can be identified and remediated. At worst – lessons can be learned from the attack so that procedures and/or technological security defenses can be improved.

Of course, if you are a PCI Merchant reading this, then your main driver is that this is a mandatory PCI DSS requirement – so we should get moving!

Which Devices are within scope of PCI Requirement 10?

Same answer as to which devices are within scope of the PCI DSS as a whole – anything involved with handling or with access to card data is within scope and we therefore need to capture an audit trail from each of them.

The most critical devices are the firewall, servers with settlement or transaction files and any Domain Controller for the PCI Estate, although all ‘in scope’ devices must be covered without exception.

How do we get Event Logs from ‘in scope’ PCI devices?

We’ll take them in turn –

Firewalls – the exact command set varies between manufacturers and firewall versions but you will need to enable ‘logging’ via either the Firewall Web interface or the Command Line.

Taking a typical example – a Cisco ASA – the CLI command sequence is as follows

logging on

no logging console

no logging monitor

logging a.b.c.d (where a.b.c.d is the address of your syslog server)

logging trap informational

This will ensure all ‘Informational’ level and above messages are forwarded to the syslog server and guarantee all logons/logoffs are captured.

Windows Servers – There are a few more steps required for Windows Servers and PCs/EPoS devices. First of all it is necessary to ensure that logons, logoffs, privilege use, policy change and depending on your application and how card data is handled, object access. You may also wish to enable System Event logging if you want to use your SIEM system to help troubleshoot and pre-empt system problems e.g. a failing disk can be pre-empted before complete failure by spotting disk errors.

Typically we will need Success and Failure to be logged for each Event –

Account Logon Events – Success and Failure

Account Management Events – Success and Failure

Directory Service Access Events – Failure *

Logon Events – Success and Failure

Object Access Events – Success and Failure **

Policy Change Events – Success and Failure

Privilege Use Events - Failure

Process Tracking – No Auditing ***

System Events – Success and Failure ****

* Directory Service Access Events available on a Domain Controller only

** Object Access – Used in conjunction with Folder and File Auditing. Auditing Failures reveals attempted access to forbidden secure objects which may be an attempted security breach. Auditing Success is used to provide an Audit Trail of all access to secured date, for example, card data in a settlement/transaction file/folder.

*** Process Tracking – not recommended as this will generate a large number of events. Better to use a specialized whitelisting/blacklisting technology such as NNT Remote Angel

**** System Events – Not required for PCI DSS compliance but often used to provided additional ‘added value’ from a PCI DSS initiative, providing early warning signs of problems with hardware and so pre-empt system failures.

Once events are being audited, they then need to be relayed back to your central syslog server. An agent program like the NNT Log Tracker Agent will automatically bind into the Windows Event logs and forward all events via syslog. The additional benefit of an agent like this is that events can be formatted into standard syslog severity and facility codes and also pre-filtered.

It is vital that events are forwarded to the secure syslog server in real-time to ensure they are backed up before there is any opportunity to clear the local server event log.

Unix/Linux Servers – Enable logging using the syslogd daemon which is a standard component of all UNIX and Linux Operating Systems such as Red Hat Enterprise Linux, CentOS and Ubuntu.

Edit the /etc/syslog.conf file and enter details of the syslog server.

For example, append the following line to the /etc/syslog.conf file

*.* @(a.b.c.d)

Or if using Solaris or other System 5-type UNIX

*.debug @a.b.c.d

*.info @ a.b.c.d

*.notice @ a.b.c.d

*.warning @ a.b.c.d

*.err @ a.b.c.d

*.crit @ a.b.c.d

*.alert @ a.b.c.d

*.emerg @ a.b.c.d

Where a.b.c.d is the IP address of the targeted syslog server.

If you need to collect logs from a third party application eg Oracle, then you may need to use specialized Unix Syslog agent which allows third party log files to be relayed via syslog.

Other Network Devices

Routers and Switches within the scope of PCI DSS will also need to be configured to forward events via syslog. As was detailed for firewalls earlier, syslog is an almost universally supported function for all network devices and appliances. However, in the rare case that syslog is not supported, SNMP traps can be used provided the syslog server being used can receive and interpret SNMP traps.

PCI DSS Requirement 10.6 “Review logs for all system components at least daily”

We have now covered how to get the right logs from all devices within scope of the PCI DSS but this is often the simpler part of handling Requirement 10.

The aspect of Requirement 10 which often concerns PCI Merchants the most is the additional workload they anticipate by now being responsible for analyzing and understanding a potentially huge volume of logs. There is often an ‘out of sight, out of mind’ philosophy, an ‘if we can’t see the logs, then we can’t be responsible for reviewing them’ mindset, whereas if logs are made visible and placed on the screen in front of the Merchant, there is no longer any excuse for ignoring them.

Tellingly, although the PCI DSS avoids being prescriptive about how to deliver against the 12 requirements, Requirement 10 specifically details “Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6”.

In practice it would be an extremely manpower-intensive task to review all event logs in even a small scale environment and an automated means of analyzing logs is essential. However, implemented correctly, rather than being simply a tool to help you cope with the inconvenient burden of the PCI DSS, an intelligent Security Information and Event Management system will be hugely beneficial. Such a system will allow potential problems to be identified and fixed before they affect business operations. From a security standpoint, by enabling you to become ‘intimate’ with the normal workings of your systems, you are then well-placed to spot truly unusual and potentially significant security incidents.

For an overview of NNT Log Tracker in action there is a 6 minute video here or get in touch with us via info@nntws.com

File Integrity Monitoring - PCI DSS Requirements 10, 10.5.5 and 11.5

2011-02-01T07:48:00.000-08:00

Although FIM or File-Integrity Monitoring is only mentioned specifically in two sub-requirements of the PCI DSS (10.5.5 and 11.5), it is actually one of the more important measures in securing business systems from card data theft.

What is it, and why is it important?

File Integrity monitoring systems are designed to protect card data from theft. The primary purpose of FIM is to detect changes to files and their associated attributes. However, this article provides the background to three different dimensions to file integrity monitoring, namely

secure hash-based FIM, used predominantly for system file integrity monitoring
file contents integrity monitoring, useful for configuration files from firewalls, routers and web servers
file and/or folder access monitoring, vital for protecting sensitive data

Secure Hash Based FIM

Within a PCI DSS context, the main files of concern include

System files e.g. anything that resides in the Windows/System32 or SysWOW64 folder, program files, or for Linux/Unix key kernel files

The objective for any hash-based file integrity monitoring system as a security measure is to ensure that only expected, desirable and planned changes are made to in scope devices. The reason for doing this is to prevent card data theft via malware or program modifications.

Imagine that a Trojan is installed onto a Card Transaction server – the Trojan could be used to transfer card details off the server. Similarly, a packet sniffer program could be located onto an EPoS device to capture card data – if it was disguised as a common Windows or Unix process with the same program and process names then it would be hard to detect. For a more sophisticated hack, what about implanting a ‘backdoor’ into a key program file to allow access to card data??

These are all examples of security incidents where File-Integrity monitoring is essential in identifying the threat. Remember that anti-virus defenses are typically only aware of 70% of the world’s malware and an organization hit by a zero-day attack (zero-day marks the point in time when a new form of malware is first indentified – only then can a remediation or mitigation strategy be formulated but it can be days or weeks before all devices are updated to protect them.

How far should FIM measures be taken?

As a starting point, it is essential to monitor the Windows/System32 or SysWOW64 folders or equivalent Unix/Linux Kernel locations, plus the main Card Data Processing Application Program Folders. For these locations, running a daily inventory of all system files within these folders and identifying all additions, deletions and changes. Additions and Deletions are relatively straightforward to identify and evaluate, but how should changes be treated, and how do you assess the significance of a subtle change, such as a file attribute? The answer is that ANY file change in these critical locations must be treated with equal importance. Most high-profile PCI DSS security breaches have been instigated via an ‘inside man’ – typically a trusted employee with privileged admin rights. For today’s cybercrime there are no rules.

The industry-acknowledged approach to FIM is to track all file attributes and to record a secure hash. There is a whitepaper that explains the detail of the this technology here - 'File Integrity Monitoring - The Last Line of Defense in the PCI DSS'

Any change to the hash when the file-integrity check is re-run is a red alert situation – using SHA1 or MD5, even a microscopic change to a system file will denote a clear change to the hash value. When using FIM to govern the security of key system files there should never be any unplanned or unexpected changes – if there are, it could be a Trojan or backdoor-enabled version of a system file.

Which is why it also crucial to use FIM in conjunction with a ‘closed loop’ change management system – planned changes should be scheduled and the associated File Integrity changes logged and appended to the Planned Change record.

File Content/Config File Integrity Monitoring

Whilst a secure hash checksum is an infallible means of identifying any system file changes, this does only tell us that a change has been made to the file, not what that change is. Sure, for a binary-format executable this is the only meaningful way of conveying that a change has been made, but a more valuable means of file integrity monitoring for ‘readable’ files is to keep a record of the file contents. This way, if a change is made to the file, the exact change made to the readable content can be reported.

For instance, a web configuration file (php, aspnet, js or javascript, XML config) can be captured by the FIM system and recorded as readable text; thereafter changes will be detected and reported directly.

Similarly, if a firewall access control list was edited to allow access to key servers, or a Cisco router startup config altered, then this could allow a hacker all the time needed to break into a card data server

One final point on file contents integrity monitoring - Within the Security Policy/Compliance arena, Windows Registry keys and values are often included under the heading of FIM. These need to be monitored for changes as many hacks involve modifying registry settings. Similarly, a number of common vulnerabilities can be identified by analysis of registry settings.

File and/or Folder Access Monitoring

The final consideration for file integrity monitoring is how to handle other file types not suitable for secure hash value or contents tracking. For example, because a log file, database file etc will always be changing, both the contents and the hash will also be constantly changing. Good file integrity monitoring technology will allow these files to be excluded from any FIM template.

However, card data can still be stolen without detection unless other measures are put in place. As an example scenario, in an EPoS retail system, a card transaction or reconciliation file is created and forwarded to a central payments server on a scheduled basis throughout the trading day. The file will always be changing – maybe a new file is created every time with a time stamped name so everything about the file is always changing.

The file would be stored on an EPoS device in a secure folder to prevent user access to the contents. However, an ‘inside man’ with Admin Rights to the folder could view the transaction file and copy the data without necessarily changing the file or its attributes. Therefore the final dimension for File Integrity Monitoring is to generate an alert when any access to these files or folders is detected, and to provide a full audit trail by account name of who has had access to the data. Much of PCI DSS Requirement 10 is concerned with recording audit trails to allow a forensic analysis of any breach after the event and establish the vector and perpetrator of any attack. Much more detail on this requirement can be found here - 'Event Log Monitoring and the PCI DSS'

If you are reading this and want to learn more about the PCI DSS and just what it takes to tackle the FIM requirements, you can view a couple of video overviews here and trial compliance software can be downloaded here

For more information go to www.newnettechnologies.com

All material is copyright New Net Technologies

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

2011-01-12T00:53:00.000-08:00

Here's a new video overview explaining the background to the PCI DSS 2.0 requirements for event log centralization and secure storage. The video also shows how to implement a solution that will make it easy to gather all audit logs from Windows, Unix, Linux, firewalls, routers, switches - even mainframes.

But that's the easy part! The main problem is that the PCI DSS 2.0 (Section 10.6) mandates the requirement for YOU to "Review logs for all system components at least daily". Seriously? Review all my Event Logs - 'At least Daily'?!

This is why you need some Security Information and Event Management technology - automatic analysis of event logs and intelligence to bring your attention to the genuinely serious or unusual events. This approach has a double-impact. First of all, the obvious benefit is that you can still continue your current day-job and meet the requirements of the PCI DSS! Secondly, it means that the events that are determined as 'significant' can realistically be investigated PROPERLY.

Implemented and used correctly, SIEM technology like NNT's Log Tracker, ensures you not only meet your PCI DSS obligations to the letter, but in the spirit of the standard too. You will get intimate with how your network really behaves on a daily basis, which in turn means you will spot a real security threat if you are ever breached.

The PCI Event Log video is here (it is the second video clip on the lower half of the page, although it is worth watching our 6 Steps to PCI Compliance video too if you have time) - contact me if you want a live overview or trial and we can fix it up!

PCI DSS 101 - An introduction to the Payment Card Industry Data Security Standard

2010-12-21T04:38:00.000-08:00

PCI DSS 101 –All the background you need for understanding the PCI DSS - Part 1

This is the first of a two part article intended to provide a backgrounder in understanding the PCI DSS.

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 https://www.pcisecuritystandards.org/security_standards/documents.php but the following is a summarized ‘plain English’ version

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 firewall
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 accessibility
Use masking and encryption of cardholder data to ensure that data is unreadable if stolen, but only ever store as little data as possible
Use encryption for any cardholder data when being transferred over public networks
Use anti-virus software, regularly updated
Increase the inherent security of all systems through configuration hardening i.e. remove known vulnerabilities through patching and configuration settings
Use Identity and Access Management controls to minimize access to cardholder data system on a strict ‘need to know’ basis
Assign a unique ID to each user and enforce strong authentication
Lock your doors – utilize physical security measures to restrict access to systems such as door locks, badge readers and video cameras
Track and monitor all access to all network resources and cardholder data – centrally backup event and audit log trails, especially for logons
Get a Vulnerability Scan and Penetration Test by an Approved Scanning Vendor performed every 3 months and after any significant network change. Use file-integrity monitoring to protect critical system and configuration files
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.

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?

For more information go to www.newnettechnologies.com

All material is copyright New Net Technologies

References –

https://www.pcisecuritystandards.org

http://en.wikipedia.org/wiki/PCI_DSS

http://corporate.visa.com

http://www.linkedin.com/PCI DSS Compliance Specialist Group

Psst - Want to know how you can save $thousands on PCI DSS Vulnerability Scanning costs? Read this...

2010-12-21T04:17:00.000-08:00

AF Blakemore run over 220 Spar stores around the UK. In common with other retailers around the world, PCI DSS has been a significant headache during the last few years since its introduction in 2004.

Retail is a business sector that always works on tight margins and cost control for any IT investment is subject to close scrutiny with value for money and return on investment carefully 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 DSS mandate, 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.

“When we looked at ASV scanning cost projections for our estate the numbers were potentially huge” says Jim Curtis, PCI DSS Consultant for AFB. “The other requirements for PCI DSS such as reviewing and backing up event logs, file integrity monitoring and device hardening were already looking to be expensive too, but the NNT solution solved everything for us”

“NNT Change Tracker was recently awarded a maximum 5 out of 5 in Secure Computing’s Group Test and combined with NNT Log Tracker, provides PCI DSS Merchant’s with the most cost-effective and easy to use Compliance Management solution available” Russell Willcox Chairman NNT

Using built-in PCI DSS device hardening templates and continuous configuration state tracking 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”

"How much money could you save?" - FOR MORE INFORMATION AND TO REQUEST AN EVALUATION OF NNT PCI DSS SOFTWARE VISIT www.newnettechnologies.com

PCI DSS Section 11.5 - Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files - what the?!

2010-12-21T04:03:00.000-08:00

As a mandated dimension of the PCI DSS, FIM verifies that program and operating system files have not been compromised (see section 11.5 of the PCI DSS)

"11.5 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"

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

It's easy to set up and you can get results within minutes of downloading a trial version - here

PCI DSS Section 10 - Backup event logs centrally

2010-11-13T12:20:00.000-08:00

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

Our new high-level overview of how to get PCI DSS Compliant - The human face of Security Management Technology!

2010-09-30T12:42:00.000-07:00

You can see this at youtube as below or directly from the NNT website here

Any comments? Please contact us here

New Webinar 7 October - 6 Steps to get PCI Compliant - and stay compliant

2010-09-19T12:45:00.000-07:00

Please join us for a new webinar on 7 October at 12:30pm London Time, duration 30 minutes.

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

We look forward to helping you with your PCI DSS issues!

Another Free Download - Device Hardening Whitepaper and Self-contained Vulnerability Scan and Compliance Reporter for Servers

2010-09-06T06:56:00.000-07:00

Here's another innovation from NNT - We know that getting systems secure and compliant with the PCI DSS, GCSx Co Co, SOX, and other Security Standards can be a time-consuming and expensive process -

‘Hardening’ Server configuration settings is a key task - but how do you know where to start?
Once all key vulnerabilities have been mitigated, how do you know that any subsequent changes to configuration settings will not render servers vulnerable again?
How do you even know when settings have been changed?

To assist with understanding of this area we have commissioned a new whitepaper from Computer Weekly’s Steve Broadhead - "Device Hardening, Vulnerability Remediation and Mitigation for Security Compliance"

Download a copy here http://www.newnettechnologies.com/nntwhitepaper-devicehardening.pdf

Please browse our website for more information and software downloads including a useful (and free! :-) ) Self-contained Vulnerability Scan and Compliance Reporter -

http://www.newnettechnologies.com/change-and-configuration-management-software-downloads.html

We’re always pleased to discuss any compliance or security issues you may have so drop me a line if you have any immediate queries?

Tripwire alternative? Tripwire no longer the only solution for automated PCI compliance...

2010-07-14T08:55:00.000-07:00

Hot on the heels of Secure Computing Magazine awarding Change Tracker their 5 star product accolade, the applause just keeps rolling in! This one was for a large ecommerce retailer requiring PCI DSS Compliance:

In terms for a quote or recommendation for your website please use the following:

“Having looked for a Tripwire alternative product I stumbled across NNT via Google. I was pleasantly surprised by their quotation compared to Tripwire. NNT delivered a solution exactly the way they promised and their professional approach has made this project really easy to implement. I will recommend NNT to any company that needs a quick, reliable and professional service to go with their excellent products”

For more information regarding NNT Automated Compliance Management solutions click here for whitepapers and to request a trial or overview.

NNT Compliance Management Suite comprises:

NNT Change Tracker for Device hardening Audits for PCI DSS, file-integrity monitoring to secure all key OS and Program Files, configuration change tracking for all devices, planned change operation provides full audit trail of changes
NNT Log Tracker – centralized log server for all audit log and events from windows and unix hosts, all common and bespoke application logs, all native syslog devices such as firewalls and IPS systems

Check it out and see what all the fuss is about!

NNT Change Tracker is the best compliance and change management product - not just us saying it either!

2010-06-05T04:24:00.001-07:00

NNT Change Tracker scores a maximum '5 out of 5' in Secure Computing Magazine's latest 'Policy Management/Enforcement Group Test.

The entire review is here

What is especially interesting is their assessment places one of the 'Big Beasts' of the compliance marketplace - Tripwire Enterprise - at only four stars, rating it as only "average value for the money"and "difficult to use"

Whereas the Change Tracker experience received the following "We found all of the components to be easy to use and manage" and "great value for the money"

For more information regarding NNT Automated Compliance Management solutions click here for whitepapers and to request a trial or overview.

NNT Compliance Management Suite comprises:

NNT Change Tracker for Device hardening Audits for PCI DSS, file-integrity monitoring to secure all key OS and Program Files, configuration change tracking for all devices, planned change operation provides full audit trail of changes
NNT Log Tracker – centralized log server for all audit log and events from windows and unix hosts, all common and bespoke application logs, all native syslog devices such as firewalls and IPS systems

It's always a good feeeling when you find other people agree with your point of view!

The easy way to get windows event log messages sent to a syslog server - for free

2010-05-21T00:20:00.000-07:00

If you are trying to engineer your own solution to meet requirements of a security standard like PCI DSS or GCSx Co Co (GCSx Code of Connection - required for any organisation needing access to the UK Government Secure Extranet) - then you may be scratching your head wondering how best to get event log messages from Windows and/or Unix/Linux servers? Here's how to do it for free - read on.

Well, the Unix and Linux servers may appear relatively straightforward, since you can edit the native syslogd file and specify the address of your syslog server - job done....sort of.

For instance, for PCI DSS compliance, you will need to go further than simply gathering syslog messages and provide a means of tracking file integrity, not to mention the need for gathering custom logs from your key applications and databases - more on this subject in a future blog...

Windows servers present a different challenge, being more oriented to SNMP Traps for performance monitoring than syslog forwarding for security events. NNT have been developing solutions to make the every aspect of 'compliance' simpler and less expensive than it has been in the past. If you haven't already seen our Log Tracker solution you should! This is proving useful for both organisations new to compliance and those that have been around the block with either products that are expensive to maintain in terms of license and maintenance fees, or that are too basic and under powered to cope with their environment. Log Tracker delivers the best of both options - powerful and comprehensive enough to easily cope with large scale windows and unix estates, but priced sensibly for the budget of most organisations that need it.

How does Log Tracker handle Windows Events? Simple - we have a powerful agent that deploys directly to the Windows server. If you don't have much time, just run the installer and tell it the address of the syslog server and you're done. If you want to be more selective about which logs you monitor - including custom application logs, for instance - the there are a range of filtering options.

So how do you get it for free? Just follow this link to www.nntws.com and help yourself - let me know how you get on with it?

Simplify and Automate PCI DSS Compliance Webinar

2010-05-11T09:25:00.000-07:00

Abstract - Has there ever been a more confusion-generating initiative than the PCI DSS? Even now, a good five years on from its initial introduction, a clear and definitive understanding of what your organization needs to do may still be a challenge. The importance and understanding of why File Integrity Monitoring (FIM) is a vital component for securing payment card and card holder details has come sharply into focus following the well-publicized Heartland Payment Systems and TJX security breaches.
USA - Thursday 27 May 12.15pm EST
UK - Thursday 27 May 12.15pm BST
More details on the PCI Compliance Webinar »

The HITECH Act - The Teeth and Claws of HIPAA

2010-05-10T10:00:00.000-07:00

'The HITECH Act - The Teeth and Claws of HIPAA', a new webinar courtesy of NNT and Broadband Testing that investigates the details behind the HITECH act and the implications for anyone tasked with ensuring your organization is certified compliant .
USA - Wednesday 26 May 12:15pm EST.
More details on the HIPAA Webinar »

GCSx Code of Connection – Compliance in 2010 Made Easy

2010-05-07T11:25:00.000-07:00

Now that the deadlines (and even the extensions to the deadlines) have passed, the majority of UK councils will be operating networks that are certified ‘Co Co Compliant’. However, recent studies have shown that many council IT teams are finding that measures put in place to meet CoCo Compliance are either inadequate, under specified or not much better than a gesture towards the security standard. In other words many are just ‘making do’! If this sounds familiar – don’t worry – you are certainly not alone.
UK - Tuesday 25 May 12:15pm BST and 4:15pm BST
Read more about the GCSx Co Co Webinar »

NNT Security and Compliance Blog

The Ever-changing DLL Hunt – Why Do 'lsprst7.dll' And 'sysprs7.dll' Continually Change?

File Integrity Monitoring - What really happens on your server when you're not looking?

What's the Solution?

PCI Compliance Server Hardening doesn’t have to be Hard

Harden Server Configuration to remove Vulnerabilities

Active Testing of PCI DSS Security Measures – Pen Testing and Vulnerability Scanning

Pen Testing / Penetration Testing

Vulnerability Scanning / ASV Scans

PCI DSS Hardening Methodologies – How do I harden my Server?

Summary

Documentation Of PCI Compliance Processes? No Thanks! How Logging And FIM technologies Can Augment (Or Replace) Process And Procedure

Small Company PCI Compliance

Process Checks and Balances – Automated

The PCI DSS is well thought out, utterly comprehensive but man - it’s big!

Retail Systems Forum Approaches - 'Complicated, Expensive and Time-Consuming – but the PCI DSS isn’t going away'

Implement Logging for PCI DSS – A How to Guide

File Integrity Monitoring - PCI DSS Requirements 10, 10.5.5 and 11.5

Secure Hash Based FIM

File and/or Folder Access Monitoring

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

PCI DSS 101 - An introduction to the Payment Card Industry Data Security Standard

PCI DSS 101 –All the background you need for understanding the PCI DSS - Part 1

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?

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

Psst - Want to know how you can save $thousands on PCI DSS Vulnerability Scanning costs? Read this...

PCI DSS Section 11.5 - Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files - what the?!

PCI DSS Section 10 - Backup event logs centrally

Our new high-level overview of how to get PCI DSS Compliant - The human face of Security Management Technology!

New Webinar 7 October - 6 Steps to get PCI Compliant - and stay compliant

Another Free Download - Device Hardening Whitepaper and Self-contained Vulnerability Scan and Compliance Reporter for Servers

Tripwire alternative? Tripwire no longer the only solution for automated PCI compliance...

NNT Change Tracker is the best compliance and change management product - not just us saying it either!

The easy way to get windows event log messages sent to a syslog server - for free

Simplify and Automate PCI DSS Compliance Webinar

The HITECH Act - The Teeth and Claws of HIPAA

GCSx Code of Connection – Compliance in 2010 Made Easy