Tag Archive for: PCI

Top 5 Network Security Best Practices

As I sat in one of RedSeal’s headquarters conference rooms last week discussing with two customers their approach to securing their networks, I was reminded how, even in the midst of our diversity, there are some fundamental truths about security and best practices. eWe’ve come up with five of the top network security best practices.

topfiveFirst and ultimately, it’s about people. There is only so much that automation can do, and often we put it in place to discover, determine, or deconstruct the errors people make. One of the primary options we have in this area is to continuously educate and communicate wise choices to limit the potential security incidents. The ultimate best practice is prevention. Creating a security-sensitive business culture is therefore a prime best practice.

Second, identify your critical assets and rank all of your assets based on their importance to your business. This is part of knowing what you are protecting. Once you know what assets are important, you can determine whether or not you are appropriately defending them. If you don’t have them clearly identified, critical assets may remain unprotected and open for attack.

Third, create a zoned network security architecture to delineate between ranks of assets and communication between them, providing for buffer zones that can deflect attacks. The common DMZ network was the first of the general-purpose zones to come into widespread use, and recommendations like those in the PCI DSS add additional zones like Cardholder Data and Wireless to the mix. Having your own clear definitions is critical.

Fourth, being clear about the access that is generally allowed between those zones, that is forbidden, and that is approved for certain business reasons is the next step. Know what access you want to have available and what access you want to make sure isn’t possible. For example, it’s likely you’ll want to prohibit login protocols from any outside link into your network. Some access limitations are also created for you by external standards. For example, PCI DSS makes clear that access into Cardholder from the Internet is prohibited, and access from Cardholder outbound to the Internet is also forbidden.

And fifth, once you’ve defined all of these aspects of your network security, it is criticcal to use automation to make sure that your network correctly implements this design. I have seen many instances where networks are not doing what the design intended. Almost without fail, there are errors in configurations that cause unexpected access, or at least consequences that were not intended. The massive interconnectivity of the network often allows potential paths that can circumvent controls under circumstances that are uncommon but possible. All of these possibilities require the use of automation to continuously review and check the devices and the network for any potential consequence, to provide as much protection as possible.

While this isn’t easy to do by human analysis, RedSeal can model and analyze this kind of information for you every day. You can know what you don’t know. It’s worth it!

The Reality Gap

A couple years ago in a conference room with a window looking out on the Arizona desert, two of us sat down with a customer to talk about their network. I asked to see their best network diagram, which he left to retrieve. When he returned, he rolled it out to its full length on the conference table. He began telling me of a number of inaccuracies that he knew while I looked in the lower right corner for the annotation.

reality-gapThe plot was years old. When I speak to groups of engineers, I often ask how old they think the average organization’s network diagram is. While the guesses vary from 2 to 5 years, everyone recognizes that they are woefully out of date. And that’s a huge deal for attempting to understand and protect your network.

…by the way, in my experience, the average is 5 years old! As a result, many of the technologies deployed didn’t even exist when the last map was made. Making the map current never seems to get to the top of the priority stack, either.

The truth is that if you can’t see it, you can’t secure it. If you don’t know what your network really looks like, you can’t possibly be certain your security controls are properly deployed. Even if you have designed a security architecture aligned with the best practices of network security zones such as those outlined in the PCI DSS, if your architecture isn’t reflected in the operational network, it’s effectively moot.

Similarly, the network and security design teams create a network design that they intend to align with the architecture.

However, when it gets implemented, does it align? Does it stay aligned as equipment changes, requirements evolve, and needs expand? How would you know?

That, of course, is the 100 million-customer-data-record question.

What do you think is the best answer?