After Interop Las Vegas you may have seen our analysis of the data that we collected and delivered in our NOC view.  I thought I’d recreate the same data for NY and do a short comparison.

1) Like in Vegas, uptime for the network 100%.  This is no small feat considering that we introduced a new wrinkle in NY, taking down the primary NOC while the education portion of the show was still going on.  This was a forced failover to the backup systems, and it went flawlessly.  I’d like to give a little credit to EM7 on the 100% uptime as it caught a failover to battery power that allowed AC to be restored before a series of critical equipment would have gone down.

2) Again like Vegas, the average monitored device in the show network didn’t even hit 10% CPU utilization.  Still lots of computing overhead availabe in the show network.

3) The NY show network wasn’t nearly as busy as in Las Vegas, sustaining an average of only 27Mbps of usage (versus 56 Mbps) in Vegas.

4) Power consumption for the network and NOC in NY clocked in at 445kwh per day, about 25% less than the Las Vegas show.  This wasn’t because the equipment was any more power efficient, but instead because the show was smaller and therefore there was less network gear.

5) Finally, a stat we didn’t track too carefully in Las Vegas, but that I find interesting.  During show hours the wireless network average 1,100 users attached.  That’s a lot of people and a lot of wireless devices.

The good news is there was nothing too unexpected in the data, overall the smaller show led to a smaller number of tickets and smaller consumption of resources across the board.  We hope to have the opportunity to work with the InteropNet team again next year and take a look at this data year-over-year for each show.

Warnings About Financial Institutions and Derivatives

Risks of Financial Institutions
The nature of a financial institution is that there are a lot of ways to go to hell in a bucket. You can push credit too far, do a dumb acquisition, leverage yourself excessively---its not just derivatives [that can bring about your downfall].

Maybe it's unique to us, but we're quite sensitive to financial risks. Financial institutions make us nervous when they're trying to do well.

We're exceptionally goosey of leveraged financial institutions. If they start talking about how good their risk management is, it makes us nervous.

We fret way earlier than other people. We've left a lot of money on the table through early fretting. It's the way we are -- you'll just have to live with it.

Derivatives
The system is almost insanely irresponsible. and what people think are fixes aren't realy fixes. It's so complicated I can't do it justice here - but you can't believe the trillions of dollars involved. You can't believe the complexity. You can't believe how difficult it is to do the accounting. You can't believe how big the incentives are to have wishful thinking about values and wishful thinking about ability to clear.

People don't think about the consequences of the consequences. People start by trying to hedge against interest rate changes, which is very difficult and complicated. Then, the hedges make the [reported profits] lumpy. So they use the new derivatives to smooth this. Well, now you've morphed into lying. This turns into a Mad Hatter's Tea Party. This happens to vast, sophisticated corporations.

Somebody has to step in and say, "We're not going to do it - it's just too hard."

I think a good litmus test of the mental and moral quality at any large institutions [with significant derivative exposure] would be to ask them, "Do you really understand your derivatives book?" Anyone who says yes is either crazy or lying.

It's easy to see [the dangers] when you talk about [what happened with] the energy derivatives - they went kerflooey. When [the companies] reached for the assets that were on their books, the money wasn't there. When it comes to financial assets, we haven't had any such denouement and the accountings hasn't changed so the denouement is ahead of us.

Derivatives are full of clauses that say if one party's credit gets downgraded then it has to put up collateral. It's like margin - you can go broke [just putting up more margin]. In an attempt to protect themselves, they've introduced instability. Nobody seems to recognize what a disaster of a system they've created. It's a demented system. 

In engineering people have a big margin of safety. But in the financial world, people don't give a damn about safety. They let it balloon and balloon and balloon. It's aided by false accounting. I'm more pessimistic about this than Warren is.

Accounting for Derivatives
I hate with a passion GAAP [Generally Accepted Accounting Principles] as applied to derivatives and swaps. JP Morgan sold out to this type of accounting to front-end revenues. I think it's a disgrace.

It's bonkers, and the accountants sold out. Everyone caved, adopted loose [accounting] standards, and created exotic derivatives linked to theoretical models. As a result, all kinds of earnings, blessed by accountants, are not really being earned. When you reach for the money, it melts away. It was never there.

It [accounting for derivatives] is just disgusting. It is a sewer, and if I'm right, there will be hell to pay in due course. All of you will have to prepare to deal with a blowup of derivative books.

Likelihood of a Derivatives Blowup
We tried to sell Gen Re's derivatives operations and couldn't, so we started liquidating it. We had to take big markdowns. I would confidently predict that most of the derivatives books of [this country's] major banks cannot be liquidated for anything like what they're carried on the books at. When the denouement will happen and how severe it will be, I don't know. But I fear the consequences could be fearsome. I think there are major problems, worse than in the energy field, and look at the destruction there.

I'll be amazed if we don't have some kind of significant [derivatives-related] blowup in the next five to ten years.

I think we're he only big corporation in America to be running off its derivative book.

It's a crazy idea for people who are already rich -  like Berkshire - to be in this business. It's a crazy business for big banks to be in.

Yo would be disgusted if you had a fair mind and spent a month really delving into a big derivative operation. You would think it was Lewis Carroll. You would think it was the Mad Hatter's Tea Party. And the false precision of these people is just unbelievable. They make the worst economics professors look like gods. Moreover, there is depravity augmenting the folly. Read the book F.I.A.S.C.O., by law professor and former derivative trader Frank Partnoy, an insider account of the depravity of derivative trading at one of the biggest and best-regarded Wall Street firms. This book will turn your stomach.

The best security program is at the business with the happiest customers.

There's a fine line between happy customers and playing piano in a bordello.

Sees a lot
Can tell the king he has no clothes
Can tell the king he really is ugly
Does not get killed by the king
Nice to have around but…how much security improvement comes from this ?

Changes happened faster that he was able to move
Did not read the signs
Good intentions went unfulfilled
A brutal way to ending a promising career
Sad to have around but…how much security improvement comes from this ?

Obviously these models of CISOs are not solving our information security problems. Instead Dr. Garigue points us to Charlemagne as a better model

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

This is the way forward! Find software security champions in the architecture and development groups,help them understand the real security issues. They will find solutions you have not thought of. Same for DBAs, same for business analysts even. Its all about beating the bushes, education, and decentralizing security services. Specifically, he points out this important mandate for IT security

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?
How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

To me this is our mandate and measure of effectiveness. Empower our customers, educate, and create business value. If I am a CISO  I don't want 20 people reporting to me who do firewall ruleset changes. I want one champion in 20 different groups - development teams, architects, DBAs, business analysts.

A concrete example, infosec can continue to go along with the herd and follow the "what everyone else is doing architecture" meanwhile developers are connecting every single thing in your business to the Web. I have been doing integration and new technology projects for a long time, and let me tell you - Change does not always create happy customers in the short run. But the chart below shows that information security is maybe more concerned with not causing waves rather than adapting.

The best security program is at the business with sustainable competitive advantage.

Setting the context for this post, it is a tough economic situation all over the world. IT spending has reduced and will reduce significantly. In one of earlier posts, I had referred to information security as an overhead of an overhead (IT). What is a good approach for security practice in this type of economy?

I don't have a magic wand to pull a rabbit out of a hat. I have always been told that: tough economy is the time for real smart people to make money. Coming back to information security topic, with a bit of common sense, it is wise for information security professionals to offer services in those areas that does not involve capital expenditure. As a Security Manager, you may be already aware that your people are willing to go an extra mile in the current economic times.

- No budget or lack of budget, means no new capital expenditure. Spend time wisely in building a future technology strategy and keep it in the back pocket when the economy turns around.

- This is a good time to create roles/responsibilities and ownership for various areas. Create operating procedures. Make your team to automate tasks. This will help your operations become more efficient.

- This is time for security awareness  education. Create pamphlets/brochures/presentations for an online or classroom training. Engage your and your team's time to impart training.

- Leverage already invested technology platforms. Leverage utilized features that reduce costs. If you have already invested in technology such as VMware, this is the time to get the best out of it. You can use VMware's toolkit to build your lab and staging environment and optimize on hardware cost.

- Off shoring has been the mantra of senior executives, this is the time to revisit those services and measure their performance closely and assess your satisfaction level. This is a good time to build a case for not off shoring if it makes sense.

- Companies are more vulnerable in bad economic times. You are in a better position to influence senior management about information security risks under these circumstances and drive home the value of protecting your intellectual property under these kinds of circumstances. management will be all ears for such a pitch.

- Time to engage your architect to optimize your security architecture, revisit standards and optimize design for cost efficiency.

- Revisit various controls and see if there are some risks that you could optimize spending on.

- Training budget is an unfortunate victim of this type of economy. Encourage employees to take free webinars offered by various security vendors and encourage them to share the summary across the team. This will put your employees in touch with latest happenings in security at the same time there is some learning that is imparted despite zero training budget.

- Since there are very few projects in action, this is a good time to have conversations with cross functional teams and educate them about your services and solicit feedback on how to do better.

- Revisit your vendor logistics and identify whether you can renegotiate some of your already existing contracts.

The above are some good ways by which you can optimize costs, this will also enhance your team's competence level in the long run. And this approach is better than letting people go, if you can pull this.

No doubt you are aware of the out-of-band security bulletin issued by the Microsoft Security Response Center today, and like all security vulnerabilities, this is a vulnerability we can learn from and, if necessary, can use to shape future versions of the Security Development Lifecycle (SDL).

Before I get into some of the details, it's important to understand that the SDL is designed as a multi-pronged security process to help systemically reduce security vulnerabilities. In theory, if one facet of the SDL process fails to prevent or catch a bug, then some other facet should prevent or catch the bug. The SDL also mandates the use of security defenses, because we know full well that the SDL process will never catch all security bugs. As we have said many times, the goal of the SDL is to "Reduce vulnerabilities, and reduce the severity of what's missed."

In this post, I want to focus on the SDL-required code analysis, code review, fuzzing and compiler and operating system defenses and how they fared.

Code Analysis and Review

I want to start by analyzing the code to understand why we did not find this bug through manual code review nor through the use of our static analysis tools. First, the code in question is reasonably complex code to canonicalize path names; for example, strip out ‘..' characters and such to arrive at the simplest possible directory name. The bug is a stack-based buffer overflow inside a loop; finding buffer overruns in loops, especially complex loops, is difficult to detect with a high degree of probability without producing many false positives. At a later date I will publish more of the source code for the function.

The loop inside the function walks along an incoming string to determine if a character in the path might be a dot, dot-dot, slash or backslash and if it is then applies canonicalization algorithms.

The irony of the bug is it occurs while calling a bounded function call:

_tcscpy_s(previousLastSlash, pBufferEnd - previousLastSlash, ptr + 2);

This function is a macro that expands to wcscpy_s(dest, len, source); technically, the bug is not in the call to wcscpy_s, but it's in the way the arguments are calculated. As I alluded to, all three arguments are highly dynamic and constantly updated within the while() loop. There is a great deal of pointer arithmetic in this loop. Without going into all the gory attack details, given a specific path, and after the while() loop has been passed through a few times, the pointer, previousLastSlash, gets clobbered.

In my opinion, hand reviewing this code and successfully finding this bug would require a great deal of skill and luck. So what about tools?  It's very difficult to design an algorithm which can analyze C or C++ code for these sorts of errors.  The possible variable states grows very, very quickly.  It's even more difficult to take such algorithms and scale them to non-trivial code bases. This is made more complex as the function accepts a highly variable argument, it's not like the argument is the value 1, 2 or 3! Our present toolset does not catch this bug.

Ok, now I'm really going out on a limb with this next section.

Over the last year or so I've noticed that the security vulnerabilities across Microsoft, but most noticeably in Windows have become bugs of a class I call "onesey - twosies" in other words, one-off bugs. There is a good side and a bad side to this. First the good news; I think perhaps we have removed a good number of the low-hanging security vulnerabilities from many of our products, especially the newer code. The bad news is, we'll continue to have vulnerabilities because you cannot train a developer to hunt for unique bugs, and creating tools to find such bugs is also hard to do without incurring an incredible volume of false positives. With all that said, I will add detail about one-off bugs to our internal education; I think it's important to make people aware that even with great tools and great security-savvy engineers, there are still bugs that are very hard to find.

Fuzz Testing

I'll be blunt; our fuzz tests did not catch this and they should have. So we are going back to our fuzzing algorithms and libraries to update them accordingly. For what it's worth, we constantly update our fuzz testing heuristics and rules, so this bug is not unique.

Defenses

If you want the full details of the defenses, and how they come into play on Windows Vista and Windows Server 2008, I urge you to read teh SVRD team's in-depth analysis once it is posted.

A big focus of the SDL is to define and require defenses because we have no allusions about finding or preventing all security vulnerabilities by attempting to get the code right all the time, because no-one can do that. No one.  See my comment above about one-off bugs!

Let's look at each SDL mandated requirement and how they fared in light of this vulnerability.

-GS

The -GS story is not so simple. A lot of code is executed before a cookie check is made and the attacker can control the overflow because the overflow starts at an offset before the stack buffer, rather than at the stack buffer itself. So the attacker can overwrite other frames on the call stack, corresponding to functions that return before a cookie check is made. That's a long way of saying that -GS was not meant to prevent this type of scenarios.

ASLR and NX

The code fully complies with the SDL, and is linked with /DYNAMICBASE and /NXCOMPAT on Windows Vista and Windows Server 2008. There are great defenses when used together, and reduce the chance of a successful attack substantially. Also, the stack offset is randomized too, making a deterministic attack even more unlikely.

Service Restart Policy

By default the affected service is marked to restart only twice after a crash on Windows Vista and Windows Server 2008, which means the attacker has only two attempts to get the attack right. Prior to Windows Vista, the attacker has unlimited attempts because the service restarts indefinitely.

Authentication

Thanks to mandatory integrity control (MIC) settings (which comes courtesy of UAC) the networking endpoint that leads to the vulnerable code requires authentication on Windows Vista and Windows Server 2008 by default. Prior to Windows Vista, the end point is always anonymous, so anyone can attack it, so long as the attacker can traverse the firewall. This is a great example of SDL's focus on attack surface reduction; requiring authentication means the number of attackers that can access the entry point is dramatically reduced.

Firewall

We enabled the firewall by default in Windows XP SP2 and later, this was a direct learning from the Blaster worm. By default, ports 139 and 445 are not opened to the Internet on Windows XP SP2, Windows Vista and Windows Server 2008.

Summary

The $64,000 question we ask ourselves when we issue any bulletin is "did SDL fail?" and the answer in this case is categorically "No!" No because as I said earlier the goal of the SDL is "Reduce vulnerabilities, and reduce the severity of what you miss." Windows Vista and Windows Server 2008 customers are protected by the defenses in the operating system that have been crafted in part by the SDL. The development team who built the affected component compiled and linked with the appropriate settings as described in "Windows Vista ISV Security" and Writing Secure Code for Windows Vista so that their service is protected by the operating system.

The team did not poke holes through the firewall unnecessarily, in accordance with the SDL.

The team reduced their attack surface, in accordance with the SDL, by requiring authenticated connections rather than anonymous connections by default.

We know that the SDL-mandated -GS has very strict heuristics so some functions are not protected by a stack cookie, but in this case, there is no buffer on the stack, so there will be no cookie. We know this. There are no plans to remedy this in the short term.

Fuzzing missed the bug, so we will update our fuzz testing heuristics, but we continually update our fuzzing heuristics anyway.

In short, based on what we know right now, Windows Vista and Windows Server 2008 customers are protected because of the SDL-mandated defenses in the operating system, and because the development team adhered to the letter of the SDL to take advantage of those defenses.

Chalk one up for Windows Vista and later and the SDL!

As usual, questions and comments are very welcome.

Setting the Web Application Security Agenda for 2009: OWASP Invites You to Join Our Summit in Portugal

http://www.owasp.org/index.php/OWASP_EU_Summit_2008

With the theme ‘Setting the AppSec agenda for 2009′, the OWASP Summit will be a worldwide gathering of OWASP leaders and key industry players to present and discuss the latest OWASP tools, documentation projects, and web application security trends. Join us in Portugal in just a few short weeks! This venue hosts a diverse selection of training courses along with technical and business tracks, making it THE place to learn about web application security and the resources OWASP has available for use today.

OWASP is a not-for-profit organization with the purpose of supporting the Web Application Security community around the world, and has granted $250,000 USD for web application security research. In addition to over 40 presentations from the OWASP Leaders and grant recipients, the OWASP Summit will host multiple Working Sessions designed to improve collaboration, achieve specific objectives and identify roadmaps for OWASP projects, chapters, and the OWASP community itself.

To facilitate this event, OWASP is investing $150,000 USD which will be used to cover air travel and accommodation expenses for OWASP leaders, active contributors, and select key industry leaders. With their confirmed presence, the OWASP Summit will provide a relaxed but professional environment to meet, discuss, influence and contribute to OWASP projects.

There are still funds available! If you are interested in attending and you meet the profile of the current OWASP supported attendees (see list here: http://spreadsheets.google.com/pub?key=pAX6n7m2zaTVLrPtR07riBA) contact Paulo Coimbra (paulo.coimbra@owasp.org). Please note that you should do so only if you meet the paid attendance criteria (see herehttps://www.owasp.org/index.php/OWASP_EU_Summit_2008_paid_participation_rules) and are unable to get corporate support to attend this event (for other corporate sponsorship opportunities see http://www.owasp.org/index.php/OWASP_EU_Summit_2008_Sponsors).

The OWASP Summit will also host a large and diverse selection of training courses, covering multiple OWASP specific and Web Application Security Topics.

The remarkable impact of OWASP is made possible only by the collaboration of many dedicated people and organizations worldwide. In that spirit of cooperation, OWASP invites all its members (who have 20% discount + 1 VIP Ticket) and interested individuals and companies to attend this thrilling event. Please join us and help to set the Web Application Security Agenda for 2009!

Please see below for additional details about the OWASP Summit or visit the OWASP Summit website: http://www.owasp.org/index.php/OWASP_EU_Summit_2008.

Projects

OWASP projects selected for Summit presentation include new documentation and innovative tools to help developers, architects, and security specialists ensure that applications are secure:

• Application Security Verification Standard,
• Code review guide, V1.1,
• Ruby on Rails Security Guide v2,
• Securing WebGoat using ModSecurity,
• Testing Guide v3,
• GTK+ GUI for w3af project,
• Access Control Rules Tester,
• AntiSamy .NET,
• Live CD & DVD Project,
• OpenPGP Extensions for HTTP,
• Orizon Project,
• Python Static Analysis,
• WebScarab-NG,
• And many, many others.

Working Sessions

Expecting the presence of the application security industry key players, the Working Sessions will cover a wide range of issues such as:

• OWASP Top 10 2009,
• Browser Security,
• Web Application Framework Security,
• Enterprise Security API Project,
• Best Practices for OWASP Chapter Leaders,
• OWASP Documentation Projects,
• OWASP Tools Projects,
• OWASP Education Project,
• OWASP Strategic Planning for 2009,
• OWASP Certification,
• OWASP Winter of Code 2009
• Two-way Internationalization of OWASP Content
• And many more.

Training

These 2-day, 1-day or 1/2-day training courses cover a wide range of OWASP specific and Web Application Security Topics:

• OWASP Top 10 - What Developers Should Know on Web Application Security
• Uncovering WebScarab’s Secret Treasures
• Securing WebGoat with ModSecurity
• Secure Programming with Java
• Advanced Web Application Security Testing
• Building Secure Web 2.0 Applications
• Building Secure Web Services
• Building Secure Web Applications with OWASP’s Enterprise Security API (ESAPI)
• Classic ASP Security using OWASP tools
• Web Application Assessments
• Hacking Owasp Orizon Project v1.0
• Ajax Security
• Practical Penetration Testing: Think Like an Attacker to Stop Attacks
• Linux Software Exploitation
• Web server/services hardening using SELinux

Main Contact:

Kate Hartmann
OWASP Operations Director
9175 Guilford Road, Suite 300
Columbia, MD 21046, USA
Phone: +1-301-575-0189
Facsimile: +1-301-604-8033
Email: kate.hartmann@owasp.org