One page write-up of project

From CSEP590TU
Jump to: navigation, search

Title

Attack, Defense and Responsibility: Improving Cybersecurity by 2014


Team Members

Caroline Benner, Andrew Pardoe, Jack Richins, John Spaith, Santeri (Santtu) Voutilainen


Team Organization

Each chapter has been assigned a lead author. As we write the chapters, we will be pasting them to specific places in our wiki for each other to review. We will take each other's feedback into account and edit our chapters accordingly. We have also established a place in our wiki for us to ask questions of each other and to share sources.


Overview

The goal of our paper is to explain to policy-makers what forces could be brought into play to improve computer security. We begin by evaluating the problems we're facing when it comes to computer security: we look at past, present and future threats. We then begin our discussion of solutions with an overview of who should bear responsibility for improving computer security. From there we offer the policy-maker a range of possible solutions for improving security, from technical, to policy to economic so the policy-maker is well-briefed in the various ways security can be improved. Our first solution is a technical one: we survey promising areas of research in designing secure systems and assess costs and benefits of these approaches. We then consider a policy solution, namely whether software engineering should be licensed as civil engineering is licensed. Finally, we conclude with a look at whether educating the consumer about security by providing common, understandable ratings of how secure the software they buy is would create consumer demand for security. This, in turn, would encourage companies to provide security.


Chapter 1 -- Threats: Past, Present, and Future (Lead author: Santtu)

This chapter lays the foundation for the rest of the paper by discussing past, present and future threats, and materialization of these threats in real attacks. The chapter will be introduced by a walk through of an attack and its effects in 2014. Threats will be examined from two viewpoints, the purely technical view of different vulnerabilities in computer code and systems, as well as the effects of service disruption at potential targets. The discussion on purely technical vulnerabilities will cover the progression of newly identified vulnerabilities from the various flavors of buffer overflows, integer under/overflows, algorithmic flaws to improved brute force attacks. Discussion on threatened targets will cover the threats posed by integration of computer systems into an ever increasing number of devices and areas where the effect of attacks may extend from disruption of service and to life threatening. such as health and financial record management, everyday appliances, and military equipment.

Sources:

Chapter 2 -- Responsibility for security flaws and exploitations (Lead author: Andrew)

This chapter examines who is ultimately responsible for the costs incurred through security flaws and exploitations? How does this differ when the software is produced by corporations, individuals or an open sourced project? What kind of incentives are there for companies/open source groups to produce more reliable software? Can these incentives be improved?

Responsibility should scale with the importance of usage. Does a click-wrap license or a disclaimer in an OSS license indemnify the creator of the software of all responsiblity? Do corporate products incur more liability than OSS projects? What responsibility does a software vendor have to society? If a single vendor holds a significant portion of the market is there a greater responsibility to protect the users of this network? Software which controls critical societal infrastructure (such as an automobile, a power plant or a voting machine) is at the far end of this scale. Are governments choosing software responsibly?

What incentives exist to produce secure software? Would legal liability be a greater incentive or a disincentive to innovate? Would anyone produce important but risky software if their company were potentially liable for all damages resulting from usage of that software?

Sources:

Chapter 3 -- Defense, technical solution: Designing secure systems (Lead author: Jack)

This chapter surveys promising areas of research in designing secure systems. Software that analyzes software code shows promise in finding security defects that humans have difficulty finding. There is speculation that different software languages, such as functional languages which have a firmer mathematical basis, would be more secure that the popular languages being used today. There are also attempts at detecting security intrusions or violations as software is being executed.

Additionally, this chapter examines the obstacles and costs of these approaches. All these approaches will incur trade-offs relative to our current approaches in software design. Tools that find security defects in source code will increase the time needed to write software as engineers' time is spent investigating and fixing possible defects found by these tools. Different programming languages will incur training and design costs as engineers go through learning how to learn these new languages. Detecting security issues while software is running will decrease overall performance of applications.

Sources:

  • Methods For The Prevention, Detection And Removal Of Software Security Vulnerabilities, Jay-Evan J. Tevis & John A. Hamilton, Jr., ACM Southeast Conference’04, April 2–3, 2004, Huntsville, AL, USA.
  • Securing Web Application Code by Static Analysis and Runtime Protection, Yao-Wen Huang, Fang Yu, Christian Hang, Chung-Hung Tsai, D. T. Lee, Sy-Yen Kuo, WWW 2004, May 17–22, 2004, New York, New York, USA.


Chapter 4 -- Defense, policy solution: Should software engineers be licensed? (Lead author: John)

This chapter explores the question of whether external organizations (such as the government or standards organizations like the IEEE) should take a more active roll in the internal practices of software vendors. Most engineers need training and licensing to practice their disciplines but software can be built by kids in a garage. A bridge constructed by a thoughtful Roman can last for 2000 years. Can we say the same for our software?

Ten years from now we'll have better software design tools and have better practices for developing software. But the tools are only as good as the people using them and the stakes will be much higher if we screw up. What are the tradeoffs between having a free-flowing software design environment that encourages innovation and risk versus a profesional management that offers higher security?

Standards bodies have traditionally restricted their governance of software to externalities - like whether a vendor's TCP stack is complaint. Should they expand their governance to include licensing, code reviews, requirement of intrusion detection, and other development practices? Or are market forces and possible litigation in and of themselves enough?

Sources:


Chapter 5 -- Defense, economic solution: Getting the consumer to understand security (Lead author: Caroline)

One major problem with the provision of security in software is that companies haven't had an incentive to provide it since consumers don't demand it. Why? Because they don't have a clue what security is and so don't know what to put their dollars behind. This chapter explains briefly that there is no way to definitively tell whether software is secure--indeed it's been proven that you can't prove in general that software is secure--and the best computer scientists can do is approximate how secure something is by evaluating how good the design is, how good the SE practices are, how the software performs in tests that catch the low-hanging fruit bugs. It goes on to evaluate tests for measuring security that can be translated into something consumers understand, such as the Common Criteria, by asking computer scientists what they think of the usefulness of this test. It then asks economists whether if the rankings of the Common Criteria were widely known, such as via press attention, it would generate consumer interest in buying products based on their security rankings.

Sources:

  • Interviews with computer science experts in security (suggestions welcome to add to my list)
  • Interviews with economists who have thought about creating demand for security (beginning with Professor Maurer, other suggestions welcome for my list).
Retrieved from "http://cubist.cs.washington.edu/CSEP590TU-wiki/index.php?title=One_page_write-up_of_project&oldid=5096"