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:
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:
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.
Pertinent information in attacker profiles includes motivation, skill, risk adversity, resources and determination.
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 is an activity that is pervasive throughout the process of secure application development. During requirements engineering, risks should be quantified for planning purposes.
In the final part of the workshop, requirements analysis practices are reviewed and evaluated.
|Changed on 28/04/2005 by webcache-kotnet-1.kuleuven.ac.be||Contact the site administrator: agileopen|