Sergey Nivens - Fotolia
The Scrum framework is a method that focuses on teamwork, accountability and iterative processes for product development, with products being hardware, software or functions. Organizations throughout the world are steadily adopting Scrum, especially in the world of agile software development projects.
So, what does this have to do with a cybersecurity program? By understanding and applying aspects of Scrum, security admins can improve how they develop, implement and manage processes and controls, effectively building an agile cybersecurity program. Here's how.
Scrum development framework basics
Scrum is a flexible, lightweight process framework based on well-defined principles. There are four Scrum principles particularly relevant to cybersecurity projects:
- Transparency: Development, implementation and management processes must be visible and understandable to all persons involved with the processes. Project team members must have a common understanding of project goals and a standard terminology to describe project status -- especially agreement on when a project task is done or ready to use.
- Inspection: Project work and progress must be frequently reviewed so that the project team can quickly identify issues that are impacting or could impact the project goal. Scrum includes several events designed to effectively meet this principle. This principle leads to increased visibility and accountability for stakeholders and project team members.
- Adaptation: If a review determines that one or more aspects of a process are preventing or could prevent project deliverables from being usable, the process must be adjusted as soon as possible. This leads to higher quality work and ensures the project appropriately supports business goals and objectives.
- Timeboxing: All Scrum events have defined minimum and maximum durations. This ensures efficient use of project team members' time and helps the team deliver the highest business value in the shortest time.
The core of Scrum is a small project team, typically between three and nine members. The team is intended to be highly flexible, productive and continuously improving. The team is also meant to be self-organizing; it should determine how best to accomplish its work. The team should be cross-functional and should have all the skills needed to accomplish a project without being overly dependent on nonteam persons.
How to implement Scrum for agile cybersecurity
Once organizations understand the theory of Scrum, they can better implement the Scrum development framework for security purposes. Organizations can use practical Scrum techniques to improve the development, implementation and management of cybersecurity projects.
The following example illustrates how Scrum techniques could be used to help develop and implement a security operations center (SOC).
It is critical for security teams to support key business objectives. Cybersecurity pros need to clearly understand project stakeholder requirements when developing or implementing agile cybersecurity controls or processes.
In Scrum, user stories describe desired high-level functionality, as shown in the following example:
- As a CISO (who?),
- I want the SOC to track how many phishing emails are clicked on by employees each month (what?)
- so that I can report the risk of phishing to the board of directors (why?).
Note that user stories are intended to communicate what a user wants -- not how to achieve the desired functionality. It is up to the project team to determine the how. User stories help ensure high-quality work and regular alignment between the project team and stakeholders.
The Scrum product backlog is a prioritized, descriptive list of all features, functions, requirements, enhancements and fixes that are known to be needed in a product -- for example, SOC SIEM, SOC use cases, SOC key performance indicators (KPIs), SOC escalation procedures, SOC employees or physical space for SOC. It is the authoritative source of requirements for any changes to be made to a product -- in this case, implementing additional SOC use cases. Product backlog items often are based on user stories and include tests that must be used to determine when an item is completed.
A key stakeholder, called a product owner, is responsible for managing the backlog.
A sprint is a two- to four-week miniproject during which one or more objectives of the overall project are accomplished. In the case of the SOC hypothetical, objectives might include developing requirements for SOC SIEM selection or developing SOC KPIs. The objectives originate from the product backlog.
The work to be performed in a sprint, also known as sprint goals, is planned before a sprint begins. Team members should discuss and answer the following three questions when planning sprint goals:
- What is the most valuable or important objective to accomplish next?
- What can the team realistically accomplish in the upcoming sprint?
- How will the work needed to reach the selected objective be achieved?
Sprints help teams break projects down into smaller, more manageable work items. They also enable faster feedback and limit the risk of a project going awry in a short period of time.
Daily Scrum meeting
The project team gathers each day for a 15-minute meeting. Daily Scrum meetings should be held at the same time and place each day. The main purpose of the meeting is for the team to quickly discuss progress toward the sprint goal and to identify any issues that may slow down or block future progress.
Each meeting participant should briefly answer the following questions:
- What did I do yesterday to help the team meet its sprint goal? For example, I created three SOC use cases.
- What will I do today to help the team meets its sprint goal? For example, I will create two more SOC use cases.
- Do I see any impediment that prevents me or the team from meeting the sprint goal? For example, I can't create a specific use case because another employee won't provide me with required information.
Daily Scrum meetings enhance team communication and help quickly identify and resolve issues.
A sprint review should be held at the end of each sprint to inspect the work done during the sprint and to modify the product backlog as needed. Project team and key stakeholders attend the meeting, which should last no more than two hours.
The following key tasks should be performed at the meeting:
- The product owner explains what product backlog items have been done in the sprint.
- The project team demonstrates the work that it has done and answers questions about the work.
- The product owner discusses the current product backlog and projects' likely completion dates based on progress to date.
The goal of the retrospective is to review project team processes and dynamics after every sprint. During the meeting -- which typically lasts one to two hours -- all team members should openly and honestly discuss the following questions:
- What went well during the sprint?
- What didn't go well during the sprint?
- What can the team improve on for the next sprint?
Similar to the lessons learned meeting that should occur after a significant cybersecurity incident, the retrospective helps ensure continuous improvement.
Attackers regularly evolve and often communicate with each other to do so. Incorporating the Scrum framework into enterprise security processes enables security admins to develop and foster agile cybersecurity measures. This is critical to enable them and their teams to become more nimble and continuously improve so that they can keep up with the ever-changing threat and risk landscape.