MBIA Breach Highlights Need For Tightened Security Ops

Configuration change management and better monitoring could have prevented search engine indexing of sensitive financial information.

Dark Reading logo in a gray background | Dark Reading

A newly disclosed breach at the largest bond insurer in the US has highlighted the consequences of operational laxity within the enterprise. The insurer, MBIA Inc., publicly exposed sensitive financial information through a web application that allowed back-end data to be indexed by search engines, along with administrative credentials that would allow an attacker access to any other database information not already easily accessible by search. Unlike many of today's high-profile breaches, this data exposure wasn't caused through active attacks like phishing or brute forcing of passwords.

"This breach occurred through lack of awareness," says Richard Westmoreland, lead security analyst for SilverSky. "A simple mistake can create a large exposure that goes unnoticed for a long period of time."

Discovered by independent researcher Brian Seely and disclosed by Brian Krebs of KrebsOnSecurity, the data exposure was caused by a misconfigured Oracle Reports server. According to security pundits, it serves as a black eye for MBIA, which put bank account numbers, routing numbers and other sensitive customer data at risk of being used for fraud and also as a reminder to other organization why security operations checks and balances are necessary.

According to Andrew Jaquith, CTO and senior vice president of cloud strategy for SilverSky, if the story holds true then the CIO or CISO at MBI probably deserves to be fired.

"This was not a security breach. This was gross negligence, " Jaquith says.

While MBIA's incident was particularly egregious, Seely discovered that it wasn't alone.

"Recently, while researching the scope of a vulnerability, we found that numerous companies and organizations had misconfigured their Oracle reporting services," he wrote.

Configuration management stands as one of the SANS Critical 10 controls. As SANS evangelizes, solid processes that establish standardized configurations, take advantage of configuration management tools, institute file integrity checking and automatically monitor for insecure configurations can go a long way toward hardening systems.

"Even if a strong initial configuration is developed and installed, it must be continually managed to avoid security 'decay' as software is updated or patched, new security vulnerabilities are reported, and configurations are 'tweaked' to allow the installation of new software or support new operational requirements," SANS explains. "If not, attackers will find opportunities to exploit both network-accessible services and client software."

In the case of Oracle Reports, organizations are encouraged to follow Oracle best-practices for enabling security on Reports servers and defining security policies on these machines.

At the same time, organizations shouldn't depend on configuration management practices for peace of mind. Too often these practices can break down.

"We have seen numerous cases like this -- to varying degrees of severity. The issue is that somewhere down the line a database server is poorly configured, or a web application is written with slight flaws in the business logic," says Amy Blackshaw, manager for RSA Fraud and Risk Intelligence. "If we only rely on having 100 percent correct configuration and business logic, we will continue to see this type of 'attack' occur."

Both Blackshaw and Westmoreland agree that monitoring and analysis of logs could have also gone a long way toward reducing the risk posed by such a breach. As Westmoreland explains, the goal would be to limit the length of time such exposures exist, thereby reducing their risk. In the case of MBIA, the fact that much of the information found by search engines was already indexed indicates that the data was sitting out open on the web for a long time.

"With appropriate logging enabled and daily log review, the window of compromise could have been shortened. With file integrity checking and 24/7 real-time monitoring, the misconfiguration may had been identified before any data had been crawled and indexed," Westmoreland says, "Mistakes do happen -- and just as with exploitation, it is not a matter of if or when -- it is happening now, so how fast can you catch it?"

About the Author

Ericka Chickowski, Contributing Writer

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights