In July 2018, F5 released its first annual Application Protection Report. As part of the report, F5 commissioned Ponemon to survey of 3,135 IT security practitioners across the world. The survey collected information about respondent’s application security processes. A key question asked for respondents to name their organization’s primary owner of application risk.
In theory, one would hope that the CISO was the number one answer by far. In reality, the CISO came in fifth place. The top owners of app security were: the CIO/CTO at 26%, Head of Application Development at 21%, and Business Units tying with “no one” at 18%. Surprisingly, CISOs received only 10% of the responses for the application security risk owner. The only choices lower than CISO were Compliance at 5% and Quality Assurance at 1%.
Over the past couple of months, I’ve been presenting the results of this report to various large tech organizations. When I share the survey results on the application risk ownership, something interesting happens. The room awakens in a series of murmurs and chuckles. Then this progresses into heated discussions, finger pointing, and exasperation. Clearly, as an industry, we have still not figured this out.
I can understand how CIO/CTO ended up as the number one response at 26%. I also see the response of “no one” at 18% as well. If no one is definitively in charge of applications security, responsibility will bubble all the way up to the top. Less mature organizations may not even have someone with the CISO role. So, in those cases, CIO/CTO may also be the answer merely because there is no one else at that level to take charge.
The second most popular choice, Head of Application Development, makes sense in organizations that develop and maintain their own applications. Twenty-one percent is quite a high number, given that most organizations have some kind of web or mobile application presence, if not for customers, then modified applications for employees and partners. A powerful stage to secure applications is in the beginning (shift left for security). Development is the stage where the bulk of impactful security testing and threat modelling occur. If an organization classifies security vulnerabilities as defects, then surely Quality Assurance is an important voice in app security. But what happens when the application moves into production? Who owns app security at that point?
One thing we’ve learned in recent years is that today’s applications are more than just code running on a server. They are a conglomeration of multiple dependent mechanisms like access control, domain name services, networks, and transport encryption. This kind of infrastructure is the realm of IT Operations and IT Security. Also, applications live in production, and this is where the consequential application attacks happen. IT owns and runs these environments. Some IT departments also have separate Site Reliability Engineering (SRE) teams that ensure sites stay online in the face of downtime, including attacks. Because of the size and frequency of DoS attacks, the SRE team needs to be involved in application risk decisions.
Traditionally, IT security teams have struggled with ensuring application security. Many lack the training, tools, and experience to deal with complex applications. However, we are seeing a shift in the industry from a focus on protecting the network perimeter to defending the applications and their clients, the endpoints.
If there are decisions to be made about an application’s risk, then those who depend on it should be a big part of the risk process. Applications are so embedded in our organizations, it’s safe to say that the applications are the business. The same Ponemon survey noted that respondents ranked over a third of their organization’s applications as “mission-critical.” Business units that must be able to trust their IT team and developers to provide the support and functionality to get their work done. If an attacker tampers with, breaches, or crashes a critical application, then the business unit is the one that will feel the most pain. If an application gets breached and customers start complaining, the business owner is going to lose money first. On the flip side, if an application isn’t mission-critical and doesn’t need high-priced protections, the business owner is the one most likely to be aware of this fact and make that call.
When it comes to understanding and managing adversarial IT risk, the CISO reigns supreme. And when I say CISO, I don’t mean a specific job title but rather whomever holds the most senior security role in the organization. Ideally, that would be a C-level individual, but F5 survey data shows that only 41% of security leaders hold an executive role. Directors or managers fill out the rest of a typical senior IT security role. Nevertheless, the head of IT security is going to be in the line of fire if applications get hacked. It’s their responsibility to protect company assets. CISOs also have (or should have) the expertise to understand application security threats and defenses.
Now, it seems I’ve made the case for every role mentioned in our survey question to be in charge of application security – and that is exactly what I’m saying. This is a team effort, and all these stakeholders need to form a committee to work together. Pulling together different perspectives and skills is vital to managing application risk. Managing that risk means identifying threats, quantifying potential impacts, understanding dependencies, and selecting mitigation techniques. All of these roles are experts and stakeholders who can contribute to and collaborate in this process.
In addition, the application risk team must have an executive sponsor who represents the entire organization. The sponsor should also have the authority to ensure the proper resources are available to get things done and, of course, settle disputes between the various roles.
As for application risk ownership itself? At this moment for many organizations, it should rest on the shoulders of the entire committee. When it comes to ensuring application security, you never want to go it alone. Security is hard enough already, but it gets much easier when the whole team pulls together towards a common goal.