How do we know that the systems that we are using are secure? At what point do we have to audit the software that we use? How do unknown security threats affect software over time?
closed as not a real question by Gilles, Adnan, lynks, AJ Henderson, Lucas Kauffman May 17 '13 at 14:11
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.
Nothing is ever really secure.
That's true as long as people are still people. If you ask any developer about their programming project they can probably give you two-to-three hypothetical scenarios where someone could exploit their code (and how). In every development project there are always high-level decisions to be made, many in regard to the level of security the project warrants. This happens either because of lack of budget, lack of planning on the part of the development (or management) team, and simple oversight (can't see the forest for the trees). Because everything that we as a people do these days interfaces with some sort of external connection whether it's an ethernet cable, bluetooth dongle, wifi card, a cell tower, an ATM card reader (maybe a stretch), or even external USB devices such as thumb and hard drives there are never any secure machines.
Software audits should happen frequently (if not multiple times a day), but the frequency of the audits depend on a few things:
Unknown security threats that arise after a software (or hardware) is released are commonly patched. Since most patches are released publicly as security updates, software updates, and firmwares this makes all other versions of the software(s) prior to the most recent currently patched version vulnerable to the now documented exploit the patch is supposed to be fixing.
An undocumented attack where no patch exists is referred to as a zero-day attack. Here is a recent warning about a Microsoft Internet Explorer 8 Zero day attack vector.
Most major antivirus / security monitoring applications will have a Bayesian pattern matching system sometimes referred to as a heuristic analysis in place that tries to prevent anything that looks similar to a documented style of attack that is happening live on a machine.
Security isn't about making something impossible to break. It is about a cost/benefit balance between usability and protection. It is practically impossible for any system to be 100% secure, however it is possible to make the effort required to break a system exceed the potential value of compromising the system.
Additionally, protective measures may reduce the value of the system to the legitimate users, so the risk has to be assessed and an educated decision made about where the appropriate balance between investing in protecting against attackers vs allowing ease of use for valid users.
The essence of security is about figuring out the best ways to allow users to do good things while preventing attackers from doing bad things in order to maximize the amount of protection that can be provided to make attacking less worthwhile. In most cases (unless you make yourself a target) you don't have to be completely secure, you just have to be more secure than the next guy of equal value. Even if you are targeted, you just have to be secure enough that the attacker will spend more attacking you than they will get from the result.
But no, we can't know things are secure, because even if a good effort has been made, a sufficiently determined attacker could always find a way to break it (even if that way is coming over to your house and threatening to bash your kneecaps with a wrench.)
In a (too simplified) nutshell, you have to balance the cost of loss and/or theft of information, with the cost to (try to) prevent them.
The book Practical Unix & Internet Security (3rd ed.) has a good (and very general, for every systems) introductory chapter talking about the security -vs- cost approach, and is a very interresting read.