Monday, November 6, 2017

Kernel debug Best Practices or "Why "fw ctl zdebug..." should not be used"

Over last several days I have seen rapidly growing amount of posts at CPUG and CP Community where "fw ctl zdebug..." command was mentioned, used and advised.

Although some of you already know my position for the matter, I have decided to write a post about the growing custom to use zdebug instead of employing full fw ctl debug mechanism.

Kernel debug in general

Check Point FW is essentially a Linux-based system with a kernel module inserted between drivers and OS IP stack. If you do not know what I am talking about, you may want to look into this post with an explanatory video for the matter.

Extracting information about kernel based security decisions is rather tricky, so Check Point developed an elaborate tool to read some info about various FW kernel modules actions.

In a nutshell, each kernel module has multiple debug flags that force code to start printing out some information. I have numerous posts in this blog explaining different flags, tips and tricks with kernel debug and also providing links to CP kernel debug documents.

Debug buffer

It is important to understand FW kernel is always printing out some debug messages. For most of the kernel modules, error and warning flags are active, and the output goes to /var/log/messages by default. This is not practical for debug, so before starting kernel debug, an engineer needs to set a buffer which would receive debug output instead of /var/log/messages file.

To do so, the following command is used: fw ctl debug -buf XXXXX, where XXXXX is the buffer size in KB. The maximum possible buffer today is 32 MB, but I advise my students to use 99999 to make sure they get maximum buffer possible anyway.

Kernel can be very chatty, so having a bigger buffer would ensure less kernel messages being lost.

Debug modules and flags

FW kernel is a complex structure. It is built with multiple modules. Each of the modules has its own flags. One can run a single debug session with multiple flags raised for several modules. To raise debug flags, one use one or several commands of this type:

fw ctl debug -m (module name) (+|-) (list of flags)

It is essential that + and - options allow you to raise and remove flags on the fly, even during an already running debug session. List of modules and flags can be found by the first link in this post.

Printing info out of buffer

Raising flags is not enough, as to get information, you need to start reading buffer out with this command:

fw ctl kdebug -f (with some options)

There will be A LOT of information, so never do this on the console. Use SSH session or redirect to a file.

Stopping debug

Once you collected the relevant info, you need to reset kernel debug to the default settings, otherwise you FW will continue printing out tons of unnecessary info. To do so, run

fw ctl debug 0

What is fw ctl zdebug then?

fw ctl zdebug is an internal R&D macros to cut corners when developing and testing new features in the sterile environment. It is equivalent to the following sequence of commands:

fw ctl debug -buf 1024
fw ctl debug (your options)
fw ctl kdebug -f
-------(waiting for Ctrl-C)
fw ctl debug 0

Why is this a problem?

If you are still reading this post and get to this line, you probably think zdebug is a god sent miracle. It simplifies so many things, it is the only way to run debug in production environment! Right? 

Wrong. To make it plain, here is the list of problematic point with this way of doing things:

1. The buffer is way too small. Lots and lots of messages might be just lost because buffers does not have enough room to hold them before read.
2. It is not flexible enough. Running debug in production requires lots of consideration and certain amount of caution. After all, you are asking FW kernel to do extra things, lots of them. The best practice is to start with a single flag or two and expand area of research in the fly trying to catch an issue. This is impossible to do with fw ctl zdebug macros.
3. It is too simple to use. You could say, what a funny argument. Yet, let's think about it. To master kernel debug as described above, one has to understand kernel structure, dependencies, flags and modules. You don't have to do any of that to run fw ctl zdebug drop, and many people do just that. 

My personal position on this is that kernel debug is a sensitive and risky operation. It requires understanding of the technology and the tool itself beforehand. Without such understanding one could miss messages, complicate things and in some very limited cases, crash the GW under debug. The latter I have not seen for quite some time, though.

Support CPET project and this blog with your donations to 

Monday, October 30, 2017

Check Point researches dissect IOTroops Botnet

Check Point security research team has recently posted an elaborate and impressive report about IOTroops botnet.

The details and depth are fascinating. Highly recommended to read.

Support CPET project and this blog with your donations to 

Monday, October 16, 2017

Check Point is finally fixing issue with CCSM continuity, somewhat

At the beginning of the year I was posting about CCSM continuity hiccup (1, 2, 3).

In a nutshell, there were two main issues:

1. CP did not managed to let people with expiring CCSM re-certificate in time and did not provide any graceful extension.
2. Due to a clerical error, some people were getting 4 years of CCSM certification while others were having only 2.

I have taken liberty to contact Check Point Education Services managers and to discuss the issue. There was a quite long threat with dozens of emails back and forth, and finally in February Check Point Certification manager has publicly acknowledged the mentioned issue.

However, Check Point did not provide any solution for the matter at that time. Moreover, they have rejected my private proposal to make a one time correction of CCSM validity for all certified specialists from 2 to 4 years, that would resolve both continuity and consistency problems in one shot.

This situation has undermined public trust and appeal of having the highest certification level with Check Point. Also, new partnership program does not require having any CCSMs, even for support partners. It seemed to me that the company did not have any solid strategy to develop an advanced certification at this point.

In my humble opinion, CCSM is nothing but a stripped down version of older CCSE Plus certification, and cannot be even compared with flawed but very challenging CCMA exams that Check Point eventually failed as well.

That said, there are signs the company is finally coming to its senses and trying to reverse the situation.

At the end of September all CCSMs have received an email from Check Point Certification manager Jason Tugwell granting an extension of CCSM status for all people having their certificates expired between the beginning of 2017 and up to end of March 2018.

Everyone in this group, including those whose certification has lapsed already, are granted extension of CCSM status till end of June 2018.

Although this is not making right 2 years of certification versus 4 years for some, but it is still covering the continuity lapse, under condition Check Point Education Services will be able to develop and release new CCSM course and exam till the second quarter of 2018.

Just to make it clear, the extension notice should be received by all CCSM professionals whose certification expires between January 2017 and March 2018. If you are one of them but did not receive such notice, please talk to account managment at Check Point to fix it.

Support CPET project and this blog with your donations to 

Wednesday, September 6, 2017

Your ultimate landing page for Advanced Tech Reference Guides

Check Point SecureKnowledge database is vast. It has hundreds of thousands of articles and documents. Sometimes, it takes a bit of an effort to find there what you are looking for.

Yet, it sometimes yields fantastic results. Here is something you may want to add to your bookmarks: a landing page for accessing ATRGs - Advanced Technical Reference Guides.

So far, it has links to 36 ATRGs. Whenever you want to learn a feature in depth, this is something you want to visit.

Also, it now has three new documents:

Many thanks to Sergei Shir for sharing this information.

Support CPET project and this blog with your donations to 

Monday, August 7, 2017

Capsule Docs on Mac? Forget about it...

Last year I was writing about my rather unpleasant experience around Capsule Docs on Mac. It is time to add another chapter to that story.  

I have made yet another attempt to use the tool on Mac. With my 10.12.6 Sierra machine it fails even more miserable than before. With the latest client (still Alpha, mind you!), I cannot even open a document.

Although I am logged in and even can open the same document on Windows with the same credentials, I am getting "Insufficient permissions"...

How hard can it be, really? What should happen for Check Point to start getting Mac user seriously?

In case you ask, the only reason for me to even touch Capsule Doc Viewer is that Check Point Education Services discontinued paper courseware, forcing both students and instructors to use e-kits with Capsule Docs protection. I will address this subject later on.

Support CPET project and this blog with your donations to 

Sunday, July 30, 2017

CPET session 3 - video is published

Thanks all who could join.

The session subject is Kernel Debug, best practices

CPET project relies on your support. 
Participate in the talks and help us with your donations to 
Follow us on Facebook and Twitter. 

Wednesday, July 26, 2017

Turning out of state drops on and off on your gateways without pushing policy

One of the regular issues I help my customers resolving is about out of state drops. there might be multiple causes, and those should be addressed by proper troubleshooting and network configuration changes.

However, there are cases when you just need a quick fix before addressing the root case of the problem.

The classic way to do that is to change Global Properties settings on your management and to install policy. The biggest problem with that approach is that the settings are global and will affect all FWs in the security domain after a policy push.

But no worries, there is a way around it, described in SK117374. Fw kernel has two parameter that define out of state drops for TCP and ICMP:


For example, by running fw ctl set int fw_allow_out_of_state_tcp 1  you can allow TCP traffic to pass through. Setting the same parameter to 0 will start dropping out of state TCP again.

Support CPET project and this blog with your donations to 

Tuesday, July 25, 2017

R80.10 debug documents are now public

Check Point has published a set of new documents describing kernel modules and debug flags, SecureXL and CoreXL debug details in R80.10. 

Although the documents are public, to download them you will need to log in to User Center.

Kernel Debug flags - R80.10 SecureXL Debug Flags - FWAccel (R80.10) SecureXL Debug Flags - SIM (R80.10)

Special thanks to Sergei Shir for this publication.

Support CPET project and this blog with your donations to 

Sunday, July 23, 2017

CPET session 3 - it is on!

The next Check Point Expert Talks session will take place on Sunday 30th of July at 14:00 CET. You have chosen Kernel Debug Best Practices as the topic.

The session is limited to 100 participants. If you cannot join, video recording will be available later on.

To put the session in your calendar, use invitation link.

Otherwise, use this link information to join.

CPET project relies on your support. 
Participate in the talks and help us with your donations to 
Follow us on Facebook and Twitter. 

Monday, July 10, 2017

CPET session 3 - choose the topic and time

Do not miss the opportunity to choose what and when will be discussed on the third CPET live session.

This time I am proposing three different subjects:

1. Details of Policy Installation with Check Point
2. Kernel Debugging Best Practices  - Chosen
3. Open Questions and Answers discussion

Note: if option 3 is chosen, I will ask to submit questions in advance, so I could go through them. 10 minutes will be left for further discussion anyway.

The proposed times are:

1. Saturday, 29th of July, 18:00 CET
2. Sunday, 30th of July, 14:00 CET - Chosen

The pool is now closed. Session details and invitation are here.

CPET project relies on your support. Participate in the talks and help us with your donations to 
Follow us on Facebook and Twitter. 

Friday, July 7, 2017

45 day trial for Office 365 SandBlast Cloud - do not miss

Check Point just has announced an unprecedented 45 day trial program for SandBlast Cloud designed to protect your Office 365 environment.

It includes engineering support for deployment and tuning of the solution.

The program is only available by request.

Details are listed in the CP community post by Stephen Johnson.

Support this blog with your donations to 

Friday, June 30, 2017

Sunday, June 25, 2017

CPET session 2 recording is out there

Thanks all for a great talk. We have been discussing Unified policy, rulebase search in the GUI and gateway side rulebase match process.

Special thanks to Tim and Tomer for joining.

CPET project relies on your support. Participate in the talks and help us with your donations to 
Follow us on Facebook and Twitter. 

Monday, June 19, 2017

CPET session - R80.10 rulebase enforcement - IT IS ON!

Hi all, thanks for participating in the pool concerning upcoming CPET session.

The result are:

Topic:  R80.10 rulebase enforcement
Time: Sunday 25th of June, 3 PM CET

Connectivity details:

Time: Jun 25, 2017 3:00 PM Zurich

Join from PC, Mac, Linux, iOS or Android:

Or iPhone one-tap (US Toll):  +14157629988,,753341892# or +16465687788,,753341892#

Or Telephone:
    Dial: +1 415 762 9988 (US Toll) or +1 646 568 7788 (US Toll)
    Meeting ID: 753 341 892
    International numbers available:

Calendar invitation can be downloaded here.

Talk to you all on Sunday.

CPET project relies on your support. Participate in the talks and help us with your donations to 
Follow us on Facebook and Twitter. 

Friday, June 16, 2017

Voting for the next CPET session is extended

Hello all, I have decided to extend the voting for the next CPET session.

R80.10 rulebase enforcement is a definite leader, but the timing is another matter. We are having Sunday 15:00 CET leading with just a single vote out of 27.

The pool will be closed on Sunday 19.06.2017 EOD, please use the last chance to define the time.

CPET project relies on your support. Participate in the talks and help us with your donations to 
Follow us on Facebook and Twitter. 

Thursday, June 15, 2017

RIP Barry Stiefel

Earlier this week I have learned say news about Barry Stiefel's passing.

Barry, the founder and director of CPUG over so many years, was my friend. I have met him in person in 2008 on CPUGcon in Switzerland. He brought together so many different people and cultures, and made us talk and share.

His energy and enthusiasm were fueling Check Point Users Group. With his big personality, he gave the community both glory and challenges. He was always fighting a fight, fighting for something he saw dear, and true, and fair.

Your fight is now over, pal. Rest in peace...

Tuesday, June 6, 2017

CPET session time and subject - take your pick

Not so long ago I have asked your feedback concerning my CPET idea. To improve the game, I will be suggesting two different subjects and different times for live attendees.

So for the next time I am proposing two different topics:
  • New logic of rulebase search in R80.10 gateway - Final
  • R80.10 MDSM and VSX deployment - live demo
 and two different times:
  • Saturday 24th of June, 11:00 CET  
  • Sunday 25th of June, 15:00 CET    Final 

To vote simply leave your feedback in this Google form. You have time till 16th of June. Most popular time and topic will be presented. You also can suggest another topic for the future sessions. Please choose just one subject this time.

I also have to make an important clarification about the proposed time slots.

CPET is a private and free of charge initiative. Performing any kind of activities towards it during regular office hours is impossible. I can only make preparations and run the session on my private time. Also, as my day job duties may require some customer facing overtime during the working week, for time being we are stuck with weekends only for the live session, where you can participate in an actual discussion. That should not be a problem for those who cannot attend, as long as the recordings are available. You are always welcome to leave comments in the blog or in other media.

Thanks for your interest.

CPET project relies on your support. Participate in the talks and help us with your donations to 
Follow us on Facebook and Twitter. 

Tuesday, May 16, 2017

VSX and local.arp - correction and follow up

Hi, in one of my previous posts I have mentioned that with Jumbo HFA 210 and up local.arp files are purged.

The issue was reported to me by a customer, and I was not personally involved in troubleshooting it. That was my oversight, which led to some erroneous statements in the original post.

Since several Check Point developers and RND managers reached out to me to investigate the details. After thorough analysis it has been found that the information reported is not 100% accurate.

Here are the results:

1. Check Point admits that after Jumbo installation local.arp on VS0 only will be purged. This issue will be corrected with the next HFA package.

2. Any VS other than VS0 will keep local.arp intact. That also means, the original warning about installing Jumbo package 216 was incorrect. With regular precaution, such as backups and local modifications saved aside, there is no showstopper for VSX, unless you filter your production traffic on VS0.

3. The actual customer's issue occurred on a physical FW and not on VSX. Here I have to remind all that the only supported way to configure Proxy ARP settings on physical Gaya based devices is through CLISH.

More info to follow.

I thank Gera Dorfman, Yigal Alexander and Sergei Shir for their time and efforts spent to investigate the issue.

Monday, May 15, 2017

Wcry lesson - we learn that we do not learn

Wannacry ransomware wreaked havoc around the globe, infecting and putting out of commission more than two hundred thousands computers. One could consider this as a brutal and effective crashtest for common security practices. Test that we have failed, miserably. Just look at the map of affected countries...

The situation could be completely different, if IT security adhered to a small set of very basic security practices, such as

Educate end users

One of the Wcry vectors is a phishing email. We all know that it is not wise clicking on email links, right? Wrong, apparently. People are still doing that. Teaching users simple security awareness practices is vital to avoid such incidents.

Scan incoming emails and downloads

One of the classic cases of Threat Emulation is scanning and detonating file attachments and downloads. Every decent security vendor has an appropriate offering in this field. 

Anti-phishing tools are also widely available, both onsite and cloud based.

Patch your systems timely

SMB vulnerability used by Wcry to propagate was patched by Microsoft in March 2017, two month before the event. Two month!

Use IPS for virtual patching

Okay, you say, we could patch all supported Windows machines, but how about XP, 8 and 2003? Even if there was no patched for unsupported Windows flavors, simple IPS virtual patching would do. How hard it can be, really?

Filter incoming traffic, segment your networks

To prevent the initial infection coming from Internet through SMB, one only needed to filter out incoming SMB traffic. Same to prevent lateral movement of the worm in segmented networks. Simple FW rules denying such traffic would do.

Backups, backups, backups

In case of infection, there is always a plan B - restoring systems from backups. If you have any. If you keep them safe. Safe in this context means offline. 

Simple and widely known best security practices could save the day. Yes, we have all seen recently that our networks are out there for anyone who wants to take them over. How sad is that?

To support this blog send your donations to

CPET feedback

Hi all,

Nobody showed up to the planned CPET session about pros and cons of Check Point Stateful Inspection, and I would like to understand what went wrong here.

Please kindly take your time to fill in a short questionnaire that would help me to plan better the next time.

Thanks a lot

CPET project relies on your support. Participate in the talks and help us with your donations to

Follow us on Facebook and Twitter. 

Monday, May 8, 2017

Urgent! Your VSX proxy ARP settings might be broken with latest R77.30 Jumbo HFA

In 2014 I wrote an article about setting proxy arp on VSX bond interface

IMPORTANT: The information below is not 100% accurate. Please jump to the new post for more details

The problem occurred the first time during a sophisticated VSX setup with one of my customers. Although CP official documentation insisted doing it from Gaia clish, it was failing, and manual local.arp file was required.

Since then, Check Point corrected its recommendation, and in sk30197 local.arp is mentioned as the appropriate configuration.

Guess what? With R77.30 Jumbo HFA package 210 and above this is now broken

The last week my other VSX customer reported to me that installing Jumbo 216 caused four hour outage on their business critical system, and the reason was failing proxy ARP settings. They have used local.arp files, but after installing 216 Jumbo HFA package those files were purged.  They also needed to use Gaia clish to configure it, again. 

After some research, we are now convinced that this is the result of fixing bonding issue mentioned in sk111675. The fix is included in Jumbo packages version 201 and up. 

The ugly part of the issue is that it was not expected and apparently not tested on a system with pre-existing local.arp.

If you happen to have local.arp files in place and plan to install the latest R77.30 Jumbo HFA, take hypercare.

The documentation is not fixed yet, and I did not manage to find any new SK for the matter just yet. 

Support this blogs with your donations to

Session 2 - meeting details

As previously announced, we are having the second session of CPET this weekend.

It will happen on Sunday, 14th of May, at 3PM CET.

Zoom meeting will be available via this linkCalendar invitation for it is here.

As before, only 50 participants will be able to join. Mark your calendars and be on time.

CPET project relies on your support. Participate in the talks and help us with your donations to

Follow us on Facebook and Twitter. 

Sunday, April 30, 2017

CPET session 2, Stateful Inspection: the good, the bad, the ugly, the brilliant

I am glad to announce session 2 with the title: 

Stateful Inspection: the good, the bad, the ugly, the brilliant 

We will touch the following subjects:

1. Why is Stateful Inspection (SI) still the best way of securing network traffic?
2. What are the particular details about Check Point implementation of SI?
3. Pitfalls, drawbacks, and bottlenecks with SI
4. Does SI have a future?

Stay tuned, the date and time will be announced soon

CPET project relies on your support. Participate in the talks and help us with your donations to

Follow us on Facebook and Twitter. 

Monday, April 24, 2017

CPET session 1 - video is ready

Video recording of the first session is now available

Thank you for your participation. Hope to see you soon.

CPET project relies on your support. Participate in the talks and help us with your donations to

Follow us on Facebook and Twitter. 

Thursday, April 20, 2017

Do not miss first CPET session

All, do not miss this session. Details are in one of my previous posts.

Calendar invitation is available here.

Only up to 50 participants, so be on time.

CPET project relies on your support. Participate in the talks and help us with your donations to

Follow us on Facebook and Twitter. You may also send us an email (cpvideonuggets (at)

Saturday, April 15, 2017

CPUG papers 2 - Architectural Principles of Check Point Firewals

CPUG papers project released the second paper - Architectural Principles of Check Point Firewalls

CPET project relies on your support. Participate in the talks and help us with your donations to

Follow us on Facebook and Twitter. You may also send us an email (cpvideonuggets (at)

Thursday, April 13, 2017

CPET pilot session 1 - details

Introduction to R80 - meeting details

CPET is inviting you to a scheduled Zoom meeting.

Topic: Introduction to R80 -  Zoom Meeting
Time: Apr 23, 2017 3:00 PM Zurich

Join from PC, Mac, Linux, iOS or Android:

Or iPhone one-tap (US Toll):  +16465588656,470434887# or +14086380968,470434887#

Or Telephone:
    Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
    Meeting ID: 470 434 887
    International numbers available:

Add this meeting to your calendar by this link

CPET project relies on your support. Participate in the talks and help us with your donations to

Follow us on Facebook and Twitter. You may also send us an email (cpvideonuggets (at)

Tuesday, April 11, 2017

CPET first pilot session - R80, the second biggest Check Point revolution

Mark you calendars, the very first CPET pilot session is planned to take place at 3PM CET on Sunday, 23rd of April.

The topic will be: 

R80, the second biggest Check Point revolution

We will discuss the following topics: 

  • tech and marketing drivers behind R80, 
  • a historical view on Check Point releases
  • what's new for both management and gateway
  • why it takes over three years to release full version of the product?
  • what are pros and cons of moving to R80
  • what to expect in the near future

We plan to record the session and to put video online later on. As we are using the free tools for the service at the moment, the seminar will be limited to 50 live participants and will last only 40 minutes.

The session links and invitation details are now available

Follow us on Facebook and Twitter. You may also send us an email (cpvideonuggets (at)

CPET project relies on your support. Participate in the talks and help us with your donations to

Thursday, April 6, 2017

CPET mission statement

The goal

CPET provides an innovative way to share knowledge and technology expertise for Check Point security professionals. We are going to address the full spectrum of Check Point related topics while focusing on architecture, optimization, troubleshooting and best practices. 

We do not want to replace other existing platforms and services, such as Check Point Education Services and Check Point User Group forum (CPUG). Instead, we help Check Point tech community by providing a new tool for social and professional interactions.


This is an independent technological initiative. We maintain integrity and transparency. We stick to the principles of CPUG community

- We tell the truth and help each other out.


We will run one hour long web seminars with an option to share a recorded version of events to those who could not participate. We plan to hold one or two seminars per month.


CPET is created by Valeri Loukine (Val). Val is known for his CCMA blog and his role in CPUG community. He is also a CPUG ambassador in Europe.

We are open to other presenters and experts to help us share the load. Contact us if you want to be a speaker. 

How much does it cost?

We believe sharing knowledge is part of success. Our mission is to make CPET accessible and affordable for a wide audience. As of now, we allow free participation in the live seminars to everybody. We are also considering a subscription or a crowdfunding campaign later, for accessing the recorded sessions. We plan to figure out associated costs of CPET during the pilot phase. We reserve a right to change the CPET commercial model to provide a viable and affordable service.


We consider CPET a community service. We volunteer our personal time and efforts to the cause, freely and independently,  outside of our daily jobs and professional obligations, without affiliations with our employers and/or particular technology vendors. 

Community Support

To make the initiative a success, we need your support. Spread the word, participate in the sessions, provide your feedback, share your expertise, be proactive. 

If you want to back us up financially, make your donation.


At this moment, we are open for sponsoring offers. If your company wants to support this initiative, please contact us.

Stay in touch

You can find us on Facebook and Twitter. Val’s CCMA blog will be the main tool to share information about events and to collect your feedback. You may also send us an email (cpvideonuggets (at)

When do we start?

The first pilot pilot will be announced in about a week from this moment. We will post the details in this blog and on social media. 

Stay tuned!

To support, send your donations to

Tuesday, April 4, 2017

CPUG papers - even better that R80 book

The last year I have made an announcement that four people decided to write a book about R80. Since then we, the authors, were working on multiple challenges, such as different writing styles, four time zone, variety of interests and preferred subjects, and finally, long delays around R80 management and gateway releases.

We have produced tons of content, we have spent multiple personal hours discussing the project, its structure, deadlines and its commercial models.

Finally, pushed back by long anticipated R80 gateway then is still not around, we have decided to revisit the original idea of a book. Then, we invented CPUG papers.

With the CPUG papers, we embrace different styles, interests and backgrounds. We are not able to release chapter, or papers, as we call them, gradually once each piece is ready. And, most importantly, we want our work to be available to the community free of charge. Today, the first CPUG paper is published: Brief History of Check Point Firewalls.

There are PDF and ePub version of the paper. All you need to access them is CPUG membership.

Thanks all for your interest and your comments.

To support this blog send your donations to

Saturday, April 1, 2017

Check Point merges with Palo Alto Networks

Unimaginable happens. In the just released statement Check Point Software Technologies and Palo Alto Networks announce a merger. The new company will be called CPAN - Check Point Advanced Networks.

The merger will get into effect immediately. Two companies are also merging their stock shares, bringing total capitalization to incredible 25 billions. New CPAN shares will be traded both on NASDAQ and NYSE.

Finally, it all makes sense, guys. All these 11 years it smelled fishy, but I could not put a finger on it. Yet today, 1st of April, year 2017, the mystery is in the open, finally. We have all seen the writings on the wall, but the puzzle was too complex to predict this outcome. Oh, the drama, Shakespeare is really jealous.

So, let me outline it for you, all historical details, stage by stage.

Stage 1. Largo 

In 1999 Nir Zuk, a renown Check Point engineer and brilliant developer, leaves Check Point and founds his startup OneSecure. The trap is set, and NetScreen gets into it, eventually. NetScreen is later acquired by Juniper. In 2005 Nir leaves Juniper, but his elaborate conspiracy scheme to bring it down is not yet activated.

Stage 2. Andante 

Shlomo Kramer meanwhile prepare another scene. He seemingly severs his ties with Check Point founders and goes rogue. In 2005 he reconnects with Nir and two of them create Palo Alto Networks.

Stage 3. Allegro 

PAN goes to the market with NGFW scheme. Both Fortinet and Juniper are startled, Check Point also seems not to be amused. Same time Nir finally activates his mines at Juniper, and the company starts falling down.

Stage 4. Presto 

PAN ascends on the security market like a rocket, acquiring market share from crumbling legacy firewall vendors. Mind you, Check Point maintains its market share and seems to be unaffected PAN's ride to power.

Stage 5. Fuge

Once both Check Point and PAN rise to practically the same revenues, as I mentioned in one of my recent posts, everything is ready for the grand finale. The issue of PAN's capitalization being too high for the merger is corrected at the beginning of the year after announcing caution to investors. PAK share prices declined 25% after such announcement.

Then BOOM! Two titans merge!

What a ride, guys, what a ride... I have to confess. I did not see it coming. Probably, nobody did. We all have been fooled by apparent fight and very vocal competition between two companies. And yet again, that was the textbook deception trick. That was the perfect cover!

Starting today, the world of information security is irreversibly changed. Check Point has secured its future once more - the future of market domination.

UPDATE: Just in case, this was April's fools day, guys

To support this blog send your donations to

Thursday, March 30, 2017

Introducing Check Point Expert Talks - CPET

Hi all!

In my previous post I have asked you about willingness to participate in a live seminars around Check Point. I was surprised and humbled by your response. About 25 percent of people who read that post participated in the survey. That is much more than I would expect.

The most popular topics are troubleshooting, optimisation and best practices. Guess what, I am teaching those courses for more than 10 years now.

Teaching a class, even a virtual one, takes lots of effort and is still limited to just tens of participants. Yet, tens of thousands of security professionals could benefit.

There are some public knowledge sharing resources such as and (not so public) SecureKnowledge database. The issue with both is that most if the info there, although extremely valuable, addressing very particular and mostly limited topics. Making a big picture out of those puzzle pieces is an herculean task. One more challenge is that neither platform allows an effective conversation.

Check Point Education Services have a wide network of training partners delivering official courses such as CCSA and CCSE, but they only briefly address some of the mentioned topics.

Something has to be done about it, don't you think?

My goal is to start a new mission. It has to be affordable in terms of personal time investment. Something that I could do in my free time outside of my day job workframe. It should be public and approachable. It should be regular. It should be in a form of an actual discussion, with later ability to recap the touched topic for better understanding.

Here it is - Check Point Expert Talks - CPET

I want to commence running one hour web seminars once or twice a month, on Sundays. I am planning to record the sessions and to put it somewhere participants will be able to access them later.

This is still an open idea, and there are lots of unknown about it: platform choices for both seminar and hosting videos, particular times for the sessions, associated costs and even an amount of efforts to spin this out.

Mission statement and information about a pilot run will follow the next week. Thank you very much for your support and encouragement.

To support this blog send your donations to