2. People
- Empowering developers is key to cybersecurity. Once a skilled developer fully embraces security as a primary responsibility, huge progress can be observed.
- Given security is often neglected by developers, this takes time and iterations.
- First, developers shall be educated practically, through a hands-on approach, so as to become aware of the impact of development practices on software security.
- Then, they shall be involved in the security improvement through security stories that can be added in the development backlog and discussed by the team.
- Eventually, at least a few members of the development team shall act as security champions, and keep improving security practices. Ideally, every developer shall feel responsible for security.
- Peer review is a key practice to for development security. It has several benefits:
- It is probably the most effective way to transmit good practices and knowledge.
- When done seriously, it strongly diminishes the probability of letting a flaw in the code (if the probability is random for each developer at a rate of 10%, then with one reviewer the probability fall to 1%, 0.1% with 2 reviewers).
- It is an effective mitigation against the risk of rogue code inclusion by an attacker that succeeded to hack a developer's workstation.
- It also improves code quality and readability.
- It facilitates maintainability, as more than one person has understood each single line of code.
- It can be used to implement separation of duties, with different developers in charge of coding and in charge of integration.
- To maximize productivity, peer review shall occur after automatic reviews (SAST/DAST tools).
- Peer review organization shall be automated, which is very easy with tools like Github or Gitlab.
- The number of reviewer shall depend on the sensitivity of code. For normal code, 1 reviewer is reasonable. For sensitive code (e.g. for a component managing access control), 2 reviewers is a must.
- The choice of reviewer shall be left to the developers, but with team/management control. Any developer shall be able to perform an additional review if he/she deems it valuable.
- OWASP provides a very good guide on secure code review: https://owasp.org/www-project-code-review-guide/
- Awareness sessions shall be organized regularly, preferrably with a hands-on approach.
- Tools like Google Gruyere (https://google-gruyere.appspot.com/) are well fitted to organize a 2-hour session with 4 to 10 persons.
- 1 or 2 days advanced training sessions can cover more theoretical knowledge, and in-depth reviews on flawed code.
- The handling of credentials (passwords, keys) by humans is a process that is difficult to handle properly.
- Users shall be educated to use systematically a trusted credential manager (Keepass is a popular choice), and always generate passwords randomly with a proper complexity (at least 100 bits, >128 bits recommended).
- Developers shall understand why they should never (ever) commit a secret in git, and how to handle such errors (when possible by revoking the credential, making the secret useless).
- Credentials that can be handled automatically without need of human knowledge shall be preferred. This is clearly the way to go, with ultimately users never manipulating credentials.
- Credential sharing is often necessary. This can be done through shared credential stores (e.g. with a shared Keepass store).
- Credential rotation is especially difficult in practice, and often never done. The best way to achieve proper rotation is to use include this requirement at design stage.