I used to be a reseller for a larger accredited registrar and I received a warning message about such practices. My customers would constantly complain to me about these letters, believing I had sent them. Verisign even tried to steal away my domain. I have received over a dozen from Verisign trying to get me to renew my personal domains with them. When I called Verisign to complain, they were extremely rude. They flat out denied trying to deceive customers of other registrars.
What ever happened to proper 'netiquette'? If I see one more domain renewal scam, pop-under adv, SPAM message, X2 cam promotion, evidence remover scam, or get rich quick scheme.... How I long for the good old days, before the commercialization of the 'net.
Yes, yes.. Slashdot is not the place for legal advise. But I thought I'd ask for your experiences nonetheless.
I'll be graduating soon and have considered working for a company (developing software) which does work for the government. Some of that work may be classified.
Clearly, I would not incorporate anything classififed into my independant software projects. However, what is to keep them from attempting to sneak in the backdoor, claiming that I did?
Something like, "You have a security clearance. And your work in the office is classified. Your work outside the office is somewhat related. Thus, even though it contains no secrets or proprietary technology, it is also classified. Sorry, you can no longer do anything useful with your property."
Any one have to deal with something like this? What should I look out for in employment contracts in this respect?
Is there a place to donate money to the highschool radio station? I'd be willing to give a few bucks to help their cause.
I think some cellular / wireless company out there should sponser the station, if they get to share the tower.
Better yet, lets construct a really massive antenna, sit outside city limits, and blast the residents with radiation.
What a moron! My question is, does he have electricity in his home? Does he use the telephone? Does he drive a car? Anything using electricity creates an EMF.
I posted a brief overview of a solution using PGP eariler. It was by no means perfect, just intended to point you in the right direction.
Then I began to read what others had posted....
The best advice I can give you is not to trust anything you read here. Some of the solutions suggested are just bad. I am a security professional so I have some experience in this area. As others have said, recognize that you are not equiped to handle this. Find someone who is.
But before you outsource, hire consultants, etc... remember -- technology is only a tool. I've seen technology based solutions that were more vulnerable than the problem.
You have a specific set of risks. Choose a solution that helps to mitigate those risks. Remember to document. Remember people actually have to use the system. Remember a create a well-defined process. Remember to create and enforce policy.
Also, look to the three R's. I could not find a single post that specifically mentioned recognition.
Resistance: how can I protect the integrity and privacy of the card numbers?
Recognition: how do you know if a breech of security has occured?
Recovery: how do we recover from said breech?
1.) Generate a new public/private key pair of significant length using PGP / OpenPGP on a detached (off the network) workstation.
2.) Store the public key on read-only media. Create two copies. One copy should be kept in a fireproof safe. The other will become a mounted filesystem on the web server.
3.) Repeat step 2 for the private key. Except, both copies of the key should be kept in a physically secure (restricted access) location.
4.) Delete the keys from the offline workstation. Delete the swap file. Wipe the free space on the workstation's hard disk. Power off the machine to clear its RAM.
4.) Mount the public key as a read-only filsystem on the webserver. Read-only media maintains integrity. I recommend it for everything critical that doesn't require writes (kernel, system binaries, HTML files). Once there are cached in memory there is no performance hit.
5. Modify your web application. Encrypt client credit card numbers using PGP and your public key.
6. When credit card processing time comes around (every night, once a week), copy the encypted credit card numbers to removable media. Retrieve the CD with your private key. Batch process the credit card numbers from an offline workstation, decrypting the numbers with the pricate key on the CD-ROM. All of this can easily be automated with shell / Perl / Python scripts.
Again, it is critical that you A) have a backup of your key pair, B) maintain the integrity of the keys with read-only media, C) physically restrict access to your keys (most importantly the private key, but it never hurts to be paranoid). Also, your private key should never come near the web server.
Remember, document the process. Define policy to administer the process. Develop contingency scenarios (what is the private key is lost, compromised, the hard disk in the web server fails, etc.). Define how you will recover from breeches in policy. Train your employees to act responsbily.
Here are a couple suggestions. First, find a non-existant address and ficticious name. Next, print labels on your laser printer. Be sure to include a phone number, and all of the other things they typically ask for on those reply cards. Make the info look real. Slap in on the front of the card and drop it in the mail. With any luck, they will add the non-existant person to their mailing list and have to pay for even more mail. Or, you can do what I do. Print labels or complete the cards with someone else's information (someone you don't like very much). Not only are you costing the junk mailer money but also annoying the hell out of someone you don't like.
Slashdot Mirror
I used to be a reseller for a larger accredited registrar and I received a warning message about such practices. My customers would constantly complain to me about these letters, believing I had sent them. Verisign even tried to steal away my domain. I have received over a dozen from Verisign trying to get me to renew my personal domains with them. When I called Verisign to complain, they were extremely rude. They flat out denied trying to deceive customers of other registrars.
What ever happened to proper 'netiquette'? If I see one more domain renewal scam, pop-under adv, SPAM message, X2 cam promotion, evidence remover scam, or get rich quick scheme.... How I long for the good old days, before the commercialization of the 'net.
Yes, yes .. Slashdot is not the place for legal advise. But I thought I'd ask for your experiences nonetheless.
I'll be graduating soon and have considered working for a company (developing software) which does work for the government. Some of that work may be classified.
Clearly, I would not incorporate anything classififed into my independant software projects. However, what is to keep them from attempting to sneak in the backdoor, claiming that I did?
Something like, "You have a security clearance. And your work in the office is classified. Your work outside the office is somewhat related. Thus, even though it contains no secrets or proprietary technology, it is also classified. Sorry, you can no longer do anything useful with your property."
Any one have to deal with something like this? What should I look out for in employment contracts in this respect?
Is there a place to donate money to the highschool radio station? I'd be willing to give a few bucks to help their cause.
I think some cellular / wireless company out there should sponser the station, if they get to share the tower.
Better yet, lets construct a really massive antenna, sit outside city limits, and blast the residents with radiation.
What a moron! My question is, does he have electricity in his home? Does he use the telephone? Does he drive a car? Anything using electricity creates an EMF.
I posted a brief overview of a solution using PGP eariler. It was by no means perfect, just intended to point you in the right direction.
Then I began to read what others had posted....
The best advice I can give you is not to trust anything you read here. Some of the solutions suggested are just bad. I am a security professional so I have some experience in this area. As others have said, recognize that you are not equiped to handle this. Find someone who is.
But before you outsource, hire consultants, etc... remember -- technology is only a tool. I've seen technology based solutions that were more vulnerable than the problem.
You have a specific set of risks. Choose a solution that helps to mitigate those risks. Remember to document. Remember people actually have to use the system. Remember a create a well-defined process. Remember to create and enforce policy.
Also, look to the three R's. I could not find a single post that specifically mentioned recognition.
Resistance: how can I protect the integrity and privacy of the card numbers?
Recognition: how do you know if a breech of security has occured?
Recovery: how do we recover from said breech?
Here is a solution using PGP:
1.) Generate a new public/private key pair of significant length using PGP / OpenPGP on a detached (off the network) workstation.
2.) Store the public key on read-only media. Create two copies. One copy should be kept in a fireproof safe. The other will become a mounted filesystem on the web server.
3.) Repeat step 2 for the private key. Except, both copies of the key should be kept in a physically secure (restricted access) location.
4.) Delete the keys from the offline workstation. Delete the swap file. Wipe the free space on the workstation's hard disk. Power off the machine to clear its RAM.
4.) Mount the public key as a read-only filsystem on the webserver. Read-only media maintains integrity. I recommend it for everything critical that doesn't require writes (kernel, system binaries, HTML files). Once there are cached in memory there is no performance hit.
5. Modify your web application. Encrypt client credit card numbers using PGP and your public key.
6. When credit card processing time comes around (every night, once a week), copy the encypted credit card numbers to removable media. Retrieve the CD with your private key. Batch process the credit card numbers from an offline workstation, decrypting the numbers with the pricate key on the CD-ROM. All of this can easily be automated with shell / Perl / Python scripts.
Again, it is critical that you A) have a backup of your key pair, B) maintain the integrity of the keys with read-only media, C) physically restrict access to your keys (most importantly the private key, but it never hurts to be paranoid). Also, your private key should never come near the web server.
Remember, document the process. Define policy to administer the process. Develop contingency scenarios (what is the private key is lost, compromised, the hard disk in the web server fails, etc.). Define how you will recover from breeches in policy. Train your employees to act responsbily.
Here are a couple suggestions. First, find a non-existant address and ficticious name. Next, print labels on your laser printer. Be sure to include a phone number, and all of the other things they typically ask for on those reply cards. Make the info look real. Slap in on the front of the card and drop it in the mail. With any luck, they will add the non-existant person to their mailing list and have to pay for even more mail. Or, you can do what I do. Print labels or complete the cards with someone else's information (someone you don't like very much). Not only are you costing the junk mailer money but also annoying the hell out of someone you don't like.