Hauppage have just released a device that can play MPEG 1/2 and DivX to your TV set over a WiFi network (eHomeUpgrade has a Press Release here).
The device seems to come in either WiFi model or Wired models (more detail on the wired model here)
I’ve been wanting to build a media PC for the lounge room for a long time now, but have been put off by the expense. Cheaper alternatives such as a modded xbox just didn’t feel right to me. This thing could be the perfect answer. I already have a server with a load of disk space that contains my media stuff, and a WiFi point. The MediaMVP would serve as a bridge between that and my TV. According to the press release linked above, $149 US for the WiFi version means its cheap too. What more could you want! I definately want one of these. As an added bonus the device itself runs Linux (although who realy cares if its reliable).
Found via Scott.
A few days ago I listened to the IT Conversations chat with Phil Zimmermann for the first time. Phil was the original author of the PGP encryption program back in the early 90’s, and suffered through a long legal battle for doing so. The chat with IT Conversations talks about this, and many other things related to encryption. Its about 30 minutes long, but well worth the listen.
Now that I’ve finally has a chance to catch up on the backlog in my aggregator I’ve found several useful articles related to the topic of securtiy.
The first from Techworld, introduces the reader to encryption topics. If anytone in my classes is struggling with encryption and GPG, this article may help.
However cryptography is jargon-heavy even by the discouraging standards of the IT world – symmetric and asymmetric cryptosystems, public versus private keys, digital signatures, hash algorithms, RSA, DES, Rijndael, PGP, MD5, SHA-1, https, secure sockets, Camellia, IDEA; what does it all mean?
The SecurityFocus article “Issues Discovering Compromised Machines” provides an excellent overview ov various techniques and the problems associated with detecting compromised machines. Well worth reading!
I decided to look at the problem of reliably discovering the compromised machines on corporate networks. Reliability is of key importance here as there are lots of ways to obtain a suspicion that the machine is “owned” or infected, but sadly there are few truly reliable ways to discover that short of full forensic analysis
If there was ever any doubt about the need to deal with compromised machines then this paper from the Honeynet project should fix that. Profile: Automated Credit Card Fraud looks at the use of IRC bots to compromise eCommerce sites, obtain Credit Card numbers and verify their validity. The level of automation here is pretty amazing.
Finally, there’s the first two parts of the Securing Linux series from IBM’s DeveloperWorks.
Only the paranoid survive, and that is no less true when securing Linux® systems as any other. Fortunately, a host of security features are built into the kernel, are packaged with one of the many Linux distributions, or are available separately as open source applications. The first in a series, this article starts you on your way to understanding security concepts and potential threats, and sets the stage for what you really need to know: how to secure and harden a Linux-based installation.
Part 1: Introduction - covers the basics. Integrity, Confidentiality and Availability.
Part 2: Planning the installation delves a little deeper, looking at topics such as Security Planning and Inventory Assesment, before looking at the importance of installing from known “clean” sources.
A lot of job Ads that I’ve read recently are asking for familiarity with MSF. A bit of quick Google research tells me that MSF is actually the Microsoft Solutions Framework.
MSF provides an adaptable framework for successfully delivering information technology solutions faster, requiring fewer people, and involving less risk, while enabling higher quality results.
Helpfully, Microsoft provide all of their MSF docco online. Interestingly, MSF’s core principles of open communication, empowerment, learning from experience and shared vision, closely match my own principles. That should make it much easier to work within a MSF environment.
Two incidents in the last couple of days has prompted me to make a some comments on the importance of verifying identity. Its critically important that administrators verify their packages. In a class I teach we spend quite a bit of time on it, then reinforce the point later in the course. Why? Because of the recent PostNuke incident.
This morning the developers of the free software content management system PostNuke posted a security announcement saying that a vulnerability in the paFileDB download management software allowed an attacker to put up a hacked version of PostNuke for download. That version was live on the PostNuke download site between Sunday at 23:50 GMT and Tuesday at 08:30 GMT.
Continue reading ‘The Importance of Verifying Identity’
Robert Hensig has opened his new blog with a cracker of a post. Robert is a senior member of the Microsoft Product Support Incident Response Team, and he’s suggesting that you shouldn’t be using passwords of any kind on your Windows networks.
Medication issues notwithstanding, it’s true - you should NOT be using passwords of any kind. Why? For starters, passwords are ridiculously easy to guess or crack.
Of course Robert hasn’t completely taken leave of his senses, he just advocating the use of really long passwords (i.e. pass phrases) instead. Makes sense when you think about it.
Have been doing some research into Service Level Agreements (SLAs) to prepare my Monday lecture. Theres q few good resources floating around on the ‘net. ZDNet Australia has an introduction to SLA basics. Covering what should be included in an SLA, and looking at some of the issues involved in penalties and bonuses.
Unfortunately not every relationship between customer and provider goes smoothly; things go wrong, relationships break down, and at those times the first thing both parties will be reaching for is the service level agreement.
ITworld looks at 10 myths about service-level agreements. An interesting siscussion.
An SLA is the contract that binds the customer and the service provider. So it’s worth the customer’s while to do a little research before signing on the dotted line. Here are 10 of the most common myths about SLAs.
Darwin Executive Guides has a good introduction to SLAs for CxO level staff.
Here are some ways to make sure an SLA (service-level agreement) protects your Web business and technology:
While CIO Magazine uses some of the same material, but instead discusses how internal IT departments can implement SLA’s with their end users.
Ronald Lynn suffers the classic irony of the shoemaker whose children go without shoes. His IT group at Inspire Insurance Solutions Inc., an insurance and technology outsourcing company based in Fort Worth, Texas, serves both external outsourcing clients as well as internal Inspire business units.
Finally, the Virginia Community College System has several of their SLA’s online. This is their E-mail SLA. It illustrates a number of points from the earlier articles.
eBCVG is carying an article on eBCVG - Public Key Infrastructure. Might be handy for later.
PKI has been getting a lot of bad press of late, but is it justified? Has the technology failed or is it a problem of implementation? First it is important to distinguish between public key cryptography (as discovered by Rivest, Shamir and Adelman, or Clifford Cocks) and PKI or public key infrastructure.
As a followup to my previous post on the MD5 Collision, I found this Illustrated Guide to Cryptographic Hashes, which explains a lot more about how hashes work, and why a collision is a big deal.
With the recent news of weaknesses in some common security algorithms (MD4, MD5, SHA-0), many are wondering exactly what these things are: They form the underpinning of much of our electronic infrastructure, and in this Guide we’ll try to give an overview of what they are and how to understand them in the context of the recent developments.
But note: though we’re fairly strong on security issues, we are not crypto experts. We’ve done our best to assemble (digest?) the best available information into this Guide, but we welcome being pointed to the errors of our ways.
It appears that a collision has been found in MD5.
What triggered this? A collision in MD5. I am not an expert in cryptography, but I do find this subject fascinating.
Effectively this means that there are two strings, which when MD5′ed return the same result. This certainly doesn’t mean that MD5 is worthless, but researchers seem to have made a lot of progress towards breaking it. As Bruce Schneier said in a recent ComputerWorld column:
This is how the science of cryptography advances: We learn how to design new algorithms by breaking other algorithms.
Bruce also argues that its time for a new hash standard:
NIST should issue a call for algorithms and conduct a series of analysis rounds, where the community analyzes the various proposals with the intent of establishing a new standard.
Most of the hash functions we have and all the ones in widespread use are based on the general principles of MD4. Clearly we’ve learned a lot about hash functions in the past decade, and I think we can start applying that knowledge to create something even more secure.
Better to do it now, when there’s no reason to panic, than years from now, when there might be.
Sounds reasonable to me.
