Introduction
Agility in project management enables quick and flexible responses to changing market and technological conditions. The implementation of agile methodologies is insufficient if security issues are not taken into account.
This article considers the guidelines contained in the French guide created by ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information) and DINSIC (Direction Interministérielle du Numérique et du Système d'Information et de Communication de l'État).
Gradual Risk Assessment in Agile Methodologies
The chosen methodology in project management determines the approach to risk management. Waterfall projects assume the delivery of a functional product at the end of the project, therefore security measures are defined and implemented for the final product. In the agile approach, functional parts of the product are delivered throughout the project duration. Appropriate security measures must be selected for each individual stage when the product is not yet complete.
Considering security issues in agile methodologies is therefore continuous (throughout the entire process of building and improving the product). Priority is given to actions resulting from the assessment of actual risk, thus the existence of residual risk is also assumed, which will be eliminated when the product proves to be successful.
Agile Team and Risk Analysis Workshops
An agile team should be characterized by:
- a wide range of competencies - team members possess various skills that they collectively utilize in the project,
- self-organization of work – the team decides on tasks and the order of their execution,
- a commitment to improving individual and team skills,
- a focus on delivering a high-quality product.
The heart of the process is the risk analysis workshops. During the workshops, threats that may impact the users of the product are discussed. Decisions are made during the meetings on how to address the identified threats.
When to Start the Workshops?
It is never too late to discuss digital security and assess the risks associated with the implementation of a project. The fact that one of the stages of product development has been reached, or even that the product has been made available to the first users, is not a sufficient reason to neglect security issues. However, it is best to start the risk analysis even before the implementation work begins.
How to organize workshops?
In principle, project team meetings are closed. The effectiveness of the workshops depends on the initiative of the participants themselves. There is a risk that the presence of individuals not engaged with the product will reduce effectiveness. The presence of a digital security expert is usually essential. The expert can take a leading role or solely a supportive one, sharing their knowledge as needed.
It is essential to adhere to the principles of effective communication; therefore, the workshop moderator plays an important role, who:
- ensures that all participants have an equal voice,
- ensures that the group stays on topic,
- maintains a good atmosphere,
- ensures effective use of time.
During the first workshops, the scope of the planned analysis should be defined. It is necessary to establish what the team is responsible for and exclude what is the responsibility of others. There should be no hesitation in planning the main steps that will determine the approach to digital security. During subsequent workshops, the team will conduct a detailed analysis of threats and plan an appropriate response.
Workshops should not last too long, but should be held at regular intervals. It is important to ask participants to document what has been established during the workshop (formalizing the results).
What to do after each workshop?
Formalizing the conclusions drawn is recommended to ensure continuity of work between workshops. The team can choose how to document their work, with French specialists recommending, among other things:
- using a Wiki-type page or another documentation space that is easily accessible to all team members,
- prioritizing issues, labeled as “completed” and possibly “ready.”
Updating and improving results
The results of the risk analysis should be periodically updated and improved. For example, in the following situations:
- there is a change in architecture, e.g., the addition or modification of a technical component,
- other data than those previously considered processed are disclosed (e.g., personal data, which were not identified earlier),
- there arises a need to focus on a product functionality that is particularly sensitive in terms of security,
- user feedback necessitates a different assessment of business value or security needs,
- the number of users undergoes a significant change, thereby increasing exposure to risk.
What is technical debt
Technical debt is a situation in which a team temporarily prioritizes delivering new functionality at the expense of design practices, such as refactoring, test automation, or knowledge sharing. This strategy may pay off, but it must stem from a conscious choice, rather than a lack of competence in necessary areas. The intention is to release a new version of the product more quickly and obtain feedback before "repaying" the debt at a later time.
By analogy, we can speak of "security debt" when a team is forced to postpone the elimination of certain risks in order to facilitate faster testing of the product by initial users. This strategy should also result from a conscious choice, rather than a lack of diligence in risk analysis or a lack of competence in this area.
Aspect of digital security and consideration of the product ecosystem in risk analysis
The purpose of the risk analysis is to identify critical risk scenarios and security measures that will allow for dealing with them. The outcome should be achieving a level of security that corresponds to actual challenges and needs in an agile approach.
A risk scenario is described in the form of a potential intentional abuse or accidental event that may have a detrimental impact on the company's image and even lead to customer loss:
Example:
- User action: “I am booking a ticket for a show online.”
- Intentional abuse: “A hacker prevents customers from booking tickets for the show online by flooding the server with a denial of service attack.”
- Random scenario: „The online booking service becomes unavailable due to a server software update error made by the system provider.”.
Among the risk scenarios that should be considered in the risk analysis, deliberate actions are particularly dangerous. The risk analysis should allow for the identification of specific abuse scenarios that are not covered by security measures. An analysis of five to ten abuse scenarios provides a solid foundation for this process.
A successful attack on an IT system is rarely the result of exploiting a single vulnerability. Deliberate attacks typically rely on a sequential approach that exploits several system vulnerabilities in a coordinated manner. French specialists warn against the typical, following sequence of actions by cybercriminals:
- preliminary reconnaissance - the attacker gathers information about the target by any means possible, from open sources (social networks) or closed sources (offices),
- breach - the attacker infiltrates the system, e.g., through an email with an attachment containing malware, SQL injection, or an unpatched vulnerability,
- internal reconnaissance - the attacker conducts internal reconnaissance to map the network architecture, identify existing security mechanisms, determine vulnerabilities to attack, and locate critical services, information, and components,
- privilege escalation - the attacker keeps their access secret to expand their operational capabilities within the system, e.g., by installing malicious tools,
- exploitation of the attack – the attacker utilizes their capabilities within the system, e.g., for data or identity theft, fraud, abuse, or sabotage (data deletion).
PROMOTIONAL OFFER
Protect data in projects in accordance with NIS2
Do you need support in securing agile projects? During the consultation, we will discuss your needs and help you prepare for the requirements of NIS2 with an additional discount.
According to French specialists, considering such an attack sequence model allows for easier identification of critical components that may be exploited by an attacker. These critical components can be technical, organizational, or human in nature.
A holistic view of the entire organization's ecosystem is essential. Such an ecosystem comprises a group of stakeholders who operate around a given product and are essential for that product. One should consider the answers to the following questions:
- Am I dependent on the services provided by this entity? Is this relationship critical for my business?
- To what extent does the stakeholder have access to my internal resources (my premises, my IT network)?
- Are the services and IT networks of the stakeholder exposed to threats from the Internet? Are they sufficiently secure?
- Can I assume that the stakeholder's intentions towards me are good?
Identifying threat scenarios, especially those of an intentional nature, requires some knowledge of digital security. This particularly pertains to sophisticated attacks that implement a planned sequence of methods to influence several elements—most often technical and human—of both the product and its ecosystem. For this reason, support from a digital security expert can be a factor conducive to the success of workshops, proportionate to the complexity of the product and ecosystem.
Risk Analysis – Basic Security Criteria
French specialists used the example of the Le.Taxi platform, which functions to provide information on the availability and geolocation of taxis.
The methodology is based on the following criteria, which are critical for the functioning and compliance of the organization:
- [D] availability: functionality is available on demand,
- [I] integrity: data is immutable and complete,
- [P] confidentiality: information is disclosed only to authorized persons,
- [R] accountability: data collected in the system can be used in case of a dispute.
Risk Analysis, Step 1 – User Stories and Their Needs
In the first step, it is necessary to identify the main elements of the product's functionality for the user and then estimate the associated security needs. This is done by creating so-called "user stories."
Example:
The client can place an order (virtually call a taxi), evaluate the completed trip, or report an incident.
For each user story, the weight of security needs must be established. The degree of importance of the needs can be expressed by a simple index, e.g., “important need” and “very important need.” A need designated as “very important” means that it is essential for the product.
The team begins its work from user stories with the assumption that security measures serve the value delivered to users. In fact, for each important security need related to a user story, there is at least one hazardous event and at least one risk scenario that may threaten the value of functionality.
Using the Le.Taxi platform as an example, the following user stories and their associated needs have been identified:
Risk Analysis, Step 2 – Sources of Risk
The next step is to identify sources of risk: who or what may threaten security needs. Sources of risk can be accidental or intentional, external or internal.
Example:
- A competing operator seeking to discredit or sabotage the service.
- Criminals aiming to acquire personal data for illegal purposes.
It is recommended to identify sources of risk of various natures and motivations in order to ensure a representative sample of risks, based on which scenarios with different threats and methods of action can be developed.
Examples of motivations behind intentional attacks:
- ideology, agitation, propaganda – e.g., activist hackers, cyberterrorists,
- fun – e.g., teenagers, experienced hackers,
- espionage, economic intelligence – e.g., intelligence agencies, specialized offices,
- saboteur actions, destruction – e.g., specialized units, intelligence agencies,
- fraud, profit – cybercriminals,
- malice, revenge – e.g., disgruntled employees, dishonest competitors.
Risk Analysis, Step 3 – Events of Concern and Their Impact
At this stage, potential events whose occurrence is undesirable are identified. This creates what is known as "events of concern (OZ)."
Example:
A competing carrier calls a taxi, posing as a client, resulting in an unnecessary and costly ride.
The concern about an undesirable event (OZ) arises from the failure to meet the identified security need in the user story from step 1. It is also necessary to determine the impact of the given event (on current tasks, personal, financial, legal, reputational, environmental security, etc.) and the estimated degree of its significance. The rating scale may vary, e.g., it may include three levels of significance: low, medium, high.
An event causing concern should be defined in a brief sentence that facilitates understanding of the harm associated with the user story being considered. It is recommended that the most likely source of risk that could lead to a threat be mentioned in the title of the assessment. First and foremost, it is important to identify events whose consequences would be difficult to overcome.
Using the Le.Taxi platform as an example, the following potential events and their impacts have been identified:
Risk Analysis, Step 4 – Ecosystem and Risk-Sensitive Elements
At this stage, it is necessary to identify which elements of the product:
- serve or contribute to the realization of user stories defined in step 1,
- and may become targets for the sources of risk identified in step 2.
Example:
The company's database (exploitable vulnerabilities: read/write access from the Internet, frequent modifications).
Identification of such elements can be organized in the following way:
- physical infrastructure: buildings, premises, physical spaces enabling activity and information exchange,
- organization: organizational structures, business and auxiliary processes, human resources,
- hardware and software: computer and telephone systems, telecommunications networks.
Key elements to identify are those that contribute (directly or indirectly) to the realization of user stories related to "critical" security needs.
It is also worth determining which stakeholders in the ecosystem may be exploited to facilitate an attack on a given product element. First and foremost, stakeholders of critical importance related to one of the identified elements should be considered.
Example:
An IT service provider offering remote maintenance of a database server.
Risk Analysis, Step 5 – Abuse Stories and Remedial Measures
PROMOTIONAL OFFER
Secure Projects in Your Organization
Are you wondering how to combine agile methodologies with information security? During a brief conversation, you will learn proven solutions and receive a discount on the implementation of ISO 27001.
At this stage, so-called "abuser stories" are created. For this purpose, the following are compared:
- risk sources identified in step 2,
- undesirable events defined in step 3,
- elements sensitive to risk established in step 4.
The aim is to check: how the risk source can exploit the vulnerability of the sensitive element, resulting in the feared event.
Example:
- An attacker gains access to customers' personal data by impersonating a server or exploiting an unpatched vulnerability.
- A customer maliciously gives a taxi driver a bad rating.
Each abuser story can be assessed in terms of likelihood and then criticality, in light of how severe the associated event will be.
For each abuser story, an appropriate risk management approach can be determined, i.e.: avoidance, reduction, transfer, acceptance.
If the risk requires reduction, security measures that need to be implemented should be specified. Their implementation is recorded by the team.
Risk Analysis, Step 6 – Residual Risk
Residual risk is the risk that could not be completely eliminated despite the implementation of security measures. It may be present at the design stage (the team accepted the presence of the risk) or identified at a later time (e.g., during an external audit). The team should conclude the risk analysis workshop by defining the residual risk.
This pertains to:
- abuser stories that have not been addressed (acceptance) or that have only been partially mitigated (e.g., security measures have been implemented that do not eliminate the risk),
- abuser stories that have been subject to risk transfer (such actions usually do not eliminate all negative consequences, e.g., insurance does not cover damage to reputation).
It is worthwhile to conduct a sort of consolidation of residual risks to make a current assessment of the digital product's risk level. The most significant residual risks should be identified and highlighted as priorities. A valuable aid in objectively and consistently establishing priorities for residual risks will be, for example, the use of scales of severity, likelihood, and criticality, linked to risk acceptance thresholds. The assessment made should be supplemented with any residual vulnerabilities identified during security audits.
Example of a Risk Analysis Workshop Report
Below we present a report from one of the French risk analysis workshops for the Le.Taxi service.
Step 1 – User Stories:
Step 2 – Risk Sources:
Step 3 – potential incidents and their impact:
Step 4 – system and ecosystem elements:
Step 5 - Abuse Histories:
Step 6 – residual risk:
Summary
Risk analysis in agile methodologies allows for ongoing responses to key threats at various stages of product development. The heart of this process is risk analysis workshops, during which issues are identified that need to be addressed in a manner appropriate to the development phase in which the product is located.
In the digital age, the main battleground for security is the technological domain. For this reason, legal and organizational safeguards, such as the establishment of appropriate procedures and effective training of personnel, will be insufficient. This means that the involvement of an expert in digital security will be essential. If a company does not have a sufficiently developed IT department, it should consider outsourcing options. If the company has such resources, it often turns out that external support provides effective and valuable assistance to the internal IT staff.
