Risque Management : FUD

How not to make decisions

Slav — Mon, 13 Apr 2009 01:39:00 GMT

In the past week, I had a number of discussions about information securtity and technology in general. With colleagues, we identified few common patterns about decision-making in corporate environments - and those are case studies on how decisions shouldn't be made. Here's examples:

We need mature solutions. Can anybody define maturity when it comes to IT? Is Intranetware mature solution for network file and print services? Whenever you hear maturity or business acumen, or something like that, reach out for your wallet. Fact: early adoption of technology works better in most cases. That's because you have better support from the technology partner, more features, more time before upgrade, and staff that feels good because they are working on something new.

Everyone else does it, so it must be good. This is the "best practice" fallacy. Cases in point: do not broadcast WLAN SSID; VLANs are for security; and multihoming servers (and having separate physical connections to different security zones) is a security feature. The myths don't withstand reality check (eg scenario-based threat analysis) but they persist in minds and get embedded in assorted standards like PCI - resulting in costlier infrastructures that are more complex to build and support.

We don't really know what we're doing but let's do it anyway. Tha is, decisions large and small are made based on uncertainty and lack of knowledge. Cases in point: we don't know what this software update is doing so let's have full system restore as the backout plan; I heard that virtual machine will have some kind of issue running our application so please use physical (the last one comes from Microsoft engineer, no details as to the issue given despite repeated questions); and we don't know how the database server will perform when the database size will reach 4TB so let's go Oracle RAC. If you don't know what the software update is doing - find out by looking in the installation package. If you have concerns abouth the database performance - create performance baseline and try to come up with automated stress test of some sort; the database size itself doesn't mean much.

Decisions should be made based on knowledge and facts.

US Senate: security through (more) bureaucracy

Slav — Sat, 04 Apr 2009 23:15:00 GMT

When I first read the news on the Washington Post web site, I thought this is a 1 April joke: Senate Legislation Would Federalize Cybersecurity. The April Fool's day has come and gone but all the signs are to that this is for real: the press releases trumpeting arrival of the legislation are still there. The bill's summary is available from the US Senate Web site (I cannot find the full text of proposed legislation yet). The problem definition is a typical scaremongering:

This comprehensive legislation addresses our country’s unacceptable vulnerability to massive cyber crime, global cyber espionage, and cyber attacks that could cripple our critical infrastructure. We presently have systems to protect our nation’s secrets and our government networks against cyber espionage, and it is imperative that those cyber defenses keep up with our enemies’ cyber capabilities. However, another great vulnerability our country faces is the threat to our private sector critical infrastructure–banking, utilities, air/rail/auto traffic control, telecommunications–from disruptive cyber attacks that could literally shut down our way of life.

So get ready for digital Pearl Harbor. Real one: Conficker virus, another April Fools' event, which some described as just that, caused zero noticeable impact.

Coming from professional politicians, the bill unsurprisingly proposes to improve the cybersecurity situation by introducing colossal new bureaucracy, headed by the US Cybersecurity Fuehrer (or Tzar, or Leader, if you so wish). If it becomes a law then the governemnt will have control over information security matters in private sector:

The legislation would require the National Institute of Standards and Technology to establish measureable and auditable cybersecurity standards that would be applicable both to government and the private sector.

Although the press release and the summary mention specifically critical infrastructure controlled by private entities - utilities, banking, transportation, health and telecommunications - apparently the bill's scope is not limited thereto. That would dwarf Sarbanes-Oxley and HIPAA information security rackets and create massive compliance burden on the economy. Layers upon layers of firewalls, "endpoint security" and "intrusion prevention" technologies, and regular compliance audits may become mandated by the law.

The bill would also attempt to place a dollar value on cybersecurity risk. Ironically placed uder the Foster innovation section, it means this:

The legislation would require the Advisor to provide a report on the feasibility of creating a market for cybersecurity risk management, to include civil liability and government insurance.

Welcome to the cybersecurity cap-and-trade scheme!

This is not the first attempt to create cybersecurity bodies in the government. Think of the DHS and its Cybersecurity Center, the people who brought us this:

Yet according to the senators all the efforts have basically failed. Maybe that signifies a problem with the approach? It does. Government-mandated dogma is not a substitute for a pragmatic approach to security threats.

How to prevent 1% of cybercrime?

Slav — Fri, 04 May 2007 22:50:00 GMT

An interesting picture appears on the PBS Shop Web site:

Because of what it says I felt an urge to click on it. The first attempt (a right-click) resulted in the following message box:

I think the law that prohibits copying the picture doesn't exist. Otherwise my Web browser would be breaking the law by caching the picture, for example. And the trademark law, at least in Australia, USA and other Western countries, actually allows nominative fair use (as well as parody).

But I don't need to do any copying anyway. The "HACKER SAFE" picture above is provided to you directly from its source, controlscan.com (and "certifies" sites other than this weblog). Clicking on it will show a page that says, among other things:

Research indicates sites remotely scanned for known vulnerabilities on a daily basis, such as those earning HACKER SAFE certification, can prevent over 99% of hacker crime.

I would be really interested in the methodology of that research. Why 99% and not 99.9%? But mentioning research is just weasel words here.

The company that brings you the "HACKER SAFE" picture provides many services related to Web security and privacy protection. Every single one comes with its own picture (they are called "trust seals"):

That, as I wrote, gives a false sense of security. Looking at the service offerings reveals more interesting facts:

The company provides vulnerability scanning for those who need to be compliant with flawed and largely useless Payment Cards Industry Data Security Standard;
The company offers vulnerability scanning bundled together with EV SSL certificates - overpriced ones, supposedly more secure and with questionable benefits;
EV SSL certificates are positioned to secure E-Mail applications among other things. Internet email standards generally don't require a browser, and current EV certificates' main distinction is the green address bar in IE7. You can encrypt SMTP using SSL but the fact that the the SSL certificate is Externed Validation will make exactly zero difference compared to any other SSL certificate. I won't be surprised though if EV flavour of mail signing certificates will emerge;
And the certificates are positioned as those giving the Highest Level of Digital Encryption available in industry - even though the level of encryption doesn't really have much to do with the type, or issuer, of the certificate.

Vulnerability scanning has its value. It's a very basic security control mechanism that allows to identify trivial system administrators' mistakes independently of their process. But it doesn't prevent 99% of security exposures. If it does, what about the remaining 1%? Is one attack out of a hundred successful? One attacker out of a hundred? That doesn't make sense.

In the example above we see how aggressive marketing can be misleading, even deceptive, and therefore diminish the value of otherwise useful service.

News: Web is dangerous

Slav — Tue, 01 May 2007 01:38:00 GMT

VoIP is scary, if you rememeber. Now, there's something else that is scary: WWW, the World-Wide Web. And thanks to Tim O'Reilly and his invention of Web 2.0, it's scarier than ever.

As in: there's much more to FUD about. Here's a perfect example: Web 2.0 Threats and Risks for Financial Services (by Shreeraj Shah). It's full of dung, as pretty much any other FUD. But being targeted at the financial industry (people with your money) it excels at that. Let's analyse:

The financial industry estimates that 95% of information exists in non-RSS formats and could become a key strategic advantage if it can be converted into RSS format.

RSS is just a way of delivering dynamic content (not quite a format), and not much of financial information really can use RSS. Market news (think of Reuters and Bloomberg services) and that is pretty much all. And the model is simple: authenticate and deliver content securely. RSS has no security implications here. And where the figure of 95% came from?

Ajax, Flash (RIA) and Web Services deployment is critical for Web 2.0 applications. Financial services are putting these technologies in place; most without adequate threat assessment exercises.

Of all corporations, financial industry is one of the most conservative. Every technology that is used undergoes rigorous assessment. And adequate (to the organisation's risk management and regulatory requirements) security is one of the top priorities there. The process of the evaluation may not be the most efficient, but that's a different issue - nothing to do with Web. Besides, Flash belongs more to entertainment industry: it's neither critical nor required by financial institutions for business-critical applications.

In the last few months, several cross-site scripting attacks have been observed, where malicious JavaScript code from a particular Web site gets executed on the victim’s browser thereby compromising information on the victim’s system. Poorly written Ajax routines can be exploited in financial systems. Ajax uses DOM manipulation and JavaScript to leverage a browser’s interface. It is possible to exploit document.write and eval() calls to execute malicious code in the current browser context. This can lead to identity theft by compromising cookies. Browser session exploitation is becoming popular with worms and viruses too. Infected sessions in financial services can be a major threat. The attacker is only required to craft a malicious link to coax unsuspecting users to visit a certain page from their Web browsers. This vulnerability existed in traditional applications as well but AJAX has added a new dimension to it.

AJAX doesn't add any new dimension to the XSS attacks: both the attack techniques and the ways to prevent cross-site scripting haven't changed.

One of the key elements of Web 2.0 application is its flexibility to talk with several data sources from a single application or page. This is a great feature but from a security perspective, it can be deadly.

And may be not. The decision to use multiple data sources is driven by functional requirements. And it can be well-secured.

Web 2.0 based financial applications use Ajax routines to do a lot of work on the client-side, such as client-side validation for data types, content-checking, date fields, etc. Normally client-side checks must be backed up by server-side checks as well. Most developers fail to do so; their reasoning being the assumption that validation is taken care of in Ajax routines.

At this point, an example is necessary. Abstract applications and developers aren't good enough. In the past couple of years the developers actually have learnt server-side data validation and more often use it than not. And the risk is of stupid developer, not of AJAX - if anything, AJAX is raising the bar for developers.

Web Services are picking up in the financial services sector and are becoming part of trading and banking applications. Service-oriented architecture is a key component of Web 2.0 applications. WSDL (Web Services Definition Language) is an interface to Web services. This file provides sensitive information about technologies, exposed methods, invocation patterns, etc. that can aid in defining exploitation methods. Unnecessary functions or methods kept open can spell potential disaster for Web services. Web Services must follow WS-security standards to counter the threat of information leakage from the WSDL file. WSDL enumeration helps attacker to build an exploit. Web Services WSDL file access to unauthorized users can lead to private data access.

Mr. Shah seriously suggests that security though obscurity is essential. That's rubbish.

A lot more analysis needs to be done before financial applications can be integrated with their core businesses using Web 2.0.

If we need analysis, that must be nothing like Mr. Shah's.