Early Morning Security Ramblings

Posting it here for those that don’t belong to LinkedIn or subscribe to Answers there:

Q:  Which Tastes Better for Security, Java or .NET?

Both this two languages are safe by security point of view with their own levels, but which one tastes better w.r.t your working experience?

A:  As others have noted, the security of the individual applications written in these languages depends on the development approach used. The next level from their is the application servers, which really depends on the app server vendor for Java and again back to the developer and the server admin. And, of course, the servers sit inside an operating system, which adds another layer of vulnerability. This is point where the earlier poster who noted that Microsoft is more often the target comes in to play. Microsoft is more often targeted, which increases the likelihood of someone trying to break in. However, the biggest threat is admins and/or policies that prevent keeping up to date on patches. Then there is the architecture as a whole, where there are points in the network, structure of the firewalls and accessibility of data. There are still plenty of admin servers that have the default log in credentials set.

Then again, the vast majority of real digital break ins come from the hacker knowing passwords in advance, which is an issue that is platform independent 🙂

If you found this interesting, please share.

© Scott S. Nelson

Consider This When Planning Web Services

As soon as Web Services started getting buzz I was both excited and concerned. Interoperability and reuse are great things. Shorter time to market is a huge benefit. Bandwidth is limited. That last was never brought up by the sales people taking clients to $1000 dinners while pitching $30,000 web service platforms with $1,000,000 support contracts.

Web services are still a great way to expose legacy systems to myriad clients across the enterprise. Where they become expensive is when they are built with only one or two expected clients to support a (myopic) SOA vision. Especially when many of the new services being built are only aggregations of other services that will generally be a specialized interface to business logic required by a limited number of clients.

If an architecture includes web services, a list of clients must be part of support case or the design is simply buzz word bingo.

This technical rant was prompted by a developer.com article that has way to much code to share with the folks who will often make the final decision, but may get their advisers excited enough to explain it to them.

If you found this interesting, please share.

© Scott S. Nelson