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.

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.

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.