Secure Coding Education: Are We Making Progress?
Secure Coding Education: Are We Making Progress?
复制标题
安全编码教育：我们正在取得进展吗？
DOI：
--
复制
发表时间：
2012
期刊：
影响因子：
--
通讯作者：
M. Bishop
中科院分区：
文献类型：
--
作者：
K. Nance;Bria N Hay;M. Bishop
第16届信息系统安全教育研讨会论文集佛罗里达州奥兰多2012年6月11日至13日安全编码教育：我们正在取得进展吗？阿拉斯加大学费尔班克斯的Kara Nance、Brian Hay和加州大学戴维斯分校的Matt Bishop摘要-虽然确保安全编码实践被普遍教授和采用的必要性越来越明显，但对于我们是否在这一领域取得了重大进展仍存在争议。本文回顾了2008年第一届安全编码研讨会的成就，并讨论了该研讨会的一些成果、挑战和发现。然后讨论了2011年安全教育峰会，该峰会探讨了安全编码研讨会上提出的一些问题。它还讨论了研讨会帮助激发或促进的一些后续活动，以及在持续追求安全编码方面仍然存在挑战的一些剩余目标。安全编码、计算机安全、计算机教育。虽然当前的计算机科学（CS）课程擅长教授编程技能，包括让学生接触工业中常用的语言，但重点往往是“使程序工作”。学生通常会被分配一组功能目标，例如创建一个从文件中读取记录的程序，然后根据检索到的值执行一些计算。在这种情况下，很少考虑安全编程问题，因此学生不会学习如何编写在真实的世界条件下对意外或恶意的畸形输入有弹性的程序。例如，假设文件中的记录数在文件头中指定，并且应用程序必须分配足够的空间来加载所有记录。如果程序员假设头文件总是准确且格式良好，那么这样的应用程序很容易编写。但实际上，这些假设可能并不成立。如果文件头中的记录数值非常大、为零、为负数或任何不等于文件中实际记录数的值，请考虑对程序的影响。编写一个可以处理这些情况的程序要更具挑战性。如果像这样的实践课程很容易纳入一般的计算机科学教育;这些技能增加了程序员的市场化;并有助于保护社会免受利用代码中的漏洞ISBN 1-933510-95-1/$15.00 2012 CISSE的攻击，为什么不将实践作为必修课程的一部分？关于术语的一句话将澄清下面的大部分讨论。安全本身没有定义;相反，一组称为安全策略的规则在特定上下文中定义了该术语。因此，“安全编程”应该是指一种编程风格，它产生的代码满足规定的安全要求。但在实践中，这个术语是用来指程序，避免一般的问题，如缓冲区溢出或未能正确验证输入。这种编程风格的更准确的术语是健壮编程或防御性编程。然而，在本文中，我们使用术语“安全编程”来表示健壮或防御性编程，以符合更常见的用法。二. B ACKER一组教育工作者和行业代表于2008年4月在安全编码研讨会上会面，目的是解决将安全编码实践融入当前学术课程的问题。研讨会上的初步互动展示了区分编程安全功能和安全编程的重要性。前者涉及诸如编写加密或审计功能之类的活动，并且通常是相对较少的具有广泛培训和专业知识的程序员的领域。后者影响所有程序员和所有代码，是程序中许多安全漏洞的原因。业界代表认为，所有程序员都必须掌握安全编程技术，并关注他们目前在培训新的CS毕业生方面所花费的时间和精力，他们认为这是基本的安全编程概念。这些概念包括程序员在编写代码时“像攻击者一样思考”的能力，如何以及为什么验证输入（以及什么构成“输入”），以及如何识别和解决各种数据类型（包括数组和数字类型）中可能的溢出和下溢。有人提出了一些关切，即虽然这些需求在这样的论坛上得到了传达，但在行业招聘广告中很少或根本没有强调这些技能，许多学生将其作为当前行业要求的指南，而许多学术机构则将其作为一种指导。
Proceedings of the 16 th Colloquium for Information Systems Security Education Orlando, FL June 11-13, 2012 Secure Coding Education: Are We Making Progress? Kara Nance, Brian Hay, University of Alaska Fairbanks, and Matt Bishop, University of California at Davis Abstract – While the necessity of ensuring that secure coding practices are universally taught and adopted is becoming increasingly apparent, there is still debate over whether we are making significant progress in this area. This paper recalls the accomplishments of the first Secure Coding Workshop in 2008 and discusses some of the outcomes, challenges, and findings from that workshop. It then discusses the 2011 Summit on Secure Education, which explored some of the issues raised at the Secure Coding Workshop. It also discusses some of the follow-on activities that the workshop helped to inspire or promote, and some remaining objectives that are still presenting challenges in the ongoing pursuit of secure coding. Index terms – Secure coding, computer security, computer education I. I NTRODUCTION While current computer science (CS) programs are adept at teaching programming skills including exposing students to languages commonly used in industry, the focus is often on “making programs work”. Students are typically given an assignment with a set of functional goals such as to create a program that reads records from a file, and then performs some calculation based on the values retrieved. In such cases little consideration is given to secure programming issues, and as such students do not learn how to write programs that would be resilient to accidentally or maliciously malformed input in real world conditions. For example, suppose that the number of records in the file is specified in the file header, and that the application must allocate sufficient space to load all records. Such an application is easy to write if programmer makes the assumptions that the header will always be accurate and well-formed. However, in reality these assumptions are probably not valid. Consider the implications for the program if the number of records value in the file header was very large, zero, negative, or any value not equal to the actual number of records in the file. It is far more challenging to write a program that can handle these cases. If practical lessons such as this are easy to incorporate into a general computer science education; and these skills increase the marketability of programmers; and help protect society against attacks that exploit vulnerabilities ISBN 1-933510-95-1/$15.00 2012 CISSE in code, why is the practice not included as a part of the required curriculum? A word about terminology will clarify much of the following discussion. Security per se has no definition; instead, a set of rules known as a security policy defines that term in a particular context. Thus, “secure programming” should refer to a style of programming that produces code satisfying stated security requirements. But in practice, the term is used to refer to programs that avoid generic problems like buffer overflows or failure to validate inputs properly. A more accurate term for this style of programming is robust programming or defensive programming. In this paper, though, we use the term “secure programming” for robust or defensive programming to conform to the more common usage. II. B ACKGROUND A group of educators and industry representatives met at the Secure Coding Workshop in April 2008, with the goal of addressing the issue of integrating secure coding practices into current academic curricula. The initial interactions at the workshop demonstrated how important it is to draw the distinction between programming security functionality and secure programming. The former involves activities such as writing cryptographic or auditing functionality, and is typically the domain of a relatively small number of programmers with extensive training and specialized knowledge. The later impacts all programmers and all code, and is the cause of many security vulnerabilities in programs. The industry representatives felt that it was imperative that all programmers have a knowledge of secure programming techniques, and were concerned about the amount of time and effort they currently spend training new CS graduates in what they considered to be elementary secure programming concepts. These concepts included the ability for programmers to “think like attackers” when writing code, how and why to validate input (and what constitutes “input”), and how to identify and address possible overflows and underflows in various data types (including arrays and numeric types). Some concern was raised that while these needs were being communicated at forums such as this, that little or no emphasis on these skills was evident in the industry job postings, which many students use as a guide for current industry requirements and many academic