Last year, I was at a site which took safety very, very seriously. On the wall in a break room was a poster with several steps that I think we in the security industry could learn from:
- Eliminate the risk. In this case, if you see a risk and it has a known solution, that should be done. For example, with SQL injection and XSS, we know the solution. There simply is no excuse. If you don’t know about SQL injection, XSS, or even input validation, then you shouldn’t be writing software. It really is that simple.
- Engineer the risk. If the risk is too hard to eliminate, then workarounds should be created to reduce the risk to acceptable levels. To do this means you are aware of the risk, and that you know how to address the risks in at least one way. If you cannot do this, you should not be in our industry.
- Operating procedures. Systems languages do useful things, and useful things include shooting yourself in the foot with the safety off. Learning how to write safe useful code is vital (i.e. don’t create a system that has “Okay” for “Destroy data”. All useful systems must be operated safely, and this means skilled and trained system administrators and highly practiced procedures. You cannot legally outsource responsibility for your risk (otherwise contract killings would be acceptable), and thus you cannot expect low skill, low cost operators to do manage something that is vital to your business.
- Involve the everyone in safety. If it’s going to happen to you, at least let folks participate in the process. In this case, consider a security@example.com, risk register, and so on
- Wear protective equipment (hard hats, etc). All I know is that we let folks with no experience use computers. If we want to continue doing this, then …
Leave a Reply