Most of the problem with certification is that the tests primarily consist of multiple-choice tests that merely test your book knowledge or very basic reasoning skills. For example one could likely pass the CISSP or CEH with very little technical knowledge by simply reading the materials and perhaps participating in lab exercises. There of course is a bit of test-taking skill and strategy that comes into play as well.

Understanding theory in IT security(or any science for that matter) is only half of it. I think that more lab-based tests need to become part of the common testing framework. A good example is the OSCP, which is one hard-core technical test.

I've taken the CISSP, CEH, CISA, CCNA, and OSCP. OSCP being a completely practical test is definitely the only one that I feel truly tested skills versus "book smarts". If I'm ever in a hiring situation and I see the OSCP on someones resume they're going to be the first person I bring in for an interview.

I'm having a problem just like this with a book I bought. I figured it was from the heat and humidity of reading it on the beach, but maybe Amazon is getting some bad books?

Loss of revenue when doing a course or conference is definitely a perspective  of consulting that I never thought of.

I've entertained the idea of taking the consulting plunge throughout my career, but haven't been brave enough yet to do it. I figure if anything happens to my current position I may just finally go for it.

What type of consulting do you do? You're independent I take it?

If anyone is interested I just received a discount code dropping this to $295:

BHUL443

I got an email about BlackHat USA 2010 Uplink where it appears they will be streaming parts of Blackhat live this year.

At $395 it sounds like a decent deal.

Does anyone have any thoughts about it?

OSCP is a tough course and really forces you to come up with some interesting and unorthodox solutions. I remember spending many a late night trying to break into the lab boxes.  It's very frustrating, but is definitely the most rewarding course I've ever taken.

Unfortunately as fun as it may be you can't implement security for the sake of security. There needs to be a valid business need to for any sort of security project. You should look for a problem to solve, and find ways to solve it. Look around and ask around, chances are if you're like a normal company there are an embarassingly large number of problems that need to solved. Once you have the problems identified, then you can come up with the projects in order to solve them.

I totally agree. I have seen the term "cloud computing" mean so many different things. Honestly the "cloud" should really only reference real on-demand offerings like those of SaaS, PaaS, and IaaS.  All too often I'm seeing this term applied to generic virtualization in the datacenter such as VMWare and Xen as well as your run-of-the-mill webhosting that's been around forever. 

While the interface to some of these services may be new, the real security implications are not. What we're seeing happening now is that large organizations are being lured to the 'cloud' by the analysts selling them the idea that they could save tons of money. Some organizations should have absolutely no issue moving their data out of the datacenter, as long as they keep as much control around it as is necessary.
 
On the other hand, a hospital or anyone else handling confidential information still needs to have full control around where that data lives, how it's backed up, and how it is disposed of. Unfortunately the 'cloud' offerings as they stand today can't guarantee those controls.

I think the "cloud" is a great enabler and even though it's really nothing new, the marketing machine behind it actually can bring about some interesting change in the industry.

It seems every day I see an article or question about security and data governance with regards to the "cloud". Given that there are so many questions around it, there is obviously real interest. With interest(and some cash), we'll likely be seeing some real solutions coming out of the marketplace in the near future.

I would bet there was lack of feedback from HR to the recruiter and that's why they told you the company wasn't interested. I'm married to a recruiter and that's a situation that happens a LOT when HR isn't interested in a candidate. Depending on the company and their culture, some HR people despise working with recruiters due to the cost and the fact that there are a lot of bad recruiters out there who practice unethically.

I'd be suspicious if the company contacted you directly after a couple of weeks without having that recruiter involved as it would seem they're trying to get out of paying a fee to that recruiter.

I don't think it will really be missed if it is dropped from the course. The course really only gave an overview of it as a pentesting framework.

I earned my CEH about 2 years ago and I think it's a great cert. It really does teach you to think like an attacker and gives a very good introduction to the process of penetration testing/ethical hacking.

If you do earn the cert, I would recommend following it up with the Pentesting with Backtrack and the OSCP certification. I feel like the CEH was the theoretical and OSCP is the practical.

The more I learn, the more paranoid I become I think. I just finished PWB and learning just how easy client side attacks are really kicked up the paranoia a bit..

I think what's being missed here is that you're not taking input from an external source such as a prompt, a file, or a socket.

The compiler appears to be fixing a logic error for you, which compilers are sometimes good at doing. What a compiler can't do is protect the program from user input that it knows nothing about if the input isn't being handled in a 'secure' manner.

Check out Smashing the Stack for Fun and Profit. It's one of the best written descriptions of buffer overflows. It's a bit linux centric, but the  concepts are all the same:

http://insecure.org/stf/smashstack.html

You may not be able to overflow a buffer in code before it is compiled. There's a good chance that the compiler will try and fix that for you.

Most buffer overflows are triggered by input that comes from an external source such as a prompt on a commandline or commands via a network socket.

When you're taking input from an external source, if proper bounds checking is not in place the buffer which the input is being placed into can overflow and overwrite memory near the location where the buffer was in memory.

In some cases this allows an attacker to overwrite memory in a way that can give them control over the execution path of a program.

I typically default to Perl when I need to do something that I can't do in a simple shell script.

I've been been wanting to get a little more into Python and Ruby, but I'm usually in a situation where time is of the essence, so throwing in a new programming language isn't an option.

I did do a project in Ruby recently and really enjoyed the syntax even though it felt very awkward at first after working with perl for so many years. I can totally understand why ruby on rails has caught on in the web development arena.