Businesses continually adopt new technologies to become more efficient and
effective. This move toward efficiency in IT has brought a “shift left” to
application security testing. Methodologies like DevOps and Agile work with iterative
and MVP states, meaning that apps are constantly updating and constantly need
testing and retesting – sometimes daily or multiple times per day.
Serverless, cloud native, containers, and Kubernetes are changing how apps are
deployed and managed. This has expanded the attack surface in the form of new
layers of complexity and more settings and updates to manage, which also means
more room for manual error. In a container, this includes the image, registry,
and east-west traffic, while in Kubernetes, this includes access and
authentication, runtime resources, and network policies. Traffic between apps
in a container does not cross perimeter network security, but should still be
monitored for malicious traffic between apps and the resources they use.
Your cloud-based ecosystem doesn’t provide comprehensive security
Cloud providers, orchestrators, and other partners don’t provide a full
spectrum of security capabilities out of the box – even with their help, your
team must create and maintain their own security policies and continuously
monitor your ecosystem for any unusual or malicious activity. While network
segmentation and perimeter security for your guest VMs or containers might be
available, your engineer will typically need to configure that.
The figure below outlines the responsibilities of cloud providers, security
vendors, and end-users, across apps, hosts, networks, and foundation services.
The responsibilities in purple and orange are primarily the responsibility of
the cloud provider and security vendors, but our engineers tell us that they
are involved in every cell of this chart in some way.
Treat security as a critical outcome, not a department
Security should be top of mind for everyone in the business, not just your
security team. While the complexity of your infrastructure builds, new tools
and capabilities give opportunity for everyone to contribute to the security
effort. Here are a few areas of change that will help you rally the masses in
defense of your business:
- Cloud providers are beginning to offer more security capabilities.
- System updates – and staying current with your patches – could very much save the day.
- Automating your processes could make or break the business. While guidelines
for humans are necessary, you need automation to abstract the complexity of
your infrastructure. Soon, automated capabilities to translate plain-language
policies into the growing multitude of settings will make their way into the
market.
Take a Zero Trust approach to your applications
The foundational idea of Zero Trust is simple: Trust nothing and always assume
the bad guys are trying to get in. It’s time to take your security beyond the
traditional network-perimeter approach and extend Zero Trust from data,
network, and endpoints to your application infrastructure. It also wouldn’t
hurt to protect the software development lifecycle (SDLC) to ensure the integrity of your software is not
compromised, given all of the automation in a typical DevOps toolchain.
Three key principles to secure next-generation IT
1. Enhance your security practices with DevSecOps
As you iterate on software, dovetail security into each iteration through DevSecOps – not simply
to test security for the entire history of the app, but to test the impact of
each change made in every update. Retrofitting your apps and software for
secure functionality will slow down your release cycle. Marrying the two
will save both time in the present, and heartache in the future when
your software is inevitably attacked. Unfortunately, traditional methods don’t
fit the bill when it comes to DevOps; it’s too expensive and too robust to
scan every piece of code manually. With a shift left strategy, security scans can be automated into every
code commit – meaning you no longer need to choose between risk, cost, and
agility.
Arm your developers to resolve vulnerabilities early in the SDLC, leaving your
security team free to focus on exceptions.
With GitLab, a review app is spun up at code commit – before the
individual developer’s code is merged to the master. The developer can see and
test the working application, with test results highlighting the impact of the
code change. Dynamic application security testing (DAST)
can then scan the review app, and the developer can quickly iterate to resolve
vulnerabilities reported in their pipeline report.
Learn more about DAST in GitLab's product documentation.
2. Secure horizontally before digging deeper
We often fall into the trap of going deep on a single aspect of security –
leaving other obvious aspects completely exposed. For instance, you may
use a powerful scanner for your mission-critical apps but neglect to scan
others; or, you may choose to save resources by not scanning your third-party
code, with the assumption that its widespread use means it’s checked out.
Avoid focusing so much on application security that you forget about container
scanning, orchestrators, and access management.
3. Simplicity and integration wins
The key is to bring security scanning to the development process by having a
tool like GitLab that allows developers to stay within the same platform or
interface to both code and scan. Making the process easier increases the
likelihood that it’ll get done – and making the process automatic within the
tool ensures that it will happen every time there is a code update.
Ready to deliver secure apps with every update? Just commit.
Cover image by Frank McKenna on Unsplash
