Oracle letter to Universities: Educate software developers on security/assurance!
I am delighted to point out a really interesting letter to Universities by Mary Ann Davidson, the Chief Security Officer of Oracle Corporation. It basically tells colleges and universities to stop ignoring security, and to instead include software security principles in their computer science curricula. I'm so delighted to see this letter, which has just been released to the public (it had been privately sent to many colleges and universities). Let me point out and comment on some great points in this letter, because I think this letter is really important.
In this letter, she notes that "many security vulnerabilities can be traced to a relatively few types of common coding errors". I've noted that myself, by the way; simply educating developers on what the common (past) mistakes are goes a long way towards eliminating vulnerabilities. She then notes, "most developers we hire have not been adequately trained in basic secure coding principles in their undergraduate or graduate computer science programs." I agree and think it's horrific; more on that in a moment. She clarifies that this is a really important problem: "Security flaws are widely recognized as a threat to national security and to the privacy and financial well being of individual citizens, in addition to the costs they impose on us and our customers." They haven't just let this be; as they note, "We have therefore had to develop and roll out our own in-house security training program at significant time and expense." Kudos to Oracle for doing such training, by the way; far too many organizations don't do that, which explains why software continues to have the same old vulnerabilities as it did 30 years ago. But clearly Oracle cannot train the world, nor it is reasonable to expect that they do so.
She also states that "We believe that the ability to recognize and avoid common errors that can result in catastrophic security failures should be a core part of computer science curricula and that the above measures will foster such change. We strongly recommend that universities adopt secure coding practices as part of their computer science curricula, to improve the security of all commercial software, and ensure that their graduates remain competitive in the job market." To that I say, Amen.
By itself, that's great, but here's the kicker: "In the future, Oracle plans to give hiring preference to students who have received such training and can demonstrate competence in software security principles." Do you see this? Students at colleges and universities that fail to properly prepare them will be at a competitive disadvantage!
Today, almost all computer science and software engineering graduates will develop software that connects to a network, or must take data from a network... yet almost all are absolutely clueless about how to do so. Not because they don't know what a "socket" is, but because they don't know how to counter attacks. And if you're hooked to a network, or take data from one, you will get attacked.
Yet the education community (with a few wonderful exceptions) still completely ignores the need to educate software developers on how to develop secure software. "It's not my job" is not just wrong; it's almost criminal. Society is depending on the educational community to educate students in the fundamentals of what they need to know. Society depends on software, and essentially every student in a software-related field will, after they graduate, write software that will be attacked. Attacks are no longer a surprise - they are a guarantee. Yet the educational system that's supposed to prepare our developers fundamentally fails to do so. Since attacks are guaranteed, and the students are guaranteed to not know how to counter them, what other results would you expect? The basics of developing secure software should be a mandatory part of computer science and software engineering undergraduate curricula. The vulnerabilities that the students will embed in software, if they do not get this education, will lead to great loss of life and the loss of billions of dollars. Sure, schools already have a lot of material to cover, but practically nothing in a computer science curricula is as important as how to develop secure software; I can think of no other omissions in the CS curricula that cause so much damage. Don't tell me that you only teach the "fundamentals"; programming languages change, but the need for security will never go away; it is fundamental. I think computer science and software engineering departments that do not explain the basics of developing secure software to all of their undergraduate and graduate students should be shut down, as a menace to society, until they change their ways.
Oh, if you want to see more about this letter, see Mary Ann Davidson's blog article about it, "The Supply Chain Problem", where she talks about what led up to the letter, and the follow-on from it: "Last year, I got fed up enough with Oracle having to train otherwise bright and capable CS grads in secure coding 101 that I sent letters to the top 10 or so universities we recruit from (my boss came up with the idea and someone on my team executed on it - teamwork is a wonderful thing)... I am sorry to state that only one of those universities we wrote to responded to my letter... We need a revolution - an upending of the way we think about security -and that means upsetting the supply chain of software developers... To universities, I cannot but contrast the education of engineers with that of computer science majors. Engineers know that their work product must above all be safe, secure and reliable. They are trained to think this way (not pawn off 'safety' on 'testers') and their curricula builds and reinforces the techniques and mindset of safe, secure and reliable product. (A civil engineer who ignores the principles of basic structures - a core course - in an upper level class is not going to graduate, and can't dismiss structures as a 'legacy problem.')"
I would love to see many organizations banding together to sign a letter like this one. If enough organizations band together, I think many universities and colleges will finally get the message. I would expand it beyond computer science, to any curricula with a significant amount of software development (such as software engineering, MIS, and so on), but that's a quibble. My goal is not to shut down any departments (I hope that's clear); it's to repair a serious omission in our educational system. Kudos to Mary Ann Davidson, for writing the letter and sending it to a number of Universities. When I learned of it, I begged her to please post it publicly. To her great credit, she's now done so. Thanks, from the bottom of my heart! Now colleges and universities have even fewer reasons to claim the nonsense, "well, no one wants information on developing secure software." The companies that will hire your students know otherwise.
path: /security | Current Weblog | permanent link to this entry
Defining "open standards": The Digital Standards Organization (digistan.org)
Lots of people agree that we need "open standards" in information technology. The problem is, there are a lot of snake-oil salesmen who are trying to (re)define that term to mean "whatever proprietary product I'm selling".
Will we be able to choose what products we use? Will we even be able to exercise our rights (as citizens) at all? These are important questions about our future. The answers to those questions depends on whether or not we have real open standards in place for critical areas of our lives. A vendor who controls critical standards could easily decide that something that is manifestly not in our interest could be in theirs, and force us to submit to their malevolent actions. This is already a concern, and through globalization it will only get worse. We are dependent on information systems, and those who control their standards control those systems... and thus, us. It's about power; should we have any? This means that understanding what real open standards are about is vital.
In my essay "Is OpenDocument an Open Standard? Yes!", I addressed this problem of multiple different definitions by finding three widely-used definitions (Perens', Krechmer's, and the European Commission's) and merging them. After all, if a specification meets all three definitions of "open standard", then it's far more likely to be a true open standard. Problem is, with all those trees, it's hard to see the forest.
So I'm delighted to have discovered the Digital Standards Organization (digistan.org). They have a wonderfully brief definition of "open standard": "a published specification that is immune to vendor capture at all stages in its life-cycle". That can be a little mystifying, so they also provide a slightly longer definition of "open standard" that clarifies what that means:
That's a remarkably clear and simple definition, and good definitions are hard! Even better, they have posted a rationale for this definition that cuts through all the noise and nonsense, and instead gets to the heart of the matter. For example, it explains the real goals of open standards: "An open standard must be aimed at creating unrestricted competition between vendors and unrestricted choice for users. Any barrier - including RAND, FRAND, and variants - to vendor competition or user choice is incompatible with the needs of the market at large." Here's a quote from the rationale's abstract, which I think makes a lot of sense:
"Many groups and individuals have provided definitions for 'open standard' that reflect their economic interests in the standards process. We see that the fundamental conflict is between vendors who seek to capture markets and raise costs, and the market at large, which seeks freedom and lower costs. There are thus only two types of standard: franchise standards, and open standards. Vendors work hard to turn open standards into franchise standards. They work to change the statutory language so they can cloak franchise standards in the sheep's clothing of 'open standard'. Our canonical definition of open standard derives from the conclusion that this conflict lies at the heart of the matter. We define an open standard as 'a published specification that is immune to vendor capture at all stages in its life-cycle'. A full definition of 'open standard' must take into account the direct economic conflict between vendors and the market at large. Such conflicts do not end when a standard is published, so an open standard must also be immune from attack long after it has been widely implemented."
Digistan is currently asking people to sign "The Hague Declaration" by 2008-05-21. This one states why open standards are important to human liberty, in ways that non-technical people can understand. As Pieter Hintjens argues in his "Open letter to Standards Professionals, Developers, and Activists", "The Hague Declaration argues that international law and national constitutions of most democracies oblige governments to adopt open standards." If the text of this letter looks a little like Andrew Updegrove's A Proposal to Recognize the Special Status of "Civil ICT Standards" or his testimony in Texas, that's no accident; Andrew Updegrove is one of Digistan's founders.
Standards are vitally important. If we allow individual companies to control standards, then we have ensured that they will control us - and what we may do - through them. Being a non-profit helps, but even a non-profit's no guarantee; is the organization interested in maximizing implementation and competition between potential suppliers, or does it have some other motivation (such as maximizing publication revenue)?
I think making standards available at no-charge is no longer a nicety; it is a necessity for a specification to be a truly open standard. When there were only a few standards, and all products were developed by large big-budget corporations, a $100 standard was not a big deal. But today there are a vast array of standards; simply buying "all relevant standards" is becoming prohibitive even for large companies with massive budgets. And those big budgets are increasingly rare; suppliers are often small organizations or individuals collaborating together, or are in countries where those kinds of funds are unavailable. Because the world now includes so many new suppliers, anything that prevents those suppliers from using standards is simply unacceptable. Don't give me the nonsense that the money is needed to help develop standards; it's not true. I've helped to develop many standards, and I never received a penny from the publication royalties. The IETF, W3C, OASIS, and many other organizations manage to publish their standards, and have for years. The world has changed. In today's world, "publish" means "freely available over the Internet without having to register for it"; if you can't Google it, it doesn't exist. The cost of putting a specification on a public web server is essentially petty cash, and not doing so means that many (if not most) of the specification's potential users cannot use it.
Open standards and free-libre / open source software (FLOSS) are not the same thing - not at all! There are some similarities, though. From a customer's point of view, both open standards and FLOSS are strategies for enabling supplier switching (by preventing lock-in). In addition, customers often don't switch to a FLOSS product, even it's technologically superior or has lower total costs, solely because the customer is locked into an existing product due to proprietary standards (in data formats, APIs, and so on). You can choose to use open standards and not use FLOSS products, but if you use an open standard, it enables you to select a FLOSS product (now or later).
I believe, very much, in the power of competition to produce lower-cost, higher-quality, and innovative components. But competition is easily stymied through lock-in via "franchise" standards. Open standards are necessary to eliminate lock-in and bring to everyone the advantages of competition: lower cost, higher quality, and greater innovation.
path: /oss | Current Weblog | permanent link to this entry
Bilski: Information is physical!?
The US Court of Appeals for the Federal Circuit in Washington, DC just heard arguments in the Bilski case, where the appellant (Bilski) is arguing that a completely mental process should get a patent. The fact that this was even entertained demonstrates why the patent system has truly descended into new levels of madness. At least the PTO rejected the application; the problem is that the PTO now allows business method patents and software patents. Once they allowed them, there's no rational way to say "stop! That's rediculous!" without being arbitrary.
Mr. David Hanson (Webb Law Firm) argued for the appellant (Bilski), and got peppered with questions. "Is a curve ball patentable?", for example. At the end, he finally asked the court to think of "information as physical"; it is therefore tangible and can be transformed.
That is complete lunacy, and it clearly demonstrates why the patent office is in real trouble.
Information is not physical, it is fundamentally different, and that difference has been understood for centuries. If I give you my car, I no longer have that car. If I give you some information, I still have the information. That is a fundamental difference in information, and always has been. The fact that Bilski's lawyer can't understand this difference shows why our patent office is so messed up.
This fundamental difference between information and physical objects was well-understood by the U.S. founding fathers. Here's what Thomas Jefferson said: "That ideas should freely spread from one to another over the globe, for the moral and mutual instruction of man, and improvement of his condition, seems to have been peculiarly and benevolently designed by nature, when she made them, like fire, expansible over all space, without lessening their density at any point, and like the air in which we breath, move, and have our physical being, incapable of confinement or exclusive appropriation. Inventions then cannot, in nature, be a subject of property." Thomas Jefferson was a founder, and an inventor. No, they didn't have computers then, but computers merely automate the processing of information; the essential difference between information and physical/tangible objects was quite clear then.
Our laws need to distinguish between information and physical objects, because they have fundamentally different characteristics.
Basically, by failing to understand the differences, the PTO let in software patents and business method patents, which have been grossly harmful to the United States.
Even if you thought they were merely "neutral", that's not enough. There's a famous English speech about the trade-offs of copyright law, whose principles also apply here: "It is good that authors should be remunerated; and the least exceptionable way of remunerating them is by a monopoly. Yet monopoly is an evil. For the sake of the good we must submit to the evil; but the evil ought not to last a day longer than is necessary for the purpose of securing the good." - Thomas Babbington Macaulay, speech to the House of Commons, February 5, 1841.
I believe that software patents need to be abolished, pronto. As I've discussed elsewhere, software patents harm software innovation, not help it.
But here in the Bilski case we see why some some people have managed to sneak software patents into the patent process. In short, too many people do not understand the fundamental differences between information and physical objects. People whose thinking is that fuzzy are easily duped. Though clearly many people aren't as confused as Bilski's lawyer, I think too many people in the patent process have become so confused about the difference between physical objects and information that they don't understand why software patents are a serious problem. Patents should only apply to processes that directly change physical objects, and their scope should only cover the specifics of those changes. I add that latter part because yes, changing the number on a display does change something physical, but that is irrelevant. If you have a wholly new process for making displays (say, using a new chemical compound), that could be patentable, but changing a "5" to a "6" should not be patentable because "changing a 5 to a 6" is not fundamentally a change in nature. Taking something unpatentable and adding the phrase "doing it with a computer" should not change an unpatentable invention into a patentable one; the Supreme Court understood that, but the PTO still fails to understand that.
I think pharmaceutical companies are afraid of any patent reform laws, because they're afraid that a change in the patent system might hurt them. But if the patent system isn't fixed - by eliminating business method patents and software patents - the entire patent system might become too overwhelmed to function, and thus eventually scrapped. I don't know if pharma patents are more help than hinderance; I'm not an expert in that area. But I make my living with software, and it's obvious to me (and most other software practitioners) that software patents and business patents are becoming a massive drag on innovation. If we can't fix the patent system, we'll have to abolish the patent system completely. A lot of lawyers will be unhappy if the patent system is eliminated, but there are more non-lawyers than lawyers. If the pharma companies want to have a working patent system, then they'll need to help reign in patents in other areas, or the whole system may collapse.
path: /misc | Current Weblog | permanent link to this entry
Open Source Computer Emergency Response Team (oCERT)
Here's something new and interesting: the Open Source Computer Emergency Response Team (oCERT). Here's how they describe themselves: "The oCERT project is a public effort providing security handling support to Open Source projects affected by security incidents or vulnerabilities...".
They promise to keep things moving. They do permit embargo periods (where vulnerabilities are not publicly disclosing, giving time for developers to fix the problem first). More importantly, though, they have a maximum embargo time of two months; I think that's great, and important, because a lot of suppliers have abused embargo periods and failed to fix critical vulnerabilities as long as they're embargoed. These abuses often resulted in customers being exploited through mechanisms that the supplier knew about, but refused to fix in a timely manner.
Google is backing oCERT, which is certainly encouraging. Google even mentions my "three conditions" for securing software (thanks!):
This ComputerWorld article on oCERT makes some interesting points. One minor point: They worry that oCERT is using the term "CERT" without permission, but oCERT reports that they do indeed have that permission.
path: /oss | Current Weblog | permanent link to this entry
Securing Open Source Software (OSS)
I've just posted my presentation titled "Securing Open Source Software (OSS or FLOSS), which is to be presented at the 8th Semi-Annual Software Assurance Forum, May 6-8, 2008, Sheraton Premiere, Tyson's Corner in Vienna, Virginia. In it, I discuss how to improve the security of an OSS component by modifying its environment, as well as securing the OSS component itself (by selecting a secure component, building a secure component from scratch, or modifying an existing component). I include a number of examples; they're necessarily incomplete, but I hope it will help people who are developing or deploying systems. (Here is "Securing Open Source Software (OSS or FLOSS)" in OpenDocument format.) Enjoy!
path: /security | Current Weblog | permanent link to this entry
Microsoft Office XML (OOXML) massively defective
Robert Weir has been analyzing Microsoft's Office XML spec (aka OOXML) to determine how defective it is, with disturbing results.
Most standards today are relatively small, build on other standards, and are developed publicly over time with lots of opportunity for correction. Not OOXML; Emca submitted Office Open XML for "Fast Track" as a massive 6,045 page specification, developed in an absurdly rushed way, behind closed doors, using a process controlled by a single vendor. It's huge primarily because does everything in a non-standard way, instead of referring to other standards where practical as standards are supposed to do (e.g., for mathematical equations they created their own incompatible format instead of using the MathML standard). All by itself, its failure to build on other standards should have disqualified OOXML, but it was accepted for review anyway, and what happened next was predictable.
No one can seriously review such a massive document in a short time, though ISO tried; ISO's process did find 3,522 defects. It's not at all clear that the defects were fixed - there's been no time to really check, because the process for reviewing the standard simply wasn't designed to handle that many defects. But even if they were fixed - a doubtful claim - Robert Weir has asked another question, "did they find nearly all of the defects?". The answer is: Almost all of the original defects remain. By sampling pages, he's found error after error, none of which were found by the ISO process. The statistics from the sample are very clear: practically all serious errors have not been found. It's true that good standards sometimes have a few errors left in them, after review, but this isn't "just a few errors"; these clearly show that the specification is intensely defect-ridden. Less than 2% of the defects have been found, by the data we have so far, which suggests that there are over 172,000 important defects (49x3522) left to find. That's rediculous.
Want more evidence that it's defect-ridden? Look at Inigo Surguy's "Technical review of OOXML", where he examines just the WordProcessingML section's 2300 XML examples. He wrote code to check for well-formedness and validation errors, and found that more than 10% (about 300) were in error even given this trivial test. Conclusion? "While a certain number of errors is understandable in any large specification, the sheer volume of errors indicates that the specification has not been through a rigorous technical review before becoming an Ecma standard, and therefore may not be suitable for the fast-track process to becoming an ISO standard." This did not include the other document sections, and this is a lower bound on accuracy (XML could validate and still be in error). (He also confirmed that Word 2007 does not implement the extensibility requirements of the Ecma specification, so as a result it would be hard to "write an interoperable word processor with Word" using OOXML.)
I think that all by itself, these vast number of errors in OOXML prove that the "Fast Track" process is completely inappropriate for OOXML. The "Fast Track" process was intended to be used when there was already a widely-implemented, industry-accepted standard that had already had its major problems addressed. That's just not the case here.
These huge error rates were predictable, too. The committee for creating OOXML wasn't even created until OpenDocument was complete, so they had to do a massive rush job to produce anything. ( Doug Mahugh admitted that "Microsoft... had to rush this standard through.") They didn't reuse existing mature standards, so they ended up creating much more work for themselves. Most developers (who could have helped find and fix the defects) stayed away from the Ecma process in the first place; its rules gave one vendor complete control over what was allowed, and there was already a vendor-independent standard in place, which gave most experts no reason to participate. The Ecma process was also almost entirely closed-door (OpenDocument's mailing lists are public, in contrast), which predictably increased the error rate too.
The GNOME Foundation has been involved in OOXML's development, and here's what they say in the GNOME Foundation Annual Report 2007: "The GNOME Foundation’s involvement in ECMA TC45-M (OOXML) was the main discussion point during the last meeting.... [the] Foundation does not support this file format as the main format or as a standard..." I don't think this is as widely touted as it should be. Here's an organization directly involved in OOXML development, and it thinks OOXML should not be a standard at all.
India has already voted "no" to OOXML. I hope others do the same. Countries with the appropriate rights have until March 29 to decide. It's quite plausiable that the final vote will be "no", and indeed, based on what's published, it should be "no". Open Malaysia reported on the March 2008 BRM meeting, for example. It reports that everybody "did their darnest to improve the spec... The final day was absolute mayhem. We had to submit decisions on over 500 items which we hadn't [had] the time to review. All the important issues which have been worked on repeatedly happened to appear on this final day. So it was non-stop important matters... It was a failure of the Fast Track process, and Ecma for choosing it. It should have been obvious to the administrators that submitting a 6000+ page document which failed the contradiction period, the 5 month ballot vote and poor resolution dispositions, should be pulled from the process. It should have been blatantly obvious that if you force National Bodies to contribute in the BRM and end up not deliberating on over 80% of their concerns, you will make a lot of people very unhappy... judging from the reactions from the National Bodies who truly tried to contribute on a positive manner, without having their concerns heard let alone resolved, they leave the BRM with only one decision in their mind come March 29th. The Fast Tracking process is NOT suitable for ISO/IEC DIS 29500. It will fail yet again. And this time it will be final."
In my opinion, the OOXML specification should not become an international standard, period. I think it clearly doesn't meet the criteria for "fast track" - but more importantly, it doesn't meet the needs for being a standard at all. It completely contradicts the goal of "One standard, one test - Accepted everywhere", and it simply is not an open standard. I've blogged before that having multiple standards for office documents is a terrible idea. There's nothing wrong with a vendor publishing their internal format; in fact, ISO's "type 2 technical report" or "ISO agreement" are pre-existing mechanisms for documenting the format of a single vendor and product line specification. But when important data is going to be exchanged between parties, it should be exchanged using an open standard. We already have an open standard for office documents that was developed by consensus and implemented by multiple vendors: OpenDocument (ISO/IEC 26300). For more clarification about what an open standard is, or why OpenDocument is an open standard, see my essay "Is OpenDocument an Open Standard? Yes!" OpenDocument works very well; I use it often. In contrast, it seems clear that OOXML will never be a specification that everyone can fully implement. Its technical problems alone are serious, but even more importantly, the Software Freedom Law Center's "Microsoft's Open Specification Promise: No Assurance for GPL" makes it clear that OOXML cannot be legally implemented by anyone using any license. And this matters greatly.
Andy Updegrove calls for recognition of "Civil ICT Standards", which I think helps puts this technical stuff into a broader and more meaningful context. He notes that in our new "interconnected world, virtually every civic, commercial, and expressive human activity will be fully or partially exercisable only via the Internet, the Web and the applications that are resident on, or interface with, them. And in the third world, the ability to accelerate one’s progress to true equality of opportunity will be mightily dependent on whether one has the financial and other means to lay hold of this great equalizer... [and thus] public policy relating to information and communications technology (ICT) will become as important, if not more, than existing policies that relate to freedom of travel (often now being replaced by virtual experiences), freedom of speech (increasingly expressed on line), freedom of access (affordable broadband or otherwise), and freedom to create (open versus closed systems, the ability to create mashups under Creative Commons licenses, and so on)... This is where standards enter the picture, because standards are where policy and technology touch at the most intimate level. Much as a constitution establishes and balances the basic rights of an individual in civil society, standards codify the points where proprietary technologies touch each other, and where the passage of information is negotiated... what will life be like in the future if Civil ICT Rights are not recognized and protected, as paper and other fixed media disappear, as information becomes available exclusively on line, and as history itself becomes hostage to technology? I would submit that a vote to adopt OOXML would be a step away from, rather than a way to advance towards, a future in which Civil ICT Rights are guaranteed".
Ms. Geraldine Fraser-Moleketi, Minister of Public Service and Administration, South Africa, gave an interesting presentation at the Idlelo African Conference on FOSS and the Digital Commons. She said, "The adoption of open standards by governments is a critical factor in building interoperable information systems which are open, accessible, fair and which reinforce democratic culture and good governance practices. In South Africa we have a guiding document produced by my department called the Minimum Interoperability Standards for Information Systems in Government (MIOS). The MIOS prescribes the use of open standards for all areas of information interoperability, including, notably, the use of the Open Document Format (ODF) for exchange of office documents... It is unfortunate that the leading vendor of office software, which enjoys considerable dominance in the market, chose not to participate and support ODF in its products, but rather to develop its own competing document standard which is now also awaiting judgement in the ISO process. If it is successful, it is difficult to see how consumers will benefit from these two overlapping ISO standards... The proliferation of multiple standards in this space is confusing and costly." She also said, "One cannot be in Dakar without being painfully aware of the tragic history of the slave trade... As we find ourselves today in this new era of the globalised Knowledge Economy there are lessons we can and must draw from that earlier era. That a crime against humanity of such monstrous proportions was justified by the need to uphold the property rights of slave owners and traders should certainly make us more than a little cautious about what should and should not be considered suitable for protection as property."
You can get more detail from the Groklaw ODF-MSOOXML main page, but I think the point is clear. The world doesn't need the confusion of a specification controlled by a single vendor being labelled as an international standard. NoOOXML has a list of reasons to reject OOXML.
path: /misc | Current Weblog | permanent link to this entry
Twisted Mind of the Security Pro
Bruce Schneier's "Inside the Twisted Mind of the Security Professional" is highly-recommended reading - he explains the different kind of thinking required to be good at making things secure. Security pros are able to see the bigger picture, and in particular, they are able to see things from from an attacker's perspective.
For example, "SmartWater is a liquid with a unique identifier linked to a particular owner. 'The idea is for me to paint this stuff on my valuables as proof of ownership,' I wrote when I first learned about the idea. 'I think a better idea would be for me to paint it on your valuables, and then call the police.'" Similarly, on opening up an ant farm, his friend was surprised that the manufacturer would send you ants by mail; Bruce thought it was interesting that "these people will send a tube of live ants to anyone you tell them to."
Being able to think like an attacker is so important that in my book on writing secure programs, I gave it its own heading: paranoia is a virtue. It's still true. My thanks to Bruce Schneier for expressing this need so eloquently.
We would live in a better world if all of us could see the world as attackers do - or at least make the effort to try. In particular, we'd stop doing many foolish things in the name of "security", and instead do things that actually secured our world.
path: /security | Current Weblog | permanent link to this entry
OSS and the U.S. DoD - Questions and Answers
I've just posted Questions and Answers for 2008 "Open Source Software and DoD" Webinar. These are my attempts to answer the questions people sent me at my February "Open Source Software (OSS) and the U.S. Department of Defense (DoD)" Some of the questions were easy to answer, but some were surprisingly difficult. In some cases, I asked lawyers and got conflicting answers. But this is the best information that I could find on the topic.
For example, I explain in detail why In particular, it appears fairly clear that both the government and government contractors can release their results as open source software under the default DoD contract terms for software development (DFARS contracting clause 252.227-7014):
I also point out that even when the government isn't the copyright holder, if it releases software under an OSS license it can still enforce its license. That's because, even when it's not the copyright holder, it can still enforce the license... and because the doctrine of unclean hands will impact those who refuse to obey the license.
Several people had questions about software developed by a government employee (which can't be copyrighted in the U.S.) and how that impacts OSS. The short impact is that there's no problem; government employees can still contribute to OSS projects, for example. I also discuss some of the export control issues (especially ITAR), and how to address them.
If there are mistakes, please let me know. Thanks!
path: /oss | Current Weblog | permanent link to this entry
OSS and the U.S. DoD - Webinar
I'm going to present a webinar on "Open Source Software (OSS) and the U.S. Department of Defense (DoD)" on Feb 11, 2008, 3:00-4:30pm EST. It is open to the public, at no charge. To find out how to sign up, see http://www.dwheeler.com/oss-dod-webinar2008.html.
Here's the summary: "Open source software (OSS) has become widespread, but there are many misconceptions about it - resulting in numerous missed opportunities. This presentation will clarify what OSS is (and isn't), rebut common misunderstandings about OSS, discuss the relationship of OSS and security, discuss how to find and evaluate OSS, and explain OSS licensing (including how to combine products and select a license). It will show why nearly all extant OSS is COTS software, and thus why it's illegal (as well as foolish) to ignore OSS options."
This presentation is hosted by the Data & Analysis Center for Software (DACS), which is technically managed by the Air Force Research Laboratory - Information Directorate (AFRL/IF).
Please sign up quickly, if you're interested. There were 45 registrants in the first half hour of its announcement.
path: /oss | Current Weblog | permanent link to this entry