Discussion Locked

.NET's long-term viability and security

0 helpful
8 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
In the Aug. 26 Internet Security Focus newsletter, does Jonathan make a good case for questioning the long-term viability and security of Microsoft's .NET? What security concerns do you have about .NET? Do you applaud Microsoft for the security measures it has taken, or do you feel the company still has a long way to go in living up to its trustworthy computing initiative?

8 replies

by spikeymike

Hello Group!

I've done several large N-tier systems using CORBA. As I see it, UDDI and SOAP are a case of trade-offs between ease-of-use and security.
I think ease-of-use has been given more thought than basic security.

Case in point:
1) UDDI will allow a client to 'discover' a service.
2) SOAP will allow a discovered service to 'tunnel' through HTTP protocols on port 80.

My problem with #1 is, I'd rather have a known, trusted, authenticated, etc.. application server (web service) to connect to. In my book, there is too much potential for abuse/misuse of data if I hand it off to a service that is advertising its ability to process my data. What is to stop a rogue developer from advertising his 'service', only to collect my data and then return a 'service not available' message? As I understand it, my client will just go on to the next advertised service and won't know they've just given up their data.

Secondly, as an administrator, I would rather have the ability to allow/disallow traffic to web services, as is the case if using CORBA and the IIOP protocol. If I have a trusted relationship with a web service provider, I'll have a reason to open and monitor the required ports.

Perhaps I misunderstood how .NET is going to work. If that is the case, please correct me.

Regards,

-Mike Dunn

by awb

Security is clearly the kety topic today.
.NET must have the best security in the industry to survive.
I would like to hear from the .NET supporters why this argument is not sound.

by orcmid

I think the question of the trustworthiness of common libraries will be of increasing concern. It is ironic, though that the cited IE SSL problem was not a problem with a Microsoft Common Library but with code that is running on many platforms, including Sun.
It seems to me that the trustworthiness of .NET depends on two factors. First, does the trust model for managed code provide a reliable way to know what is being run and what its origins are? Secondly, the will to produce trustworthy code in that framework. I sense more capability here than in the Java model, but it needs to be fully demonstrated.
This will involve all software providers, not just platform vendors. I upgraded a major music-software package and it still requires dministrator privileges to run! We have to cut that out and be far more accountable for steps taken to demonstrate trustworthiness and also anticipate remedies of when security-impacting defects are discovered.
Microsoft has demonstrated great adaptability and I am not so pessimistic at this point.

by whoneedsgates

It is regretable that the secutiry issue ponted out in the article was the bind security issue. But Microsoft has continued to be slow or not responsive to security issues. A major example of this is the recent IE patch. This patch resolved a significant security hole which had been discovered 7 months ago. Also, there are several significant IE security issues which reman unresolved, as well as othe Microsoft products which have significant security issues (as defined by the security community) which Microsoft either has not patched or claims are not 'significant'.

I do enjoy your jab at Java with no explanation.

Combined, your post indicates that you are pro Microsoft and anti-Java, without making the attempt to include any basis for your conclusions.

by bsj

I find it ironic that the author mentions vulnerabilities within the BIND related libraries. When you consider that BIND
ON UNIX is one of the most vulnerable, and constantly-being-patched packages out there, his criticisms of the .NET platform seem like the pot calling the kettle black. While I have no doubt that patches will be needed for .NET over time, Microsoft has thus far been very responsive in bringing out patches for the platform. Considering that UNIX dwellers have had decades todevelop an architecture as comprehensive as .NET and have thus far failed, I think to criticize when he has nothing to compare it against seems pedantic...

by Member 33540636

Jonathan's basic argument about building on top of an existing codebase which may itself be flawed is interesting. To then tie this to .Net as if .Net invented the problem is just more of the same anti-MS rhetoric that plagues and de-values this column. Judging by some of the posts in this discussion, its obvious that Jonathan knows his readership and is giving them what they want.

Reported vulnerabilities show that MS is no worse and no better than other commercial software providers in creating flawed software. The truth is that hardly anyone was writing with security in mind when much of the existing codebase was created (e.g. BIND, SNMP)

To suggest otherwise leads those less well-informed to focus on platform choice to the detriment of how go about securing and managing that platform.

The specific points raised by one poster about UDDI and SOAP are interesting/valid, but please note that these are XML Web Services standards (well the first is actually a consortium project not a standard), NOT .Net creations. Your concerns are valid across all Web Services platforms and would form the basis of a much more useful discussion than hackneyed MS bashing.

Whatever scepticism one has about MS' true motivations forTrustworthy Computing, they have at least raised the subject. The Web Services (call it Network Computing if it makes you comfortable :-)) vision will not come close to realisation until issues of Trust, Privacy and Security are addressed.

Choosing Web Services suppliers should be based not just on what the web service does and how much it costs, but also:-
Performance
Availability
Security

and how these things are managed as well as the trustworthiness of the supplier.

by -e

...What business does a UNIX system administrator have providing commentary on Windows development tools?

Not a lot of credibility - not to say you aren't correct (although I disagree, but I may be a little biased as well).

by indianapolymath

My experience seems to be very different than most. First let me say that in general, applications are delivered much quicker within a Microsoft environment but with Unix once everything is setup correctly, Unix just never trips up (assuming you can standardize on a single platform).

I have worked for two multi-billion dollar companies that grew by obtaining other top companies. This presented corporate IS with very dissimilar systems. I found very early on in this environment that the features provided by one Java engine vender never matched the features provided by another and at times implemented features differed. This became even more painful when venders would release service packs!

As far as security venerability, I feel Microsoft is much more forthcoming than Sun. This is probably due to the fact that Microsoft is the sole vender of its platform and any exposure of an issue points directly to Microsoft. If you visit the CERT site, review the Unix advisories and digdeep into the issue and its resolution, I find that most of the time Sun does not participate by not responding. I would rather work on a platform that is forced to be more forthcoming with issues than play ?hide and find the issue?.

Now I realize that with all the existing technologies (XML, etc.) and ones to come, communicating with different systems is far better than it has been. But this can only become a reality if the skill and competence of the IS development staff is sufficient. I prefer delivering components to abstract complexities to a known operating system, Microsoft, and working with that IS staff to provide the collaboration with these components. It is far easier and cheaper requiring a Microsoft platform than a specific Unix platform. Of course there is a price for this ease but that is what processes and management is for. ;-)

This discussion is closed to new replies.