The author of this blog is a PhD candidate at Óbuda University Doctoral School on Safety and Security Sciences, Hungary, with the research topic of information and communication technology’s security in critical infrastructures. He conducted various research on different perspectives of cybersecurity, such as the Union-level governance as well as national-level and business effects of cyberattacks, including financial and non-financial impacts. He is a security expert in the business area, holding ISACA, ISC(2), and EC-Council certificates. He is the founder and CEO of a cybersecurity consulting firm providing such services as risk analysis, virtual CISO, etc.
November 28, 2022
Security in DevOps
For a multitude of reasons, it's crucial in the realm of cybersecurity to have the right set of security controls. Both the internal information and communication technology (ICT) services - which are provided by either on-premises ICT infrastructure or the cloud - and the company’s ICT products and services must uphold this obligation. Whereas our last blog post dealt with cybersecurity controls in applications, in this post we will focus on security requirements for development processes and related technologies.
The systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of the two. In the past, functions worked in silos that differentiated internal and external software and IT operations. However, software developed for internal usage and customer-facing software products today mostly does not differ, and the widely applied DevOps methodologies bring together software development (Dev) and IT operations (Ops) practices [1]. This approach aims to shorten the development life cycle by providing continuous delivery and integrity with high software quality. Interestingly, it is complementary to Agile software development, as several of the DevOps aspects that are applied derive from the Agile methodology, and this is true even in the case of operational tasks. Consequently, effective integration, communication, and collaboration among development and operations teams are emphasised, something which forces them to focus on the delivery of products. Alongside development, continuous integration and delivery play crucial roles in achieving automation to save time and effort. When DevOps is introduced, new application functionalities are delivered more rapidly and more frequently. However, this agility by no means implies that one should provide software code without planning. The proper planning of functional and non-functional requirements fulfilment is in fact a crucial part of the process.
Continuous integration (CI) is the practice of integrating all the code changes into one or more relevant branches of a shared source code repository early and often and automatically testing each change at the point of committing or merging. Errors and issues can be identified and fixed more frequently and made accessible because of frequent changes, triggering automatic testing and validation processes, which include static code analysis conducted by, for example, Selenium and TestNG. With integrated Static Application Security Testing (SAST), an IDE (integrated development environment) can provide analytical information about not only fulfilling the syntax and semantics of the given programming language but also injected security vulnerabilities, which must be eliminated before the application code is committed to the code repository.
In essence, building code combines unit and integration testing, code review, and packaging. Continuous delivery (CD), working in conjunction with continuous integration, is the practice of automating the release process. Automation of the entire CI/CD pipeline is achievable when more tools are introduced, from which Jenkins is a freely available popular solution. After the release is built, it can be deployed to production at any time – manually or by continuous deployment, involving proper configuration management, as deployment consists in configuring and maintaining consistency in the functional requirement of the application. Of course, there are more tools, such as Ansible, Puppet, and Chef, that help in the deployment of the new release. Integrating Dynamic Analysis Security Testing (DAST) tools into the CI/CD pipeline can uncover further issues when all components are integrated and running, looking for a broad range of vulnerabilities, including input and output validation issues providing a wide range of opportunities for cross-site scripting or SQL injection.
Furthermore, the build and delivery processes in their entirety are typically highly automated and can involve microservices, containerisation, and even cloud environments. DevOps Security or DevSecOps is a set of practices, cultural approaches, and tools that integrates security (Sec) into DevOps processes to increase the ability to deliver applications and services securely. DevSecOps entails embedding governance and cybersecurity functions into processes. Done right, it facilitates efficient product releases overall. Naturally, it is much easier and less costly to implement technical and organisational measures for an application at the earliest stages of the design of the processing operations. Security-by-design represents an approach to software development that seeks to embed security controls at the beginning of application development and to make systems as free of vulnerabilities as possible through such measures as continuous testing, authentication safeguards and adherence to best programming practices. Where security requirements are concerned, the kind of frameworks that were discussed in previous blog posts, such as the NIST Special Publication (SP) 800-53 Revision 5 [2] and the OWASP Application Security Verification Standard (ASVS) [3], feature security controls which not only tell developers the security capabilities their software products must have, but also advise testers, DevOps engineers, and IT operational staff what they must do or must make the automation tools do during the CI/CD pipeline.
Consequently, it is essential to tackle properly the security of the automation tool, including authentication and authorisation to source handling, source codes and the corresponding automation tools, auditing activities, backups, network segmentation, and so on. For example, in the case of identity and access management (IAM) and privilege management, both human access and machine access must be covered. DevOps practitioners require privileged access across development and production environments. For automating processes, machines and tools also need elevated privileges (or permissions) to access resources. Hence, secrets, including privileged account credentials, SSH Keys, APIs tokens, issued certificates, and so forth, may be used by humans or non-humans during the DevOps processes.
To conclude, in application development both the produced software and the related processes must take security issues into account, which is not an easy task. DevOps methodologies can help make applications as secure as possible, but one should also think about how to ensure that the related environment is safeguarded against vulnerabilities by applying the proper security control set.
References
[1] W. P. Luz, G. Pinto, and R. Bonifácio, “Adopting DevOps in the real world: A theory, a model, and a case study,” Journal of Systems and Software, vol. 157, 2019, doi: 10.1016/j.jss.2019.07.083.
[2] “Security and Privacy Controls for Information Systems and Organizations,” Gaithersburg, MD, Sep. 2020. doi: 10.6028/NIST.SP.800-53r5.
[3] OWASP, “Application Security Verification Standard 4.0.3,” 2021. (accessed Aug. 27, 2022).
by
Bederna Zsolt
November 28, 2022
Security in DevOps
For a multitude of reasons, it's crucial in the realm of cybersecurity to have the right set of security controls. Both the internal information and communication technology (ICT) services - which are provided by either on-premises ICT infrastructure or the cloud - and the company’s ICT products and services must uphold this obligation. Whereas our last blog post dealt with cybersecurity controls in applications, in this post we will focus on security requirements for development processes and related technologies.
The systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The systems development life cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of the two. In the past, functions worked in silos that differentiated internal and external software and IT operations. However, software developed for internal usage and customer-facing software products today mostly does not differ, and the widely applied DevOps methodologies bring together software development (Dev) and IT operations (Ops) practices [1]. This approach aims to shorten the development life cycle by providing continuous delivery and integrity with high software quality. Interestingly, it is complementary to Agile software development, as several of the DevOps aspects that are applied derive from the Agile methodology, and this is true even in the case of operational tasks. Consequently, effective integration, communication, and collaboration among development and operations teams are emphasised, something which forces them to focus on the delivery of products. Alongside development, continuous integration and delivery play crucial roles in achieving automation to save time and effort. When DevOps is introduced, new application functionalities are delivered more rapidly and more frequently. However, this agility by no means implies that one should provide software code without planning. The proper planning of functional and non-functional requirements fulfilment is in fact a crucial part of the process.
Continuous integration (CI) is the practice of integrating all the code changes into one or more relevant branches of a shared source code repository early and often and automatically testing each change at the point of committing or merging. Errors and issues can be identified and fixed more frequently and made accessible because of frequent changes, triggering automatic testing and validation processes, which include static code analysis conducted by, for example, Selenium and TestNG. With integrated Static Application Security Testing (SAST), an IDE (integrated development environment) can provide analytical information about not only fulfilling the syntax and semantics of the given programming language but also injected security vulnerabilities, which must be eliminated before the application code is committed to the code repository.
In essence, building code combines unit and integration testing, code review, and packaging. Continuous delivery (CD), working in conjunction with continuous integration, is the practice of automating the release process. Automation of the entire CI/CD pipeline is achievable when more tools are introduced, from which Jenkins is a freely available popular solution. After the release is built, it can be deployed to production at any time – manually or by continuous deployment, involving proper configuration management, as deployment consists in configuring and maintaining consistency in the functional requirement of the application. Of course, there are more tools, such as Ansible, Puppet, and Chef, that help in the deployment of the new release. Integrating Dynamic Analysis Security Testing (DAST) tools into the CI/CD pipeline can uncover further issues when all components are integrated and running, looking for a broad range of vulnerabilities, including input and output validation issues providing a wide range of opportunities for cross-site scripting or SQL injection.
Furthermore, the build and delivery processes in their entirety are typically highly automated and can involve microservices, containerisation, and even cloud environments. DevOps Security or DevSecOps is a set of practices, cultural approaches, and tools that integrates security (Sec) into DevOps processes to increase the ability to deliver applications and services securely. DevSecOps entails embedding governance and cybersecurity functions into processes. Done right, it facilitates efficient product releases overall. Naturally, it is much easier and less costly to implement technical and organisational measures for an application at the earliest stages of the design of the processing operations. Security-by-design represents an approach to software development that seeks to embed security controls at the beginning of application development and to make systems as free of vulnerabilities as possible through such measures as continuous testing, authentication safeguards and adherence to best programming practices. Where security requirements are concerned, the kind of frameworks that were discussed in previous blog posts, such as the NIST Special Publication (SP) 800-53 Revision 5 [2] and the OWASP Application Security Verification Standard (ASVS) [3], feature security controls which not only tell developers the security capabilities their software products must have, but also advise testers, DevOps engineers, and IT operational staff what they must do or must make the automation tools do during the CI/CD pipeline.
Consequently, it is essential to tackle properly the security of the automation tool, including authentication and authorisation to source handling, source codes and the corresponding automation tools, auditing activities, backups, network segmentation, and so on. For example, in the case of identity and access management (IAM) and privilege management, both human access and machine access must be covered. DevOps practitioners require privileged access across development and production environments. For automating processes, machines and tools also need elevated privileges (or permissions) to access resources. Hence, secrets, including privileged account credentials, SSH Keys, APIs tokens, issued certificates, and so forth, may be used by humans or non-humans during the DevOps processes.
To conclude, in application development both the produced software and the related processes must take security issues into account, which is not an easy task. DevOps methodologies can help make applications as secure as possible, but one should also think about how to ensure that the related environment is safeguarded against vulnerabilities by applying the proper security control set.
References
[1] W. P. Luz, G. Pinto, and R. Bonifácio, “Adopting DevOps in the real world: A theory, a model, and a case study,” Journal of Systems and Software, vol. 157, 2019, doi: 10.1016/j.jss.2019.07.083.
[2] “Security and Privacy Controls for Information Systems and Organizations,” Gaithersburg, MD, Sep. 2020. doi: 10.6028/NIST.SP.800-53r5.
[3] OWASP, “Application Security Verification Standard 4.0.3,” 2021. (accessed Aug. 27, 2022).
Bederna Zsolt
