First, do you have a decent relationship with your former company? If so, good, reach out to someone there who might be able to get you authorization to contribute them back to the project Second, if they won't or if you can't, reach out to the project and at least notify them of the bugs and I would assume you can provide the details of where they are located. You're already providing more than a bug report at that point which helps them more than nothing at all. Third, work with another person to develop a clean-room patch so it isn't your exact work and therefore not your former company's work product.

Taking your analogy a bit further..... While you may have a more secure door without the lock, you also have what is commonly referred to as a wall. Without a way to use the door it is no longer serving it's intended purpose. The most secure computer is one that is not on a network and cannot be physically accessed. Once you actually need to access it you are now weighing the tradeoff between usability and security. The picture password is intended to provide a way for users who wouldn't otherwise protect their device with a low impact way of doing so.

The question was asked as "should the BES be in the U.S. or the foreign country." Given those two options the better place would be the U.S. since the OP was concerned about the foreign country to begin with. Your point about the physical access is correct, however if you have encrypted mail stores and you encrypt the handheld you could conceivably create quite a headache for anyone who even has access the physical box or the handheld (assuming you didn't remote wipe it anyway).

BES should be in the US, the data will flow through the foreign carrier but it will be encrypted. So unless you are a high value target, I don't think they'll spend the resources to decrypt that data. It would take a little while.

They allowed access to the encrypted BBM (If you aren't using your corp encryption key) and I think BIS (POP3/IMAP). They have stated that any country wanting access to corp BES data could not be accommodated since they each use their own private keys.

I believe the Blackberry BIS service only supports Outlook Web Access (Not true ActiveSync), there are third party apps for ActiveSync but from my research they are a bit cumbersome to use.

Well I know one reason I moved to a Blackberry and BES was that ActiveSync didn't handle notes. Additionally the iPhone didn't handle tasks. I don't know if any Andoid based devices do but none did when I was looking in January of this year.

We tried all three of those trust methods. None of them worked. It boiled down to a different internal domain name vs external domain name. Both were in the cert, the pre tried to use the first one instead of the one specified in the connection setup.

There seems to be many people having issues with s self signed SSL certificates on Exchange. The phone requires you to load the certificate and "trust" it before you can connect. It doesn't allow for you to "trust" it inline with the EAS setup (ala Windows Mobile and iPhone). If you get past that, and you are running a standard SBS sever which by default creates a self signed cert with CNs for the private AD host name, the public dns host name and some SBS specific websites (companyweb and others). The pre supports multiple CN certificates, but it seems from some early research I did with a friend who just picked one up, that it uses the 1st CN to create the SSL connection (or verify the root ca) instead of the server url the user entered in the setup. Since many small shops don't use their public domain name as their AD domain name there seem to be many people having an issue.

Also, the error message it provides is not very helpful and is generic "SSL certificate error. Is the date and time correct"

Thankfully my friend's company happened to own the domain they used for the internal AD as well and since he is the admin he just added in the DNS records for it. It then worked as designed.

Thank you for your input, we already block incoming and outgoing traffic on port 445. I was more specifically looking for information on blocking the control communications of the worm. Sorry for not being more clear.


Thanks again.

I was looking for information on this last night and wasn't able to find much.

Is there a way (on a ASA/PIX specifically) to block the outbound connections made by this worm so that you can contain the traffic to the local network and also log the hosts that are infected?

The only thing I found was someone making reference to blocking http://ipaddr/search?q= requests but I couldn't find any backup for that claim. TIA