I'm not much of a Mac fan. This is simply because I don't have a need to use Mac's. I have friends who use and love the Mac book pro and I've seen a few being used on the train when I travel into and back home from work. I'm still not a fan though so never looked into Mac OS until a few days ago when I was testing out a new security tool for some due dilligence work that was required and a copy of Mac OS would have been very useful for testing.
Could I just go to Apple's site and download a trial? Nope. Not allowed. It seems insane to me that Apple have no ability to allow the regular intel user the ability to try out Mac OS without having to buy the hardware. This policy must be causing Mac sales.
Tuesday, February 26, 2008
Friday, February 22, 2008
Mail for Exchange documentation woes
Too many times now I've come across badly written documentation. That is documentation that leaves you hanging wondering "what next?" or "where do I go from here?".
An example of this is the Mail for Exchange application on my Nokia E61. Having spent no less than 4 hours trying to get it to work and still having no joy I realized just how painful the documentation is. I'll cover the fun and games with Mail for Exchange in a later article but for now I just want to highlight how badly written the documentation is.
When configuring my phone to connect to my Exchange server over wireless I get an error "Communication error, retry later". The documentation has a section that reads "Troubleshooting - Errors you may receive" and lists that error with no fix or reason why that error is occurring.
Thanks Nokia.
If you are going to present the user with an error you should at least give the user and idea of what to do with it.
An example of this is the Mail for Exchange application on my Nokia E61. Having spent no less than 4 hours trying to get it to work and still having no joy I realized just how painful the documentation is. I'll cover the fun and games with Mail for Exchange in a later article but for now I just want to highlight how badly written the documentation is.
When configuring my phone to connect to my Exchange server over wireless I get an error "Communication error, retry later". The documentation has a section that reads "Troubleshooting - Errors you may receive" and lists that error with no fix or reason why that error is occurring.
Thanks Nokia.
If you are going to present the user with an error you should at least give the user and idea of what to do with it.
Tuesday, February 12, 2008
Get ready for a bumper patch Tuesday
With no less than 12 security updates coming out of Microsoft later on today and Vista SP1 slated for February 15 there will be a lot of update servers groaning under the weight of so many updates to download so it's probably a good idea to ensure your WSUS servers have plenty of free disk space and are as up to date as possible now to ensure they download the minimum necessary during the next couple of weeks.
Monday, February 04, 2008
Call for Eicar V2
Many years ago it was recognised that there existed a need to test AV software without throwing live viruses around and so the EICAR test file was developed as a safe way of testing that AV software was indeed working.
This was fine but I think there is now a need for an EICAR v2. Something that is NOT recognised by AV software by default. Why would this be of use?
Well, A scenario I had last week involved a virus getting onto NetApp filers. Now, Netapp will send the file to an AV scanner and get one of three responses back: clean, infected or timed out.
Clean means the file gets added to the clean list and will not be rescanned until the file changes.
In other words, if the file has a virus that the definitions do not pick up that file is NOT rescanned even if new definitions are released. This means a virus-infected file can get onto a NetApp system.
Having an EICARv2 test file will enable testing of the automatic clean-list clearing type of scenario and be very useful to the IS industry in general.
This was fine but I think there is now a need for an EICAR v2. Something that is NOT recognised by AV software by default. Why would this be of use?
Well, A scenario I had last week involved a virus getting onto NetApp filers. Now, Netapp will send the file to an AV scanner and get one of three responses back: clean, infected or timed out.
Clean means the file gets added to the clean list and will not be rescanned until the file changes.
In other words, if the file has a virus that the definitions do not pick up that file is NOT rescanned even if new definitions are released. This means a virus-infected file can get onto a NetApp system.
Having an EICARv2 test file will enable testing of the automatic clean-list clearing type of scenario and be very useful to the IS industry in general.
Subscribe to:
Posts (Atom)