I've been patiently waiting for the arrival of a new book I ordered on Amazon; Linux Server Security: Hack and Defend
. Everyday for the last couple of days I hit up my mailbox and look for that notification that there's a package in main office. That little bugger was supposed to be here yesterday. But I digress.
My newfound clarity as of late has me harping on quantifable progress by way of effort and time invested --it is because of this that I have such an issue with penetration testing and enterprise security operations. In a nutshell, I like to not only see progress, but I like to be able to identify irrefutable successes and victories with regard to whatever work is being performed. I'm sure a lot of this perspective is stemming from the recent frustrations I've had at work. I simply can't get behind efforts that are meaningless in the longrun. It's this fundamental principle that has me questioning everything I've worked towards with regard to offensive security and ultimately my role in the security operations department at my job.
So full disclosure; my entire security career was initially based upon my interest in security and not necessarily having legitimate qualifications. But here's the ruse, what exactly are legitimate qualifications? Back in 2006, apparently all you had to have was an interest and maybe a 2 year tech degree (like yours truly). That's what got me in the door and for close to 10 years, I worked as some type of security [analyst | engineer | admin], eventually and recently landing roles as a penetration tester. BUT FUCK.... what does all of that mean? What are security skills anyway? The fact that security is not based on an underlying systematic enterprise where testable explanations and predictions can be made (like a legitimate science), equates to the concept that most efforts put forth in the name of security are just tests, guesses, or trial and error scenarios where real progress cannot be measured. In a nutshell, the work is unforgiving, never-ending, and impossible to measure with regard to success. You can't win.... or can you?
Pentesting and Security Operations share this trait of unquantifiable measurements of success. Sure if you can compromise a system or network during a penetration testing engagement, you can go home (or back to the hotel) happy that you're a badass and you pwned some hapless administrators network. But what are you really doing to improve security.. or your client's security for that matter? You're basically just showing that you spend too much time playing with tools and honing a skillset that is ever-so-fleeting in its relevancy. It's juvenile, and pointless in the grand scheme of things. A penetration test is more or less worthless because a dedicated attacker will always find a way in due to the fact that real attackers don't have a scope or an engagement window. So what exactly are pentesters actually selling? "We'll break in before the skiddies do", which is good enough for most companies, right? After all, they're not really interested in the security of their network. They're just trying to check a regulatory compliance box so they don't get dinged come audit season.
Security Operations primarily deals with vulnerabilities and the remediation of those vulnerabilities. There's often some Risk aspect baked into the reporting, but hell, vulnerability management is basically counting grains of sand at the beach. Risk based reporting is rooted in some variation (emphasis on the word variation) of the Risk formula:
Risk = (Impact * Probability) / Cost
Risk = Threats * Vulnerabilies * Impact
<Insert dickface security practitioner's custom risk formula here>
There's no real science behind "security operations". It's just people spinning their wheels, looking at spreadsheets, generating charts and graphs, putting in remediation plans, arguing about remediation windows or reasons why something can't be fixed, or if something should be fixed, or its real impact on whatever is believed to be the most sensitive aspect of an enterprise or private data network. Yak yak yak bla bla bla.
Real, quantifiable security has to be based on a science, and a domain where limits and metrics can be baselined, tested and compared. But I'm not really concerned with that. I want to get away from that as much as I possibly can. This is why there's a phenomenon called InfoSec burnout. It's the byproduct of indivduals work in this field that can't ever seem to get ahead and make significant progress to generate some level of satisfaction in the work that they do. You see, without this quantifiable measurement of success, one can never really know how good they are. This is my problem with security, and it's always been. When it comes to the work I've done over the last 12 years, I can't say for sure if I'm good at what I do. I can scan, scrape, metasploit, exfil, infiltrate, crack, hack, and sniff with the best of them, but what are those skills really worth unless you're using them for bad, and not good? If given a target and goal (and a down payment) without a scope or engagement window, I can do some damage. But that type of work is hard to come by (right now at least -- corporate espionage anyone). In the enterprise, sure I've held positions that had me watching the network, but I'm a robot, and all it takes is for Jamie in HR to download some ActiveX plugin to ruin my week. You can't win.
But I tell you what... programming and development is not the same. As a programmer, you're on the outside looking in. Your job is to satisfy customer requirements -- whomever that customer may be. And lo and behold, security software development is on the rise. This is the panacea of security work as it sits on the outside and it's rooted in software engineering concepts and principles. Security Software Developers DO security, they aren't responsible for it. If a network gets breach and a data is compromised, it's on the security team, not the developers that wrote the software. This is due to the fact that developers aren't necessarily responsible for the defensibility of their solutions -- until now. The logic behing security software development and engineering is straight forward; "the communications link between these two components is insecure"... implement strong encryption. "This entry field is not adequately validated as unexpected behavior can result from various inputs".... improve data validation exception handling, ensuring only XYZ data will be processed. It doesn't get any more straight forward than that.
Systems analysis for incident response can also be improved by software engineering principles -- in essence designing solutions that can logically analyze a system for indicators of compromise. System and software are predictable -- people aren't. This is the fundament aspect of bullshit security operations and offensive security. It relies on the impossible task of predicting human behavior. --can't be done.
I want to stay away from security work that is based around behavior prediction. System security is fine by me. Software security is also fine by me. Security Software, it's research and development, is fine by me. Anything else, is just uncivilized.
Now's where's my Linux Security Book??