Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/21/2010
12:31 PM
Alexander Wolfe
Alexander Wolfe
Commentary
Connect Directly
Facebook
Twitter
RSS
E-Mail
50%
50%

Sloppy Software Dev Exposes Google Hacker Holes

I've ranted on the subject before, but it's worth sounding off again in light of the recent China hacker breaches of Gmail: Poor software development procedures are the big reason major firms are apparently running around scared witless that their products are vulnerable to cyberattacks. (The corollary, about which we haven't read anything, is that firms with buttoned-down dev rules are likely feeling, if not entirely safe, then at least free of the panic which plagues the cluelessly unprepared.

I've ranted on the subject before, but it's worth sounding off again in light of the recent China hacker breaches of Gmail: Poor software development procedures are the big reason major firms are apparently running around scared witless that their products are vulnerable to cyberattacks. (The corollary, about which we haven't read anything, is that firms with buttoned-down dev rules are likely feeling, if not entirely safe, then at least free of the panic which plagues the cluelessly unprepared.)The scary thing is, it's my belief that there aren't many PC-generation vendors (you know what I mean here; I'm not going to name names) who adhere to enforced best practices. Let's stipulate that this is not totally their fault; software developers who came of age without ever having to wield a soldering iron can't be expected to have a deep understand of the hardware upon which their poorly commented, non-error-trapping spaghetti code is running.

I do suspect that networking companies have an inherent advantage insofar as hacker exposure goes. That's because the higher complexity level of their software output -- as compared with, say, desktop PC apps -- means that they're more likely to enforce internal practices such as (real, as opposed to theatrical) code reviews and deep QA testing. This may not be driven by security concerns; at the top level, it's because without a proper process, the stuff just won't work. But the upshot is the same, and they're in a better place as a result.

Personally, I hadn't been planning on writing anything in the wake of the Google China attack. However, I was set off by Wednesday's New York Times article, Fearing Hackers Who Leave No Trace, by John Markoff and Ashlee Vance.

It's a worthy piece of work, taking note of the U.S. government-enforced back door, which vendors like Cisco must put into their products so the National Security Agency can do what it does. (Though of course the NSA would be able to do that even without the back door.)

However, as one would expect from a broad-audience article, it doesn't pick inside-baseball nits, such as my software dev complaint above.

User-Side Protection

The one other angle I'd like to mention involves not the vulnerabilities of the creators of source code, but rather of the users. The deal here is, if any company really wants to be secure, what they would have to do is ensure that they're not using any apps which might be vulnerable.

Sounds like a small deal, but it's not. In practice, this means that if Adobe Acrobat is perceived as being vulnerable to attack--something mentioned in the Times article--then what your organization would need to do to be secure is to not use (or to sandbox) Acrobat. [I can't believe I'm half-channeling Richard Stallman here, though not with the intention of making the same point.]

That's not really practical in the workaday world, but it is in organizations which have the resources to develop their own alternatives. What I'm getting at here is, I wonder if any of the "black ops" orgs are down with this? They're the people who are providing our attack-side resources in the below-the-radar cyberwar with China and Russia.

I don't know what the answer is, but it's certainly an interesting question.

Follow me on Twitter: (@awolfe58)

What's your take? Let me know, by leaving a comment below or e-mailing me directly at [email protected]. Like this blog? Subscribe to its RSS feed: (here)

 My videos on ( YouTube)

 Facebook 

  LinkedIn

Alex Wolfe is editor-in-chief of InformationWeek.com.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
RetiredUser
50%
50%
RetiredUser,
User Rank: Ninja
5/22/2014 | 6:09:24 AM
Right on the Money
I absolutely agree.  The recent Heartbleed article on Dark Reading got me ranting similarly about the need for security requirements in software projects and more care by the community in observing them: http://www.darkreading.com/messages.asp?piddl_msgthreadid=11947&piddl_msgid=219318#msg_219318
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/2/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9498
PUBLISHED: 2020-07-02
Apache Guacamole 1.1.0 and older may mishandle pointers involved inprocessing data received via RDP static virtual channels. If a userconnects to a malicious or compromised RDP server, a series ofspecially-crafted PDUs could result in memory corruption, possiblyallowing arbitrary code to be executed...
CVE-2020-3282
PUBLISHED: 2020-07-02
A vulnerability in the web-based management interface of Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM & Presence Service, and Cisco Unity Connection could allow an unauthenticated, remote attack...
CVE-2020-5909
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, when users run the command displayed in NGINX Controller user interface (UI) to fetch the agent installer, the server TLS certificate is not verified.
CVE-2020-5910
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the Neural Autonomic Transport System (NATS) messaging services in use by the NGINX Controller do not require any form of authentication, so any successful connection would be authorized.
CVE-2020-5911
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the NGINX Controller installer starts the download of Kubernetes packages from an HTTP URL On Debian/Ubuntu system.