In this playbook we refer to both Security Engineers and Security Champions. These are quite different roles but the distinction may be unclear to you if you've not heard of them before. We explain below what each of these roles looks like and the kind of skills required to be successful in them.
The best security engineers are software security people, but software security people are often impossible to find. When you need to grow the number of security engineers in your organisation by developing existing people, start with developers and teach them about security. Starting with network security people and attempting to teach them about software, compilers, SDLCs, bug tracking, and everything else in the software universe usually fails to produce the desired results. Unfortunately, no amount of traditional security knowledge can overcome a lack of experience building software.
Security engineers come in a variety of shapes and sizes. All good security engineering teams include both people with deep coding experience and people with architectural experience. Software security can't only be about finding specific bugs such as the OWASP Top Ten. Code review is an important best practice, and to perform code review you must actually understand code (not to mention the huge piles of security bugs). However, the best code reviewers sometimes make poor software architects, and asking them to perform an architecture risk analysis will only result in blank stares. Make sure you cover architectural capabilities in your security engineering team in the same way that you cover code. Finally, a security engineer is often asked to mentor, train, and work directly with hundreds of developers. Communications skills, teaching capability, and consulting practical knowledge are must-haves for at least a portion of the security engineering team.
Our description of a Security Engineer is based on what BSIMM defines as a Software Security Group. We have made some minor changes to better align with our terminology and culture.
Security Champions are essential to scale security effectively. The ratio of security specialists to developers tends to be very low; it's not unusual to operate on a ratio of 1:100 or less. To be effective, we can't rely on a central team for all security activity, and we must empower delivery teams to own the security of their own products in a meaningful way. Security Champions are widely recognised as the best solution to this problem.