...the "bat it away" syndrome

Can you safely combine all the above computing goals?     Here are Five Rules:

1. Do not children or other computer illiterate users use your computer with a non-password protected administrative account. This removes the potential for them to log in as the admin and perform or allow configuration changes that compromise security. 

It is usually more secure to not password-protect your home accounts because this blocks the possibility of remote control of your system over the internet...but in this case where there are irresponsible users that may use this computer....you should then password protect the administrative account. Login requires a password. (Start - Control Panel - Users and Passwords.)

Never allow non-technical users to be able to make administrative decisions!

How do irresponsible responses affect security with use of Java and ActiveX ? Source
Java and ActiveX are two systems that let people attach computer programs to Web pages. People like these systems because they allow Web pages to be much more dynamic and interactive than they could be otherwise. However, Java and ActiveX do introduce some security risk, because they can cause potentially hostile programs to be automatically downloaded and run on your computer, just because you visited some Web page. The downloaded program could try to access or damage the data on your machine, for example to insert a virus. 

Both Java and ActiveX take measures to protect your from this risk. But ActiveX security relies entirely on human judgment. ActiveX programs come with digital signatures from the author of the program and anybody else who chooses to endorse the program. Think of a digital signature as being like a person's signature on paper. Your browser can look at a digital signature and see whether it is genuine, so you can know for sure who signed a program. (That's the theory, at least. Things don't always work out so neatly in practice.) 

Once your browser has verified the signatures, it tells you who signed the program and asks you whether or not to run it. You have two choices: either accept the program and let it do whatever it wants on your machine, or reject it completely. 

ActiveX security relies on you to make correct decisions about which programs to accept. If you accept a malicious program, you are in big trouble. One way this can happen is that some person you trust turns out not to deserve that trust. The most dangerous situation, though, is when the program is signed by someone you don't know anything about. You'd really like to see what this program does, but if you reject it you won't be able to see anything. So you rationalize: the odds that this particular program is hostile are very small, so why not go ahead and accept it? After all, you accepted three programs yesterday and nothing went wrong. It's just human nature to accept the program. 

Java security relies entirely on software technology. Java accepts all downloaded programs and runs them within a security "sandbox". Think of the sandbox as a security fence that surrounds the program and keeps it away from your private data. As long as there are no holes in the fence, you are safe. Java security relies on the software implementing the sandbox to work correctly. 

The main danger in Java comes from the complexity of the software that implements the sandbox. Common sense says that complicated technology is more likely to break down than simple technology. Java is pretty complicated, and several breakdowns have happened in the past. 
If you're the average person, you don't have the time or the desire to examine Java and look for implementation errors. So you have to hope the implementers did everything right. They're smart and experienced and motivated, but that doesn't make them infallible. 

When Java security does break down, the potential consequences are just as bad as those of an ActiveX problem: a hostile program can come to your machine and access your data at will. 

What about "signed applets" in Java?
One problem with the original version of Java is that the "sandbox" can be too restrictive. For example, Java programs are not allowed to access files, so there's no way to write a text editor. (What good is editing if you can't save your work?) 
Java-enabled products are now starting to use digital signatures to work around this problem. The idea is like ActiveX: programs are digitally signed and you can decide, based on the signature, to give a program more power than it would otherwise have. This lets you run a text editor program if you decide that you trust its author. 

The downside of this scheme is that it introduces some of the ActiveX problems. If you make the wrong decision about who to trust, you could be very sorry. There's no known way to get around this dilemma. Some kinds of programs must be given power in order to be useful, and there's no ironclad guarantee that those programs will be well-behaved. 

Still, Java with signed applets does offer some advantages over ActiveX. You can put only partial trust in a program, while ActiveX requires either full trust or no trust at all. And a Java-enabled browser could keep a record of which dangerous operations are carried out by each trusted program, so it would be easier to reconstruct what happened if anything went wrong. (Current browsers don't do this record-keeping, but we wish they would.) Finally, Java offers better protection against accidental damage caused by buggy programs. 

Making an irresponsible, uninformed response in allowing Java or ActiveX to run - when using a non-Administrative account, is less dangerous. System changes cannot be made. So use the LUA account when surfing the web! Internet Explorer 7 also does not allow ActiveX scripts to run without you granting permission, another safeguard.

2. Only allow children and computer illiterate users on a multi-user account to log in on a LUA (Limited User Account,) not having administrative permissions to make system and security changes.

3. Configure your security-protective programs grant access or change system properties automatically by set rules rather than prompting the current user which way to go! Uninformed users will often make the wrong choice and allow a change that is a security risk. When in doubt, deny the request! Better to be asked the question again than to allow a bad change that you may suffer the consequences in security compromise.

Allowing configuration changes with blind trust - is a primary way to get your system compromised. Your defensive shields are at the mercy of the user's inappropriate responses to security questions. We are impatient people wanting convenience. It is easy for the user to respond to a security alerts from his firewall, antivirus or antispyware program by hitting "PROCEED" without thinking. Don't allow that opportunity by following the three rules above and you will suffer much fewer security risks and compromise.

4. Do not allow children or computer illiterate users to install any software or introduce any files to your system from untrusted or unknown sources. Supervise and perform any installations. Ensure all data diskettes, CD and DVDs or external memory stick or drives come from "healthy" sources and scan with your antivirus and antispyware programs before inserting them into your system. Do not let your teenager buy cheap software off of eBay and then play or install it onto your system!

5. Stay educated about current and future risks for computers and the internet. Keeping your security tools and practices up to date is the only way to avoid the potential harm just a few mouse clicks away.

6. Don't depend upon companies that have your data to take responsible action

Despite the growing awareness, and threat, of the data break-ins, Taylor said that many companies that have not directly experienced information thefts remain less likely to improve their defenses. He also believes that many IT security professionals won't recommend additional data protection technologies to their employers because of fears that it will reflect poorly on their previous recommendations. 

"Companies that haven't had a breach still take the ostrich approach when budgeting for data protection, burying their heads in the sand, and often spend only one-tenth of what we see companies allocating to data security after a breach," said Taylor. 

"Security pros are afraid that pushing hard for additional tools will make their existing work and the technologies they've purchased look flawed, which is a shame because these people who best understand the technology side of the equation are trying to distance themselves from the problem."

Source      1/22/07

IT Pros Say They Can't Stop Data Breaches 
By Deborah Rothberg      August 30, 2006      Source

Updated: Nearly two-thirds of respondents in a new study say they're ineffective in preventing data breaches. 

In the wake of widely publicized security compromises at AOL and AT&T, a study released Aug. 28 by the Elk Rapids, Mich.-based privacy management research company Ponemon Institute finds that only 37 percent of IT professionals believe their company is effective at detecting data breaches. 

Citing a lack of resources and high product costs as barriers to preventing data leakage, respondents were uncertain about their company's ability to discover breaches of confidential information. Only 43 percent believed that their company would detect a large breach (involving more than 10,000 customer records) more than 80 percent of the time. 17 percent of respondents felt their company would correctly detect a small data breach (involving less than 100 customer records) more than 80 percent of the time. 

"We've gotten pretty good at protecting from spam and viruses. But, when you rob a bank, you go for the money, and that's the data. Companies are beginning to shift their priorities away from the perimeter and onto the information content," said Gordon Rapkin, president and CEO of Protegrity, a Stamford, Conn.-based provider of enterprise security management solutions. 

Respondents viewed the loss or theft of customer or consumer data as the second most detrimental data breach, even if privacy laws required notification, diminishing brand, reputation and customer confidence, and making the incident a public event. The loss or theft of intellectual property came in first in terms of risk, reputations and cost to the organization. 

Rapkin attributes many of the recent data breaches to what he calls our "Culture of Security." 

"People just don't get it. If you think about our IT culture, you wouldn't think of putting together a PC today without anti-virus software or a network without a firewall, but we still think we can create a database and not protect it. This is where the culture hasn't matured; we're protecting everything but the data, and we need a cultural shift." 

Though 66 percent of respondents reported the use of technologies to help their organizations manage the leakage of sensitive or confidential information, cost was the primary reason cited why organizations would not use these technologies. Thirty-five percent felt that they were too expensive, 16 percent felt manual procedures were adequate, 16 percent felt that their organizations were not vulnerable to breaches and 12 percent criticized existing technology-based data for having too high of a false positive rate. 

"It's interesting that they claim cost as a reason they're not taking greater precautions. An earlier Poneman study found that the average data breach cost $13 million, and I estimate that this AT&T one will cost way more. Companies are still thinking 'it's not going to happen to me,' worrying about protection and not prevention," said Rapkin. 

Many respondents believed that their organizations did not have the right leadership structure or enough resources to properly enforce compliance.