More and more companies are promoting close cooperation between development and operations to accelerate the delivery of high-quality software. But the fast DevOps environment requires a security approach that goes beyond the functional DevSecOps concept: Secure DevOps.
This article was published in "Computerwoche" at 07.05.2017 in German.
DevOps is currently breaking new ground, especially in the SAP environment: HANA is a development platform that offers ideal conditions for fast and agile programming of new applications with high quality thanks to big data processing. This meets the growing demands of companies to react flexibly to changing market and customer needs in order to be successful in competition. Instead of fewer large SAP releases, as is usual in conventional software development, numerous smaller functions and solutions based on the high-performance HANA platform are continuously put into operation.
Functional approach falls short
But even if the time pressure in the DevOps environment is high, the topic of security must not fall by the wayside - especially as the abundance of new programming creates increased attack possibilities for cyber criminals and economic spies. DevSecOps is a new approach that tries to meet the security requirements of agile software development. However, this approach is too short because it focuses primarily on functional protection measures for the DevOps environment. Authentication, authorizations and encryption, for example, are used to protect interfaces against manipulation or to prevent possible security gaps from third-party components.
However important these functional protection components may be, they are not sufficient to effectively counter the security risks in the DevOps environment. Therefore, companies should simultaneously adopt a technical approach that includes security in the development right from the start and uses suitable tools to meet the security requirements throughout the entire software lifecycle: Secure DevOps. Security standards such as OWASP Top 10, SANS 25, BIZEC App / 11 and BIZEC Tec / 11 should be considered and tested automatically at several test points.
This is the only way to ensure that the new functions and applications can be safely programmed, configured and transferred to the target system.
Software Life Cycle Roadmap
Secure DevOps places the following requirements on DevOps teams developing applications based on classic SAP or SAP HANA in the individual phases of the software life cycle:
- Code Development
The earlier an SAP security gap is eliminated, the less subsequent effort is required. Therefore, errors and weak points in the ABAP code should be identified and corrected as early as possible during programming. In addition to the standard test tools in the SAP development environment, open source tools and third-party add-ons are also available to analyze the ABAP source code in accordance with certain security standards.
These tools integrate the security standards in the form of preconfigured check catalogs and ensure that each check is performed automatically directly during code writing - comparable to the interactive spell checker in Microsoft Word, with which text documents can be analyzed and corrected for errors as they are entered. Automatic source code analysis eliminates the need for manual intervention by programmers and reduces associated error possibilities.
- Trial Period
In order to further increase the security level in the DevOps environment, automated tests should be mandatory immediately after development, without which code release is not possible in principle. You can also choose from various test tools for this test phase, with which the ABAP source code is tested directly in the development environment. Whether tools from SAP, open source or add-on providers are used depends on the individual requirements in the company. If it turns out during the test phase that the code does not meet the required quality criteria, it must under no circumstances be transported to the next level, but must be corrected.
- Build Phase
In the build phase, the individual ABAP code fragments are "packed" together with the configurations and table contents into executable units - hence also known as packages or, in SAP jargon: transports. The transport system in SAP is an important tool for transferring your own developments into the productive system. However, since it does not perform a detailed check on the transport objects, it only becomes clear after the import whether the adjustments can be inserted without any negative effects.
Therefore, automatic security and quality tests should be carried out as early as the build phase. Furthermore, the integration of these checks in the change process ensures that the adjustments in the productive SAP System do not change any critical settings or unintentionally overwrite data.
- Runtime Environment / Operation
Since every change affects the runtime behavior of a system, this can also be associated with a deterioration in the security level - for example, if logging is deactivated by a new configuration. To avoid this, the system operation should be checked cyclically with suitable test tools. If a security incident occurs, the system administrator must immediately receive an appropriate alarm.
Seamless Coupling of Test Tools
Numerous practical examples prove this: Even in conventional programming in the SAP environment, IT-supported tests are indispensable for identifying and correcting security gaps in the code and applications in good time. This applies all the more to the DevOps concept, which combines a permanently high throughput with agility and high quality requirements. To be on the safe side with DevOps, companies should use testing tools that are integrated directly into the DevOps environment and ensure a high degree of automation throughout every phase of the software product life cycle.Whatever security tools a company chooses: It is important that the individual components can be seamlessly integrated and coupled with each other so that no media breaks occur. Otherwise, there is a risk that the overview will quickly be lost and existing error or defect lists will be overlooked.