SecurityRequirementsEngineering

Security is a blind spot in application development. It is typically retrofitted by security professionals tweaking the infrastructure. However, as the network continues to penetrate deeper into homes and professional systems alike, and the voracious appetite for application integration punches more and more holes through traditional, network-based defenses, this approach is faltering. Today's applications must be developed with security in mind.

In so far as agile teams succeed in writing fewer bugs, their software scores better w.r.t. security as there are fewer incidences of unexpected behavior for attackers to exploit. On the other hand, agile processes by themselves will not guarantee security requirements. This session is one of 3 that explores the principles and techniques developed in the security community and investigates whether and how they can be integrated into an agile process. This session focuses on engineering application security requirements.

Security's defining feature is the historical and continued standoff between defenders and attackers. No system is ever completely impervious to attack. Attackers invariably respond with novel attacks as engineers improve protection measures. A system that is considered secure is in a state of unstable equilibrium; its ability to fend off attacks ceases as its environment changes, whether through technological breakthrough or by an increase in motivation or resources. To remain secure, the system must change as the environment changes, preferably anticipating changes, certainly embracing attackers' progress. These observations would suggest that the demands of security engineering fit well with the agile mindset.

This and its 2 sister sessions, Secure Design and Architecture and Security Risk Analysis, are simulations. Participants are not only asked to play the role of members of a project team, but also those of attacker, customer or other stakeholders; it is essential to be able to transport into the mindset of the attacker.

Case study (15min)

The customer is an extremely well-funded startup called Big Wheel Fortunes. They have comissioned a green-field development to implement the following user stories:

• buying chits: chits are staked when gambling. So, before gambling, a user must own chits. Winnings are also paid in chits.
• redeeming chits.
• registering payments: this is a covert user story, unavailable for all but those customers of Big Wheel Fortunes who have negotiated a special arrangement. Payments increase users' credit with Big Wheel. This user story plays as a preliminary to laundering. In this story, the user does not interact with the system directly; trusted parties do so on behalf of the customer. The assignment requires the system contractor to designate the trusted party and design the interaction.
• gambling: this user story is the ostensible core of the system. Users bet one or more of their chits. Whether or not the user wins is determined by a stochastic process with a given distribution. The increment to a winning user's chit count is calculated by rounding down the product of the stake and the odds.
• laundering: this is the true core of the system. Users who have registered payments may enter into interactions that are ostensibly the same as in the gambling user story. However, while the user's credit has not run out, wins are guaranteed. Each time a win occurs, the users' credit is decremented by the amount of the win. The system must guarantee that credits never fall below zero.

Requirements analysis (1h)

This part of the session produces a set of abuser stories weighted with the costs of absorbing risk. Abuser stories are like user stories. While user stories tell about legitimate uses of the system, abuser stories tell of how a system may be abused. Development aims to implement the former and avoid the latter.

Like user stories, abuser stories can be used in planning. While the implementation of user stories bring business value to the system, the refutation of abuser stories brings risk reduction. Risk can, at least in theory, be quantified as a cost and can, therefore, be rationally traded against business value when drawing up development priorities.

Writing the abuser stories involve the following steps:

• identify the assets that need to be protected (10min),
• identify potential attackers the system needs protection from (15min),
• write abuser stories (20min),
• quantify the risk presented by the respective abuser stories (15min).

Assets

The system under development aims to make money for the customer. This money-making ability is clearly an asset. However, such description is too vague for risk assessment; we need to be more precise. We should also identify the required security guarantee for any given asset. For example, if you get paid for consultancy, do you want the amount to be kept secret (confidentiality) because you do not want to divulge your rates to a competitor? Presumably your customer would be rather upset if you could change the amount he is paying you (integrity). It would be equally upsetting if you could deny that you received the money and demand a second payment. Maybe you would like to dodge taxes and leave no trace of payment at all. The list goes on.

Attacker profiles

Pertinent information in attacker profiles includes motivation, skill, risk adversity, resources and determination.

Abuser stories

During this part of the workshop, subgroups are formed and assigned attacker roles. The subgroups describe what assets they would target and how they would abuse them.

Risk assessment

Risk assessment is an activity that is pervasive throughout the process of secure application development. During requirements engineering, risks should be quantified for planning purposes.

TBC

Evaluation (15min)

In the final part of the workshop, requirements analysis practices are reviewed and evaluated.