Friday, February 10, 2017

CCSM, more warning signs

In my previous post I have started to write about issues around CCSM certification with Check Point. As said there, if your CCSM certificate expires soon, you will not be able to renew it, as no new exam version is available yet.

Since then I have been approached by several people with questions and stories about their own CCSM certifications.

Surprisingly, I have realized there is a mess with CCSM certification period. While majority of CCSM professionals have got certificates valid for two years only, some others got four years of certification.
Here are some stories.

CCSM certification extended for two more years.

A colleague of mine passed CCSM exam in 2015. As soon as the qualification had appeared on his profile in UserCenter, he downloaded his e-certificate PDF. Earlier this year, when the company was updating its partner status, he checked his status, and UC said, his CCSM expires early February 2017. That statement was also backed up by e-certificate he downloaded again. Now, here is the twist: although e-cert downloaded in 2017 shows two years of CCSM, the older 2015 e-cert has four years. Most interestingly, his certificates have the same name and ID number, but different expiration dates. Later on, my colleague has raised a ticket with account management, and after sending them 2015 e-cert he has received two year extension.

2017 CCSM get four years

Someone who asked me not to reveal his name said he has been granted CCSM for four years at the beginning of 2017. Same situation is mentioned in the comments to the previous post by one of my readers as well.


Trying to get to the bottom

Being surprised by the inconsistencies, I have put my investigative blogger hat, trying get to the bottom of the truth. I have reached out to Shay Solomon, Director of Education Services at Check Point, asking for a clarification. Shay has answered that CCSM is valid for two years only. My next question was, how comes some people get four year of certification.

Then something strange happen. Shay has asked me to provide the names of my sources. I have made several attempts to get more specific information and then even acknowledgement of the problem's existence and Check Point plans to fix it. Instead, all I have got was "We will look into in".

So here it is, folks. Check Point not only fails to provide means to maintain CCSM status without interruption, but also cannot decide if it is valid for two or four years. The Director of Education Services says two years, but people get certificates for four.

At this point I do not know the gravity of the situation. To assess it, please let me know if your current CCSM has two or four years. Please check both your e-cert you have downloaded and UserCenter status, as they can show different things.

As the issue might be quite delicate, please do not use your real name in the comments or, alternatively, just send the info to my private email address: "varera (at) gmail dot com".

Most importantly, if your e-cert shows four years, keep it in a safe place. You may have to appeal later, if CP takes some sort of a corrective action.

I will continue writing the story as it develops.



Saturday, February 4, 2017

CCSM lacks continuity, and it is Check Point's fault

Security Master program (CCSM) is the highest certification with Check Point available today. It was introduced at the end of 2014 to replaces failing CCMA certification.

It is clear now that CCSM is also experiencing some road bumps on its way.

During the last two weeks I have received several reports from CCSM professionals about inability to extend their CCSM status.

The issue is, CCSM certification is valid for two years only. Just to remind you, CCMA privileges had four year. Many people who jumped into CCSM at the beginning of 2015 are now facing the fact their certification is about to expire. Yet, there is no way to extend it.

Yes, that is not a mistake. You cannot extend your current CCSM certification. The usual was would be to take a new CCSM exam. But here's the caveat, it is still the same CCSM exam based on R77 version. And, not surprisingly, you cannot retake the same exam twice, if you passed it the last time.

One could extent one's CCSE for a year by taking two blade exams, but there is no such an option for CCSM. Nothing can be done. You may only wait till the next version based on R80 will be out.

I have asked Check Point Educational Services to comment on this situation. This is what they say:

"CCSM certification cannot be extended until the R80.10 software, certification training course, and certification exam is released.  This is a known issue."

I personally find the situation quite unsettling. I am privileged to know personally many of Check Point Education Services team members; and trust me, those people are dedicated, intelligent and hardworking.

Why are the processes failing then? Is it something about the system itself? I can't say. Yet I find necessary to start a dialog and to discuss openly and freely good and bad of being a Check Point certified professional.

Please do not hesitate to share your opinion too.

I will continue writing about history, issues and wins of Check Point certification system in this blog. Stay tuned.


Sunday, January 29, 2017

Using "fw monitor" command is even easier than you think

Arguably, fw monitor is one the most important troubleshooting tools with Check Point firewalls. It is flexible, extremely powerful and versatile. It is also one of the most frequently misused tools. There is a single compelling reason for both cases.

fw monitor uses INSPECT, an internal C-like language that is used by Check Point to build kernel-based security. Same language is used to define any object, action, protocol and even IPS protections. It is also a huge piece of knowledge that Check Point never shared in full.

Here is a conundrum. You can write extremely complex and very effective filter with fw monitor. The only condition is, you need to possess an intimate knowledge of INSPECT. In other words, to do so, you have to be a Check Point developer.

There are some documents and references about fw monitor usage. There is a well known long-read from 2003, for example. The doc is compelling, very details and yet mostly useless on the field. Who would use IP header offset to filter traffic, really? I have never done that in more than 17 years of working with CP FWs.

There is also a fantastically well written SK30583. It has quite nice set of examples, large list of filtering options and a very elaborate syntax explanation.

However, there is something even better. Imagine you are stuck in a datacenter dungeon, no internet access and some pressing matter to resolve. Where can you find a good reference to fw monitor syntax and options, if SecureKnowledge is not available, and your personal notes are at the office on your desk?

Well, you do not have to pull your hair out. You are working with Check Point FWs, remember? Just get on CLI and look into $FWDIR/lib/fwmonitor.def on one of the firewalls.

The file has a list of all fw monitor macroses you can use.

For example, remember my line from the previous post about kernel debug filter? Here it is:

fw ctl debug -e "accept host(8.8.8.8);" 

I use here host macros that automatically generates filter for source and destination IP addresses.

Now, this is how this macros is described in fwmonitor.def file:

#define host(_addr) (ip_src=(_addr) or ip_dst=(_addr))

Also, remember how annoying it is when your own SSH session is creeping into fw monitor output when you are trying to run a trace? Here is a no_term macros:

#define no_term ((not ssh) and (not telnet)) /* remote terminal */

And just in case you ever forget the rest of traffic filtering syntax, you can always look into $FWDIR/lib/tcpip.def file for reference.


The author thanks Sergei Shir, Check Point SecureKnowledge content developer, for his dedicated work and references provided in the comments to the previous post in this blog.


Friday, January 27, 2017

New certification manager at Check Point Education Services

Everybody, meet Jason "Tug" Tugwell, new Check Point Certification manager.

Jason is the new face in Education Services, but not at Check Point. He joined Check Point in 2007 as a tech advisor and then was leading different TAC teams at Dallas, helping out customers.

I am sure, he will make a difference in Check Point certification process.

Personally, I am looking forward to see more refined technical real world inspired question in the new certification exams.

All the best from here. Tug us well, mister Tugwell.




Wednesday, January 25, 2017

Kernel debug filter that is almost never used

Some of us are running kernel debug on Check Point FWs from time to time, especially students of my Advanced Check Point Troubleshooting Course.

There are many tricks and best practices, but one that I love the best is applying INSPECT traffic filter on the output. And guess what, this one is rarely used.

The issue is simple. When running FW kernel debug, we are trying to extract as much debug information as possible. Usually Check Point support engineers ask customers to run something like "fw ctl debug all". I assume they find filtering out gigs of text files very rewarding.

On my side, I am trying to keep things simple and controllable, hence enabling only necessary debug flag. Yet, by default you get all kernel output for all packets traversing your FW during the debug session, and that might be still too much when trying to debug a single faulty connection.

This is how "fw ctl debug" help output looks like in practice:

Usage: 
fw ctl debug [-d ] [-s ""] [-v (""|all)] [-k] [-x] [-m ] [-e expr |-i | -u] [+|-]

I have highlighted there the interesting part. If you ever used fw monitor, you know -e flag already. It stands for expression, a traffic filter based on INSPECT syntax.

Same deal here. You can actually limit quite a lot of unnecessary debug printout by filtering only the messages related to some particular traffic.

For example, adding
fw ctl debug -e "accept host(8.8.8.8);" 
to your kernel debug commands you will get output related to traffic to and from the famous Google DNS server.

This saves lots of time and effort when analysing the debug info afterwards. As all the other parameters, this filter is reset with fw ctl debug 0.

Have fun.

Wednesday, January 4, 2017

Check Point support - are you happy with it?

One of the recurring complaints around Check Point is about support. Every third post at CPUG mentions CP support being slow, ineffective, sometimes calling names.

Even in the latest Gartner Magic Quadrant for Enterprise Network Firewalls 2016 report, one of the cautions says:

 -  Gartner receives anecdotal reports from clients about support issues, mostly focused on the time it might take to get appropriate escalation. Gartner analysts recognize that this is inevitable for a vendor of this scale, but note that the frequency of issues is, of late, slightly higher than its direct competitors. Check Point has recently extended the support quality metrics it monitors to address this issue and monitor its progress.

I am personally not convinced Check Point support is the ultimately worst of all. I have seen some cases with other security and technology vendors and can say one's support experience with Check Point could sometimes be seemed as swift and easy in comparison.

I have also seen quite a few positive examples about Check Point support, mostly with more expensive Diamond plans, but also with some basic cases.

Support experience is a function of many factors: severity of an issue, an understanding of one's own security system and networks, and of course, an understanding of what to expect in the first place. I have seen many occurrences when SLAs and timing were completely misunderstood by a customer. I have even published a quick guide for support plans in 2015.

Granted, support can always be better. There are no magic bullets and "fix all" checkboxes, although sometimes Check Point seems to do miracles while fixing your things.

What is your own experience with Check Point support? Is it adequate, good, bad, mediocre, fantastic? What would you improve? What are you happy with?

Please do not hesitate to share in the comments.

Tuesday, December 6, 2016

CP vs PAN - time for big words

I have mentioned in the past Check Point starting a new game against competitors, much more aggressive and less hesitant when it comes to calling names.

It has just got even more interesting. There is a jpeg chart circulating on LinkedIn where PAN is attacked as never before.

 See full size


I could not trace this pic to its source, actually. Check Point people are distributing it as is, without any link to an origin. The URL below its title leads to the old "facts vs hype" page on the Check Point web site. Google search also does not recognise the image yet.

What is interesting here is that several PAN marketing statements are called lies.

In my 20 years in this business I have never seen this word used in a marketing campaign or in a competitive analysis materials. Does it mean someone at Check Point snapped? I am also curious if this is something official, or yet another vague attempt to stay civil while being outraged, like in case of anti-PAN videos in the middle of 2016.

I wonder if this is even something Check Point would be able to acknowledge as its own graphics...

UPDATE: the author of the picture is Nick McKerrall, according to his own words.