Security in Application Modernisation
I still see many security issues found late in the development lifecycle as infrastructure specialists fail to patch or configure the platform sufficiently, and applications developers fail to code securely or use insecure open source libraries. Security is for everyone and not just for the security specialists.
The Old World
It’s a standard software development principle that the later a defect is fixed, the greater the cost of fixing the problem resulting in costly rework and delays to a programme.
The same issue occurs with security but more often as the programme managers try to avoid the potential delays or programmes being halted due to the fear of ‘security says no’ (apologies to Little Britain). In the worst case the solution needs to be reworked with procurement starting again. The gathering of security requirements needs to be shifted left to as early in the development lifecycle to meet the desired defect profile.
The New World of DevOps
In the new world of DevOps, the impact of not including security is now far greater.
The traditional waterfall approach to development created friction between the different stages of development lifecycle with multiple handoffs resulting in projects with a long delivery lifecycle that often did not meet the latest requirements of a business. Agile techniques improved the application development lifecycle but did not solve the bridge between development and operations.
DevOps principles used in the are designed to remove that friction by advocating automation for the deployment of application components into an operational context. If security requirements are missed, the benefits of the DevOps pipeline are removed as the pipeline is stalled whilst the problems are fixed.
Much of this development risk can be avoided by considering:
- Assess the risk of the changed context early
- Plan to build in consistent security controls through auto
- Externalise credentials and policy management
Let’s consider each of these in turn.
A Changed Risk Context Needs New Security Controls
When applications move to Cloud, the new context of the environment needs to be considered — as new risks require new controls.
In a traditional data centre, the security was under your direct control. With Cloud services the infrastructure security is delegated to a Cloud provider, each having a different set of security controls, where limited assurance of control effectiveness in a multi-tenant environment can be provided. Controls for cyber and operational resilience may need to move from the underlying infrastructure into the applications to provide the required trust in the application.
As the application moves to the Cloud, the interpretation of legal and regulatory requirements change. For example, as the security of the storage is no longer under your control, the data being processed may require data-at-rest encryption to meet GDPR requirements. Emerging regulatory guidance such as the draft guidelines from the European Banking Authority (EBA) on outsourcing arrangements are suggesting encryption of data-in-memory as a requirement.
Organisations need to take time to update policies to including additional requirements due to the change in risks within the Cloud. It is not simply a lift-and-shift of a legacy application as new security controls may be required.
Build-In Consistent Security Through Automation
As applications are migrated, whether as a virtual server or a container, the security configuration of needs to be built correctly the first time — specific to the context of server being orchestrated. There is little time for post install configuration and installation of security agents manually by a separate security team.
Plan for secure configuration of a device at initial deployment with continuous maintenance. In a world of zero-day threats, there is no time to wait for the next change slot to patch, be prepared to automate deployment of updates at speed during a business day (and roll-back if it causes problems).
Externalise Credentials and Policy Management
Many traditional applications have been designed with static passwords, encryption keys and digital certificates that cannot be changed. They were stored insecurely (base64 encoding is not encryption!) and were shared between different infrastructure and application components. In the Cloud Native world, each component uses a unique password/certificate/key to ensures the compromise of one credential would not compromise the whole platform.
To enable the DevOps pipeline for agile deployment and continued security, every user credential, key and certificate needs to be externalised with the credentials using directories and tools to automate the management of passwords, encryption keys and digital certificates. It is not just the initial externalisation that needs to be thought about but the management of the lifecycle with renewal and deletion of the secrets when the component is destroyed.
As the number of credentials being managed will explode, think carefully about the tooling needed to reduce the management overhead and build into the DevOps pipeline to support the full lifecycle of secrets.
A Hybrid Multi-Cloud Perspective
In a multicloud world, the security needs to be consistent across the different cloud platforms to enable mobility and flexibility. Look for a common set of security capabilities that can be utilised across the cloud platforms.
With some clients I have found they express a preference for centralising the credentials on-premises as they can control security within their own data centre but that increases the operational risk as real-time connectivity always needs to be in place between the cloud and on-premise security infrastructure. Multiple layers of networking increase complexity and the risk of a communication failure increases. Look at how to use a credential vault that will encrypt data-in-use to remove the added operational risk and complexity with on-premise integration.
This is not just a one-off exercise of looking at the risks and security requirements. The context changes and the application is updated with new code, new credentials and new vulnerabilities requiring a continuous process of improving security. This does not happen from security specialists, it happens by everyone involved in the infrastructure and application lifecycle identifying security requirements as early in the development process and calling out for help when needed.
Not all of us working in security respond with “security says no”!
