Security and Risk Management Strategies Blog

The Fox and the Henhouse

Blogger: Bob Blakley

Yesterday Societe Generale, the second-biggest bank in France, announced that it had suffered almost 5 billion Euros in losses due to the activities of one of the bank's derivatives traders.

Societe Generale apologized for the losses, and explained a three-day delay in announcing the fraud publicly by saying that bank officials needed time to unwind as many of the fraudulent positions as possible in order to limit the bank¹s losses.

Although Societe Generale did not identify the trader responsible for the fraud in their initial communications, he has subsequently been identified as one Jerome Kerviel.

Societe Generale's press release regarding the incident can be found here:
http://www.telegraph.co.uk/money/graphics/2008/01/24/socgen.pdf.

The details of the fraud are not yet completely clear, and uninformed speculation is not likely to be helpful.  But the first paragraph of the bank¹s press release deserves comment.

Societe Generale begins by saying this: "Societe Generale Group (the "Group") has uncovered a fraud, exceptional in its size and nature: one trader, responsible for plain vanilla futures hedging on European equity market indices, had taken massive fraudulent directional positions in 2007 and 2008 beyond his limited authority."

Three things about this sentence are worrying.  First, the fraud is described as "exceptional in size and nature".   The good ones always are exceptional in size and nature.  Common frauds aren¹t usually hard to prevent after you¹ve seen a lot of them; the reason you pay a risk manager is to prevent the exceptional frauds.

Second, the bank describes Kerviel¹s job as "plain vanilla futures hedging." The worry here is that the bank¹s risk managers think futures hedging risks not worth worrying about because they¹re just "plain vanilla."

The third worrying thing is the last clause: "one trader... had taken massive fraudulent directional positions... beyond his limited authority." Clearly his authority was NOT limited; the risk management and governance mechanisms of the bank apparently failed to prevent Kerviel from exceeding his authority, and they also apparently failed to detect his actions in time to limit the damage.

Societe Generale goes on to say this in the last half of the first paragraph: "Aided by his in-depth knowledge of the control procedures, resulting from his former employment in the middle-office, he managed to conceal these positions through a scheme of elaborate fictitious transactions."

The governance and risk management lessons are the two usual ones:

1. The fox is a dangerous guard for the henhouse.  It may be safe to move traders into the design of risk-management systems; it is probably not a great idea to move the risk management personnel onto the trading desk.

2. The most dangerous assumption in the security business is the assumption that there are good guys. The risk management system MUST be designed to be secure even against attacks by insiders who have developed and operated it.

The only way to design a system to be secure against these insider attacks is to have strong attestation, transaction tracking, dual control, and supervision features - in other words, to ensure that activities are carried out in public and reviewed in a timely way.

Societe Generale appears to acknowledge these lessons later in the press release, when the bank notes that "The individuals in charge of his [Kerviel's - ed.] supervision will leave the Group."  Firing Kerviel's bosses will not fix the problem; only improving the bank¹s governance will prevent future frauds.

Five Immutable Laws of Virtualization Security

Blogger: Pete Lindstrom

There are many opinions about the impact of virtualization on an enterprise security posture. A recent article in InformationWeek (http://www.informationweek.com/shared/printableArticle.jhtml?articleID=204301246) gives a good example of the variance in opinions. In reality, we can apply traditional security practices to virtualization to determine whether risk increases or decreases with new virtualization architectures. It shouldn’t be surprising that the increase or decrease in risk is predicated on the current architecture. Here are five laws to live by when evaluating your virtualization architectures.

[This content is excerpted from the Burton Group Overview, “Attacking and Defending Virtual Environments.”]

When combining the standard risk principles with an understanding of the use cases of virtualization, a set of immutable laws can be derived to assist in securing virtual environments:

Law 1: Attacks against the OS and applications of a physical system have the exact same damage potential against a duplicate virtual system.

The point here is that, for all intents and purposes, a VM acts like a physical system, and in most environments that means it can be attacked in exactly the same way. The suggestion that because VMs run in user mode and are therefore more secure is insignificant if an attack remains within the VM and has access to the VM’s content and programs as if it is in kernel mode. So, when comparing a physical system with an OS and applications to an identically configured VM, all existing attacks will work the same way. Importantly, many attacks occur in the application stack, often against sensitive information itself. Any data on the VM may be stolen, and if the VM has network access it may be used as a stepping stone to attack other systems just as a physical system might be so used. The only attack that may be original and different is one that breaks the virtualization mechanisms and compromises additional VMs.

It is important to note that although VM and non-VM attacks are largely the same, the ability to recover from an attack may be significantly increased with VMs, and so the response and recovery may be different.

Law 2: A VM has higher risk than its counterpart physical system that is running the exact same OS and applications and is configured identically.

This corollary to the first rule above introduces the effect of the additional attack surface from the hypervisor and VMM. Because the VMM monitors and responds to a VM, it becomes susceptible to attack itself. The same is true for hypervisors. Any addition of software on a platform necessarily increases its risk if all other things are equal (i.e., there are no attack surface reductions performed in conjunction with the migration). Of course, all other things aren’t equal, so it is important to recognize the basically negative impact of the virtual environment on risk and to pay more attention to offsetting that risk in other ways.

Law 3: VMs can be more secure than related physical systems providing the same functional service to an organization when they separate functionality and content that are combined on a physical system.

When two processes share the same memory space, an attack against one process can impact the other. That is, system ownership by an attacker trumps any other security. One of the ways to benefit from virtualization is to separate various functions into their own isolated operating environments. An even better way is to separate data as well. Either type of separation provides an opportunity to reduce the risk added by the virtualization software.

Law 4: A set of VMs aggregated on the same physical system can only be made more secure than its physical, separate counterparts by modifying the configurations of the VMs to offset the increased risk introduced by the hypervisor.

While separating resources reduces risk, aggregating resources will initially increase risk (Rule 2) and so must be reconfigured or hardened to attain the same level of risk or a reduced level (Rule 3). Turning off services, adding controls, and separating content can reduce that risk.

The most obvious examples here are the replacement of a physical demilitarized zone (DMZ) with one built in a virtual environment and the aggregation of multiple physical desktops (e.g., like the military aggregating classified and unclassified desktops) into VMs on the same physical machine. Once again these VMs must be hardened to a level more secure than their physical counterparts in order to meet a similar risk level.

Burton Group’s current view is that subzones of a DMZ (or any other zone of trust) may be consolidated on a physical system yet separated by virtualization technology provided the risk of a breach is considered low. However, Burton Group recommends that virtualization not be used in a massive or systematic way to mingle production resources across zones of trust (e.g., between the DMZ and the trusted zone). Virtualization used in such a way could easily aggregate risks to medium or high, well exceeding the surety level of software VM isolation, which must be assumed at this time to be low.

Law 5: A system containing a “trusted” VM on an “untrusted” host has a higher risk level than a system containing a “trusted” host with an “untrusted” VM.

Broadly, “trusted” systems are managed and have protection controls deployed, while “untrusted” components may or may not be managed but are generally considered to have weaker protection and are therefore more susceptible to attack.

In American football, the general concept of “getting low” while blocking is an advantage to the blocker. In attacking systems, the same is true. Attacks at lower levels have higher risk than those at higher levels. This is primarily due to the ability to spoof or trick higher-level programs into believing assertions about trust and authenticity.

This rule is particularly important with Type 2 virtualization (OS-hosted virtual machine) because the host OS has a ready attack surface. Because client-side architectures involve both of these scenarios, it is important to recognize and understand the differences. Given this rule, it is important for deployments of trusted VMs in untrusted environments to consider the implications and harden the VM image accordingly.

[Addendum: During additional discussion within Burton Group, the question was raised, "Is this a vote against using virtualization?" On the contrary, we feel that virtualization has great benefit. It's just that some vendors and observers in the industry incorrectly and blithely say that virtualized environments improve security. There are many cases this isn't true--as discussed above--and it's important that practitioners think carefully about proper levels of protection as they move forward with such projects. Virtualization has security issues, but don't throw the baby out with the bathwater.]

Security in SaaS: When Applause Turns to Head-Scratching

Blogger: Trent Henry

We just completed research and writing on a piece entitled, "Considerations for Risk Management When Choosing Software as a Service." It should be publishing in the near future. Our Service Director Eric Maiwald wrote this report in the midst of Salesforce.com's reported breach and subsequent security enhancements, so it was timely. In fact, as users of Salesforce.com, we were pleased to see the company offer improved protection against certain forms of identity fraud--especially phishing.

But soon after the security enhancement was implemented, we realized it wasn't quite working right for us.

See, Burton Group Analysts are a distributed, traveling bunch. We tend not to cling to the same IP address for very long. Unfortunately, part of the Salesforce.com fix was to authenticate users based on inbound IP address.
(Back in the day we might have balked at this due to its low surety--but with so few routers/firewalls honoring source-routing flags and weird ICMP redirects, it tends to be reasonably effective.) Of course, Salesforce.com realized that lots of its users are mobile, so they also implemented a browser cookie that anchors to a given host in the event of changing IP address. More details are at https://trust.Salesforce.com/security.html.

However, the cookie part of the solution didn't seem to be working for many of us. This meant that we had to repeat the system enrollment process each time we DHCPed (is that a verb?) with a new IP block. The end result? -- some significant inconvenience and delay in using our presumably available-everywhere SaaS application.

What a conundrum. I abhor phishing. And I don't mean to pick on Salesforce.com. On the contrary, enhancing security is a noble and applauded decision. But as a security practitioner, I know first hand that if information protection gets in the way of an application's usefulness, it causes all manner of consternation and often a total retreat from better protection. The good news is that this hasn't happened to Salesforce.com; glitches are getting worked out and improved security remains. The bad news is that it is likely to happen to other SaaS vendors.

In essence, attackers create an environment for potentially poor decisions that can directly impact the original benefit of a system. Although insiders continue to cause harm in organizations, Internet-facing systems are particularly open to a wide array of damaging bad guys. Mobility adds to the complexity of protection. The possibility for hastily implemented SaaS security, especially after the latest successful attack, is quite high. And haste will cause applications to fail. At best, the result is temporarily inconvenienced users. At worst, it's (also hasty) dismantling of protection and reluctance to try for better.

Where does that leave us? SaaS is in our future; make no mistake. And attacks will continue to evolve and succeed. The goal in this ever-connected mobile world is to raise the bar for protection with thought and care. Like independent software vendors and in-house developers, SaaS solutions must consider security requirements and threats, design protection as best they can (nothing is perfect), use multiple mechanisms where appropriate (defense-in-depth), and include strong response capabilities (well-trained, adequately staffed support teams). When problems are found, a vendor should think through how the application is used when deploying fixes or additional mechanisms. An overly quick, troublesome response will likely fail, lead to head-scratching, and--perhaps worst of all--ultimately be circumvented by the very users that need better protection.