Locking Down Your Switch.....Cont'd

I have been talking here and here of the importance of locking down your switch (indeed your network in general) and why this is so important. It seems to me that the most basic controls are often the most overlooked. It is not surprising that most best practices call for basic network physical security and, on the same note, it is not surprising that basic security is often overlooked.

Looking through PCI DSS, for example, you will see a requirement both for WAFs (Web Application Firewalls), which operate at Layer 7, and for restricting physcial access at OSI Layer 1. Indeed, it doesn't make sense to put 3 deadbolts on the front door if the back door or a window is still open.

Shared Assessments is a member-driven industry standard used to "inject standardization, consistency, speed, efficiency and cost savings into the service provider assessment process." This standard also requires that physical ports be locked down (disabled) as referenced in:

I.3 Secure System Hardening Standards: Unnecessary physical access ports disabled or removed.

On another note (and I will discuss in another post), it is interesting to note that both PCI DSS and Shared Assessments include OWASP Top 10 as requirements.

Cybersecurity Act of 2009

The Cybersecurity Act of 2009 is something to keep your eye on.

Here's what you need to know.

MasterCard's Security Changes and its impact on PCI Compliance

Over the past few months, MasterCard has made some major security changes that, seemingly, will impact PCI compliance now and in the future for quite a number of businesses.

First, MasterCard advised all Level 2 merchants (those processing between 1 - 6 million payments cards annually) that Self-Assessment questionnaires would no longer be sufficient for compliance; thus, Level 2 merchants would now be required to have a third-party perform an on-site assessment. This new change "can cost $10,000 - $30,000 per year for a merchant already PCI-compliant and more for a retailer meeting the standard for the first time."

Not too surprisingly, merchants are looking for alternative payment methods (i.e. PayPal) in order to reduce the number of card transactions.

MasterCard, with their second big security change, has decided to disallow merchants' use of RKI (remote key injection) services to install new encryption keys on POS systems. This new rule by MasterCard jeopardizes the on-going Triple DES compliance efforts for all POS terminals: merchants have until July 2010 to upgrade their POS terminals from DES to Triple DES. If this upgrade now has to be done manually, as opposed to automatically with RKI, it could make meeting the July 2010 deadline quite difficult for businesses with a large number of POS terminals.

More on Locking Down Your Switch.....

In my last post I talked about the importance of locking down (disabling) physical access on your network switches to only those with authorized access. I discussed how, along with being a best practice, it is also a requirement of such standards as PCI DSS and ISACA.

Let's add another standard to that list today and that's NERC. Indeed, NERC CIP 007-1: R2 states that "The Responsible Entity shall establish and document a process to ensure that only those ports and services required for normal and emergency operations are enabled."

More to come.....

Lock Down Your Switch, or Else!

Locking down your switch is one of the most important steps to do (for the network engineer) or verify (for the IT auditor). Indeed, restricting physical access to your network to only those authorized is paramount. Further, it is a requirement of PCI DSS (9.1.2. Restrict physical access to publicly accessible network jacks) and ISACA (P8 Security Assessment—Penetration Testing and Vulnerability Analysis - 6.1 Rogue Access Jacks)

Looking at this from both an operational and assurance mindset, it is equally important to ensure physical access control. But, as I am sure you are aware, importance is relative. How often is PCI DSS 9.1.2 given a checkmark for compliance on either your Self-Assessment Questionnaire or on-site assessment?

From an audit, and even an engineering perspective, it is really a best practice to lock down your switches and disable any ports not in use, especially those going to areas where people may have easy, unattended access to the network.

Of course, for those in site support who may have to set up new user connections, it is quite cumbersome if the ports they need to plug their patch cables into are disabled. Indeed, instead of patching their cable and being on their merry way they now need to create that dreaded change request!

When you are on the operational side - and are feeling the pain - it is hard to see the merit of going through these processes. But, when you realize that there is a reason why the change request asks for business impact and, in many cases, will need business approval you start to see a pattern. The work we do is not in a vacuum - it supports the business. To that end, we need to be cognizant of what we are doing and what the risks are to the business.

So, the next time you need to patch in a new user and the port is disabled. Don't get mad (and, please, don't get even!) - just be glad that someone out there is doing what he/she can to keep your business secure. Now it is your turn.

SAS 70 vs. ISAE 3402

This article from PWC touches on some of the key differences. One of note is that service organization management are now required to provide a formal assertion acknowledging responsibility for their controls.

More to come.....

More thoughts on PCI DSS

Network Solutions, whose recent security breach exposed almost 600,000 cardholders, said "We store credit card data in an encrypted manner, and we are PCI (Payment Card Industry)-compliant." Here again is another example of the mindset to which I referred in my last post: PCI compliance does not equal security.

If PCI compliance doesn't equal security, does it equal culpability? Indeed, Heartland's CEO blamed the PCI QSA for the breach. Interestingly, Nevada in June passed a law that mandated PCI compliance for businesses that accept payment cards and provides that compliance will shield such businesses from liability for damages from a security breach.

As the breaches continue, let's recall Visa's statement after Heartland:

PCI DSS remains an effective security tool when implemented properly - and remains the best defense against the loss of sensitive data. No compromised entity to date has been found to be in compliance with PCI DSS at the time of the breach. [emphasis added]

Good to know.

Thoughts on PCI DSS

Of the Ten Common Myths of PCI DSS, Myth 4 is surely the one most in need of debunking. Indeed, PCI compliance in and of itself will not make you secure. If an organization is to ensure compliance AND security, there must be a "continuous process of audit and remediation."

As one who has worked in change control, I can appreciate the fact that quite a number of PCI requirements pertain to this area.

Perhaps the most important command you can use on a router is "wri mem" - to save any changes you have made. It is nice to see the importance of this concept (saving your work) memorialized in PCI DSS:

PCI DSS Requirements
1.2.2 Secure and synchronize router configuration files.

Testing Procedures
Verify that router configuration files are secure and synchronized—for example, running configuration files (used for normal running of the routers) and start-up configuration files (used when machines are re-booted), have the same, secure configurations.