It’s a jungle out there when it comes to cloud native security. Cloud environments are massive, noisy and always changing. The number of assets that need monitoring is intense, forcing security teams to operate in a constant state of overwhelm.
New tools come to market and as security operations teams acclimate to them, a new pain point emerges that requires yet another tool. SecOps teams need all the help they can get.
DevOps support is key to moving processes earlier in the development lifecycle. Regardless of any friction that might exist between the two teams, it behooves SecOps teams to get more strategic about how they enlist DevOps’ support.
While these situations are context-driven, in my experience, SecOps teams that invest their political capital with DevOps teams in the following ways have reaped the highest returns.
3 Security Best Practices for DevOps Teams
- Assign dedicated roles to each service an application uses.
- Perform regular audits to make sure logging stays enabled.
- Use open-source security tools.
Design ‘Least Privilege’ From the Beginning
One of the most effective ways to harden an application (increase its layers of security) is to start with dedicated roles for each service it uses instead of generic ones. This way, should your application become compromised, you can still contain the scope of the damage.
Consider a scenario where a front-end application needs to read assets from an S3 bucket (a container for storing objects in Amazon Web Services). The easy path — which is the norm in many organizations — is to assign broad, generic access rights.
A more secure method is to create a role specifically for each application and service pair, granting the front-end application read-only access to only the required S3 buckets. Implementing this approach may require audits and careful design.
This will, of course, slow down the development process, at least until developers get up to speed on this. It’s an approach that conflicts with the “move fast” mentality of many organizations, but it pays dividends in security.
Developers often start building applications using generic access only to have security come in down the line telling them it’s a bad practice. By then, the environment has already racked up a substantial amount of security debt that may or may not get completely resolved.
Enable Logging on All Components
This is another security 101 best practice that can easily fall out of whack. Comprehensive audit logs provide invaluable visibility into system activities and are crucial for detecting, responding to and investigating potential security incidents.
Implementing thorough logging, however, has its challenges. In environments with numerous services, the cost of storing and processing logs can quickly escalate.
There’s also the ongoing management overhead to consider. DevOps teams, often under pressure to optimize performance and reduce costs, might be tempted to disable logging for non-critical services. It’s also possible to forget to enable such logs, as it requires checking the box for each new service you’re deploying.
You should perform regular audits to ensure that logging remains enabled, especially for critical services. If the company has a small or limited security staff, it falls to DevOps to ensure logging is enabled. While they usually do, it’s easy to forget to re-enable logging after making a change or forget to turn it on when activating a new service.
Another challenge with logging is the danger of siloed reporting. In multi-cloud environments, logs from different providers (such as AWS and Google Cloud Platform) are usually stored in separate systems. This segregation can severely hamper efforts to correlate events across environments, potentially missing critical security insights.
For companies that don’t have a log management tool, there are workarounds that depend on what other tools are in use. For example, you can dump logs to S3 and configure Splunk to index them and look for anomalies or malicious activity.
Use Free Tools for Security Scanning
Shifting left sounds great in theory, but it’s a heavy lift that requires major recalibrations across people, process and technology. And that kind of change takes time.
Case in point: e-commerce has been around since the 1990s, yet only recently have hardcore e-commerce companies started to merge their security and fraud teams in a meaningful way.
But you must start somewhere, and what better way to make DevOps an ally than to give them free security tools? Two of my favorites are Syft and Grype but there’s also OWASP Dependency-Check and a host of others. SecOps teams must support DevOps teams with scanning. You must also make sure that scan results are actionable. Each identified issue should come with clear remediation steps that developers can follow.
Despite everyone’s best intentions, rarely do we see DevSecOps become a thing until a breach happens. Change that and these won’t be hacks, they’ll be standard operating procedure.
