The Cyber Sentinel

I ran a couple of sessions at RSA Europe 2011 to talk about PCI DSS and Risk Based Compliance. What struck me was the make up of the audience. One or two years ago, I could have put good money on the make up of the audience being 90% merchants, but now, an equal balance […]

I’ll be talking about PCI DSS and Risk Based Approaches at RSA Europe this week, Thursday 13th October at 13:00 – 13:50. If you are planning to attend, would be great to see you. If you can’t make it, you can download my presentation here: GRC-304 – Taking a Risk Based Approach to PCI DSS

You might have noticed things have gone a little quiet round here, as my last blog post seemed to get me into a spot of trouble… Anyway. It’s certainly not my style to tread on the feet of a major UK acquirer and in the end I was asked to remove the names of the

We all know what risk is. It’s like stepping outside of the house in the morning, looking up at the sky, working out whether or not you think it’s going to rain and then working out whether or not it’s going to rain enough to warrant taking an umbrella, full waterproofs or avoiding the rain

If you’re hitting section 5.1.1 of PCI DSS and want to verify that all anti-virus programs detect, remove, and protect against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits), then what do you do? How do you test anti-virus software actually works? I’ve been using the EICAR test

What a great little tool to help verify SSL configurations. If you’re working through PCI DSS and hit section 4.1a, then www.ssllabs.com does a grand job at ensuring your SSL configuration is inline with security best practice. Still not too convinced that I need to ‘sample’ some HTTPS network traffic to make sure it’s actually

Version 2.0 of the Prioritized Approach has been released and is available for download at www.pcisecuritystandards.org. So what’s moved? A number of controls have been moved from milestones 5/6 to milestones 2/4: 9.1 – Physical Access 10.5 – Audit Trail Integrity 11.1 – Wireless Scans 12.5.3 / 12.9 – Incident Response Plan 11.3 – Penetration

Having a poke around recently, it became apparent that there was no clear definition as to what a DSE or a TPP actually ‘is’. Some QSAs have assumed that Third Party Processor (TPP) in effect means ANY payment/transaction service provider and have incorrectly classed entities that service To clarify what a TPP actually is –