Many security teams struggle with prioritization: mostly reacting on incoming requests and constantly pulled in many different directions. There is no way to measure or to point out improvements that were achieved in terms of raising the level of security.

OKRs are a great tool for target setting in teams in general, especially in security. For the last nine months all our work of operating and developing Offensity is driven by OKRs. This article tries to share some insights and why OKRs might work well for your team.

Who we are – disclaimer

We are a team of security enthusiasts based in Austria. We provide professional social engineering and penetration testing campaigns. If you need help in these areas, contact support@offensity.com.

Offensity also helps professional IT admins identify vulnerabilities by scanning their infrastructure automatically. Make sure to test our tool - it's completely free for up to 2 domains and 50 subdomains!

What are OKRs?

OKRs stand for objectives and key results. The objective defines, what we want to achieve. One of our objectives in the past was for example:

"Improve the security of the web application at https://reporting.offensity.com/."

This is what we wanted to achieve. "What is >improve<?", by boss asked. Well, this is what we have key results for: Concrete tasks that can be measured - thus how do we achieve it. They were:

  • Security updates of server software are installed automatically once per day
  • Caching of data in restricted web site areas is prevented
  • A+ scoring for web app's SSL settings on https://www.ssllabs.com/ is reached
  • A scoring for web app's SSL settings on https://securityheaders.com/ is reached
  • The web app is security-scanned by the Offensity-framework and issues with medium risk or higher are resolved within three working days

This made very clear, what we have on our roadmap and what to focus on. The next month, we kept the objective and just changed the key results:

"Improve the security of the web application at https://reporting.offensity.com/."

  • Two factor authentication is introduced and enforced for staff
  • A manual penetration test of five man-days was executed for the web app
  • Static source code analysis is executed for the web app
  • Penetration test and source code analysis findings of medium risk and higher are resolved within three working days
  • A re-test of resolved issues was executed within four weeks

By following this process we continuously improved our security and to had a common picture of what needs to be achieved in the next weeks.

Here is another example of one of our former OKRs in our team:
"Gain customer loyalty, improve quality, usability and user experience"

  • All customer scanning profiles are scanned with Nessus. Major findings that were not detected by Offensity are implemented.
  • All customer websites are scanned with Burp's active scanner. Major findings that were not detected by Offensity are implemented.
  • Summary page at reporting.offensity.com is deployed containing overview about
    • overall risk score
    • number of open issues per category (none-critical)
    • timeline showing the highest risk score for the past weeks (or months)
  • Monthly summaries with key figures are sent out to customers automatically

By using OKRs we were able improve key areas of the product in a very structured way:

  • We dedicated resources to internal and external server infrastructure
  • We introduced and improved processes like change management, backups, development guidelines
  • We started automating our infrastructure and processes.
  • We introduced data retention policies.

What works for the Offensity team?

Three to five objectives with up to 10 key results for each objective worked best for us. We currently update our OKRs quarterly (– while starting out with monthly OKR cycles).

When updating our OKRs we try to follow these simple principles:

  • Every objective must have a real impact on your team or company
  • Every key result must contribute to the objective
  • KRs are measurable. Always.
  • You can shift time frames, e.g. have one OKR for one quarter and another for one year
  • You can keep the objective and change the KRs over the OKR cycles
  • Change, add or remove OKRs whenever necessary, also during the cycles
  • Document dependencies to other teams or colleagues
  • OKRs are open and transparent
  • OKRs are not directly connected to bonuses and special payments

My final recommendation: start small and improve the OKR process where you see need.
In general, setting OKRs for development teams should be straight-forward and a very good way to go.

Further information on OKRs

For further information about OKRs, I recommend the following resources: