Agile Processes in Software Engineering and Extreme Programming- P9

Agile Processesin Software Engineeringand Extreme Programming- P9:“The Program Commitee of XP 2000 invites you to participate in this meeting ofsoftware development researchers, professionals, educators, managers, and students.The conference brings together people from industry and academia to shareexperiences and ideas and to provide an archival source for important papers onflexible process-related topics.
Nội dung trích xuất từ tài liệu:
Agile Processes in Software Engineering and Extreme Programming- P9228 X. Ge et al.such as XP. Improving the security awareness of the whole project team is ob-viously important. The practice of security training is focused on improving organisational secu-rity capabilities and providing appropriate technical knowledge. In addition tosecurity professionals or experts, the human roles involved in an software projectcan be classified into: – Stakeholders, including several roles in XP: customers, coaches, trackers, and manager. They always provide the stories that form the metaphor of the development, and answer subsequent questions. – Developers, including metaphor, programmers and testers. They work from the requirements of stakeholders and security experts, with the goal of de- livering an appropriate system. The requirements of security training vary for different roles. Training forstakeholders are the more general, focusing on how to respect security policieswhen requesting new functionality, and ultimately when using the system. Devel-opers need technical training for specific system architectures, explaining built-inor add-on security mechanisms. They also need training that enables them tomodify existing mechanisms, and to design and install new mechanisms wherenecessary. System attacks rarely create security holes; they simply exploit existing ones.Unidentified security vulnerabilities are typically the result of poor software de-sign and implementation, whilst the exploitation of identified vulnerabilities isthe result of poor risk assessment. Improving the security knowledge and aware-ness of developers can mitigate these vulnerabilities and risks. However, en-hanced security awareness by project participants is not normally a sufficientsubstitute for a security lead in the development team. A security specialistbrings deep understanding of security issues and of software development, andacts as a resource for the development team. In some cases, the security specialisttakes a role of coach in the project.4 Fundamental ArchitectureSoftware security is a system-wide issue that takes into account both systemarchitecture (such as the model of access control) and concrete security mech-anisms (such as the implementations of access control). Whilst many securityvulnerabilities arise through poor implementation, significant mitigation can beachieved by a strong fundamental security architecture. The key to meeting the security requirements of a system is risk manage-ment; to manage security risk, threats must be identified early, and it mustbe possible to analyse their implications. This is facilitated by incremental de-velopment of a security-focused architecture, or high-level platform design, thatallows assessment of risks and rigorous security testing of deliverables. The secu-rity architecture captures the experiences of the similar system developments. Itprovides a basis on which to address the trade-off between security requirementsand functional user stories. Extreme Programming Security Practices 229 The practice of creating the fundamental architecture is not incompatible withthe spirit of XP (see [7]), and related XP values, especially simplicity. [6] showsthat a security architecture can be constructed incrementally, and demonstratesthat the practice of constructing a security architecture itself is agile too. Several artifacts and tasks can help to create a fundamental architecture: 1. Architectural risk analysis. The central activity of architectural risk analysis is to build up a consistent view of the target software system at a reasonably high level. The most appropriate level for this description is the typical “white board” view of boxes and arrows describing the interaction of various critical components of software system. 2. Practical security handbooks on software systems, such as [12], and program- ming languages, such as [9], which either implicitly or explicitly document security best-practice. 3. Experience and knowledge of other software projects. These are not always formally documented but they are transmitted to every participant in the project by security training. The practice of fundamental architecture is also supported by recognised secu-rity tactics, such as defence in depth and fail securely. To conform to XP values,the fundamental architecture should be as simple as possible, e.g., a basic outlinefor the first release, with new features incrementally added in later iterations.5 ConclusionProven principles and practices for building secure software build on hundredsof years of security experience in a variety of situations, from military defenceto software engineering. In addressing the need for seamless integration with agile practices, we anal-ysed common elements of ...