Mobile security

Cisco, Juniper Treating Gear Against Potential Heartbleed

Cisco Systems and Juniper Networks are among the latest technology companies working to address potential problems related to the Heartbleed OpenSSL bug.

Both companies issued warnings about possible vulnerabilities in some of their equipment, and continue to update the lists of products that may be affected, or have received patch fixes, or have been confirmed as unaffected.

Among Cisco Systems Inc. (Nasdaq: CSCO) gear listed as "vulnerable" to the bug are Cisco's MS200X Ethernet Access Switch and its Mobility Service Engine. Meanwhile, the Cisco 7000 Nexus Series switches and UCS fabric components are among those products that have been confirmed as not vulnerable.

Juniper Networks Inc. (NYSE: JNPR)'s advisory includes its Juno OS version 13.3R1, though earlier versions of the OS are listed as not vulnerable.

Since news about the Heartbleed bug broke earlier this week, numerous companies reportedly are reviewing their products and services to size up the possible risk, so there may be more advisories to come from other telecom firms.

In addition to the actions by Cisco and Juniper, Telenor issued an advisory to customers in Norway to change passwords for their Telenor services, even though it has classified the Heartbleed threat as "low." (See Eurobites: Telenor Counters Heartbleed Threat.)

And it wouldn't be a networking issue if there wasn't some sort of virtualization angle. Check out this InformationWeek article that suggests SDN might have a solution to the kind of problems Heartbleed is posing.

— Dan O'Shea, Managing Editor, Light Reading

Page 1 / 2   >   >>
Mitch Wagner 4/15/2014 | 4:48:34 PM
Re: Open source People in accounting and middle management live in spreadsheets, however. 
jabailo 4/14/2014 | 6:29:40 PM
Re: Open source I still think we're not understanding each other.

The way that software that is open source is made "quality" is by a kind of tailoring.

So, think of an open source tree, not as a house, but as lumber -- or rather prefab panels.

At no point would you simply bring home material from a lumberyard, through it together and insist that you've just built a home.

So, where we disagree is on the locus and extent of expertise.

In the traditional software house, all the higher level functions such as coding and QA are internal.    In the open source model it is expected, and in some sense because of the zero cost of the software, that you will have one or more expert craftsman in your own organization to nail together the final product.   And those craftsmen are not just Lego brick assemblers, but real honest to goodness computer programmers!

jabailo 4/14/2014 | 6:23:27 PM
Re: Open source True, but that cuts both ways.

Developers don't use spreadsheets ... because most people don't use spreadsheets!

What you say?   Well, for the most part, most simply do not use spreadsheets.  The majority of computing is now done using web forms...many of which, with dynamic java, have replaced the movable functions of spreadsheets.

But it gets worse.

Of those who "use" spreadsheets, even fewer create spreadsheets...most using a travel expense spreadsheet.

Of those who create a spreasheet, most never use more than one worksheet.

Of those who use more than one worksheet in a workbook, most never build macros.

And so on...
Mitch Wagner 4/14/2014 | 5:02:23 PM
Re: Open source Reminds me of another problem with open source: Developers are attracted to projects they themselves use. So the web browsers and IDEs are very sophsiticated, but spreadsheets are rudimentary. Because developers don't use spreasheets. That was true at one time -- I don't know if the state of open source spreadsheets has advanced. 

Good question regarding the heartbeat. Why do you need a heartbeat? If the server is down or off the network, it just doesn't respond. 
Mitch Wagner 4/14/2014 | 4:59:45 PM
Re: Open source danielcawrey - As I understand it, Certain Government Agencies are issuing unambiguous denials. But their credibility is suspect. 
brookseven 4/14/2014 | 1:19:53 PM
Re: Open source  

I think that the truth lies somewhere in the middle here.

First off, most of the major OS projects do not willy nilly accept all submissions.  That does not mean that bad quality code never gets added, but I think putting out the notion that a guy off the street can automatically get his code in an Apache Web Server needs to get cut off right here.

Secondly, the lack of central control means that there has been challenges with the tidiness of many open source projects.  Having many brains both good and bad adding code can create all kinds of cruft.

Third, it is up to the user of an OS project to perform their QA on new OS releases.  One has to be very careful in picking up a new version from any OS stream.  We always treat the inclusion of a new OS version as equivalent to a maintenance release.

I suspect that nobody did had a regression suite for that testcase.  I know given the breadth of deployment of this code that seems unlikely.  But given the number of folks who don't retest OS once they have integrated it, I think that seems likely.



t.bogataj 4/14/2014 | 12:37:43 PM
Re: Open source I agree, but my point was elsewhere.

On one hand, the open-source community is a bustling space of experts keen to share their ideas and expertise; on the other, anyone can contribute, according to his/her (limited) skills. In my workplace I see the the full spectrum of coders/programmers, and I also see the difference: the creative ones are neither good at defensive coding, nor they have the discipline to critically evaluate their own design.

The "creative programmers" and the "good coders" generally do not overlap. Without proper control (yes, literally: control) over what is accepted in the main trunk (or an open-source project), even those considered best will participate their share of flaws and bugs.

As a wiser person said: The difference between a beginner and an expert programmer is not that the expert does not make bugs; the difference is that the expert generates bugs which are much more sophisticated and much harder to debug.

I am not advocating for the "corporate-style" control over open-source projects. But I firmly believe that following formal procedures and best practices is a must. Which is not really the case in the open-source community.


PS. Regarding democracy... another quote (by W. C.): The best argument against democracy is a five-minute talk to an average voter.
jabailo 4/14/2014 | 12:16:35 PM
Re: Open source I don't think that's quite it.

Open source -- like democracy -- requires an intelligent and aware set of users at all levels.  You can't expect to bite off a big block of code and have it be exactly what you want.  So the "corporate review" would be done (and should have been done) by a savvy IT department.

It's expected that there will be expertise at both ends of the supply chain.  That means companies that employ people with the proper skill set.   This differs from the Lego-model of programming where large software manufacturers sell pre-packaged assemblies that are guaranteed to certain degree of reliability.

Although, truth be told, if you dig deep enough, there are no real guarantees.  Any time you put all your eggs in one basket -- whether it be a runtime, or library -- you risk the danger of overleverage.

t.bogataj 4/14/2014 | 3:28:49 AM
Re: Open source The difference between open-source effort and a formal corporate process is that in the former, the programmers do not have to bother with design reviews, coding rules, best practices; there are no bosses to scrutinize your work, and no annoying people from V&V filing bug reports. It's nice and cozy to code in a friendly community.

And Heartbleed bug is the result.

DOShea 4/13/2014 | 3:48:26 PM
AT&T After this story was published, AT&T posted this note about its own Heartbleed evaluation on its consumer blog: http://blogs.att.net/consumerblog/story/a7795231
Page 1 / 2   >   >>
Sign In