Posted on by

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.

Posted on by

Check Point 2013 Security Report

When I was in Israel at the end of 2012, I was talking with the folks putting the finishing touches on the Check Point 2013 Security Report. Of course, since then, the report has been formally released and you can now read it for yourself. Here’s a video preview of what you’ll find in it:

Some of the data gathered for this report was related to the 3D Security Reports Check Point generated for customers during 2012 where we took a Security Gateway and either ran it in-line (in bridge mode) or plugged it into a mirror port on a customer’s switch. It’s worth pointing out that, in many cases, a competitive security solution was already in place and the Check Point Security Gateways were seeing stuff the other solutions were missing.

Other data for this report also came from SensorNet, ThreatCloud, and results from our Endpoint Security Best Practices Report, which is a great way to find out if your Windows PC is configured according to our Best Practices.

The most surprising statistics?

  • 63% of the organizations surveyed had at least one malicious bot in their network. 
  • 43% of the organizations surveyed had traffic to/from an anonymizer service.

Of course, if you’re knee deep in the security space, 0% of this is news to you.

Posted on by

How to Not Be Like Burger King. Or Jeep.

On today’s episode of PhoneBoy Speaks, I discuss how to prevent your Twitter account from being hacked like Burger King’s account was. And today (after I recorded this episode), Jeep’s Twitter account was also hacked. Of course, I can only do so much in a 5 minute podcast, and the topic itself of choosing strong passwords–and getting users to actually do it–has been covered ad-infinitum elsewhere.

The fact is, passwords are not very secure. To be secure, they must be both long (number of characters) and high-entropy (more random, the better). Humans, as a lot, are not able to remember passwords that meet both of these requirements, so they cheat. They either write the passwords down, they use password management tools like LastPass or 1Password, or they just choose stupid passwords–usually the latter.

The best compromise I’ve seen is actually the Password Haystacks method that Steve Gibson came up with. All other things being equal, as long as you use all 4 different types of characters in your password, length wins. Because when it comes to guessing passwords, there is no such thing as “close.”

Of course, if the password itself can’t be guessed, surely you can compromise the password reset process, as was done with Mat Honan’s widely publicized pwnage. Hopefully we can strengthen that too, but companies–especially ones that cater to non technical people–rarely err on the side of secure.

Posted on by

Securing Data in the Cloud

On my podcast PhoneBoy Speaks today, I discussed (very briefly) the idea of doing information security in the cloud. Surely, I could talk and write volumes on the subject. I’ve even given presentations on the subject.

The reality is, virtualization changes the game in so many ways that it’s hard to know where to begin. That said, my view starts with the most basic question: what is it we’re ultimately trying to protect?

The good news is that the answer is still the same, regardless of whether physical servers on your premises are involved or some cloud services provider is: it’s the data. Your job in information security is to ensure the Confidentiality, Integrity, and Availability of data to prevent Disclosure, Alteration, or Destruction of said data.  

The bad news: the cloud makes this job a lot harder. The reality of bring your own device (BYOD) also makes this harder for much the same reason–less opportunities to inject the necessary controls to ensure data doesn’t go where it’s not supposed to.

Of course, it’s not just about protecting the data. That part is actually pretty easy. Protecting in a way that allows it to be used in a convenient way, now that’s a lot harder.

Posted on by

Zen and the Art of Malware Detection

Detecting malicious code that enters your network is challenging problem that traditional anti-virus and anti-malware can’t keep up with. These tools use a series of heuristics and static signatures to try and detect malicious code.

Tomer Teller, a security researcher and evangelist at Check Point, told me about an incident at the 29th annual Chaos Communication Congress where the crowd of security professionals were asked if anyone is actually using AV. Not a single person raised their hand.

How much value does AV provide? There was an article put out by Imperva that got misquoted and misrepresented in the media. The main message? AV only catches about 5% of malware. The real story is a bit better, but it’s still not all that rosy.

To help you understand why this problem is particularly tricky, consider how many ways you can write a “Hello, World!” program–often one of the first programs you write when learning a computer language. It is so called because the program writes the phrase “Hello, World!” to the output device. It’s often a simplistic program, such as the following C-based example:

#include <stdio.h>int main() {    printf(“Hello Worldn”); }

A more complex example (that I borrowed from here) might look something like this:

#include <stdio.h> #define THIS printf(
#define IS “%sn”
#define OBFUSCATION ,v);
double h[2]; int main(_, v) char *v; int _; { int a = 0; char f[32]; h[2%2] = 21914441197069634153456391018824026170709523170177760997320759459436800394073 07212501870429040900672146338833938303659439237740635160500855813030357492372 682887858054616489605441589829740433065995076650229152079883597110973562880.0 00000; h[4%3] = 1867980801.569119; switch (_) { case 0: THIS IS OBFUSCATION break; default: main(0,(char *)h); break; } }

Replace “print Hello World” with “inject code into target host using latest exploit” and you can begin to understand why it is so hard to detect malicious code by simple inspection.

That isn’t to say that static analysis provides no value–it does. It catches the really obvious stuff. Unfortunately, it’s not foolproof.

Posted on by

In Information Security, Trust Matters

In a previous post, I asked if we could trust no one in Information Security. The reality is that, at some point, we have to trust. We have to trust that we have the right policy in place. We have to trust our people to do the right thing. We have to trust our tools will do their job.

Of course, we should not blindly trust. We need to evaluate that our tools are doing their job, keeping the bad stuff out and enforcing the policy you’ve specified. We need to trust that our people are doing the right thing. Your tools are both enforcing the policy and educating the users about what the policy is, right? And, of course, you need to evaluate the policy to ensure it is both effective and in-line with business objectives.

If Information Security professionals spend all their time doubting everything, not only will they drive themselves crazy, but the real threats will get by.

Along these lines, The marketing folks at Check Point put together a video discussing trust and its very important role in Information Security.

Posted on by

Unsafe at Any Version?

It’s funny, every time I read about yet another security vulnerability in Internet Explorer, such as the recent one involving Adobe Flash hosted on the Council of Foreign Relations website that performs a heap spray against Internet Explorer 8, I am reminded of the old Ralph Nader tome Unsafe at Any Speed, which was a book released in 1965 about how unsafe the automobiles designed by the American Auto Industry are. Thus, the phrase “Unsafe at Any Version” seems to come to mind when I think of Internet Explorer. Likewise, I tend to think the same thing about Adobe Acrobat, Adobe Flash, or Adobe Shockwave (2 year old vulnerability, anyone?)

Is it fair to say these products are unsafe at any version? While evidence seems to suggest that is probably true, I believe the security problems we see in these products are evidence of their success. Okay, maybe Internet Explorer was successful because of being illegally tied to Microsoft Windows, but I’m trying to remember the last time Internet Explorer, Adobe Flash, and Adobe Acrobat Reader were not considered “required items” for a PC.

Which is part of the problem of keeping these programs secure. There is a lot of legacy code in those apps. They were written well before Secure Coding Practices became the norm. Internet Explorer itself has a fundamental flaw by being so tightly tied into the operating system. Rewriting code is no fun and, unless there is a significant business reason to do so, doesn’t happen.

Granted, Adobe did do this with Adobe Reader, but there’s still a lot older Adobe Readers out there still, just waiting to be compromised. Just like there are millions of people still running XP and Internet Explorer 8, which Microsoft will eventually stop providing security patches for.

These applications aren’t going anywhere anytime soon. Which means the bad guys are going to continue to find vulnerabilities in these applications for the foreseeable future. It certainly will keep us good guys busy for the foreseeable future, too.

Posted on by

Trust No One?

Trust. It’s something I’m sure many security professionals think about in various contexts. However, I don’t think anyone can fully appreciate the level of trust that we exercise on a daily basis without really thinking about it.

Just think about getting packets from point A to point B. There’s an insane amount of things we simply trust without really thinking about it. This includes:

  1. The program running on point A to generate traffic: who created that program? Will that program do something you don’t expect?
  2. The OS running on point A: is that program running through an OS where key calls are “compromised” in the same way that the recent Linux Rootkit was?
  3. The various processors that run on point A: are those processors calculating true? Will they have a divide-by-zero bug like ye olde Pentium processors? Or did someone replace the processors in your device with one that purposefully does what you don’t expect?
  4. The transmission medium of those packets: how secure is that medium? Who (or what) can read those packets off the wire, or the air as appropriate?
  5. The routers and switches along the way between point A and point B. They, too, are computers running code, are they not? Are they configured correctly? Will they route the packets along the path you expect? Are they potentially compromised as a result of bad design or malicious intent?
  6. Point B, that receives the traffic: does it believe what it is reading off the wire? How does it know Point A sent it? Will Point B process it correctly?

And so on. Trying to account for all these possibilities to ensure absolute security is next to impossible and will surely drive you crazy. That said, the thought exercise is important if you’re trying to design a secure system. All of your assumptions about various elements of that system must be examined on a regular basis to ensure that you don’t miss when something transitions from a largely theoretical threat to a very real one.

Soon, I’ll share some ideas on what a “trust no one” network might look like. Does such a thing exist today? Is maintaining such a thing even practical?

Posted on by

How to COPE with BYOD

If you’ve been in the IT industry long enough, you’ll start seeing the same concepts “reinvented” every few years or so.

The current panacea is so-called Bring Your Own Device–the idea that an end user can use their own technology devices in a corporate setting while having some level of access to corporate data. While we went through this with laptops and personal computers over the years, now the devices we are bring our own of? Mobile phones/tablets.

Another acronym I’ve heard recently describes the state of IT, again, as long as I’ve been in it–Corporate Owned, Personally Enabled. Here, the idea is that a corporate-owned asset is used for an employee’s personal needs. This has been the case with corporate-owned PCs forever without any formal policy for the last couple of decades. Now we’re starting to see this with mobile devices, either with or without the use of third party tools.

The reality is that, regardless of whether companies adopt BYOD, COPE, something else, or neither, the reality is, employees are going to use personal devices to do work. And, likewise, use corporate devices for “personal use.” This has always been the case and will always be the case, regardless of any formal policies to the contrary.

From a security point of view, this creates some rather obvious issues. On corporate-owned devices, some sort of “device management” or “Endpoint Security” offering is installed, which users tolerate to varying degrees. (I happen to like Check Point’s Endpoint Security offering, but I will admit, I’m biased.) BYOD won’t work because users are often asked to submit “device management” or an “Endpoint Security” installation in order to use their own device on the corporate network.

But ask yourself: what is it that you’re really trying to protect on that endpoint? Prevent malicious software? You have a properly segmented network, right? You have the technology to detect any malicious traffic from that segment, right? Good. That should take care of it.

But what if the software doesn’t “phone home” while on the corporate network (or generate malicious traffic), but collects data and then sends it out over the mobile operator’s network? Modern mobile operating systems have these things called sandboxes that prevent one app from reading data from another in the first place. Obviously, if you’re jailbroken or rooted, all bets are off.

And malicious apps, while not unheard of, are nearly non-existent in the official App Stores for iOS or Android. Same with potential privilege escalation-type attacks in iOS and Android. Not impossible but a lot harder to pull off, given that Android and (moreso) iOS are pretty secure out-of-the-box.

Really there’s only one thing to worry about on these devices: the corporate data. This data needs to be protected. Which is generally pretty easy to do assuming only a trusted application is able to access the data, the regular OS protections are in place (i.e. device isn’t rooted or jailbroken). And, of course, the data has to come on and off the device in a secure manner (e.g. either with strong encryption or using a physical access mechanism).

Once you have the magic, trusted app (or suite of apps) to access, work with, and secure the small amounts of corporate data the device can work with, congratulations! You’ve now eliminated the headache of managing potentially unknown devices in the hands of users who will do everything they can to thwart your security controls anyway. If users want to work with corporate data, they can use the “trusted” apps to do it, which should have appropriate hooks back to corporate to validate whether you are able to even use the data and, if you or your device goes rogue, wipe the data from your device without wiping the entire device (which has personal data on it).

While I believe there are great solutions along these lines (yet), this is the only kind of solution I believe makes any sense in the long term. People will be able to bring their own devices and access business data while infosec will rest easy knowing business data is still  accessed and stored safely.

It’s a BYOD solution everyone can COPE with.

Posted on by

Denial of Service: An Old Classic Not Going Anywhere

The implementation details will vary depending on the attack target and the request type, but the basic concept of a denial of service is to overwhelm a target with a seemingly legitimate series of requests so that real requests are ignored and not processed. If the attack is launched from multiple points on the network, it is referred to as a distributed denial of service attack (a.k.a. DDoS).

I remember when I first started hearing about denial of service issues more than 10 years ago. I even played with a few tools to generate them on my own–in my own network, of course. Back then, defenses for this sort of thing simply didn’t exist. Aiming a tool at a helpless server protected by an even more helpless firewall was a great way to wreak havoc.

In general, there are two ways to create a Denial of Service condition:

  • Cause the relevant service to crash. This is actually pretty difficult to do in a simple fashion given the resiliency of most public-facing services, though for lesser-used services, it can happen.
  • Resource exhaustion, where some resource needed to provide the service (bandwidth, buffers, etc) is depleted in a way that causes the service to not respond to legitimate requests.

Over the years, every part of the service stack has gotten more resilient against the most basic form of these attacks. For example, a simple SYN flood won’t take down most web servers these days as web servers are smart enough not to allocate resources to a connection until the three-way handshake completes. That said, if you can get a few million of your closest friends to run Low Orbit Ion Cannon at a server, or visit a particular webpage, you can still take down a target.

To give you a real-world example of this, I’ll talk briefly about a recent denial of service someone brought to Check Point’s attention via a Pastebin posting. The attack, ironically, was not all that different from the first SYN floods I played with more than a decade ago.

According to the report on Pastebin, the security researcher was able to essentially cause a Check Point Security Gateway to stop processing packets by sending ~120k packets per second. That’s easy to generate inside a VMware environment, or even on an isolated network segment. Over an Internet link? Depends on the size of the pipe.

Regardless of how realistic that particular incoming packet rate may be in a given environment, what happens when the gateway sees that much traffic? In many cases, it simply runs out of memory, causing traffic to be dropped. It also runs out of processor capacity to forward said traffic.

Since the only way to truly stop a denial of service attack is to disconnect from the Internet, your best hope is that the various components are optimally configured to operate in potential denial of service conditions. Check Point’s official response to this issue mentions four specific configuration changes that can be made to their security gateways:

  1. Implementing the IPS protection “SYN Attack” feature in SYN cookie mode, which will reduce the memory footprint caused by these bogus connection attempts.
  2. A hotfix for SPLAT/GAiA systems that, along other things, optimizes how the SYN+ACK packets that come back from the server are processed (IPSO does not require this).
  3. Where applicable, use multiqueue to increase the number of processors that can handle traffic on a given interface.
  4. Increasing the receive buffers on the interface.
These settings have proven to be effective at mitigating a potentially large SYN flood. That said, there’s only so much you can do. Your Internet link is still a potential bottleneck. Your Security Gateways, even optimally configured, can only process so much traffic.
Unfortunately, there is no silver-bullet solution to this problem other than bigger and better servers–or security gateways. This means that denial of service is something we’re going to have to battle with for a long time.