Background, I am 28 years old and have a Bachelor in Business/Commerce with majors in finance and economics.
Numbers crunching goes a long way in the auditing arena not to mention the attention you'd have to play to methods applied, etc. However, this is for auditing, say on the CISA level (http://www.isaca.org/Certification/CISA ... fault.aspx
) but that (auditing) can be very boring.
Inside computers, networking/Internet/security excite me the most. And that brings me here.
An issue you will have to ultimately resolve is which route to go. Pentesting on a professional level involves knowing a lot about nothing about a lot. There are different aspects to consider and knowing them will make you invaluable. For example, network is a must. You MUST know how machines and protocols interconnect. If you don't understand the fundamentals of it all, it would be difficult to piece things together at the end of the day. You'll be missing a lot of components.
Operating systems come as a MUST in second place. This means you'd have to take a good amount of time understanding what operating systems do what, how and why. For example, pentesting a Windows machine is highly different than pentesting a Linux/Solaris/BSD machine. When I state you must understand them, I'm stating you must have (repeat MUST have) an administrators level of understanding. This involved creating accounts, creating connections, installing software, understanding the processes involved with any machine you touch. Having this level of expertise makes things easier to understand for the pentester role. For example, let's supposed you're able to pick any tool to compromise a machine. Take your pick there are plenty, Core Impact, Canvas, Metasploit, etc.. So you've gained access to a machine now what? Do you know how to sanitize your actions in eventlog under Windows, what about LIDS, Snare, etc., under *nix? Understanding the operating system from the ground up really well gives you a solid method to begin compromising machines and locking them down without specifically relying on tools.
At 28, with no real background in computer science / networking / etc, what is the best educational route?
choices: Certs, get your degree, diploma from a technical institute, etc.Huh?
Am I living in a pipe-dream of ever becoming an accomplished, respected, and contributing member to the “community” with my age and bg?
You're never too old to make a change and learn whatever it is you want to learn. Anyone thinking on these terms is inviting "learned helplessness" into their lives and subliminally setting themselves up for failure.
So the route I would go I've rambled about before. Rather than re-invent wheels, I will submit a link to give you a good foundation. This is my suggestion. Others might say "learn the tools!" I say learn the core and you won't need the tools. You say toe-may-toe I say toe-Mah-toe. http://www.infiltrated.net/pentesting101.html
Networking. Study CCDA material if possible. This will give you a thorough understanding of the protocols. If you don't understand OSI, you need to stop, go back and re-read.
Operating systems. Create projects for yourself. VMWare is free. Create say a 12 server farm with a mixture of operating systems. The server farm should consist of say a webserver running a CMS, an email server, a DNS server, etc. Learn how to configure and administrate different operating systems. This gives you visibility and exposure on how things are done. Where things are installed, what are the different permissions used, what ports are opened and closed.
Tool time + Programming time. Now that you've learned a bit about networking and operating systems, its now time to learn what tools do what to what protocol and how. During this phase you should be experimenting with specific tools aimed at services you configured in your labs. In parallel, with the administrative role you were learning, you should be looking at the programs and logs to see how these tools affect your systems. This allows you to 1) defend 2) look for ways to be more covert. It also gives you an opportunity to discover substitute tools already available on your operating system and use those as opposed to using noisy pentesting tools. You MUST pick a language and learn others whether you want to or not. Sometimes pentesting involved disassembling code to see what's broken and how you can subvert it. There are many-a-pentesters who don't know much about reverse-engineering often leaving gaping holes after a job. Knowledge of Assembly even at a basic level is a good thing to have. As is Python or Perl (again, pick your poison)
Anyhow, this post while rather long should give you a baseline. A realistic baseline on how to become a solid pentester. Breaking into machines is somewhat easy nowadays, I've yet to find many "pentesters" who could do it without using an array of tools but instead using whatever is on the system itself (curl, telnet, netcat, etc). Remember the majority of tools are using system available tools anyway. When you can literally substitute nmap with say telnet, sleep then you're on to something. When you can sub say Acunetix with LWP + cat + /usr/local/share/dict/list in a shell script, then you truly understand a lot more than you may realize.
For those reading this and wondering why the glutton of not relying on tools... Imagine yourself in a controlled environment without access to tools. What could you do? Would you know how to run tcpdump + a shell script + say LWP to inject into a DB? I've seen a lot of controlled environments where tools weren't an option, yet the results were the same. I learned to avoid relying too much on tools a long time ago.
Anyhow, as for the education level, again: Networking, Operating Systems, Tools, Security Frameworks, Certifications ... Pick your poisong (cert) some are better than others yet all of this is opinion driven. My personal faves to gun for would be OSCP followed by the CPT. If you can get those, you can smoke the C|EH. From there I'd move to the CEPT then any SANS (GPEN) cert if you want "recognition". This is for pentesting only.