Risk
9/3/2013
01:30 PM
Commentary
Commentary
Commentary
Connect Directly
RSS
E-Mail
50%
50%

Software Patches Eat Government IT's Lunch

The software industry's publish-now, update-later approach exacts a huge toll on government IT leaders like Robert Jack, CIO of the U.S. Marine Corps.

In a recent article on the growing threat of software product liability for the Berkeley Technology Law Journal, Lawrence Levy and Suzanne Bell noted, "As society increasingly relies on software to perform critical functions in everything from manufacturing to life-support systems, the risk that an error in a software program will lead to economic loss, property damage or personal injury increases."

One of the big questions surrounding software liability, however, is whether computer software is a good or a service. That's important, Levy and Bell say, because "the sales of goods, but not of services, are subject to the damages and warranty provisions of the Uniform Commercial Code." The courts, however, are now beginning to consider cases involving not only the software itself, but also significant maintenance and support services, and this is likely to impact more and more organizations.

In the meantime, Jack concluded, software vendors aren't likely to change the way they develop, test and deploy their products. "I've been beating that drum for 15 years," he said. "I don't believe legislating software assurance is going to work. I need corporate citizenry to step up to the plate and take responsibility for what they put into their software."

About the only thing government agencies can do is manage their risks. The fast pace of software adoption has all but rendered the government's approach to software security certification and accreditation obsolete. In fact, "the old certification and accreditation process has been gone for three years now," said Ron Ross, a senior security official at the National Institute of Standards and Technology, during the same forum.

NIST, which sets the security standards for government agency information systems, has moved to a risk management framework that calls on agencies to perform real-time network monitoring to identify attempts to exploit hardware and software vulnerabilities. About 10% of attacks will get through defenses no matter what, Ross said.

If you know that your system can withstand a cyber-attack and that malware can't spread through the network and bring you down, he added, authorizing officials should be in a better position to accept a certain degree of risk. However, most federal agencies' inability to replace legacy systems due to lack of funding and cultural inertia makes it difficult to manage all the risks associated with so much software.

The challenge is only getting greater for CIOs like Jack as government agencies expand their networks into the cloud and extend their services to mobile devices. While those moves hold the promise of new and greater efficiencies, they also add more layers of software and the inevitability of more software patching.

Previous
2 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
WKash
50%
50%
WKash,
User Rank: Apprentice
9/17/2013 | 12:50:08 PM
re: Software Patches Eat Government IT's Lunch
There's an interesting story and commentary on the importance of, and the balance between, software developers who crank out code and product managers who are responsible for the customer experience. See "Why your software development process is broken" at: http://www.informationweek.com...
WKash
50%
50%
WKash,
User Rank: Apprentice
9/17/2013 | 12:38:19 PM
re: Software Patches Eat Government IT's Lunch
This misses the point of what the Marine Corps and other large scale organizations are facing. First, the Marine Corps can't just software A and switch to software B because software A is costing more to update/fix. Second, we're talking about high costs because of the large number of users and devices that exist. The Marine Corps works with the US Navy. Together they have more than 800,000 users on the network. Simple bug fixes and version updates may not be a big deal for an organization of 1000 workers. It's a much different and more expensive matter for large organizations.
blowenth
50%
50%
blowenth,
User Rank: Apprentice
9/7/2013 | 3:04:49 PM
re: Software Patches Eat Government IT's Lunch
I find it interesting when people complain that they are losing
money as a result of applying software fixes.



The simple answer for organizations that are losing money applying
software fixes is for the organizations to discontinue using the
software. Then they would they recover those "losses" -- right?



But, of course, they will nearly always "lose" even more money if
they discontinue using the software. Adoption of nearly all
business software products results in cost reduction of
actions that can already be performed. There is often very quick
adoption of new products that provide significant cost reductions
because the people that purchase the products can get their money
back in less than a year and then go on to get significant cost
reductions year over year. However, people still gripe because
they don't save even more because of product defects.



For example, Larry Ellison of Oracle said that Oracle saved a Billion dollars a year when it
adopted Internet technology products for HR and other internal processes. -- I believe
it. Now Oracle could have saved even more that a Billion dollars
if there were no product defects. Lets suppose Oracle saved
$1,000,000,000 but if there were no product defects they would have
saved $1,010,000,000. Now Larry could say that Oracle lost
$10,000,000 by adoption of Internet technology products --- and it
would be true using the logic of the per "Software Patches Eat
Government IT's Lunch" story.



Software, unlike almost all other products, is peculiar because
customers pay to get fixes to defects in delivered products. Why
is this? Why do customers purchase such products and then have to
pay to have design defects repaired. Lets consider to companies
building the same type of software products.


Lets say Company A gets the product out in 2010 where it is
purchased by the Bank of America. Lets stay that Company A's
product has many software defects costing BoA $10,000,000 during
the next two years. Lets say Bank of America, saves
$500,000,000 per year because of the adoption.

Lets say Company B gets the product out in 2012 at the same
price as Company A and because of the extra two years of
testing, software defects cost $0 per year and the Bank of
America starts saving $500,000,000 per year at that point.
What's the better deal for the Bank of America?

Did Bank of America lose $10,000,000 by adopting Company A's
product or did it lose $990,000,000 by waiting to adopt Company
B's bug free product?



Of course there are tradeoffs here. If the products have too many
bugs then they become unfit for use. But competition typically
sorts this out.



Anyway, the bottom line here is that when you hear about
organizations losing money because of the cost of applying fixes for
software defects, its probably not the case that the organization
lost money by adopting the use of that software. They just want to save even more -- and that is good. However, sometimes it's
good to remind people to consider all the costs and benefits.
WKash
50%
50%
WKash,
User Rank: Apprentice
9/5/2013 | 6:58:06 PM
re: Software Patches Eat Government IT's Lunch
Government gets a lot criticism for its bureaucratic ways, but it does offer a template, courtesy of the National Institute of Standards and Technology, for how software code can be certified to meet certain operating standards. Enterprises would be better served if there were standards software developers could agree to that, as you say, using an automated process, would give software the equivalent of a clean bill of health. That won't address the need for updates, as you say, but it would give customers more confidence in what they're buying. And that hopefully would led to marketplace choices that would reward the more responsible developers.
moarsauce123
50%
50%
moarsauce123,
User Rank: Apprentice
9/5/2013 | 5:04:24 PM
re: Software Patches Eat Government IT's Lunch
A bug is anything that negatively impacts user experience. That means it does not need to be a coding error. The code can be all well, but if using the application is so complicated that it will lead to many mistakes the software is buggy and needs fixing.
A big problem these days are indeed the ridiculously short times to market as well as the 'agile' methods that reward not committing to anything, no planning, no documentation, and rapid releases of something. I think we all would better served by spending a few months up front to design applications and make up our minds as to what we really want, then build that. Sure, flexibility is always needed as some aspects come up while doing the development work, but it just doesn't pan out when doing everything on the fly.
MarciaNWC
50%
50%
MarciaNWC,
User Rank: Apprentice
9/4/2013 | 9:07:41 PM
re: Software Patches Eat Government IT's Lunch
Would be interesting to see those reports Jack cites indicating that 25% of hospital operating room liability
lawsuits are now tied to software coding problems.
Lorna Garey
50%
50%
Lorna Garey,
User Rank: Ninja
9/4/2013 | 2:40:33 PM
re: Software Patches Eat Government IT's Lunch
Excellent analysis. Patches have always been painful, and seem to be getting more so. The "goods vs. service" distinction is a factor those choosing between SaaS and COTS should consider.
cbabcock
50%
50%
cbabcock,
User Rank: Apprentice
9/3/2013 | 7:30:47 PM
re: Software Patches Eat Government IT's Lunch
Software patches are often updates, not bugs in the sense of poor code needing corrections, to bring an application into line with updates elsewhere in itself or to keep it compatible with a wider set of software. We need to get to the point where software is built in such a standard fashion that updating it is a standard, and automated, process. This is where cloud vendors start to draw away in terms of efficiency from the one-of-everything enterprise data center.
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-0334
Published: 2014-10-31
Bundler before 1.7, when multiple top-level source lines are used, allows remote attackers to install arbitrary gems by creating a gem with the same name as another gem in a different source.

CVE-2014-2334
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiAnalyzer before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

CVE-2014-2335
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiManager before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2336.

CVE-2014-2336
Published: 2014-10-31
Multiple cross-site scripting (XSS) vulnerabilities in the Web User Interface in Fortinet FortiManager before 5.0.7 and FortiAnalyzer before 5.0.7 allow remote attackers to inject arbitrary web script or HTML via unspecified vectors, a different vulnerability than CVE-2014-2334 and CVE-2014-2335.

CVE-2014-3366
Published: 2014-10-31
SQL injection vulnerability in the administrative web interface in Cisco Unified Communications Manager allows remote authenticated users to execute arbitrary SQL commands via a crafted response, aka Bug ID CSCup88089.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.