PCI – Going Beyond the Standard: Part 13, Secure Coding / SDLC

Once again, my ability to help out with this stuff is limited, but even my knowledge of what constitutes a good coding practice exceeds that of most organisations with whom I’ve worked.

The best phrase I’ve heard about the need for security relevant skills in coding is; “Applications are the gateways to your data.” So no matter how much network security you have, no matter how many controls you have in place, if your applications are insecure the bad guys get what they are after.

Functionality, and sometimes just appearances, often wins over the needs to build in security from the ground up. This is especially true with organisations who do not have the necessary skill-set in-house and are forced to outsource. The inability to conduct the right due diligence, as well as the usual budget constraints, combine to perpetuate the same vulnerabilities for quite literally decades.

Cross-Site Scripting (XSS) for example, has remained in the OWASP Top 10 since its first release back in 2004 (according to this site anyway), and has never dropped below 4th. How is that possible? With the enormous amount of information out there about how to code against this flaw, the answer is not that the bad guys are getting smarter (which they are), it’s that we are staying ignorant.

Ignorance is a choice.

As much as spending money on security is the last resort (in my opinion), few organisations have the luxury of maintaining a secure coding skill-sets in-house, meaning this must be outsourced. This is simple for web-hosting, just find a compliant provider for the services, custom apps however require a little more due diligence. Luckily all you have to do is ask the right questions. Oh, wait…

In a perfect world, your security needs would drive your budget, in reality, your budget determines what quality of service you can afford. To once again quote the cliche; You get what you pay for. Unfortunately, the competition in this field is so fierce, that organisation are almost forced to provide a crap service just to break even. It used to be that security testing involved a human being skilled in the arts of ethical hacking, now price compression is pushing everyone down the road of automation and good-enough-for-PCI-work.

So regardless of which development life cycle forms the foundation of your coding practices, it must include security at all stages. Let’s take the waterfall method as an example;

waterfall

 

Security is built into no less than FIVE separate phases; Requirements, Design, Development, Testing and Monitoring, and this is in no way overboard.  Spiral, RAD, and Agile are no different, it’s just effected slightly differently.

In the end your WRITTEN life cycle must be taught to all parties, and followed explicitly, and strict separation of duties put in to place. This is not to say that you now need to hire ten more developers to meet the intent, but your checks and balances between the FUNCTIONS of the process need to show due care and attention.

Again, I’m no expert in this stuff, and there is really no way of going above and beyond here (not that going too far has EVER been an issue I’ve come across), but there is simply too much information out there, and too many talented security professionals, for there to be any excuses for not building appropriate security into your development life cycle.

Oh, and if you don’t use a code builder software (GitHub for example) to enforce the appropriate phases and authorisations, as well as effect the separation of test and production, you are already way behind the curve.

Finally, if all you use is the OWASP Top 10 as a checklist to test your web facing apps, you will be breached, it’s just a matter of time.

Not sure how to proceed? Ask.

Leave a Reply

Your email address will not be published. Required fields are marked *