I recently read an interesting and insightful article on Security Roundtable written by Craig Templeton, CISO at REA Group, where he questioned whether DevSecOps, the systematic and innate integration of security into the DevOps process, was little more than a marketing buzzword.
Craig’s article painted an exciting picture of organizations (such as his) working together seamlessly from the start to ensure that security was and is a vital element of DevOps, and not an afterthought. Like my colleagues at Palo Alto Networks and others in the cybersecurity space, I could not be happier that Craig and REA have found a way to make the “sec” part of DevSecOps second nature.
However, I also want to inject a different perspective into this discussion. REA seems to have done great work in making security a critical element from the start, without creating friction or slowing down the pace of DevOps. However, I hear from many of my industry peers that they are still very much in the infancy of their own DevOps journeys, and the practice is not as simple as the theory.
The reality for many is that at just about the first step, there is a potential misalignment. DevOps is a cross-tribe group with a simple goal: deliver a technology-based business function, which typically continues to evolve over time. Here’s the mismatch: Security likes to understand risk and make informed decisions. DevOps teams are focused on delivering outcomes, typically at pace to be ahead of competitors. In order to succeed, those outcomes must include the relevant security context.
A good analogy is what has happened in the telecommunications industry, where space used to be measured on speed and uptime. In this context, the engineers would see security as a potential threat to their measured goals. I was at a family event many years ago and met a distant relative who worked in this space. When I told him I was in cybersecurity, he virtually stopped talking to me on the spot.
The second challenge is that the businesses expectations of DevOps can change as fast as the project itself evolves. All too often, these start as skunkworks concepts, where external expertise is often bought in to see if it works for your business. Before you know it, the project is a success and has gone mainstream. The consultants you leveraged to help get started won’t have the same security baseline as your business, and your willingness to take risks in a small pilot is typically very different when it comes to implementing them as core business services. Look in the news today, and you see many projects where poor account credentials result in a breach. If these were set up as simple proof-of-concept projects, undoubtedly simple passwords were used, or they were stored in clear text so other members of the team could easily access them. As such, as Craig suggests, you need to start as you wish to continue, and build it in from the start.
This leads to my third consideration. DevOps is typically made up of cross-functional teams that can themselves be dynamic. There will always be friction between these roles; it’s part of what makes DevOps succeed–small, dynamic groups that resolve focused challenges. However, this agility can increase cyber hygiene risks. Changing staff and teams can make it hard to have a consistent cyber champion in the team. Moreover, what is deemed to be “cyber success” can change.
For instance, the cyber champion could deem that all cloud processes should be behind a firewall. If that firewall is configured as we often see, allowing any communications, team members can tick the box to indicate that they have included the proper security protections. You may risk being leveraged by adversaries for crypto-mining (others using your compute power effectively to make money), which will impact computing performance, while also exposing the organization to potentially negative brand impact should the event result in a headline.
The question you must ask, therefore, is what should you expect of a cyber champion in your DevOps teams? How do you maintain consistency where there can be high levels of change? And, most critically, what are the handoff points where it needs expertise? How is this done in a manner that doesn’t slow the project down or create bottlenecks where you rely on small pockets of expertise?
Cybersecurity is increasingly leveraging automation to allow it to function dynamically in agile compute spaces, so the actual technical issues should act as inhibitors. For me, the issue is recognizing that business goals and the teams’ expertise will vary. Therefore, it is critical that everyone is clear on what is expected of them and where the handover occurs to the core cybersecurity team.
Agility and pace cannot and should not be an excuse to not apply the learning from years of cybersecurity experiences. This means you need the same visibility and metrics you have in every other aspect of your IT processes. However, the reality is that DevOps typically means more cross-functional people collaborating, and doing so at greater pace. To me, this simply means cybersecurity teams also are collaborating at that pace. With skills shortages all around, it is key to know the skills to impart across the teams, and when and where to leverage the cybersecurity experts. It is critical that they all share a common goal based on business outcomes, and not on individual production elements.
Craig’s view from his business is an enviable position. The reality is that every business is at their own level of maturity. In the future, we might be able to retire DevSecOps as a buzzword. However, today it’s a good reminder that security needs to be a part of the development and operations teams that are enabling new business agility. Who knows? In a few years, maybe we’ll just call this agile IT or something completely different.
Greg Day is chief security officer, EMEA, for Palo Alto Networks.