I've heard of companies outsourcing jobs to China. I used to joke with my remote co-workers that I had been replaced by a Perl script. That said, I never heard of an employee outsourcing his own job, going so far as to FedEx his RSA token to China so they could log into the VPN and do work on his behalf. While the real guy was in the office, working!

Regardless of what security or remote access solution you use, if you're not looking at your logs, you have no idea if you have a problem! That's how "Bob" was able to get away with this for months! No one bothered to look at the VPN logs and notice there was a remote access VPN connection going from China during the workday!

Of course, with the sheer volume of logs that your different security or remote access devices generate, it's hard to know what to look for. This is why large companies in particular employ Security Information Event Management systems (SIEMs) which attempt to gather and correlate this data from disparate systems to try and help you find that problem needle in the haystack of security logs--finding the key events that you need to focus on.

Check Point puts out a SIEM for its own product suite called SmartEvent, which works across all of our Software Blades and distills the hundreds of thousands of logs into useful and actionable data, telling you the things you need to know about what's going on through your ChecK Point infrastructure.

Regardless of whose security or remote access solutions you employ, if you're not looking at your logs, you have no idea what's going on!

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.

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.

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.

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?