Internet.com reports about the logic behind unpatched systems. A lot of it goes to the fact that system administrators are deluged with new patches and are fed up of high level alerts on inessential patches. However, when a system crashes, the blame falls squarely on the shoulders of the system administrator. In order to resolve this, two things need to happen: First of all, there needs to be a better understanding overall of what danger security vulnerabilities represent. When it comes down to it, it is not just the system administrator responsibility to ensure that systems are secure. If software developers are careful in their implementations and consider security implications of the choices they are making when designing and developing software, the risk of an exploit is lowered. Secondly, there is a need for better education in general. Most user neither know or care about vulnerabilities. By default, most machines are not even set to auto-update. There are a number of ways this can be solved. Operating System vendors like Apple, Microsoft, and Redhat already offer an automated way to apply patches to a machine. These tools should be turned on by default to ensure that “most” machines get patched…

The leading contender for the communications protocol that facilitates the world’s business transactions is designed to transmit data over HTTP, in the clear. Although some of the creators of Simple Object Access Protocol (SOAP) have expressed concern, the consortium responsible for redrafting SOAP into the new Extensible Markup Language (XML) Protocol is nearing agreement that security is, simply put, not their problem. In the meantime — and possibly as a result– Microsoft and Verisign have just announced a new security procedure for person-to-person SOAP transactions, but a workable mechanism for securing Internet transactions between software and software may be years away. Some of SOAP’s architects contend that building security into their protocol would only sacrifice its simplicity, and that the HTTP sessions that SOAP transactions rely on can already be secured at the session level, with protocols such as SSL. Moreover, securing sessions from outside interception, security experts believe, cannot protect transactions from two other perceived threats: interception from the inside and bad programming. With a protocol extension to SOAP for message attachments in the works, a third possible threat emerges — one that too many have become familiar with: malicious scripts. Chris Dix, a SOAP programmer with FMStrategies, sides…