Blizzard Entertainment, makers of the phenomenally-successful multiplayer game World of Warcraft, have introduced two-factor authentication for logging into the game.  For $6.50, they’ll sell you a dynamic password keychain token called the Blizzard Authenticator, which looks much like the RSA keyfobs many in the IT industry use to log into their corporate VPNs.

It may seem silly to use two-factor auth for a video game.  However, with 12 million players, World of Warcraft is a big business, and stolen accounts are worth money.  Logging into someone else’s account, looting it for virtual money and supplies, then selling them on the open market can easily net $50 per account, more for particularly lucrative ones.  What’s more, the account itself can be sold to offshore “gold farmers” who have a constant need for accounts as Blizzard revokes theirs for Terms of Service violations.  Considering that a stolen credit card number is usually worth only about $10, WoW accounts are actually pretty good targets for theft.

People steal these accounts via installing old-fashioned key loggers — Trojan Horses attached to downloaded software that monitor the user and steal their password when they log into WoW.  Generally these keyloggers are attached to fake WoW cheat programs with names like “WoW stat changer“, or modern recreations of some early real cheats that no longer work (the “speed hack” and “teleport hack.”)  Aspiring cheaters download and install these applications and are disappointed to find they don’t work, but don’t realize that their account has been stolen when the app was run.

The best mitigation to this would, of course, be not to download dubious cheat programs for World of Warcraft.  However, since downloading and installing UI add-ons is a normal activity by WoW players, it is perhaps a bit much to expect players to know the difference between a safe UI add-on (written in Blizzard’s LUA scripting language) and an unsafe one (with real executable code.)  So Blizzard offers a two-factor token, which renders a stolen password useless — since the dynamic passwords change every minute and are not reusable, keyloggers can no longer steal accounts.  If you’re a World of Warcraft player who downloads & runs a lot of not-very-trustworthy Internet software, $6.50 is a small price to pay for security.

The ironic thing about this is that most banks won’t offer this level of security to their customers.  The loss of my World of Warcraft account would be a minor inconvenience (Blizzard keeps backups, after all, and can “roll back” a player’s account to a previous state upon request), while the theft of bank accounts and credit cards would be much more serious.  Yet my bank offers only passwords for protection, and other banks’ “two-factor authentication” isn’t really (”something you know” and “something else you know” is not two factors, it’s one factor repeated twice.)  Banks usually cite cost as the reason, and at the $90 for an RSA token, that sounds reasonable — but if Blizzard can put out their own tokens at $6.50, banks could, too.  The real reason is that the banks do not want to inconvenience their customers by making them carry around an additional object for access to their accounts.  For the most part, customers care more about convenience than security, and many customers would be locked of their accounts by losing a token than would be saved from theft.  (For that matter, customers don’t even know it when their bank account isn’t stolen because of a security measure, so they have no perceived benefit at all.)

Blizzard’s answer to the convenience/security tradeoff is to give customers the option — you can get an Authenticator if you want one, or just use passwords otherwise.  Banks don’t want to do this, though, because it would make password-only customers feel insecure.  The availability of a token might make them realize how unsafe a password alone is, and they might decide to forgo online banking altogether.  This is the last thing banks want — online banking is much cheaper than tellers.

Auren Hoffman at Summation has an interesting post on the “black hat tax.”  Essentially, how much do hackers and other online criminals actually cost us?  He estimates it at 25% of time and resources, after taking into account not just hackers but also scammers, phishers, and responding to law enforcement requests.  According to James Currier (who founded a good number of social-networking type sites, some of which are quite substantial), this “tax” is 25-40% for consumer Internet companies, with it being especially high in unexpected places (like online dating sites.)

That’s a lot of money.  More importantly, it’s a lot more money than most managers think we’re spending on security.

Now, the accuracy of these statistics is obviously dubious — even a respected and experienced person’s ad hoc estimate is still just an ad hoc estimate.  But it’s worth thinking about this for your company.  How much time and effort gets spent on problems that are, if not strictly security problems, problems you wouldn’t have were it not for malicious users?  This includes not just the things you do to defend your sites (firewalls, IDS, code reviews, etc.), incident response, and responding to subpoenas.  It also includes having to carefully write & test your emails to make sure they don’t get caught in spam filters, and setting up logging & auditing on your sites so you’ll be capable of responding to a subpoena if you get one in the future, and planning for regulatory compliance, and some of your disaster recovery & backup costs.  Consider not just purchases of security hardware & software and the hours of work by the security team, but also all the time consumed by product development and IT teams planning for or responding to security threats.

This “black hat tax” is your real security budget.  And importantly for security managers, this is a genuine, demonstrated cost, as opposed to the “risk” we spend most of our time talking about.  It’s one thing to say the company might suffer a $10 million loss in the case of a data breach, so we need to spend more on security.  Managers can go on believing that “it won’t happen to us.”  It’s quite another to say that the company already does lose $500,000 every year due to the cost of dealing with malicious users, and that we should spend that same money proactively, on planned security measures, rather than spending it reactively.  Don’t just think of your security budget as simply mitigating risk — think about what your company is already spending, just not on the security team.  Can you prevent some of that cost from being incurred?  Can you centralize some of these effors?  Security spending as a way to reduce cost, rather than as a cost center, may be a lot more appealing to your CIO.

HexView has an article about tracking vehicles with RFID tire pressure monitors. The devices are found in tires and transmit tire pressure to the engine control module, which sounds innocuous enough, but to prevent modules from reading neighboring cars’ tires by accident, they also transmit a unique ID. Thus, you can follow a car around town based on its ID, turning tire pressure monitors into tracking devices.

RFID devices are becoming more and more common, and this trend will continue — they’re too convenient for many purposes for the security risks around them to stop them. You may not want every consumer good you buy to be tagged with an ID that lets people watch your shopping from 100 yards away, but the scenario of being able to check out at the grocery store by instantaneously scanning every item in your cart simultaneously is too compelling for people to resist.

Bruce Schneier has a post on the ineffectiveness of security cameras, but while calling them ineffective it does note that criminals moved their crimes to somewhere the cameras couldn’t see. This may be “ineffective” for a government camera system designed to deter crime, but it’s precisely what privately-owned security cameras are meant to do — make a target unappealing so criminals go elsewhere. This actually shows that cameras do deter crime… but only where they can see it.

However, both of these technologies can have pernicious effects, too. The HexView article points out that you could use the RFID tire monitors to commit murder — set a bomb with a radio trigger that goes off when the “right” car drives over it. It would also be just as useful to private investigators spying on citizens as it is to law enforcement chasing down criminals. And speaking of law enforcement, these cameras create a dangerous imbalance in their favor — the camera evidence is all under their control, and thus can come up when needed to prove a perpetrator’s guilt yet be conveniently lost in cases of police brutality, abuse of power, corruption etc.

This is an interesting time for surveillance — police and government surveillance ability is skyrocketing (London is practically blanketed in cameras at this point, as the British seem much less uncomfortable with them than Americans are) but it is still largely in the hands of authority figures. This is dangerous because of how fast the change is coming — our criminal laws and sentencing structures are based on the principle that most criminals get away with it. A $75 fine for speeding seems pretty reasonable, but what if that fine were levied every time a car hit 1 mph over the speed limit? Most of us would get fined a dozen times a day, every day, despite not even meaning to speed, because our behaviors are based on the idea that we probably won’t get caught and that even if we are police are unlikely to punish us for very minor transgressions. If people were caught for speeding every time, and fined every time, a $75 fine would be absurd — the fine could probably be under $1 and still bring in a few hundred dollars a month from every citizen. What is the right legal structure here? I can see two possibilities:

• Raise the speed limits to the speeds we really think no one should exceed, and continue to fine every time.  Maybe you should get charged every time you exceed, say, 85 on a highway or 55 on a city street.  Set them high enough that there’s no leeway required.
• Leave the speed limits where they are but set the fine really low, say a $0.25 per minute of speeding.  This makes speeding discretionary — you can obey the law, or not, but if you choose not to you pay a penalty.  This is a fundamental change in the whole idea of crime and punishment, and itself has some pernicious consequences — it means that a certain income level can render you “above the law,” which is not a good thing.  Obviously some crimes (such as murder) should not be treated as discretionary, but for traffic violations it could make sense.

It’s not just traffic laws that are like this; consider the War on Drugs.  If every person who ever smoked marijuana went to prison, we would have a nation of felons — there’d be few people left who could vote, get security clearances, hold most jobs, etc.  The RIAA lawsuits against file-sharers are a good example of what happens when technology that catches everyone gets used to enforce laws designed under the assumption that only the worst and most flagrant criminals will be caught — people being hit by millions of dollars in fines for using technology to do something that wouldn’t even raise an eyelash if done by old, physical means (e.g. posting a song on BitTorrent vs. handing it to a friend on a cassette tape.)

A surveillance society needs a different kind of jurisprudence — one that sets punishments that fit the crime even if applied every time.  On the bright side, actually doing this would lower crime rates tremendously due to the psychology of criminals.  Escalating punishments does little to deter crime because criminals are risk-seekers — they do not expect to get caught.   Even a small punishment can be a strong deterrent if applied every time — if criminals are usually caught, such that all criminals have some first-hand experience with being caught and punished, it would break this idea.  On the not so bright side, a surveillance society must have very liberal laws to avoid being a police state — our current legal system, applied to everyone every time, would result in tyranny.  We all break 10 laws a day, it’s only sloppy enforcement that allows us to live our lives.  Unfortunately, the technology for ubiquitous enforcement will come well before the legal system changes to make it livable do.

What’s interesting to me is what will happen when surveillance becomes even more common: that is, when it is no longer monopolized by authority.  This has already started with cellular phones.   Almost everyone carries around a device which, while primarily for communication, contains a camera and often a voice recorder and videocamera as well.  Everyone is equipped to carry out impromptu surveillance at any time.  Devices like these glasses from ThinkGeek (found via BoingBoing) coupled with the rapidly falling cost of storage capacity will change this to everyone actually carrying out impromptu surveillance all the time.  This will have a chilling effect on human behavior at first — would you act differently if you knew everyone around you was videotaping everything you did?  Everything you say will, indeed, be able to be used against you, and not just in a court of law.  However, look at what young people put on MySpace and Facebook these days — the next generation does not have the assumption of privacy.  They’ve grown up in a world where they know everything goes on a permanent record, and have simply accepted it.  Sure, they’ll be occasionally shocked by it (e.g. the first time their party photos on MySpace disqualify them from a job), but the knowledge of permanence has not stopped them from sharing themselves, and eventually the rest of us will adjust, too.

Consider what the democratization of surveillance does to government power.  When we’re all recording, someone is watching the watchers.  Corruption, abuse of power, etc. all rely on the fact that authority figures can get away with crimes because they are more reliable witnesses in court than their victims are.  When everything is on the record — and not just the official record, but everyone’s record — police and government officials become compelled to act within the law.  While this may not be much of an impediment in truly totalitarian societies like China where the courts are as corrupt as everyone else, it’s a very strong bulwark of freedom in any society with an independent judiciary and a liberal tradition like the Untied States and Europe.  This is the next generation of surveillance — everyone sucking in light and sound from their glasses, or lapel pens, or even contact lenses, recording every moment of their lives on multi-terabyte devices that fit in their pockets.  It’s probably only 5-7 years away, and it washes away the current problems of a surveillance society and replaces them with new ones.

I think this cycle will continue for some time.  After all, once we’re past the era of democratized surveillance, computer graphics and artificial intelligence technology will improve to the point that ordinary people can modify their recordings to create perfect video of events that never happened, indistinguishable from the real thing.  What happens to recordings in law courts then, when they cease to be reliable evidence and become hearsay?  Tapes will become the new eyewitnesses, known to be unreliable and requiring corroboration from others.  When it becomes truly easy to make forged video, perhaps we will have emerged from the surveillance society from the other side — why bother to record anything when there’s no way to tell if it’s real?  Sometimes the only way out is through.

The Today Show has a cover story today entitled “Mom lets 9-year-old take subway home alone.” The controversy over this — that is, the fact that there is any — is a wonderful example of how poorly people assess risk in modern society. What this woman, Lenore Skenazy, has done to stir up trouble is to make a decision about her child based on reason rather than emotion (specifically fear) — something that seems frighteningly uncommon today. As she puts it:

“It’s safe to go on the subway,” Skenazy replied. “It’s safe to be a kid. It’s safe to ride your bike on the streets. We’re brainwashed because of all the stories we hear that it isn’t safe. But those are the exceptions. That’s why they make it to the news. This is like, ‘Boy boils egg.’ He did something that any 9-year-old could do.”

She’s right. Most of us in our 30’s today remember growing up in the 1980’s — and it involved riding your bike across town, visiting neighbors, and being unattended for relatively long periods of time. Of course there were unsafe areas – there were parts of cities where people alone really aren’t safe — but these are the exceptions rather than the rule. Today, most parents seem to live in fear, convinced that there are criminals lying in wait to abduct children everywhere. It simply isn’t the case — it never has been, and crime rates are lower today than they were in the 80’s! We have not gotten any less safe, we have simply become so afraid that we think we’re less safe. And this culture of fear is damaging and contagious:

“Half the people I’ve told this episode to now want to turn me in for child abuse. As if keeping kids under lock and key and helmet and cell phone and nanny and surveillance is the right way to rear kids. It’s not. It’s debilitating — for us and for them.”

There are a variety of reasons that people believe that their children are under constant threat. Among them are:

• Vividness criterion: shocking anecdotes stick in our memory more than statistics, and they attract our attention. This is both why the media reports on every bad thing happening to a child, and why we remember them.
• Availability bias: when determining how frequently something happens, rather than turning to statistics we turn to how many cases of it we can remember. Since the news reports on every plane crash, but almost no auto accidents, we think of air travel as riskier even though we know the statistics show differently. Since in this age of pervasive news reporting we hear about crime more often, crime must be more common, even though the statistics show differently.
• Fundamental attribution error: when something happens, we tend to overestimate behavioral causes. So when a child is hurt, we assume the parents did something wrong, even if the event is random and exceedingly rare.
• We overestimate risks from intentional causes and underestimate risks from natural causes. This is probably related to the vividness criterion — someone deliberately hurting a child is more shocking than the child being hurt in a bike accident. The result is that we expect people to be malicious a lot more often than they are, and we think children are more likely to be hurt by criminals than by illness or car accident, once again despite statistics showing otherwise.

In truth, the violent crime rate today in the United States is less than half of what it was in the 1980’s! Most of our burgeoning prison population consists of nonviolent drug offenders, and most violent crime occurs in geographically delimited areas. Skenazy is right — the streets and subways of New York City are as safe as they were in 1963. Crime against children is even lower — the simple fact is that the overwhelming majority of humanity doesn’t want to hurt kids and is inclined to help and protect them.

It’s sad how many normal childhood experiences have been lost to this obsession with safety from small risks — just try to buy a chemistry set today even as an adult and compare it with what was available to young children 20 years ago (or to what’s in The Golden Book of Chemistry Experiments, now available pretty much only via BitTorrent, which begins by teaching children to use an alcohol burner to shape glass tubing. Today, a children’s chemistry set would never be allowed to contain an alcohol burner… or glass tubing.)

The key is this:

‘The statistics show that this is an incredibly rare event, and you can’t protect people from very rare events. It would be like trying to create a shield against being struck by lightning.’ ”

She said that people ask her how she would feel if one of those terrible and rare events happened to her son. “It would be horrible,” she said. “But you can’t live your life that way; you could slip in the shower.”

When faced by extremely low risks, the rational response is sometimes to disregard them. Sometimes the response to fear of something is, in aggregate, worse than the thing itself. We of course do the same thing with terrorism, and these same biases cause us to misallocate security dollars in industry, too (how many companies have tens of thousands of dollars in firewall and IDS hardware, but no disaster recovery plan?)

On January 21st, 2008, the major French bank Société Générale lost $7.09 billion attempting to unwind unauthorized trading positions taken by Jérôme Kerviel, a futures trader with the bank. Kerviel had taken positions worth $73.3 billion, far above not only his trading limits but the bank’s entire market capitalization. The loss taken by unwinding the positions during a declining stock market was the largest rogue trader loss in history, dwarfing the $1.4 billion loss by Nick Leeson that collapsed the venerable Barings Bank in 1992.

For all that we in the security industry picture threats coming at our companies from without, sometimes the greatest threats lie within. No external hacker has ever done the kind of damage that rogue insiders like Kerviel and Leeson are capable of, yet we focus on putting firewalls around our companies, rooting out worms and viruses, and securing our websites. While these are undoubtedly important, it is equally important to protect against internal adversaries — and often much more difficult.

The Problem of Trust

Companies must trust their employees — without the employees, there is no company. Accountants and traders are trusted with financial records, system administrators and information security personnel are trusted with access to critical files, physical and cleaning personnel are trusted with physical access to the facilities, and managers are trusted with company secrets, strategy, and intentions.

IT employees and developers are specialists.  As systems increase in complexity, those trusted with building and maintaining those systems are required to obtain knowledge further and further from most people’s understanding. Often, knowledge of how to build and maintain these systems also involves the knowledge of how to subvert them. IT engineers and developers know how their systems break down — they know their weak points, where they’re being watched and monitored, and where no one is looking. This problem isn’t unique to information technology — an aircraft mechanic probably knows how to sabotage a plane without leaving a trace, and members of police and military bomb squads are experts on explosives and what cannot be detected or tracked. And as recent news has demonstrated, traders in brokerages and banks know how the internal controls of their corporations work, and where they break down. Internal attackers are thus the most dangerous of all — they are already equipped with the kind of domain knowledge that an external attacker might need to spend weeks or months gathering.

Although we cannot entirely abandon trust in a company’s employees, we should consider where this trust comes from and whether or not it is warranted. Many companies sharply divide the level of trust and privilege given to employees vs. that given to contractors and vendors within their IT and development departments. The theory is that employees are allied to the company for the long term, and compensated with long-term benefits like retirement plans and vacation time that they will be unwilling to risk for short-term gain while vendors and contractors have less loyalty since they come and go as needed. However, in today’s IT world, is this really the case? I do not doubt that the contractors feel little loyalty for the company, but it is increasingly doubtful that the employees do, either. The average IT employee’s tenure at a corporation is now under 18 months — and thus they place little value on long-term benefits. Books like Corporate Confidential advise employees to view their employment relationship as, if not outright adversarial, at least mutually exploitative, to be dropped by either party as soon as it becomes in their interest to do so. Employees see that corporations no longer feel loyalty to them — the days of the job for life are over — and so loyalty to the corporation has gone as well.

Of course, lacking a strong sense of corporate loyalty does not lead most employees to embark on rogue-trading schemes, steal from their employers, commit electronic sabotage, etc. And even in the 1950s heyday of the organization man and the corporate family, some people took advantage of their employees and ran off with stolen fortunes. Some people are thieves and will steal given the opportunity no matter how well-treated they may be. Others are incorruptible, bound by their own moral code that would prevent them from stealing regardless of opportunity.  The vast bulk of humanity, though, is somewhere in between.

These employees are not likely to become attackers, and trusting them is a necessary part of doing business. However, this trust need not be absolute — we can trust, but verify. While we may not be able to prevent every internal attack, we can deter them, and make them less likely to occur. Steps can be taken to help keep most people honest, reducing both the incentive and the opportunity for theft.

Building Employee Loyalty

The days of the job for life and absolute loyalty to the corporation are probably over for good, inasmuch as they ever existed at all. However, the fact remains that internal attacks, particularly those not motivated by theft but rather simple vandalism, are much more likely to be carried out by disgruntled and angry employees than by content ones.

IT employees and developers are sometimes a strange breed — the sort of person that chooses to spend their time with technology is often different from the sort of person who chooses to be a manager.  So if it’s not a good retirement plan, an increase in vacation time after 5 years, and a promise of stability and long-term employment, what does build loyalty and goodwill with technical employees?

(Of course, any generalization about a type of person is going to be more accurate for some people than others, but I’ve found these to be useful rules of thumb for dealing with technology employees.)

• Autonomy. Figuring out how to do things is precisely what geeks enjoy about work — tell them what you want, not how you want them to achieve it.
• Isolation. Technologists, all told, are not very social. They do their best work when left alone. The cubicle is a horrible environment, giving you all the obstacles to collaboration of offices but without any of the privacy. Offices are ideal for most development work, the only exception being the early stages wherein there’s a lot more collaboration and brainstorming than actual coding.
• Technology. People who love technology want to be on the cutting edge. Using current technology makes them more invested in their jobs. In addition, it’s worth investing in the technology they’ll use every day — their workstations, displays, etc.

These are important, but will not, of course, make every employee perfectly happy. There are some things that technical employees have no patience for at all:

• Arbitrary or emotionally-driven decisions.  Using an older, inferior, or simply less appropriate tool (e.g. programming language, web framework) because “the boss likes it,” “we’ve always done it that way,” or “we’re a [insert product here] shop” really upsets them.  They need real-world reasons for using a technology, like technical benefits or budgetary limitations.
• Anything perceived as unfair. If employees feel they’re paid less than market value, or that someone else who’s not as good as they are is paid more, this breeds resentment. Trying to keep salaries secret helps not at all — today’s employees, especially younger ones, for the most part don’t understand why salaries should be kept secret, and thus will totally disregard any order to do so. It is important that technical employees see cause and effect in review processes, compensation, etc. and have a clear idea of how their performance is being assessed.
• Internal politics.  Engineers want to get things done, and they don’t care overmuch who does them — when engineering solutions, they’ll totally ignore interdepartmental boundaries. Having to worry about some manager’s fiefdom-building gets in the way of technical work and is relatively incomprehensible to them.

When it comes to performance management, technical employees need to be told, directly and clearly, how they’re doing and what needs improvement (if anything. ) Not being people-oriented, they often can’t read you. They don’t know if you’re happy with them or not unless you tell them, and they’re certainly not going to ask. While they deal extremely well with technical ambiguity — they love to solve problems, so an incoherent mess from a technical perspective is just a challenge to overcome — they don’t deal well at all with ambiguity in other contexts. Clear expectations and consistent feedback make their job simply another a problem to be solved, which makes it much more satisfying to them.  Without this feedback,

For many managers, these may seem like obvious guidelines — but they’re often problems in companies, particularly in IT and development departments of nontechnical companies. These factors mean a lot to many technical employees — often a lot more than traditional compensation. The best prevention against malicious insiders is to keep the insiders from becoming malicious in the first place by ensuring that the company earns their trust and respect.

Reducing Opportunity for Attack

Unfortunately, no matter what your company does, some people aren’t going to love their jobs. In addition, presented with the opportunity to steal, people are going to be tempted — and the greater the opportunity, the greater the temptation. Thus, it is important to reduce the opportunity for theft.

The traditional information security controls are often useless against insiders. The firewall provides no protection at all against someone already inside. Anti-virus and anti-malware systems matter not at all to someone who doesn’t need to gain access to a PC on the network, as they already have access legitimately. Network access controls are impotent against the domain administrator, who has the authority to alter access control lists at will. Obfuscation and hiding secret data provides no defense against the developer tasked with performing the obfuscation and hiding.

Fundamentally, a system designed to provide security always involves an implied question — secure from what? The vault door in a bank secures against burglars coming in in the night — not against the bank manager turning rogue. Alarms secure against armed robbers, not against tellers sneaking cash out of the drawer. Security cameras watch the tellers, but do no good against computer hackers or fraudsters. Reducing the opportunity for insiders to attack the company means considering how insiders differ from outsiders, and what security measures may be employed against them.

The primary advantages of an insider are twofold: knowledge and authorization. They have knowledge of the defenses — Jérôme Kerviel had worked in Société Générale’s internal audit and control department, so he knew exactly how they searched for and detected rogue trades. And they have authorization in that an internal attack often does not involve any sort of elevation of privilege — only an employee misusing their legitimate authority. Even the right to be inside the building, rather than having to break in through a firewall, is a measure of authority an outsider lacks.

However, insiders also have a disadvantage as compared to outsiders: proximity. It is often much easier to verify a suspicion that someone has committed a crime than it is to find the culprit to begin with. As is often depicted in crime dramas and classic mystery plots, investigators have a much easier time finding out who committed a crime when they have specific suspects to question and investigate than when a crime is committed by a random stranger with no known connection with the victim. Fingerprints and DNA evidence do little good if you have no suspect to compare them to. The same goes for electronic forensics — a hacker will often leave plenty of evidence of their activity on their own computer, and a monitoring device at their ISP would likely detect their activities. However, if the hacker is external, or even in a foreign country, as a security professional you’re unlikely to have any idea where their computer is, let alone have access to it. When an insider attacks, on the other hand, the traces can be very obvious. Attacks come from IPs within your perimeter, and your own monitoring equipment might have seen the entire attack end-to-end. The simple fact that there are only so many people inside the company capable of mounting an electronic attack limits the suspects and allows each to be investigated.

Smart insiders know this. While an outsider may believe he is able to hide from detection simply by being a needle in a haystack (how many companies really inspect all their edge firewall logs, even with an automated process?), an insider knows that he’s under observation and has a substantial chance of getting caught. Thus, he will almost always take steps to cover their tracks — steps an outsider would take, too, but the insider has the advantage of legitimate authorization to bolster his abilities.

Deterring internal attackers, then, involves neutralizing their advantages while maximizing their disadvantages. There is little to be done about their first advantage (knowledge of internal procedures), but actions can be taken to mitigate the power of legitimate authorization and to maximize the disadvantage of proximity.

Preventing Abuse of Legitimate Authority

Developers can modify the source code of your product — that’s what developers do. System administrators can change permissions on files and access secured areas — that’s their job. However, no one person should have the ability to do everything — this is the principle behind separation of duties.

Separation of duties enables legitimate tasks to be carried out while making it more difficult for these same powers to be abused. There are three basic controls that can be placed on a power to help prevent abuse:

• Authorization: determines if a person has the right to perform a task
• Recording: keeps a record of when, how, and by whom the task has been performed
• Custody: actually carries out the task

For example, imagine your company needs to deploy new code to a server in a datacenter. The person responsible for the authorization function sets the access control policies on the various machines to determine who has access. The person or system responsible for the recording function makes entries in change-control logs so that it is clear what has been done. The person with custody of the system actually places the new files on the server. In a small company — or one with poor internal controls — these could all be the same person.

If these tasks are all handled by the same person, the potential for abuse is very high. If this person wants to propagate malicious code to the servers that monitors transactions or even steals money from accounts, he can do so. He can authorize himself or another (possibly even a fake account) to make any change desired, carry out the task, and then erase or suspend the logs or records of not only the action but also the authorization changes.

On the other hand, if separate people are responsible for each of these tasks, none of them is capable of perpetrating a fraud on their own. This process could be organized as follows:

• A product team or business owner is responsible for developing the system and determines who can modify the code.
• A division of the IT department is responsible for all audit logging throughout the environment, regardless of who owns the particular servers.
• An operations engineer is responsible for actually placing code on the servers; the developers never have access directly to the production datacenter.

This makes fraud much harder. A member of the product team can tamper with the code, but has no way to actually get it into the datacenter. An operations engineer can access the datacenter, but lacks access to the code. And either one making a change leaves a trail — since audit logging is controlled by another team within IT, neither are able to turn auditing off or simply overlook suspicious entries.

Maximizing the Chance of Detection

Separation of duties limits the ability of a person with legitimate authority to abuse it. However, the is another thing that can be done to those people with the ability to abuse their authority from actually doing so — cause them to believe they are likely to be caught. Internal attackers know what audit and logging systems are being used within an environment, and they know where the “blind spots” in those systems are. Many criminals commit a crime only when the opportunity presents itself.  By eliminating failures in monitoring, we eliminate temptation as well as improving our forensic abilities.

Most of the systems used in a modern IT environment have extensive auditing capabilities. (Note that I am using the word “auditing” in the sense of creating an audit trail, not in the sense of some external consultant or accountant reviewing that trail.) Windows machines create an event log of almost everything that happens on them; in an ActiveDirectory domain, security events are also logged on the domain controller. UNIX/Linux/Solaris machines create various system logs, and have the ability to send them to remote machines as they occur. Databases like Oracle and SQL Server have fine-grained audit capabilities and are able to record every access to sensitive data and even detect potential data aggregation attacks. Web servers record every access, as do keycard-based entry control systems, VPN concentrators, firewalls, and a variety of network devices. An attacker, even an internal one, leaves a bewildering array of changes, alerts, and traces every time he does anything.

However, this does little good if no one notices the tracks! In addition, they are often ephemeral — a Windows Security Event Log will grow too large and begin overwriting itself in a matter of hours in a large corporation. If the logs are not available to investigate an incident, they might as well not exist at all.

One of the most powerful ways a company can prevent internal attacks is with the implementation of a Security Information and Event Management product. There are several of these on the market (I have experience implementing the SenSage event data warehouse, but ArcSight, Symantec, IntelliTactics, Computer Associates, and others have competing products,) but the idea behind all of them is to gather event data from a variety of sources and aggregate it in one place. This has two major advantages:

• The data is centrally managed by a separate custodian than the one that controls the various systems it came from, thus providing separation of duties.  The system administrators of the systems creating the logs cannot tamper with the logs.
• Data from disparate sources is correlated together, thus detecting attacks in progress and tracing attacks back to their source during an investigation.  Forensics is made easier and more effective.

Different SIEM systems have different advantages, and while all will provide separation of duties, some are better at handling massive data volumes than others. Likewise, the data mining involved in event correlation is still a black art in many cases, so different systems have different capabilities in that regard. However, just knowing that a SIEM exists, is monitored, and is out of reach for would-be fraudsters to tamper with can be a powerful deterrent against rogue employees.

Conclusion

The possibility of internal attacks is an unfortunate consequence of the specialization of modern society — those with the capability to build and maintain complex systems are often those best able to compromise and abuse them. However, good design of internal controls centered around separation of duties combined with judicious use of technical information-management solutions greatly reduces the opportunity for insiders to turn against a company’s infrastructure.

Today I found a link to an article by my least-favorite current presidential candidate, Rudy Giuliani. I was expecting a cavalcade of fear-mongering — his usual stock in trade — but discovered to my surprise an article entitled “The Resilient Society.” This gave me pause, as resilience is precisely what I believe must be the necessary societal response to the distributed threat of terrorism. Security must be divided into prevention, detection, response, and recovery — resilience is the ability to quickly recover from attack at as low a cost as possible. Resilience is the difference between a society changing its entire way of life in response to a terrorist attack vs. society being able to return quickly to normalcy, thus making itself impossible to terrorize. I was not expecting to hear about resilience from Rudy Giuliani — after all, this is the one aspect of national security that cannot be centralized around an all-powerful government (Giuliani’s obvious goal), but rather relies on the distributed strength of every citizen. Was I about to actually agree with an article by Giuliani?

It turns out that I had nothing to worry about. Despite its title, there are only four paragraphs about resilience in the 41-paragraph article, and even those are wrong.

So what does Giuliani think must be done to defend a society from terrorism? Primarily a command-and-control response process combined with offensive attacks on the sources of terrorism.

With regard to prevention, Giuliani favors deployment of massive detection nets to fight against the attacks we’ve already faced — radiation and biohazard detectors at every port and point of entry. The cost-benefit ratio of this would be astronomically poor; as a free society with mostly open borders, there are a phenomenal number of entry points to the United States, and only very rarely (possibly never, so far, though the government would not be likely to tell us if it did happen) does anyone try to smuggle weapons-grade nuclear material or biological weapons through it. This isn’t to say that these measures would do no good, but they protect only against specific attacks and are obvious. They signal to terrorists “you can’t bring a nuclear or biological weapon through a shipping container in a port,” thus letting them know they should instead a.) use conventional weapons, b.) acquire nuclear/biological materials already inside the United States, or c.) enter via uncontrolled border space. If I, in three minutes, can think of three easy ways around a measure that will take billions of dollars to implement, it’s not very cost-effective.

He discusses the difficulties in information sharing between law enforcement and military agencies, clearly seeing these as an unalloyed negative. He’s right that there have been clear communications breakdowns, where these organizations had information that they were legally free to share, but chose not to out of myopia or the desire to preserve the institutional sovereignty of their silo. Despite the Central Intelligence Agency being founded to ensure all military and civilian intelligence agencies share information, it has in many cases become the most isolated hoarder of information of them all, and this is a problem. However, in other cases the obstacles to information-sharing are the civil liberties guaranteed by the Constitution. Giuliani has no issue with sweeping these away — this is, after all, the person who claims “Freedom is about authority. Freedom is about the willingness of every single human being to cede to lawful authority a great deal of discretion about what you do. You have free speech so I can be heard.” (That quote is not taken out of context in any way. He did not, however, go on to add “War is Peace. Freedom is Slavery. Ignorance is Strength.”)

Judicial oversight is not inimical to detecting and stopping international terrorism. Judges do not want terrorist attacks to happen, either; these protections exist to ensure that normal people are able to live their lives without constant monitoring. Surveillance is not unintrusive. Comamnd-and-control executives like Giuliani think that it does not matter if people are being watched, as only the “bad guys” will be prosecuted, but this simply isn’t true. First of all, people change their behavior when they know they’re being watched. It has a chilling effect not just on actually criminal behavior, but also on any behavior that people consider “socially unacceptable.” Surveillance drives everyone toward the mainstream center of society, homogenizing them; it creates the very opposite of a free society. (For a chilling illustration of this, I highly recommend Charles Stross’s sci-fi novel Glasshouse, one of the best and most terrifying books I’ve ever read, though it requires a high tolerance for transhumanist concepts.) Second, who watches the watchers? Even if Giuliani’s motives are pure (they’re not), and he wants to use these tools of warrantless surveillance, imprisonment without trial, etc. only against international terrorists, no one can possibly believe the entire law enforcement apparatus of a 300-million-person nation is entirely free of corruption and petty tyranny. Security has a cost — Giuliani looks only at how these measures benefit security, ignoring their unintended consequences. Security is of limited value — a terrorist attack is tragic but it does not end the world. We must not embrace “security at any cost” — instead we must consider security at a cost that we can bear, and most importantly, not allow the cost of security to exceed the cost of terrorism.

Giuliani also wants a “good Samaritan” law for people who report suspicious activity, protecting them from lawsuits. This is a terrible idea. Lawsuits are there to provide a cost for making a false of frivolous report — people will still report the man walking down the street with a pile of dynamite, but they think twice about reporting possibly-suspicious but almost certainly innocuous activity, like speaking Arabic in an airport, or loitering in a parking lot. Making reporting costless means you’ll get an inevitable excess of it, resulting in both the chilling effect of universal surveillance and a waste of law enforcement’s time. When people are encouraged to report everything unusual, you drown in reports and make people paranoid. This teaches people to react to the unknown with fear — that is, it accomplishes precisely what terrorists aim to accomplish. People reporting suspected terrorist activities should not be immune from lawsuits; rather, courts should decide whether the report was reasonable and take appropriate action. Often the reporters should be held blameless, having had a reasonable reaction that turned out to be incorrect, but doing so automatically makes filing false reports a simple way for private citizens to use the nation’s law enforcement apparatus as a means for private revenge.

Giuliani also calls for “tamper-proof biometric ID cards” for all non-citizens. As a security professional I can’t help but chuckle when anyone uses the word “tamper-proof.” But there’s nothing terribly wrong with this… except that it doesn’t do any good. We already know when people enter the country legally, and we identify them then; if they sneak in, they’re not going to have a “tamper-proof biometric ID card” any more than they have a regular ID card now. In addition, identity alone does not provide security. The fact that you know who someone is does you little to no good if he does not have a background in committing terrorist acts. And if he has a background in committing terrorist acts, why would you hand him a “tamper-proof biometric ID card?” Just deport him!

Giuliani supports fences around borders and stepping up guards, but claims to want to avoid turning the nation into a “fortress” in order to “deepen the connections between America and the Islamic world that will prove essential in prevailing over radical Islamic extremism.” On one hand, he’s on to something there — the only way to truly prevent terrorism is to eliminate the motivation for terrorism. Otherwise, 100% prevention is impossible — total prevention requires that you succeed every time, while the villains only have to succeed once. On the other hand, he simultaneously advocates precisely the foreign policy that creates that motivation — worldwide interventionism and American control and support of often-corrupt foreign governments. Now, the fact that a given policy makes people want to kill you doesn’t necessarily mean that that policy is wrong – but it is a cost of that policy that must be taken into account, and to claim that it will not have this effect is disingenuous.

Stepping up epidemiological surveillance and data gathering is the one good idea Giuliani has. Not only would it be helpful to detect bioterror attacks, but more importantly, it can help detect and contain natural pandemics. The emergence of a serious disease threat at some point in the future is a certainty, and unlike surveillance of people’s activities, this sort of surveillance has very little civil liberties cost.

Giuliani is obvious very proud of New York’s CompStat method of crime detection and prevention, given his desire to apply the same methodology to everything. For terrorism and border control, it makes some sense, as these are essentially law enforcement problems with a lot of parallels. However, for emergency preparedness it does not. Dividing up funding based on “need” determined by a statistical formula is absolutely certain to result in “gaming the system.” Emergency preparedness must be decentralized; there is no way for the Federal government to take care of it on a nationwide basis, or even to effectively coordinate and monitor it. Fundamentally, preparedness requires having appropriate materials on site and appropriate plans made, and no one can make those plans from afar.

Finally, Giuliani gets to the putative subject of the essay, resilience. He says, rightly, “Government should harness the inherent strength of the American people and the private sector in order to build a society that may bend—but not break—if catastrophe does strike.” It is somewhat ironic to hear this from Giuliani, who has just spent the preceding 30 paragraphs calling for increased central control of everything. His entire resilience proposal is as follows:

• Create government-organized response teams of private citizens who have been trained and equipped by government to respond to disaster,
• Pass a law shielding people from lawsuits if they are trying to help in disaster response, and
• Set government standards for how businesses, citizens, and charitable organizations should respond to disasters.

Ah, for every problem a government solution. This is precisely what resilience isn’t. A resilient society is one that responds to and recovers from disaster on its own — one that is not broken by disaster but continues to function mostly unchanged. The model of a resilient society is England during the IRA period: terrorist attacks happened, and life went on largely unchanged.

Western society is still phenomenally resilient, but not as much as it once was. You cannot build a resilient society using only government. A resilient society comes from a variety of factors, and these can do more to protect against the impact of terrorism than any technological or centralized security measure. They include:

• A culture of hope. People have to believe that every terrorist attack is an abberation, and that life will return to normal. This is what prevents a localized disaster from having repercussions on an entire nation for years to come; without this, with a culture of fear instead, the damage of a terrorist attack is multiplied a hundredfold.
• A citizenry that trusts itself. People must believe they are competent to solve their own problems, so the first reaction to a disaster is not “how will I get help,” but rather “what do I need to do?” Government cannot save everyone; if the able-bodied and passably intelligent people save themselves, government is freed up to help those who genuinely need it, and not simply those who abrogated their responsibility to plan.
• A populace that cares for others while still expecting them to take care of themselves. When disasters like Hurricane Katrina or 9/11 occur, there is an outpouring of charity from the populace to help. It doesn’t take government to solicit this; general benevolence will do, the desire to help anyone hurt by a disaster rather than using disaster as am impetus to hoard more for yourself and your tribe. However, people also must recognize the limits of charity, and be willing to go back to their own lives as time passes.

All of these are cultural shifts; we can’t impose them, and as Giuliani is running for head of government, it makes sense for him to talk about government actions. However, the statements he’s making are precisely what damages resilience. When all we hear from government is how they are expecting impending doom, and how government will save us when it happens, it does not teach us to have hope, trust ourselves, and help others! It teaches us to always anticipate disaster, do nothing and wait for help when it happens, and expect the government to do all the helping. Regardless of what the government does, this rhetoric from our politicians itself reduces the resilience of our society.

During this year’s Christmas shopping season, I made some large in-person transactions at the same time as my wife made an online transaction, and my credit card was suspended by the issuing bank for potential fraudulent activity.  This happens relatively often, whenever someone’s spending patterns are flagged by the neural-network based automated fraud detection used by all the major credit card issuers.  When calling the bank to have the card reactivated, I was told by the customer service representative, “since online transactions are, you know, more dangerous, we tend to notice those.”

This is not an uncommon perception.  Many people who think nothing of handing over their credit card or writing a check when at a store or restaurant hesitate to use the same card online, regardless of communication protections (e.g. SSL/HTTPS), third-party assurances like the preposterously-named HackerSafe, or the size and stability of the vendor.  After all, it’s the Internet, there are bad people out there.

However, the perception just isn’t true.  There are two ways in which the Internet particularly helps thieves, though:

1. Once they’ve stolen an identity or credit card number, thieves often use the card online, as they don’t have to present themselves (and thus show up to witnesses and potentially security cameras) to use the card.  This is actually probably what the credit card company in my experience meant — not that the transactions are more dangerous, but that fraudsters often use stolen cards online.
2. Hackers stealing credit card information online often steal entire databases.  They don’t steal your credit card while you’re buying something online — they break into the online store and steal everybody’s card.

However, they could just as easily have broken into the servers of a brick-and-mortar store — it’s not the fact that you used the card online that makes it possible for them to steal it, it would have been just as at risk handing it to a cashier.

In many ways, it’s a lot more risky to make non-cash payments in person!  When you hand your credit card to a waiter or clerk or cashier, they could easily copy the number, expiration date, and CCv2 code (the three-digit code on the back than an online site often won’t even get.)  With a debit card, they have the opportunity to watch PINs being typed.  Whereas in an online store, only relatively few, well-paid professionals will have access to your data (system administrators, etc.), every $7 per hour sales clerk can see a hundred card numbers per day, and probably has significantly more financial motivation to steal them (although in my experience, the fact that someone doesn’t need money won’t stop them from stealing it if they’re the type to steal — just look at Michael Milken, who defrauded people out of hundreds of millions of dollars at the same time he was making hundreds of millions legitimately.)

Some people — usually those of us who remember the days before debit cards — eschew all these fancy online and electronic forms of payment and instead stick to good old fashioned checks.  After all, no one can possibly steal those!  They’re paper, and have your signature on them.  This is the ultimate in perception differing from reality — it’s hard to imagine a less secure way to make a payment than a paper check.

First of all, there’s the ease of committing fraud with checks.  A thief with a stolen check (or deposit slip) has all they need to take money from your account — the routing number and account number (found at the bottom of the check in MICR letters.)  Note that the thief doesn’t need any kind of ID… or a PIN… or a physical card… or a CCv2 code… or even to know your name.  No, the numbers will do.  What can they do with a stolen check?  There are three basic things:

• Order up a whole book of checks with your information and account numbers on them.  No ID is required to order checkbooks online.  They can then spend these checks anywhere, and the bank will process them — you probably won’t find out until your account is empty and you start getting NSF notices.
• Remove the amount and recipient from the check and write it out to themselves instead.  This is a bigger problem for institutional checks, which are often printed on a laser printer.  It’s really easy to remove laser-printed text from an offset-printed check — just lay some Scotch tape over the laser text, rub it hard with your fingernail, and peel the text off.  Then you can print out a new amount and recipient with your own laser printer, and it looks just like the real thing.  Chemical agents (”check washing”) can do this with ball-point pen ink, too, though it’s not so easy.
• Issue a demand draft (”paperless check.”)  This is what happens when you pay by phone with your checking account number, or use an automated bill pay service, or send money via PayPal.  Using your routing number and account number, money is simply removed from your account and put into someone else’s.  No authorization or authentication is used, your name is not even required.  Yes, really.  Anyone can do this from any account to any other account.  For a while, you used to be able to do this from a web site.

Second, there’s the difficulty in getting your money back or even stopping the fraud!  With a credit card (and to a lesser extent, a debit card), it’s pretty simple — you call the bank, say you did not authorize a charge, and the credit card company removes the charge.  It is then up to them to prove you did make the charge, such as by getting a signed receipt from the merchant and matching your signature.  So long as you report the fraud within 30 days, you are not liable — the worst the card company can do to you is to cancel your card (but you still don’t have to pay for the charge you didn’t make.)  In theory, you’re liable for up to $50, but almost no card issuers really charge this since it’s terrible customer service (”Sorry you were stolen from!  Give us $50!”)

With checks, the money is already gone.  If you report a check as fraudulent, there is no federal law saying the bank is liable — it’s up to the bank’s own policies and in some cases a hodgepodge of state laws whether they have to help you at all.  The bank may get back to you in 60 to 90 days (during which you don’t have the money, even if it was the entire contents of your checking account.)  You have to report the fraud on a paper letter, with a notarized signature, usually by certified mail.  What’s more, you have to prove that the checks were not authorized — the burden of proof is on you, not the bank or merchant — and you have to do it to each party from which you’re trying to reclaim money.  If a thief wrote bad checks in 20 different jurisdictions, you may be dealing with this for years.

Worse yet, you can’t stop the fraud from taking place.  The thief can keep writing checks on your account even after you’ve started reporting them as fraud, and even after you’ve closed the account.  Every time the thief writes a bad check on a closed account (the classic practice known as “paperhanging”, a favorite of Frank Abagnale during his criminal youth), your bank will reopen the account and send you an NSF notice.  You have to dispute all of these, too.  And finally, your account (and possibly your name) will go into ChexSystems (the equivalent of the credit bureaus used to check people’s checking account history) as fraudulent, which will make it difficult or impossible to get new checking accounts for many years.  On the bright side, it will make it harder for the thief to open accounts in your name, but that’s little consolation since he can keep using the closed one he already has.

From a security perspective, checking accounts are horrid.  They come from a day when authentication and authorization were unheard-of, and security came mainly from the idea that no one would figure out how to subvert the system.

What can you do to protect yourself?

• Don’t use checks.  If any method of payment is offered aside from checks, use that.
• Don’t use demand drafts, either — they’re checks.  Don’t pay by phone using a checking account number — use a credit/debit card.
• If you must write paper checks, use them only to pay bills, dealing with relatively trusted merchants.  It doesn’t make you totally safe, of course, but it helps some.  Use gel ink to write checks (it’s harder to wash), or a dot-matrix printer to print them (the impact-printed ink is nigh-impossible to remove.)  According to Abagnale’s The Art of the Steal, this makes check-washing nearly impossible (though ordering up new checks in your name still works.)  Incidentally, The Art of the Steal is a fantastic (and very short) book, and I highly recommend it to anyone interested in security — it gives a great view into the security mindset, looking at all parts of a system and seeing how it can be subverted.
• Don’t store any more money in your checking account than you have to.  You’ll still have to fight every fraudulent transaction to stop the bank trying to collect it from you, but at least you’ll still have your money while you’re doing it.

The sooner we move on from this antiquated and unsafe payment system, the better.

Web browsers protect the user from attacks largely through the same-origin policy: any code from one web site (such as HTML pages or JavaScript) is not permitted to interact with any code from another web site. I can make a web page that embeds a Hotmail window in the middle of it (with an IFRAME), and you’ll see your Hotmail in the window — but my page’s script is not permitted to read or write what’s in that window. Without the protection of the same-origin policy, using the Web for commerce or anything at all sensitive would be impossible — you would never know when a site you access might try to log into your bank, or your email, without you even noticing. Since your browser supplies your cookies to sites automatically, if a site could script against another, it could do so as you with all your privileges. Luckily, all browsers do enforce the same-origin policy. But what about things that aren’t browsers, but live inside them? A lot of rich content on the web, including many advertisements and all the videos on YouTube, are actually Adobe Flash applications. Others are Java applets. Though they’re embedded in your browser, they’re not the browser itself — so the browser can’t enforce the same-origin policy on them. However, we’re still safe, because Adobe and Sun have been smart enough to build the same-origin policy into the Flash and Java runtimes. They also check to make sure a web page can communicate only with the site it came from, not other sites. However, Flash and Java provide many things a regular browser cannot, and they’re frequently used in enterprise applications where cross-site communication is desirable. In addition, sometimes you actually want other sites to be able to script against you. If you’re a public web service and you want your components to work in mashups, you have to allow some cross-site access. To enable this, Flash allows web servers to place a file called crossdomain.xml on their server, which contains XML that looks something like this:

<cross-domain-policy>
<allow-access-from domain=”www.domain1.com”>
<allow-access-from domain=”www.domain2.com”>
</cross-domain-policy>

With this code present on a site, that site becomes accessible to any Flash application on domain1.com or domain2.com. Wildcards are allowed, including putting in the domain “*”, which means any site on the Internet can script against it. This is a legitimate thing to do if your site is a public API without authentication (e.g. Google Maps.)

However, it’s quite dangerous to do to a site that isn’t fully trusted. It is critical that crossdomain.xml not allow any more sites than necessary, because of the risk that relaxing the same-origin policy entails. If, say, an online bank were foolish enough to allow “*” or some easily-manipulated domain (i.e. one with a lot of user-uploaded content, like a social network or a forum), then anyone able to add content to that domain could upload a Flash applet that would connect to the bank as the user, using the user’s cookies, and perform whatever tasks it wanted — invisibly, with no sign to the user anything is going on. (Just because Flash apps usually have an appearance onscreen and are used to render graphics doesn’t mean they have to be; a Flash app is just a program.)

However, there are two serious problems with this method of relaxing the same-origin policy — and either of these can allow a malicious website to “relax” the policy of another site against its will. In each case, it involves combining another well-known attack (cross-site scripting in one case, DNS rebinding in the other) with the Flash security model to produce a vulnerability.

Cross-site scripting is the term for any vulnerability where user input is echoed back to the user (either the same user or a different user) from the site without proper sanitization. For instance, if I ask the user for his name, and he answers “<script language=”JavaScript”>alert(”Hello!”);</script>”, and from this I create a web page that says “Hello (name)” to him, he’ll get a pop-up on screen, because the “name” is actually code that, when it comes from the web server, is executed. This is a problem for the same-site rule because that code comes from the web server — instead of just popping up a dialog, it could have manipulated the web site and performed tasks on the user’s behalf! According to the same-origin policy, it’s “safe.” Now, in this scenario this sounds pretty harmless — after all, he’s attacking himself — but what if another page on the site allows any user to see a list of everyone’s name? Or what if it’s a forum and the user’s name is displayed on every post? Now that attacker’s code is running for everyone, in each case as themselves and able to take actions on their behalf.

How does this relate to Flash? Well, the crossdomain.xml file can be located anywhere on the server — the Flash applet chooses where to load it from. So if I can use a cross-site scripting attack to make a file on the web server that looks kind of like a crossdomain.xml file, I can tell my malicious Flash applet to load and apply that policy. (The filename doesn’t have to be crossdomain.xml — it can be kittens.jpg if I want. As long as it’s on that server, it can grant access to that server if the Flash applet knows where to find it.) There’s a good illustration of this attack on the Hardened PHP Project.

The other, and far scarier, attack is to use DNS Rebinding. The same-origin policy means you can only load from the site with the same domain name, like perimetergrid.com. But pages really load from IP addresses, not names. The DNS system translates names to addresses. However, the DNS system is federated — there’s no one master library of all DNS names. When you try to go to a site, your computer asks your ISP’s DNS server for its IP address, and the request is forwarded to the authoritative DNS server for that name. That DNS server then replies with the IP. If I wanted to (I don’t), I could set up my own DNS server that I control, have the root DNS point perimetergrid.com there, and then have my DNS server respond to any lookup up my site with any IP I wanted. The web browser would then load that page, and proudly display it as “perimetergrid.com,” because it trusts DNS.

Malicious DNS servers can do many horrible things. Imagine this process:

1. I load up a web forum. Someone has made a post with an embedded Flash applet.
2. The Flash applet loads from evil.com, and then it gets a crossdomain policy from evil.com (IP 6.6.6.6. Note that I don’t mean the real web site “evil.com”, but am just using the name to stand in for some malicious site.)
3. Evil.com, which is a malicious site with a malicious DNS server, responds with a crossdomain.xml that allows script from “*”. Now my Flash applet is allowed to script against evil.com.
4. The Flash applet now tries to load a web page from evil.com again. However, the malicious DNS server instead returns the IP address of your mail server, or your bank, or somesuch.
5. The Flash applet on your computer loads the page right up and can script against it. After all, it’s just evil.com, which it knows from step 3 is safe for scripting. It gets the data it wants, using your credentials, without your knowledge.
6. The Flash applet sends the data back to evil.com — which this time returned its real IP address so it could receive the communication.

This is really hard to defend against. We assume that DNS can be trusted, but DNS was not designed with security in mind and will never be secure. Evil.com could even have returned IP addresses inside your local network, behind your firewall and the browser and Flash applet would dutifully access them.

There are some techniques called “DNS pinning” that help mitigate this, by not allowing the DNS to return different IPs in rapid succession. The problem is that they break load-balancing — when you access a major online property with hundreds of servers, your request probably really is handled by many servers, all of which have the same name. Breaking this attack also breaks Google and Microsoft and Facebook.

Luckily, Adobe is aware of the issues and in Flash 9 has some mitigations proposed, including forcing socket access to get cross-domain policy by IP rather than by name. There’s a full whitepaper about it on Adobe’s site that’s a good read; Adobe is quite security conscious and has a mature security model for Flash, it’s just very hard to stop these sorts of design flaws in the web. Restricting socket access will help a lot — at least a malicious app won’t be able to port-scan behind your firewall and perform network attacks, though it could still browse web pages. This is an arms race between attackers and software companies that will continue quite a while.

Hackers love wireless networking. At DefCon 15, it was easy to predict which sessions would have lines running out the door and require getting there well in advance for a seat - it was the sessions with “wireless” or “Wi-Fi” in the title. The Wireless Village was very popular, and many of the hacking contests involved wireless access points.Why do hackers love wireless networks? Really, there are two reasons, and those two together have some scary implications for risk on the modern Internet.

1.) Wireless Networks Use Shared Media

Back in the 80’s and 90’s, most wired Ethernet networks were based on shared media topologies. In principle, when you plugged into an Ethernet network and sent a packet, the packet on the wire (the actual electrical impulses) went to every other machine on the network. Hubs were simple repeaters, broadcasting everything they received. Only when your signals reached the router at the Internet edge were they actually intelligently processed. Thus, every computer on the LAN got every packet - the network cards just threw away any packets whose destination address specified another computer. However, a hacker wanting to eavesdrop on others had an easy job - just toggle the network card into “promiscuous mode” (a hard task on some network cards and OSs, but completely trivial on others) and it will receive every packet, giving you a god’s-eye view into the network. Protocols were mostly unencrypted then, too - so you saw everyone’s email, their paswords as they logged into Telnet or IMAP, etc. You could also spoof traffic - since you saw the packets sent by others, you could simply send responses back claiming to be the recipient. So long as your response arrived before the real one, yours would be accepted and the actual response discarded as out of sequence. It was the golden age of network-protocol hacking. Such easy access to passwords made other types of hacking easy, too - once you had the password to someone’s UNIX account or email box, there was a very good chance it would work on all their other accounts, too.

Then it all changed. Shared media has significant disadvantages as it scales - since everyone is dumping packets onto what essentially amounts to a single wire, collisions occur when two systems transmit simultaneously. Both then have to back off, slow down, and retransmit their garbled packets. The packets are tiny (Ethernet frames are normally restricted to 1500 bytes or less), but if you have 100 systems communicating at once, collisions can become quite frequent. Plus, even in the late 90’s people were not totally unaware of the security risks - the fact that any student could read all the network traffic of everyone else in their dorm was not considered desirable by universities, for instance. Thus, Ethernet was converted over to switched media. Switches, unlike hubs, do not treat all ports as equal. Instead, they remember which ports they have received traffic from an address on, and only forward traffic to an address to those ports. Traffic is only broadcast to all ports when a switch has no idea for which port it is intended, or when a packet is actually marked as a broadcast. Now, when you put your Ethernet card in promiscuous mode, all you hear is traffic meant for you - everything else has been blocked by the switch. Suddenly, packet sniffers went dead - there was nothing to see anymore. Ethernet became a lot more secure.

But wireless changes things again. Wireless networks are shared media, and they are shared inherently, in a way that cannot be changed. Radio waves fly in all directions. There is no way for your laptop to transmit only to another laptop or an access point - all radio is broadcast. Thus, when you sit down in a coffee shop and turn on wireless, you begin broadcasting everything to everyone within range (about a mile, for attackers who have good antennas and high-power network cards.) The shared media nature can be mitigated somewhat via cryptography - if all the traffic to the access point is encrypted, it hardly matters if someone can eavesdrop since they can’t understand it anyway. But open access points are, by their nature, open - they’re either not encrypted at all, or they’re encrypted in such a way that everyone is using the same key. Once the hacker has the key (either by cracking it, which is not hard on most Wi-Fi networks, or by simply paying as a legitimate user of the wireless hotspot), they can read all the traffic just like in the hub-based glory days of old.

There are solid wireless encryption systems. A network based on WPA2 with a strong passcode is quite secure, about as good as a wired connection (keeping in mind that “as good as a wired connection” is not an absolute guarantee of safety, either.) Modern encryption systems like AES coupled with 802.1x certificate-based authentication can make a well-engineered corporate wireless LAN quite safe.

But hackers don’t love well-engineered corporate wireless LANs. They love the terrible ones in coffee shops and bookstores and your house. On these networks, they can listen to all traffic, they can spoof traffic, and they can even kick people off and hijack their connections, or edit their connections on the fly. The “airpwn” attack from a DefCon 2-4 years ago was particularly amusing; using two wireless cards, it would sniff everyone’s HTTP traffic on one connection, then on the other card spoof responses to all requests for images, substituting other images (such as the hacker group’s logo, or more unsavory fare like the infamous goatse.cx site; that is not a hyperlink on purpose, do not navigate to that URL as it is not safe for work or, indeed, for anywhere else.) The result was that one laptop at a security conference was able to dynamically edit the HTTP streams of everyone else there - hundreds of people. That’s the kind of power a hacker can have on a shared-media network. In addition, on these sorts of networks, it’s trivially easy to hijack sessions. This means that on any site that uses HTTPS for authentication only, but then HTTP for the actual service (a category that includes all of the Google apps like GMail, as well as all the Yahoo! and Windows Live services), a hacker gains full access to your account if they overhear any of your wireless traffic.

The only truly safe way to use a public wireless hotspot is to use it only to VPN to a network you trust. Anything else is dangerous.

2.) Wireless Networks Provide Plausible Deniability

The legal system is not terribly friendly to hackers. Even innocuous and non-destructive activity, when applied to networks you don’t own, is often illegal. Now, for the most part hackers don’t worry overmuch about getting caught - if you don’t cause more than $5,000 in damages, the FBI won’t get involved, and the average local police department is about as capable of investigating sorcery as computer crime. However, when a hacker does worry about legal prosecution, a public wireless network is the next best thing to Siberia for where to commit a crime from.

When you do anything on the Internet, a host of servers are recording your activity based on your IP address. IP address, however, is not necessarily long-lived. Depending on how you access the Internet, your IP address might change every time you plug your computer in, or reboot, or move from building to building. Thus, investigators must be able to tie the IP address they know committed a crime to a specific, physical person.

With wireless, this is a problem. All the sites being attacked don’t see the IP address of the hacker - they see the IP address of the wireless access point. Thus, they have to subpoena the owner of the access point and demand to know who was using it. In the case of a well-designed corporate wireless LAN, they can check their logs to see which 802.1x certificate was using that IP at that time, and uniquely identify you. But in the case of a public hotspot, there probably aren’t any logs at all! They’re completely incapable of giving you up. And even should someone who was there say “I saw a shifty guy in the corner using a laptop!” to the police, that’s not going to be enough evidence. And if there are logs, they will tie your traffic to your MAC address, a unique code assigned to your network card at the factory.

Most people think MAC addresses cannot be changed, so it uniquely identifies your network card. If the police get a hold of your network card, they’ve caught you. This is actually totally untrue. Many network cards will allow you to change the MAC address to whatever you want (in Windows, it’s on Connection Properties -> Configure -> Advanced -> Physical Address), though this is entirely up to the network driver. Many Windows drivers block this functionality, thinking that users don’t need it. On Linux, however, the network drivers have been written by geeks, who operate under the impression that users need everything. Thus, on Linux systems changing your MAC address is as simple as typing one command (”macchanger eth0 00:11:22:33:44:55″), and you can even configure the network stack to give you a new, random MAC address every time you connect to a network.

As a result, a trail that leads to a wireless hotspot is basically a dead end for investigators. They get nothing but a fake MAC address that could correspond to any computer within a 1-mile radius - the hacker might not have even been in the building. Hard to get “beyond a reasonable doubt” out of that.

And those are why hackers love wireless networking. It’s like the 80’s phone networks, where a hacker can be a ghost in the machine, undetectable, and with tremendous power. It’s a dangerous place.

You might wonder, if wireless networks are so anonymous, how hackers ever get caught. Actually, there are three main ways:

1. They get stupid, and brag about what they did.
2. They get stupid, and while performing their illegal activities they also do something that identifies them, like log into their email account.
3. Investigators follow the money. We don’t catch you breaking into the bank, we see where you sent the money to. We don’t catch you stealing credit card numbers, we catch you using them.

Luckily for those of us in the business of investigating and preventing computer crime, wireless networks won’t save criminals from their own stupidity, and you can’t send cash through the airwaves.

SecurityFocus reports that a patch has been issued for a vulnerability in the Macrovision SafeDisc driver.  Apparently, due to a flaw in how the driver handles configuration parameters (which probably means a garden-variety buffer overflow), it’s possible for a local user to use the driver to elevate privilege all the way to the kernel.

This sort of security flaw is a major problem with copy-protection drivers like SafeDisc; this is also the same basic issue as caused all the controversy over the “Sony Rootkit” of 2005.  Fundamentally, the purpose of any copy-protection or DRM system is to protect data from the user.  Thus, it is attempting to create a security boundary where none exists — to prevent the user, possibly a user with administrative privileges, from performing certain manipulations of data entirely under his control while allowing other manipulations (e.g. watching a film, playing a game, listening to a CD) to continue unhindered.  The problem is that it’s just data — what copy-protection and DRM vendors are doing is the equivalent to my trying to write a book, with normal ink on normal paper, that you can read but not copy, even by hand.  It can’t be done; there is no inherent difference between reading-to-read and reading-to-copy.

So instead, DRM and copy-protection vendors, like Macrovision, create a system that runs at a level of privilege above what the user can normally achieve — on a Windows machine, at least NT AUTHORITY\SYSTEM privileges, but often kernel mode drivers.   This driver then sits, Big Brother-like, above the user, watching his activities, and preventing “illicit” operations.  Meanwhile, while being immune to manipulations by the user, this supervisor must take orders from data — that is, Macrovision SafeDisc must be told by a game that it should check for copy protection and stop the game if it fails, while the Sony “rootkit” must be told by a CD that it should allow playing but stop copying.

Thus, the user’s computer is put into a rather odd state — the user doesn’t control it, a piece of supervisory code does.  And if that piece of code is flawed (as it was in both the Macrovision and Sony cases), attackers can write malware that issues instructions to that supervisory code, imitating “protected” media.

If you’re a non-Administrative user (such as almost all Vista or UNIX/Linux users, but only a few Windows XP-and-before users), you are protected from running code that does certain potentially-harmful things to your system.  You can’t write to the Windows directory, or modify installed programs, or register a driver.  However, these copy-protection drivers supply an end-run around this protection — you can supply data to the copy-protection driver (after all, you have to be able to tell it to check up on you), which means that any malware you run can also supply data to the copy-protection driver.  And since it runs with greater privilege than you, it can do all the harmful things you supposedly can’t.  Copy-protection drivers, to make content more secure for the copyright-holder, make your computer less secure for you.

From a theory perspective, the problem here is that there is no security boundary (a line which code and data cannot cross without being subjected to a security policy), on a general-purpose computer, between an administrative user and all the data on the system.  This is what the copyright-holders want, but it’s not really possible for them to get it.  All of these systems can be circumvented by simply placing a new supervisor above the one added by the copyright holder (e.g. run the system in a virtual machine, or with a kernel debugger attached, or in the most extreme scenario, just walk through the code execution by hand, choosing to ignore instructions you don’t like until you get a fully unprotected data stream.)  Thus, they fake it, in ways that make the system less secure, simply to make it more difficult for a nontechnical user to get the unencrypted stream.  The result is a simple arms race between copyright-holders and hackers, which has a side effect of harming innocent users by making them increasingly vulnerable to malware.