In practice, it is not an easy task for manufacturers to continuously integrate a strong security mindset into complex software projects. In our blog series, Stephan Neumann, Head of usd HeroLab, and Torsten Schlotmann, Head of PCI Security Services, talk about practicable approaches and ways to still effectively improve software security.
- Part 1: Reasons for more Security
- Part 2: Anchoring Security in the Corporate Culture
- Part 3: Requirement and Threat Analysis
- Part 4: Static Code Analysis
- Part 5: Dynamic Code Analysis and Vulnerability Management
There are many reasons why security should be embedded and integrated as 'business as usual' in everyday life and in all phases of the development process. For part 2 of our series, we asked our two experts about the best ways to start.
Stephan Neumann: "There is no universal recipe for the development process for Secure Software. Starting points are individual for each company. But over time, best practices have developed that work very well. Therefore, my recommendation is to integrate security into the corporate culture. It is important that the implementation of necessary measures becomes standard, learned practice. The topic of security needs to lose complexity and ideally reach the state where departments no longer perceive security as an additional expense. One way of achieving this stage is to train colleagues from the specialized departments to become so-called Security Champions. These bring a certain basic knowledge of IT security with them through private interest, their previous activities or their education. Security Champions can be completely normal developers who, in addition to their everyday tasks, have a particular focus on security. They can provide support internally in interpreting vulnerabilities or act as contact persons for external security audits. When asked about the optimal number of Security Champions, measured by project or team size, all I can say is that in a normal-sized team, even one Security Champion would be an absolutely wonderful thing."
Torsten Schlotmann: "I have also experienced this during the audits of our customers. Ideally, the security champion is someone from the respective development team, because he or she knows exactly what the challenges of the department are and can also act as a qualified contact person for security issues. As a tendency, the technical colleagues are more likely to accept the advice of the internal Security Champion, because they don't have the feeling of being assigned someone from a central security organization for this role who evaluates their work from the 'outside' - instead, it's someone from the team who is perfectly integrated and can contribute directly from the inside."
