It has gotten soooo bad, that almost nobody understands how to even use a command line. I had a student at the University ask me "why do I have to put spaces between the words" when running a command with flags.

Definitely learn Linux and scripting (bash, korn, csh, or whichever you prefer). At the minimum, it will get you a deeper understanding of troubleshooting a system or remote administration. I hate GUIs.

Those things you mentioned will help get you the knowledge, which is probably the better direction to start (than say perhaps getting your CEH first and then learn how to hack later).

However, down the road you will probably want to start looking at any of the DoD 8570 certs as well, to get past the HR filters.

jjwinter's questions are extremely relevant; answering those will give you a better idea of what area to focus on, since there are so many different sub-topics within this field (and a ton of knowledge to go with).

You can get a job in the pentesting field with no pentesting experience, but harder to do without IT or networking - not impossible.
Be aware that the CEH will get you past the HR filters when applying for a job, but means almost nothing to a hiring manager who is more interested in your ability to use a methodology, your knowledge of protocols and how to exploit them, and your fu with the different tools. That said, get your CEH but spend most of your time learning how to pentest, not just how to use the tools.

Can you provide the whole hash string and command you used?

Also, I have a video at the bottom of this page on JtR:

http://hackingdojo.com/pentest-media/

Yes, we have an online lab for students, but check out the "Media Page" on the HackingDojo.com site as well for information and targets to set up the virtual hacking lab, if you're unfamiliar with this concept:

http://hackingdojo.com/dojo-media/

There are some of my conference talks on that page as well, but look for the one titled "Penetration Test LiveCDs – DefCon 15" for a more in-depth discussion of LiveCDs used for pentesting labs. There is a free video on setting up a lab here:

http://hackingdojo.com/downloads/videos/virtual_lab/

Enjoy!

That's actually a really nice document. Well worth a bookmark and some time to read the whole thing, even for non-newbs. Nice find!

It may not matter. The purpose of identifying the customer's routers and switches is to see if you can attack an administrative port (ssh, telnet, and/or snmp). Otherwise, just keep moving on.

BTW, we discuss that in the Nidan class.

I'm a believer in what Thomas Smith wrote regarding advertisement. Just replace the word "ad" with "security recommendation" and you'll see what it takes to make end-users want to participate in securing their organization:

"The first time people look at any given ad, they don't even see it.
The second time, they don't notice it.
The third time, they are aware that it is there.
The fourth time, they have a fleeting sense that they've seen it somewhere before.
The fifth time, they actually read the ad.
The sixth time they thumb their nose at it.
The seventh time, they start to get a little irritated with it.
The eighth time, they start to think, "Here's that confounded ad again."
The ninth time, they start to wonder if they're missing out on something.
The tenth time, they ask their friends and neighbors if they've tried it.
The eleventh time, they wonder how the company is paying for all these ads.
The twelfth time, they start to think that it must be a good product.
The thirteenth time, they start to feel the product has value.
The fourteenth time, they start to remember wanting a product exactly like this for a long time.
The fifteenth time, they start to yearn for it because they can't afford to buy it.
The sixteenth time, they accept the fact that they will buy it sometime in the future.
The seventeenth time, they make a note to buy the product.
The eighteenth time, they curse their poverty for not allowing them to buy this terrific product.
The nineteenth time, they count their money very carefully.
The twentieth time prospects see the ad, they buy what is offering."

Some very quick off-the-top-of-my-head examples:
1) Failure to follow policies during deployment

• User turns off backup application. Control: user is not given permission levels that allow disabling app
• User fails to use complex password when creating database account. Control: password is verified by supervisor after installation (or) database configured to allow only complex passwords

2) Mismanagement of systems

• User fails to patch system. Control: organizational patch management system installed
• User changes banners to look like system is patched. Control: monthly scanning, administrative action
• User uses system for FTP server, even though it is intended for Web application only. Control: Monthly scanning, administrative action

This should NOT be considered appropriate actions for any / all organizations. Each org has a different culture, which may invalidate all these controls.

What I'm about to say will undoubtedly sound pedantic, but please understand you hit a nerve of mine that stems from a continual need by many to be noticed (even if they dont say anything valid). But the examples you provided are perfect examples of noise, simply for the sake of noise. There are a lot of posts similar to what you pointed to that are more like blogs, and less like valid research in the field of InfoSec. As a researcher, you always have to look at the source material and evaluate its validity in a discussion of this matter.

Simply put, none of the articles you linked have any research value. Instead, check out legitimate research, like that done by Susan Handche, professor at George Mason University (as an example). In "The Privacy Papers" (published by Auerbach), she quotes "corporations and government agencies... Will have to dedicate more resources to staffing and training of information system security professionals," and that employees "are not aware of the security consequences caused by certain actions... Thus it is imperative for every organization to provide employees with IT-related security information that points out the threats and ramifications of not actively  participating in the protection of their information."

She also indicated that "informed and trained employees can be a crucial factor in the effective functioning and protection of information systems." She also docents her findings, which doesn't exist in your articles.

There is a ton of real research, performed by real researchers out there, with research statistics to back up their claim. I just get frustrated reading articles like what you pointed out without any real research being done... And then people (not necessarily you) quotes them as something close to gospel.

</rant>

Other than training? The only things left is that organizations have to be punitive, or implement security apps that force compliance with security policies... but that's the big problem - there has to be security policies, and it needs to be supported high within the organization.

However, the MOST effective method of improving security within an organization has been training, so that's where most of the money and efforts have been placed, and rightly so.

Oh, and ISO 17799 has had a number redesignation a while back. It's now called ISO 27002:2005, but I've been in the habit of calling it ISO 17799 for so long that I still call it that in conversations - I think most of us still call it that, unless we are writing documentation (at least within my circle).

Just wanted to clarify.

Probably the first place to start is ISO 17799. That will give you an industry-wide overview of what's expected within an organization with respect to all manners of security. After that, you can start drilling down towards specific policies, standards, and procedures (including verification of compliance).

Keep in mind, what we are discussing is within the domain of an ISSO or CISO.  People (like me), have spent our careers developing our knowledge level to understand threats and risks within an organization so that we can cyclically evaluate and improve the security posture of an organization. There is a lot of information and learning that goes into this, and I think the ISO 17799 is a good place to start.

Hope that helps. I'm sure once you take a look at the ISO, you'll have a ton more questions. Fire away.

You are correct that there are usually root causes to any findings, which typically is due to poor patch management, failure to follow policies/standards/procedures during deployment, mismanagement of systems, or lack of training (to name a few).

In the perfect world, at a high level you would be able to classify all those under "failure to follow policy" since everything else is (or should be) driven by policy. However, once you start drilling down into standards and procedures, things get too diverse to put into a collective "best practice" document for the InfoSec community - for an individual organization, this is absolutely possible, but a comprehensive list is not realistic.

Since I mentioned it on twitter, I figured I would mention it here. I accidentally lowered the Mukyu (novice) class at HackingDojo.com to $75 (normal price is $199). I'm not going to be able to modify that price until Monday, so if anyone signs up I will honor the lower price until I fix it next week.

Also, for clarification, the course is still a video-training class and has lifetime access.

So, there it is. If you want to take advantage of my oversight, knock yourself out.