Exploring SDL: Successes, Learnings and Failures – Part 1
Another security announcement? Yes and no. This is where we let you take a look at – and even take part in – a security process that we started more than a year ago. So what happened then that is worth its own blog post – or even more? Well, hopefully, this will give you a bit more visibility into our approach to security, and perhaps some ideas that you can bring to your own efforts to guard against the always evolving threats.
As in every startup, diversity at LogMeIn always was and is a great driving force. We’ve always cared about security, but back in our early days, this diversity was both a blessing and a curse. The upside is you have a room full of smart people looking at security from different angles. The downside is you have a room full of smart people looking at security from different angles. Inevitably you end up with a situation where you would need a more standardized way.
We were fortunate to have founders that already considered security a top priority. Many software companies, even good ones, start from a less optimal position. As anyone who has worked in software knows, security too often starts as an afterthought. It’s something one of the developers mentions that should be considered during development; and then managers, marketers or sales people use it as a selling point by glomming onto some fancy buzzwords, FUD, and/or numbers. That’s not to say companies don’t care about security. It’s just that, in most entities, security mostly remains an ad hoc activity.
In 2001, the software industry began to wake up to the fact that the ways most of us were doing security were flawed, if not completely wrong. That was the year that the Code Red worm infected around 400 thousand hosts. Two months later the Nimda worm got the most widespread worm in less than an hour. Both these worms targeted Microsoft, causing a significant break in its reputation. In response, Microsoft had to come up with a systematic approach for security, completely rethinking the ways security was done in their software. The result was a new concept, approach and philosophy: the Security Development Lifecycle (SDL), which since has become recognized all over the security industry, and is considered a proper alternative to post development security testing and hardening; instead it really considers security from design on, integrating into development, testing, operation, and maintenance.
Now think about where the industry was a year ago. Heartbleed. Shellshock. Sony. Target. The list goes on and on. Real companies. Real threats. Real damage.
At the time, we were doing a great job updating our products and services to protect against the risk de jour, but we realized that compared to the emerging threat landscape out there, methods to harden our products and ourselves with best practices shared among the developers needed to be much clearer. We reviewed those few alternatives and came across SDL. We read it. We liked it. We convinced the CTO (thankfully it wasn’t hard at all) to introduce it. Then we faced the inevitable reality between good idea and real world adoption.
In an ideal world the SDL process is as easy as it can get. The ideal world ends when the first manager in your company says: “Well, not before summer. We will have a release then.” Your SDL checklist says you have to introduce some new processes – should those wait half a year? Will we reach the Dynamic maturity level in the next decade? And this is the point that none of the reference material mentions.
What we’ll be talking about in this series is our SDL journey. Our successes, our learnings, our failures (and yes, we had a few).
So if you’re considering SDL, actively employing it or just curious about how we look to protect against the always evolving threat landscape, keep a look out for new posts in the comings days and weeks in which be sharing more about how we did this at LogMeIn. And in the meantime, if you’re new to SDL or just looking to brush up on the latest SDL thinking, here are a few go-to resources we found to be tremendously helpful:
- First there is the definitive reference book from Michael Howard and Steve Lipner entitled, The security development lifecycle. Great book with all the details what SDL is, what activities it involves, and what the benefits are.
- You can also find all the revised versions of SDL released since the book is on Microsoft’s web page .
- There is also a YouTube channel dedicated to Trustworthy Computing, holding numerous fancy professionally produced videos about why SDL is good and what utilities there are to help you. For introducing SDL in your company
- The Microsoft SDL Optimization Model (also on Microsoft’s site) that breaks down the various activities of SDL into smaller pieces and phases. This way you can start from the Basic level, and work your way up to the Dynamic level.