1. By Ramesh Mannava

2.  Overview  Introduction  10 secure software engineering topics  Agile development with security development activities  Conclusion

3.  Describing the development of secure software systems.  It is well known that bugs in early phases cost 10 to 200 times less than after deployment.  This presentation shows how to incorporate security throughout the software development lifecycle.  Industrial experience is used to identify how can mature engineering process are combined with agile projects.  How can we combine them in order to provide a benefit to agile projects.

4.  Most security issues in software systems result from flaws in the code or design of software system.  CERT reported over 5000 software vulnerabilities in 2005.  These flaws are the result of inadequate consideration of security during requirements analysis, design, implementation, and testing of software systems.  Production of trustworthy software has become an issue.  The need for trustworthy systems result from the growth in complexity and connectivity of modern software systems.

5.  Trustworthy software relies on the education of computer scientists and software engineers.  Most threats to our software are with anti-virus software on the host, with firewalls and intrusions prevention systems.  Agile software development has been used by industry to create a more flexible and lean software development process.

6. A Course is designed which covers the following ten topics of secure SE  What is Software Security  Threats and Vulnerabilities  Risk Management  Security Requirements  Secure Design Principles and Patterns  Secure Programming: Data validation  Secure Programming: Using Cryptography Securely  Code Reviews and Static Analysis  Security Testing  Creating a Software Security Program

7.  Focus is on how security vulnerabilities arise from poor software engineering practices.  Both coding bugs and architectural flaws introduced as sources of software vulnerabilities Expected outcome:  Clear understanding of the need for software security and how software security is different from security features like access control or cryptography.

8.  Case studies of software security exploits were studied.  By this, the nature of threats and vulnerabilities could be understood.  The case studies were selected mostly from web applications.  Attack patterns were studied, which describe general methods attackers use to exploit software vulnerabilities. Expected outcome:  Understand common threats to web applications and common vulnerabilities written by developers.

9.  Security needs to be understood in terms of risk management.  It is impossible to eliminate all risks, risks evolve with time.  Data flow diagrams are constructed to describe architecture of application and to document trust levels and system boundaries  These diagrams show potential entry points into the application Expected outcome:  Create a risk model of a web application, ranking and detailing the risks to the system’s assets.

10.  Security requirements are based on the risk model for the application.  Security requirements describe what software should not do.  Attackers frequently do what the application designers assume that users never do in order to compromise an application.  In order to understand their assumptions in designing a system, system architects need to think like an attacker. Expected outcome:  Construct, document, and analyze security requirements with abuse cases and constraints.

11.  Eight principles for design and implementation of security mechanisms are developed[3].  These principles help developers to design systems that are less likely to be compromised and that mitigate the effect of compromises that do happen.  Cover secure design patterns such as Encrypted Storage and Trust Partitioning. Expected outcome:  Apply secure design principles to the design of a web application.

12.  All exploits arise from some type of input produced by an adversary.  Many of these flaws could be eliminated via accurate and precise input validation.  Whitelist approach is used to input validation. Expected output:  Validate both the input and output of a web application.

13.  A number of security vulnerabilities have resulted from improper use of cryptography.  Often from using poor sources of randomness or from a failure to properly use a complex cryptographic API.  This topic explains how to select proper encryption algorithms for higher quality. Expected outcome:  Use cryptography appropriately, including SSL and certificate management.

14.  Code reviews are an essential part of the security effort, providing an early opportunity to find and fix security bugs.  Code reviews are also a method of teaching developers about security vulnerabilities and secure coding practices.  Bugs discovered in code reviews and testing are tend to be different.  Making it essential to both review and test code for security bugs. Expected outcome:  Participate in a code review focused on finding security bugs using static analysis tools.

15.  Security testing is substantially different from functional testing.  Most security defects aren’t found in security features like authentication or access control.  Instead, most security bugs are accidental disfeatures.  Security testing efforts were focused on verifying that the web application successfully mitigates the threats documented in their risk model. Expected outcome:  Create a test plan and conduct thorough testing of web applications with appropriate software assistance.

16.  Focuses on how to build awareness of software security issues for organizations that are not using any software security practices.  It also addresses the problem of introducing new software security practices into an organization.  Which acknowledges the problem of software security. Expected outcome:  Integrate trustworthy development practices into an existing software development lifecycle.

17.  Combining the most compatible and beneficial activities, shown in the picture, with an Agile process.  This create an Agile security process that implements the most cost effective benefits from the three SE process.

18. The three security engineering processes are:  Cigatel’s Touchpoints  Microsoft SDL  Common Criteria  To better integrate the SE activities, move them from their recommended phase and place them with the development team.  The activity can be performed during a work package.  For example, Abuse Cases are moved to the design phase and the coding developers should write them instead of the requirement engineers.

19.  In the release phase, Repository Improvement fits very well with the retrospective meeting that development team performs at the end of a work sprint.  Integrating these two activities is made easier by moving them to a more developer heavy phase.  During requirement analysis, the security enhanced Agile process primary focus is: To write specific requirements for security goals. These will aid both programmers and testers to know what goals are required and need verification.  Having better security specified user stories makes it easier to write, design safe software.  The main focus for the improvements are with the developers teams and their work sprints.

20.  Ten topics are described to teach developers to design secure software systems.  Agile security process is described.  In future, these proposed security processes will be integrated in practical experiments with the existing development process.

21. [1] Baca, D., Carlsson, B., Agile Development with Security Engineering Activities, Waikiki, Honolulu, HI, USA, May 21–28, 2011, pages 149-158. [2] Luckey, M., Baumann, A., Fernandez, D., Wagner, S., Reusing Security Requirements Using an Extended Quality Model, Cape Town, South Africa, May 2, 2010, pages 1-7. [3]Salzer, J. and Schroeder, M., “The Protection of Information in Computer Systems,” Proceedings of the IEEE 63 (9), pp. 1278-1308 (Sep, 1975). [4] Walden, J., Frank, C., Secure Software Engineering Teaching Modules, Kennesaw, USA, September 22-23, 2006, pages 19-23.