Welcome to the New-school

I finally decided to contribute something to the global knowledge-base. Whether this something is of interest to you is yet to be determined. You may ask what is the deal with the blog name, so let's start there.

In the underground, hackers were often referred to as either old-school or new-school, with the latter term being somewhat derogatory. I always considered myself on the cusp. The old-school was long in the tooth when I started hacking freebsd, linux and Windows NT 3.1. Shell accounts on Netcom did not compare to X.25. But I had the old-school ethic and interest, and many of my friends are straight-up old-school: the NWA of globally connected networks. WTF you say? I am getting there--just explaining my relationship with the new-school term.

The role of a security engineer is rapidly changing. Five to ten years ago, security engineers handled a lot of firewall configuration; IDS deployment; anti-virus; pentesting and in enlightened environments, code review/programmer training. Now, security engineering is moving towards an aspect of, or integral part of, the software development process. I think the following factors are contributing to this change:

1. For a number of very pragmatic reasons (simplifying operations and responsibility, improved product knowledge, easier to configure products with better defaults, device-ifying of many things), much of the network side of security engineering has moved into network engineering. Any product company building a networking device with security functionality should be expecting it to be managed by network engineers. Network engineers are, in the end, responsible for the network infrastructure, and if packets flow through it, it is part of the network infrastructure. Having split-responsibility for networking devices complicates trouble-shooting and increases MTTR.

2. In-house software development is rapidly increasing as many business leverage the internet for some or all of their revenue stream. I worked at Amazon.com for a total of three years, and it may come as a shock to hear that Amazon largely considers itself a software platform development company. Simply put, Amazon's software platform enables its revenue stream, and Amazon's ability to be agile with regard to features and platform direction is critical to its success. Amazon is an internet company, but not only internet companies are highly dependent on software agility. The financial industry stands on the cutting edge of computing and software development. And software product companies have taken notice; look at Microsoft. What does this have to do with security engineering? If you have been paying any attention to the security space, you have witnessed the rise of the application-level vulnerability. Core OS network-connected services where once the focus of vulnerability research. If one thing was learned about security, it was that only the necessary services should be exposed externally. Indeed, the average company has a radically improved external security posture with regard to exposed services. What is left? Web applications springing up like weeds and the SOA offerings coming online. Of course there is also the core software these applications depend on, going all the way down to the OS (and beyond).

Where should the focus of security expertise be applied? It does not take a genius to figure that it is better to build security in than try to bolt it on, hence the re-focus of security engineering towards the software development process. This brings us to the new new-school.

Some of the old-school are not all that prepared for the new new-school, while others are deeply thankful to finally start working on the real security problem: design and implementation of software, hardware and everything inbetween. Design and implementation baby. Yeah, now we are talking. Well, sort of. I also have another little bias that is a love of dynamic programming languages. To some of the old-school, dynamic programming languages are considered toy-like, suitable for scripting at best, near sacrilegious, dangerous and should be exercised from real programs. Not in this new new-school; we are all over this dynamic programming language sh*t and intend to use it for everything we can get away with.

There you go. This blog is about security as part of software design and implementation with a bent on dynamic programming languages. It actually just might be a place that I jot down little things I notice and learn while hacking Ruby on Rails apps, but I don't know if that is enough for a BLOG, so I will pretend the scope is big and worthy of notice. Time for me to shut up and add some real content.