10 security tips for protecting data while traveling
2007 - The safest computer is the one thats not on and not connected. Information about yourself on the
Internet in places like MySpace.com could lead to identity theft or stalking. Update software programs and
apply security patches in a timely manner. When you travel, you must assume that your data is at risk.
Thieves will take private important personal and business info from your laptop, cell phone and personal
digital assistants. Protect your privacy and be aware of your
China has an open hacking policy; however,
citizens go to jail if they are hacking in an attempt to overthrow the government because the Chinese military trains personnel to hack into computer systems, travelers may be targeted if they are carrying military information.
Russian hackers specialized in identification theft. They steal credit card information then sell it in bulk and specific data in the military. Pricing is based on the
quality and reliability of the data.
Israel and France hacking is about economic espionage and to steal corporate secrets or to access corporate networks.
10 security tips for protecting data while traveling
The list is divided into three categories: mild, medium and paranoid. Travelers should choose the
security level they need for their specific travel plans.
1) Use removable storage media to store critical data. 2) All data including the information on the removable media should be backed up.
3) Before leaving on a trip, firewalls, intrusion detection systems and antivirus applications should be updated. 4) Any equipment that is not needed or not in use should be turned off.
1) Only take the information needed just the bare minimum, only the data necessary to accomplish your goals.
2) Documents should be duplicates, not originals.
3) Use encryption to protect critical data
Because wireless capabilities enable hackers to
burrow into hard drives, travelers can no longer assume that data is safe even if it is on a hard drive.
4) digital devices should never be left unattended in hotel rooms.
5) Removable media should be carried
6) Laptops or other hardware should be locked in a hotel or room safe.
1) Do NOT use free connections without encryption
2) never perform work-related tasks using public Internet kiosks.
3) Change all your passwords when you get home.
4) When traveling, a more restricted user account should be established on a laptop, and the regular user account should be suspended until returning home.
5) The temporary account should be wiped clean before
plugging a laptop into a home or office network.
ABOUT THAT WORD YOU SEE "TRUSTED"
Risks Digest 21.30
Date: Fri, 23 Mar 2001
From BUGTRAQ ---- SECURITYFOCUS.COM
Some information regarding Verisign Certificates that has come out of this fiasco is quite disturbing but has been under reported and may have been missed by many in the security business.
Pay close attention to this paragraph from the Frequently Asked Questions
"The update is needed because of a characteristic of VeriSign code-signing certificates. Every certificate issuer periodically generates a Certificate Revocation List (CRL), which lists all the certificates that should be considered invalid. A field in every certificate should indicate the CRL Distribution Point (CDP) - the location from which the CRL can be obtained.
The problem is that VeriSign code-signing certificates leave the CDP information blank. As a result, even though VeriSign has added these two certificates to its current CRL, it's not possible for systems to automatically download and check it. "
The first question I have after seeing that is how many of the rest of the 500,000 certificates that Verisign says they have issued also do not have this CRL Distribution Point field properly filled in. In the lack of any information to the contrary I would hazard to guess that it's probably that none of the 500,000 certificates issued by Verisign have supplied the information that should be in this field. If this is truly the case then we have yet another problem of much wider scope than the improper issuance of two certificates, there are a great number of valid certificates which could be stolen or misused and even if Verisign were to add them to their CRL the certificates themselves don't point to the CRL so they won't be properly rejected.
Two things need to be done, one is that software which checks certificates must be changed to warn users that certificates lacking a CRL are much more suspect and Verisign needs to re-place all certificates that currently lack this critical information with new certificates that have this field properly filled in.
Additional questions that come to mind is how many other certifying agencies have also failed to fill in
the information in this field and what percentage of the certificates being used today are
Date: Thu, 22 Mar 2001
From: Michael Sinz
Subject: When security is based on trust
So, lets see - Microsoft says that ActiveX is secure as long as the software (ActiveX thing) is not from
"evil" source. To prevent bad software from being used, they use digital signatures to identify
the person or company who made the software such that you could either trust them or know who to go after
when it does something bad. The OS and system infrastructure does not try to enforce anything other than
check these certificates and warn you based on your settings as to if you want to run unsigned software or
any software signed by company "X" or a number of other possible combinations of warnings.
There is no built in security beyond that point. Once you say "Yes, run it" you are opening up your system to complete control by the ActiveX control.
Ok, in a perfect world, with no one wishing to do harm or rob you blind, such a mechanism would work just fine. The Internet is not such a world.
And now, to put this into even brighter "this is not the right way to do things" light, Microsoft says that you can not even trust that software that says it is from Microsoft really is from Microsoft unless you first check the dates on the digital signature and remember that if it is Jan 29 or 30, 2001, that it is most likely not really Microsoft and you should not accept it.
What do people do now? If you accept anything from Microsoft, it is too late. If you ask for confirmation before running, what are the chances you would even think to look at the dates once you see "Microsoft" as the signing party?
All of this really goes to show that security must be done at the start and not just "added in" by saying "make sure you trust the author". Even if you trust the author, there could be bugs. And, as this example shows, you can not even always trust you know who the author is.
Time to think this though some more...