In my first Network Security post, I think I will rant a bit more than anything really technical, but the technical stuff will come as I get a little more accustomed to this site.
While working at Check Point's TAC (Technical Assistance Center), I have seen all kinds of things that, quite frankly, blow me away. Of all the things that do this (trust me, there are surprisingly many), there is one that stands out above the rest: not listening to the first Engineer that was spoken to. As a higher-level engineer, I don't take those front-line calls. I get the case escalated to me if the previous engineer is unable to solve the issue. I can't count the number of times I have merely repeated what the previous engineer has said (sometime word-for-word), and that is indeed the solution to the issue at hand.
If you read this, and at some point decide to call Check POint for some kind of Technical Assitance, here are some personal suggestions to have your problem solved as quickly as possible:
1. Accept the possibility that the Check Point device is not at-fault.
I don't know how many times a case was worked by front-line, and they came to the conclusion that the issue is not with the Check Point device. At this time the customer or partner just refuses to listen to this answer. The case gets escalated to me, and by the time I can get a call and remote session going, it can sometimes be up to 1 week after that front line engineer has given his solution. Once that call is made, I typically respond with the first-line's findings as well, and sometimes have much convincing to do. Once the customer/partner finally listens to our advice, they typically find the cause of the problem, and not with Check Point. Had they listened to us a week earlier, they would have had the issue fully resolved a week earlier.
2. If you are looking for root cause, accept the possibility that it will not be found.
Again, I see SO many cases opened with something along the lines of "We had a problem, we rebooted, problem was resolved. Looking for root cause and permanent fix." To be honest, 99.9% of these cases will NOT have a root cause. Not because we can't find it or we're not looking for it, but because inadequate troubleshooting was performed,there are too few details about the exact details of the problem, and there is very debugging that is enabled and logging by default. Naturally, the front-line will tell the customer/partner that there is no root cause to be found, and again, they refuse to listen, and the case gets escalated to me. There isn't anything new that I will be able to find, I won't be able to conjure any new details to find this. And again, this can take up to a week or more, all becaause the partner/customer refuses to listen to that front-line.
3. Accept the simple troubleshooting.
While not nearly so common there now, this is another biggie. There's one case that I remember that perfectly exemplifies this point. I had a partner call in for a new case. The end-customer had been working on this issue for weeks, the paartner had additionally worked the issue for another coupole of weeks. By the time that first call was made, tthis issue had existed for over 5 weeks. By the time the case got me, over 6 weeks had gone by. In the end, the problem was caused by a very simple spelling error. The front-line engineer had suggested checking the spelling, but the partner got all huffy and insulted (or something) at this suggestion, and refused to budge on it with that engineer. I got the case, we checked ALL other possibilities, and finally I had to corner the partner and forced to check some spelling. Sure enough, there was a simple spelling error. Corrected that and problem solved! This really could have (and SHOULD have) been resolved day 1 by checking that spelling, VERY simple troubleshooting. But rather than do this, egos got in the way and the case had dragged on for way WAY longer than it should have
4. Be prepared to actually work.
While most people who call us are rather good with this, there are quite a few cases that get escalated to me where the steps have been provided to resolve the issue, but the partner/customer can't do it. Myself, I'm not so worried about the end-customers, I am usually happy to work with them, as long as they work with me. But the partners, that is the worst. In the end, the nature of the partnership is such that the partner does the actual work with the end-customer. That includes doing the work that we lay out for you. We are Technical Assistance, we are more than happy to help you out with any problems, but we cannot actually perform the work for the partner/customer; that is their responsibility.
5. Be prepared to learn on your own time. Check Point TAC cannot teach you.
SO many times I have customers complaining about how they just aren't familiar with Check Point; they're familiar with Cisco, or Windows, or X-Y-Z, "but I am unfamiliar with Check Point." I have even been asked, "How do I learn this?" Seriously? How do you learn something? How did you learn Cisco? How did you learn Windows? How did you learn X-Y-Z? We're like a car manufacturer... If there is something broken, we will fix; we cannot teach you to drive. If you do not know how to drive, you have to go elsewhere to learn. You can't call Chrysler or Kia and tell them to teach you to drive.
In short, you are calling the Technical Assistance Center for Technical Assistance; don't argue every option, and seriously consider whatever options are presented. The only excepetion to this would be if that engineer has SERIOUSLY lost your trust in their abilities, at which point you should be seriously contemplating using the "Escalation to Manager" button in the case. Otherwise, listen to what we say!
