 |
privacy |
||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2004-10-12Open Source: Shrinking the Trust SurfaceHerewith, some additional clippings on security matters. These are related to trust of software in one respect or another. This supplements the earlier entries on ""Open Source: How Trustworthy, How Secure?", "Trustworthy Software Security: How Do We Get There From Here?", and "Zombie Planet: Spam and Phish Egg Harvesting." The continuing emphasis is on open-source processes and software. IST OpenEvidence for eDocument AccountabilityIST Results - Establishing an audit trail for e-business. This announcement applies to an IST project that created open-source technology for creating and processing electronic evidence. This is about trust and security and it might also be applicable not only in the implementation of eBusiness applications, but in the auditing of software development for those and other applications. I shall dig deeper. This works applies to interoperability of PKI and includes time-stamping abilities for that which I also will find interesting. (Time-stamping is important with regard to authentication of when a digital signature was made.) The OpenEvidence project site is being overhauled at this time, and there is a SourceForge project that has the developed software. Part of the OpenEvidence operation involves third-party certification of some sort. It will be interesting to see how that works, and how it fits in webs of trust and other activities. The OpenEvidence initiative has contributed elements to OpenSSL which is PKI and X.509 based. There has also been use of OpenEvidence components with cURL, a command-line copy tool that is URL based and honors HTTPS, kerberos, and other transport security and user authentication conventions.Floating All BoatsJon Udell's Weblog: Securing Windows. Udell looks at the efforts to secure Windows and challenges the simplistic assumption that open-source software can automatically achieve something that is taken ideologically as impossible for Microsoft to fix. Udell suggests that John Viega's appraisal of the myth of open-source security deserves far more discussion, and I must concur. Jon points in this interesting direction:"I'll be particularly interested to see whether SourceLabs and SpikeSource, two newly-announced companies focused on commercial support of open source 'stacks,' will include security auditing and certification as part of the value they add.I'd like to know that too, and I wonder if we will find that there are also tools for open-source developers to apply in accounting for their own security-supportive practices and audits. Software Disasters: The Human RoleACM News Service: Software Disasters Are Often People Problems. The most provocative element in this blurb is its mention of a 2002 NIST study that estimates losses due to bugs at $59.5 billion per year, with $22.2 billion savable through better testing. I am not aware of any evidence that the better testing would cost less than that, however. One can hope. It is particularly interesting that problems can be traced back to the requirements process:"The success or failure of a project often hinges on how well an organization delineates its business processes and the redesign route they follow, and communicates these guidelines to the technical team. Other factors that can lead to failures include a shortage of strong leadership, and miscommunication with project developers stemming from inadequate resource allocation, little participation of stakeholders in planning sessions, and indifferent executives."The danger of using developers to validate business requirements is emphasized as well. The 2004-10-04 Associated Press article echoes other material cited here, with the inclusion of the September 14 LAX flight-control failure. I take this article as reinforcing the attitude, which I share, that it is not just code and programming but design, system engineering, and the business setting of computer system development that must be examined for increasing the dependendability and trust of computer-mediated systems. This article also relates to the number of software systems that are still-born before we ever get to see how buggy they might be when placed in use. It occurs to me that proper risk management is lacking in either case. If We Could Just Do It Without PeopleYahoo! News - Software Disasters Often People Problems. Here's another source of the AP story. My first reading was here, and I was blown away by the rundown on breakdowns in the overall deployment and assurance processes of systems and what the impact is. This can be read as an useful testament to the difference between the problem space and the solution space as well as what happens when even the solution space is not addressed from a lifecycle and failure-behavior perspective. But one of the greatest missings in solution-oriented approaches is failure to account for the problem-space impact of the solution itself. It strikes me that it would be good to have as a mantra that any system is going to fail eventually, and the question is, how is deployment undertaken in a way that provides resilience in the face of that inevitable failure.More Secure Applications DevelopmentThis seems remarkably like some sort of echo chamber, now that I see another prospective 50%-vulnerability reduction. I wonder if this is just half of security vulnerability or half of defects generally. How would we know? ACM News Service: App Developers Need to Redouble Security Efforts. Gartner experts identify the application layer as the most vulnerable to security breaches, now that network and physical security is solved for the most part (?!). Either way, the justification for expanded attention to security by development and quality assurance teams is that elimination of 50% of vulnerabilities before going into production would save 75% in configuration and incident response costs. (There's still no estimate for the increase in development costs to gain that reduction.) It is recognized that the strong development of resilient security architectures and tools for their support is now in its infancy. That suggests to me that we are still operating with highly-speculative perspective on what makes a difference and how to institutionalize it. Esther Schindler's 2004-09-30 eWeek article provides expanded information on how weak our understanding of the economics of security are, along with identification of how attention is moving into the application layers. This is a good page for finding an RSS feed and linking to the ongoing security coverage by eWeek.Six Secrets of Highly-Secure OrganizationsSlashdot | 2004 Global Information Security Survey Results. Slashdot sightings are at least as much fun for the twists and turns of the comments as the linked material. The 2004-09-15 CIO.com article is not as much fun and it squeezes the numbers pretty hard. At the same time, there is some solid perspective along with extensive treatment of how IT is the fox in the security hen house. It is important to understand the rôle conflict here just as much as how that figures in the shipment of buggy software by practically everyone.Security: Code That Proves ItselfACM News Service: The Search for Computer Security. Harvard's Greg Morrisett thinks that programs should arrive with proofs of their trustworthy behavior. It is conceded that this kind of assistance only goes so far and we are left with the ethical, legal, and social questions and behaviors to deal with. Alvin Powell's 2004-09-30 Harvard Gazette article leads with the statement, "Morrisett says safety these days is (unfortunately) a matter of trust." I find it remarkable to presume that it can ever be otherwise, although we can perhaps, reduce the "trust surface," as it were. There is a bit more on the approach to having provable safety, especially with regard to programming-language design, and Morisett's home page provides more on the technical side. Some of the proposed tools would be interesting tests for certain kinds of general-purpose programs (e.g., having a proof the correctness and safety of a LISP kernel written in assember). I notice that I have some reservations about all of this, and I am willing to suspend judgment until more cases and applicability are understood.IP Threats to Open-Source ConfidenceYahoo! News - Copyright Battle Erupts over Open-Source 'Mambo' Code. This intriguing coverage of a copyright/contract dispute points to a number of problems having to do with IP ownership of code. There is the usual problem of programmers thinking their creations belong to them (when it is actually a work performed for hire). The risk that interests me is someone contributing copyrightable subject matter for which they are not the copyright holder. The Free Software Foundation deals with this by requiring explicit transfers of copyright along with attestation that the covered work being transferred is the IP of the contributer. Or words to that effect. We already have issues about provenance in the SCO-IBM suit, which claims that contributions were made by IBM to Linux that were contractually not theirs to contribute. Although the copyright-infringement aspect is not going so well for SCO, it does not mean that the litigation has failed. For the Mambo-Miro dispute, the bottom line of the article is that we haven't seen the last of this kind of dispute. It might seem strange to mention this in a compilation of entries on computer security, but think about it. Users want to be secure, and that means not vulnerable to damage as the result of lawsuit, not just damage as the result of an attack by other means. And, when you think about it, knowing that code has been assessed as secure would tend to mean one knows where it is from, one would hope. Otherwise, what recourse is there when the inevitable failure arises? |
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |