For the most part, most companies in most sectors are still pretty new at software security. Twenty years from now there is a good chance we’ll look back at the history of software security like we look at cars. Software in the 90s and 00s were like the cars that were build in the 50s and 60s before seatbelts. When seatbelts showed up in the mid 60s, they provided the tools to for your safety but for the most part, nobody used them. It probably took an actual incident for people to realise it was important. Nothing was mandated. We don’t want to tell people want to do. Automobile deaths stayed rather high until the mid to late 70s when governments started to mandate their use. Even today though… people don’t always use them. I’d say we’re somewhere around the 70s in terms of software security. Tools and methologies exist to produce really safe, secure applications. Some people totally get it and are strapped in, but many are more concerned about how fast they can go which, like the car, actually increases the risk. Many require an incident to realise it’s important. Those incidents are becoming more and more common.
I’m fully quality to write some quite terrible code
I’ve been programming in C language since about 1987 which really just means that I’m fully quality to write some quite terrible code. I know how to wield the beast that is C and I find the managed languages for wimps. I’m only kidding about that last bit. Every language is designed to solve some kind of problem and within its success, introduces new ones. Javascript has got to be my favourite at the moment. That feels like we have come full circle, moving back from the comfy chair that was .NET and Java and back into a space that feels like…well a bit like C did way back. The barn door of disaster has been flung open offering plenty of ways to code some seriously unpredictable behaviour! It’s exciting times!
Over the past few years we have seen a slow migration of thought from building quality software to building “secure” software. #AppSec and #DevSecOps are a thing. While those who understand software security would hopefully say secure software == quality softare ,and you would be absolutely right, quality doesn’t make the news. The words “Security”, “Hackers”, “Breach”, along side familiar pictures of nefarious looking hooded individuals with swirls of 0s and 1s around them are regular ingredients to our mainstream news-feeds. This is what many software companies across every possible vertical are reacting to, and what so few have prepared for.
#DevSecOps are a thing
Let’s get back to my mojo for a moment. After years as an SE (Sales Engineer) I’ve found my mojo from a programmatic sense has not faded so much but shifted. While some frameworks and some languages are on the rise while others which were highly favoured a few years ago seem to be fading a little (AngularJS) and yet I still need to investigate and educate myself to know how they work and what they are capable of while never really get my hands fully dirty in a large scale development. I do miss that. However! My role does bring new perspective to these new developments that I would have never experience before! This is thanks to…
Customers! Yes the wonderful customer or I suppose I can even include customer prospects in that. In a given year I’ll probably work directly with 10-20 different companies which may have between 1 and 20 different development teams coding in different ways. On top of that I’ll visit and discuss developments with another 10-20 that I may never see again. The end product of all of that is this. Far more than I ever did as a developer, I get to see what the rest of the world is doing. How their DevOps teams are creating their environments, what cloud technologies are favoured, what languages they use, what frameworks and also what market vertical (Finance, Telco, Auto) they are in and how that compares with others their sector. I’m not afraid to say that I actually geek out on that a bit. It is fascinating stuff. It’s also very interesting to have this perspective and to a degree, advantage when I sit with a new development team and get to listen to their feelings about what they are doing from straight up development methods, to framework or langauge justification, to a creating a Secure SDLC. I can happily report that most dev teams think they are doing really well! To misquote Morgan Freeman in the Shawshank Redemption…
“I wish I could tell you that SOFTWARE COMPANY X fought the good fight, and the HACKERS let him be. I wish I could tell you that – but SECURITY is no fairy-tale world.”
BSIMM Spider Diagram
The developer driven environment has meant wonderful things for the speed and progression of software as well as new methodologies from micro-services to containerized CI/CD but it has also presented a new problem in the midst of our security culture revolution. High speed development can lead to code that is more vulnerable and of lower quality for a variety of reason. Thankfully many languages and frameworks are building some security measures in. VertX is just one example of this (http://vertx.io/blog/writing-secure-vert-x-web-apps/). It does seem that as fast as we can thing of preventative measures we are confronted with new imaginative threats that are simply taking advantage of old problems. A recent example being the Marai botnet. I’m still amazed that SQL Injection is still the top item on the OWASP Top 10. Come on people! Where I’m going with this is that I am seeing organizations large and small working to create an SSG (Software Security Groups) within a SOC (Security Operations Center) and create initiatives to plug the gaps in a tractable way with clean clear processes. There are even assessments in place to see how well you are doing with these like the BSIMM from Cigital (now part of Synopsys (shameless plug)) or OpenSAMM depending on your flavour. I’ll do a blogcast of the key differences between these very soon.
Get back to my mojo yet again. It is relevant to security culture. The trend to developer driven anything started back in the DotCom boom of the nineties. I remember coming to work in a shirt and tie and within a year I could wear flipflops and a tank. Coders (good Coders) were sought after and then meant the ball was in their court. Software is a weird world. I struggle to think of another job where you aren’t necessarily paid a fortune for what you do but you still seem to get a lot of freedom in terms of choice of tools, IDE’s, dress code etc. I would argue that most other jobs don’t have that level of flexability. Coders are still in demand so I don’t see that changing soon. But…that is kind of the problem now isn’t it.
It’s OK! We’re certified!
Concentrating just on the Secure SDLC only, I have already seen a wildly mixed bag in terms of the initiatives from CiSOs, CTOs and the general Security leadership teams. Some of the more experienced and trusted leaders come from the traditional SIEM world of firewalls and network security. There are a lot of CISSPs (link to podcast about Certs). I have had interesting experiences during discovery meetings the software teams are there with the security team and up until that point, they had never met. Scary stuff… but at least they had a security team.
…at least they had a security team
Building a security culture needs to start of course with creating a dedicated team like a SOC that empowers a SSG. Accountability at a high level is essential. They in turn need to properly to train and encourage developers that security is equivalent to quality. Developers need to learn that taking the same amount of pride in software security that they do in their software craftsmanship and ingenuity is the way forward. At the moment, what we are witnessing is still high speed adoption of new relatively unproven, yet tantalizingly powerful, open source technologies and frameworks that provide some incredible OOTB functionality but also create a laundry list of dependencies on 3rd party written code that is simply out of the control of the team. NodeJS… from a functional perspective is amazing. I like that I can knock out a complex web application in a few hours that used to take a team of people a week. That said… I have no idea if 95% of the code I’ve used is secure or even of decent quality. Expanding from the Node example to the general use of FOSS (Free and Open Source Software). Gartner has a stat that indicates something ilke 80% of code in most projects is FOSS. That stat is from 2014 which means it’s definitely too low. Modern development is really just writing really clever glue to stick it all together. Governance efforts to really understand what is happening in this area are breaking new ground. Use of FOSS can not only be opening the door to security issues but also legal issues. That’s a subject for a different post though.
Why can’t we just mandate a security culture?
Why can’t we just mandate a security culture? Well… as I said, coders are still very much in demand. If we can’t mandate closed toe shoes, we’re going to struggle with curbing their technological enthusiasm with imposed security concerns. They need to feel that building security into their work is their idea and is something carries bragging rights when they speak to their community. Saying this I do see massive improvement year on year and many of the modern development cultures I have the pleasure of working with have clear initiatives surrounding security.
At a recent speaking engagement I reminded the developers that currently most companies are actually doing a pretty poor job at building security into their development process. However… I reminded them of a joke I heard when I was young which reminded me of where we are with software security at the moment…
Yes…it’s a wifi Teddy Bear
Two software developers are walking in the woods and they run into a bear! One panics thinking their are doomed! The other switches to his running shoes. The panicked developer says… what are you doing you can’t out-run a bear! The 2nd developer says… I don’t have to outrun the bear, I just need to out-run you.
I think we will get there, one bear at a time.
Yes that’s a wifi enabled Teddy Bear. Be afraid.
