Slashdot Mirror
Tech Companies Ask U.S. to Regulate Cyber Security
qtp writes "Wired reports that a group called the National Cyber Security Partnership, which consists of 'leading software companies' including Microsoft and Computer Associates and industry organisations such as the BSA, has asked the Department of Homeland Security to regulate what they call 'Cyber Security'. Representatives from Microsoft, Computer Associates, and the BSA headed the Security Across the Software Development Cycle Task Force that submitted this report to the Bush administration today. (For all of you who dread reading 123 page reports, there is a three page summary available as well. The Washington Post, Forbes, and Other Sources are covering this story as well. I hope this is just another [late] April Fools Day joke, but I'm afraid that this looks too scary to be real."
Business gets .gov to regulate security.
Regulation and "Approved By.." nonsense costs money.
MS, et al pay.
Open Source can't pay.
Non-approved things can't be used, ergo closed source wins.
Adopting a "top-ten" list detailing industry best practices. Patches should be well-tested, small, localized, reversible, and easy to install. Patches would also not require reboots, use consistent registration methods, include no new features, provide a consistent user experience, and support diverse deployment methods.
I thought Microsoft was involved in the partnership. How is that going to work??
This is not a troll. MS patches generally violate some or all of the goals stated above.
I want to drag this out as long as possible. Bring me my protractor.
Big businesses like regulation. It costs them, but it costs their smaller competitors more in relative terms.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
The proper way to improve security is invalidate all those EULA disclaimers.
You've noticed the same kinds of disclaimers on the GPL, yes? If the warranty disclaimer on a Microsoft license is invalid, what makes the one on the GPL valid; and if it is not, then how would, say, the contributors to the Linux kernel fare if they were sued for a major security breach?
Yup, that was pretty much my take on things (Rule 1: industry *never* asks for regulation without an ulterior motive), although I think that there's a bit more to it -- if any cronyism can be used by existing players, it might be a useful tool against challengers, forgetting about Open Source for a moment.
I'm all for the government issuing advisories, but regulation of security is not feasible. I remember reading about older military software -- the government used to try to do much more comprehensive security reviews of all kinds of software it used with tiger teams. Unfortunately, it turned out the extreme expense of this kind of thing isn't feasible in the real world, and still left holes.
If I had to give a government recommendation, it would probably be along the lines of:
* Issue advisiories. There are organizations like CERT that do this. Unbiased (not from a vendor), trustworthy information is difficult to come by.
* Issue best-practices papers. These are probably most useful to IT professionals, though it might even be a good idea to produce them for software developers. Microsoft recently collaborated with the Fed to produce a set of best security practicees documents for Windows. This is an easy thing to add to a company security policy ("[] must comply with USG Document #135F3 Best Practices"). It just tried to deal with a couple of common misconfigurations. It's *hard* to get this kind of stuff directly from a vendor (which frequently wants to hand out information that will encourage you to buy more or is more interested in putting a positive spin on their mistakes) or a consultant (who frequently wants you to buy more consulting services) or a security software (like a firewall) company, which is primarily interested in scaring companies into thinking that they need security software.
* Government certification of software intended for non-government use is a bad idea. It takes a long time, allows cronyism, can be used to attack some sections of the market (like most Open Source). It's perfectly reasonable for USG-use purchase requirements, but it's not reasonable for broader use.
* Producing a classification system *could* be very useful, where the government writes documents describing particular classes of software, but it not responsible for ensuring that a particular version of a program fits into a class of software. For example, a hypothetical class-local/1 might require that:
a) The software bounds-checks all memory accesses to data at the compiler level (free with some languages like Java, and can be done in C if necessary).
b) The software does not access the network.
c) The software does not write to any data files.
Others useful requirements for various classes of software might be: "The software does not provide privilege escalation within the UNIX operating system's privilege system (as a suid/sgid program or a daemon running as a different user does...there would be an equivalent for the Windows security system)", "All data that the software uses from the network is either exact-match checked or bounds-checked prior to use of any of that data, and a failure to pass checks results in that data not being used" (might be useful for simple network software, like clients of the daytime protocol). The government is great at writing requirements and making them publically available--let's use that. Then, if a company guarantees that they are compliant to a particular document in a contract, there is a clear point that they can be called on for non-compliance. Finally, there would be a market for software that can check software for some elements of compliance. Automated security checking is a major issue -- it's neat, it's more and more feasible (see CMU's Java proof-carrying compiler for some neat stuff. The problem is that there are currently no standards written by security folks who know what they're doing, so it's hard for businesses to ask for compliance to a particular level of security, and no tools that can certify programs to a particular level.
There are probably a lot more suggestions that the government could use, but this is a start...
May we never see th