Newspost Serie Software Security

Software Security: Reasons for More Security

2. November 2021

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.


In Part 1 today, we talk about external and internal drivers that are placing the topic of software security in the focus of manufacturers.

Newspost Serie Software Security Zitat Torsten Schlotmann

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."

Newspost Serie Software Security Zitat Stephan Neumann

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."

Also interesting:

Top 3 Vulnerabilities in SAP Pentests

Top 3 Vulnerabilities in SAP Pentests

During their penetration tests (pentests), our security analysts at usd HeroLab repeatedly uncover vulnerabilities that pose significant risks to corporate security. They increasingly encounter the same vulnerabilities. Our blog series "Top 3 Vulnerabilities" presents...

PCI DSS v4.0.1 Released

PCI DSS v4.0.1 Released

In response to stakeholder feedback and questions received since the release of PCI DSS v4.0 in March 2022, the PCI Security Standards Council (PCI SSC) released an update to PCI DSS: Version 4.0.1 on June 11, 2024. This update incorporated feedback from key...

Categories

Categories