Don't Roll Your Own Crypto

Security professionals are fond of telling developers "Don't roll your own crypto" and for good reason.  Implementing crypto is tough!  If you don't believe me then I dare you to look at the OpenSSL code.  Go ahead, I'll wait.  Are you scared yet?  This isn't going to be one of those "Security is hard" posts, I swear.  But implementing security is hard!  It's not just crypto.  Implementing session management can sneak up and bite developers.  There are a lot of intricacies that developers just don't think about.  Developers don't have the mindset of an attacker.  They are busy implementing business requirements so their company can make money off an application.  Developers might have the best of intentions when they are trying to code securely but some times it just isn't enough.  Looking for a script tag passed in from a web application isn't sufficient to defend against sophisticated XSS attacks.

The OWASP Top Ten is a must read for anyone with even a passive interest in security.  Injection vulnerabilities such as SQL injection are the biggest menace according to OWASP.  Application security professionals such as myself bemoan the fact that SQL injection is still a major issue in 2015.  We try to pound it into developers heads to use query parameterization to protect against SQL inject.  That's all a developer has to do to protect their code from SQL injection.  Simple, right?  Not really.  Developers don't have time, or maybe the interest, to keep up with secure coding techniques.  Security professionals, on the other hand, are expected to stay up to date on secure coding techniques.  It is incumbent on us to take our knowledge and work side by side with the developers.  In a perfect world application security professionals would pair program with the developers but this isn't a perfect world and we have a lot of other things to keep us busy.

"Give them some training and they'll know how to code securely."  Excuse me while I try to stop laughing.  Yes, training will help developers to code securely.  Unfortunately most developers don't get more than a couple hours of annual training.  They can't possibly learn how to defend against the OWASP Top Ten in that little bit of time, not to mention there are so many more vulnerabilities lingering outside the top ten that are just as dangerous.  Furthermore, as new developers come into the organization they will have to be trained so there's a constant need for training.

Ok, I'm beginning to sound negative about application security.  I'll try to be more positive.  Let the developers do what they do best and do what they were hired to do.  And that's to build killer apps.  Separate the business logic from the security components.  Instead of instructing the developers to write their own session management code suggest they use one of the many proven and actively maintained session management frameworks available.  Just as developers have their own niche so do application security pros.  Authentication and authorization functions are extremely complex and that's why there are a number of products available that easily integrate with a home-grown application.  Application security pros in organizations should have the capability to get their hands dirty and write a little code to satisfy some security requirements.  Organizations need to take advantage of this unique knowledge.  Organizations don't necessarily need to buy security products if they have the right personnel to build it.  But the security requirements need to be weighed against the skillset in the company.  If the skillset in the company doesn't exist then it's better to acquire a COTS product.

The security industry is overflowing with security products.  There's SAST, DAST, IAST, WAF and the latest trend is RASP.  They all have a role in the secure SDLC.  RASP stands for Real Time Application Security Protection and can protect against various attacks such as XSS, CSRF, SQLi, etc.  RASP is the most interesting because it becomes a part of your application if integrated properly.  There seems to be a lot of opinions on RASP.  Some argue if developers were coding securely that RASP wouldn't be needed.  That is true.  Unfortunately there are lots of variables that contribute to the lack of secure coding.  Some view RASP as a band-aid and to help secure legacy apps that are still in production but management isn't willig to allocate the proper resources to maintain it.  I argue if an app is in production then an organization has a duty to allocate the proper resources to maintain it but that's another topic for another time.  I don't necessarily view RASP as a band-aid.  I view RASP as any other 3rd party library or framework that developers use to help build their apps.  RASP allows the developers to focus on what they know and leave the details of security to other people who have the time to spend studying sophisticated attack vectors and adapting these technologies to protect against the attack vectors.

Implementing security is hard and it's not for the faint of heart.  Security is an art.  It takes a special, and some would say slightly deranged, mind to be good at security.  The security community is big and still growing.  There are a number of professionals who have dedicated their lives to making applications as secure as they can possibly be.  Create an environment where security professionals can work side by side with developers to implement proper security.  If this means bringing in 3rd party libraries or frameworks to achieve this goal then so be it.  Hackers are looking for any advantage they can get.  A security function that isn't implemented properly could create just the hole the hackers are hunting.