While the PCI DSS was a good idea, in theory, it has never lived up to the potential in practice. Basically, it imposes another layer of regulation (not required by government or industry, but by arbitrary third party) that must be added on. The regulation does have its good points, but in practice and implementation it becomes another checklist that must be run. Also, expensive audits and tests are required to prove compliance.
Still, breaches happen and they happen to organizations who are "PCI DSS Compliant" and maintained their expensive status through audits and tests.
Depending on your organization's home country, PCI DSS is just one of many regulatory requirements. None of them work as intended and none of them guarantee you won't experience a breach. They do guarantee that if a breach occurs, you will be held up to international ridicule, will suffer immense financial penalties and lose business as partnerships dissolve and participants distance themselves from your organization.
The only thing you can be assured of is that you have already been breached, the bad guys have been in your system for a long time, and when you discover the breach you just see the tip of the iceberg.
Your best defense and solution is well-trained and loyal information technology and information security staff who take an active role in the organization's efforts to maintain security throughout. They also lead the charge in developing and implementing sound, workable internal information security policy and practices. This includes:
- Maintaining the skills and abilities of the IT/IS staff
Security practices and awareness must be universal--including the C-suite (this means no special users)
Equipment and systems must be patched, maintained and monitored
Questionable practices and behaviors must be fairly called out and no retribution allowed
Development best practices must be strictly adhered to (such as no testing on production data and no developer access to production data or environments)
Test and development systems must be maintained in the same way as production
Test and development systems must be separate and firewalled from production with no convenience ports
Secure coding must be taught, practiced and adhered to throughout the development and test process
If a language or coding package cannot meet secure coding practice, get rid of it and move to one that can
You must have an active, practiced and well-thought-out incident response plan
This isn't a list of things I think are important. They are things that would have prevented large, public, expensive and embarassing breaches in the recent past.
The Adobe breach just underscores the fact that most companies give IS lip service, put your individual financial and personal data at risk and just really don't give a crap.
OK, I'm done.