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.

IBM bought Watchfire and HP bought SPI: But who’s going to win the software security trifecta?

Blogger: Diana Kelley

Over two years ago, in the Market analysis section of a Burton Report on application security I wrote, “As the technology and market matures, Burton Group expects that large, established vendors who supply complementary technologies will either develop their own tools or add one of the startups to their portfolio.”  Based on my assessment of the tools and the market, I genuinely believed we’d see that happen sometime in 2006. I was wrong. But, only by a few months.

This month we saw two titans purchase web application testing tools. IBM was first out of the gate, with the acquisition of Watchfire. And HP followed suit this week with the announcement that they’d scooped up SPI Dynamics. These are powerful data points proving that “large, established vendors” are taking the security of applications seriously. Both acquisitions make sense, IBM has a strong history in software development and owns the Rational line. HP put out a clear message about application testing last year when they purchased Mercury Interactive.

From an application security perspective, this is a really exciting shift in the market – but it surprised me that both companies picked web application testing as the strongest horses. My first questions were: Why didn’t either go for a static software analysis vendor? And, what about WAF (web application firewalls)?

IBM had a strong Rational Unified Process (RUP) relationship with static source code analysis vendor Secure Software, the original owners of the Comprehensive Lightweight Application Security Process (CLASP), which has since moved to OWASP. But Secure Software was acquired by competing static source code analysis vendor Fortify in January of this year, not by IBM. And WAF’s (like those from F5, Citrix, Breach, NetContinuum, and Imperva) dynamically learn where and how an application may be failing while it’s in production. While the WAFs can be configured to protect the application against its failures, wouldn’t it be sweet if they could consume information from the penetration testing tools, like SPI and Watchifire, and not only provide stronger protection against known vulnerabilities but also communicate their knowledge back to static source code analysis tools (Fortify, Klockwork, Ounce) – the very tools that can point a developer to the exact line of code where the problems may have originated?

Security guys – we know about defense in depth – and I think it’s time to apply that to software. Both in the SDLC and in production. Specifically, the company that really gets this right is going take the software security tool trifecta; the “shadrack, meshack, and abendigo” (gotta imagine Marlon Brando saying that in his best Sky Masterson voice) of software security. This means, static source code analysis (both in the IDE and stand-alone), pen testing tools, and WAFs – integrated and working together.

IBM – you’re first out of the gate – are you willing to make the acquisitions and do the integration work required to cross the finish line? CA and HP – you’re well positioned, are either of you willing to take the big win? And Symantec and McAfee – take note. Focusing on risk is a great direction – but let’s not forget that the software running our systems, our transactions, our core business processes directly informs what we have to “secure” after the fact. Making that software stronger is imperative.

I’m not a betting man (person?), but if I were, I’d also bet that IBM is going to figure this out first.

Short disclaimer: If you’ve read previous writings of mine on software security, you’ll know I don’t think this is a tools only problem. If you haven’t: it’s not a tools only problem. Robust software means a robust SDLC and there’s a lot of people and process in there, stuff a tool can’t always catch, that must be security aware.

Welcome to the blog of Burton Group's Security and Risk Management Strategies (SRMS) team!

Blogger: Dan Blum

This blog is created with the following in mind:

Industry perspectives: Whether it’s a denial of service attack on DNS servers, a rule covering electronic evidence or a hot vendor acquisition such as Cisco snapping up Reactivity in February, SRMS wants the option to weigh in. We have a unique perspective from many years of experience, many months of in-depth research on any number of topics, and hundreds or thousands of insightful customer interactions and probing vendor briefings.

Analysts unplugged: Have you ever sat down for 15 minutes to read your inbox, but an hour later you’re still at it? This happens all the time for me, but often as not it is a rewarding, not frustrating experience. Our analysts and consultants get into incredible discussions from time to time; I’ve often thought “I wish he/she would publish this!” Now we can, as a team. This blog won’t be like our architectural Technical Positions – where we bend over backwards to achieve consensus – it’ll be more of a backstage view.

Realism about security: SRMS promotes a systematic, comprehensive approach to security. However, we understand that information protection is more than a model; it must always happen within the larger context of the business. There are so many aspects to this that it’s hard to know where to begin. Even risk management - which is where we say to start - can be treacherous, and this has led us to addressing methodologies for both quantifiable and non-quantifiable risks.

Thematic focus: In our recent VantagePoint 2007 webcast, we identified five themes that we’ll be tracking closely: proactive security, de-perimeterization, raising the bar on OS (and endpoint) security, creating information-centric security architecture and achieving sustainable compliance. As important events or thoughts on these themes emerge, we’ll be sure to address them in the blog.

Make a difference: Information security is not a game; bad things are happening to people and organizations all the time. Yes, we’re in this business to make money, but what also keeps us motivated is the opportunity to score wins for the defense. Whether it’s improving the thought process, encouraging responsible behavior or promoting better practices, standards or better ways for information protection to work, we want to be on it. In keeping with current coverage themes, we’re very interested false positives reduction, reputation based trust, data redaction, endpoint and data virtualization, security event standards and other areas where breakthroughs are needed.

Feedback loop: Comments are turned on, and we’ll use them to have a discussion with the industry. If you have further ideas on what we’ve covered, or even if you disagree with something we wrote, please chime in. Time permitting, we’ll also to participate in ongoing blogosphere discussions, even if they occur on other blogs.