Security ceritifications ramblings
sexion8
Member Posts: 242
I've seen quite a few post in regards to the C|EH and "hackers" as a means of employability. This will be another long rambling post, but I hope I can shed some light for newcomers into the industry, even some of my fellow peer dinosaurs regarding this cert and anything generally under the term "hacker|ing|s". For those who know me (of me (without sounding elitist)), I've been in the industry for quite some time. Before there were Cisco certifications, CISSP's, etc. I've never really been the certifying kind, it is only of recent I've had my company push me towards this route. My experience in the industry has been hands on, everything self taugh. I've spent on average 10 hours a day online since circa 1997, dabbled with computers since I was 8 now I'm in my mid thirties.
Security as an industry really wasn't an industry when I got involved in it. The administrators of the machine(s) were the security professionals. You either knew your systems, or you didn't know much at all. As a systems administrator, then engineer, then network administrator, then engineer, over to the security realm, I learned systems and networking as best as I could. Understanding various systems made security easier for me on the technical side of things. During the mid 90's I wrote - what I read now via cache - lame "how to secure your Linux/BSD/Solaris System's" documents during the reign of Phrack, PacketStorm (hey Ken if you ever come across this), Webfringe (hey Spikeman, etal). I immersed myself on the "hacking scene" during the BBS days staying off the radar, on through the days of Genocide2600's PacketStorm (hey DoXaVG, Geno, etc if you guys come across this).
Having worked through the dotcom daze, I was fortunate enough to tinker around with many technologies in many arenas of IT. Heavy emphasis was placed on networking since after all, everything was connected (dot com). I was able to dabble with MySQL administration, builds, etc., server builds, modifications, kernel tuning, network optimization, routers and the routing protocols, etc. Whatever there was to be learned, I tried to learn it for my own sanity in trying to understand the scope of everything around me...
Enter the "hacker" FUD/Marketing... During the late 90's security was making huge strides under intense marketing. IDS's first popped up even though Marcus Ranum had the excellent Network Flight Recorder, DugSong had his Anzen Flight Jacket for NFR. Ron Gula (hey Ron if YOU ever come across this) had his Dragon product line... Everyone was jumping on the security bandwagon. To me, the technology and protocols had always been addressed as a system administrator - if you understood systems, you'd understand how to harden them. If you understood networking, you'd understand how to properly configure ACL's, block out unwanted traffic WITHOUT using firewalls if need be... You made due. Security wasn't as understood as it sort of is now.
With all the hooplah surrounding security "hackers breaking in" more and more companies started hiring "hackers". L0pht became @stake (hey Mudge if you come across this). PacketStorm had its issues and was purchased by Securify - who was then purchased by Kroll O'Gara - whom I turned down a job offer from like an idiot. Everyone wanted in. Throughout this time, certs really didn't make much of a difference, what you knew made the difference...
Everyone wants to be certified
My biggest qualm about individuals certifying was - and still is - reading a book and passing a test is not the same as implementing tasks. In the real world, the common book scenarios one sees rarely see the light of day. Not only this, by the time the book gets published, because IT changes so fast, the information in the books is obsolete. Akin to looking for information on how to fix your car today, only to find out your car is obsolete by the time you actually found the book you needed. There were really limited amounts of security books around. My first "true blue" security book, was Tipton's Information Management for the CISSP exams. Nice blue cover, hefty 90.00 price tag at the time. The book, even though it was filled with good information, was not for me. I needed tech books. In came the Cisco related books along with reading RFC after RFC after anything security related. Whether it was Phrack, Sysadmin Magazine, LISA material, SANS - was still sort of limited. Documents over at NIST, CIAC.LLNL.Gov, I spent hours, days, years going through documentation, playing with technologies while working... Never telling myself I couldn't.
Nowadays, there are hundreds of certs many are ok on the conceptual level, but many people tend to misunderstand the purpose of certifying... Back in the days, one worked in a particular area, mastered that area, then certified themselves. Nowadays its "oh, look new cert, let me buy a book, pass the exam and I will be an expert!" How wrong this concept is. You could read a hundred books on "How to Drive A Car" however, if you don't take the time to actually drive it, what good is it? Experience holds a lot of weight and certifications cannot compete with experience. It's nice to have many titles under one's name/signature but what good would it do you to be say a CCVP and have issues understanding something as simple as protocol troubleshooting? Say, a network going down perhaps because a firewall was introduced.
Prepare yourself by gaining experience with whatever technology you can. I've built labs from scratch using whatever I could just to understand things. Whether it was building myself an ATM network, dual homed redundant firewall setup, completely scripted Intrusion Detection System built from syslog on a shell script. I try to take the time to understand whatever it is I'm doing. I'd hate to place myself in a position where say I'm interviewed, I'm being labeled an SME (subject matter expert) because of my resume, but am unclear on the core of it all. What would be the point of having an uber resume, asking for decent money if you seriously don't have the clue. Who would you be lying to? At the end, it would be yourself.
My advice to some entering the arena is, switch things up a bit. If you can afford to, buy some older equipment on eBay, learn how things work. On all levels, whether its reading an RFC, crimping your own RJ45's, building your own punch block based FXO/FXS VoIP lab... Learn whatever you can. You will thank yourself in the end for it. When you become accustomed to understanding the common concepts, the rest becomes so much easier no matter what the certification is. So my advice...
Start with an A+ no matter how boring you find it. Information from the A+ helps in understanding forensics anyway...
Security+, Network+ ... Some may snicker at these certs, I say its a beginning to broaden you.
CCNA + CCNP + CCSP level studying. Even if you DON'T intend on becoming Cisco certified, there is a lot to be learned in their material. Some of the best information on VPN's, IKE, IPSEC, I've learned from Cisco Press books, by setting up labs and tinkering around with them.
From here, its a matter of defining what you intend on doing. Security is so broad. Penetration Testing, Cryptography, Network Forenscis, Web Application Testing, Program Application testing, Auditing, Security Management. There are so many different areas. RFID, WiFi - which I believe someone in networking should know anyway. What I suggest is, don't limit yourself yet at the same time, don't burn yourself out too fast. Limiting yourself can also mean, don't specifically focus on say one cert... What good would a "Superappliance Certified Guru" be if there are limited companies purchasing that particular vendor's products?
However, if Superappliance were say a firewall, the core of it all is all the same no matter what the firewall is. In an instance like this, you might want to check out the SANS firewall certification. Same goes for different "UberHacker Certifications". What makes them so uber? At the end of the day, the technology, concepts, even tools are all the same. Before focusing on the cert, focus on the technology, why does it do what it does. Why does this tool behave this way towards this technology. Would it make sense to run into an automobile parts store, buy all known automobile related tools to fix your car if you actually have zero idea on what's under the hood?
Anyone can read a book and assume they understand something well enough to call themselves experts, I can assure you I've met hundreds of "experts" throughout my years who've left me scratching my head wondering how they earned their certs, how they managed to get into a position... I've also met some talented individuals who've never certified on anything, but they can mop the floor with the best of them. Its all about what you want to do in the arena, but never **** yourself by shortchanging yourself and not learning as much as you can.
Learning means understanding things from the ground up PERIOD. As a child you didn't just walk, you crawled, stumbled, practiced then began to walk. Same applies towards security... Learn it all from the ground up, no matter what the cert. You'll see in time they all pretty much boil down to the same topics, scenarios, applications, protocols, "bodies of knowledge". You'll find it easier in the long run, more rewarding and those certs will actually mean a lot more than asking for a ****, trying to cram it all, getting the cert, going for an interview, then fumbling on questions you should have been able to answer.
Anyhow, just felt like rambling
Security as an industry really wasn't an industry when I got involved in it. The administrators of the machine(s) were the security professionals. You either knew your systems, or you didn't know much at all. As a systems administrator, then engineer, then network administrator, then engineer, over to the security realm, I learned systems and networking as best as I could. Understanding various systems made security easier for me on the technical side of things. During the mid 90's I wrote - what I read now via cache - lame "how to secure your Linux/BSD/Solaris System's" documents during the reign of Phrack, PacketStorm (hey Ken if you ever come across this), Webfringe (hey Spikeman, etal). I immersed myself on the "hacking scene" during the BBS days staying off the radar, on through the days of Genocide2600's PacketStorm (hey DoXaVG, Geno, etc if you guys come across this).
Having worked through the dotcom daze, I was fortunate enough to tinker around with many technologies in many arenas of IT. Heavy emphasis was placed on networking since after all, everything was connected (dot com). I was able to dabble with MySQL administration, builds, etc., server builds, modifications, kernel tuning, network optimization, routers and the routing protocols, etc. Whatever there was to be learned, I tried to learn it for my own sanity in trying to understand the scope of everything around me...
Enter the "hacker" FUD/Marketing... During the late 90's security was making huge strides under intense marketing. IDS's first popped up even though Marcus Ranum had the excellent Network Flight Recorder, DugSong had his Anzen Flight Jacket for NFR. Ron Gula (hey Ron if YOU ever come across this) had his Dragon product line... Everyone was jumping on the security bandwagon. To me, the technology and protocols had always been addressed as a system administrator - if you understood systems, you'd understand how to harden them. If you understood networking, you'd understand how to properly configure ACL's, block out unwanted traffic WITHOUT using firewalls if need be... You made due. Security wasn't as understood as it sort of is now.
With all the hooplah surrounding security "hackers breaking in" more and more companies started hiring "hackers". L0pht became @stake (hey Mudge if you come across this). PacketStorm had its issues and was purchased by Securify - who was then purchased by Kroll O'Gara - whom I turned down a job offer from like an idiot. Everyone wanted in. Throughout this time, certs really didn't make much of a difference, what you knew made the difference...
Everyone wants to be certified
My biggest qualm about individuals certifying was - and still is - reading a book and passing a test is not the same as implementing tasks. In the real world, the common book scenarios one sees rarely see the light of day. Not only this, by the time the book gets published, because IT changes so fast, the information in the books is obsolete. Akin to looking for information on how to fix your car today, only to find out your car is obsolete by the time you actually found the book you needed. There were really limited amounts of security books around. My first "true blue" security book, was Tipton's Information Management for the CISSP exams. Nice blue cover, hefty 90.00 price tag at the time. The book, even though it was filled with good information, was not for me. I needed tech books. In came the Cisco related books along with reading RFC after RFC after anything security related. Whether it was Phrack, Sysadmin Magazine, LISA material, SANS - was still sort of limited. Documents over at NIST, CIAC.LLNL.Gov, I spent hours, days, years going through documentation, playing with technologies while working... Never telling myself I couldn't.
Nowadays, there are hundreds of certs many are ok on the conceptual level, but many people tend to misunderstand the purpose of certifying... Back in the days, one worked in a particular area, mastered that area, then certified themselves. Nowadays its "oh, look new cert, let me buy a book, pass the exam and I will be an expert!" How wrong this concept is. You could read a hundred books on "How to Drive A Car" however, if you don't take the time to actually drive it, what good is it? Experience holds a lot of weight and certifications cannot compete with experience. It's nice to have many titles under one's name/signature but what good would it do you to be say a CCVP and have issues understanding something as simple as protocol troubleshooting? Say, a network going down perhaps because a firewall was introduced.
Prepare yourself by gaining experience with whatever technology you can. I've built labs from scratch using whatever I could just to understand things. Whether it was building myself an ATM network, dual homed redundant firewall setup, completely scripted Intrusion Detection System built from syslog on a shell script. I try to take the time to understand whatever it is I'm doing. I'd hate to place myself in a position where say I'm interviewed, I'm being labeled an SME (subject matter expert) because of my resume, but am unclear on the core of it all. What would be the point of having an uber resume, asking for decent money if you seriously don't have the clue. Who would you be lying to? At the end, it would be yourself.
My advice to some entering the arena is, switch things up a bit. If you can afford to, buy some older equipment on eBay, learn how things work. On all levels, whether its reading an RFC, crimping your own RJ45's, building your own punch block based FXO/FXS VoIP lab... Learn whatever you can. You will thank yourself in the end for it. When you become accustomed to understanding the common concepts, the rest becomes so much easier no matter what the certification is. So my advice...
Start with an A+ no matter how boring you find it. Information from the A+ helps in understanding forensics anyway...
Security+, Network+ ... Some may snicker at these certs, I say its a beginning to broaden you.
CCNA + CCNP + CCSP level studying. Even if you DON'T intend on becoming Cisco certified, there is a lot to be learned in their material. Some of the best information on VPN's, IKE, IPSEC, I've learned from Cisco Press books, by setting up labs and tinkering around with them.
From here, its a matter of defining what you intend on doing. Security is so broad. Penetration Testing, Cryptography, Network Forenscis, Web Application Testing, Program Application testing, Auditing, Security Management. There are so many different areas. RFID, WiFi - which I believe someone in networking should know anyway. What I suggest is, don't limit yourself yet at the same time, don't burn yourself out too fast. Limiting yourself can also mean, don't specifically focus on say one cert... What good would a "Superappliance Certified Guru" be if there are limited companies purchasing that particular vendor's products?
However, if Superappliance were say a firewall, the core of it all is all the same no matter what the firewall is. In an instance like this, you might want to check out the SANS firewall certification. Same goes for different "UberHacker Certifications". What makes them so uber? At the end of the day, the technology, concepts, even tools are all the same. Before focusing on the cert, focus on the technology, why does it do what it does. Why does this tool behave this way towards this technology. Would it make sense to run into an automobile parts store, buy all known automobile related tools to fix your car if you actually have zero idea on what's under the hood?
Anyone can read a book and assume they understand something well enough to call themselves experts, I can assure you I've met hundreds of "experts" throughout my years who've left me scratching my head wondering how they earned their certs, how they managed to get into a position... I've also met some talented individuals who've never certified on anything, but they can mop the floor with the best of them. Its all about what you want to do in the arena, but never **** yourself by shortchanging yourself and not learning as much as you can.
Learning means understanding things from the ground up PERIOD. As a child you didn't just walk, you crawled, stumbled, practiced then began to walk. Same applies towards security... Learn it all from the ground up, no matter what the cert. You'll see in time they all pretty much boil down to the same topics, scenarios, applications, protocols, "bodies of knowledge". You'll find it easier in the long run, more rewarding and those certs will actually mean a lot more than asking for a ****, trying to cram it all, getting the cert, going for an interview, then fumbling on questions you should have been able to answer.
Anyhow, just felt like rambling
"Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth." - Marcus Aurelius
Comments
-
keatron
Member Posts: 1,213 ■■■■■■□□□□
My advice is to have fun and enjoy what you're doing. Be passionate about it. If you're not passionate, there's only so much energy and effort you'll put into it anyway. I myself was not big on certs just as little as 5 years ago. However, certifications opened up doors and got me into places that gave me the opportunity to apply that passion, and feed that passion. If you have the passion, the itch, the drive, no one will have to tell you to read RFC's, you'll find them and read them all on your own (which is probably what led Sexion8 to read up as much as he did back then).
Let me share why I still recommend certifications for most people I run across. While no single certification actually made me uber anything, what some of them did was made me want to know MORE about a particular topic or technology I only had to touch on for the cert. Who knew 6 years ago that I would be knee deep in the SCADA systems that control our infrastructure (water, gas, electrical). I sit in on one presentation from the Department of Energy about it. I listened for the two days, to the conceptual over views of all things SCADA, however, CONCEPTUALLY, I had a problem with or disagreed with some of the "we're secure because" statements. So I went and studied for the CSSA (Certified SCADA Security Architect) exam and passed it. This only fed the flame of my desire to rip this whole thing apart more. So I met with some vendors, got some second hand SCADA equipment, read TONS of documentation on the properietary and seemingly closed protocols that these systems run on, understood them, then set up the equipment and learned how it worked. In other words, on the wire, in ethereal, or snort, what do the packet streams look like that tell a gas grid to either turn off a valve or turn on a valve look like. Guess what, configured the equipment to mimic a small PDU/Gas system and started playing with it. It wasn't long before I was able to go through an ethereal **** and isolate these VERY simple commands being sent to these legacy devices. And then shortly after that I was able to capture that traffic. Change a few hex numbers in the packet to for example send a open command to a valve that had just had a close command sent to it. And figured out quickly that these systems don't discriminate on who or what they accept these commands from. Then I started looking at the implications of the industry move to wrap all this simply stuff in TCP (MODBus TCP for example), and screamed bloody murder. Not to mention a lot of these systems are now being emulated on Windows boxes, the same Windows box the gas technician uses to surf the web for **** all day!
Now understand this; The SCADA architect certification didn't require any of the depth I went to. But if I'd never did the cert, I might not have never got the itch, the passion, the drive to dig deeper. When we go out to fancy eateries, we like to sample foods and find out what we like. Use certs for the same thing. Sample the "taste" of different areas and see how much you like it. While at the same time, adding bits to your knowledge base you didn't possess before. While it sounds great to force all newcomers to sit and listen to you and I talk and learn how it's "really" done, sometimes certification is the only formal exposure and introduction people can get to these technologies. I can't count the number of certifications I've gotten in order to get introduced to a certain technology only to find out, it wasn't something I wanted to be interested in at all. But if you don't go, then you wont know.
Sexion8 has some valid points though. If you look through all my posts, you'll see that the underlying theme is always know the basics, know the protocols that these tools and technologies utilize. If you learn those, then you're on your way to learning that everything is possible, and nothing is impossible.
Keatron.