Software Security is a People Problem

February 12, 2014

Software Security is a People Problem 

My first professional job was as a software developer. I had recently graduated with honors with a computer science degree and a software engineering specialization. In other words, I (supposedly) had all of the know-how and tools to enter the world of software development.

At my first job, we weren’t just back-office developers, but rather Technical Consultants — responsible for deploying and customizing our company’s software for our clients. I distinctly recall one day when our client asked me to move the location of a web form from one part of the screen to another. I searched our knowledge base inside and out but couldn’t find any way to do that, through code or configuration. I even asked my more senior peers, but they didn’t think it was possible either. It turns out our software wasn’t as customizable as we thought it was after all. But that didn’t stop me. Like a good consultant — determined to make our client happy — I got creative. It turns out that there were many field labels on that page that were customizable. I used this customization to insert JavaScript into the field text in such a way that when the page loaded, so did the script — moving the web form to the desired part of the screen. Thinking back on it, this was my first Cross-Site Script (XSS).

I also recall reviewing coding guidelines as part of my onboarding process. One of the pieces of advice was to always use parameterized SQL statement, but I never understood why. So I went on with dynamic SQL. My code was even reviewed by senior consultants on our team, but I never heard a complaint.

My first hack was accidental. As many development teams do, we “ate our own dog food”, or in other words, internally we used the same software that we were selling. Therefore, I was aware of certain development features in the software — such as a configuration mode. One day while entering my own timesheet for the week, without thinking too much about it, I appended “&config=true” to the URL. I don’t know what else I was expecting, but our time and attendance software switched to an administrative mode where I could add, edit, and delete fields! I had just inadvertently executed a vertical privilege escalation attack. Our coding guidelines advised to not “rely on client-side parameters”, and for the first time, I understood why.

That day I realized that my company had made a false assumption — the assumption that I as a developer understood software security, and I admittedly did not.

A month or two later when I got a message from my friend Rohit to join a new startup promoting software security, it all clicked. I had experienced firsthand the problem that we were going to solve. Software security isn’t about pen-testing, but rather it’s about people. It’s about creating self-sufficient development teams who understand the problem of software security and providing them with the right tools, processes, and training to foster a culture of security awareness.

If you have a development team who cares about and knows software security, hang on to them tightly. As our VP of Sales Chris Faciana always says: we are in the business of zero vulnerabilities and zero remediation, and a developer who knows security is also in a zero % unemployment market.

 

Previous Article
Making the Business Case for a Software Security Requirements Program
Making the Business Case for a Software Security Requirements Program

Most of our customers need to justify the costs of implementing a software security requirements program wh...

Next Article
Five ways to secure your Internal network on a low budget
Five ways to secure your Internal network on a low budget

When it comes to network security, we can safely assume that most of the companies make a conscious effort ...

×

Schedule a live demo

First Name
Last Name
Company Name
!
Thank you!
Error - something went wrong!