Last updated at Wed, 12 Apr 2023 22:16:18 GMT
Going from a centralized security group that dictates a “command and control” approach to cloud security toward a model of “trust but verify,” is at the core of the modern shift toward security-practice democratization. Organizational practices behind legacy, centralized data centers are being rethought, as teams realize that the old methodologies simply can’t scale to support the speed necessary to thrive in today's competitive landscape.
The issue isn’t unique to any one industry. Across the board, businesses need to help securely develop and deploy applications so that the company meets bottom-line expectations and remains competitive. How then, can DevOps and IT teams work and innovate in a friction-reduced or—we can all dream—a friction-free way?
It begins with getting in a room
Whether it’s physically or virtually, getting security and DevOps teams together at the beginning of a project helps set the standard moving forward. Setting weekly or bi-weekly meetings to ascertain the scope of what’s being built or what needs to migrate helps curtail misinformation, misunderstandings, and ultimately enables a more protected product.
Whatever the process—GKE clusters, IAM roles, storage—it’s important to work with key security stakeholders early to get those standards integrated to support the development teams. Collaborative communication tools like Slack can aid greatly in catching changes or vulnerabilities prior to or post-deployment. For example, if someone goes in and makes a change to IAM configuration after deploying, security teams can be alerted via Slack, and then know to go in and check that everything is as it should be.
As development and security teams integrate these types of simple alerts—and auto-shutdown of instances are avoided—they begin to alleviate perceived friction and define an efficient macro-level working process. Then, by the time deployment is at hand, there are fewer “big things” that can go wrong.
Monitoring what’s yet to be created
Let’s take a use case like Terraform, a more cloud-agnostic, open-source coding tool that uses a single configuration to manage multiple providers. Before, a resource would be spun up and then the team would have to go back in for fixes if issues arose. DivvyCloud by Rapid7 can work with programs like Terraform, incorporating new features that allow checks against the plan before development kicks off. Issues are then caught within that plan before resources are even created. This will:
- Help save on resource costs
- Ensure all teams are aligned and aware
- Anticipate problems before they even happen
- Enable key learnings for more efficient future deployments
Perhaps the biggest benefit is the potential for vast improvement in launch time. When issues are flagged earlier and earlier in the process, the culture really does begin to shift left, with security teams perhaps having to deal with less friction—or maybe no friction at all!
All that being said, the above is very much a security team POV. So, what do dev teams think about seeing these issues and potential vulnerabilities come up sooner in the process, while they’re simultaneously being told to get things online faster?
The one-team conversation
It’s true that the “there’s no ‘I’ in team” rallying cry can come off as a bit of a corporate cliche. However, in much the same way as security is shifting earlier into the development process, it really can help to have that “one-team”conversation before things kick off in earnest. Getting everyone in a room—again, physically or virtually—and being open and honest with all teams about how the process is going to go can preemptively help clear the air about pain points along the way.
When opening up the security identification and remediation process to developers, it simply becomes a question of how comfortable the security team is with specific actions. Are the dev teams ingrained enough to be able to apply turnkey fixes with no approval whatsoever? Or, perhaps, going back to the example of Slack alerts, it’s an automated notice that a change has been made by a developer and the security team can quickly take a look … or decide not to. Either way, they’ve been made aware by a simple automated process, and now both teams can stay aligned. A potential drawback of that automated communication, though, is that it can quickly become noisey. No one needs or wants 300+ alerts a week, especially if some of them don’t actually require attention. The ability to customize which alerts you receive and how you receive them creates a scaled down, meaningful alert system. It allows room for action and cuts down on communication fatigue and friction.
Mapping back to innovation
Working toward harmony between DevOps and security not only drives innovation for those teams, but it also means that the enterprise is able to build and deliver more products and solutions. Accelerating speed-to-build and speed-to-deployment doesn’t have to come fraught with so many risks in the age of cloud.
The true reward comes when teams find more time for innovation by working together and educating each other. The next step comes in convincing stakeholders outside of these organizations that the process is worth improving and well worth the investment.
