Tuesday, April 5, 2011

Keynote Summary by Mark Lohrum

Neal Ziring, the current technical director for the Information Assurance Directorate at the NSA, was given the honor of delivering the opening keynote for the 2011 CERIAS Symposium on April 5th at Purdue University. He discussed the trends in cyber threats from the 1980s to today and shifts of defenses in response to those threats. He noted that, as a society, we have built a great information network, but unless we can trust it and be defended against possible threats, we will not see the full potential of a vast network. Ziring’s focus, as an NSA representative, was primarily from a perspective of preserving national interests regarding information security.

Ziring discussed trends in threats to information security. In the 1980s, the scope of cyber threats was rather simple. Opposing nations wished to obtain information from servers belonging to the U.S., so the NSA wished to stop them. This was fairly straightforward. Since the 1980s, threats have become far more complex. The opponents may not be simply opposing countries; they may be organized criminals, rouge hackers, hacktivists, or more. Also in years past, much expertise was required to complete attacks. Now, not so much expertise is required, which results in more threat actors. In the past, attacks were not very focused. Someone would write a virus and see how many computers in a network in can effect, almost as if it were a competition. Now, attacks are far more focused on achieving a specific goal aimed at a specific target. Ziring cited a statistic that around 75% of viruses are targeted at less than 50 individual computers. Experts in information security must understand the specific goals of a threat actor so attacks can be predicted.

Ziring also discussed shifts in information security. The philosophy used to be to simply protect assets, but now the philosophy includes defending against known malicious code and hunting for not yet known threats. Another shift is that the NSA has become increasingly dependent upon commercial products. In the past, defenses were entirely built internally, but that just does not work against the ever-changing threats of today. Commercial software advances at a rate far faster than internal products can be developed. The NSA utilizes a multi-tiered security approach because all commercial products contain certain shortcomings. Where one commercial product fails to protect against a threat, another product should be able to counter that threat; this concept is used to layer security software to fully protect assets.

A current concern in information security is the demand for mobility. Cell phones have become part of everyday life, as we as a society carry them everywhere. As these are mobile networking computers, the potential shortcomings of security on these devices is a concern. If they are integrated with critical assets, a security hole is exposed. Similarly, cloud computing creates a concern. Integrity of information on servers which the NSA does not own must be ensured.

Ziring brought up a couple of general points to consider. First, information security requires situational awareness. Knowing the current status of critical information is necessary to defending it properly, and knowing the status of the security system consistently is required. Currently, many security systems are audited every several years, but it may be better to continuously check the status of the security system. And secondly, operations must be able to operate on a compromised network. The old philosophy was to recover from a network compromise, then resume activity. The new philosophy, because networks are so massive, is to be able to run operations while the network is in a compromised state.

Ziring concluded by discussing the need to create academic partnerships. Academic partnerships can help the NSA have access to the best researchers, newer standards, and newer technologies. Many of the current top secure systems would not have been possible without academic partnerships. It is impossible for the NSA to employ more people than the adversaries, but it is possible to outthink and out-innovate them.

Wednesday, March 31, 2010

Panel Members:

• David Bell, Retired, Co-author Bell-La Padula Security Model
• Joe Pekny, Purdue University
• Kenneth Brancik, Northrop Grumman
• Petros Mouchtaris, Telcordia

Summary by Utsav Mittal

The panel was started by Petros Mouchtaris. He said that applying for funding is not that bad although the researcher gets a lot of rejections, but then also once the funding comes through it gives the researcher a lot of control about the areas he wants to work in. He said in the last 10 years most of their funding came from DARPA, initially the funding was for long-term small projects. He said that a smaller, long-term project gives more time to foster basic research about abstract ideas.

Joe Pekny, who has worked in Discovery park for about 10 years, said that the fundamental principle about generating funding is about that “Research follows impact.” He said that difference between getting and not getting funding is between the ability of the researcher to relate his potential and ability to provide impact. He also talked about the research opportunities in electronic medical records and about privacy issues in videos surveillance that is widely used.

He mentioned some tactics that help in order to monetize the research impact:

1. Leverage: He mentioned that everyone wants a big grant which runs long, but that is not always possible, so the researcher should leverage whatever opportunities that he has to have the biggest advantage.

2. Interdisciplinary: He said that this is important, as many problems that we face today are of a complex nature and no single idea can crack the problem, so different smart minds from different areas should work on it.

3. Minimalistic: Joe said that a minimalistic team should be assembled in order to crack the problem, there should not be too many people working on the project.

4. Relationships: Joe stressed the importance of fostering long standing relationships for generating funding.

5. Entrepreneurship: Joe mentioned that money never comes in the form that a person wants it to, so a researcher should have the spirit of entrepreneurship.

6. Operations v. Philanthropy: He meant that if a organization thinks that the researcher has the potential to solve an operations problem then it would shell out billions and fund it. On the other hand if they do not believe in the potential then they may give money as philanthropy.

7. Vision: Joe said that an enduring, fundamental over arching vision is needed for a researcher to be successful. A researcher should have creativity and innovation is every situation.

Kenneth Brancik shared his experiences about research funding in the last 30 years. He related his life experience and its help in increasing his “situational awareness.”” He said that technology is an enabler for business. He said we should think out of the box and be aware about the “situational awareness” related to cyber security. He said that a researcher, in order to understand the complex cyber security problems, should:

1. Think out of the box
2. Understand the business impact related to it.
3. Use a wide angle lens to look at the picture.

David Bell started his talk by quoting Mark Twain and about people being lost in “Power Point Age” which cracked the audience up. David shared his experiences that he had working with ARPA and other federal agencies. He also mentioned about various projects like “Blacker.” He mentioned that in the earlier research was “Tethered research.” People were not very sure what they were working on, all they knew was that they are working on some advanced technology. His current take on federal funding was that it has dropped from 1.3% to 1%, and a lot needs to be done in the area of cyber security.

Wednesday, March 31, 2010

Summary by Robert Winkworth

“Everything I Needed to Know About Security I Learned in 1974”

Security luminary David Bell concluded this year’s Information Security Symposium with a lecture in which he argued that while the speed and size of computers has changed greatly across the decades, the principles underlying the issue of security have been remarkably constant.

With the exception of one noted MULTICS covert channel hack, the speaker asserted no fundamentally new innovation in computer security appeared from 1974 until 2005 (when he retired.) Dr. Bell had done a great deal of conceptual modeling, particularly near the beginning of his career. This, he explained, influenced his later work in security. In 1971, Bell, having read many classic MULTICS papers, felt even then that “all the good stuff” had already been done and made public. He recalled, with some amusement, that government facilities did not always share his awareness of these facts. Material freely available in research libraries, when cited in military security reports, often becomes classified as though somehow it might be made secret anew.

Commenting on the 1972 Anderson Report, Dr. Bell noted that a core collection of only about a dozen critical infiltration tactics proved successful in almost every documented penetration test. Clearly by better abstracting these procedures into general categories of attack we could better understand and predict them. So, Bell was called to produce a mathematical model of computer security, but no other details of his assignment were specified. This, he explained, turns the technical process of testing and setting conditions in the machine into a cultural process of negotiating policies. “Security” is not meaningful until defined. Likewise, threats to security must be discussed before we can discuss their remedies. General principles of a security model are not useful until somehow applied, and Bell prefers to see these concrete examples before signing off on a policy, however academically sound it may seem.

Along with Len La Padula, David Bell is probably most widely recognized for his contribution to the Bell-La Padula Model of secure systems. This widely influential set of conceptual tools appears frequently in the fundamentals of IA curricula at Purdue and probably throughout the world.

Our host was critical of those that see security as a personnel problem, noting that this approach fails to recognize the technical weaknesses that remain regardless of the people involved. And coordinating the technology is possible; Bell shows us computer systems that have never suffered a documented breach and never required a security patch. Unfortunately, the process of replacing an existing infrastructure is difficult, particularly for an entrenched bureaucracy, so the challenge facing many security modelers is producing a plan that outlines not only the destination but all the intermediary steps necessary to transform an existing system to one that approaches the level of security desired.

Many evaluators are assigned to networks the technology of which they cannot explain. Since they cannot articulate an effective policy for interactions between such a network and its trusted neighbors, a common reaction to this is to simply isolate them. As internetworking becomes pervasive, however, this cannot remain a practical strategy. Networks must be connected, but such connections introduce weaknesses if they are not thoroughly documented and regulated. How we can possibly manage the explosive complexity of internetworks remains a daunting question.

“We are not safe and secure today,” concludes our eminent guest. Those that claim otherwise are “either misinformed or lying.” Bell called upon us to implement more of the sound ideas in information assurance that hitherto have existed only as concept, and to fully acknowledge the extent to which models such as BLP have not been fully embodied.

Gene Spafford was on hand for today’s session, and asked for Dr. Bell’s comments on the software solutions of Rogers and Green Hills (two of the best-rated security platforms.) Bell found both quite sound. He was concerned, however, that neither had achieved the market “traction” that he would like to see. He provided some examples of how each could be more effectively introduced to companies that might use them in live networks.

As of March 31, 2010, the media presented in this lecture is available.

Wednesday, March 31, 2010

Summary by Gaspar Modelo-Howard

Day two opened with a keynote from Under Secretary Beers, who has had a long and interesting career of over 34 years, including military service and working as staff member for the National Security Council, under four U.S. Presidents. During his talk, he provided an introduction of the National Protection and Programs Directorate (NPPD) and DHS, discussed the importance and role of cyber security to protect the overall security of the United States, how DHS is continually evolving to meet the changing landscape and its mission, and current challenges and problems faced by NPPD.

Under Secretary Beers began with a discussion of the responsibilities of DHS and NPPD in particular. DHS has five goals or missions, listed here in no particular order: (1) counterterrorism, (2) securing U.S. borders, (3) immigration, (4) response to disasters, and (5) cyber security. This last goal refers to protecting cyberspace for civilian side of government and working with private sector to achieve physical Critical Information Infrastructure Protection (CIIP).

DHS is a pretty new department, formed in late 2002, so they are currently embarking on the transformation of its workforce. Main reason is a number of professional disciplines were brought together to start the Department but there were at time very few professionals to start DHS. So it is an evolving organization. Currently, NPPD has equal number of private contractors and federal employees working in the Directorate but there are several initiatives to fill more permanent positions. In terms of cyber security, the Department is looking to hire 1,000 people in cyber security in the next 3 years. They also expect to increase NPPD cyber security workforce to 260 by end of FY 2010.

Under Secretary Beers mentioned the difficulty faced when hiring cyber security specialists is that academic institutions do not currently produce enough graduates to meet the federal demand. Such statement considers that not all of the needs are for pure technical positions. Much to the surprise and amusement of the audience, the Under Secretary mentioned there are not enough lawyers in DHS. It takes a long time for DHS leaders to get legal advice on some topics because there are more questions than the lawyers can answer. Some of this would also be rectified by having better laws relating to cyber security.

Generally speaking, DHS and NPPD in particular, are looking to draw knowledge and experience from math, science and cyber security communities to build a strong federal department. DHS objective is to forge stronger links with educational institutions such as Purdue University, to better prepare itself to deal with cyber security matters.

During his presentation, Under Secretary Beers made an important point to help define the national cyber security strategy: 85% of cyberspace in U.S. exists outside the government. That is why the Directorate works closely with private sector. For example, the Office of Infrastructure Protection (IP) takes 18 critical sectors of the American economy (water, power, finance, etc.) and work with them to develop security plans (standards, strategies, best practices) and improve preparedness to respond to emergencies. Mr. Beers also stressed the role cyber security plays within DHS, as it is part of every other part. Cyber security works as a cross sector, for example between the communication and information sectors.

The Under Secretary noted that cyber threats are increasing on a daily basis and they also include physical attacks, because of the potential impact they can have in cyberspace. He shared two examples: (1) a bond trading company which had to evacuate during the first World Trade Center attack of 1993 and (2) the train derailment and fire in Baltimore, 2001. In the first story, the investment company had to evacuate the World Trade Center but did not backup systems off-site. It took a presidential order to allow them to re-enter the building since the fire marshal had prohibited anyone from doing so. In the train story, the fire disrupted communication links going thru the same tunnel where the disaster occurred. Such cables were major Internet links that slowed down service around the US.

NPDD cyber security daily operations include monitoring of attacks, protecting the .gov domain and monitoring Internet connections from/to government networks. US-CERT, the cyber security operational arm within NPDD, uses the Einstein intrusion detection program to work on these responsibilities. (I think it was cool that he mentioned Einstein as usually high-ranking U.S. Government officials avoid such topics). Mr. Beers also noted that under President Obama’s cyber security 60-day review, DHS had to create a Computer Emergency Response Team (CERT) plan to deal with cyber security threats and crisis. It has been done and involved government at different levels (federal, state, local) and private sector. Also, DHS opened last October the National Cyber security and Communications Integration Center to improve national efforts to address threats and incidents affecting U.S. critical cyber infrastructure.

To finish his presentation, the Under Secretary talked about several of the current and future cyber security challenges faced by DHS. First, they are currently working on developing systems that make it possible for different cyber security players to share information. This is a common problem when requesting or managing information from different sources, for example the private sector, because such information is highly sensitive to its owner. Second, DHS is also increasingly responsible for cyber security awareness and outreach initiatives. They are working with academic institutions to foster and identify potential government employees. Third, in terms of global involvement, US-CERT is partnering with similar institutions in other countries to work on international incidents and to create stronger ties. DHS is fully aware of the interconnectivity of networks, regardless of physical location. It actively participates in the annual Meridian Conference for international CIIP collaboration and invites representatives of foreign countries to their biennial Cyber Storm exercises.

In the Q&A session, a member of the audience asked Mr. Beers if he could prioritize DHS cyber security needs in terms of the human capital. This is important as cyber security is an interdisciplinary field and there is need for professionals with technical and non-technical backgrounds. Mr. Beers listed three needs: (1) people with computer science background to operate the cyber security centers; (2) people with system design and administration skills; (3) people with business background to deal with contracting issues and proficiency to understand technical requirements. This last group is important as government has a responsibility to define as clear and specific as possible the requirements and objectives so other sectors can determine how to comply. He then mentioned that government might have to start training centers as there are not enough graduates coming from college.

As a follow up question to his comment on cyber security savvy lawyers, he was asked if real problem is that U.S. does not have the appropriate laws to protect its cyber infrastructure and also if DHS is advocating for new legal frameworks. Mr. Beers agreed that a better legal framework is required and DHS is indeed advocating for this to happen. In a later question, he also pointed out that legal and cyber security communities need to further discuss issues affecting both sides and such exchanges should also happen outside the government (because of restrictions a federal employee might have by law).

The next two questions were about international efforts taken by DHS, citing the United Nations is working on developing cyber security laws and best practices. The Under Secretary mentioned that DHS cannot work at international level and that time has come for State Department to step up.

A question then was made regarding the difficulties when physical and cyber security communities interact. Mr. Beers noted it is a recurring but expected problem when working with entities from public and private sectors. Sometimes they find cases where both exist under one directorate, but in general this is not the case and it is part of the evolution of security.

A member of audience asked about briefing on current and future strategies with U.S. Cyber Command and NSA. The Under Secretary mentioned that major elements of collaboration are still under development. There are discussions on having DHS deputy and employees at Cyber Command and NSA and vice versa.

A final question was made on comparing costs of training employees in cyber security with costs of scholarship, suggesting the second option might be cheaper. Therefore there might be an incentive to increase number of scholarships. Mr. Beers agreed to the suggestion and said DHS is looking into additional opportunities to fund students/institutions but was also quick to point out that not every cyber security professional has to come from an academic setting.

Overall, it was an interesting talk by the Honorable Beers, providing an overview of the structure, mission and challenges faced by NPPD and DHS. He stressed out the importance of cyber security as part of the primary mission of the Department and the relevance of working with different partners to successfully achieve the mission.

Tuesday, March 30, 2010

Panel Members:

• Mike McConnell, Booz Allen Hamilton
• Rand Beers, DHS
• Eugene H. Spafford, CERIAS

Summary by Derril Lucci

The fireside chat saw Admiral John McConnell, the Honorable Rand Beers, and Professor Eugene Spafford discuss some of the issues in security today. One of the first topics covered was how technology will change business and society. Admiral McConnell made a point to mention that once every 50 years, a new technology comes along that revolutionizes the way in which things are done. Among the examples included the gin mill and the textile industry. Another topic that was discussed was the need for a new internet. What is meant by this is a need for an internet that can go through a trusted third party. This new idea, they believe, will make for a safer internet. This lead to the debate about the innovation of cyberspace versus security. Security can be viewed as a restriction to the innovation of cyberspace because it is a tradeoff between standards and regulation. Admiral McConnell also discussed a potential threat to our banks. He said that every day, $7 trillion dollars is moved by two banks in New York City. If these transmissions are ever interrupted, coupled with a well timed terrorist attack, it could topple both the U.S. banking and the global banking industry. This is why both Admiral McConnell and Secretary Beers have lobbied for action by the government to set up a plan to prevent this. However, they both stressed that the U.S. government has a history of dragging its feet when it comes to this matter, and they feel that the U.S. will not do anything until the event has already occurred. Furthermore, Secretary Beers called for academic institutions to come together and decide where we want to go, as a Network/Cyber security community. Admiral McConnell said that it is up to future generations to devise schemes to lower the risk of attacks by those who wish to change the world order.

Tuesday, March 30, 2010

Panel Members:

• Nicolas Christin, Carnegie Mellon University
• Cassio Goldschmidt, Symantec Corporation
• Aaron Massey, North Carolina State University
• Melissa Dark, Purdue University

Summary by Preeti Rao

March 31, 2010, Tuesday afternoon’s panel discussion at the Eleventh Annual CERIAS Symposium was on Information Security Ethics. The panel consisted of four pioneers from academia and industry - Nicolas Christin from Carnegie Mellon University, Cassio Goldschmidt from Symantec Corporation, Aaron Massey from North Carolina State University and Melissa Dark from Purdue University.

Melissa Dark introduced the panel and put forth the thought that Information Security Ethics is a really messy topic because it involves a variety of stakeholders. Identifying all the stakeholders, their competing interests and balancing the competing interests is not an easy trade-off. There are a number of incentives and disincentives to be considered. Information security ethics is interesting when discussed with respect to certain scenarios and the panel chose to do that.

The first presentation was from Nicolas Christin and he presented on Peer-to-Peer Networks, Incentives and Ethics.

He started off by talking about Peer-to-peer (P2P) networks in general, their interdisciplinary nature, their benefits and costs. He quoted that P2P traffic is a very sizable amount of load and that 30 to 70% of internet traffic is from P2P networks. They carry a bad reputation because of copyrighted materials dissemination. But they have numerous benefits too ñ software distributors save on infrastructure by distributing free and proprietary software to legitimate users through P2P networks. Another advantage is in censorship resilience.

Christin identified five stakeholders in P2P networks and discussed about their ethical dilemmas and competing interests. End users, content providers or copyright holders, electronics manufacturers, software developers and internet service providers (ISPs) were the five stakeholders he talked about. While end users tend to download content for free, content providers or copyright holders are worried about unauthorized replication of their content. Electronic manufacturers benefit from digital media portability on P2P networks — electronics like iPods would not have been this successful if people did not get music for free or for very low cost. Software developers potentially benefit from increased P2P use. ISPs have interesting ethical dilemmas. While ISPs benefit due to increased bandwidth usage from users downloading content, a number of users are into copyright infringement — downloading content for free through P2P networks through the bandwidth provided by these ISPs. Sometimes ISPs assist companies of content providers. He quoted a very good example of Comcast. Is it ethical to download TV shows using Comcast’s Internet, or watch the TV shows using Comcast’s cable TV service?

He summarized the competing interests and ethical dilemmas of the stakeholders identified on P2P networks as end users producing and downloading infringing content, content industry poisoning P2P networks, content industry launching Denial of service attacks on P2P hosts, ISPs advertising access to movies, promising users that they will get access to the movies, and then filtering out BitTorrent traffic, electronics manufacturers advertising ripping and copying capabilities of the devices.

He left the audience with a set of intriguing questions. Is downloading content ethical or unethical? How do we decide what is ethical and unethical in Information Security? What are the criteria to be applied to make this decision? Are the decisions ever ethically justified? The bottom line is the unclear set of incentives.

The second presentation was on Responsibility for the Harm and Risk of Software Security Flaws by Cassio Goldschmidt.

He identified five stakeholders in analyzing the situation of software security flaws. The stakeholders were Independent Software Vendors (ISVs), Users, Government, Software Vulnerabilities and Security Researchers.

He quoted Microsoft’s example as an ISV and how users always blame ISVs for faulty software. For software industries, the weakest links are software developers and software testers. ISVs are doing a lot to build secure software they have started training classes to teach how to write secure code and how to secure every stage of SDLC and test life cycle. But, software by nature is vulnerable, no matter what. Users buy software because of its features; when a user is ready to buy software there is no way he can make out whether that software is secure. Goldschmidt argued that managing software security is very difficult when one cannot compare two pieces of software are more secure; hence we cannot expect users to buy and use “secure software”. There are many non-technical users who do not know the importance software or system security. Users definitely have something to do with the software vulnerabilities.

He talked about security researchers and vulnerability disclosures. There are conflicting interests and possible risks in security researchers disclosing software vulnerabilities. Before one does a full disclosure of vulnerabilities, one needs to think about how people and media would take advantage of it. He quoted an example of the concept of Microsoft’s “Patch Tuesday” and the following “Exploit Wednesday”. Sometimes software industries buy products from companies because of strategic partnerships, long term relations, money, etc. The decision is not always based on security.

Government has a role to play in promoting software security. But if the government enacts laws to enforce software security, there will be serious financial issues for the ISVs. For example, software development process would become very expensive for start-ups. He concluded that enacting laws for software security can be hard.

He summarized — software is dynamic. People have yet to understand the meaning of software. Some call it a product. Some call it a service. Some even call it free speech because it has a language and associated grammar. The problem of software security is very complex. It needs attention and awareness.

The third presentation was from Aaron Massey on Behavioral Advertising Ethics.

Behavioral advertising which targets custom-made advertisements to users based on their behavior profiles uses technologies like cookies, web bugs and deep packet inspection. Massey opined that Behavioral Advertising Ethics is interesting and overlaps with Advertising, Privacy and Technology domains. He quoted examples of some ethical dilemmas associated with these domains:

• Advertising: Is it ethical to target ads based on user’s profile/history For Example: a door salesman posing questions to customer to know more about their preferences and suggesting products based on gathered information.

• Privacy: For example, a Facebook program which tracked user A’s online shopping history and displayed ads on user B’s (friend of user A) homepage suggesting to buy the product bought by user A. Is this a probable privacy breach for user A?

• Technology: Where does the ethical value lie? And, is it in the technology itself? Is it in the use of technology, or is it in the design? As an example, take a hammer. It can be used in a constructive or destructive way and the design does not restrict the purpose of usage.

Considering these questions when building a behavioral advertising technology, is there a way we can make it secure without compromising the utility of the technology?

Melissa Dark summed up the panel presentations considering the three keys for information security ethics: the stakeholders, their competing interests and tradeoffs, the incentives and disincentives. She mentioned that incentives and disincentives have been long standing norms and expectations. We need to think about how these norms and expectations affect ethics, how our mindsets affect the larger ethical debate. She opened the floor for questions.

Questions and Discussions

Question 1: Often with online shopping and ethics, users usually do not have many options. Either you buy the product or leave it. For example, the Facebook scenario discussed earlier. In such situations, if you disagree with the ethics then how can you affect the changes? Usually most companies just have ethics externally posed on them.

Aaron Massey: There are privacy policies that are in place and FTC enforces these privacy policies. If a company violates its privacy policy, though as an individual you cannot sue the company, you can file a complaint to the FTC. FTC would review company’s business practices and take necessary actions. Companies like Facebook, Google work with FTC right from the beginning to get everything right.

Melissa Dark: Masses can make use of consumerism and market forces. She mentioned that there are 45 Data Breach Disclosure state laws, but no single federal law in the US for handling data breach disclosures. The usage of right language to talk about information security is very important.

Victor Raskin: Supported Melissa on that and said the language, the framework used to talk about information security is very important.

Eugene Spafford: Awareness is equally important for software security. Our current mission should be to make security visible.

Audience: Informal collective action (example - blogosphere) is very powerful, can be used as a weapon against unethical actions.

Aaron Massey: Danger and the slippery slope is the connotation in ethics.

Question 2: What are the roles of users, government in realizing information security? In Australia, ISPs are now restricting access to end users on certain resources because a recent law put liability on the ISPs to take corrective action; the end users are just notified.

Nicolas Christin: There are similar laws on P2P networks. But again, managing the tradeoff between ISPs and users is critical. Users can easily conceal their actions and ISPs have to make a decision on restricting their users. Ethical and legal dilemmas are happening because the legal scholars who usually write the laws usually have no technology background.

Eugene Spafford: It is hard to strike the right balance and create good laws.

Question 3: Educational institutions are not doing a good job teaching how to write secure software. What should an institution do to give good security education?

Melissa Dark: Public institutions have a lot of masters to serve. They take tax payer money and are under many obligations. Yet security education curriculum is being modified and improved constantly. There has been tremendous growth in the past decade. There is still a lot more to be done for security education.

Audience: College education is just once, but industry education and training needs to be constantly revised.

Nicolas Christin: Security education: should it be industry driven or college education driven? In college education, the main goal is to train students to get good jobs. University respond to market demands. Selling security and security education is hard. Knowing how to write secure code needs lot of training and experience. For a new graduate the most important thing is to secure a job, need not necessarily be a secure software coding job.

Aaron Massey: Even before security education: what is security? How do you measure security? Should you concentrate on secure programming, testing or design?

Eugene Spafford: Purdue CERIAS is doing a great job in giving security education. But still, lot of awareness is needed.

Question 4: What is ethical software or ethical coding? Does the society have a role to play in making the society ethical?

Aaron Massey: Society is addressing ethical questions. For example, the FTC is holding workshops on how to treat privacy online. There is no single solution yet.

Question 5: What are the best practices from other disciplines that can be adopted into Infosec ethics? Do other disciplines have a generic framework? Aaron Massey: Healthcare legislations, HIPAA are evolving. Generic framework is a good domain to look at. Investigations are on in this regard. Professional code of ethics is as applied to a profession. But Information security profession, its demands and roles are not yet clearly defined.

Question 6: How does ethics depend on the perception of truth? How can advertising be a win-win situation, if advertising is just informational and not manipulative? Does anyone read the privacy policies where information is there, but not consumable?

Aaron Massey: Research is being done and people are coming up with Nutritional labels for privacy policies ñ an alternative way of understanding privacy policies instead of reading a lot of privacy policy text.

Audience: An idea based on agricultural domain: suppose companies identify themselves as data-collection free companies and certify themselves as ones who do not collect information about people, would that help?

Nicolas Christin: There are companies that produce privacy practices in machine readable form so that you do not have to read the whole document. Companies are trying different methods for privacy policy reading.

Tuesday, March 30, 2010

Panel Members:

• Steve Dill, Lockheed Martin
• Donald Robinson, Northrop Grumman
• Ross Maciejewski, Purdue
• Alok Chaturvedi, Purdue

Summary by Ryan Poyar

The first panel of the 2010 annual security symposium kicked things off to a great start and an interesting discussion. The topic was the Visualization of Security. The focus of the panel was to address the issue of how to use the vast amounts of data that is available in a way that can help predict and protect systems from future threats. Alok Chaturvedi, a professor at Purdue, initiated the discussion by describing how using visualization could potentially make it possible to display large amounts of data in a meaningful way. Donald Robinson from Northrop Grumman rationalized the use of using visualization with his argument that as humans we are naturally very good at recognizing patterns and making sense of visualizations as opposed to dealing with raw data. Currently, this technique is being researched through the project VACCINE (Visual Analytics for Command, Control, and Interoperability Environments) which is primarily focused on helping the mission of the Department of Homeland Security. As one of the researchers working on VACCINE, Ross Maciejewski described that the goal of the project was to be able to determine potential threats from an abundance of streaming real-time data sources and then further to provide real-time targeted counter measures against each threat. While all of this sounds very good in theory, getting it to work in practice requires many hurdles to be overcome. The discussion for the remainder of the panel was a debate on who should be responsible for making the threat determination from the data and then who should determine the correct response. Even in a non-real-time environment with only humans this is a very tricky endeavor. It seems that it is necessary for a specific expert in each field to analyze the data from their perspective and look for threats based on their expertise only. If a threat is found, it is then very difficult to determine who has the right background and is the best choice to mitigate it. Further, who has the ability to foresee threats that cross multiple disciplines? If we have a difficult time answering these questions in a detailed, comprehensive, non-real-time environment how will we be able to design a system a priori that can answer future questions in real-time?

Tuesday, March 30, 2010

Summary by Jason Ortiz

Mike McConnell, retired Admiral of the Navy, former Director of NSA and former Director of National Intelligence delivered the opening keynote speech for the eleventh annual CERIAS Security Symposium. The majority of this keynote was devoted to recounting his experiences and efforts to move forward national cyber capabilities. The following is a summary of those efforts.

Admiral McConnell opened the address with a simple statement: “The nation is at significant risk.” He pointed out that the United States’ economy and livelihood is in information streams. If those streams are interrupted or tampered with, the United States could lose trillions of dollars almost instantly.

McConnell continued the keynote by making three predictions. The first of those was the idea that the United States will continue to talk about cyber defenses but not really do anything until after a catastrophic cyber event. The Admiral supported this idea by pointing out that if extremist groups were to focus their efforts on cyber attacks, they could disrupt transportation and the economy. As evidenced by attacks last spring in California (criminals cut fiber optic cables), they could also disrupt services such as 9-11 service, internet connectivity, and cellular phone service.

McConnell’s second prediction was that after a catastrophic event, the government of the United States would suddenly lurch into action. They will pass laws, appropriate money and work to prevent the same sort of catastrophe from reoccurring. After all, Washington D.C. responds to four things: crisis, the ballot box, money and law. A catastrophic cyber attack would generate changes or problems in all four of these areas.

McConnell then proceeded to explain the most important aspects of cyber security as he learned as Director of the NSA. The first most important aspect is authentication. The second most important aspect is data integrity. The third aspect is non-repudiation. The fourth is availability, and the least important aspect is the ciphertext itself (encryption).

Finally, the third prediction made by Admiral McConnell was that the United States would reengineer the internet. He explained how the military uses the internet and predicts that the entire national network will be implemented in a similar manner in the future. Concerning the government, it is McConnell’s belief that the government can help to implement the redesigned and more secure network.

Teaching as an adjunct faculty member, even at George Mason is a labor of love: the pay is not great, but the job definitely has rewards. One of these rewards is to see how bad a job we are doing as an industry in teaching people about security awareness. I teach a course on how to develop secure software. In my opinion, this is a “101” level course. At George Mason, it is listed as 600. The quality of the code at the beginning of each semester is interesting. Some code is very well structured and most of the code is not that bad, but the security awareness is not there. When you teach security awareness to the students, the quality of the code improves. Especially when you give them the techniques on what to watch for, and the methods and the mechanisms that can be used to avoid those challenges. This is not what this talk is about.

This talk is about the end result, and what happens after you do that [give them the tools and techniques], even when we spend this time, a full semester, 15 weeks of concentrated effort. By the way, they write a ton of code, which is one of the challenges about the class—let me just describe this one problem, since this talk is likely to run somewhat shortly anyway:

Right now, I have students writing programs. I give them a specification and they write a program back to me given that specification. And the only way I can think of to grade it is to actually do a code analysis. To actually look at it and do the testing myself. Then I come back and identify the vulnerabilities at the code level, because if I don’t do it at the code level, how could they possibly learn what they messed up ? And that’s “killing me”. I spend at least 40 hours every time a program is turned in by the class. And I guarantee I am not hitting every vulnerability. If anybody has a way of structuring these assignments so that I can get the same points across, I am all ears. We will leave this as an aside.

At the end of the class, even with the folks that I consider to be good coders, there are still vulnerabilities that are creeping in. Especially into the more interesting and full featured assignements that we give out.

The students spend the second half of the semester writing something big. This year they had two choices for the final assignment. The first choice was a network enabled game, which had to be peer-to-peer, between two machines, running across the network. They could choose the game. I am always interested when people choose really bad games.

Quick thing: in any game, the idea is that there is an adversary actively trying to compromise the game, and the software has to defend against that. Don’t choose random ! Random is hard in that environment. You want to choose chess. Chess has a defined state: there is no randomness in chess. If people choose games like poker, it is a bad idea: who controls the deck ? There are ways to work around that though.

The second choice of assignment was a remote backup service which, surprisingly enough, about half the class chose to do. I think conceptually they can get their head around it. I thought it would be a harder assignment.

These projects turn out to be non-trivial: there is a lot of code written. I think the most lines of code we saw was on the order of 10,000 lines of code, which isn’t huge by the standards of industry, but certainly is pretty big for a classroom project. Some of the submissions were much smaller. Some people try to abstract away the difficulty by using whatever Microsoft libraries they can find to implement the project functionalities, which caused its own difficulties. Most of these projects, by the way, were the worst from a security perspective. Not because the Microsoft technology wasn’t good; actually Microsoft has done some pretty cool stuff when it comes to security APIs, but the students did not understand what the APIs had to offer, so they called them in ways that were truly insecure. This is another challenge that we get: understand the underlying base technology that we rely on is a major challenge.

So, this talk —back to this talk…

This talk is about what we do after we’ve already done some level of training and started focusing on security, to keep our products more secure over time. Because, frankly, our economy (this is a bad time to say this of course) isn’t a big smoking hole; some people would say it is. The impact of software vulnerabilities definitely impacts on the economy. There is a great book called Geekonomics by David Rice. The major thesis of the book is that the cost of vulnerabilities in code is actually a tax that we all pay. So when you buy, say, Microsoft Office or Adobe Illustrator, whatever tool suite you’re on, all the vulnerabilities and bugs in that are paid by every user and every person that gains service through the use of these tools. We are paying a huge cost. Because all of us are being taxed, we don’t see it. It is a very big number. Every once in a while it becomes specific. I have worked for the banking industry. You have to love these guys, because you do not have to make an ROI argument with them when it comes to cybercrime. They’re either experiencing fraud or they’re not. If they’re experiencing fraud, they know how much. In the case of fraud, the numbers are high enough that, even as a CEO used to seeing big numbers, you would pay attention to them. By the way those banks are still profitable, some of them.

The thing is, if all that fraud is happening, who is paying for that ? Eventually, the cost of fraud has to be passed on to the consumer for the bank to remain profitable. So, again, the point I want to make is that we are all paying this price.

---

Some of the pre-conceptions I had before preparing this talk turned out to be false.

The main question of this talk is “How are we doing as an industry?” Is software trending towards a better place or a worse one? My position when I started preparing this talk is that we are going towards a worse place. The thought around that is that we are trending towards more complex systems. Why is that happening ? I’ll argue with numbers later; these number show that software is getting at least larger if not more complex.

Question: “How do you sell version 2?” Actually, “How do you sell version 9?” (since nobody has version 2 anymore). So how do you sell the next version of a software? You are not going to sell version (n+1) with less features than version (n) in this market. You have to add something. But most of the time we add something, that means more code. There is also all that engineering work that goes into maintaining that code over time. There is no economic incentive to buy version (n+1) if it does not provide something new besides a new pretty GUI. I guess this did not work too well with Vista. In theory it works. Actually, have you seen the Windows 7 interface ? That is actually pretty cool. I am currently being blown away by how the interface on my Mac increased my productivity, after just a few weeks. I think 7 might give Microsoft a leg up in that area. But I digress.

So, software is getting bigger because the vendors who produce the software for us, by and large, need to add features to the products to sell it to us. That’s one reason. A couple of other things though:

• If we are getting bigger, are we getting more complex. And if we are getting more complex, does that actually affect the security question? That was the underlying thought behind this talk.

---

To the left, this is the only code I can write and guarantee it comes out bug-free. [points to “Hello, World”, with character encoding issues]. There is a joke there…

But that’s not like average code. Average code looks more like the code on the right [points to cryptic code: deeply nested, and dense]. By the way, in fairness, I “borrowed” from the recent winners of the C obfuscation project. But I have been handed code that is at least that ugly. When you start trying to understand that code, you are going to find out that it is nearly impossible to do so. It really matters how much you focus on the readability and legibility of your code. Architecture matters here. But as you get bigger, chances are that even with good controls, you are still going to wind up with increasing complexity.

How many people think they can pick up bugs in the right hand side given an hour to do it? How confident would you be?

I read a lot of source code. By the way, one of the reasons I teach the class is to keep touching source code. Even with the course I teach and all the time I spend doing it, I am not going to find it. Now, there are tricks you can do from a vulnerability perspective. Following the inputs is always a good idea. I do not necessarily have to read every line to find the most tasty vulnerabilities in a piece of code. Nonetheless, that is kind of ugly [obfuscated code on the right] and there is a lot of ugly in the products we use every day. So we have to account for that.

---

Here is what a few bright guys in the industry have to say about this. [list of a few quotes on the slide including one from Dr. Gene Spafford]

This is a general acknowledgment that complexity is the driving force behind some of the problems that we have. What do you all think ? Is it real, is it fake ? There are pretty outrageous claims being made here. I like the second one: “Every time the number of lines is doubled, the company experiences four times as many security problems.”

Do you buy that ?

If that is the case, pardon the language, but we are screwed. We can’t survive that because the level of changes that we are experiencing in the code base that we are sitting on are following something like Moore’s law. The period at which code bases are doubling is much longer than a year and a half [Moore’s law], but it is occurring. So, if we project at five years, that would be a fairly reasonable time to expect that we will be sitting on something twice as big as what we’re sitting on today, unless it all comes down and crashing and we decide we have to get rid of legacy code.

If we are increasing by four times the rate of security problems, we are in serious trouble. So the questions are:

1. “Is that true?”
2. “If it is true, or even partially true, what do we do about it ?”

---

There is research that tries to correlate complexity and security faults. Surprisingly, this is an underexplored area of research. There was not as much literature in this area as I was expecting,but there is some. Some of it comes from Industry and some of it comes from Academia.

The first one comes from academia and it does find some correlation between complexity and security. One of the interesting things about that paper is that it actually went in and looked at a number of different complexity metrics. A lot of people use source lines of code but these guys actually looked at several different ones. Some perform much better than others at predicting vulnerabilities in the experiment that was run, which is a relatively small experiment.

The next one is an industry line. These guys sell a tool that looks for, in an automated sense, for software vulnerabilities. By the way, I really wish that these tools were much cheaper, because they do work ! They actually are cool products. Do they find every bug? Absolutely not: they have very little concept of the context. So I find vulnerabilities in the code of students who run Fortify and Coverity and Klocwork against their code all the time. The thing is, these tools do find vulnerabilities, so they reduce the total count of vulnerabilities. And everytime we close one of these vulnerabilities, we close a window to the attack community. So I wish these tools were cheaper and therefore more commonly used.

So, these guys [next reference] run their experiment over a fairly large codebase. They pulled a number of open source products and ran their tools against them. They found a very large correlation in their experiments between lines of code and not just the number but the rate of software vulnerabilities that were being discovered.

So there are some folks on the pro- side.

---

We have some folks on the con side. Very interesting paper out of MIT where they went through multiple versions of OpenBSD and looked at what happened to the vulnerability rates over time. And they showed pretty much the opposite. They showed a trending of vulnerabilities down over time. I have a theory for why this is. This is one of the surprising things as I got into this paper I was trying to figure out what was going on there, because that seems counter to my intuition.

There are some other folks at Microsoft who would say “Look at XP and look at Vista, it’s night and day. We got religion, we got our security development lifecycle going on.” By the way, I believe they deserve a huge amount of credit for doing that. You could say it was a response to a market demand, and that’s probably true. But they did it and they have been a pretty strong force in the industry for pushing this idea of secure development forward. I’m not in any way, shape, or form an anti-Microsoft guy, although I really love my Mac. They’re showing a system (Vista) which is larger but has fewer vulnerabilities.

This is interesting: we have people looking at this problem hard and they are coming up with entirely different results. That got me thinking, as I was preparing this talk, “What is actually going on here?” I think I have a few ideas as to why we are getting these divergences.

---

One thing is that source lines of code is probably a very poor measure of complexity. If I have a program that never branches and is a thousand lines long, chances are it is going to be pretty easy to analyze. But if I have a program that has a bunch of recursive loops in it, and they are chosen based on random values and interact with threads that have to synchronize themselves over a shared database. Someway, it is going to be more difficult to get your head around that. So there are lots of different ways to measure complexity. Examples include:

1. Size
2. Cyclomatic
3. Halstead metrics
4. McCabe metrics

I think this is an area that ought to receive more focused attention in research. We ought to spend more time trying to understand what metrics should be applied, and in what context should they be applied to understand when we’re getting past our ability to successfully control quality in a software project. I think this is a very interesting research question. I do not know how you feel about that, if that is something that people should chew on. I spent a lot of time crawling through IEEE and ACM in preparation for this talk. Frankly, i was a little bit underwhelmed by the number of papers that were out there on the subject. So, to anybody working on their doctorate, anytime you find a white space, this is a good thing. And this is a very focused research area. It is very easy in one sense to run an experiment. The hard part is actually in understanding the difference between discovering a vulnerability and understanding how many vulnerabilities are likely in a particular population of code.

---

So, let’s talk a little bit about size. Again, source lines of code are probably not the best measure. And by the way some vendors publish the source lines of code for their products and some don’t. So some of these numbers are better than others; some of them are estimates. Microsoft has started publishing the numbers for Windows. So we have: * 40 million LOC (MLOC) in XP, depending on which version we are talking about * 60 MLOC in Vista, although some people would say higher.

These are pretty large numbers. If you told me my car had 60 MLOC on it, I probably wouldn’t drive it. As an interesting aside, has anyone driven a BMW 7 series? Nice car, right? They had huge quality problems when they were first shipping, mainly the German version, before it came over. Anyone know the story behind this? The cars would crash. I don’t mean they would hit something. The computers in the car would crash. And at that point you could not re-enable them. They were dead; they had to be towed off the road and the computers replaced.

Prof. Gene Spafford: “I had the first series and the windows system onboard, while the car was sitting in the garage, thought it had been in an accident and disabled the car and actually blew the explosive bolt on the battery on the starter cable. So I had the distinction of having the first BMW 7 series in the Midwest towed to the dealership”

Dr. Ron Ritchey: “Don’t you find it ironic that somebody in you position, with your standing in industry, is the guy that has the BMW that blows itself up because of a software fault ?”

Prof. Gene Spafford: “Somehow, it seems very appropriate… to most of my students”

Dr. Ron Ritchey: “I think that’s brilliant.”

Someone in the audience: “Was it actually a security fault ? Wasn’t it actually one of the students who didn’t want you to come to class ?”

Dr. Ron Ritchey: “Well, a failure mode is a failure mode.”

[more joking]

---

So, how fast are these things growing ? Between versions, quite a bit. Windows, if we go way way back to NT4, some numbers show around 8MLOC; the number I got for this talk was 11, so I went with it. XP, 40MLOC. That’s twice twice. [discusses also Mac OS X, Linux, Internet Explorer]

The point is that a lot of different products are getting a lot more complex. I shouldn’t say that. They are getting larger. But there is strong evidence to suggest that structurally, if you do not focus on it, larger does actually equal more complex. I do need to be a little more careful here. One of the pieces of belief I’m attempting to prove is that the reason why SLOC as a metric are showing that sometimes things get better and sometimes things get worse, is probably because SLOC is not the measure we should be focusing on. Unfortunately, it’s very hard for an outside researcher, unless you work for Microsoft, or you work for Sun, or you work for one of these companies that produces these large code blocks, to have access to the source code in order to run these different metrics and track the performance of these metrics over time. I think that it would help a lot if we could get these metrics published and used better, to correlate these tools.

---

This is a simple experiment that we ran for the talk. We basically took a number of different versions of Windows and we went into the national vulnerability database NVD, which is a wonderful program run by NIST. They track all vulnerabilities they can get their hands on. They do analysis of each vulnerability, and they put them in this database that is accessible to anybody (to you, to anyone), to do research. This is really useful data. So we pulled the data from NVD.

---

This slide shows vulnerability discovery over time and each one of the different lines is a different product. [# of vulnerabilities vertical per year, years in horizontal; one curve per product, with the product’s release year as the origin of the curve]. You need to take a second and look a this to realize what is going on. The bottom one where the line jumps up and then kind of bounces at the bottom a little bit, that’s 95. With 95, you saw a little bit of bump when the product was released and then a flat line. What’s going on there? Is Windows 95 a really solid secure product? No. But keep that question in your mind for a little bit. When we start getting to more modern operating systems and look at the curve for XP for instance, it goes up. Notice that it spikes up initially and then it continues to spike over time. In my opinion that is an unusual curve, because that was when Microsoft was starting to develop an appreciation for security being important. If you look at Vista, unfortunately this hasn’t been out that long, we have a huge spike at the beginning. If we look at NT, we see a more classic curve: a lot of spikes in the early lifecycle of the product and then it dwindles down. That dwindle could happen for two reasons. One, nobody cares about it because they are not running it, so vulnerability researchers go away, which I think is a factor to keep in mind. But I also think that the code base that these products are sitting on is being mined out.

For the vulnerabilities that are being discovered, there is this concept of foundational code versus new code that I’ll get into. It’s really interesting that in the first two years we are seeing this spike in vulnerabilities. The count at two years for Vista was around 75 vulnerabilities. In fairness, I did not distinguish between root-level compromises and more minor issues. This is just raw numbers. You might get a much different analysis if the only thing you cared about was root level compromise. This is not an argument that there aren’t techniques to reduce your risk. Fortunately, there are. This is an argument about our ability to control the number of faults that we write into our software, that result in vulnerabilities over time.

---

[graph showing the cumulative number of vulnerabilities (vertical axis) for Windows products over time (horizontal axis)]

This is an interesting graph: it represents the cumulative number of vulnerabilities over time. The fact that you have numbers going up left to right in this graph isn’t really that scary. But what you want to see is the rate of change over time [the rate of discovery of vulnerabilities] decreasing. You want to see these curves flattening as they reach the right. That’s a good thing. When you see stuff that is accelerating forward, when the curve of your graph is going positive, that’s not a good thing. What that says is that you are not managing complexity well, you are not managing the security well. Vista hasn’t been long enough to figure out which way it is going to curve. XP had a pretty bad history, as did 2K, though you can see it starting to flatten out. And NT is following the curve that we would like to see: it is starting to flatten out as we go to the right.

---

The last thing that we want to show is cumulative vulnerabilities versus complexity. So this is the slide that attempts to answer the question are we getting worse or better. And, again, because I do not have better data, I have to use source lines of code. As we get to more source lines of code, what is happening to the rate of vulnerabilities that we’re experiencing? They are pretty clearly going up, and the rate at which they are going up is not linear in many cases. There is a curve occurring here. Whether when we got to 120 MLOC it would flatten out or not, we don’t know. What this data tends to suggest is that as complexity goes up, the total count of security vulnerabilities goes up at a rate greater than the linear extrapolation of the number of source lines of code.

I am not going to try to make a proof out of this; it’s a thought exercise. The thought is “Hey, this might be true.” The sum of the evidence seems to suggest that’s true.

So the result suggests that complexity does matter. And actually it contradicts some of the data that has been coming out by industry saying that “We’ve got religion, SDL [software development lifecycle] is working”, which, by the way I think is probably a true statement, but it’s not true enough to completely eliminate this problem. Interestingly enough, why are some of the numbers different ? Let me get into that.

---

There is this notion of foundational code. Foundational code is the code that is shipped in the initial release or at least exists in a particular version of a product. As that product moves forward and more things are added to it, that new code, those patches, the things that we change, those aren’t in the foundational code. Those are in the new areas. We need to be careful figuring out what is going on when we have foundational code versus new code. We can have two or three different scenarios.

In the first scenario, you have foundational code, say 10 MLOC. Version (n+1) comes out and you have 20 MLOC, and the new code is just a superset of the old code [diagram with two concentric circular areas]. In other words, all of the foundational code still exists in the product.

The other extreme you could have is when new code merely replaces foundational code, which is no longer being used in the product [diagram with a small and a large circle that barly overlap, small being the foundational code]. The first case is much more likely to happen, because once you have a library written … I don’t know if you maintain your own personal libraries of code; I probably have code that I wrote when I was a senior in high school, because it just works. So foundational code tends to be sticky. There are probably lines of code running in Windows 7 that Gates wrote back in his graduate days.

The interesting thing with foundational code is that when we find problems in it we fix them. Sometimes when we fix them we break other things, but over time the quality of foundational code improves. It has to: we’re not that bad. In fact, once we find a problem, if it’s a class of problems, we often go looking for other examples of that same class of problems in our code. So one fault in one section of the code can actually make larger chunks of the code better. So this notion of foundational code is somehing that we need to keep in our heads. As we go out we figure, “Hey, I’m gonna ship version (n+1)”, I might want to ask myself: “Did I only change my code at the margins that make the user experience a little bit better? But most of the code that I’m shipping is actually code that has really gotten through the rigors and the experience of a lot of peer review, a lot of time to stress the code” Or, “did I throw out everything else and start from scratch because maybe my foundational code was so bad that I needed to do that?” Maybe there are other marketing reasons to do that.

But I have to have a notion of how much of the product I am shipping is foundational code versus new, because that is going to affect the vulnerability rate that it is going to experience over time.

---

Another issue that we need to worry about, say that we are about to ship version (n+1), how many vulnerabilities are in it? 2, 12, 2,000? What you have to worry about is how many people care, how many people are looking. If you have a non-popular product, a niche product, the number of people that will focus on it is probably directly correlated to the number of people that really don’t like you. What I mean by that is that people need to have a reason to target the smaller set of groups that are using that tool.

An unpopular product is not going to experience the same level of scrutiny.

---

Now, if you are Internet Explorer, there will be a lot of folks focused on you. And this skews our data horribly. If you are trying to compare the fault rate between IE and Opera, that’s a difficult thing to do because, while people care about the security of Opera, people in the attack community are business people. [the day before, the “fireside” conversation touched on the “professionalization of the attack community”]. They are business people that like not to follow the rules. (Of course, some of these people live in countries where the rules are written differently.) They invest in what they can get a return on; they are very good at this. And, if you are going to choose where you are going to invest your money, as an attacker, what do you choose? Do you choose IE or do you choose Opera? Well, up and until the point that Opera has a market share that is similar to IE, you are going to choose IE, because you get a bigger bang for your buck. So, this is something that we need to keep in mind.

---

Another thing that we need to worry about is that having the vulnerability reporting, itself, turns out to be really difficult to get right. One problem that we have now, is that the vulnerabilities are not being published. There are commercial organizations and a black market that are perfectly happy to pay you to release your vulnerability only to them, and it does not get into tools like the NVD [national vulnerability database]. This is one of the challenges that we have. A lot of the really good vulnerabilities that are being discovered are being sat on. So, we are not learning about them at the same rate that we used to. It used to be that tools like metasploit would be up to date very quickly with new vulnerabilities, but it’s slowing. It’s slowing because you can hand that vulnerability over to the black market and get 10.000 dollars, sometimes more depending on what product is being targeted and how “cool” the attack is —cool being an operational term.

There are other problems: it’s very hard sometimes to [identify] two different bug reports, two different fault reports, that actually are the same vulnerability but they were expressed in differet ways. So, the data that we collect, itself, can be somewhat challenged. Also, we don’t always know when these things are truly closed up. Sometimes the fix dates are published because, when you get to “Patch Tuesday” and your box reboots, they might have told you about all of the vulnerabilities they just patched; they might not. The same thing happens with all of the folks. That’s an operational security decision. So, again, not all of the data is getting to us, so you have to take some of this with a grain of salt. But, again, I am making an argument about the large numbers; not trying to make sure that every single fact that I have is 100% correct. It;s more of a trend that I think demonstrates the concept.

---

There are some industries that are much more careful about their development process than others. And when you look at the fault rates, their fault rates are actually much lower than our experience by industry as a whole. In this case I am refering to safety critical [faults], and aerospace is a good example of this. Now, there was an incident with one of fly-by-wire airplanes that recently crashed in London. [Prof. Gene Spafford helped clarify that it was an Airbus 340. It is actually a Boeing 777, flight BA038. So, there have been accidents caused by software faults in the aviation industry. But, by and large, their fault rate is pretty darn low.

In fact, their is a project that my academic advisor was involved in, which was TCAS II. TCAS II is a system where, if two airplanes are on a collision path, there are transponders in both aircrafts that negociate with each other and give the airplane directions to deconflict themselves. So, the TCAS alert will go off and say “This airplane, dive, go left”, and the other will say “Climb, go right”. The thing is, you have to make sure that both instructions are right. There has been one accident, where the TCAS system went off and announced directions, and air-traffic control said “No, the TCAS box is wrong, do what I said”. The pilot chose to follow air-traffic control and, indeed, collided. It was a pretty bad accident. The TCAS system was actually correct; it came with the right decision. There has never been a case where TCAS has given the wrong answer in an operational setting. So, the point is that if we focus on this, and train for it, and actually run complexity metrics against our code and measure it today, we can get better. Unfortunately, it is costly: there is a price to be paid. And can we, as a society, afford to pay that cost for every product that we rely on. The answer is probably no. But, I get back to the point I made earlier: are we truly calculating the cost of faults in the products that we rely upon today ?

---

There are lots of different reasons why managing complexity is hard. I’ve just listed a few of the examples. [slide would help here].

You can’t manage complexity in an ad-hoc development environment. Just throwing code together without any idea of how you are going to collaborate, how you are going to compare, how you are going to define interfaces, how you are going to architect your code, is … madness. It does not work. That’s another thing I learned from my class. Most of the assignments are written as individuals, and the quality of that code is directly tied to the quality of that individual developer. As soon as they get into project teams, things get a lot more interesting, because the faults start showing up at the integration layer, as opposed to the unit level. So, when we bring development shops together, especially large development shops, if you do not have a lot of good process behind your development, you are not going to manage complexity well.

---

Here is the point that I wanted to get to: if you really focus on security and in general software faults management, you can actually write code that is of higher complexity, without necessarily injecting a lot of security faults into it. But the problem is, you have to know how good you are before you do that. If you have really good development processes, if you have smart developers that thave been trained, they’re security-aware, they’re quality-aware, they’re writing code. [the slide presents curves with different slopes and asymptotic behaviors] You might be able to have —the bottom axis here is complexity, driving up in complexity— [the vertical axis is the number of faults] …

The bottom line is the mystical beast: you write larger code and actually get higher quality. [the curve decreases from left to right]. I would say that if you could be on these first two lines [constant curve and slow linear increase], you are doing very very well. The idea here is that you want to measure the complexity of your code and you want to measure the fault rate that you are experiencing once you ship the product. This is going to take years to get good numbers for any particular organization. But once you know where you are at, from a maturity standpoint, and once you have decided what you are willing to pay for in terms of your development processes, you can place yourself somewhere on this graph. Based on that you are going to have to make a decision of how far along on that complexity curve you are willing to tolerate [faults increase with the complexity], and your customers are willing to tolerate from a vulnerability perspective. If you are that top line [at least quadratic growth] or worse, you don’t want to be doubling the complexity of your code in the next five years, because youre vulnerabilities number is not going to double but to quadruple. You are going to be that “four times” number that we saw a couple of slides ago. If you’re instead on one of these slow-sloped lines, maybe you can double the complexity of your code and still successfully manage the vulnerabilities that you’re exposing. But unless you measure that, unless you’ve looked at it, it’s all ad-hoc. It is faith versus true.

So I am making, I hope, a plea here. As you go out, as you start looking and working on real world software projects that are going to translate into code that large numbers of people run, that you know where you are on this graph.

So, conclusions:

One thing is that the initial code release, the foundational code, that’s where most of the bugs are introduced. The lesson here is, as you’re releasing large chunks of new, that’s when you need to focus really tightly on this question. When you’re just doing the maintenance-side of things, that’s a little easier. But that initial chunk, all the numbers show —the research is in fact pretty consistent in this area— that large chunks of foundational code is usually where most of the action is from a vulnerability perspective.

Complexity does impact vulnerability. I strongly believe that. I don’t believe that source lines of code (SLOC) are a way to go. I believe that we need better complexity measures that correlate better to security faults. I do believe complexity drives security.

This is an important one: foundational code is increasing in size rather rapidly. So, again, not Moore’s law, but about every five years it appears to be doubling, at least with the large products that we are using every day. And our ability to prevent vulnerabilities from increasing at the same rate is directly related to our ability to put ourselves in the right curve [referring to the graph on previous slide] and then potentially make some hard choices. Because, I have two large options.

If I discover that I am on one of these high-slope curves, one approach is that I can invest more heavily in my software development processes. I could invest more heavily in training my developers. I could invest more heavily in measuring the complexity of code as I am doing it, and maintaining it over time. I could walk closer to the kind of standards that are used in the safety critical world. So I could put myself on a slower slope, and I could say “OK, my customers need more complexity because that’s what is going to sell. But to do that I am going to need to invest more heavily in my software development process.”

The other option is: I have to choose to release products that have the same complexity as version (n). And really what that means is that I am going to choose to give up some functionnality that i would normally like to release. And that’s a very hard decision to make. But, as consumers, we have some ability to control that as well. By the way, one of the things that the software industry has been doing over the last year and a half to two years is moving away from charging you for software. Software as a service: big move. You are not being charged for software; you are being charged for the use of the software. I actually think this is going to be a good thing in the long term for security. Why ? Because there is a profit motive for maintaining that software and keeping it up and reliable over time.

Same token: anybody bought Oracle or any of these large products recently ? They’ll add: you want some new Oracle feature ? Fine, they are almost not going to charge you for it, but they are going to charge you for the maintenance. 25 percent a year. That might be annoying to you but it is changing the economics behind software development pretty dramatically. I think it’s in the right way: a way that starts shifting the focus to what the customers actually need as opposed to adding features just so that you will buy the next version. (somewhat of an aside).

The last option which, I’m afraid, is the default one, is that you don’t care. You go ahead and you release the product that has the increased complexity. You probably don’t know what part of the curve you’re on. And because of that, we are moving towards a world where the complexity [vulnerability?] rates are increasing as opposed to decreasing. Frankly I think that some of the reason the curve of the vulnerability rate flattens out is because there are only so many vulnerabilities that you need as an attacker to get where you want to be. So there are a numbers of reasons why that curve might flatten, which are beyond bugs simply disappearing. So with that, I would open up to thoughts and questions.

Links

• IATAC
• Booz Allen Hamilton
• Geekonomics, by David Rice
• Static code analysis tools for security:
  • Fortify
  • Coverity
  • Klocwork
• National Vulnerability Database
• The Metasploit Project
• British Airline’s Boeing 777 crash in Heathrow Note: My curiosity got spiked. Actually, the crash was due to icing of the fuel lines, as reported by the Air Accidents Investigation Branch
• TCAS II

A keynote summary by Gaspar Modelo-Howard.

Dr. Ronald W. Ritchey, Booz, Allen and Hamilton

Ronald Ritchey is a principal at Booz Allen Hamilton, a strategy and technology consulting firm, and chief scientist for IATAC, a DoD initiative to provide authoritative cyber assurance information to the defense community. He spoke about software complexity and its relation to the number of vulnerabilities found in software.

Ritchey opened the talk sharing his experience as a lecturer for a secure software development course he gives at George Mason University. The objective of the course is to allow students to understand why emphasis on secure programming is so important. Using the course dynamics, he provided several examples on why secure programming is not easy to achieve: much of the code analysis to grade his course projects includes manual evaluation which makes the whole process long, even students with good development skills usually have vulnerabilities in their code, and some students insert vulnerabilities by calling secure-sounded libraries in insecure ways. All these examples allowed Ritchey to formulate the following question: How hard can it be to write good/secure software?

Ritchey then moved on to discuss software complexity. He presented the following statement: software products tend toward increasing complexity over time. The reason is that to sell the next version of a program, market is expecting to receive more features, compared to previous version. To add more features, more code is needed. Software is getting bigger, therefore more complex. So in light of this scenario: Does complexity correlate to software faults? Can we manage complexity for large development projects? And, should development teams explicitly limit complexity to what they have demonstrated they can manage?

Several security experts suggest that complexity increases security problems in software. Quoting Dan Geer, “Complexity is the enemy”. But Ritchey mentioned that researchers are divided on the subject. Some agree that complexity is a source of vulnerabilities in code. The latest Scan Open Source Report[1] found strong linear correlation between source lines of code (SLOC) and number of faults, after the analysis of 55 million SLOC from 250 open source projects. Shin & Williams[2] suggest that vulnerable code is more complex than faulty code after analyzing the Mozilla JavaScript engine.

Some researchers suggest there is no clear correlation. Ozment and Schechter[3] found no correlation after analysis of the OpenBSD operating system which is known for its developers’ focus on security. Also, Michael Howard of Microsoft Corp. pointed out that even though Windows Vista’s SLOC is higher than XP, Vista is experiencing a 50% reduction in its vulnerability count and this is attributed to their secure development practices.

Regardless of the relationship between complexity and security, Ritchey mentioned it is likely that SLOC is a weak metric for complexity and suggested potential replacements in terms of code structure (cyclomatic complexity, depth of inheritance), computational requirements (space, time), and code architecture (number of methods per class, lack of cohesion of methods).

Looking at different popular programs, it is clear that all are becoming larger as new versions are released. MacOS X v10.4 included 86M SLOC and Ubuntu Linux has 121M. Browser applications also follow this trend, with Internet Explorer v6 included 7M SLOC and Firefox v3 has 5M. A considerable percentage of these products doubled their sizes between versions: Windows NT4 has more than 11M SLOC and its later version XP has 40M, Debian v3 has 104M and v4 jumped to 283M.

In light of the different opinions and studies presented, Ritchey analyzed the Microsoft Windows operating system by counting the vulnerabilities listed on the National Vulnerabilities Database[4] for different versions of this popular system. No distinction was made between the root level compromise and other levels. From the results presented, a large number of vulnerabilities were found after the initial release of the different Windows versions. Such trend represents the initial interest shown by researchers to find vulnerabilities who later moved to newer versions or different products. Ritchey also commented on the impact of the foundational (initial release) code, which seems to have a higher vulnerability rate than later added code from updates. From the cumulative vulnerability count vs. complexity (SLOC) graph shown, lines go up so it might be true that complexity impacts security. He alerted though on need to be careful on how to judge these numbers since factors such as quantity and quality of resources available to development team, popularity of software, and operational and economic incentives might impact these numbers.

Throughout his talk, Ritchey emphasized that managing complexity is difficult. It requires a conscious cultural paradigm shift from the software development team to avoid and remove faults that lead to security vulnerabilities. And as a key point from the talk, a development team should know at a minimum how much complexity can be handled.

Ritchey then concluded that complexity does impact security and the complexity found in code is increasing, at a plausible rate of 2x every 5 to 8 years. The foundational code usually contributes to the majority of vulnerabilities reported. The ability to prevent vulnerability rates from increasing is tied to the ability to either limit the complexity or improve how we handle it. The speaker (calls himself an optimist and) believes that shift from software as a product to software as a service is good for security since it will promote sound software maintenance and move industry away from adding features just to sell new versions.

References

1. Coverity, Inc. Scan Open Source Report 2008. Available at http://scan.coverity.com/.
2. Shin, Y. and Williams, L.: Is complexity really the enemy of software security? In: 4th ACM workshop on Quality of protection, pp. 47—50. ACM, New York, NY, USA.
3. Ozment, A. and Schechter, S.: Milk or Wine: Does Software Security Improve with Age? In: 15th USENIX Security Symposium, pp. 93—104. Usenix, Berkeley, CA, USA.
4. National Institute of Standards and Technology. National Vulnerability Database. Available at http://nvd.nist.gov.