If Only App Control Were Around When Pointcast Was A Thing

Back when I first got into IT and just started working with FireWall-1, Pointcast was a thing. For those who weren't around back in the mid to late 1990s, Pointcast had a very popular screensaver that displayed news and other information delivered periodically over the Internet to PCs. The problem was: it used an excessive amount of bandwidth on corporate networks, especially if more than a couple of people used it.

The result was, of course, corporations wanted to block access to Pointcast. The problem: how to do it. All we had in the mid 1990s was the traditional firewall which could control access based on IP and port. So we should be able to block the port or IPs it communicates with, right?

Pointcast used good old HTTP. Even back then, no one in their right mind would block HTTP. Of course, everything uses HTTP or HTTPS to communicate these days, and with a traditional firewall with the ability to control traffic only by IP or port, leaving HTTP or HTTPS wide open is tantamount to leaving the barn door open. 

Pointcast didn't exactly publish their list of servers, but users of the PhoneBoy FireWall-1 FAQ contributed a list of IPs plus a couple of other clever solutions to the problem, which I've made available after the break if you're curious.

Of course, with things like content delivery networks, Amazon Web Services, and a host of other ways to serve up an application to users that are available today, attempting to control access to these applications merely by port and IP address is crazy. 

Fortunately, there are a number of solutions to this problem. Check Point's solution is the Application Control Software Blade, which can allow/block access to an application regardless of the ports and destination IP users, and even limit the bandwidth these applications use. New applications or changes to existing applications are made available to the gateway periodically so you can see that you're users are using it and, when it kills you bandwidth or worse, you can block it. 

If only tools like App Control were available back in the day, security admins could have spent more time on more important issues rather than figuring out how to block Pointcast and other applications and I would have a few less FAQ entries on "how do I block X application."

Read more »

No Good For Workloads? Depends on the Workload.

From Chris Hoff's (a.k.a. Beaker) NGFW = No Good For Workloads:

NGFW, as defined, is a campus and branch solution. Campus and Branch NGFW solves the “inside-out” problem — applying policy from a number of known/identified users on the “inside” to a potentially infinite number of applications and services “outside” the firewall, generally connected to the Internet. They function generally as forward proxies with various network insertion strategies.

If you look at the functionality Check Point and its various competitors provide, this is precisely what a large chunk of the "next generation" functionality is geared towards--protecting a number of known/identified users from the dangers they might encounter from a potentially infinite number of application and services. There are differences in how the different security solutions perform this task, as well as how well they perform, but that's their overall goal.

That is, as Beaker continues, very different from what a Data Center firewall needs to do:

Data Center NGFW is the inverse of the “inside-out” problem.  They solve the “outside-in” problem; applying policy from a potentially infinite number of unknown (or potentially unknown) users/clients on the “outside” to a nominally diminutive number of well-known applications and services “inside” the firewall that are exposed generally to the Internet.  They function generally as reverse proxies with various network insertion strategies.

In other words, we're not always sure who is coming in, but we know what they are going to and (hopefully) what applications and services they are going to connect to. 

What kinds of protection do you need in these scenarios? Usually very different. Can every next generation firewall provide just the right protection? 

First, let's take a step back and realize that the Data Center itself is very different from what it used to be a decade or two ago. Whereas we started with a number of servers hosting resources in one or two physical locations with users mostly in known physical locations, we now potentially have services, data, and users all over the place, with a mix of physical and virtual servers where traditional methods of segmentation and protection are not practical. 

The "core" of the enterprise network--where all the necessary resources ultimately connect together--is quickly becoming the Internet itself. How do you protect your resources in this reality?

We go back to one of the fundamental tenets of information security, our old friend segmentation. This means grouping together resources with like function and like information confidentiality levels, placing a enforcement point at the ingress/egress point where you can enforce the appropriate access control policy. The goal for that enforcement point? Let the authorized stuff in and keep the unauthorized and bad stuff out. 

Of course with virtualization, end user PCs, and mobile devices, the boundaries become more difficult to apply but with virtualized security solutions, integrated endpoint security on the end user PCs, trusted channels (VPNs), and secure containers on mobile devices, more is possible than you think. Check Point and other companies have various solutions for this. 

Once the network is segmented and enforcement points are in place, then you can decide what protections and policies should be applied. In some cases, like on User Segments, you want lots of protection as users could go anywhere on the Internet and unknowingly bring in some malware to run amok in your network or send company secrets to their Gmail account. For your data center? Maybe you just want to make sure authorized users can reach specific applications and you want to sanity check the traffic to make sure it's not malicious. Or maybe you just need a simple port-based firewall with low latency for a given app.

The idea of putting a firewall as the core of your network--especially a next generation one-- is silly, as Beaker rightfully points out. Really, your core should be a transit network with enforcement points--those things we typically call firewalls--at the ingress point of the various network segments. This way, just the right policy and just the right protections can be applied without applying them to traffic that doesn't need it. 

This is where I think Check Point's portfolio shines. In the Security Gateway space, the Software Blades architecture is flexible enough to allow you to be very granular about what protections are applied to a specific enforcement point, whether a physical gateway, or a virtual one either in a Check Point chassis (e.g. VSX) or in a VMware or Amazon Web Services environment. This means you can scan a random MS Word document from the Internet for malware on one gateway close to the users while not impeding the flow of traffic in and out of your Data Center that flows through a different Security Gateway. And yes, if you have a 5 microsecond transmission requirement, Check Point has a solution for that with the Security Acceleration Module in the 21000 series of appliances. 

Does an NGFW solve every problem? No, and anyone that tells you it will is flat out wrong. It's not always the right tool for the job, as Beaker points out:

Show me how a forward-proxy optimized [Campus & Branch] NGFW deals with a DDoS attack (assuming the pipe isn’t flooded in the first place.)  Show me how a forward-proxy optimized C&B NGFW deals with application level attacks manipulating business logic and webapp attack vectors across known-good or unknown inputs.

While an Enforcement Point needs to be hardened for DDoS--especially if it is exposed to the Internet--no Enforcement Point is going to completely mitigate a DDoS. There are a number of mitigation strategies that include on-premise DDoS-specific appliances as well as external services, which I know Check Point has advised customers to utilize in various scenarios as part of their Incident Response Services.

Likewise, business logic and webapp attack vectors are outside of the wheelhouse of all NGFWs. You still need to properly secure your web applications, even with an NGFW in place. In addition, there are dedicated, Web Application Firewalls for this purpose and if you've properly segmented your network, you can make sure only those resources are protected by them.

At the end of the day, a Next Generation Firewall, whether it is from Check Point or someone else, is not a panacea. It can be a powerful tool, but like all tools, it needs to be applied properly as part of a comprehensive security strategy that begins with proper segmentation and a well-defined policy. From there, you can apply just the right protection to just the right resources.

Disclaimer: It should be obvious from my last post I work for Check Point, but this is my own opinion. 

Growing Up With Check Point

Note: I've released a podcast of this article if you prefer. 

The 20 Year Anniversary of Check Point's founding has a special place in my heart. Mostly because it is how I personally made my career. How I got involved in Information Security. How I, unbeknownst to me at the time, helped a lot of people get into Information Security.

18 years ago, I had no idea what Information Security was. I was a systems administrator working for a contracting agency fresh out of college. I did some odd programming jobs which, quite frankly, I was never that great at, and eventually, an interesting contract: doing tech support for a company out of San Mateo, CA.

The product: Qualix HA, a high availability product for Sun Workstations based on a Veritas product. One of the products we also sold along with it and provided high availability for was a product called Check Point FireWall-1.

That contract turned into a full-time job and eventually, as the other people in the group kept getting hired out to do "professional services" or whatever, I had to learn FireWall-1 the hard way: by supporting customers calling for help without much of a backstop.

Back in those days, Check Point did all of their support out of Israel. SecureKnowledge didn't exist. They had a mailing list, which had a lot of questions asked on it, but not a lot of answers.

On a hidden page on the Qualix website, there was an FireWall-1 FAQ started by one of the developers at Qualix. I started writing entries on it. Eventually, I got permission from Qualix to take the content and put it on my website--phoneboy.com.

Qualix became Fulltime Software and got bought by Legato Systems in 1999. Before that happened, I got a job at Nokia in their IP Routing Group--the guys who make the firewall appliances that ran Check Point's firewall. 

PhoneBoy's FireWall-1 FAQ existed for the better part of 8 years as a publicly available resource containing the knowledge I collected about the Check Point products from the mailing lists and my own work with the product as a technical support guy. Obviously a lot of that knowledge also migrated itself into Nokia's Knowledge Base, which I more or less maintained during my tenure there. It also made its way into two books that I published with Addison Wesley (now Pearson Education).

In parallel, I created a moderated mailing list on FireWall-1 in June of 2000, first called FireWall-1 Wizards, then renamed to FireWall-1 Gurus after the folks who own the Firewall Wizards trademark suggested I should change the name. The mailing list lasted for about 9 years.

Around 2003 or so, I started burning out. Technical Support is a difficult job to do long term in general and I had done more than my share. I ended up moving onto other things inside Nokia's Enterprise Solutions or whatever it was back at that time. In 2005, I agreed to let Barry Stiefel take the content on phoneboy.com and copy it onto cpug.org.

I kinda thought I was done with Check Point stuff by then, but I was wrong. I kept working with Nokia's Knowledgebase for the Enterprise Solutions group, which had a lot of Check Point content in it. This meant, for me, reading, writing, and re-writing this content. I kept mentoring folks in the TAC when they had issues with Check Point or just general network troubleshooting. I kept supporting other products that were somewhat Information Security related (VPN and Remote Access product as well as Sourcefire on Nokia).

When the Check Point acquisition of Nokia's Security Appliance business was announced, I wasn't sure what to expect: for a platform that I spent 10 years of my life supporting as well as my own career. When it became clearer that I had a home at Check Point, I began to start looking a bit more closely at the Check Point products again.

What I discovered was that the product hadn't changed all that much. Sure, there was NGX, the rise of Secure Platform and Check Point's own appliance offerings, and many refinements along the way, but the fundamentals of the product were basically the same.

But change was happening: I could see it before I was officially part of Check Point as I was told about the new IPS Software Blade in R70. As I started visiting the Check Point headquarters in Tel Aviv, I got to hear in more detail from the people who develop the product. I got to see the changes up close and personal. App Control, URL Filtering, Anti-Bot, the new (and old) SMB products, DLP, appliances, Gaia, I got to see it all before it was released.

Also, Check Point made a couple of key acquisitions prior to Nokia's Security Appliance business: Pointsec, which was a well-known disk encryption solution, and Zone Labs, which made the ZoneAlarm desktop firewall product. Both of which ultimately became part of Check Point's Endpoint Security offering along with the later acquired Liquid Machines to provide Document Security along with Dynasec to provide Compliance solutions to Check Point's overall product portfolio.

It's been a beautiful thing that I'm proud to say I've been a part of since nearly the beginning. And, of course, there is a lot more to come.

Let's face it: the threats to our networks have only gotten more complex, more dangerous. A lot of the fundamental issues in Information Security haven't changed, either. End Users still do unwise things. Companies don't invest enough time or money in doing the basics in security practices like segmentation, user education, changing default passwords, and a whole host of other practices.

The Information Security market has many players. Check Point plays in many spaces with different competitors in different segments but continues to grow and innovate year over year and continues to remain independent and focused on the goal of securing the Internet in a sea of acquisitions by larger, less security focused companies. 

Here's to another 20 years, Check Point. 

Blast from the CHKP Past: Can't Talk to Translated IP from Internal Net

It's pretty obvious from looking through the number of 404s I'm seeing in Google's Webmaster tools that a lot of pages still link to old stuff I wrote about Check Point FireWall-1. I'm actually trying to "fix" these 404s now by resurrecting some of the old content.  Not updating it, of course, but at least making the links point to something semi-useful, if historical.

This is one of those articles, obviously not at it's original URL, but the original URLs will point here. What amazes me about this particular article is that it's still relevant today as NAT really hasn't fundamentally changed in the Check Point products for some time. The basic concepts are still the same, too, and other than the implementation details, is probably relevant for other security products, too. 

Bottom line: NAT only works if the firewall is in the path of the communication. How do you know? Follow the bouncing packet, otherwise known as Troubleshooting 101. 

Hit the break to see this old FAQ in all its ASCII network mapped glory.

Read more »

The TSA and A Lesson in Data Loss Prevention

From PhoneBoy Speaks Ep 305: Threat? What Threat?

In sealed court documents accidentally leaked on a US Federal government website, the US government basically admits that there has been no attempted domestic hijackings of any kind in the 12 years since 9/11. Furthermore, at least as of mid-2011, terrorist threat groups present in the Homeland are not known to be actively plotting against civil aviation targets or airports.

It gets better. Jonathan Corbett, the guy who has been challenging the feds on the constitutionality and the effectiveness of the TSA in the courts, was told by the US Justice Department to take down his comments about a sealed document he wasn't allowed to talk about, but the government themselves posted the unredacted version on their site and other sites made it public.

The same is true for Corbett's comments about those documents, the Justice Department asked him to remove from his site, but they apparently forgot to tell Google as it was still in their cache!

This is a clear demonstration of what can happen if confidential data inadvertently leaves your organization. Clearly this unredacted, sealed legal brief should have never been made public. Thankfully, in this case, it was, but surely some folks in the US Government weren't happy with this lapse. Neither would your employer if it's your company's secret plans for world domination that got leaked.

Likewise, if you inadvertently leak information on your own website, or someone else does, even if you can manage to get it taken down, Google takes a while to forget it saw it. The rest of the Internet won't necessarily forget, though. Ever.

So what are your plans for Data Loss Prevention in your organization? Are you even employing any DLP technology? Is it actually catching real incidents of data loss or is everyone going around it? 

I'm not saying DLP is a panacea or 100% effective, but if you're not doing it, then you don't have any idea where your corporate information might end up. 

FireWall-1 User Interface from 3.0

If you ran Check Point FireWall-1 on SunOS or Solaris, you probably remember this screen:
This is a screen capture from fwui, the management interface for FireWall-1. Actually FireWall-1 2.0 and 2.1 looked like this too.

Meanwhile if you ran the management interface on Windows, you were presented with something like this:
You could actually run the firewall on Windows NT as of 2.1, though it took until 2.1c until it was reasonably stable.

Actually you could run something that looked like the Windows UI on Solaris with Motif, which Check Point charged extra for. Eventually the Motif and the OpenLook GUI were deprecated and what we now refer to as SmartDashboad only runs on Windows.

And, of course, there are far more GUI clients these days--about a dozen or so if I remember correctly. But then again, the product does so much more today than it did back in the mid 1990s.

And yes, I remember those days quiet fondly.

Blast from the CHKP Past: Can't Get Putkeys to Work

For those of you who never had to work with Check Point FireWall-1 4.1 and earlier, you're lucky you likely never EVER had to use putkeys.

The fw putkey was used to establish authentication between the Management and Firewall modules. The problem was: the authentication would frequently break. Especially in larger, distributed environments. Often for reasons that no one outside of a few developers in Tel Aviv never fully understood.

The eventual replacement for fw putkey was SIC, which was added in FireWall-1 NG (5.0). It is based on certificates and is way easier to set up. It's also far less prone to random breakage. 

The following classic article is presented for nostalgia purposes only. Hopefully no one in their right mind still needs this article, which was very popular on my FireWall-1 FAQ back in the day. It was the collective wisdom of my peers and my own experience as of around 2000 or so.

Read more »

Moving The Security Theater Elsewhere

I decided to move PhoneBoy's Security Theater off of Wordpress onto Posthaven

On the plus side, it's one less instance of Wordpress to maintain. On the minus side, I had to copy/paste the old articles in since there is no way to import Wordpress as of yet. But it was under 100 articles and it was kind of nice to see my thoughts on security from the last several years again.

The reality is, the threats haven't changed. We've had to evolve the tools in order to address increasingly complex threats. You can look at Check Point's own product evolution to get a sense of that.

Also, the basics haven't changed. A lot of security risks can be sufficiently mitigated by properly segmenting your networks, using sufficiently complex passwords that are unique, proper monitoring of the logs of your security devices, and keeping your software up-to-date with the latest security patches. 


Fun with Compliance

Earlier this week, I hung out with Jeremy Kaye, one of our in-house compliance experts at Check Point:

http://www.youtube.com/embed/uvL6HdlrW08

While I've been doing InfoSec for a while, or at least working in companies that sell InfoSec products, compliance isn't something I've had a ton of direct experience with. Sure, Check Point customers used our products to help meet various compliance regulations, but until Check Point acquired DynaSec in 2011, there wasn't a team inside Check Point dedicated to this topic.

While we had some technical challenges with the Google+ Hangout itself (and it was the first one we did at Check Point), I think the conversation with Jeremy went fairly well. The questions I asked where ones I've always wanted answers to. Like, what good is compliance? Why does it seem like compliance is in the eye of the auditor? Why so many regulations anyway?

The big takeaway for me from this conversation is that security should drive your compliance efforts, not the other way around. Because chances are, if you have a strong information security program in place already, compliance is pretty straightforward, no matter which regulations you have to comply with.

Check Point 600 Appliance: Big Security for Small Business

Ok, this is a completely shameless plug for my employer. But it's really big. And really small at the same time. And my take on it, which wasn't cleared with the marketing folks, and thus my, albeit biased, opinion.

The Check Point 600 Appliance, which was announced today at Interop, represents Check Point's refreshed entry into the SMB Security space. It provides the same security functionality you'd find in Check Point's larger appliances in something that fits into an SMB--both in terms of form factor and price. This includes Check Point's award-winning IPS, App Control, URL Filtering, Anti-Virus, Anti-Spam, VPN, oh and don't forget the firewall :)

If you're familiar with the SG80, which Check Point launched a couple years back, the new 600 Appliance looks a bit like that, though the internals are slightly different from the SG80. There are standard USB ports, Express Card and SD-card slots in the 600 as well as optional WiFi and ADSL ports. It also includes a revamped Web Interface that incorporates functionality from the UTM-1 EDGE and Safe@ appliances allowing full management of the security policy across all Software Blades.

Under the hood? It's nearly the same code that runs in the larger Check Point appliances--Check Point R75.20 running Embedded Gaia, to be exact. When you SSH or serial console into the appliance, you are presented with clish, which functions similar to how it does on one of the larger appliances. You can also drop into Expert mode for more advanced debugging, which again, works very similar to how its done on the larger gateways. 

The main differences between the 600 and the Check Point 1100 Appliance, which was announced a few weeks ago are:

  • Lower price: List price of a 600 is roughly $200 cheaper than the comparable 1100 model.
  • Chassis color: Bright orange, like the old Safe@ boxes.
  • Central Management: While the 1100 can be centrally managed with standard R75.46 or R76 management (standalone or Provider-1), the 600 can only be centrally managed by Check Point Cloud-Managed Security service.

In any case, I am truly excited about this as finally, SMBs can finally get the same Enterprise-grade security that the Fortune 100 relies on for a fraction of the cost--starting at $399.

Check Point's SMB Portal has information about the new appliances as well as how to acquire them.