Summit on Education in Secure Software Final Report

Transcription

1 Summit on Education in Secure Software Final Report Dr. Diana L. Burley The George Washington University Dr. Matt Bishop University of California, Davis GW: UCD: Report GW-CSPRI Technical Report CSE Support for this work was provided through the National Science Foundation Directorate for Computer & Information Science & Engineering and the Directorate for Education & Human Resources under Award # Opinions expressed, conclusions drawn, and recommendations provided do not necessarily reflect the views of the National Science Foundation. June 30, 2011

2

3 Summit in Secure Education: Final Report Table of Contents Executive Summary...1 Summit on Education in Secure Software...5 Background...5 Summit on Education in Secure Software...6 SESS Objectives...6 SESS Teleconference...7 Secure Programming Education: Requirements and Challenges...7 Summary of Requirements...7 Details of Requirements...8 Summary of Challenges...9 Details of Challenges...10 The Roadmaps (and Potholes)...11 The Roadmaps...12 Computer Science Students...13 Non-Computer Science Students...17 Community College Students...21 K-12 Students...24 Computer Science Professionals...27 Non-Computer Science Professionals...30 The Role of Higher Education...34 Licensure and Certification...35 Conclusion...37 Appendix A Summit Overview...41 Appendix B Organizing Discussion Questions...46 Appendix C Summit Agenda...47 Appendix D Participant List...49 Appendix E Licensure/Certification Presentation Summary...52 About the Authors...58

4

5 Summit on Education in Secure Software Final Report Dr. Diana L. Burley and Dr. Matt Bishop Executive Summary Cybersecurity risks pose some of the most serious economic and national security challenges of the 21st century. In order to meet these challenges, the software that controls critical systems and infrastructure must be reliable, robust, and able to satisfy the requirements that are placed upon it. To this end, all people involved in the development and deployment of these systems and infrastructure, from the policymakers who determine what requirements the systems must meet to the businesspeople who provide the support needed to create the systems to the architects, implementers, and operators of these systems, must understand the criticality of reliable, robust, and secure software to control these systems. The notion of trustworthy computing embodies many more facets of computing than software implementation, but poorly implemented software undermines all other aspects of trustworthy computing. Thus, a curriculum designed to meet the cybersecurity challenges of the future must integrate principles and practices of secure programming. Because of the breadth of people who will influence the creation and deployment of this software, students studying a variety of technical and non-technical disciplines must recognize the difference between software that is sufficiently robust and software that is not. To determine how best to address this need, the National Science Foundation Directorates of Computer and Information Science and Engineering (CISE) and Education and Human Resources (EHR) jointly sponsored the Summit on Education in Secure Software (SESS). The summit focused on how best to educate students and current professionals on secure programming concepts and practices, and to provide roadmaps indicating both the resources required and the problems that had to be overcome. Organized by The George Washington University and the University of California at Davis, the summit began with a teleconference on September 7, 2010 and continued with a two-day workshop in Washington, DC on October 18 and 19, SESS participants included members of academia, government, industry, professional organizations, and policy makers from both the public and private sectors. This multi-disciplinary group provided depth to identify technical challenges and breadth to identify operational constraints and opportunities. This enabled the summit participants to examine ways to advance and improve the state of education in secure software. The goal of SESS was to develop a comprehensive agenda focused on the challenges of secure software education. To meet this goal, SESS had three specific objectives. 1. To have cybersecurity stakeholders from academia, government, industry, and certification and training institutions discuss the goals of teaching secure programming and the current state of that teaching; 2. To use that discussion as the basis of a collaborative effort to suggest new approaches, and improve existing approaches, to improve the quality of that education and to enable it to reach a broader audience; and 3. To outline a comprehensive agenda for secure software education that includes objectives for different audiences, teaching methods, resources needed, and problems that are foreseen to arise. Summit on Education and Secure Software Final Report 1

6 Summary of the Findings The findings are presented in the form of road maps for constituent groups that describe ways to improve the state of education in secure programming. The road maps explain what the members of the constituent group should know, various methods by which they might be educated, and what resources will be necessary to achieve that level of education. The road maps also identify expected and possible challenges to meeting these goals the potholes. Each roadmap concludes with specific recommendations for meeting the articulated educational goals. Although presented as separate road maps, one for each constituent audience (computer science students; non-computer science students; community college students; K-12 students; computer science professionals; and non-computer science professionals), the roadmaps should be considered as different views of a unified educational program that spans kindergarten through professional development, and audiences ranging from software developers to those who focus on management, policy and use to ordinary computer users. Thus, the educational goals in the road maps should be considered the core fundamental end points to be reached through instruction guided by a secure programming curriculum. Overall, SESS participants asserted that secure programming must be considered within the context of the system design and deployment process. They highlighted 6 critical points that students of secure programming should know: 1. Understanding security, especially during design, requires a holistic approach; 2. Understanding and being able to identify common and emerging attack vectors is a critical component of security; 3. Well-tested principles and frameworks of software development can inhibit attacks; 4. All frameworks have weaknesses and subtleties; 5. Part of secure programming is using strategic approaches to overcome these weaknesses; and 6. Users of tools that aid in secure programming must know how to use those tools, and understand their limitations. Summary of the Recommendations Several themes emerged from the recommendations of the individual roadmaps. The ten recommendations below provide a starting point for stakeholders across constituent groups to begin to transform education in secure software. 1. Increase the number of faculty who understand the importance of secure programming principles, and will require students to practice them. 2. Provide faculty support for the inclusion of security content in existing courses through clinics, labs, and other curricular resources. 3. Establish professional development opportunities for college faculty, non-computer science professionals, and K-12 educators to heighten their awareness and understanding of secure programming principles. 4. Integrate computer security content into existing technical (e.g. programming) and nontechnical (e.g. English) courses to reach students across a variety of disciplines. Summit on Education and Secure Software Final Report 2

7 5. Require at least one computer security course for all college students: a. For CS students focus on technical topics such as how to apply the principles of secure design to a variety of applications. b. For non-cs students focus on raising awareness of basic ideas of computer security. 6. Encourage partnerships and collaborative curriculum development that leverages industry and government needs, resources, and tools. 7. Promote collaborative problem solving and solution sharing across organizational (e.g. corporate) boundaries. 8. Use innovative teaching methods to strengthen the foundation of computer security knowledge across a variety of student constituencies. 9. Develop metrics to assess progress toward meeting the educational goals specified in the roadmaps presented in this document. 10. Highlight the role that computer security professionals should play in key business decision-making processes. Conclusion A holistic view of secure software education suggests that programmers and non-programmers alike must be educated in the core principles and practices of secure software design. A paradigmatic shift that adjusts the current emphasis from students as customers to society as customers will support holistic and comprehensive curricular reform. In order to achieve this level of transformation in the underlying educational system, SESS participants identified several structural enablers that must be considered. Although not explored in detailed during this event, we suggest that topics such as: the cultural shift among faculty and industry stakeholders that supports the development of a holistic view of software security; the identification of measurable objectives and corresponding measurement methods; the development of national licensure programs; and the alignment of expectations for university education and realistic constraints in the system; should be the focus of follow-up efforts. Summit on Education and Secure Software Final Report 3

8 Summit on Education and Secure Software Final Report 4

9 Summit on Education in Secure Software We... [have a] desperate shortage of people who can design secure systems, write safe computer code, and create the ever more sophisticated tools needed to prevent, detect, mitigate and reconstitute from damage due to system failures and malicious acts. 1 The term secure programming is a misnomer. By rights, it should refer to programming designed to satisfy a specified security policy the definition of secure, after all, is satisfying a security policy. 2 But the term is used more broadly to refer to programming designed to prevent problems that might cause security breaches. This style of programming deals with common programming errors (such as failing to check that the size of an input is no greater than the size of where it is to be stored), and should more properly be called robust programming. 3 Taking this more comprehensive view of secure programming, the Summit on Education in Secure Software (SESS) examined the questions of what should be taught in our nation's educational programs about secure programming to various constituencies of students, and what would be required to do so. The constituencies of students include computer science students, programmers, and non-technical students at the levels of post-secondary education, and secondary education. This report provides the background for the workshop, the workshop's goals, its organization, and key findings. Background President Obama has stated that recruiting and retaining cybersecurity professionals is a national security priority. 4 Almost every facet of society relies upon computer systems and infrastructure; indeed, that infrastructure provides critical support for the global economy, civil infrastructure such as power grids and other mechanisms for distributing utilities, and public safety. This led Mr. Obama to assert that cybersecurity risks pose some of the most serious economic and national security challenges of the 21st century. 5 In order to meet these challenges, the software that controls these systems and infrastructure must be reliable, robust, and able to satisfy the requirements that are placed upon it. To this end, all people involved in the development and deployment of these systems and infrastructure, from the policymakers who determine what requirements the systems must meet to the businesspeople who provide the support needed to create the systems to the architects of the systems to their implementers, operators, and support personnel, must understand something about what constitutes software that will control these systems. The notion of trustworthy computing embodies many more facets of computing than software implementation, but poorly implemented software undermines other aspects of trustworthy computing. 1 K. Evans and F. Reeder. A Human Capital Crisis in Cybersecurity. Center for Strategic and International Studies. Washington, DC (2010). MA (2003) p See, for example, M. Bishop, Computer Security: Art and Science, Addison-Wesley Professional. Boston, 3 Throughout the rest of this document, we use secure to conform to the more common usage. We are, however, speaking of teaching robust coding to anticipate and avoid problems (which we may not yet know about) brought on by fragile (non-robust) programming Cyberspace Policy Review: Assuring a Trusted & Resilient Information & Communication Infrastructure: 5 Ibid Summit on Education and Secure Software Final Report 5

10 Thus, principles of secure programming must be integrated into a curriculum designed to meet the cyber security challenges of the future. Because of the breadth of people who will affect, or be affected by, software, understanding the difference between software that is sufficiently robust to avoid common programming errors and software that is not robust is critical to a variety of disciplines, both technical and non-technical. The most appropriate method for teaching this material, and more importantly what resources are necessary to teach it, has not been well explored. Summit on Education in Secure Software In response to this challenge, the National Science Foundation Directorates of Computer and Information Science and Engineering (CISE) and Education and Human Resources (EHR) jointly sponsored the Summit on Education in Secure Software. The focus of the summit was on how best to educate both students and current professionals on secure programming concepts and practices, and to provide roadmaps indicating both the resources required and the problems that had to be overcome. Organized by The George Washington University and the University of California at Davis, the summit began with a teleconference on September 7, 2010 and continued with a two-day event held in Washington, DC on October 18 and 19, The SESS overview document is included as Appendix A, the organizing questions are given in Appendix B, and the agenda is presented in Appendix C. SESS participants included representatives from academia and professional organizations across the public and private sectors as well as policy makers and government representatives. This multidisciplinary group brought the needed depth (to identify technical challenges) and breadth (to identify operational constraints and opportunities) to enable the summit to find ways to advance and improve the current state of education in secure software. Appendix D lists the participants in the SESS. SESS Objectives The high-level goal of the SESS was to develop a comprehensive agenda focused on the challenges of secure software education. This challenge arises within the context of student education and professional development and training, and is aggravated by curricular and faculty constraints. Additionally, the need to measure attainment in a meaningful, useful way complicates the problem. The SESS had three objectives: 1. To have cyber security stakeholders from academia, government, industry, and certification and training institutions discuss the goals of teaching secure programming and the current state of that teaching; 2. To use that discussion as the basis of a collaborative effort to develop new approaches, and improve existing approaches, to improve the quality of that education and to enable it to reach a broader audience; and 3. To outline a comprehensive agenda for secure software education that includes methods, resources needed, and problems that are foreseen to arise. To achieve these objectives, the summit combined activities designed to gather, synthesize, and disseminate insights that enhance the education of students in secure software. A key consideration was capturing what the implementation of those plans would require. We began by posing a set of organizing discussion questions (shown in Appendix A), and asking participants to discuss them using a social networking website before the preliminary teleconference and the actual summit meeting. Summit on Education and Secure Software Final Report 6

11 SESS Teleconference Before the summit meeting in Washington DC, invitees participated in a teleconference. This began as a plenum session, and then the group split into three small discussion groups, one each focusing on academia, industry, and government and others. The goal was to develop a preliminary view of the requirements and challenges of teaching secure programming from the perspectives of each of the three groups. The requirements and challenges are discussed in the next section. A common, key theme emerging from the discussions is that any successful approach to teaching secure programming will have to address concerns within and among the sectors. Secure Programming Education: Requirements and Challenges This section of the report provides summaries and detailed listings of the requirements and challenges (see Tables 1 and 2). The members of the groups identified some requirements and challenges critical, and in some cases multiple groups identified the same requirements and challenges. These are highlighted (bold, underlined) in each table. The requirements and challenges were used to seed the development of the roadmaps. Summary of Requirements Distinct themes emerged from the group discussions. The academic and industry groups emphasized the importance of educating students about why robust, secure code is critical to security, and (where appropriate) about how to write secure code. They also pointed out the need to be able to critique code, to identify non-robust practices and security vulnerabilities in both other people's and their own code. This includes knowing how to test code. Industry participants focused on peer review as an important element of analysis, and academic participants focused on teaching approaches and frameworks that would provide the tools to do the analysis. Government participants presented the need to recognize the possible security problems of foreign code and the consequences that might result from the integration of code drawn from multiple sources. All groups noted that secure programming must be considered within the context of the full system design and deployment process. The requirements discussion highlighted 6 critical points that students of secure programming should know: 1. Understanding security, especially during design, requires a holistic approach; 2. Understanding and being able to identify common and emerging attack vectors is a critical component of security; 3. Well-tested principles and frameworks of software development can inhibit attacks; 4. All frameworks have weaknesses and subtleties; 5. Part of secure programming is using strategic approaches to overcome these weaknesses; and 6. Users of tools that enhance secure programming must know how to use those tools, and understand their limitations. Summit on Education and Secure Software Final Report 7

12 Details of Requirements Table 1 shows the requirements for secure programming based on the perspectives of each sector, and highlights the requirements that cross multiple sectors. Identified Requirements for Secure Academic Industry Government Programming Education Importance of writing secure, robust programs X X X Security is not just about coding it is the entire design and deployment process. X X X Understand that code is international, and that your code may interact with foreign code in unanticipated ways. Common attack vectors, and perpetual emergence of new vectors. Know, and be committed to using best practices, at all times. Well-tested principles and frameworks for creating secure programs. Edge cases and how to test for them. The importance of peer review. Weaknesses and subtleties in the frameworks and approaches to overcoming them. The cost of finding bugs and security flaws at various stages of the design process and after deployment. How to use tools to test their designs. The security vulnerabilities of specific computer languages. Understand what exploits are being used, and how to defend against them. X X X X X X X X X X X X Table 1: Requirements for Secure Programming Education Identified by Sector Summit on Education and Secure Software Final Report 8

13 Summary of Challenges The challenges to teaching secure programming for each of the groups proved quite different. The academic participants focused on the challenges related to faculty. Developing faculty skills in security, especially secure programming, and understanding the significance of secure programming is particularly important. Once these skills are developed, the next challenge is to identify effective methods for those faculty members to maintain a current knowledge-base, and to ensure that they learn accurate, realistic and timely scenarios, and are able to communicate them to students. Industry participants expounded the need to convey the criticality of data integrity and migration strategies. Like the academic participants, they felt that ensuring faculty taught, and students saw, accurate, realistic scenarios, was critical to learning secure programming. Government (and other) participants highlighted the challenges of understanding the risks associated with highly interconnected systems. Among the complications were connections across sector boundaries, national boundaries, and cultural boundaries. A second, equally important, challenge is mitigating those risks. These challenges were consistent with the requirements that emerged from the government (and other) groups. Summit on Education and Secure Software Final Report 9

14 Details of Challenges Table 2 shows the challenges for secure programming based on the perspectives of each sector, and highlights the challenges that cross multiple sectors. Identified Challenges for Secure Programming Education Developing faculty skills in security, especially secure programming, and understanding the importance of secure programming. Teaching materials that are suitable and continuously up-to-date. Aligning concepts with student abilities. Finding room (and proper placement) in the curriculum for security topics. Academic Industry Government X X X X X X X Organizing secure coding rules into a coherent framework. X X Licensing and NDA restrictions. X X Helping individuals understand the threats posed by the Internet and interconnected systems. X X Conveying accurate information about the threat environment; including accurate simulations of attack-defend incidents. Designing systems with the concept of least privilege in mind. Assisting with sensible & informed risk management decisions in light of interconnected systems. Researching and testing best practice tools and techniques. Ensuring that mitigation strategies are incorporated in the design process. Ensuring sufficient system tests and evaluations before deployment. X X X X X X Table 2: Challenges for Secure Programming Education Identified by Sector Summit on Education and Secure Software Final Report 10

15 The Roadmaps (and Potholes) A goal of the summit was to develop road maps that describe ways to improve the state of education in secure programming. The road maps explain what the students should know, various methods by which they might be educated, and what resources will be necessary to achieve that level of education. The road maps also identify expected and possible challenges to meeting these goals the potholes. The summit used small working group sessions and plenary discussions to achieve this end. The first day began with a plenary session with presentations from an academic (Matt Bishop, University of California at Davis), a non-government practitioner (Alan Paller, SANS), and a government practitioner (Dickie George, National Security Agency). At lunch, the participants heard about models of education from the medical and legal professions. Then the workshop separated into three groups corresponding to the ones in the teleconference, and discussed how to improve the state of education in secure programming. At dinner, deans from several schools addressed the topic of the role of higher education. On the second day, a professor of education (Melissa Dark, Associate Dean of the Purdue University College of Technology) addressed the group, discussing how to design a curriculum for secure programming. The workshop then split into numerous subgroups, focusing on the intended audiences for the education: computer science students, non-computer science students, community college students, K- 12 students, computer science professionals, and non-computer science professionals. The day concluded with an afternoon plenary in which plans for developing a comprehensive agenda were discussed. Although presented as separate guides, one for each constituent audience, the road maps should be considered as different views of a unified educational program that spans kindergarten through professional development, and audiences ranging from software developers to those who focus on management, policy and use to ordinary computer users. Thus, the educational goals in the road maps should be considered the core fundamental end points to be reached through instruction guided by a secure programming curriculum. Professor Dark eloquently argued that educational goals must consider both curriculum (what you teach) and instruction (how you teach). Curriculum identifies the desired results of the education, as well as suggesting specific evidence to determine whether those results are met, and planning how to teach the students to ensure they reach those results. According to Prof. Dark, the development of educational goals should take into account Bloom s Taxonomy of Learning, which posits three interrelated dimensions of learning (e.g. cognitive, affective, and psychomotor). This complex learning process requires interdisciplinary assessment tools. For example, the Forced Concept Inventory (FCI), a mechanism commonly used in disciplines such as English, can reveal declarative, conceptual, procedural, principle, and problem solving skills. As such, it allows us to know what the students know and can help us understand student needs in a holistic way. Using this approach to design and implement a secure programming education that effectively engages the minds, experiences, and education of novices and experts, can help identify student needs, and match them to appropriate teaching methods and educational venues. Summit on Education and Secure Software Final Report 11

16 Box 1. Building a Securing Programming System Melissa Dark, Associate Dean, College of Technology, Purdue University Educational goals must consider both curriculum (what you teach) and instruction (how you teach). Curriculum provides the opportunity to identify desired results, which help determine acceptable evidence, and plan the learning experience. This approach to building a securing programming system, that more effectively separates the minds, experiences, and education of novices and experts, can aid in the identification and matching of student needs to appropriate teaching methods and educational venues. The Road Maps The remainder of this report contains the road maps developed by the workshop participants for each of the constituent groups. The road maps are the collective response to the first two organizing questions: What should be taught? What resources are required to properly teach these concepts? They are presented in the following order: Computer science students; Non-computer science students; Community college students; K-12 students; Computer science professionals; and Non-computer science professionals. All activities, whether related to faculty development or curricular additions, will require money. The report does not specify how much money is required because this will depend upon the precise plans developed, the institutions and people involved in the execution of the plans, and a host of other factors. So, readers should take this as a given. The roadmaps discuss non-financial resources that meeting the educational goals will require. The potholes are the challenges associated with teaching the concepts and acquiring the necessary resources. Each roadmap begins by defining the constituent group. It then presents the educational goals, required resources and associated potholes. Each roadmap ends with a recommendation for action. Individually, the roadmaps provide specific guides for each constituent group. Collectively, they provide a series of recommended steps to develop a system of secure software education that addresses both overlapping and divergent needs of the constituent groups. Summit on Education and Secure Software Final Report 12

17 The Roadmap: Computer Science Students Who are they? Summit participants defined computer science students as all students majoring in computer science or computer engineering. The Roadmap All computer science majors require students to know how to program. The ideas developed by the participants of this group build upon that observation. All students should understand the very basics of security, for example being able to discuss the meaning of confidentiality, integrity, availability, privacy, separation of duties, layering of security mechanisms (also called defense in depth, and the idea of least privilege, even if their primary focus is not systems or software. A general-purpose computer security course is an appropriate way to cover this material. Opinions differed on whether the course should be in the first two or last two undergraduate years. All students should understand the role of security in design as well as implementation. This includes common patterns used to improve security. As was noted in the working group, this is really just good design. Part of this, is understanding what can happen if one does not apply the tools and techniques to identify and resolve potential problems. This also should be discussed, including not only technical issues such as corruption of data and resources but also the non-technical, and often intangible, consequences such as loss of money, customer trust, and damage to reputation. The material the students learn should be grounded in problems and practices found in industry and government. In particular, the security issues raised should reflect the real world as well as teach principles. Usability is a part of this, because security problems often arise when systems and programs are so complex that users, and more importantly system administrators who install and configure these, make mistakes that open the system, site, and organization to attack. The security lessons need to be integrated into courses that are not primarily security-related. For example, in software engineering courses, security could be framed as a necessary component of software quality. In this way, raising the security implications arising from decisions at each stage of the life cycle would make the students more aware of and sensitive to security considerations. In particular, the various aspects of input validation, the inadequacy of which is currently a critical problem, could be integrated into all courses that require programming. Most computer science textbooks ignore problems of security, or mention them in passing; they do not explicitly include security considerations in design or implementation. Such considerations should at least be mentioned in design; examples of code should embody these principles in practice. One way to do this would be to work with textbook authors to ensure that the example programs and system designs include security considerations, including the application of secure programming techniques. An alternative is to develop supplements to widely used textbooks that expand upon the application of security principles to the subject matter in the textbook, in a way that integrates with the textbook. More general supplementary lab books could achieve the same effect, but the instructor would have to integrate the material into the course curriculum rather than treating it as simply a part of the text. Students need to be able to assess existing programs and systems, and be able to work with other people s code. For example, most academic programs are relatively small, and students write them either alone or in small groups. But non-academic projects are typically large and complex, and teams of Summit on Education and Secure Software Final Report 13

18 programmers work together to develop them. This means that programmers spend much of their time reading and modifying other people's code. Because of the security implications of making such changes and integrating back into the code base, students should know how to analyze existing code as well as develop secure code. To support their learning how to assess programs, students should have resources available to assess their own programs. Tools and other technologies will help meet this need. Source code review tools and testing tools will cover the back end, but at the front, the use of languages and integrated development environments (IDEs) that restrict the ability of the programmer/student to create non-secure programming constructs is also helpful. Care must be used, though, because requiring students to use a programming language designed for security in all classes will severely impact their ability to use the languages that are common in industry. The problem is not merely that they will be inexperienced in those languages. More importantly, they will not know how to write secure code in those languages because the language and IDEs they use will not require them to apply the principles of secure programming on their own, and thus inhibit their familiarity with the practice of those principles. Perhaps more valuable than tools is human assessment--someone who can review programs and point out examples of (potential) problems, so the student can then learn how to do so themselves. From such interactions, the student will learn how to do assessments the practice rather than the theory (which can be taught in regular classes). The idea of a secure programming clinic, which would function much as a writing clinic and writing support systems do in law schools and other departments, was discussed, but concerns were raised about its scalability. One way to force this upon students is to give students (or teams of students) an assignment, and later in the term require them to extend the programs. However, for the extension, each student (or team) is given another student s (team s) program, or a poorly written, uncommented program from a standard repository. This very quickly teaches students the need to write good, clear code and as a side benefit, it also encourages good documentation. Concerns focused on teaching secure programming. Participants noted that graduate students would be needed, both to work with students in doing assessments and to grade assignments (in their roles as teaching assistants). Unfortunately, the participants felt that few graduate students have the skills and experience in secure programming to do this. Worse, many faculty either do not have the skills, or do not believe that students need to continuously use secure programming techniques (because they are ancillary to the material in that particular course), or both. Participants agreed that a major problem is to raise awareness of the need to know something about security in general and secure programming in particular. One suggestion was that those who are trying to hire graduating students (and interns) should put in their job descriptions a statement of what the job requires with respect to security, such as a basic knowledge of it or the ability to apply the principles of secure programming when writing and/or analyzing code. This would be something industry and government could do to make faculty in particular and academia in general believe that security, and knowing how to write secure programs, is important. Summary Educational Goals Students should understand the basics of security Students should understand the role of security in design as well as implementation. Summit on Education and Secure Software Final Report 14

19 Students should know about security issues, problems, and methods currently used in industry and government, and how those expand upon basic security principles. Students should understand the basics of usability, especially how a failure to take into account the user when designing interfaces can create or exacerbate security problems. Students should be able to assess code written by others. Students should have experience working on large projects, and in particular gain experience in using a source code control system. Students should be able to identify and question assumptions that relate to security, especially when those assumptions affect coding style and program structure and implementation. This will teach them how to think like an attacker. Teaching Methods All students should take a general-purpose computer security course that covers the basic ideas and principles of security. Classes should teach good program design in the particular area of the class. This also includes the principles and practice of secure programming. Use real world examples to teach the importance of, and the need for, practicing secure programming techniques. Create a repository of fragile, uncommented, non-secure programs and modules for use in exercises teaching students how to analyze, and how to harden, existing code. Create a repository of real world examples to teach the importance of, and the need for, practicing secure programming techniques. Have students use a source code control system for all their programs. Have students use commercially available tools to find potential problems in programs. Require students to work on programs in teams. Have students critique programs and designs in textbooks and other repositories for potential security problems, including a failure to apply principles of secure programming. Use widely available lists of vulnerabilities and compromises to demonstrate basic principles of security. Provide both tools and assistance for students in assessing code. This will give them hands-on experience in doing assessments. Resource Requirements Graduate students who know security and secure programming to help grade programs and help students learn to assess code. Currently, most graduate students lack this knowledge, so they would need to be taught this. Summit on Education and Secure Software Final Report 15

20 Support for clinics and hands-on laboratories, especially people, space, and equipment. Tools and other material used in industry. A means to learn what currently are the problems that institutions are facing with respect to poor coding; what are the most troublesome vulnerabilities, what are the currently used practices, and so forth. Potholes/Challenges Lack of students to support mentoring in assessments of programs; this includes grading programs in all classes using secure programming criteria. Limited space in the curriculum to add new courses or new content to existing courses. The lack of faculty who know, understand, and apply secure programming techniques, and will require students to use them in non-security related assignments. Motivating faculty to include security content to their curriculum. The slow pace of change in academia. Finding textbooks that include secure programming considerations, especially at the beginning programming level. Getting those who hire students to write the need for a basic knowledge of security into their job descriptions. Getting material support from industry and government, in the form of tools and information to guide the faculty in teaching students this material. Recommendations Take steps to increase the number of faculty who know about and are willing to require the application of secure programming in their classes (especially non-security classes). Integrate computer security into existing (non-security) courses in minimally invasive ways. Work with publishers and others to develop supplements to textbooks that provide examples that exhibit secure programming practices. In the future, work to get such examples into the textbooks themselves. Encourage the use of industry tools and technologies in the classroom and for projects. Among these are code analysis tools and source code control systems, as well as collaborative systems. Provide support for faculty and students to assess student programs and projects for robustness, especially to teach students how to assess their own, and others', programs. This can be done through a clinic, classroom instruction, or some other medium. Students should take a class in the basic principles and ideas of security, including important security issues, problems, and secure coding practices, and how those relate to principles. Summit on Education and Secure Software Final Report 16