Beginning AppSec Training Program for Developers

Gone are the days of investing only in developing cool, shiny and user-friendly products without caring much about how secure they are.

We live in a world where being naive about software security is equally dangerous as leaving your house with doors unlocked.

As the numbers from 2017 undoubtedly demonstrate, yes there are people with bad intentions around and the damage they can cause is enormously rising each year.

The number of reported attacks on businesses has doubled in 2017 compared to 2016, totaling 159.700 for the entire year.

That is why security has lately found its way into the software development life cycle and many common concepts have recently been incorporating security in their titles, be it DevSecOps instead of DevOps or SSDLC instead of SDLC.

Although companies had to learn their lesson in a hard way, they have come to realize that, the earlier vulnerabilities are detected and fixed in their software development life cycle, the cheaper and the less time consuming it is to deal with the consequences.

Despite increasing their investment in security teams and trying to create internal security policies, secure software development (life-cycle) is still no joke and it can be painful to achieve.

Security teams are well known to be asymmetrically staffed compared to development teams and their workload is well beyond their capabilities.

With the development teams facing huge pressure to meet the release deadlines or sprint targets, security is not a real priority for them which creates constant tension between two internally stressed out teams.

In the field, we have all seen security analysts complaining about the software developers’ lack of knowledge on writing secure code and asking them the same, easy security questions over and over again.

Unsurprisingly we have also run across software developers complaining about pages of scan results full of security vulnerabilities they are asked to fix. It is a nightmare for companies having two teams that need to work closely with each other with so many mutual complaints.

So, what is a good way to avoid this conflict partly if not wholly?

A good starting point would definitely be an application security training program for software developers.

When security vulnerabilities are detected by whatever scanners the company is using, a common tendency among security teams is accusing the software developers which results in throwing solutions right at their faces without caring to raise any awareness on the vulnerability to prevent the same vulnerability to recur in the future.

Actually, the solution has been worded centuries ago; Give a man fish, you feed him for a day, teach a man to fish, you feed him for a lifetime.

That is exactly where we need to start. We need to raise awareness on the possible exploitations of the vulnerability, show ways to prevent them and expect developers to fix their own code afterward.

Each day new frameworks, new programming languages and/or new environments are popping-up and we keep seeing similar problems almost in every system and if we say security is a continuous process, developers need to understand why and how their code is generating pages of reports on a security scan.

Here are some rules of thumb, which if applied correctly, would prevent many vulnerabilities from showing up on scan results.

• Input Validation: Developers should be strictly advised not to trust user input + Client-side validation is irrelevant + Always use input validation!
• Whitelisting: Instead of trying to filter “bad”, let them accept “good” input.
• HTTP Headers: Why to use, how to use and how to edit.HTTP-Only
  X-Frame-Options
  X-XSS-Protection
  X-Content-Type-Options
  X-Download-Options
  Content-Security-Policy(CSP)
• Password Security: Make sure developers understand that password storage is crucial and they should avoid storing passwords in “plain-text”. Let them use “Security” libraries and language-specific standard functions (bcrypt, scrypt, PBKDF2…)
• Hashing vs. Encryption
• Authentication vs. Authorization: Recall that these two concepts answer two different questions ; Authentication: “Who are you?” and Authorization : “Are you are permitted to do this action?”
• User Authentication Factors: Something you know (pin or password) + Something you have (badge, token, or phone) + Something you are (biometric)
• Do not use default values (or easily guessable values)
• Keep your server and third-party applications and libraries up-to-date

Surely, as an AppSec guy you can say dozens of things for each one of these subjects.

This is just a basic template for starting an “AppSec Training” program and does not intend to go into more details for now.

If developers know ​what not to do,​ they will definitely come up with the fix and will get back to you with more challenging stuff.

It is time to stop complaining and start explaining the basics. Eventually, you’ll spend more time on your security research as you would most probably prefer 😉 Cheers!