The difference between Window/Apple GUI environments and the GUI environments in Linux/Unix is this:
There is a "standard" API, but it's using the old, limited feature Xlib API.
Today, there exists two very popular alternative Desktop environments, which in turn are based on two different Widget-toolkits. These are Gnome (uses GTK+) and KDE (uses Qt).
Developers wishing to develop on Linux will usually pick one of these two Toolkits, as almost all Distributions offer both environments (and associated development libraries).
So the problem isn't a lack of API details (GTK API's and Qt API documentation), but moreso an issue of choice.
Interepreted languages help, but aren't a cure-all
on
Secure Programming
·
· Score: 2, Insightful
Buffer overflows are arguably the most common vulnerabilities that occur in the wild, which in turn indicates that most of the network services attacked are being written in C.
Moving to interepreted languages mean that any dodgy user-supplied input will be detected at runtime, and will most likely result in some sort of a traceback (but no exploitable overflow).
This however does not eliminate the remaining classes of vulnerabilities, relating to default configurations (username/passwords), poor encryption mechanisms, Denial of Service attacks (minimised due to most popular interpreted languages having their own garbage collection), and more.
We need more developers to be putting on their black-hats, and looking at their code and wondering "what if I tried this? Could I break this code?".
By going with ati, they've also alienated the linux community single handedly becuase ati doesn't have linux drivers.
Hi there. I run Linux here (Gentoo) and the following system:
AMD XP 2500+
nforce2 motherboard
512MB PC 2700 RAM
ATI Radeon 9700
I play the following games on Linux. Enemy Territory and America's Army. With high detail settings on both games, 1024x760(?) resolution, fullscreen, I get 70-80FPS. This is *excellent* FPS, and wouldn't be possible unless there were decent drivers available for ATI cards under Linux.
Here in Australia we have another "unorthodox" politician, Natasha Stott Despoja (pronounced Despoya).
Here's a few things I can remember about Natasha:
1. Someone at the Government pay office thought she was a politician's staffer, when she went to collect her paycheck.
2. She has worn Doc Marten boots into Parliament.
3. She has often been a guest on the popular nationwide alternative radio station Triple J
The problem with the BSD's is that they do not have official binary patches available. I don't want to have to build my entire system again when a bug hits such as realpath:
V. Solution
<snip>
2) To patch your present system:
a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. The following patch has been tested to apply to all FreeBSD 4.x releases and to FreeBSD 5.0-RELEASE.
c) Recompile your operating system as described in <URL:http://www.freebsd.org/doc/handbook/makew orld.html>.
I'm not a Linux fanboy. I run OpenBSD on my home firewall/gateway, FreeBSD under VMware on my home PC, and am developing web applications (for work) on OpenBSD/sparc64. I also have an iBook running OSX and NetBSD.
Binary patches are in my eyes - the one thing holding back many people from deploying BSD in a production environment. Or at minimum me.
For any distribution/os to be acceptable it needs the following:
Support: This means email, phone and on-site if need-be. You can eliminate the last two if you are already employing very good administrators. However management often wants "piece of mind" or in legalese "due diligence" for their shareholders. This means being able to show that they have ensured that if something goes wrong, they have someone to go to.
Fewer product cycles: You do not want to have to upgrade your operating system and/or hardware more than every 3+ years. Anything below that is too costly if you have a large number of servers.
Patches - fast and simple to apply: In this arena, Solaris is pretty good. RedHat and Linux distributions in general seem to suffer from dependency lunacy. That could be just me though. FreeBSD and the BSD's unfortunately are atrocious in this area at the moment. To install a bugfix you have to have your own cvs/build server in most instances - there are no official binary patches available. If you have skilled admins it isn't a problem.
Commercial application support: Out of the free O/S's out there, both RedHat and SuSE seem to be the leaders. Of course, you may not need to run for example - 10 different Oracle servers. So you could have 1-3 (production/development) Oracle servers, and run alternative platforms on the rest of your boxes. This "hybrid" architecture would bring your costs down.
Education/training: Out of the free Unixes, RedHat definitely appears to be the king. Then again, if you have skilled Unix admins who know how to view processes across both SysV and BSD systems, or remove files with a - in front of them, they probably don't need it. Management may however want it for that annoying "due diligence" thing.
So I haven't really given you any answers, but I hope I've offered some good points to consider.
Parent deserves 6 points. Damn good comment, an excellent example of how you can bridge the gap between proprietary and OSS in the software development world.
Nah, I agree with you wholeheartedly. I'm also a big python advocate. I gotta say though, I didn't stop to consider the BaseHTTPServer/etc modules to handle a standalone, easily maintainable web "application".
RE: Point 2 comments
About wxPython docs and how wxWindows has extensive documentation. I saw that when I last checked it. For me it seemed like a potential waste of time to wade through it all in order to get at what I needed. If the tcl/tk option hadn't worked out for me, I probably would've fallen back to this option.
RE: Point 3 comments
The final reason for me choosing tcl/tk over python was knowing that the one constant in the project would be my use of Expect. This being part of the ActiveTcl distribution meant that distribution the interpereter and the scripts would be easier. Also, the pyExpect scripts (when I last checked) seemed to have fallen behind or stopped development.
My personal preference will almost always be Python for server-side scripting. Primarily because its syntax requirements result in easier-to-maintain code, and also because of its wealth of libraries (sockets, BaseHTTP*, re, ftplib, etc), and portability. But I think I'll be using Tcl/Tk (for portable GUI apps) until wxPython comes of age.
With regards to the C/C++ point and the documentation point in the article...
I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.
I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.
So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.
I could either:
a) Put the backend script onto a webserver, and allow administrators to use it via a web browser and CGI.
b) Use Python and wxPython to provide a GUI application that runs on windows/unix/mac.
c) Use Tcl/Tk to provide a GUI application that runs on windows/unix/mac.
I eventually chose the tcl/tk option, because of the following reasons:
1. A webserver-based application would require ongoing maintenance of either a new server, or speaking with existing server ops to get our stuff onto their boxes. This didn't fit in with timeframe and would be difficult to maintain and distribute updates.
2. wxPython lacks extensive documentation. I'm not going to force myself to join mailing lists and peruse demo code to figure out how it all works.
So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.
It is interesting to note that some of these stable, yet "user-unfriendly" operating systems have become the base for commercial appliances/operating systems/etc.
For example:
Debian has been adopted by a few commercial Linux vendors as their base operating system (Stormix is one from memory, I've heard of others but memory fails me).
FreeBSD has been adopted by both Apple (MacOS X) and Nokia (for their IPSO network O/S - used for firewall, IDS, etc appliances).
One of the reasons I've installed Yellow Dog Linux on my iBook (for coding & development) was because it was such a pain having to search across multiple "vendors" of open source ports and packages for Darwin. Depending on which package I installed, I would either have to modify makefiles to use up to three different -L (path's to programming libraries), such as/usr/lib,/sw/lib and/usr/local/lib. It was bloody annoying.
So I welcome this move towards a unified ports system for Darwin, it was definitely needed.
...I have yet to see *any* SMS spam on my phone. However, I have yet to participate in any television/special-offer "sms to win"-type promotions. Which is where I assume marketing companies get their data from.
As such, I think this is a pre-emptive move, and one which I am glad is coming. Because of the nature of SMS, it will be harder for companies to avoid being tracked down (unlike spam). This is a good first step!
Yeh I'm going to be getting broadband shortly too. As quoted in an earlier post, it costs almost double the 3gb plan to get 5gb (instead of decreasing as you would expect with economies of scale).
The only options for me with cable are either Optus or Telstra. And one thing not mentioned by other poster's are that if you want to get cable internet in an apartment, you general *cant* get telstra (their policy it appears is to not support apartment blocks), so you have to go with optus.
So yes, I will also be bending over to get cable from Telstra for exorbitant prices. I cannot wait until we get some competition.
I've had a few recent experiences with OpenOffice.
What happened was I blew up my folks PC when I tried to upgrade some hardware, so replaced their PC with an older one of mine running Win2k and the latest OpenOffice (1.0-something). I tried testing it out by importing my resume and printing it out.
It was immediately apparent that there was a problem with the conversion because all of the bullet-points were wrong, and some other formatting inconsistencies. I couldn't use my folks as a test lab for trying it out, because they needed to import existing documents.
My belief is that for small documents, the import/export routines to and from MS Office to OpenOffice/StarOffice are fine, but most major companies have customised documents with tables and autocompletes and other spiffy things that they use on a daily basis. Those are the things that will most likely break on import, and as such, the migration path to OpenOffice/StarOffice is neither cheap nor simple.
I'll keep trying it out ever new release, but I'm still a little disappointed in how well it can import/export MS Office stuff. If it isn't 100% then it's not good enough for me for anything other than quick writeups.
NOTE: I do understand how hard it is to keep up with changing formats tho, the developers have done a great job so far!
In all of the environments I've worked in (been in security industry 4 years), the people have been pretty aware of open source/Linux and have been positive about it. Most are willing to consider your request that certain source code/libraries/scripts you develop be made publically available.
However, this needs to be clearly defined in your original NDA. If you are considering commencing work that might be useful to the open source community, you might want to get your current NDA re-negotiated so that you can get sign-off from your company to release "authorised" components on a per-case basis.
The main thing that companies will be afraid of is liability and losing face if the product/code/etc is found to be faulty. Most of the boiler-plate open source licenses out there cater to this, by stating that the product is not guaranteed to be fit for any purpose, and that by usage the customer/user takes on all liability themselves:
(Example, BSD license)
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
As a developer you also can make this easier by separating components of your software, making them modular. So that one library that does one thing in a useful way (but nothing especially proprietary) can be distributed, but another library that does some funky stuff on their proprietary application/database remains closed.
Note: It might be worth implementing WASTE using a subset of SSL, to avoid any concern of flaws in this protocol. Feedback is gladly accepted on any potential weaknesses of the negotiation. We have spent a decent amount of time analyzing this, and although we have found a few things that are not ideal (i.e. if you know public keys from a network, you can sniff some traffic and do an offline dictionary attack on the network name/ID), but overall it seems decent. The current implementation probably needs work, too.
Which suggests to me that it isn't worth rushing out and developing application with *just* yet, until further reviews have occured (and the protocol has matured/evolved).
I semi-agree with the above poster. I have only just gotten back into the industry after a 12 month hiatus. I stupidly left my previous job without checking the state of the market.
I think the problem is that the most common certification (and security job) is a checkpoint firewall admin. And the number of checkpoint certified people are growing, as more people try to jump across to security from general systems administration.
As a result, its now a buyers market for recruiters and employers. Certification is the sole differentiator (university degrees aren't considered that important here in Australia in the security market). For this reason alone I'm considering getting a CISSP certification, solely to differentiate my resume from all the others.
Fook, don't hit preview then the back button on your browser.:-(
Ok, time to summarise my longer post.
Background: I've worked in security professionally since late '99. I started with Unix and *cough* hacking back in '96.
1. Subscribe to security mailing lists: Best place to start with this is from www.securityfocus.com. These guys have lots of good lists to get onto - including Bugtraq.
2. Work (at home) with the systems you're likely to work with: This means building a home network, running up some unix servers, windows servers, a managed switch (try to find an old one).
3. Get some good books: For introduction to firewalls - "Building Internet Firewalls", for security design - "Security Engineering: A Guide to Building Dependable Distributed Systems", for crypto - "Applied Cryptography". There's heaps more, but those are some good starters. A good all-rounder is "Secrets and Lies" from Bruce Schneier.
4. Learn to hack: My motto for security work is - "You've got to know where the holes are in order to fix them". This means learning what those holes are, and what are common types of security vulnerabilities and threats are out there. The best way to do this (IMHO) is to start hacking your home systems. Grab Nessus (http://www.nessus.org) to begin with, and work from there.
5. Learn to program: You'll eventually get to a point where you want to develop your own tests, checks and scripts that available programs don't provide. If you are feeling game, try to write your own sniffer with libpcap (http://www.tcpdump.org) or your own scanner with libnet (http://www.packetfactory.net/projects/libnet/)
6. Teach yourself: I don't have much faith in security courses out there, primarily because I have had to work with people in "security" whose only experience/qualifications are a certain firewall certification (glances sidewards at Checkpoint). But if you need it to break into the market, go for it - just don't rely on it entirely. I don't have any real certifications, but I have practical experience with the top firewalls out there (most common security job is firewall admin), heaps of Unix's (solaris, digital, aix - and the various *BSD's and Linux), and can also do some programming. If you're going to work for a good company, they'll be more impressed with your skills than your certifications - though they help differentiate you.
When I worked at a major carrier in Australia as a security admin, we had some on staff known as 'LELU' - which from recollection stands for Law Enforcement Lliason Unit. These were the people whom the different law enforcement groups would approach with warrants and requests for subscriber info. Then LELU in turn would approach the security geeks and say 'we need to know which subscriber was on IP address x.x.x.x at 10.30pm GMT+11'.
Not once do I recall a 'raid' of our subscriber info. The LELU process seemed to be a good mechanism for law agencies to work with the techs at the organisation.
Slashdot Mirror
So the problem isn't a lack of API details (GTK API's and Qt API documentation), but moreso an issue of choice.
Moving to interepreted languages mean that any dodgy user-supplied input will be detected at runtime, and will most likely result in some sort of a traceback (but no exploitable overflow).
This however does not eliminate the remaining classes of vulnerabilities, relating to default configurations (username/passwords), poor encryption mechanisms, Denial of Service attacks (minimised due to most popular interpreted languages having their own garbage collection), and more.
We need more developers to be putting on their black-hats, and looking at their code and wondering "what if I tried this? Could I break this code?".
Hi there. I run Linux here (Gentoo) and the following system:
I play the following games on Linux. Enemy Territory and America's Army. With high detail settings on both games, 1024x760(?) resolution, fullscreen, I get 70-80FPS. This is *excellent* FPS, and wouldn't be possible unless there were decent drivers available for ATI cards under Linux.
Your post is incorrect.
Because KDE users can sit back with that knowing grin on their face, secure in the fact that their desktop is superior... ;-)
Just make sure you dont *forget to* mask *your* email addresses.
Troll. Seen it before.
Here's a few things I can remember about Natasha:
1. Someone at the Government pay office thought she was a politician's staffer, when she went to collect her paycheck.
2. She has worn Doc Marten boots into Parliament.
3. She has often been a guest on the popular nationwide alternative radio station Triple J
Prices for support from BSDI: here.
I'm not a Linux fanboy. I run OpenBSD on my home firewall/gateway, FreeBSD under VMware on my home PC, and am developing web applications (for work) on OpenBSD/sparc64. I also have an iBook running OSX and NetBSD.
Binary patches are in my eyes - the one thing holding back many people from deploying BSD in a production environment. Or at minimum me.
So I haven't really given you any answers, but I hope I've offered some good points to consider.
Try America's Army Online for a good FPS game. The bonus is that its free for download/use (apart from it being payed for by US taxpayers).
Parent deserves 6 points. Damn good comment, an excellent example of how you can bridge the gap between proprietary and OSS in the software development world.
Nah, I agree with you wholeheartedly. I'm also a big python advocate. I gotta say though, I didn't stop to consider the BaseHTTPServer/etc modules to handle a standalone, easily maintainable web "application".
RE: Point 2 comments
About wxPython docs and how wxWindows has extensive documentation. I saw that when I last checked it. For me it seemed like a potential waste of time to wade through it all in order to get at what I needed. If the tcl/tk option hadn't worked out for me, I probably would've fallen back to this option.
RE: Point 3 comments
The final reason for me choosing tcl/tk over python was knowing that the one constant in the project would be my use of Expect. This being part of the ActiveTcl distribution meant that distribution the interpereter and the scripts would be easier. Also, the pyExpect scripts (when I last checked) seemed to have fallen behind or stopped development.
My personal preference will almost always be Python for server-side scripting. Primarily because its syntax requirements result in easier-to-maintain code, and also because of its wealth of libraries (sockets, BaseHTTP*, re, ftplib, etc), and portability. But I think I'll be using Tcl/Tk (for portable GUI apps) until wxPython comes of age.
I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.
I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.
So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.
I could either:
I eventually chose the tcl/tk option, because of the following reasons:
So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.
It is interesting to note that some of these stable, yet "user-unfriendly" operating systems have become the base for commercial appliances/operating systems/etc.
For example:
Debian has been adopted by a few commercial Linux vendors as their base operating system (Stormix is one from memory, I've heard of others but memory fails me).
FreeBSD has been adopted by both Apple (MacOS X) and Nokia (for their IPSO network O/S - used for firewall, IDS, etc appliances).
Go here for more info. Droooooooooooooool. ;-)
So I welcome this move towards a unified ports system for Darwin, it was definitely needed.
...I have yet to see *any* SMS spam on my phone. However, I have yet to participate in any television/special-offer "sms to win"-type promotions. Which is where I assume marketing companies get their data from.
As such, I think this is a pre-emptive move, and one which I am glad is coming. Because of the nature of SMS, it will be harder for companies to avoid being tracked down (unlike spam). This is a good first step!
Yeh I'm going to be getting broadband shortly too. As quoted in an earlier post, it costs almost double the 3gb plan to get 5gb (instead of decreasing as you would expect with economies of scale).
The only options for me with cable are either Optus or Telstra. And one thing not mentioned by other poster's are that if you want to get cable internet in an apartment, you general *cant* get telstra (their policy it appears is to not support apartment blocks), so you have to go with optus.
So yes, I will also be bending over to get cable from Telstra for exorbitant prices. I cannot wait until we get some competition.
I've had a few recent experiences with OpenOffice.
What happened was I blew up my folks PC when I tried to upgrade some hardware, so replaced their PC with an older one of mine running Win2k and the latest OpenOffice (1.0-something). I tried testing it out by importing my resume and printing it out.
It was immediately apparent that there was a problem with the conversion because all of the bullet-points were wrong, and some other formatting inconsistencies. I couldn't use my folks as a test lab for trying it out, because they needed to import existing documents.
My belief is that for small documents, the import/export routines to and from MS Office to OpenOffice/StarOffice are fine, but most major companies have customised documents with tables and autocompletes and other spiffy things that they use on a daily basis. Those are the things that will most likely break on import, and as such, the migration path to OpenOffice/StarOffice is neither cheap nor simple.
I'll keep trying it out ever new release, but I'm still a little disappointed in how well it can import/export MS Office stuff. If it isn't 100% then it's not good enough for me for anything other than quick writeups.
NOTE: I do understand how hard it is to keep up with changing formats tho, the developers have done a great job so far!
However, this needs to be clearly defined in your original NDA. If you are considering commencing work that might be useful to the open source community, you might want to get your current NDA re-negotiated so that you can get sign-off from your company to release "authorised" components on a per-case basis.
The main thing that companies will be afraid of is liability and losing face if the product/code/etc is found to be faulty. Most of the boiler-plate open source licenses out there cater to this, by stating that the product is not guaranteed to be fit for any purpose, and that by usage the customer/user takes on all liability themselves:
(Example, BSD license)
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
As a developer you also can make this easier by separating components of your software, making them modular. So that one library that does one thing in a useful way (but nothing especially proprietary) can be distributed, but another library that does some funky stuff on their proprietary application/database remains closed.
NOTE: I am not a lawyer! ;-)
Going through the documentation, I found this:
From here
Note: It might be worth implementing WASTE using a subset of SSL, to avoid any concern of flaws in this protocol. Feedback is gladly accepted on any potential weaknesses of the negotiation. We have spent a decent amount of time analyzing this, and although we have found a few things that are not ideal (i.e. if you know public keys from a network, you can sniff some traffic and do an offline dictionary attack on the network name/ID), but overall it seems decent. The current implementation probably needs work, too.
Which suggests to me that it isn't worth rushing out and developing application with *just* yet, until further reviews have occured (and the protocol has matured/evolved).
I think the problem is that the most common certification (and security job) is a checkpoint firewall admin. And the number of checkpoint certified people are growing, as more people try to jump across to security from general systems administration.
As a result, its now a buyers market for recruiters and employers. Certification is the sole differentiator (university degrees aren't considered that important here in Australia in the security market). For this reason alone I'm considering getting a CISSP certification, solely to differentiate my resume from all the others.
The market has improved, but only slightly.
Fook, don't hit preview then the back button on your browser. :-(
Ok, time to summarise my longer post.
Background: I've worked in security professionally since late '99. I started with Unix and *cough* hacking back in '96.
1. Subscribe to security mailing lists: Best place to start with this is from www.securityfocus.com. These guys have lots of good lists to get onto - including Bugtraq.
2. Work (at home) with the systems you're likely to work with: This means building a home network, running up some unix servers, windows servers, a managed switch (try to find an old one).
3. Get some good books: For introduction to firewalls - "Building Internet Firewalls", for security design - "Security Engineering: A Guide to Building Dependable Distributed Systems", for crypto - "Applied Cryptography". There's heaps more, but those are some good starters. A good all-rounder is "Secrets and Lies" from Bruce Schneier.
4. Learn to hack: My motto for security work is - "You've got to know where the holes are in order to fix them". This means learning what those holes are, and what are common types of security vulnerabilities and threats are out there. The best way to do this (IMHO) is to start hacking your home systems. Grab Nessus (http://www.nessus.org) to begin with, and work from there.
5. Learn to program: You'll eventually get to a point where you want to develop your own tests, checks and scripts that available programs don't provide. If you are feeling game, try to write your own sniffer with libpcap (http://www.tcpdump.org) or your own scanner with libnet (http://www.packetfactory.net/projects/libnet/)
6. Teach yourself: I don't have much faith in security courses out there, primarily because I have had to work with people in "security" whose only experience/qualifications are a certain firewall certification (glances sidewards at Checkpoint). But if you need it to break into the market, go for it - just don't rely on it entirely. I don't have any real certifications, but I have practical experience with the top firewalls out there (most common security job is firewall admin), heaps of Unix's (solaris, digital, aix - and the various *BSD's and Linux), and can also do some programming. If you're going to work for a good company, they'll be more impressed with your skills than your certifications - though they help differentiate you.
Hope this helps.
When I worked at a major carrier in Australia as a security admin, we had some on staff known as 'LELU' - which from recollection stands for Law Enforcement Lliason Unit. These were the people whom the different law enforcement groups would approach with warrants and requests for subscriber info. Then LELU in turn would approach the security geeks and say 'we need to know which subscriber was on IP address x.x.x.x at 10.30pm GMT+11'.
Not once do I recall a 'raid' of our subscriber info. The LELU process seemed to be a good mechanism for law agencies to work with the techs at the organisation.