It has been announced that President Obama will pick his new cyber czar tomorrow. This will likely be a position reporting to the National Security Advisor, similar to Richard Clarke’s position under President Clinton.

This position will be critical for organizing the government’s fragmented information security efforts, both for the government sector and the country’s infrastructure, which is largely privately owned. Many of the security tasks that must take place to improve our nation’s security posture are well known. They are employed by forward thinking and risk averse sectors such as the financial industry. The challenge is rolling out those security tasks to a varied and diverse infrastructure operated by the US government and the critical sectors such as energy and telecom. Some of these tasks are deploying hardened OSes, modern patch management and vetting applications as they enter an organization before they are deployed.

Some of the challenges facing the new cyber czar include dealing with technology that is increasingly developed in India and China and attacks that frequently are sourced from overseas. There is a need to reach out internationally as the technology and infrastructure of the Internet is global. Any new regulations imposed need to be thought of as global in nature. The US cyber czar must take a lead in forging new international relationships to deal with cybercrime and the threat of cyberterrorism which may emanate from the same countries that are providing the US with the technology we use to run our Internet. Knowing who is friend or foe in the cyberworld gets more challenging every day in our increasingly globalized software and services economy. How do you work with internationally owned companies to get them to do the right thing to prevent cyberattacks from terrorists or nation states when the expense will hit their bottom line?

I look forward to a cyber czar that can take a global view to protect our infrastructure and a risk management view to understand the cost tradeoffs of protective technology and processes.

In lieu of actual technical content, and inspired by Jeremiah’s blog post, 8 reasons why website vulnerabilities are not fixed, I started thinking about all the different manifestations of reason #8, “No one at the organization knows about, understands, or respects the issue.”

I polled the Veracode research group, most of whom have been security consultants at one time or another, and ask them about the best responses they’ve heard from customers that reflect a lack of understanding or respect for a pen test finding. These often start with the proclamation, “that’s impossible…” followed by one of the statements below.

Developer doesn’t understand how the web works

• “Users can’t change the value of a dropdown”
• “That option is greyed out”
• “We don’t even link to that page”

Developer doesn’t understand the difference between network and application security

• “That application is behind 3 firewalls!”
• “We’re using SSL”
• “That system isn’t even exposed to the outside”

Developer doesn’t understand a vulnerability class

• “That’s just an error message” (usually related to SQL Injection)
• “You can’t even fit a valid SQL statement in 10 characters”

Developer doubts attacker motivation

• “You are using specialized tools; our users don’t use those”
• “Why would anyone put a string that long into that field?”
• “It’s just an internal application” (in an enterprise with 80k employees and a flat network)
• “This application has a small user community; we know who is authenticated to it” (huh?)
• “You have been doing this a long time, nobody else would be able to find that in a reasonable time frame!”

Developer cites incorrect or inadequate architectural mitigations

• “You can’t execute code from the stack, it is read-only on all Intel processors”
• “Our WAF protects against XSS attacks” (well, clearly it didn’t protect against the one I’m showing you)

Developer cites questionable tradeoffs

• “Calculating a hash value will be far too expensive” (meanwhile, they’re issuing dozens of Ajax requests every time a user click a link)

So that’s what we came up with in about half an hour, and I know there are dozens that we’ve forgotten about in our old age (you know, over age 30). This drives home the point that education is one of the largest gaps in most SDLCs. How can you expect your developers to write secure code when you don’t teach them this stuff? You can only treat the symptoms for so long; eventually you have to attack the root cause.

Submit your best “that’s impossible” lines in the comments! I know there are some good ones out there.

If you visit this article on the New York Times website, you’ll get immediately redirected to the website containing the original content of the article. [UPDATE: they fixed it, so it won't redirect you anymore]

Why does this happen, you ask? Apparently the New York Times ingests various third-party news feeds, wraps the article in the New York Times template, and serves it up. Here’s an example of an IDG article that was served up in similar fashion — note the word /external in the URL. When importing the article, the New York Times allows the external feed to include HTML markup. Going back to the McAfee article from ReadWriteWeb, the text includes a little tutorial on how HTML Injection works:

<p><span class="bold">How To: HTML Injection</span></p></p><p>
<ol>
<li>Go to the McAfee <a href="http://www.mcafeerebates.com/promocenter/mcafee/">Rebate Center</a></li>
<li>Click on Get Rebate</li>
<li>Include this line of code into the 'Date Purchased' field: <br/>
  <span class="italic">
    "<meta  HTTP-EQUIV="refresh" content="0; URL=http://readwriteweb.com">
  </span></li>
<li>Click on continue</li>
</ol>
</p><p>This is a very basic redirect that will take you to ReadWriteWeb.</p><p>
</p><p>And voila - you've just effected your first HTML injection.</p>

The New York Times shoves this content right down the pipe to your browser, and the META tag triggers a redirect to http://readwriteweb.com. Harmless, but confusing if you’re the reader.

What this behavior indicates is that any third-party news feed used by the New York Times can probably inject arbitrary HTML content, such as XSS attacks, into nytimes.com. Oops!