I have been talking about data centric security all week, so you might figure that’s what I will talk about in this week’s summary. Wrong.

That’s because I’m having a Rip Van Winkle moment. I just got a snapshot of where we have been through the last six years, and I now see pretty clearly where we are going. It is because I have not done much coding over the last six years; now that I am playing around again I realize not just that everything has changed, but also why. It’s not just that every single tool I was comfortable with – code management, testing, IDE, bug tracking, etc. – has been chucked into the dustbin, it’s that most assumptions about how to work have been tossed on their ears.

Server uptime used to be the measure of reliability – I now regularly kill servers to ensure reliability. I used to worry that Java was too slow, so I would code C – now I use JRuby to speed things up. I used to slow down code releases so QA could complete test sweeps – now I speed up the dev cycle so testing can happen faster. I used to configure servers and applications after I launched them – now I do it beforehand. Developers should never push to code production; developers should now push code to production as frequently as possible. Patching destabilizes production code; now we patch as fast as possible. We’ll fix it after we ship; now infrastructure and efficiency take precedence over features and functions. Task cards over detailed design specs; design for success gave way to “fail faster” and constant refactoring.

My friends are gone, my dog’s dead, and much of what I knew is no longer correct. Rip Van Winkle. It’s like that.

Step away for a couple years and all your points of reference have changed – but it’s a wonderful thing! Every process control assumption has been trampled on – for good reason: those assumptions proved wrong. Things you relied on are totally irrelevant because they have been replaced by something better. Moore’s Law predicts that compute power effectively doubles every two years while costs remain static. I think development is moving even faster. Ten years ago some firms I worked with released code once a year – now it’s 20 times a day. I know nothing all over again … and that’s great!

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

  • Mike Rothman: Is better possible? Another great one by Godin. “If you accept the results you’ve gotten before, if you hold on to them tightly, then you never have to face the fear of the void, of losing what you’ve got, of trading in your success for your failure.” Yes, we call can get better. You just have to accept the fear that you’ll fail.
  • Gunnar: Apple and IBM Team Up to Push iOS in the Enterprise. My Mobile security talk two years back was “From the iPhone in your pocket to the Mainframe”, now the best in class front ends meet the best in class back ends. Or what I call iBM. IBM and Apple match was a bright strategy by Ginni Rometty and Tim Cook, but it might have been drafted by David Ricardo, who formalized comparative advantage, a trade where both sides gain.
  • Adrian Lane: Server Lifetime as SDLC Metric. And people say cloud is not that different … but isn’t it funny how many strongly held IT beliefs are exactly reversed in cloud services.
  • David Mortman: Oracle’s Data Redaction is Broken.

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

This week’s best comment goes to Jeff, in response to Leverging TI in Incident Response/Management.

Sorry if this goes a little bit off topic, but I believe this relates back to responding faster (and continuous security monitoring that Securosis has championed), but would like to get your thoughts on the best place/recommended infrastructure designs to terminate, decrypt, and inspect SSL traffic to/from a network so all relevant security tools – IPS/IDS, WAFs, proxoes, security gateways, etc., – can inspect the traffic to ensure a complete picture of what’s entering/leaving the network to allow for quick/faster responses to threats.

Thx, Jeff