If you've read any management article, book or interview recently, its unlikely that you've not come across the term "OKR". The term (and practice) has become as entrenched with management culture, as its founding company, Intel, has with microchips.
OKR is a goal-setting methodology that can be used by companies, teams and people. The focus of OKRs is to define and acheive "Big, Hairy Audacious Goals" through visibility, transparency and alignment.
OKR stands for "Objectives and Key Results". Let's briefly look at what this means.
Objectives are essentially "what" you want to achieve. This is a statement that captures your goal. It shoud be forward-thinking, aspirational and engaging. For example:
Achieve a 30% increase in customer subscriptions in 2021
Objectives are important, because they capture "what" you are going after.
While the "what" is very useful, its nearly pointless without capturing the "how". That's where Key Results come in
Key Results are mapped to the Objective, to be able to tie the Objective to a set of results to be achieved for the Objective to be considered achieved. They are metrics that measure progress against an Objective. For example:
Improve Net Promoter Score from 60% to 80%
Sign on 3 New Corporate Clients for the SaaS Product with 100 Subscriptions per company
OKRs are done at multiple levels in an organization to be able to drive a shared sense of mission. They are typically available to all members of the organizations, teams right upto the C-Suite and Company. The idea is that even an employee 8 levels below the CXO should be able to find the OKRs for the CXO and possibly create OKRs for herself that aligns with the CXO's or the Company's Objectives or contribute to their Key Results.
Companies like Google, Dun and Bradstreet, Target swear by OKRs. We at we45 have also introduced OKRs as a way to measure our progress quarter to quarter. We are loving the process so far and we believe its an important approach to achieving collective alignment.
One of the things I observed about OKRs is that they are very useful in creating Goals and Results for your AppSec Program as well. Let's face it. Your AppSec Program is another management system and having specific, aspirational goals is something you'd definitely want to look at, to make it successful in the short and long run.
For this, what you need is:
- Objective ⇒ Some Goal that would drive your AppSec Program forward, is aspirational and is engaging to your organization and the specific teams that are part of the AppSec Program.
- Key Result ⇒ A set of metrics that allow your to measure progress against the Objective in the form of clear and possibly quantitative metrics.
However, the natural question is. "How do we define these OKRs for AppSec?" We need to think about:
- Our Apps and their stack
- Our teams and the way we're setup
- Balancing tactical needs against strategic needs
- Creating short term and long term impact
- Getting the right people on the team
Naturally, I realized that answers to a lot of these questions, nay, the entire OKR process itself, can be derived from Threat Modeling.
Effective Threat Modeling by itself can ensure that your OKRs and AppSec Program are not only in great tactical shape, but also help define a strategic roadmap for your AppSec Program.
Let me try and draw up some parallels and correlating factors between OKRs and Threat Modeling in form of examples in specific areas
Better Objectives and Key Results with Threat Modeling
Objectives are Goals. And what better way to derive data for your goals than an Effective Threat Model.
Suppose your Threat Modeling reveals that most of your threats are Authorization and Access Control related, you can possibly create an Objective that looks like this:
Implement Consistent Access Control Mechanisms across <Your App/All Projects>
Now based on the Controls identified in your Threat Model and a collaborative discussion with Engineering and Product Ownership, you can define Key Results that may look like this:
- Get 80% of Developers trained on Access Control by the end of Q1 2021
- Achieve 100% compliance against OWASP ASVS Authentication, Authorization and Access Control Modules L1 and L2 Controls
- Manually Test with Pentesting or Red-Teaming all Authorization Scenarios identified in the Threat Model
- Implement OAuth and OIDC with O365 IdP for 3 Consumer Facing Products by Q1 2021
As you can see, this not only creates a specific plan, this also helps you define a consistent playbook that is measurable and creates a sense of alignment between Engineering, QA, Security and Product Ownership folks
Speak their Language
One common problem that I hear across the security industry (and have been hearing since I entered security in 2008) is that security doesn't know how to speak the language of management. This is true. And still a very real problem. Management does not understand Security-Speak and security is still not aware of how to express issues that matter to management. This creates a barrier that is much larger than it appears. Not only does this create funding challenges for security teams, but it creates a much more substantive process-oriented divide that siloes security teams. While DevSecOps has definitely addressed this divide in some way, there's a long way to go here.
We, as Security folks need to be able to frame our problems better to Management can sit up and take notice and help us achieve our objectives as we help them achieve theirs. And OKR is PURRFECT for that.
For example, let's say that your Chief Revenue Officer (CRO) has an objective:
Increase Top-line Revenue from <X Product> Business Unit
Now, as a CISO/AppSec Manager, you can directly create Objectives Key Results that align with your CRO's OKRs. For example:
Increase Customer Confidence by including and delivering security features
The above Objective directly addresses the Revenue Objective and can have follow-on Key Results that include things like:
- Documenting security features of <X Product> and including them in website (builds customer confidence)
- Achieving certifications against specific certs like ISO-27001, SOC2, PCI, etc
This sort of alignment clearly speaks to a multi-directional flow that ensures that management clearly understands "why" certain security initiatives are being undertaken. And its in the system that they use every day.
Balance the Strategic and Tactical
Security Programs constantly need to balance the strategic objectives and the tactical objective
A Strategic Objective may be
Get all Developers aligned to security objectives
vs a Tactical Objective that may be
Have no vulnerabilities in prod above a CVSS4 score
Deeply examined, both objectives are similar in nature and Key Results for these objectives can be achieved with a combination of strategic and tactical result metrics and actions. For example:
Get 80% of developers trained on Security Essentials (Strategic)
can be included with Tactical Key Result
Include 1 Static Analysis tool and Secrets Identifying tool in Github Actions pipeline
Both of these Key Results can be included selectively in multiple objectives, and they both trace their origins to Effective Threat Modeling.
I believe that there's great synergy between OKRs and Threat Modeling. Threat Modeling done well, provides a great deal of useful input in framing your OKRs and measuring them correctly over time.
In addition, OKRs also provide a framework in which Security can start aligning and being visible, effectively to Senior Management Objectives and Cross-Team Objectives. This increases collaboration and visibility. In addition, this provides a much-needed frame of reference to non-security teams on the need and importance of security initiatives for their product, service and company.
Abhay is the Chief Research Officer of AppSecEngineer. With our library and hands-on cloud labs and cyber-ranges consisting of amazing courses on DevSecOps, AppSec, Cloud Security and Threat Modeling, AppSecEngineer helps you become a better AppSec Professional. Subscribe today!