Checkpoint Secure Platform Tip on Open Servers

When installing Checkpoint SecurePlatform (SPLAT) on an open server with several interfaces, it can be hard to locate the interface number to match the network card. This can also be difficult if you have added a NIC or removed one. Many administrators run into this issue, where they think the interface names and numbers are the same as the old configuration after they do a re-install or full upgrade on the same box. However, after a lot of troubleshooting, they realize SPLAT has re-ordered the interfaces and now they do not match your old config.

To avoid this trap, there are a few ways to deal with this. One way is to watch the console of the box while you pull and plug cables in. After pulling cables from the NICs, the console will indicate that eth1 has been unplugged or eth2 has been unplugged. This is one way to track the interface numbers to NICs but isn't optimal since it requires you to cause a network outage.

Another easier way to do this is by using the handy ethtool command, native to SPLAT. In expert mode, you can run the following command:

ethtool –p nickname

For example: ethtool –p eth1

Once this command is entered, it will cause an interface to blink - this will be the correct NIC. In our example, the interface that is blinking will be eth1. This can be repeated for all the NICs starting at eth0. Most broadcom NICs will blink many times and stop automatically while Intel NICs will blink constantly until the command is stopped. This trick works well on quad cards and can also be used when your are adding or removing NICs.

Mike A.

Did you find this tip useful? Do you have a tip that you think people should know about? Please leave your thoughts in the comments section below.

A New Dad's Perplexed Ramblings on Internet Security

I recently had the pleasure of becoming a new father, complete with all the joys of sleepless nights, diaper changing, and the almost-complete loss of personal time. One thing I’ve learned since we got the good news is that you will never stop worrying about your children, no matter what age, and no matter where they are.

As a security professional, I am dreading what is going to happen when my child starts peeling back the proverbial onion that is the Internet. In the past, I always had a very strong stance on how I would monitor my children’s activity on the Internet, and it was to monitor everything. I wanted email alerts for keywords, URL filtering with daily reports, and emails of chat logs each night. That would be a good start, right? 

Since looking into the adoring eyes of my first child, however, I have had to ask myself some morality questions. How do you know when you’re going too far?  When do these protections change from monitoring into spying? Will all of these protections affect my child negatively instead of positively in the end?  Will I be using my child’s future education funds to maintain all these protections?

These questions (and many others) have caused me to look at how businesses handle the same issues and whether their solutions can translate to the home front.  No, I’m not talking about writing a security policy for usage of family computers and the Internet.  The best proactive deterrent in business is education.  Educate your staff (my children in this case) about the dangers of the Internet, appropriate surfing, what to look out for, and what to do if you think something bad has happened.  Without education, we really are just letting ourselves bang our heads against the wall of overprotection, and - let’s face it - that hurts our heads and our wallets!  All of this being said, there is still a time and a place for a little additional protection to ensure that some of our more deviant staff (or teenagers) are kept in check.  

Speaking of teenagers, does anyone have a manual?

Finding yourself in the same predicament? Check out our post on Child Safety Resources Online.

Customers May Always Be Right but Clients Are Often Wrong

That's right, you read the title correctly. This blog post is all about how many of the clients I have dealt with in the past few years have been the source of countless headaches and hours of frustration. Of course, in this case, I am referring to wireless clients such as laptops, smartphones, and handheld scanners. You didn't think I was actually referring to people did you?

Designing, implementing, and securing wireless networks can be both rewarding and frustrating at the same time. On one hand, each engagement gives me the opportunity to help an organization experience the awesomeness that is mobility. On the other hand, there is a moment in almost every deployment where I end up scratching my head and saying: "Well that doesn't make any sense". The latter of the two situations usually results in large amounts of research, troubleshooting, tweaking, and testing to determine the cause of the issue and resolve it. More often than not, the source of the issue is the wireless client's supplicant or drivers and not the configuration of the WLAN itself.

Wireless client vendors and software designers have a lot of latitude in the way they design their products to interact with a WLAN. It's because of this design latitude that we end up with some pretty interesting WLAN connectivity and performance issues. In no specific order, here a few issues for which you might want to start your investigations at the client level instead of jumping right into tweaking your WLAN configuration:

Loss of connectivity when roaming between access points

Your first impulse might be to conclude that you don't have a strong enough signal and start dropping in additional access points. While this could actually be the case, it is just as likely that the issue lies with the capabilities, or lack thereof, on your wireless client. It's up to the client to decide when it is time to roam to another access point. Some will roam more aggressively than others and some tend to 'stick' to an access point for much longer than they should. To make matters worse, there are latency issues introduced during roaming depending on if the client is using PSK or 802.1X/EAP. You should spend some time researching and testing your client capabilities to ensure that you take latency and roaming requirements into consideration when designing your WLAN. Additional research subjects: Opportunistic Key Caching (OKC), 802.11r-2008, 802.11k-2008. 

Random loss of connectivity

This is a tough one. When your clients are randomly dropping their connections, you could have any number of issues at play. Some questions you might ask are: Is it happening to just a single client or all clients? If it is happening to a few clients, are they the same hardware and software versions? I've been involved in quite a few engagements where the final solution to this particular issue was simply to upgrade the wireless drivers and/or supplicant being used on the client. For some reason, wireless drivers never seem to be included in any kind of regular update cycle. Maybe it is time to start thinking about changing that?

"I feel the need for speed"

You've got your new whiz-bang, 802.11n, faster-than-light WLAN deployed but your wireless clients just don't seem to achieve the speeds you thought they would. You've inspected the specs and your card is definitely an 802.11n-capable card. So what is the problem? First, ask yourself: Are all clients under-performing or just some of them? If all clients are under-performing then you might actually have some issues on the WLAN/LAN side to work out. However, if it is only some clients that leave you completely underwhelmed then you might need to dig a little deeper to see what your clients are actually capable of. Not all 802.11n clients are built equally. Some can only do a single spatial stream, some can do two, and newer clients can do three. Some might have issues with packet aggregation, block ACKs or channel bonding. All of these factors will have an impact on the connection rate and actual throughput you experience. Your client might actually be performing incredibly well and you are just pushing it too hard like an overbearing parent at a little league game. A good place to find out what your client is actually capable of is the Wi-Fi Alliance's Certified Product Database.

There are many more examples that could be given but I think you get the point. WLAN connectivity and performance issues are quite commonly caused at the client end of the connection and not on the infrastructure side. We spend so much time planning and configuring the WLAN infrastructure that we sometimes forget that clients are a big piece of the WLAN puzzle. It's as true for WLANs as it is in business: spending the time to fully understand your client is never a waste of time.

Dan C.

Have a question, comment, or something to add? Please feel welcome to leave a note in the comments section below.

Ruminations on the recent PCI DSS Virtualizaton Guidelines

The long awaited guidance on virtualization technologies was recently released by the PCI SCC. Having read it over I did not find any big surprises, but a few thing did stand out for me.

This is guidance only and does not supersede the PCI DSS. It doesn’t really add anything new that wasn’t included in the PCI DSS already. Basically just because you use virtualization doesn’t mean all the PCI DSS doesn’t apply. Furthermore when adding virtualization you are adding another layer of complexity; technical, administrative, and architectural. However I think it tips the Council’s hand in what we might see in an updated DSS in October 2013.

They include in virtualization, not just VMs, but virtual storage, virtual networking (think virtual switch, not vlan), virtual desktops, and or course the hypervisor. They also throw in the cloud for good measure. I wish they wouldn’t have done that, because that’s a whole other kettle of fish.

Here is my top 3 from the guidance.

1. Mixed-mode: They use the term mixed-mode when mixing VMs of different trust levels or those in-scope and out-of-scope for PCI on the same hypervisor/hardware. They strongly recommend that all VMs in such a scenario should be in-scope. The reasoning is that the lower security VMs represent a potential avenue of attack. I see their point: A guest VM could be popped and then chained with a vuln. to escape to the hypervisor (or host OS) at which point it essentially game over. I see their point, but other controls in the PCI DSS are supposed to be in place to mitigate this.

   They also point out that it may not be possible to achieve appropriate levels of isolation between in-scope and out-of-scope guests with a particular virtualization technology. True, but in that case all the guest VMs would be in-scope due to inadequate segmentation.

   All in I think this is a very strong statement. I suspect that merchants and service providers will protest strongly. As a QSA if you can demonstrate that your virtualization solution provides for adequate isolation, you’ve configured it properly, and have the processes in place to keep the isolation in place, you should be OK for now. But you might want to start planning for this to be added in PCI DSS version 2.x in October 2013.

2. VM Images: This one made me do a head slap (figuratively). VMs of course aren’t really hardware, they are just a bunch of bits in a VM image. This image contains the memory contents, disk contents, swap files, etc. So what about when a VM is dormant (off or suspended)? For PCI in-scope VMs it likely contains CHD. It may even contain it in an unencrypted state depending on when it was suspended. Worse it would contain sensitive authentication data in memory (verboten to store). What about moving images around? Some solutions do this to allow for increased availability. Maybe you are backing them up. Or moving them up to AWS to do some testing. We now have a new class of files that can contain both CHD, and verboten sensitive authentication data. Proper care and handling will have to be taken. What policies, procedures, technical controls are in place?

3. Complexity: There’s a saying in computer science that all things can be solved by adding another layer of abstraction. That in a nutshell is what virtualization essentially is. OS process isolation wasn’t sufficient so we invented the virtual machine monitor in the 60’s and this essentially gave birth to today’s virtualization hypervisors. That additional level of abstraction has many implications. First off we have just increased the attack surface. Also we now need processes to control the lifecycle of VMs so we can keep a handle on them. We have also created a new class of administrators: the virtual machine admin. They have administrator level access to the hypervisor of course. But what about the underlying VMs? What about the virtual appliances that perform traditional network or security functions, the virtual switches, virtual firewalls, virtual AV? This has implications for separation of duties.

There is nothing to get too alarmed about. Most of this is already included in the PCI DSS on careful reading. It does highlight that in an effort to cut down on costs and leverage infrastructure we’ve introduced a host of other issues that we’ll have to deal with. Perhaps the cost saving and leverage wasn’t quite as large as was originally thought, especially when you throw PCI DSS compliance into the mix.

Jason M.

If you have any questions regarding virtualization and how it will affect your PCI DSS compliance efforts, please leave a comment or feel free to contact us directly. Our team of experienced QSAs would be happy to have a discussion with you.

Aruba Networks CEO Talks Mobility with NCI

A few days ago I was given the opportunity to sit down with the CEO of Aruba Networks, Dominic Orr, and a few members of his Canadian team. While the swordfish was great, I thought the conversation was even better. Listening to and discussing thoughts on the future of mobility with a team of like-minded individuals is an amazing way to spend an evening.

Here are some quick points and discussion summaries from the evening:

1. Wireless networking and mobility is growing at an incredible rate (no surprise there). With the ever growing number of devices that are ‘wireless only’ it is more important than ever to start planning your mobility strategy. That means immediately. Not tomorrow, not next week, immediately. You don’t want to be caught in a reactive stance when your environment gets hit by the tidal wave of BYODs.
2. It’s great to see that one of the top players in the wireless/mobility space is making a conscious effort not to leave smaller clients behind during this period of enormous market growth. Solutions like Aruba Instant allow SMBs to take advantage of enterprise-level features without going over budget. Mobility is primed to be a game-changer for everyone; not just the richest companies.
3. Starting now, or in the very near future, context will be king. It is no longer good enough to only plan for coverage, capacity, or even secure access. To take full advantage of mobility, you will need to start providing coverage, capacity, and security based on the context of the individual users and devices connecting to your network. Using identity, device type, time, location, and application usage as the context in which you create your policies will allow for optimal, secure, and efficient use of wireless networks and mobility in the workplace.

Overall, I left that dinner feeling energized and excited about the future of mobility. Am I ready to cut all of my cables right now? No. However, as more and more device manufacturers take the option of a wired connection away, it is comforting to know that networks are set to adapt and offer a far more customized level of service than ever before.

Dan C.

What are your thoughts on the future of mobility? Do you need help developing your strategy? Leave a comment or contact us directly and let's start the discussion.

Full Disclosure: NCI is a partner/reseller of Aruba Networks.