Slashdot Mirror
Ask Slashdot - Breaking Into Penetration Testing At 30
An anonymous reader writes I currently work for a small IT MPS in the Southern USA. Recently, my boss approached me about offering security evaluation and penetration testing to customers in our area due to the increasing number of regulations companies area are having to meet. My role in the company is that of a proactive systems administrator. I have strong troubleshooting skills, a moderate knowledge of Linux, and a strong grasp on Windows systems. My working knowledge of networks is a bit rusty, but I've started working on my CCNA again, and skill/knowledge of any kind of programming language is extremely lacking as I have slacked off in that department. However, I've been working with Powershell scripting, and have picked up some resources on Python. Where would a guy like me start? What can I do, as far as personal development, to give me a shot at building this "new department" within my company? Am I beyond hope?
Go to a gay bathhouse. You'll get plenty of penetration testing experience there.
Have you run Nmap.exe ever? If yes, you are a fully qualified security expert.
Seriously, nmap should let you find an unpatched internet facing system. Then you have a vulnerability to point at. Instant cred.
Enough for you to learn while being paid.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
At 30?
You're young.
Do whatever you want.
Good luck with that.
If you a sysadmin have to ask that question, and as you say lacking in network skill, are you the most appropriate for that role?
I think penetration testing requires pretty good programming skills, particularly low level type stuff.
The fact that you have not maintained any programming skills suggests that it is not something which interests you sufficiently to pursue it in your free time. I am skeptical that a person without an intense curiosity to understand how systems work at a low (i.e., code and assembly level) would find the motivation to develop the necessary programming skills and reverse engineering know-how to discover holes in systems.
But perhaps I am wrong and these skills are not required to be a successful penetration tester.
If you don't know where to start, try something like Kali. Have a play around with Metasploit as well.
Get certified.
>> my boss approached me about offering security evaluation and penetration testing to customers in our area
Because it might at least mitigate the damage after your company get sued by customers who get hacked after you tried to learn on their dime. (Google "Target Trustwave"...)
Seriously, if there's a real business opportunity in your market, your management should either hire an experienced guy/gal and/or partner with an existing firm. Then, you'd have the opportunity to learn along them...while picking up the certs you'll need to be credible when talking to other companies. (And if your management is too cheap to buy your security certs, that's a BIG red flag!)
Download Kali Linux, and figure out all of the tools it contains. By the time you have done that, you should be ready to start trying pen-tests. Do it like you would anything else, set up a test bed (a honeypot of sorts) without any specific weakness (just relatively unpatched/unprotected) and try to break into it. This is basic pentesting. Get a few books from amazon (there are a zillion on the subject, one that stands out is the RTFM (red team field manual) to go deeper. In a year or two you will probably be pretty good at it.
The big risk in saying "sure boss, I can pentest" is that you will start doing jobs where you find nothing wrong (but who knows if there is really nothing wrong) and then the customer comes back a year later and says "why did my whole network get ransomwared???"
Preferably roofied.
...sez Anonymous Cosby.
Momentarily, the need for the construction of new light will no longer exist.
One thing you need to keep in mind is that Penetration Testing isn't just about the technical aspects. You need to be up to speed on all the legal aspects, not just in terms of know what laws govern the particular industry/company you happen to be conducting a test for, but in terms of liability. You really don't want to wind up finding yourself accused of breaking the law, whether state or federal, in the course of your job - and without a degree of caution, that's certainly not an impossible thing.
Remember, most of what gets done in any penetration test worth a damn would otherwise be illegal on any number of levels if you were doing it without the express authorization of the owner of those systems. Make sure you know what you're doing, and that the lawyers sign off on it first so that your company is covering your butt if anything goes bad.
Where would a guy like me start? What can I do, as far as personal development, to give me a shot at building this "new department" within my company? Am I beyond hope?
Learn to program, learn to hack. There are resources available for both. It will take years and it's hard work, but without that, you'll just be another consultant following a script.
If you're not willing to take time and work hard, then yes, you are beyond hope for reaching this goal. Your best option in that case is to continue your current career path and just enjoy what you can of life.
"First they came for the slanderers and i said nothing."
I love learning and starting things.
Security has risk. It isn't just about "did they flip this electronic switch" but "did they steal payroll, take your intellectual property, or brick your server closet".
Ask yourself this: If you say "all clear" and then there is a $100,000 (tiny) loss because of a security miss on your part, what consequences do you expect?
You are beyond hope. Programming has to basically be your hobby for you to be good at it and stay good at it.
http://www.cybrary.it/course/advanced-penetration-testing/
I don't know why you have the "At 30" suffix on your subject line.
Younger people are definitely NOT smarter or better or faster at detecting bugs or defects in systems. In my experience, young people today completely lack the ability to do a focused deep dive on something like the arcana of a communications protocol, or reproduction of a defect that only occurs under very specific scenario.
The main difference between young penetration testers and "old" penetration testers, is that the young ones do it for fame and glory, and receive all the publicity in popular media. The old penetration testers do it quietly and well, and get paid in actual cash money, not Internet lulz points or whatever....
SANs training [sans.org], listen to a lot of the podcasts from security researchers out there (pauldotcom), see if there are any security meetup groups in your area, and most importantly start playing with all the great tools that are out there (someone mentioned Kali download it and start playing with it) oh and become even more comfortable with Linux.
I learned everything I know about penetration testing by watching the only two episodes of Tiger Team ever aired.
not that paper certs make professionals, but for knowledge you might look into the training for Security+ or CISSP certifications. you might also want to look at company security policies to know what to test against. then get ahold of a Nessus system to scan the systems in question. there are other products, both for sale and open source that will allow functional testing of systems. as mentioned above, be careful of the ramifications of testing without customers knowledge. their own security guru might get real excited about that... :D
A good place to start is just playing around with the popular toolkits, reading their manuals and seeing what you learn. Nmap is great (ZenMap is the same but with a nice GUI). Some more good options here: http://ask.slashdot.org/story/13/03/26/1544238/ask-slashdot-do-it-yourself-security-auditing-tools
Also, try and hire a (good) 3rd party vendor to run a security audit on an application you control. That will help you see what your competition offers and you can see how much of that you can do yourself. Might learn a thing or two along the way.
Finally, practice makes perfect. If you buy a copy of Metasplot tools they give you a bunch of real example servers you can hack the hell out of. That lets you practice pen testing without getting yourself in trouble.
Your employer is going to be held liable/accountable if you miss a glaring hole in their information security infrastructure. I'm not saying you can't train to do this but I don't necessarily know that it's the kind of thing you can pick-up on the side or over a few weekends. I've dabbled in security over the years, am very familiar with *nix, worked in infrastructure as a sysadmin, am a fulltime well paid programmer and I am familiar with the variety of tools out there and I wouldn't consider myself for a role like this one. Too much risk.
If I asked you how you would send me a file over a public network and keep it secret, would your first question be; what type of file do you want to send?
I would say look at a cert like Offensive Security Certified Professional (Penetration testing with Backtracks) It's been a while since I did the curriculum I think it was worth it and learned a lot.
if you have to ask, you are not suited for it, if you were a natural you would of solved your question already.
certificates mean nothing other than what you have learnt is out of date.
(anon, because; reasons)
What are you testing? Are you certifying by any standards ?
If so you'll need security qualifications as well, and a proper team. Unless what some people/companies think, a true penetration test is much more then running a vulnerability scanner on a subnet.
If your boss allows you to get a decent education and qualifications, and allows you to set up a team with specialists, of course you can. Just think of your own role in the team. Will you be managing the team, doing audits on windows systems, maybe testing web-apps, social engineering, trying to bypass the IDS, testing your companies own special application for correct configuration? Doing the whole thing on your own is just too complex in almost any situation, and all require a specific set of skills.
A full pen-test is quite a thing to offer to a company, and remember that you'll be the one signing of for their security.
(no penetration test is ever conclusive, but if you leave a glaring SQL injection undetected because of lack of DB skills, imho that is indefensible)
30 is not too old though.
Check out a Security BSides con at http://www.securitybsides.com. These are very affordable one day cons generally.
If you do, take SANS 560. It's a good start, helps provide a framework, and fills in gaps in your knowledge.
If you don't have funding, why bother (for your company - since you'll be making them more money).
However, I'd recommend doing it on your own - learning is always good. But if your company won't fund your education, you shouldn't put in all that work to do it for them. If they will let you learn on company time, then, that's a different discussion (but that means part of your 40 hours will be dedicated to learning and breaking shit). And it will take months to get up to speed, since you won't have a mentor to help point things out to you.
Ethical Hacker and all those other cheap certs are worthless. Books can be useful, but again, sometimes you need someone to point out the pitfalls, etc.
Hi, I work in the general cyber security industry. I would advise against heading this type of project given your current lack of experience. Penetration testing largely involves running scripts and tools that are mostly automated, and then interpreting the results to determine how to proceed (running the scripts and tools again but against a more well defined target) and repeating until you are in. That is one part of it. A second part is analyzing a company's complete security posture, this involves more than the technical systems, it involves the people that run/maintain/protect the technical systems and analyzing how well they do (or dont) do that (how easy they fall victim to social engineering, who has a level of access that is unwarranted, where the weak points are in terms of people/policy/implementation, etc.
I would not go into this with little previous experience. I would definitely hire someone with experience to be a part of this before proceeding.
Now, on to learning. If you want to be competent in cyber security, you should know the following (this is my opinion, don't take this is gospel, compare my suggestions to others):
Networking. Be intimately familiary with layers 1-4 of the stack. Know all aspects of TCP/IP (V4, V6 is still not widespread and will not be too hard to learn if you master V4). All aspects, not the basics, this is a necessity. You will not be able to identify that one odd TCP packet with a weird flags set or the malformed DNS request if you don't know what a normal TCP packet looks like.
As a test, answer this question with an essay: "What happens when I open up a browser and type google.com and hit enter." (assume all caches are flushed on all devices, your own equipment and the network equipment you are traversing). If your answer is not very long, then you most likely are missing some of the interactions that took place)
Tools. You need to know tools for analyzing network traffric, and diving deep into network traffic. Wireshark is one of the most popular programs for inspecting pcaps, get very familiar with this tool. Learn how to do the same sort of searching and poking about you do in wireshark with command line tools. Learn what BPF's are. Most useful security tools are *nix based. You absolutely need to become at least comfortable with operating out of the *nix command line (no gui) and know basic *nix tools. There is no way around this.
Knowledge of python and shell scripting has been very helpful to me. You do not necessarily need to know how to program in python or in the shell script of your choice (though it helps bunches) but you do need at a minimum to be able to read and figure out what code is doing, and to make minor modifications to get programs to do what you need.
Hacking. You need to know how hacking takes place. Not at the script-kiddie level of "run this and the system is hacked" but closer to the hardware level. Know how different hack attacks work, know what features or lack of features of the hardware/OS (things like DEP, ASLR, protectected memory pages/ring 0-3, userspace vs kernelspace) make the hacks even possible (buffer overflow, stack smashing, heap sprays, unsanitized inputs, etc). This requires some understanding of computer architectures.
Become familiar with internet RFCs. Know what the popular options are for intrusion detection. Learn how to read snort signatures since there are many of them (when I say learn to read the snort sig, that means you can take a snort signature,understand what it is trying to detect, and then be able to write a rule or signature based off of that in whatever IDS system you are using, if you have something different/in addition to snort).
Read alot. Do whatever work in the field you can. Learn. Don't stop learning, because the adversaries are not, and your intimate knowledge of computer security Circa 2014 is not going to protect you or your organization from the new hacks happening now. (lots of hacks are recycled and reused long after they have been patched/mitigated (due to poor patch managment/security procedudes), so knowing what was happening in previous years does help alot, but still never stop learning)
Ignore them people saying your lack of programming "freshness" is a barrier. You could be the best/most productive programmer around here and still have no clue where to start digging for useful, relevant exploits you could abuse in any particular system you seem to be an expert in.
With that said, what you want to do is get yourself involved in the latest articles about zero day exploits, trojan horses, patch fixes, heartbleed, so on a so forth. You can get started right here on slashdot: any single search of one of those keywords will point you to news about a known issue, then it probably links to specifics of such issue. Eventually they lead to techniques used, be them SQL/packet injections, memory exploits, privilege escalation. With this you get the basics on the WHY and the HOW things are happening. When you start reaching outside of /. and to the less known technologies fixing flaws constantly, and you get a very good idea of the WHEN of such events - every single day!
Now what you have to do is pick a system you want to test. Familiarize with its architectural patterns, integration with internal and external components, the system it resides in (including hardware/software), but specifically it's use of memory, it's use of the OS APIs, etc. Do this until you get a feel of something fragile. The smell of weakness is usually an exploit waiting to happen. Then you will probably hit a lot of walls.
Also, remember that most exploits come in the form of an actual feature. Change your mindset to something like "if this can be used for good, it can be used for something not that good". That also works your way when you want to have your way with a specific technology.
When it's not a feature that reeks of bad engineering, the only thing left are bugs. But you can't look at bugs in the closed source, black-box environment most technologies you would want to test come packaged in. So find integration bugs: IPC, external interfaces, dependencies can usually be abused with heavy load, injections and whatnot, to induce unexpected behavior.
SANS training is pretty good, if you have the money (or can get work to pay for it). They start at the very basics and go up to advanced pen testing, reversing, etc.
Offensive Security has some good free tutorials and paid training, including lab work, for their OSCP/OSCE series of certifications.
Skip the CEH. I don't know anyone who takes that seriously, even if they have one. It's basically just an expensive way to prove you know netcat.
It's already started, but you could try 'Software Security' from the University of Maryland: https://www.coursera.org/cours.... At least it gives a solid foundation.
Go to some social cons, and ask someone if you can watch them during CTF competitions, and ask them a ton of questions afterward.
Do online training like Offensive security.
Looks for other online past CTFs that are set up as tutorials...
http://resources.infosecinstitute.com/n00bs-ctf-labs-infosec-institute/
or persistent CTF labs:
http://www.root-me.org/en/Capture-The-Flag/CTF-all-the-day/
Practice Practice Practice.
However, you should try to hone your Blue team skills as well as Red. The most important aspect of Pen Testing is customer service... after you break their sh*t, you better damn well know the right way to architect their solution. The worse off the client is, the most likely they'll turn right around and pony up another contract to fix it all for them :)
Start out simple, review the OSI layer, it is not doctrine but it is a start. Configure firewalls like IPTables and PFsense (free unlimited access). Take the time to understand the rules, this will help you learn common ports and how TCP/IP works. Get snort, set it up.
Start reading all the security sites, get on the e-mail list to receive all the new security notices. Maybe Security+ or CISSP rather than CCNA, may look better on paper and they will introduce you to the vocabulary of the trade. Learn about all the commercial and open source pen testing and evaluation tools, acquire some to see how they work. Many places just require a certification of some configs and a "passing" score form a commercial tool to get their C&A approved. If your company does Government (US) work Read the NIST, NSA, and DISA security documentation and STIGs. Formally request them if need be, they are no that hard to get.
Realize that security has grown in the last 10 years, Web sites, code reviews, network perimeter, phones, etc... Is there a niche your company might be able to fill?
Hire someone who lives, breaths, and eats this stuff or do so yourself.
No matter what certifications you get (although you should get certified, for legal reasons as mentioned by others), it's critical that you keep abreast of what's going on in the field, otherwise you're not doing your job. Listen to podcasts on the way to, from, and while you're at work. Read all the websites you can. And learn the tools.
This Week in Enterprise Tech: http://twit.tv/show/this-week-... - frequently mentions useful tools and products for testing or securing a business.
Security Now: http://twit.tv/sn - hosted by one of the best known names in the business, Steve Gibson.
Internet Storm Center: http://isc.sans.edu/ - Website has all kinds of detailed on latest vulnerabilities and security issues - podcast is also available in daily or monthly form.
Kali Linux: http://kali.org/ - can be used as a bootable environment or installed on a partition as a portable pen testing "toy."
Metasploit: http://www.metasploit.com/ - Widely used, frequently updated pen testing kit.
To test something you have to understand it better than the person who built it.
Penetration Testing is a large playing field. You get to test various operating systems, many types of applications in any language your client deemed worthy, and of course whatever technology those whacky webapp guys learnt today. It would take forever to learn all those technologies, and by the time you're done there will be new things to learn.
My suggestion is to start with a basic certificate (CEH/OSCP/GPEN) - not for the certificate itself, but for the wide (and shallow) coverage of the various areas you'll have to study to be an effective Penetration Tester. In fact, you don't even have to take the classes and exams - just look at the syllabus, get the books/videos/whitepapers if you can and use it for self study. Oh yeah, you're going to have to learn many things alone. many many many things. RFCs, specs, whitepapers, videos, lectures - be prepared to cram a lot of information. a lot.
Once you're done learning the basics, pick a topic and specialize. Web applications, cell phones, networks, hardening, secure programming, there are so many to choose from...
My best tip to build a new department is to pick people who 1. you trust, 2. know more than you, 3. Are good at expressing themselves orally and in writing.
Good luck.
You have limitations. Bad. You're aware of them. Good. Better than good, top quartile.
When you put the scare quotes round "new department" is that meant to imply that you're expected to do it all yourself? Hoping that's not the case, then the question comes down to what kind of person to recruit. If you're a Rolls, find a Royce. You'll get some management experience if nothing else.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Seriously, if there's a real business opportunity in your market, your management should either hire an experienced guy/gal and/or partner with an existing firm.
Exatly. If you don't have 70 years experience debugging the Windows and Linux TCP/IP stacks, 90 years experience manipulating buffer overflows and instruction injection into active memory, and at least 120 years experience installing rootkits, you're not qualified. The security industry is one area where no new blood is wanted or needed, and anyone wanting to learn is both a terrorist and an underperforming liability. The last thing the world needs is for you to learn on the job. That privilege is reserved for every other line of work (bar none), but not, I repeat, not and never ever IT security.
But seriously, ignore the parent post. By that guy's logic there will never be any new security experts ever (except maybe within the NSA, which I half-suspect is where he works). Of course there is a learning curve, and you'll do some learning on the job, and need to mitigate some liability, but get certified and bulk up your skills as much as you can ahead of time. It's all about risk management, both yours and your client's (don't forget your risks. Remember, if you get hacked on your watch, it's your neck on the line, so get tooled up as much as you can ahead of time, get good legal advice on contracts, and an umbrella policy if you can get one).
As an 'older' programmer I've personally found that doing lots of open source contribution has helped keep my skills fresh. The trouble with a job is that you tend to get pigeon holed a bit and that tends to make you lose track of what is new and happening in the world outside your company. Contributing to open source will help mix that up and expose you to new ideas.
I would imagine that there's a bunch going on that you could get involved in.
best of luck, LLAP
Peace, or Not?
If you work for a small MSP and are mainly targeting small/medium business then you should just get a tool like SAINT (http://www.saintcorporation.com/) This is what the small MSP that I worked for did. They offer training in their tool and you have a full suite of pen testing and vulnerability testing software. This is the option that your company should do.
However, if you really want to know what you are doing then get Kali and take the training. Like honestly pay for the training and the tools. Learn the software and the technology. This is what you should do.
joe_dragon strikes again.
Jeezus, you're 30 and you're thinking you're too old to learn something new? WTF??? That's the wrong attitude dude!
:P
I'm not going to entirely out my age, but I began my pen-testing career at age 42 - you must think I'm a wrinkled old grandpa; but I'm not....
Tell your boss you'll do it, but only if he sends you to several SANS training events, or at least coughs up for some SANS Ondemand training, then do the trainings, get the CERTS and rock and roll baby! SANS will get you up to speed on what you need to know quickly.
Good luck you young punk you...
Did you ever wake up in the morning, with a Zombie Woof behind your eyes? -- FZ
Start with the education like the other posters have pointed out. Without that you can't even manage an outsourced operation for those pen tests. Offering security evaluations, on the other hand, requires one to get involved with the certification processes. Those customers surely want to get certified with their evaluations.
Probably the most important thing is to have the mindset for penetration testing.
You are no longer trying to keep things up and running, and making systems usable; you are looking for all of the ways to make things break in new and interesting ways. You have to think creatively - you have to think about what the system/network admin missed and/or how "best practices" fail in a given situation/on a specific system.
That's why a deep technical understanding in a lot of areas is very helpful - you learn how things interact, and how failures can occur in different areas. For example, does a software package add a user? Does it open a network port? How does it handle permissions? How is authentication done? How do systems rely on the network? How does the network rely on various systems (like a DNS server)? The more you know about all of the interactions between the system(s) and the network, the more attack vectors you can come up with.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
I came here looking for a joke but got disappointed. :-(
Too many people are focused solely on the "and pen testing" while ignoring the "security evaluation" part. Unless you can help mitigate the problems (which will often be in custom code) you'll embarrass yourself and your company on the first job. Which, since turds roll downhill, means you'll be out of a job, since your boss won't take any of the blame.
Your boss is clueless. Here's what you need to do
1. Agree with whatever he says
2. Use the time to find a new job
3. Result - Saved your Ass (which is a good kind of "profit').
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
I started penetration testing at age 16. She said I sucked at it, but I continued doing it anyway.
Age 30 is late to the party, but you should at least try it once.
If you haven't sucessfully hacked a number of systems up to now, then maybe you're not the right candidate. It's like, who are you going to ask to test your locks, the designers or the burglers.
If you want to do what the high-dollar bank auditors do that I have to deal with (banking IT customers), just BUY a pen test app, run it on network, and hand over a 300 page PDF that includes goofy things like "LaserJet 4000 Printer - Old/No SSL web interface. Upgrade firmware recommended."
Except he's asking how to be a pen tester. What you suggest is not what he is looking for.
But seriously, this is one of the BEST ways to start learning pen testing, all the tools you need in one place.
Install it and start testing on your own home network first to learn the ins/outs and to see how secure YOUR network is. Then, maybe get permission to run it at work with your boss that suggested you get into this.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
I really don't see age as a qualifier for the question. If you want to be a MD at 60 go for it, let alone a Pen tester at 30. The biggest thing is to get certified. Personally I recommend CEH (Certified Ethical Hacking). Why? Because it will beat into your head how many laws you potentially break every time you do something, provides a rigid set of guidelines to follow to stay out of jail, and additionally demonstrates to potential customers that you have a clue.
CISSP is usually better for Auditors, not so much Penn testers but small shops often perform double duty.
If the first paragraph did not make it clear enough, make sure you have an attorney handy to draw up agreements. You really don't want to do this off the cuff without legal framework, the penalties are too severe.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
You will be paid to run a crappy automated scan and hand out passing marks.
The service you will be providing is to provide a plausible means of checking off a box on a corporate checklist. Your financial transaction will be leveraged as an excuse to make security claims bearing no resemblance to the services you were paid to provide.
If your worried about lacking skillz to be effective you're already light years ahead of most of your competition who simply don't give a fuck.
If you think your career is finished at 30 you either don't have the technical savvy to succeed or need to get a little self confidence
I'm a 29 year old non-OS programmer who is learning Linux device drivers. My boss didn't ask me to learn it -- I told him I had to in order to continue doing my job. Get some textbooks, create a test/development environment you can use where you won't break anything, and go buckwild.
I'm an outsider to this, but sometimes another perspective doesn't hurt?
Maybe it would ultimately be more useful, and make you more valuable, if you went way outside the box.
Can a huge collection of tools prove security? Or does it end up being like having a bouncer at the door of a party with an ever growing list of troublemakers knowing new ones keep coming? While there's certainly value in seeing that the known is blocked, if something that actually matters is to be protected, it'll have to be safe against the unknown too.
If there are gaps, the security provided ends up being an illusion which may be worse than nothing if it leads the client to take chances they wouldn't in an untrusted environment.
Do those here that have systems considered secure do things like ensure that there are HARDWARE blocks preventing malicious writes to any piece of flash memory in the system? If that isn't done (and wasn't from a clean state), you may have lost before you started. Can Windows and security even be in the same sentence?
But MS bashing aside, being vulnerable to one bullet can be just as deadly as being vulnerable to 200,000.
Having a system fully patched or updated for a multitude of flaws and showing that DOES NOT PROVE SECURITY.
Quite the opposite, it proves that design, testing, isolation or whatever, the whole creation process FAILED miserably because there were things that had to be fixed. If the design was secure to start with, a local system could have been in a box stored for half a dozen years, and be put into service without fear.
Testing may tend to confirm quality, but TESTING DOES NOT CREATE QUALITY.
If you manufactured some physical products where significant flaws were found, lets say in tires or semiconductors, it may very well be appropriate to reject the entire lot, not just those that fail testing.
Whatever is done to patch a inherently buggy resource, the most important thing to do is be certain that those depending on it know in no uncertain terms that it cannot be trusted.
If the workaround means that some things can never be hooked to a network, so be it. Don't be part of an expensive security fraud. If extreme measures are required make sure that's known. And for things where it's treated like it really doesn't matter, all connected must be educated to know the limitations. The insecurity that we're all exposed to in so many ways is sickening. It seems many expensive efforts amount to a fraud.
You might stand out as providing value if you focus on seriously neglected areas like unprotected flash memory, and let others do the grunt work of scanning. If you code, being really really good with a narrower focus, is far more valuable than covering everything and being mediocre.
I think it might be insightful to compare security and privacy practices with other countries. How should I say this... sometimes people can't smell they own poop.
The Open Web Application Security Project website is a great place to start browsing from, to investigate both pen testing and secure development.
I would also recommend getting some familiarity with the PCI DSS standard. It is aimed at companies involved in online payments (and a bitch if you have to prove compliance.) However when used as a descriptive framework rather than a prescriptive one, it's great foundation for planning a company's IT security aspect.
I'm sure there's a bunch of other security standards for other industries that could be used in much the same way. A good security consultant should at least be able to name check them.
Never trust a man in a blue trench coat, Never drive a car when you're dead
I think that would be a black hat approach.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Everyone appears to be focusing on your picking up all the penetration and ethical hacking skills with valid points. However you ask how you would go about building the department. If you may not be the 'hacker' performing the assessments then this could drastically change the scope of the answer. Yes you still need to learn quite a bit, but you can understand what a buffer overflow exploit is, how it can be used, and the ramifications of it without actually being able to create/use it as a pentester. It all depends if that is what your role will be, or if you will be another cog on the team.
A good security team has different people with different strengths. Your pentesters are definitely the 'hacker' types that need to be able to think in that unique way that allows them to analyze and see behind what the scans are reporting. That does not mean that is the only piece of the puzzle. Books such as this one: http://www.amazon.com/Hacking-Ethical-Hackers-Handbook-Fourth/dp/0071832386/ref=sr_1_1?s=books&ie=UTF8&qid=1426106455&sr=1-1&keywords=grey+hat
discuss the various roles in a security team (I read an earlier edition of the book, overall I would say it is a good overview and provides some good knowledge, but do not expect to become a pentester after reading it - you can find the same information with patience online).
I know all us geeks jump into the techie side of things so we immediately want to be the pentesters, but you may also want to spend some time reading up on what skill sets you need for the team as a whole. Especially as you will be providing services to customers which naturally dictates you will need more than just pentesters (and even within that scope you may have specialists - one person may be a networking whiz, another may be a web app guru, etc.).
What rings true in many of the posts above though is you need to have a desire and curiosity for security. Even if you end up gravitating towards the policy and governance side of security (ick in my opinion :-) ), you need to be curious and read and learn everything you can get your hands on. As soon as you think you know it all, it changes and you start over. Good luck.
JUST DO IT!
Start with the regulations that the companies in the area will need to meet and work back from their. The regulations will state some kind of standard or requirements that they will need to meet. What do those regulations say about penetration testing? Use those requirements to determine what you need to focus on first.
The software industry just isn't a place for changing direction or starting new things. I mean, come on - learning a new skill is disloyal to the older skills. If everyone just learned things willy-nilly, who would sort the punch cards anymore?
Just keep your head down - you probably only have 2 or 3 more good typing years left before you're too old to sit up or retain bowel control.
Go ahead and run NMAP against a company. Even worse, go ahead and attempt to exploit what you find. After you get out of jail we can discuss why you were wrong in your advice and actions. Simply running nmap against someone is enough to result in at least one felony charge.
If you ever bothered to read the preface to the CEH course, CISSP course, or any other certification for hacking you would this exact thing spelled out very clearly. White Hat hacking is mostly paperwork to cover your ass, not just hacking. The latter part is maybe 10% of your job, maybe..
Any IT Security professional will tell you the same thing, unless they are BS'ing like you are :)
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
From TFA Recently, my boss approached me about offering security evaluation and penetration testing to customers in our area due to the increasing number of regulations companies area are having to meet
Does not appear to be internal testing from internal IPs that is the question now does it?
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Don't freaking tell me 30 is too old? Full Retirement age is at 67 and yet people still work past this age. Companies need to stop with the age discrimination and people need to stop worrying if 30 is too old to do anything including career changes. Stan Lee is in his 90's and still freaking working.
With such limited background, I don't think you should commit to this area, until you are at least famiar with network protocols and equipment, writing exploits, detailed and fundemental knowledge of operating systems and their associated tools and toolchains, and excellent knowledge of the wide variety of scripting languages tools and runtimes that constitute the exposure surface, a good grasp of software engineering principles reverse engineering and debugging, including understanding of assembly language and executable fomats, etc. I really don't understand why people ask such questions on a whim. If you had a sensible grasp of the issues, you wouldn't be asking the question, since you would clearly know what you don't know. There are probably not many under 30s with this knowledge, so your age is not an issue. Good developers are actually an aging bunch, in my experience. If you are smart, technically strong,mand ready to go up against the best hackers, go for it. Just don't become some inept mediocrity running someone else's tools, without even understanding the output from them. I have seen such people in my own company's IT dept. Totaly worthless.
You have no idea what you're talking about. And yes, I could say that more nicely, but that doesn't make your statement any less uninformed.
Yes, programming skills CAN be a bonus. A bonus. Not a requirement. Some of the best security people I know have a rather superficial knowledge of programming. Mostly, what you need is a way to automatize tasks. Python is the tool of choice today. And you hardly need any programming skills to use that.
Forget stuff like x86 assembler. Seriously. Forget it. Most of the stuff you'll be doing is analyzing web applications where you either don't get anything that could be analyzed or where you get the source code. Yes, that's the two extremes you're dealing with. The few fat clients you will analyze will be written in Java or C#, and for both there are FAR, FAR better ways for analysis than disassembling.
Networking, yes. Networking is your bread and butter and you should know a LOT about it. But writing networking yourself? Please. What you will be dealing with is the intimate details of the HTTP and SSH (and of course their combination). If you can deal with this, you have 99% of the bases covered. It can't hurt if you know a bit about the general working of TCP (you should know about the handshake, and I'm not talking about the secret handshake to get into the conferences).
SQL databases... while it can be a bonus to know how to set them up, what you really need is to know how to inject exploits into queries. That's a neat trick for a few quick wins where you can show off to prospective clients. But in general that topic is fading quickly. They caught on. They use stored procedures and prepared statements now. Injections, while still fun and profitable, are sinking on the Top 10 quickly.
Unix, forget it. Linux, yes, as a toolbox. You don't need to get intimate knowledge of the kernel's quirks (though it does not hurt), but what you really need to learn inside and out is the IP stack. You want to know how to route ANY kind of traffic through your box and force ANY kind of app to use your box as a proxy, preferably one that can even crack pinned certificates. Yes, that's useful. And for that, you will want Linux, and you will want a few assorted tools that make such things possible.
nmap, metasploit, nessus, nikto, sslyze, ... the list is near endless. Yes, you should know them. Yes, you should know how to use them. But they are tools. They are not the ends, they are the means. You don't really need any of them, but they make your life a LOT easier (and your analysis affordable, after all you will be under quite a bit of time constraint when doing your tests, customers rarely want to pay you a month just to take a look at their crappy webshop).
In conclusion, what you list there reminds me of the old "how to become a hacker" meme that was circulating the net a while ago. I don't want to claim it was a hoax, since I don't know what it was like a quarter of a century ago. But the time has moved on and the trade has evolved. Tools exist today that have not existed back then. Attack vectors exist today that nobody considered back then. And at the same time, attack vectors vanished that were very real back then. It's cute, it's funny, it's exciting to think that there's a "crib sheet" on "how to become a hacker". There isn't. There are a few core skills that are important. Are. Now. Today. Whether they are in 3 months, I have no idea. 10 years ago I would have agreed with the Assembler bit, but time moved on and nearly all commercial software today is written in C#, and you don't disassemble that. There are better tools to use here. And 20 years ago being a crack C coder was crucial because there were no good tools, and if there were, you would not get your hands onto them. You needed to be able to write your own. Not anymore.
So please. I know it's tempting to butt in whenever one thinks they know a little bit about a topic but sometimes ... sometimes it's just better to not claim that you do. Especially if there are people really asking for advice, advice that may well shape their future careers. And bluntly, if someone followed that "list to hackerdom", at the end he'd mostly be 15 months older.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Nah.. just be honest with the boss and tell him you aren't sure how to do it but are willing to learn. Then tell him from what you can tell so far, it will not be quick or cheap.
Write up a combination of the suggestions you get with an estimated time and costs so even if he decides to hire a pentester, he will have an idea of what to look for and salary as well as what to charge. If he decides to train you, you will have an idea if what to expect.
It's useless to learn pen testing... unless you also learn "pen fixing".
It's totally useless to know that there are problems there, but now how to fix them.
It's like going to a doctor, they tell you they have bad news and good news. The bad news is that you have cancer. The good news is that they scored 5 under par during their last round of golf. The second piece of information doesn't help resolve the first one. Unless you treat any disease you find, you haven't helped them, you've only made them feel like crap about something they can't do anything about on their own.
Typically, you want a "defense in depth" strategy, which means firewalls, DMZs, the whole nine yards. But learning how to use script kiddy tools to get in is not going to teach you the skills you are going to need if you want to keep someone else using those same script kiddy tools out.
It takes an almost entirely different mindset, and it does, in fact, take real skills -- almost the same skills you'd need to write those tools yourself, in order to write the code necessary to fix the problem so it can no longer happen. In other words, you not only have to know how the tool is getting in, to keep the tool from getting in. This can require substantial knowledge in systems and network architecture, and, if the way the tool happens to get in is via SQL injection, cross-site scripting, etc., etc., you will likely have to *minimally* know enough about the technology that's being exploited that you can fix it.
This is not the job for a single individual; it's a job for a team of at least several people (if they are incredibly good), or potentially a *lot* of people, if they are individually specialized to the point of being narrowly focussed in being able to go deep in only one or two areas.
The best advice I could give you is advice you are no longer able to take: learn this stuff while you are a minor, and unlikely to be put away for a felony, or learn this stuff prior to the electronic trespass laws going into effect in the mid to late 1980's. Both of these mean you've missed your window on getting a broad base of experience on a lot of disparate systems, of the type you'd be asked to pen test (or subsequently "pen fix").
Unless you are really wealthy - or your company is - and you are able to set up a lot of systems which, when you hack them, there's no risk that you'll end up in jail.
Other than that - there's some training available, but if you want to fix the problems you find, you have to think about systems as a gestalt, and you'll have to learn about networking and at least some types of programming, probably in considerable depth, to make up for your inability to legally acquire breadth, and then hire people to get breadth on your team.
Alternately, realize what I did the first day of kindergarten: I didn't want to go back after the first day "because they would not give me reading, writing, and arithmetic". In other words, this is not knowledge that someone can gift you with, it's knowledge that you'll have to fight to acquire, and it's not going to be easy for you.
SANS regularly hold ethical hacking courses to explain the general thought process. Would recommend one of these as a starting point. For the rest, I don't think you can do much better than a lot of reading. There's heaps of security books to read. Two standouts for me are the hacking exposed series, and there's a book on hacking recipes for python (can't recall the title) which was pretty fabulous.
Hope that helps. Good luck.
First off, start playing. Grab a free VM tool like VirtualBox, load up some raw Linux and Windows VMs in it, launch Kali, and start poking around. Break things, but in a manageable, recoverable, legal way. Never, ever, ever poke at something where you don't have written permission from the owner. If you want something a little less random, Lamp Security had some guided CTF exercises out there a few years ago that took you through the pen test process.
Look into formal training. In my experience, SANS has some decent hands-on classes, and you get a fancy certification to go with it. A better option would be to look into Black Hat Training class, and stay for the briefings and Defcon.
Talk to people in the profession. There are a lot of security folks on Twitter - Jack Daniel, Jeff Moss, Dan Kaminsky, Johnny Long, HD Moore and Deviant Ollam to name a few. Follow them, ask questions, join in conversations. Meet up with them at conferences. Security professionals love to tell war stories, and we love to educate people who are interested and want to learn.
Speaking of certifications, don't make the mistake of making them a goal. For what you're looking at, the so-called "big name" certifications (like CISSP) are pretty meaningless. CEH (Certified Ethical Hacker) would probably be worthwhile to have, since it would relate directly to the work you're doing. But realize that certs are mainly viewed as window dressing - great for the business card and marketing department, but all they prove is that you're good at taking tests. Make sure you're getting the knowledge that goes with the cert, and can demonstrate it in the field. The skills and abilities are far more important than the letters in your signature block.
Just do what everybody else does.
Run Nessus on their stuff, put your name in the report, re-arrange a few things, and charge them $2500 for the "penetration test scan"
For extra bonus points, let it get caught in an infinite loop and submit the contact-us form 543,200 times before noticing it.
Am I beyond hope?
Yes.
But not because you lack technical skills, those can be learnt. You're seriously working for a boss who thinks that he can turn a sysadmin into the head of a pentesting department by telling him to make it happen?
There's a lot that goes into a good pentest, and a reason that there are entire companies staffed with people who do essentially just that. It's not something you learn with a book on a few weekends. If your boss doesn't understand that, the result will be a disaster. And we already have too many people out there selling the printout of a Nessus scan as a penetration test.
What other comments said is spot on. Your boss needs to hire an experienced pentester, period. If he doesn't want to do that, there's no chance you'll be heading a pentesting department anytime soon.
Assorted stuff I do sometimes: Lemuria.org
I was your age. My whole career has been built during my 30s and 40s and I am now in my 50s.
If you think you are too old at 29, well you probably are.
People with your skill set, or rather lack thereof, are as common as dog shit. You're essentially a Windows only admin, which means you lack everything you need for the task at hand.
Have you considered offering PCI Compliance rather than pen testing? While there are guidelines its a lot easier of an industry to break into without prior experience. A good pentesting service can test a really wide variety of things - a company that I used to work for would not only do the standard scans/attacks with ~40 different commercial and free tools, but also social engineering tests, mailing people usb sticks with autorun exploits, and stuff like that. I didn't get the specifics, just kind of the vague outline. While it's def not impossible to get into that, its something you should def do professionally before offering it as a service. Either way, PCI Compliance testing is like a watered down pentest, in which you're not actually supposed to break into anything. It also has a really wide variety of much smaller customers that are required to have it performed for various payment industry related reasons. A PCI scan can be anything from a half-arsed SAINT scan with minor notations, to a fairly comprehensive set of manually verified tests for things like SQL injections and XSS vectors.
"Breaking into penetration testing" LOL
You don't *break* into penetration testing. You jab, probe, insinuate, bore or stab into penetration testing.
If it acquires resources on instantiation like a duck, then its a shared_ptr<Duck>
Python is a good language to start with. There are some Python books for pen test you should look for. It would be best to get a full grasp of the language with the ORiley tome. As you are Windows-centric, you have the best development environment available to you: Visual Studio. Download the free version and then install Python Tools for Linux. There is a Microsoft Virtual Academy (MVA) course to get you started.
If you are passionate about the subject, it shouldn't take more than half a year to come up to speed. You will not be doing original research, just using existing tools. Your scripting background should come handy here. Furthermore, satisfying legal regulations may be more about ensuring patches are installed and best practices are followed. Again, not too far from system administrations. Relax and go for it.
Your company needs to have proper penetration testing done. Hire/contract someone to do it.
This is one of those areas of computing where it is not a good idea to learn as you go and build up the skills and experience in-house, because any mistakes you make are going to leave the company liable and possibly cost them some serious money.
If you want to learn about it on your own time and play with the corporate systems to do it, and they have no problem with you doing that, then by all means go ahead and learn.
But don't take on responsibility for the security of the corporate systems until you know what you're doing.
I do not fail; I succeed at finding out what does not work.
Well, speaking as a professional "information security consultant" (who, on occasion, uses nmap and even more-destructive tools against clients), I guarantee you that mutually acceptable employment terms which permit and even expect the use of such tools is what has been paying my very comfortable standard of living for the past few years. From tiny companies that have a mobile app to supplement their primary business, to "stealth mode" silicon valley startups, to healthcare-related companies that are paranoid about leaking info, to huge financial firms (ugh, avoid those), to colossi of the computer/software/cloud industry, I've worked all kinds of places.
Of course, it helps that I'm employed by a company with an excellent reputation. Very little of my work actually involves automated tools; I will run them (unless the client asks not to, which is uncommon) because there's no reason not to, but that's not what they pay me for. My job is to find the stuff that the tools won't, like XSS in an optional parameter that you'll never see used while spidering a site, or exploitable race conditions in a driver when you send the right pair of IOCTLs in close succession, or... you get the idea. Yes, it takes longer, and yes, it costs more that hiring some script kiddie (or telling your sysadmin to turn into one), but it's worth it in the end.
There's no place I could be, since I've found Serenity...
From the source in question, yes it may land you in jail. It all depends on the target and what they choose to do with you port scanning them.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
It may not necessarily be easy, but if it's something you really want to do, don't let the naysayers dissuade you.
'He who has to break a thing to find out what it is, has left the path of wisdom.' -- Gandalf to Saruman
I just came from watching porn!
CAPTCHA: thrusts (seriously?!?)
Some of the best security people I know have a rather superficial knowledge of programming.
By what definition of BEST are you using?
Because....
Most of the stuff you'll be doing is analyzing web applications
This is accurate and contradicts the previous comment. Having a "superficial" knowledge of coding is a great way to be superficially good at that kind of work, I guess.
If you can't write JavaScript in your sleep, if you don't know the quirky differences between MS-SQL, MySQL and Oracle SQL, and what xp_cmdshell does (for example), you won't be able to properly exploit things you find.
If you can peek at a nmap and know "OK, I'm showing a bunch of Filtered UDP ports. Is that a firewall, IPS, dropped packets or open services?" How can you tell? How does UDP respond to probes?
That's great, networking knowledge helps (and is required), but application code and logic is important these days for security.
just sayin'
If you can sew yourself a hammock, climb through a vent and stay in the false ceiling for 3 days, then use a tempest receiver to monitor the PCI bus, maybe think about it.
1) I don't know how you can be a decent sysadmin without really understanding networks. ..hey can you start this shows a lack of understanding of the business model.
2) If you were asked to build a pen test department worry less about your skill, and more about what it takes to build a team to present a coherent business offering. Your boss asking you
3) I expect a pen tester to be able to whip up code and modify existing hacks to break in. Powershell doesn't count as code
4) I expect paying for a pen test against an application to a) break in to it and b) show me in the code where the problem lies once they have done it. Running nessus or nmap and telling me to patch a system...not even in the realm of close to an offering.
Penetration testing and vulnerability scanning are not the same thing.
It's not difficult to make vulnerability scanning a "value add", and then consult on how to fix the issues found. It's also a way to get your foot in the door to do more work, if you can create a good relationship with the client. Vulnerability scanning is reasonably easy (there are online services that you can resell). It's a good place to start, while you ramp up your skills.
Penetration testing is considerably more technical, and it can cause problems with the relationship to the client. The whole point of a penetration test is to show that the admins have egg on their faces.... And not just admins, since you can also test physical security if the project is scoped right. (Google "how I legally robbed a bank.")
It's entirely possible to provide both services. A blue team for for vulnerability scanning and remediation, and a red team for true penetration testing.
The last thing the world needs is for you to learn on the job. That privilege is reserved for every other line of work (bar none), but not, I repeat, not and never ever IT security.
It is kind of a dick move to walk into a project with a negative deliverable (from the customer's perspective they are desiring proof that there are no security holes) and have no real idea what you are doing. Why do you think fortune tellers have such a bad rap? "oh yes, i can see it now, everything is fantastic! there are no issues anywhere! oh, and avoid Pisces" Sure, you can't be wrong (unless they are literally getting exploited while you audit), but then again you are almost certainly not right either.
Do you ask a deer how to hunt deer? No, you ask a hunter.
Competition Good, Monopoly Bad.
You needn't be a crack driver to be a world class mechanic. You needn't be a master bricklayer to design a house. And you needn't be a coding wizard to be a good pentester.
Of course it helps. But it's not asked for. And, and this is the important part, it's not going to be paid for. That exploit you want to write, you won't. Nobody pays for this. What your customer wants is a report where you report that there is such a thing, preferably with a link to someone who already wrote one. Because that's the key to your work: Someone already did just that.
I think you work under the assumption that you will find new, exciting 0day exploits during your work. You won't. Finding a new exploit or attack vector is usually a very time consuming task. Few of the things that shake the security world are found on the clock. And I doubt many of the people holding the earth shaking talks at Black Hat can claim that they got paid finding what they found. Would be an interesting survey.
But nearly everything you do is regurgitate what you have said and done before, or at the very least what has been said and done before by others. Simply because of the usual reasons: Time and money. You simply don't get customers that say "I want this machine secure and money is no issue, take whatever time you need and test every single nook and cranny". Most try to cut corners wherever they can, so if you can at least run down the OWASP Top 10 you're already quite happy. And there's nothing new or exciting about it. You do what has been done, using tools that have been written, what's left for you to do is to put the wrench at the right bolt.
The reason for this is simple: Security has far too long been a non-issue, and hence these things are actually still an issue. Why do you think XSS, injections, insecure session handling and direct object reference are way, way up on that OWASP list? Because they're trivial to find for the pentester? No, because they are numerous in the wild AND easy to find for exploiters. Because people creating webpages (and programs) still treat security as an afterthought, if at all.
I agree with you that if you're looking for new exploits and arcane collision problems between very special programs with very special configuration under very special circumstances, you need a lot of intimate knowledge of the machine involved and the languages used. But that's simply not the day to day business of a pentester. Sadly. I'd love to do that.
But nobody would want to pay for it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
My guess is you're being set up for a fall. Don't do it.
Who gets fired after a chemical spill? The Material Safety guy not any company officers.
Who gets fired after a fire? The Facilities Maintenance guy not any company officers.
Who gets fired after a computer security breach? The Computer Security guy not any company officers.
Tracy Johnson
Old fashioned text games hosted below:
http://empire.openmpe.com/
BT
It is better to set up a virtual server with a wide variety of images in a wide variety of stages of secure. One decent hardware server can run it and hold 4 or 5 images live during testing.
I have hundreds of images in all states of secure- from a heavily STIGed and locked down DoD Server 2008R2 Gold Image to a base unpatched install of Server 2000 with IIS6 for Windows server testing. Same with OS including Mac and linux builds. Cisco images are also important. It does you no good to know the OS if you can't get past the firewall or navigate the network.
http://www.lulu.com/shop/herman-van-heerden/a-first-course-in-ethical-hacking/ebook/product-21886754.html