#Trusting obscurity software
#Trusting obscurity code

Apparently he wrote code used by agents in the field to cable back to the home office.

The really disturbing thing is that Hanssen created code (in C and Pascal) that was (is?) used to carry out various communications functions in the FBI. During some of that time, he was root on a UNIX system. Hanssen was assigned to the FBI counterintelligence squad in 1985, around the same time he became a traitor to his country. Hanssen carried out the ultimate insider attack against U.S. The moral here is that it pays to be paranoid. Remember that employees may like your environment, but when it comes down to it, most of them have a business relationship with your company, not a personal relationship. Given that most attacks are perpetrated by insiders, there's a large logical gap here, suggesting that most of the people who believe they can trust their employees must be wrong. When we point out the possibility of an insider attack to clients, we often hear 'That won't happen to us we trust our employees.' But relying on this reasoning is dangerous even though 95% of the people we talk to say the same thing.

#Trusting obscurity software

If someone is really intent on getting to software through illegal means, it can probably be done. Think about the fact that many companies are not able to protect their firewall-guarded software from a malicious janitor. Sometimes the employee isn't even disgruntled maybe he just takes his job home, and a friend goes prodding around where she shouldn't. Several studies show that the most common threat to companies is the insider attack, where a disgruntled employee abuses access. This actually happened to Id software right before they released the first version of Quake.Įven the most secure networks are often amenable to insider attacks.

Think through a scenario in which some unanticipated flaw lets an intruder steal your software. Avoid trusting even a dedicated network if possible. It may appear that software running server-side on a dedicated network could keep secrets safe, but that's not necessarily the case. Cracks for interesting software like DVD viewers or audio players tend to show up on the same day that the software is officially released, and sometimes sooner. For years, there was an arms race and an associated escalation in techniques of both sides vendors would try harder to keep people from finding the secrets to 'unlock' software, and the software crackers would try harder to break the software. Skilled youths will circumvent any protection that a company tries to hardcode into their software, and release 'cracked' copies. The transparent binary problem is why copy protection schemes for software tend not to actually work. They can pull a binary apart, and figure out what it does. One problem is that some attackers are surprisingly good at reverse engineering binaries. However, as we discuss in Chapter 4, keeping the 'secrets' secret in a binary is incredibly difficult. Many people make an implicit assumption that secrets in a binary are likely to stay secret, maybe because it seems very difficult to extract secrets from a binary. These kinds of requirements are almost always high on the list, but turn out to be far more difficult to meet than the average user may suspect. Top-secret algorithms need to be protected from competitors. Keys must be kept secret to avoid eavesdropping and tampering.

Users don't want their personal data leaked. In Chapter 5, 'Guiding Principles for Software Security,' in 'Principle 8: Remember that Hiding Secrets Is Hard' from pages 109-111: 1 We include two relevant principles from Viega and McGraw. In other words, it's quite valid to use obscurity as a small part of an overall defense in depth strategy. Obscurity is a useful defense, so long as it is not your only defense. Other parts of this book show many examples of how such information can be found. Even if this is not true, it is trivially easy for an attacker to determine obscured information. According to Howard and LeBlanc in Chapter 3, 'Security Principles to Live By,' in 'Never Depend on Security Through Obscurity Alone' from pages 66-67:Īlways assume that an attacker knows everything that you know - assume the attacker has access to all source code and all designs.