How We Safeguard Development and Delivery of Avantra

With the number of supply chain attacks across the software industry increasing and gaining extensive coverage in the media, it reminded us to asked ourselves if this is something that could happen to us as well. When security issues with unprecedented impact surface, it’s quite natural to take a closer look at exactly the weakness uncovered. Nonetheless, security has to be seen as a holistic concept, with the overall security being as strong only as the weakest link of the chain (pun not intended). 

Avantra uses full-stack automation to manage SAP landscapes, which tend to be very critical components within enterprises. Shortly after the attack, the question came up whether we want to issue any statement with this regard. We decided not to, in order to avoid jumping on the bandwagon.

However, Avantra customers obviously keep asking the same questions. And with many of our customers being Managed Service Providers, their customers in turn keep asking these questions as well. That’s why we want to describe Avantra’s overall approach to security - from development to deployment to delivery -  in this article.

ISO 27001 - Information Security Management

We dedicated the better half of the year 2020 to implementing an Information Security Management System according to the ISO/IEC 27001 standard in order to benefit from the best practice it contains. And we decided to reassure our customers that we follow the recommendations of the standard by getting certified in November 2020.

One of the probably not so widely known aspects of ISO 27001 is that it requires commitment of the organization’s top management. At Avantra, no less than three members of the Leadership Team are involved in executing the ISMS. Another important aspect is that continuous improvement is built in: we constantly evolve the system. It’s a great relief if you know a known attack won't hit you, but in order to prepare for tomorrow you need to constantly improve!

While the ISMS covers many aspects, the so called Secure Software Development Policy plays a major role. It’s purpose is to assure we develop code in a way to preserve customer and business security, and ensure this code has been appropriately tested and validated before being used in a production environment and published to customers. The key ingredients are:

Risk Assessment: for every new feature and for every major software version we assess and control the risk to confidentiality, integrity, and availability. It’s an integrated part of how the teams organize their development work, and it is linked back to the ISMS team: if we identify a risk it’s being tracked and reviewed periodically until it’s being mitigated.

Code Integrity: we perform code reviews to ensure that potential coding vulnerabilities are identified. By using merge requests and an enforced approval process we can ensure no line of code is included into the product that has not been reviewed by a separate (senior) developer. This process is accompanied by automated code analysis for the most common vulnerabilities based on industry standards such as OWASP, SANS CWE, and CERT Secure Coding. Likewise, any third-party library we include into the product is verified for known vulnerabilities.

Version Tracking: helps us to ensure that only appropriate releases of code are tested, deployed, and delivered. We are using a Version Control System (git) to track every line of code, and we assign version numbers for every release created by the automated build environment (or CI/CD).

Security Testing: ensures that best practices have been fully considered during the design and development and threats have been mitigated. This area is one where we massively invested in during the second half of 2020, with efforts going well into 2021. Automated vulnerability testing is accompanied by periodic manual penetration testing conducted by external parties. And obviously, security testing links back to the initial risk assessment, where high risk features will be mitigated by dedicated penetration testing. As mentioned above, security has to be managed in an integrated fashion, so we have other areas that are directly or indirectly involved in delivering secure software:

Access Management: access to all Avantra resources and data is provided based on the least privilege principle. This includes the Version Control, the build systems, and the software delivery, of course. Only the build system and senior developers are able to push releases to the download area. And only Avantra customers have access to the download area. All access permissions are periodically verified and reviewed.

Network Security: our production environment is primarily focused on the software delivery, of course. It is kept separate from all development systems, with only limited and controlled traffic allowed between the environments. Our build environment is not accessible from the Internet at all.

Change Management: all our production environments, and in particular the build system are under change control. Like with the source code itself, we require a four-eyes principle for every change of the build system configuration. Does that mean we can guarantee supply chain attacks are impossible? You should never say ‘never’ in IT security, but what we can do is assess and control security risks, and let independent third parties verify and certify we do as we say. This raises the bar high. Very high.

While we’re talking about security: One of the primary interfaces Avantra uses to connect to SAP systems are delivered with an ABAP transport. Everything built in there is designed also according to the least privilege principle! And none of the Avantra components require root permissions to run with. Subscribe to our blog to get articles you must read sent right to your inbox and find more details in our Security White paper!