Difference between revisions of "One page write-up of project"

Revision as of 18:25, 7 November 2004

cmbenner Thanks for the write-up, Andrew. Not sure the best way to edit this so I just added my edits to Andrew's version and said where I did this below. Main thing: I think we should tell the policy-makers right off the bat what we're doing (our goal is to offer them solutions for improving security) and make the overview sort of dummy-proof. So I did that, take a look. Also, I think that Andrew's chapter should be #2 and following threats simply because it seems funny to me to explain the problem (threats) and then jump into a specific subset of solutions (Technical--Jack) and then back up to a higher level and overview the concept of responsibility for defense (Andrew) then go back into the nitty-grittier level of another subset of defense option, John's chapter, so I reordered them. Also, Andrew's chapter seems to be a nice introduction to more specific discussions of specific defenses. Feel free to disagree.

Other notes: (not all totally relevant to the one pager, but I figure, why make you jump elsewhere right now?) 1. To answer Santu's question, my chapter will be on an economic defense--would some sort of measuring system for judging software security, like the Common Criteria, help consumers understand it and therefore demand it. As much technical detail as I will attempt will be a simple explanation in layman's terms of what a set of measuring criteria like the Common Criteria actually measure to approximate security, what computer scientists think of their attempt to measure security, and why you can't definitely tell whether a piece of software is actually secure. I plan to talk to economists to understand why the Common Criteria aren't widely used as a way to for consumers to understand security and whether if they were, consumers would use them to chose security, and also talk to computer scientists to ask what they think of the Common Criteria.

2. I see potential for overlap here which I think we should keep in mind. For example John, Andrew and I want to talk about market incentives for companies to produce secure software I plan to focus specifically on consumer demand and how you create it. Does that overlap with what you have in mind Andrew or is yours more of a general overview of incentives? How about you John, are you looking at market incentives only as an alternative to licensing? Also, Andrew and John want to talk about liability issues--any overlap there? We can work out overlap in editing each other's pieces but the more we do now, the better, to avoid serious overlap with just a little bit of time to fix it at the end. I'll start a new page, called "writing the paper--discussion"--where we can keep each other updated on what we're saying, work out things like this, ask each other questions.

3. Chapter length: aim for max 8 pages each give or take? 12 pt. Times New Roman?

4. A thought on Maurer's note from Friday on avoiding being too technical--I'm probably a good litmus test for you guys writing technical chapters since I only have general knowledge of CS. For example, I can only explain a buffer overflow in detail because someone told me about it recently (prior knowledge was simply I knew it was a means of entry for attackers into a program which is probably all a policy-maker knows and cares about.) To continue on that track, I don't know what integer overflows/underflows are and I'd guess algorithmic flaws are a bad choice of algorithm for accomplishing a particular task or badly designed algorithms. So now you have a sense of what sort of general knowledge policy-maker would have. So one thing that jumps out at me now is Santtu's discussion of the purely technical class of vulnerabilities: I'd suggest while writing this--and you were probably planning on thinking this way, but I'll just throw it out there--asking yourself each time: how much does a policy maker really need to know about how this particular vulnerablity works in order to make a sound policy decision (sound policy decisions being: require that engineers be licensed, or mandate that certain checks be done each time software is released, etc). As Maurer said, they care almost nothing for being educated about CS--they want to know only what they need to know to make decisions and they have no patience for detailed technical stuff or terms they don't understand unless they are explained well and briefly. Writing policy briefs can be tough in my experience!

5. A thought on the licensing chapter: will you consider the middle ground between licensing all software engineers vs. only those who make, say, commercial software, or some specific subset of all the software out there? i.e., I don't need to be licensed to build a bridge in my backyard for my kid to play on but I do to build the Golden Gate.

6. Deadline for roughs for us to turn into each other? Right before TG to read on the plane to Grandma's, say Wed. the 24th, which gives us 2.5 weeks? I'd say right after TG on Monday the 29th but that only gives us until that Friday, the 3rd, no weekends, to comment on each other's stuff and make fixes.

7. Anyone up for writing a quick intro to trace a security exploit in 2014, as I think that would be a great way to start. Is that part of your idea Santtu for starting your chapter, or if not, would it be easy for someone to do? I'd volunteer, but I'm not the person to do this.

8. I added a quick note on my sources.

9. Possible title: I like something like what we have now: "Attack, Defense and Responsibility: Improving Cybersecurity before 2014."

Team Members

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

Overview cmbenner: I made changes throughout this overview to make it even simpler and more straightforward for policy-makers who have little time and little patience.

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 threates. 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 cybersecurity, from technical, to policy to economic. 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 and providing common, understandable ratings of software security would solve the problem of security through economic demand.

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. 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:

• http://catless.ncl.ac.uk/Risks
• Beyond the Horizon: A Call to Arms, Jeannette M. Wing, IEEE Security and Privacy. November/December 2003, pp. 62-67.
• Technology News: Security: Windows Cash-Machine Worm Generates Concern. http://www.technewsworld.com/story/32350.html
• Computer Security Threat Monitoring and Surveillance. James P. Anderson Co. http://csrc.nist.gov/publications/history/ande80.pdf
• http://secunia.com – past and present security vulnerabilities
• Publications at http://www.computer.org

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?

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?

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. This chapter explains briefly that there is no way to definitively tell whether a piece of software is secure--indeed it's been proven that you can't prove a piece of 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 (or others?), 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.

Primary sources: 1. Interviews with computer science experts in security (suggestions welcome to add to my list) 2. Interviews with economists who understand demand and how you might create it for security (beginning with Professor Maurer, other suggestions welcome for my list).