Cybersecurity is a dance that requires many partners moving in sync, both inside and outside of your IT department. To achieve meaningful success, all parties must eliminate silos, share their insights willingly, and achieve a collective mindset.
This challenge starts with aligning the mission of your offensive and defense security specialists, but then it extends to your application coders and architects who drive innovation, according to panelists speaking at the CyberRisk Alliance’s InfoSec World conference in Orlando on Monday.
Panelist Kim Jones, director of security operations at Intuit, referred to the process in Star Trek terms: “mind-melding.”
Jones noted that cybersecurity teams operating in corporate enterprises tend to be siloed and specialized when it comes to the activities of OffSec specialists (aka red teamers) and defensive security personnel (or blue teamers).
Defense-minded infosec professionals tend to “understand the importance of castling and building the moats etc.” but “don't necessarily understand how the bad guys are [coming after them.]” Meanwhile, red teamers try to topple underlying defenses without imparting their knowledge in a constructive manner — “forgetting that, even internally, it's important to understand that we're all trying to defend the business, and that sharing that mindset and information allows us to do that better.”
Proper collaboration between red and blue teams allows for the concept of purple teaming, whereby offensive and defensive security specialists combine their perspectives and know-how to optimize security within an organization.
“Purple teaming, for me, is the open-book exercise that allows for sharing,” said Jones. “It allows us as the defenders to actually see how the offenders came at us. And the offenders see that there is a reason why we can't just shut everything down. And… we collectively figure out together how to either eliminate — or more than likely just mitigate — the risk of that particular attack pattern.”
Security philosophy: More than just red and blue teams
This philosophy doesn’t just apply to red, blue and purple teams. You might say security is made up of additional colors of the rainbow, as well, as everyone must be part of this collective mindset. Moderator Ed Adams, who serves as board director at Cyversity and CEO of Security Innovation, cited the “InfoSec Wheel” concept created in 2020 by Louis Cremen (expanding on the work of April Wright), which added a “yellow team” comprised of application builders and coders. Sharing red-team and blue-team intelligence with this yellow team effectively allows for orange-teaming and green-teaming thought exercises that incorporate offensive and defensive security principles into the DevOps process.
Adams noted that one of the more encouraging mind shifts he’s seen lately “is organizations thinking about security as an aspect of software quality in the case of software products. That was definitely not the case 20 years ago, when I started in this industry. Security was in on one side of the world and product development and everything else was on the other side of the world. It seems to be changing a little bit.
“When we do blue teaming, we take pride [in] teaching our developers about security controls that they must [introduce] to protect their applications from attackers,” added panelist Trupti Shiralkar, senior security engineering manager, product security, at Datadog. “When we do red teaming, this happens either in production or when we are ready to release the service or application in production. So it happens pretty late in SDLC [software development life cycle].”
The value of fixing vulnerabilities in design phase: 'All the colors matter'
Once an app hits production, however, the game changes. After all, research has shown that fixing vulnerabilities during the design phase is generally much cheaper than doing so once production commences.
“And that's the exact value purple teaming brings to us — when we bring those exploitation techniques and attack techniques and mix [them] with our security controls during design phase, we suddenly reduce the average age to remediate vulnerabilities to almost one-third. And the overall security value — the return on security value — is really high,” Shiralkar continued.
Ultimately, it’s important that all points of view are heard and given relatively equal weight.
“All the colors matter,” said panelist Sherron Burgess, senior vice president and CISO of BCD Travel. They’re all essential in their own way. Yet how do you get the app builders or yellow teamers to play ball and honor the needs of offensive and defensive cyber specialists when their primary goal is to innovate?
For starters, Burgess said companies can mandate minimum security standards that production lines must adhere to in order to go into production. Organizations can also strive to create a culture that makes security a company-wide responsibility — for example by requiring specific security certifications for certain projects. For builders, this “gives them a measure of accomplishment like: ‘Yes, I can I build a PCI-compliant product or system that meets the scrutiny of XYZ assessor,’” said Burgess.
Plus, “if there's a threat that we won't be able to renew those initiatives because processes drop off, then there's a different level of pressure across the business — not just from security — to get things done.”
Jones said that it’s important for IT leaders to communicate the economics of security when working with development teams — and then find opportunities to introduce new workflow efficiencies to help offset and counterbalance the perception that security slows down innovation.
“I spend a lot of time talking about what it really costs for us to do security and getting to the point of reducing that cost and increasing efficiency by creating … frictionless systems,” said Jones, who recommended talking directly with builders and asking them how IT/security professionals can “make your life easier.”
“And that breaks down a lot of … barriers and makes it easier for me to truly integrate within the organization.”
It also helps to give your developers some level of freedom and autonomy. “We never have enough security engineers,” said Shiralkar. So forcing developers to coordinate with security on everything just slows everything down, she noted. “And if you study today's fast, feature-driven SDLC, they want to design their features fast [to] generate shiny new revenue.”
That’s why involving your security team too much can make developers feel as if “you’re creating a hindrance to their revenue,” she continued.
Therefore, security teams should save such interference for the mission-critical, top 10% of projects. In those circumstances, “we have to involve security because we cannot afford to have security breaches… but the rest of the 90% we can actually teach our developers how to do security [themselves].”
Ultimately, said Adams, a major key to getting DevOps specialists on board is to encourage to them see security as “another aspect of software quality, just like functionality, performance and reliability, all those other abilities that they've already been thinking about.”
Shiralkar agreed that this approach helps drive motivation among Datadog’s company’s app and services builders.
“Security is really no different than quality engineering,” she said. “As a software developer, you are so used to fixing software bugs, quality assurance bugs. What are security bugs? [At the] end of the day, you have to fix code or you have to place another control so honestly speaking, security engineering is really part of quality engineering.”
Upon instilling this point of view, “they are extremely motivated with producing higher quality software. Once they are convinced, they take efforts to learn security through our security champions program, security ambassador programs [and] DevSecOps. They show a lot of interest.”
