Secure Software Development

1. Secure Software Development Security Operations Chapter 9 Rasool Jalili & M.S. Dousti Dept. of Computer Engineering Fall 2010

2. Security Operations • The disconnection between security and development SW development efforts that lack any sort of understanding of technical security risks. •  Need recommendations to solve this problem by bridging the gap between two disparate fields. • Approach is born out of experience in two diverse fields; SW security and information security.

3. Best practices in software security, (touchpoints) include a manageable number of simple security activities that are to be applied throughout any software development process. • Even the best development efforts can fail to take into account real-world attacks previously observed on similar application architectures. • Information security staff-- have spent years responding to attacks against real systems and thinking about the vulnerabilities that generated them. • However, few information security professionals are software developers, at least on a full-time basis, • These two communities of highly skilled technology experts exist in isolation. But, their knowledge and experience bases,, are largely complementary.

4. The issue is how information security professionals can best participate in the software development process. • Some recommendations relevant to both software developers and information security practitioners. • The idea is to describe how best to influence the complementary aspects of the two disciplines. • Requirements: Abuse Cases; • Involving infosecin abuse case development. • Many abuse case analysis efforts begin with brainstorming or "whiteboarding" sessions • Infosec people are likely to find that the software developers are unaware of many of the attack forms seen every day out beyond the network perimeter. • Do not overstate the attacks that you've seen and studied!

5. Design: Business Risk Analysis; • Info Security people? • Design: Architectural Risk Analysis; architectural risk analysis assesses the technical security coverage in an application's proposed design and links these to business impact. • For architectural risk analysis to be effective, security analysts must possess a great deal of technology knowledge covering both the application and its underlying platform, frameworks, languages, functions, libraries, and so on. • Information security can help by providing perspective to the conversation. All software has potential weaknesses, but has component X been involved in actual attacks? • Test Planning: Security Testing • Thinking like a good guy is not enough. • Donning your black hat and thinking like a bad guy is critical. • infosec professionals who are good at thinking like bad guys are the most valuable resources.

6. Implementation: Code Review • By its very nature, code review requires knowledge of code. An infosec practitioner with little experience writing and compiling software is going to be of little use during a code review. • System Testing: Penetration Testing • Need them definitely. • Fielded System: Deployment and Operations • Need them.

7. Come Together • Close cooperation with the development organization is essential to success. • If infosec is supposed as the security police. • SW security appears to be in the earliest stages of development, much as the field of information security itself was ten years or so ago.

8. End