"Twitter Segmentation": or why you need at least three accounts

After I'd been using Twitter for a few months (ok, I really don't remember how long it had been) I realized that I needed two accounts for a number of reasons: privacy, personal branding, and audience. Well, when I created @seclectech I'm up to three accounts. Here is why. Besides that I take my time on Twitter way too seriously.

As much as I love shooting the shit with folks as @frednecksec that is just one side of me. And arguably not my best side. I know it. It is the the snarky, sarcastic, cynical side that can't help but mock the endless FUD about SCADA and Smart Grid Security and the never ending drumbeat of Sinophobia and generally react by picking positions I may or may not believe, just for the fun of it, and just to mess with people.

But I don't want to engage in that all the time and it is not healthy either. Sometimes, I don't want to follow people that engage in that sort of nonsense (or cause me to engage in that sort of discourse) I just want to learn about cool technical stuff (whether security or non-security related). Folks like @jonoberheide @jordansissel @jedisct1 @rgaidot consistently provide solid technical information about the topics I'm interested in (and might be interested in) without the snark (i.e. security and technology politics) of other folks I follow on @frednecksec who might be more entertaining.

If twitter had better filtering options (for example that would allow me to block hashtags such as #stuxnet or #wikileaks or #tsa) I might not need to do that, but until that happens I need two different public accounts depending on the tweets I want to produce or consume.

How did your technical skills fare in 2010?

Well, my first full year at SAIC is coming to an end and it is time to take stock of what I've learned, technically, over the past year. I hope to have another blog on management, project, and customer engagement skills, because, truth be told and like it or not, I've grown more in that area than technically in the past year.

Now your day job shouldn't be the only thing determining the level of your technical skills, but it is obviously a major factor. In the last quarter, I picked up leadership/management responsibilities so I will mindful in 2011 to ensure that I at least maintain the skills I've got and not become "soft" and hands-off. This point has been made crystal clear to me as I've been reviewing folks resumes (but have seldom interviewed them) that have let their skills go. A cautionary tale. And some that that I have managed to interview, I've heard the line "I could learn that again if I needed to" one too many times. Folks hold on to the skills they hold precious, even if you have to do it on your own time or change jobs. It is just too easy, especially if you are doing well and making an impact for your organization to let things go.

Coding
The last year has been no different that other periods. Historically, coding occurs in fits and stops. At the beginning of the year I was involved in a research project where I was doing a bunch of Python development with MongoDB, but that ended early on. Near the end of the year more light scripting mostly using dpkt, scapy, and nfqueue-bindings for some protocol testing testing that will hopefully end soon so I can stop the dreaded commute two times a week to Tysons Corner.

Networking & Security Products
I really enjoyed working with ScreenOS on the lower end Juniper SSGs. Most of my firewall experience was Cisco (or PF) so it was a refreshing change of pace. It was a bit frustrating at first, both the ScreenOS CLI and WebUI are preferable to anything from Cisco has ever developed. On the other hand, I did not enjoy working with Garretcom industrial switches, especially their screwed up way of configuring trunk ports and and VLANs. Not to mention their screwed up Flash UI. Working with one of the wireless clients/bridge/APs commonly used by some of the armed services was also a mixed bag, but I learned a little bit about RF surveys and the pros and cons of Mesh vs. Bridge vs. Client/AP wireless architectures. And then there is Air Defense, which I probably haven't learned as well as I could have but there wasn't enough time. In the lab, I kept up my skills up with IOS and ASA based SSLVPNs, but this was actually something I first learned in 2009.

Design/Build/Test/Deploy
A few of my projects have been true engineering (as opposed to assessment) projects that involved specific requirements (either that were provided to us or we had to develop ourselves for the client) where we were responsible for network/system design, configuring all these components and finally bringing them to deployment and handing the components over the customer. The "big enterprise" operational/IT skills I picked up at Hewitt definitely helped here. A couple of projects have required designing and implementing a new wired and wireless network infrastructure (as well as the appropriate C&A activities necessary to connect it) and this has been an interesting challenge, sort of like putting together a puzzle as you figure out to connect all the various L2/L3 infrastructure and security devices together.

Miscellaneous Stuff
Besides fooling around with MongoDB for about a month solid, I learned that some of the RAID controllers on Compaq hardware are lame and that backing up and restoring ESX filestores can be extremely slow and painful if you have SATA drives. Hands-on experience (mostly just getting it working and defining an appropriate security architecture vs. hard core device hacking) with several different smart meters, collectors, and headends, but nothing to write home about and certainly nothing I'd pose for a newspaper for in front of my hacking gear. Last, but not least, I've had the pleasure working with a great new client of taking a deep dive into a popular SCADA system and architecting a real time vulnerability management solution that will be deployed in the new year. Didn't learn any new products here but definitely a new experience of developing a solution from scratch.

It seems like I should have done more than this, but perhaps this is even better than 2010. I learned some new products, APIs, and wrote a bit of new code. I guess it could be worse as a senior engineer for a large government contractor I could be writing technical proposals and pricing non-stop. Fortunately I've been able to dip down and keep my hands dirty now and then, in addition to the normal QA (and tough questions) to keep engineers honest and on track.

So it's been a decent year, but in 2011 I need to do better, and this will be a challenge as there is no doubt that more of my time will be involved managing employees as opposed to just leading projects.Undoubtedly I will need to do work on my own time to keep it real. Stay tuned for some goals I will define for the new year.

Greatest Hits from the Arce/McGraw Article on Cyber FUD

These guys nailed it in Software [In]security: Cyber Warmongering and Influence Peddling and here are my favorite lines:

The (perhaps intentional) conceptual roll up of cyber crime, cyber espionage, and cyber war into the scariest of cyber boogeymen exponentiates the FUD factor, making an already gaping policy vacuum more obvious than ever before

Amen, I still don't even know what "CyberSecurity" really means. Back in 2003-2004 when I first heard about it I thought it was a was for "non-security folks" (putting physical security folks in that bucket) to refer to IT/Computer/Network Security. But I don't know anymore. This conflation is confusing.

The problem with these kinds of stories is that they have somehow worked their way to the halls of policymakers who repeat them without critical analysis. For every careful Dan Geer there are ten shrieking cyber security talking heads busy stirring the pot saying things like, "We may call it espionage, but it's really warfare.

The "World's Greatest Hacker" is the least of our concerns because he isn't influencing policy in the beltway.

What makes us particularly skeptical is the intentional blurring of the lines that helped to distinguish the military, the intelligence community, and the cyber security industry — a direct result of US government pouring of billions of dollars into the burgeoning maw of perpetual cyber security initiatives.

Is it any coincidence that the cyber-euphoria coincided with the US economy going to hell as IT security vendors "cyber-ize themselves." There are quite a few Austin startups (you know who you are) that have become "Cyber Security Vendors" to get that Federal money.

They point out that those beating the cyber war drums the loudest are at least partially responsible for the sorry state of affairs in computer security. Retired Director of National Intelligence (DNI) Admiral Mike McConnell bears the brunt of this criticism, as do one-time NSA Director and Deputy DNI General Mike Hayden, and one-time cyber czar Richard Clarke. We know all of these men and they are all honorable and careful. Like us, they are all capitalists as well.

Anybody that goes after "Digital Pearl Harbor" Clarke is OK in my book.

Public/private partnerships pander politically but they do no real good. As it turns out, security is not a game of ops centers, information sharing, and reacting when the broken stuff is exploited. Instead, it is about building our systems to be secure, resilient, survivable, and trustworthy.

They go after all my favorite buzzwords. The public private partnership is when the vendor and contractors (and sometimes critical infrastructure asset owners) write all the policy to their economic advantage

In conclusion, this is article is a strong defense of defense and building security in. We should let the military and the Intelligence Community do their job and the rest of us (in the Information/Network/Application/Internet Security profession) focus on ours and stop trying to play "soldier hacker." Of course the irony is some of the biggest "CyberWar Cheerleaders" have neither a background in the military, the intelligence community, or Computer Security.