With an increased ease of access to cloud infrastructure resources, we often see a porting of applications from private "perimeter controlled" data centres into cloud infrastructures without the requisite attention paid to the design changes that are needed to support the secure deployment of these workloads. In addition to this, the complexity of cloud infrastructure and Open Source tooling often generates "sample / PoC" code that is implemented into production without scrutiny or a thorough understanding of each function or component.
In order to help mitigate these risks, there are a few areas Arctiq recommends companies invest their time and resources:
- Tooling
- Education
- Communication
Investment in Tooling
Reducing the amount of time that humans must spend deploying and maintaining application systems can shorten the time it takes to act on new or existing security threats. In order to free up this time, adding tools in the following areas an help produce a more secure footprint.
Deployment automation
While this isn't a new concept, a fully automated deployment pipeline enables security to be easily woven into the process and removes the need for human involvement. With this approach, teams are much more likely to apply secure defaults while also having more time to fine tune their security configurations. Secure default configurations can easily be crafted with the assistance of security professionals and templated for inclusion within all new or existing deployment pipelines.
Automated patching
Tools continue to rise in the market that are focused on the automated patching of existing code. In their simplest form these tools can scan a code repository, identify a vulnerable library, and automatically create a Pull Request / Merge Request with a new version of the code that includes the fixed version. This type of automation, paired with deployment automation, can drastically reduce the the time it takes to fix vulnerabilities with very little human involvement.
Infrastructure resiliency
The infrastructure that applications are deployed upon must also support patching operations; independent of the applications that are running on top of them. This requires a fully resilient infrastructure that can dynamically change as components are patched, replaced, or reconfigured.
Runtime enforcement
Many tools exist to help identify issues before they show up at runtime, however, there are also tools that can identify and isolate applications that are already deployed. Such runtime tools can be critical in identifying the blast radius of a potential vulnerability and can help identify which specific workloads require attention. These tools can also often restrict application workloads to operate within a "known and acceptable pattern", often blocking processes that may be tied to an exploited vulnerability.
Centralized visibility and policy enforcement
As it relates to IaaS and other cloud managed services, teams can invest in centralized tooling to authorize which cloud services can be provisioned along with ensuring that they adhere to corporate policy. These tools help to centrally identify what cloud assets exist, and also provide detailed reporting and audit trails on how these assets are accessed or modified.
Applications deployed as containerized microservices can become increasily difficult to troubleshoot as a result of their overall complexity and ability to run across multiple Kubernetes clusters or regions. Tooling that can help visualize and secure the flow of traffic between these microservices will help arm development teams with the ability to isolate specific issues, while simplifying the security configuration and reducing human error.
Endpoint security enforcement
The idea of a "perimeter" in Cloud infrastructure isn't as concrete as it once was in the datacenter. This is largely due to a lack of understanding of the cloud platforms underlying security controls, the responsibilities that are shared between the cloud provider and the customer, and the rapid nature in which infrastructure changes are automatically applied to productions systems with less human interaction (read: CAB meetings) . In the age of just-in-time change, tools need to be deployed to treat every endpoint or application as a part of the perimeter itself. Tooling that enables zero-trust networking and process management at the microservice level becomes increasingly important to reduce the dependency on the IaaS perimeter configuration.
Investment in Education
Having the right tools will not improve security posture, and could possibly cause harm, if they aren't used properly. As tools are deployed across an organization, investment in education is a critical step towards the proper adoption and usage of this tooling. Enterprises should invest in;
Developing customized training courses
Training courses for infrastructure and security tooling that teams will use is essential towards the broad adoption of these tools and reduces human error. Education about the importance of security tooling as it relates to the development process for Product Owners is also critical towards ensuring that security metrics are tracked with each deployment.
On-demand access to ephemeral test/learning environments
Development teams, whether focused on application or infrastructure development, need immediate access to evaluate and test tools and their configurations. Time delays in obtaining a "safe" environment for learning will result in inappropriate environments being used for testing, or tools that never get implemented.
Developing an “access enablement” process
Teams that must complete training prior to gaining access to higher environments are more likely to succeed in the implementation and maintenance of their security infrastructure. The successful completion of security training should be recorded and proudly displayed on a developer profile.
Investment in Communication
One of the most important elements to address, once tools and training programs exist, is ensuring that shared knowledge of each tool exists with a process to provide feedback or improvements. Enterprises should invest in;
Detailed developer and infrastructure documentation
Providing accurate, thorough, and easy to follow documentation is critical to the adoption of any tool or process.
"If it isn't documented, it doesn't exist"
Visibile infrastructure & security code that is being applied to their workloads
In this world of "everything-as-code", teams should have easy access to view the configuration code for systems that may affect their overall deployment or runtime activities. Access to view these configurations should be a simple process and should be helpful to teams who wish to have a deeper understanding of the their supporting infrastructure.
Community experts that can coach other teams on tooling usage
It's often found that development teams learn better from other development teams. Once security tooling has been deployed in production, the early adopter teams should provide additional documentation, use cases, and guidance on their specific implementation. This type of activity leads to a "community support" model that can help accelerate the deployment of security tools and processes for newly onboarded teams and applications.
Effective feedback loops for tooling and documentation enhancements
New security tooling should fit into existing processes that will reduce "tool fatigue" when it comes to interacting with developers. For instance, security tools can provide notifications to developers directly in their Git tools (in the form of GitHub Issues or Jira tickets), or through their favorite chat tools like Slack.
When teams need to provide feedback about security tooling configuration, it's best to also provide this in the form of GitHub issues or even possibly Pull Requests if the development teams would like to contribute to the overall deployment / configuration of said security tooling. The goal here is to leverage existing tools that help provide clarity to the development teams and reduces friction for providing improvements or suggestions.
Do you have some other ideas around effective security investments that teams can make? Leave them in the comments section below!
Need help making some of the changes and investments outlined above? //take the first step
.jpg)
