Hackers, Crackers, Terrorists, and Other Things You Should Care Less About

@kodefupanda: Who cares who #stuxnet target was? The takeaway is that ICS security is a prob that effects us all. We need solutions not attribution.

@taosecurity: @frednecksec Attribution is necessary if you want to deal with the threat. It's not necessary if you only want to address vulnerabilities.

@frednecksec: @taosecurity Depending on who "you" are. If you are a scada admin and are behind on the vulngame, threats are somebody elses problem.

So, for quite a while now, one of my pet peeves in any security talk/whitepaper (especially a SCADA or control system security one) is when the author has a list of bullets under a headline called threats. You know, the bad guys. Typically they throw in some cheesy clip art. Even worse they will talk about the motivation: fun, profit, curiosity, world domination, etc. I always found this annoying and irrelevant. Really, who cares why someone is attacking (attempting to exploit a vulnerability in) your system and it really does not matter who they are apart from an IP address that you may or may not be able to do traceback that you may or may not be able to report to law enforcement. You focus on what you can control. Your own networks. Your own systems. Assuming you even have the time, talent, and tools to do that.

But admittedly I have a bias here. Most of my career has focused on vulnerabilities. And most of my career, I've been focused in the technical realm. Not policy or procedures. Not politics. Not targeting the bad guys (well at least after I left tactical MI, and I only targeted bad guys in warfighter command staff exercises, never in the real world.) It has been about monitoring your assets, protecting your them, ensuring devices, applications, and other hardware/software components are properly engineered so that when they are deployed operationally, they can stand up, that you've done a reasonable job reducing the attack surface, ensuring the right set of security capabilities have been implemented, that you've thought things through. You pay lip surface to threats (attack trees, threat models, etc.) but you really are only concerned about that magical moment when a threat exploits a vulnerability. That event. The goal is to prevent that or make it as unlikely as possible, or if it does happen you want to minimize the impact.

When you are concerned about technical vulnerabilities, the capabilities or intent of the threat agents don't really matter, unless there is an intersection with the assets you are responsible for monitoring or protecting--or securing prior to deployment if you are in product security or appsec. So I learn the adversary has some new tool (malware, script, or whatever) that I can detect (or not detect) that I should attempt to monitor and recover from. There is some new way of exploiting applications or network access controls or surreptitiously gaining unauthorized access. This is why you pentest, this is why you do design reviews, this is why you do operational drills. It is really not about threats. It is about your stuff. Not their stuff or them.

So if you come from this vulnerability-centric frame of mind (or at least I think I'm accurately capturing this outmoded way of thinking about the brave new world full by Cyberwar, APT, Cyberterrorism, and what my Senator this morning referred to as "Cyber Shields") you become sort of confused when folks like Bejtlich say that this no longer matters, that that this is an outmoded approach not appropriate to the 2nd decade of the 21st century. That is all failed that we must give up and go after the Chinese dragon or the Russian bear. We must stop all we are doing. Defense no longer works.

You know, sort of like a Bush Doctrine for cyberspace. Take the fight to them.

(To me there is a difference between the fact that you have to continuously stamp out vulnerabilities, over and over, Microsoft Tuesday after Microsoft Tuesday, new application or protocol. A never ending struggle that guarantees job security for a lifetime. This might be insanity, but it is not failure, but I digress)

So the big question here is who is we. What has really changed for the system administrators, the security administrators, the firewall administrators, the folks responsible for monitoring the logs, the pentesters, the application security girls, the policy and compliance weenies. They all must suddenly switch to a threat focus?

If by we, you are talking about the intelligence community if you are talking about the military, national security policy? Absolutely. Do what you need to do--or what I assumed you were already doing. Target terrorist networks with "cyber weapons" take out critical infrastructure with your cache of 0-days SCADA (or Telcom) vulnerabilities. Just do it, Cybercommand. Or whoever.

But for the rest of us, that probably aren't doing as good a job as we should monitoring our networks, patching our systems, analyzing our logs, keeping the auditors off our backs, keeping our aging systems even running as we have to do more and more with less, we are supposed to care about who the bad guys are and going after them?

For us, I say Stuxnet and Aurora (the Google one, not the smoking, shaking generator one) change nothing.

Altitude Induced Peace and Grown Up [Security] Jobs

So while en route from PHX to BWI, late Thursday night after a couple of (what appear to be) successful days onsite with a new-ish client, I couldn't help but a feel a bit of satisfaction, or perhaps, more importantly, lack of restlessness that has characterized much of my infosec^H^H^H^H^Hcybersecurity career. Things actually made sense. My career had some sort of meaningful trajectory. I had not just been hopping around every 18 months for the the last decade. There was a method to the madness.

(Perhaps it is no coincidence that the we've finally settled and bought a house north of Baltimore, that I wasn't on pins and needles while out of town when talking to my wife, or that the start of the school year has gone surprisingly smoothly for my two oldest children, or that my oldest's BPD, et. al. is reasonably under control, but I digress)

Around the turn of the century (and perhaps longer), I definitely had a case of the what do I do next? What is the next big thing? How can I scratch that itch?

I got my start as a trainer, which was a monkey I had on my back for a few years, only made worse that I had a B.A. in English and History from an engineering school and that my first job out of college was as an 8th grade reading teacher of all things!

So I relished the chance to leave Trident (only after my stock options from the Veridian acquisition were safely deposited) on to a all too brief stint as a security consultant at SBC (where I mostly wrote proposals and coded tools nobody would ever use) to my 5+ years at Cisco (internal consulting, then R&D, then back again) which was just as frustrating as it was rewarding. Politics. Personalities. My own naiveté. But exposure to Big Corporate life and a hell of a lot of cool technology. Then, fleeing to a small company, which was also as rewarding as it was frustrating. Mostly the working at home thing and not having enough people to work with, which was maddening, because I found out I was more social than I thought, culminating in that fateful move to Chicago for operational IT work and a hell of a lot of Ruby coding. On call. Weekend upgrade. BSD! Then back to training because I was burned out of ops work and wanted an easy way to move back East. And I actually enjoyed teaching. Adults (in the military) and kids (when I was a middle school teacher).

What triggered my thoughts at 28,000 feet (or whatever 737-700s fly at Eastbound) was recalling how natural early in the morning it was to be up at the whiteboard in the meeting I was having: drawing network diagrams, proposing solutions, debating implementations, cracking jokes. How this was just like teaching--or at least how I liked to teach. And I realized that there was no way that I could have felt this comfortable if I hadn't had the last two (no, scratch that, three) jobs.

One of the best things about teaching at Tenable (more so with the Enterprise classes than my Nessus classes) was how I'd get all sorts of weird questions based on peculiar aspects of a student's network (or political) environment. This kept me on my toes. And before then, at Hewitt, getting just enough of a taste of the keeping-shit-running hell of operational work and large, complex, global networks that makes a SCADA system seem simple. And before that all the lessons learned from Dale (who was channeling Tom Peters) about projects and clients and who you really are. So despite the fact that I still haven't stayed in one place for more than 18 months in the last two years

But the "grown-up" part in the title? What is that about?

Perhaps because I was (or still am) only a mediocre bug-hunter (or pentester or whatever, though I loath the term) but that of vulnerability sort of work I did at Cisco (and later at Digital Bond) never seemed to make a difference. And if I'm honest about it, the learning about a new product, application, protocol, or whatever was more interesting than actually finding flaws in it. Besides, you never really knew would be fixed or not--certainly was not in the critical path, was only at the tail end. Maybe things have changed now in appsec as it has gone mainstream? Maybe I got involved in that field too early. I know I got interested in fuzzers way too early. That's for damn sure.

Although I still do some of this sort of work, these days most of what I do now involves building things, not breaking things. And it is in the critical path. Secure network & system design is in the critical path. Hell, even compliance work is in the critical path.

That cool, technical work where you could wear shorts and sandals into the office every day and never had face to face meetings with your clients and never had to record time or worry about how much time you are billing, burn rate, or profitability--that was not in the critical path.

As much as I miss Austin, that is what I'll be thinking of when I head down 95 and pull into the office in the BWI flight path tomorrow morning for the first time in a week.

A year later am I still scared? And some lessons on proposals

A year ago, when I started my current job at SAIC, I referenced a Tom Peters quote about how your projects should scare you. Well, a year later, I'm no longer scared if the new job will work out, if I will hate it, if there will be enough billable work to keep me employed--or at least from spending too much time in IR&D-land. In fact I'm not scared at all, although I'm certainly being challenged. This is a good thing, obviously.

I'm at that point where I'm at thought I would be based on my standard 18 month cycle. It is interesting how this cycle has repeated itself as I've moved from job to job. About now, things are firing on all (or maybe too many) cylinders and I have the confidence that I lacked for a while. That confidence partially comes from having gotten over that "prove yourself" hump. (One of the consequences of switching jobs is that you have to prove to yourself and others at the beginning the way you don't if you stay in the same role years and years. Of course if you have a continuing stream of new projects where you have to prove yourself to new clients, you get some of that but it is not the same level of stress)

Right now, I have too many projects (this week I billed to 6-7 different charge codes, which is way too many as there is a reason you should have only 2-3 projects at a time) and tasks and they key challenge to to delegate and distribute the load so I don't burn out.

And to say no. I will never forget how during my interview at Hewitt the to-be-CISO asked me if I could say no. I don't remember my answer, but I learned why it was necessary and I certainly see that now. And the need to disengage. Tonight, I told my boss (or at least my boss for a few more days now if the rumors are true) that I was taking the night off and my wife and I watched The Edge of Heaven. Highly recommended if a bit slow moving at first. No, I wouldn't be working on that proposal tonight.

Which leads me to the original idea for this blog. So proposals? What have I learned about proposals? Right now, I'm going through one of those frustrating periods at work were I'm doing less technical work and more proposals and pricing than I'd like. These periods are a necessary evil and they are worth the thrill of the award, but they are not fun. I thought I hated technical proposals but pricing is worse. And there are things worse than pricing, but I wont go there.

So it seems like I've done a lot of proposals in the last year. Maybe I have maybe I haven't relative to folks in similar roles in similar sized companies, but there has definitely been variety. A few technical proposals I've written from scratch (more or less) and done all the pricing and am now leading the project but most where I'm part of a larger proposal team. And this is where the idea for this blog came in mind as I was stuck in traffic on 695 this afternoon.

What are some lessons of writing projects proposals (or at least participating in proposal teams) from the last year?

Who is the boss? This seems easy but it doesn't always happen. Even if there are multiple PMs or team leads involved, you need to appoint one who will run the proposal process. Ambiguity as to who is driving the process can be a disaster. It will screw it up.

Err on the side of more conference calls and less emails. I can't believe I'm saying this. Especially if there are folks that haven't worked together before or are from different organizations. You have to build up that trust. Don't hesitate to pick up the phone. Just sending out calls to contribute and review a document isn't going to cut it.

Divide and conquer. Assign tasks to specific questions in the RFP. Yeah, the folks assigned may screw it up and somebody may need to clean it up and rescue that section, but there needs to be clarity on who has to write what.

Tell folks when things are due. When does the client need it? What the internal process hurdles? When are you tasks due. Open ended tasks also won't get done. Especially if folks are using spare cycles they need to know when to perform that context switch.

Get some sleep. Yes, since proposals are typically on top of your normal project it does require nights and weekend.

And on that note.