I am an IT Security practitioner by trade. I do not think that this is an accident either. While I did not start my IT career with the intent to become a “security guy”, I was intrigued like many by the overtones associated with security and hacking, cracking, scripting, <insert reference>, like so many others. It took me almost 5 years to truly understand the complexities associated with the multiple factions within the IT security / Cyber assurance demographic and grasp the drivers that originally drew someone into the field. From analyst to architect, every practitioner has a unique story to tell, this one is mine.
Early on, I never anticipated being long in the tech industry. When I finally had my eyes opened to the world of remote system compromise, I could not help but respect the expertise I assumed it would require to accomplish such tasks. Knowing something such as protocols, and truly understanding them to a point that you could engineer against their weaknesses was so attractive to me that I set off to find the most ambitious undertaking I could find and to begin with mastering an instrument that would be the tool to guide me through this process. With some subtle suggestions from colleagues and combing through what used to be searchable as “Google Groups” (usenet), FreeBSD had just the right amount of pedigree and RTFM attitude to hold my attention. FreeBSD in many ways was (and still is) the biggest contributor to my professional development over the past 20 years. Version 3.4 was out before I was in any way proficient on the system, but between 3.4 and 4.1, I became so fanatical about it I launched bsdvault.net which ultimately became one of the premier FreeBSD help sites with over 25k registered users and a google ranking of 8 at its pinnacle (not easy to achieve). All the while, we never once accepted advertisements or used the site to profit in any way other then intellectually. I had finally built the foundation and expertise to begin tearing things apart, analyzing the results, and reassembling them in the interest of identifying flaws.
Over the next 5 years, I spent my days doing security R&D for UUNet which was a breeding ground for expert engineers ranging from Applications, protocols, networks, systems, and general hacking of just about everything. And oh my the contests… Ranging from contests to create the best paper airplane, to creating packet engines that could rewrite TCP session headers, the cultural atmosphere turned a common workplace into something much much more. In a sea of experts, the drive to stand out meant you had to have more then commitment to learning, but a true aptitude for the technology. This was the lesson that got lost in the arrival of the “certified engineer”… We did not care about certifications in that environment and while I understand the concept of qualified individuals, I saw CCIE’s get eaten for breakfast, lunch, and dinner on the regular as they tried to use text book examples to solve real world problems. Most subject matter experts that I know are not certified to this day. Some may ask;
“if they are so good, then why don’t they just go get the certification?”
And most would not even stop to answer that question. Why? Because they are oversubscribed with work and opportunities. The phenomenon of being a go-to person for the most complicated of issues tends to be a self-fulfilling cycle as long at the resource can say “No” when necessary to ensure the successful completion of their current engagement. Simply put, they do not need it, and they do not have the time to go get it. In some cases, the expert may simply not be a good test taker, and while that argument may be a tougher one to accept, you cannot deny the possibility of it simply by way of the fact that there are certainly people who are GOOD test takers. And so it goes with the world of certifications.
Along the timeline of computer based networks and specifically the Internet, the evolution of security has such an interesting story to tell it could likely entertain even the most unsophisticated (Computer literate) audience. From the beginning, issues relative to computer and network security have been treated as a symptom. Like many symptoms, the solutions have always been geared at treatment and not cure. This is in contrast to issues qualified as flaws which are dealt with by fixing the flaw. If this is the case, and going all the way back to the beginning, secure computing was the goal and not “open” computing, where would we be today? Right where we are? Better off; or worse even? Here is an interesting exercise as a final note to part one… consider the word security as it relates to IT and see what word you find most associated with the word security or even more specific, issues related to security. In most instances, my experience suggests the word block follows not to far behind…