Not Being Complacent with Compliancy

For those of you that know me, or have heard me speak before at an event, you know then how I like to tell stories to relay messages. One of the stories that I often tell is one about a client that I like to call my Model Client. The story dates back a good ten years now but it is still relevant on how to achieve PCI compliance and almost ensure compliance for years to come. So sit back and enjoy this story.

Both Jim and I were assigned to this client to conduct an enterprise security assessment along with a PCI-DSS audit. On our kick-off call a few things were clear; they appeared to have never done a full enterprise security assessment in the past, just some vulnerability scanning using Nessus, and this was their first go around for PCI (I honestly think they didn’t fully read the standard either before this engagement).

Spotting this, we suggested that we start with the assessment first and play the PCI audit by ear. “Why?” they asked. I explained that from the answers they had provided, that they more than likely would not pass, so instead of the actual audit, we’ll just do a gap analysis so save them some money. Like most companies, they wanted that Report on Compliance and figured that they should have no trouble passing but agreed to play it by ear and let us start first with the assessment.

As usual, Jim and I arrived Sunday night and proceeded straight to their site to make sure of where we were going the following day and also to do some reconnaissance. As always, Jim pulled out his wireless gear and was on their network within a matter of minutes. While Jim played on the wireless network, I proceeded to look at physical security. As luck would have it the cleaning crew was wrapping up for the night and let me in the main lobby – the main doors to their offices were locked.

The next day, Jim and I arrived right as everyone was showing up for work. We grabbed our bags and got in line, and walked in without question. As we roamed around we found a conference room to place our stuff and then proceeded to find our contact’s office. I can’t begin to tell you how surprised he was.

Client: “Yes, can I help you?”

Us: “Hi I’m Jim and I’m Kirk. We’re here for the assessment.”

After the introductions, I proceeded to tell the client how they already have failed the physical PCI requirements from what we’ve seen and accomplished so far. Also during this time the client leaned over and pulled out a binder with a couple of pages in it and gave it to me saying it was their security policies that I had asked for on the kick-off call. At this point I knew my assumptions that they had not read the PCI standard were correct, merely from the lack of documentation they were providing. After a little more conversation, and providing them with an example of the level of documentation we would expect them to have, we agreed that a gap analysis would be best.

During this time, Jim had been hard at work (or hardly working) on the internal portion of the assessment. When the client and I arrived back into the conference room that Jim and I had placed our stuff in, Jim had a big smile on his face and was shaking his head. “So, what would be the worst possible system for me to have access to?” he asked the client. The client’s eyes just rolled back and you would have thought he was thinking, “What have I gotten myself into.” To our surprise though he was thinking just the opposite and he invited us to his house for a BBQ with his staff.

After work, we went to the client’s house for what we thought was going to be a relaxing BBQ. To our amazement, this was a get together to re-scope the engagement. They wanted us to identify everything wrong with their environment, no matter how insignificant we may think it is. They wanted everything looked at and assessed, which we can tell you is not the norm for today’s PCI penetration tests!

At the end of the week, we delivered a large report of everything we identified wrong with their environment. We also managed to identify all the gaps within the PCI requirements that would need to be address before they should even consider going for the Report on Compliance. They absolutely loved the results and asked if we could get together for a Board meeting in a few weeks to show the Board all that was found and to also give our recommendations, or path, to a more secure environment.

A few weeks later at the Board meeting, the client had us not only give our presentation but also show, in real-time in front of all the Board members, us accessing sensitive data and gaining control of sensitive systems. The client wanted to instill the right amount of fear and show that what they do is important and needs attention and that they had a real problem and that things needed to change.

We concluded our presentation with the following basic recommendations:

  1. The blueprint for any organization’s security efforts is its Policies and while creating these policies, you need to keep any regulations or standards that you must adhere to, in mind so that you know you will be meeting them.
  2. Your policies will drive your standards and procedures, and in some cases your technology purchase decisions. The results of the assessment should be used to help build these standards and procedures. Additionally sources like the Center for Internet Security (CIS) and NIST are also good (and relatively free) reference points to use for baseline standards.
  3. After, and only after, steps 1 and 2 are complete, thenevaluate solutions that will enforce your policies.
  4. Finally, test, test, and test again. Security is a moving target and you need to be as proactive as possible to try to stay up with it.

Side note – We cannot stress #3 enough. We see it time and time again, that a PCI audit is conducted and a client runs to a security product vendor to solve all their problems before they have even established their policies. The end result is that after the policies are created, the client finds that their solutions do not fit their actual business requirements. This can result in hundreds of thousands (millions in one case we experienced) of dollars being wasted, or, even worse, changing business requirements to fit the solution. Always start with policies and procedures, and then select solutions that support those policies. AKA – looking at products should be the last thing you ever do to address a problem area.

After our Board meeting we made our normal parting comment to the client, “Just because the engagement has ended, doesn’t mean the communication has to. Contact us anytime for advice.”

After a few months, Jim and I started to receive calls from the client and they would continue on a monthly basis for the next two years. The calls were generally looking for advice on various areas of security and would typically include giving advice on what was best practice, does it meet PCI compliance, and what are we seeing in the industry. We’d always end the calls by reminding them that requirements in standards are the minimum level of security that needs to be put into place to meet compliance and that they should think beyond the requirements as much as possible.

Well, two years had passed and the client was finally ready for us to come back in. This kick-off call was quite different from the original one that we had in that it started with a challenge, “Now see what you can do to us.” They couldn’t wait for us to get back on site and let us know that everything was in play this go around like last time.

When we arrived in town and started our typical reconnaissance we knew we were in for a challenge instantly. There where cameras everywhere and Jim’s initial attempts at the wireless were failing. The next day, we tried our normal tailgating but to no success. This time, all employee traffic was filtered through the main door that was now equipped with a card reader – not to mention that employees also had spotted that we had no company badges on and immediately directed us to the receptionist.  Once checked in, the client opened the main door for us and said, “Ok boys, have at it! Let me know if you need anything.” At this point we felt like two kids in a candy store.

We first tried setting up in a conference room; ports were all shut off in every conference room we went into. Next we tied taking over an empty cube, same result. We then took a port from an active workstation to find port security was enabled. Next we used the old trick of printing off a network printer’s configuration settings, spoofing our MAC, and taking over its port. To our surprise we could only see a few printers; aside from that we couldn’t route anywhere else in the network. After trying several other attempts to gain access to the environment, and also after several escorts back to our contact (the employees were extremely aware of their surroundings, obviously a lot of security awareness training, they wouldn’t buy any line we threw at them) we decided to give in a little, “Can you activate a port in a conference room for us?” “Sure,” our contact replied, “but that’s not going to do you any good either.” Our contact was right as the conference room only allowed Internet access.

At this point we decided to have a talk with the client to see what’s been going on over the last two years as things had appeared to have changed drastically since we were last there.

They explained the following changes that they had made:

  • First, they took our initial assessment as a challenge, lesson learned, and something that they never wanted to see happen to them again.
  • Next, they had taken our advice and started first with drawing up all new policies from the ground up with heavy employee involvement. The thought was that they needed a culture change and what better way to do that than to have everyone invested, from the start.
  • Finally, they looked at standards and regulations as a starting point for their security; “Here is where we start, now how do we surpass this.” This was their mindset kept throughout the process.
    • A great example of this was in their segmentation of their environment. They didn’t just segment their PCI systems. They segmented their entire organization by functional area, department, and routed each segment through a firewall for maximum security and control. Not only that, each functional area was segmented into three segments: servers, workstations, and printers/miscellaneous devices. This explained why our MAC spoofing trick with the printer failed. This type of thought process was done throughout their entire environment.

At the end of the meeting they handed us the keys of the kingdom. They wanted everything tested; areas and devices they knew were secure along with those that they were unsure of. They were an open book and have been ever since. As soon as we find something, and yes it’s rare now, they address it immediately (security related issues are given top priority in their change control process). They still welcome blind penetration testing but are right there to tell us where everything is and the areas they are most concerned about, nothing is hidden by them to us, they want everything looked at.

I probably went more into this story than I needed to but I wanted to make one very important point, standards and regulations are the bare minimum level of security that is needed for compliance. By just doing the bare minimum does not by any stretch of the imagination mean that you now have a secure environment.  In fact, from our experience, by just doing the bare minimum to meet compliancy means that your environment is still vulnerable to attack. Yes, you have some road blocks up now, but you will still have a lot of vulnerabilities that can be exploited. There are attackers out there that specifically target certain compliancy standards because they know where the typical gaps are going to be. As Jim used to say,” ISO 9000/9001 was the greatest gift to hackers as everything was labeled and all important business solutions and functions were documented”. Meaning the business had just given their attackers a roadmap on how to harm or cripple them the most.

So remember, when approaching compliancy, be it PCI or any other standard or regulation, think like this client did, “Here is where we start, now how do we surpass this.” Remember, standards and regulations change constantly, and if you are doing just the bare minimum to be compliant, you’ll probably be out of compliancy again when they make their next change.