Practice, Practice, Practice … Secure Programmer!

Practice, Practice, Practice. Secure Programmer! Melissa Dark: Purdue University Stephen Belcher: National Security Agency Ida Ngambeki: Purdue University Matt Bishop: University of California Davis I. Abstract One of the major weaknesses in software today is the failure to practice defensive or secure programming. Most training programs include only a shallow introduction to secure programming, and fail to integrate and emphasize its importance throughout the curriculum. The addition of an ongoing, practical, mentored clinic or Secure Programming Clinic (SPC) is one way of addressing this lack without adding significantly to an already stretched curriculum. In order to properly design this clinic, it is important to identify the knowledge, skills and abilities (KSAs) needed to develop effective programmers. This paper describes the results of a Delphi Study undertaken to determine the primary knowledge areas in secure programming. II. Background The current state of software today is generally poor. The quality of the software in most systems does not support the trust placed in that software. Software security failures are common, and the effects range from inconvenience to severe problems. For example, failing to properly handle an error condition made Facebook inaccessible for a few hours [John10]; the iPhone failed to ring in the New Year in 2010 [Bilt11]; a flaw in an election system used to count votes resulted in some votes from a precinct not being counted [Zett08]; a 2010 FDA study of recalled infusion pumps reported that one of the most common reported problems was software defects [FDA10]; and scientists analyzing on-board computers that control automobiles were able to exploit software vulnerabilities to control the car without physical access [CCK+11]. Indeed, much of computer security deals with handling problems created by programming errors, including analyzing and countering attacks that exploit these problems. A variety of causes underlie this phenomenon. One cause is the failure of practitioners to practice “defensive programming,” in which basic principles of robust coding guard against unexpected inputs and events. This style of programming is often called “secure programming” or “secure coding,” but this term 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” [Bish02]. 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. ” In this paper, we use the term secure programming to include both. The failure of practitioners to practice this style is not due to incompetence. One factor stems from the market economy; those who do know how to practice secure programming are often not given the opportunity to do so because it would increase cost or time to market. Few believe that customers will accept longer delivery times, or higher prices, for more robust programs. Another factor is simply lack of preparation. As Evans and Reeder noted [EvRe10], “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 systems from damage due to system failures and malicious Dark, M. , Belcher, S. , Ngambeki, I. and Bishop, M. (2015). Practice, Practice, Practice…. Secure Programmer. Proceeding of the 19th Colloquium for Information System Security Education, Las Vegas, NV.