Cyber Expert Defines CISO ‘Tribes,’ Talks Software Life CycleAdd bookmark
The April 9 episode of “Task Force 7 Radio” featured distinguished software security figure, Gary McGraw, the Vice President of Security Technology at Synopsys.
McGraw is the author of eight bestselling books on software security. He has over 100 peer-reviewed articles in scientific publications, is frequently quoted in the press and holds dual PhDs in Cognitive Science and Computer Science from Indiana University, where he’s on the Dean’s Advisory Council for the School of Informatics.
On the show, hosted by information security executive George Rettas, McGraw covered everything from the concept of perimeter security to baking security principles into software at the design stage, along with a “governing” framework. McGraw also touched upon a comprehensive CISO study that placed the security team leaders in four “tribes” based on the organization’s security posture.
Asked about the significance of software, McGraw said, “It turns out the software we were counting on to work…has a problem, and that is that it’s broken. And broken software leads to all sorts of issues, primary among those is security. If you want to attack cyber security properly, you have to focus on the root cause, and that turns out to be broken software.”
On doing more to secure software from the outset, McGraw said he typically describes it as a “trinity of trouble.” The first aspect: complexity. He said, “Software is complex, it’s the most complex thing we’ve built as a species.” The second aspect: “extensibility.” He said, “The idea of a software program is to be able to be flexible and change later. A lot of software is designed expressly with that kind of flexibility in mind.”
The third “trinity” point: everything being networked. “Back in the old days,” he said, “they liked the idea of perimeter security, or drawing a boundary around a system. Software defeats that by being massively distributed. The notion of being able to draw a boundary around software and do perimeter security becomes impossible.”
The Fall Of The Perimeter
Is the concept of perimeter security truly dooming cyber security, though?
Commenting on this, McGraw said, “Perimeter security is an idea that’s been around for a long time… The real issue with (it) is you have to be able to have a boundary all the way around the system. Modern systems are massively distributed, and the movement to the cloud means perimeter security doesn’t even work in modern designs. We have to move beyond that…”
On balancing risk in the software process, McGraw said, “There’s such a thing as spending too much on security, or having too much security in a system so that it becomes not very useful… You have to balance ‘getting stuff done’ – which is the reason we have software and systems in the first place – against our security desires, and make that balance appropriate. It’s a tricky proposition we’ve been working on for many, many years.”
Workload & The SDLC
Sure, risk is inherent in the software development process, but who, under the Information Security banner, should be overseeing the security protocols?
“No one was responsible for it 15 years ago,” McGraw said. “But then we saw the advent of the software security group, and it turns out many Information Security departments either have one inside or closely associated with them…”
From a management perspective, McGraw said, it’s about identifying someone in the enterprise to complete a task and giving them the resources and responsibilities for doing it. “Then, it’ll get done,” he continued. “That’s what a software security group is about… (We’ve) made a huge amount of progress in the last 20 years in software security, and I’m really proud of that.”
At this point, the “TF7 Radio” guest outlined the software development life cycle (SDLC). He said from a security perspective, there are seven things you should do in the SDLC, three of which are paramount. One, he said, was code review with a tool. He called that the “number one touchpoint.” Second, he added, is architecture risk analysis, sometimes called threat modeling. The idea there, McGraw said, is that to ensure the code is sound, you have to pay attention to the architecture as well as the implementation. The third point: regular penetration testing.
McGraw then outlined his work with BSIM (building security in maturity model). He called BSIM a “measuring stick for software security,” capable of measuring the capabilities of a software security group. In its eighth version, BSIM has become a framework for understanding what activities a software initiative should have inside it. Today, he said 109 firms comprise the BSIM community.
The “TF7 Radio” guest also outlined a comprehensive study of 25 CISOs he put forth. The study, McGraw said, breaks CISOs into four “tribes.” Each designation essentially describes the security posture of the respective organization.
Security As A Cost Center
Tribe Four, the Synopsys VP said, is a “problematic” space to be in. CISOs in this group only operate as a “cost center,” meaning the CISOs are often overwhelmed, under-resourced and not really a CISO.” They typically exist beneath several levels of management. These CISOs do not drive budget creation, and have a “glass ceiling imposed on them.”
Compliance Is Everything
The next tribe, McGraw said, involves “Security as Compliance.” This means that for some enterprises, simply exceeding compliance measures has been both a hurdle and a threshold. Those in this tribe “intentionally leverage compliance requirements to make some security progress.” Yet, McGraw added that by itself, compliance is “not good enough.” He said it’s the bare minimum standard you have to reach.
“What we see in Tribe Three,” McGraw said, “is that previous security leadership was replaced, usually at the same time as some compliance regime was imposed from the outside, probably because of a big crisis… CISOs in the compliance tribe tend not to be deep, technical people. Often they’re very strong with management and leadership, with senior management gravitas…” However, they encounter scenarios where “technical debt is still accumulating.”
The Alpha Geeks
The “Security as Technology” tribe involves CISOs that have moved well past compliance and who are often technologists/“alpha geeks” who overemphasize technological aspects.
A technology CISO sets out to be a “good business person,” McGraw said. However, they’re not thought of as senior executive businesspeople. These CISOs solve problems, take on sticky challenges and often encounter the “Superman Syndrome,” where they get in the weeds to remediate a particular issue. McGraw said “sometimes firms are really attuned to having a Tribe Two CISO.”
Tribe One: McGraw called this “the top of the mountain.” CISOs here have evolved past compliance, and are committed and viewed as senior executives. The enterprise, too, has moved past compliance, and uses a risk management approach to supply oversight. Tribe One CISOs also get lines of business to participate in the security mission. While these C-Suite members could be technologists, they look exactly like their senior executive peers, and have a “seat at the table.” McGraw said these CISOs “proactively try to get in front of problems they see coming up, both internally and externally.”
The "Task Force 7 Radio" recap is a weekly feature on the Cyber Security Hub.
To listen to this and past episodes of "Task Force 7 Radio," click here.
Visit McGraw's personal website, here.
Be Sure To Check Out: Is Cryptocurrency Cyber Security's Next Big Threat?