Even in an era of deepening cynicism, pretty much everyone acknowledges that, at least in principle, cybersecurity is critically important. But to application developers, DevOps and IT operations teams, security teams are sometimes viewed as naysayers — the Dr. No of the digital world. Their obsession with risk, even if those risks seem far-fetched, has always been something of a downer. After all, risk-taking is widely regarded as fundamental to business success and rapid innovation. Being risk-aversive is not the way companies make money.
The conflicting perspectives of security professionals with their IT and DevOps colleagues have been a source of tension throughout the history of computer technology. For many organizations who find themselves along the road to digital transformation, those differences have led to an alienation of their functions, conflicting tool sets, misaligned priorities and wildly different work timelines. Rifts of those sorts are clearly counterproductive and can hobble any digitally focused business.
But there are fundamental reasons behind those conflicting perspectives. Understanding the dynamics of that estrangement is essential to building a more collaborative workforce, and crafting an organization in which everyone is facing the same direction can indeed become possible.
It is typical that developers, IT operators and security professionals are given very different charters in most organizations. DevOps and site reliability engineering (SRE) staff normally bring a “can do” attitude to their assignments, forging ahead in agile sprints to get their applications and the infrastructure that supports them quickly online.
Security people, on the other hand, have more of a “can’t do” attitude derived from the control function that is at the heart of minimizing vulnerabilities and exposure. Security implementation and testing almost always take longer than the development phase, so the two are inherently in conflict.
The recent shift to agile development — a compressed and iterative pattern of software development in which process steps overlap and testing is essentially continuous — has further aggravated the tension between DevOps and security. For example, while a piece of software could be ready for deployment within hours of having its code written, a comprehensive threat analysis could take three months or longer, which could seriously compromise the organization’s speed to market.
While that’s bad enough, there can even be conflicts within the organization’s defensive workforce. According to cybersecurity thought leader David Strom, the tension between security teams that look for problems and the remediation teams, which are frequently made up of people drawn from multiple departments who have been assigned to fixing those problems, sometimes leads to bad blood. He notes that the security teams responsible for identifying risks are often viewed by their counterparts as “the human equivalent of frequent car alarms — always going off when the wind shifts or crying wolf at false red flags.”
Ed Bellis, the CTO of Kenna Security, captured a handful of the other less-than-flattering impressions that colleagues hold of their security personnel. For example, some see the security team as “chief problem officers,” constantly flagging issues but offering little in the way of solutions. Still, others see the security team as a speed bump, slowing or halting new innovation by erecting barriers to progress. And there are those who view security as a money pit in which much is spent but with very little to show for return on the investment.
The Road To Reconciliation
That said, there remain several important ways that security teams can temper the risk of their colleagues seeing them as the pariahs of digital progress and instead become partners in a shared high-value process. One is by recognizing and focusing on common objectives.
For example, one corollary to the massive amount of data and data analytics companies use to pull together sensitive customer information is that the information comes from many sources. How can the customer experience be made convenient and delightful while remaining secure from fraud and other risks associated with multiple datasets?
A similar concern applies to the different application programming interfaces (APIs) that customers might use to access the business. What vulnerabilities do they create? Both topics provide an appropriate focus for security as well as development teams.
Another avenue to professional rapprochement is to build cybersecurity directly into the business value chain. Cybersecurity-related questions of trust are key to customers, suppliers and business partners in many sectors of business. It is particularly important in the fields of human health. Pharmacy benefit managers and health insurers, for example, spend a great deal of time figuring out ways to protect customer data and then how to explain it. A well-secured data exchange system can help alleviate that burden.
Perhaps the most significant single step, according to a recent McKinsey study, is a dramatic expansion of automation in the security environment. Moving from ticket-based service requests to API interfaces for security services requires integrating cybersecurity directly into the software development toolchain. Doing so would allow development teams to perform vulnerability scans, adjust data loss prevention rules and many more security-oriented tasks formerly left to the security team. There just aren’t enough skilled humans to do it alone.
But to enable robust and fully joint ownership of the results, each of these measures involves more tightly integrating security teams and functions into the development and operations process as well as into the end user services. In time, the two cultures must merge. The alternative is untenable.