.webp)
Built on the premise of bringing software development best practices to operations and infrastructure teams, DevOps promises to help your organization deliver applications and services faster and more efficiently. There are plenty of technical best practices for practicing DevOps, but the biggest shifts that have to happen to make DevOps work are cultural.
I’ve implemented DevOps cultures at small and large organizations with great success. Below find a step-by-step process for starting to get your InfoSec, Hardware, Firewall, Networking, Data Security, Support, and Operations teams working together effectively.
The first obstacle in getting your security and engineering teams to communicate is literally the words they use. Different teams might describe the same process with a different name, or use the same broad term to refer to very different specific data points. For example, when a firewall team hears “security,” they think of blocking ports, but operations teams are focused on system configuration like password complexity and disabling services. Teams need to come to an agreement about what they’re talking about by using more specific language.
The fastest way to overcome that language barrier is by getting all relevant teams on the same tooling. Using the same tools will allow disparate teams to share a frame of reference and look at the same data. Using shared verbiage is easy when you’re discussing the outputs of the same tool. A scanning or assessor tool like Tenable or Rapid7 are a great start for ensuring your security and engineering teams are looking at the same data and trusting a single source of truth - even if one team is providing hooks in and pulling data out of it for automation. Our product Sicura goes one step further, by both providing security information and offering a “what’s next” for actionable steps to take based on that data.
Next, you need to pick a single benchmark for security and compliance. Pick a benchmark, any benchmark - just choose one. All the well-respected benchmarks have specific rules for firewalling, networking, operating systems, applications - so the members of all those teams can agree on a single standard. Your benchmark is the common framework that all teams can work towards achieving compliance against, further solving the language barrier. At Sicura, we like the CIS Benchmarks published by the Center for Internet Security, because we think they’re the most technically sophisticated and clear - in fact, we’re one of only two products certified by CIS for remediation. Without a chosen common standard, you’ll find the network team working with a different standard than the applications team, and the security team trying to come in behind them all with a third standard.
An even more robust way to get your disparate teams communicating is to make them one team. Now, that’s easier said than done. A lot of organizations are composed of siloed teams, where the only times the application and firewall team interact is through passive-aggressive ticketing or when something goes very wrong. You’ll tackle this by getting folks in the same room - for planning meetings, daily standups, cross-attending other teams meetings. This achieves two parallel goals: ensuring team goals are aligned and achievable, and perhaps more importantly, convincing your engineers that the folks on other teams are real people with the same goals. Don’t try to make it happen too fast, because if you rush, you’ll break it - this approach requires a long-term vision broken into small quarterly, months, and weekly steps.
Since infrastructure is so highly integrated between all the teams, you want to incorporate team leads from every team into planning meetings. Including all team leads when you’re working through goals for the month or quarter ensures that everybody knows what everybody else is working on, and how one team’s work will impact another. While adding more meetings to folks’ calendars isn’t always popular, most team leads will be thrilled to know what their formerly-siloed colleagues are working on. Operations teams will be especially thrilled to know what’s coming down the pipe - since they are the team that eventually has to keep those new projects running long-term. Planning together will lead to collaboration and efficiency. This type of joint sprint planning is integral to Agile management and has been the norm for years in the software world - bringing it to your infrastructure team is the point of “doing devops”.
Once team leads have set goals collaboratively, the collaboration can cascade down to the full team. Present the goals to the entire team and then host breakout conversations for each subgroup to add detail and determine tactical steps to achieve those goals. At first, they’ll naturally break out into their old ‘silo’ teams. After a while, though, you’ll notice more and more cross-team discussion focusing on a specific goal. Between planning days, encourage teams to send a representative to other teams’ standups to stay aligned on progress. Scattering standups throughout the day will help, so representatives can report back. You’ll start to see collaboration blossom organically and team members building personal connections with folks on other teams at every level. Your job is to help your teams get over the initial awkwardness (agile ice breakers really work!) and see each other as teammates - all engineers approaching the same problems with the same thought processes.
It’s tempting to plan out your exact process for implementing DevOps practices (the above six steps are just that!). But resist the urge to plan too much. All you have to do is get it started, then step back and watch it unfold naturally. When I worked on implementing this culture at a large organization, I had a master plan at the beginning that quickly went out the window. Teams I didn’t expect to form, formed. Connections were made between different engineers that I hadn’t foreseen. Once it gets started, the culture takes on a life of its own, driven by your people. So empower the team to do exactly that. Let them own it and evolve it at their own pace. What did match my expectations was hesitation to the change of process - but once everyone saw the value of doing work in a faster and more collaborative way, all those hesitations disappeared. They quickly saw the value and began to take ownership over this new process, changing the culture at the organization forever.
If you’re reading to level up your DevOps organization, and give your engineering and security teams actionable insights and next steps into your infrastructure, Sicura can help. Reach out today!
Ready to maintain secure and compliant infrastructure focused on cost, automation, and consistency?