Computer Security: the security marathon
If you believe that “security” is a sprint, that a quick hack is invulnerable, that quick bug fixing is sufficient, that plugging security measures on top of existing structures is good, that once you are secure your life will be easy... then let me convince you otherwise.
An excellent example of this is when the summer students join us at CERN. As the summer period is short, software projects must be accomplished quickly, like a sprint. Rush, rush! But often, this sprint ends with aching muscles.
Regularly, these summer students approach us to have their project or web server made visible to the Internet. Regularly, quick security reviews of those web servers diagnose severe underperformance with regards to security: the web applications are flawed or use insecure protocols; the employed software tools, databases or web frameworks are sub-optimal and not adequately chosen for that project; the operating system is non-standard and has never been brought up-to-date; and the server hardware is old and no longer supported. So, unfortunately, we often must decline making their project public on the Internet. Their fun sprint ends with them in the hospital. Game Over.
In reality, “security” is a marathon. It requires detailed preparation, proper integration and scheduling. Just as running a marathon becomes a part of life, “security” is a part of software development. Thus, as for every marathon run, you need to prepare well. In software programming, being “well prepared” means having a proper software development lifecycle (SDLC).
A good SDLC extends “programming” to phases on software design and repeated testing. Only with proper functional specifications is it possible to verify whether code works as intended, i.e. fulfilling the specified use cases. “Security” is just another aspect of checking whether the code can be abused or not. We have compiled a list of hints and tips for the various phases of your SDLC. Good books on that are available by R. Anderson (“Security Engineering”) or G. McGraw (“Software Security”). Automatic tools like “flawfinder” might help you discover the easy bugs. We have produced a long list of such automatic static code analysis tools for many different programming languages. Regular training is another step. The computer security team provides adequate training sessions on web application development and programming, Java, C/C++, Python, PHP and Perl. Just check our training web page.
Check out our website for further information, answers to your questions and help, or e-mail Computer.Security@cern.ch.
If you want to learn more about computer security incidents and issues at CERN, just follow our Monthly Report.
Access the entire collection of Computer Security articles here.
