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
In Part 1 today, we talk about external and internal drivers that are placing the topic of software security in the focus of manufacturers.
Torsten Schlotmann: "There are many reasons for secure software, but I would first like to focus on regulation as a driver. We conduct our audits according to standards in which secure software development plays an important role. In general, software development is an essential component in all relevant security standards. Regulatory requirements by the legislator, compliance requirements for example from the credit card industry, ISO standards or customer requirements must be considered and implemented in software development. While all of this should not be the primary and most important driver, it may be the first for many companies. However, due to the constant changes and increasing complexity of the standards, it is no longer enough to deal with security or its implementation exclusively in the implementation phase. Security needs to be embedded and integrated into all phases of the development process and included as 'business as usual' in everyday life."
Stephan Neumann: "A further driver for secure software is the cost factor. Applications are a lucrative target for an attacker because of the density of sensitive data. Should an attacker successfully exploit a vulnerability, a lot of follow-up tasks arise, which unfortunately also involve time and costs. The circumstances must be clarified and major damage prevented, customers informed and new certificates and passwords assigned. Once this is done, the next step is to fix the vulnerability. Maybe new systems have to be set up, the infrastructure is also involved. Perhaps it also makes sense to perform a test afterwards to see whether the vulnerability has finally been fixed. This selection of examples is intended to show that there is an insane amount of work to be done - work that could perhaps have been avoided. I can therefore recommend not only to look at the external drivers that my colleague Torsten has described, but to integrate security also on your own request. By doing so, you create the opportunity to identify vulnerabilities in time or prevent them from occurring in the first place by using trained developers."
