Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
This is going to be a rant partly, because it's just one of these days, and I'm hoping this post will serve as a cure. Maybe it helps others in the process, that's fine, too.
</disclaimer>
OK, now that the title got your attention, what is this about? I recently reviewed a number of security related architecture documents, most of them triggered by findings in our internal quality processes. What puzzled me most was the creativity that was put into those, mostly by people whose main job isn't security.
While I can understand the desire to get a solution fast security is one of those topics where creativity is a really REALLY bad idea. For many different reasons.
When you look at the kind of implementations that are vulnerable to attacks you'll realize quickly that attackers have an endless amount of creativity available, too. Watch this video to get some ideas:
From the developer perspective this means there is a high probability that any time you're inventing a new solution for a security problem you might create another exploitable piece of code.
This is especially true for ANYTHING that envolves encryption and/or cryptography based authentication. Everything in that area has been solved, peer reviewed and tested many many times, yet rarely a month goes by with another highly creative and incredibly vulnerable new approach. This is an area that's easy to do badly for the best of us, spare me the experience with the rest of us :wink:
How can you avoid that? Easy. For this special case, stop being creative and rely on what others have already solved.There is a wide variety of secure coding guidance out there, OWASP is an excellent starting point: https://www.owasp.org/index.php/Category:How_To
If you haven't yet, moving to a formal SDLC (Security Development Life Cycle) is also a good idea. I liked this recent presentation by @securityninja a lot:
Also, please make sure that whatever you do is based on a threat model. That doesn't necessarily mean the full formal approach, but it helps if you write down what the threat is that your code is supposed to mitigate. It also helps testing if it actually does what it's supposed to do.
I'm pretty sure that wherever you work, somebody else has already done something similar. Try to identify the security champions in your organisation, and get in contact with them. Better yet, create a community of security experts where you can discuss and share your solutions. If you're on your own, the SCN Security Forum is also a good place to discuss. ANYTHING is better than inventing stuff that has already been properly implemented somewhere else.
Another reason why creativity in security is bad is that your code might actually live a long time, and may even need to be maintained. If you implemented a novel approach to a common problem, that makes maintenance harder. Even worse, even if you got it right the first time, another developer doing maintenance might introduce a vulnerability because he didn't fully understand your approach.
The last reason, adding a business perspective: any new piece of security infrastructure that doesn't quite work like the other ones introduces complexity. It adds complexity for administrators that might need to come up with new processes to maintain the solution, and it adds complexity for users that barely understand how to use the other solutions in a secure manner.
Please, try to think of that when you are about to implement a novel way of user registration or password reset processes.
So there, I'm done. Anyone with the same problem? Other Suggestions? Feel free to share your best stories in the comments :wink:
