On 13 August, jcorey asked about how to deal with those who firmly believe that the only answer to any security problem is to inspect everything at the edge. This is an important question, and I wanted to give Joe an answer. (You might have to scroll down when you click the previous link, it seems that linking to individual comments is broken.)

Today, 15 October, I wrote a little thesis as an answer to his question. I’m calling it out in a separate post because I want to make sure those of you with aggregators that don’t update when posts receive new comments still have a chance to reply with your thoughts. I’ll also repost it here:

jcorey-- You've nailed the biggest obstacle to deploying something like direct connect. Many security professionals have been taught that there simply is, and never will be, a process or technology that allows you to trust anything that originates from outside your corpnet. These professionals cling to this belief, and have been the cause that allowed the whole “detection” market to bloom.

Let me be clear: this total lack of trustworthiness is no longer absolutely true. Of course there will be times when unknown machines will be used by known and unknown people to access your information. But what about one particular subset -- known humans, with known portable computers -- can't we do something better than treat them as toxic invaders?

Indeed we can. And that's what I'm proposing with direct connect. The technology -- managed, of course, with the right processes -- exists so that you can extend the trust to known computers even though you don't trust the network they're connected to. This is because you have mechanisms that:

1. Allow you to configure the machine according to your requirements (domain join, group policy)

2. Dictate computer and user authentication requirements (IPsec policies, smart cards)

3. Limit what the users of these machines can do (UAC, non-admin, Forefront Client Security, Windows Firewall, even software restriction policies)

4. Validate the health of machines initiating incoming connections and remediate if necessary (NAP, System Center Configuration Manager)

5. Limit the threat of attacks against stolen computers (domain logon, smart cards, BitLocker with TPM)

With the robust authentication, validation, configuration, and control mechanisms available to you, I simply don't see that there's any need to fall back to “detection” now. Detection technologies were -- and remain -- necessary for the times when we have no clue about the health of client computers and when we had no way to gauge the intent of the users. But it is truly reflective of a head-in-the-sand mentality to assume that this is a complete description of what's capable today.

You know, someone once asked me what it takes to be a security professional. I answered that there are two primary elements: become a networking/packet wonk, and be willing to change your opinions when the right evidence comes along. Indeed, I suspect that many security folk have forgotten the need to keep their wonikness updated, which in turn makes them resist new ideas regardless of the strength of the evidence. I'm not very proud of what I just wrote, because I loathe generalities, but I'm not sure what else to think here. Sigh.

Joe’s question is important and strikes at the foundation of what it means to be a security professional today. I’m eager to continue this conversation, because it’s reflective of what I sense to be a radical shift in our jobs—we are, or should be, no longer the wolf-crying propeller-head who sits in the basement and twiddles with the firewall. Instead, our job should be defined as one who’s charged with protecting the organization’s information from attack, while maximizing its utility to authorized users, according to the principles of least privilege. Your thoughts?

Finding Zune-Fi: Ina Fried of News.com wanders the polite streets of San Francisco in search of Zune connections over Wi-Fi. She finds a few, and has a good experience. One cafe owner sees the ease with which she can stream music and calls it cool. She can't connect at the long-running Google-sponsored free Wi-Fi at Union Square, however, which means the Wi-Fi likely has an accept button that must be pressed. Surely Microsoft could insert a little technology that would allow a browser-free acceptance of terms? Probably involves Yet Another Protocol: the Wi-Fi Terms Browser-Free Presentation Protocol (WTBFPP).

Kodak adds interesting Wi-Fi enabled all-in-one: The new Kodak ESP 9 is a multi-function printer (fax, scan, print, copy) that connects to a network via Wi-Fi or Ethernet. The $300 device spits out 30 pages per minutes in color, 32 ppm in black only. Kodak claims that the model line to which the ESP belongs uses ink in a vastly more efficient manner than the "average of comparable consumer inkjet printers."

That being said, there are some interesting implications that XSS Filter and other user-specified defenses have for the SDL. Given that XSS Filter is effective in stopping many types of reflected XSS attacks, should we relax the SDL coding and testing requirements around server-side XSS defense? Of course not. For one reason, the SDL requirements are effective in preventing forms of XSS that XSS Filter does not address, like persistent XSS. For another, not everyone uses IE 8. If we were to relax server-side requirements now, we would jeopardize IE 7 users, as well as Firefox, Safari, Opera, Chrome, and all the other browsers’ users.

But what if these conditions change? What if David and others on the security science team develop a new version of XSS Filter that’s effective against all forms of XSS? And what if all the browser manufacturers develop similar technology and implement it in their browsers? (Or alternatively, what if every user on the planet switches to IE 8? ☺) Then would we relax the server-side XSS defense requirements? Yes, we probably would.

I’ve always been more of a security pragmatist than a security purist. While the security purist in me would want to keep the requirements around to prevent developers from falling back into bad habits, the security pragmatist in me would recognize that development teams have a limited amount of bandwidth, and making them defend against rare, obscure vulnerabilities is a poor use of their time. Unfortunately, we’re not likely to face this scenario any time in the near future, so the SDL will continue to require server-side input validation and output encoding to prevent XSS attacks.

We now return you to your regularly scheduled development-focused blog.

• ValidationSummary controls look at the ErrorMessage field to figure out what to display, so always use ErrorMessage in a verbose enough way that it will be helpful from a ValidationSummary control.
• If you need a shorter message to display inline (i.e., where the validation control is on the form, as opposed to the ValidationSummary) use the body of the control to define it.

In the past, I've used RequiredFieldValidator controls on my web forms to remind users that certain fields are required. I would set the ErrorMessage to something vanilla like, "This field is required", or even something simpler like "*" (an asterisk) if I didn't have much room on the form to display more prose for an error.

A friend was recently testing a new feature that I'd built for our sales team and she had a hard time seeing the little red asterisks that were showing up next to required fields. It felt to her as though she was pushing the submit button on the form but nothing was happening. It was clear that a ValidationSummary control would be helpful, especially if placed close to the submit button for the form.

I've been a bit lazy in the past about using ValidationSummary controls, partially because most of my forms are simple enough that they feel a bit redundant. But on a more complicated form, they can be very helpful to guide users back to the places on the form where there's problems.

So I threw one of those puppies on the form and immediately saw that there was a problem - my error message was set to "*", which meant that my validation summary was pretty useless - it just displayed a bunch of red asterisks! And in places where I'd used the prose, "This field is required", well that was pretty useless as an error message in the summary.

After a bit of research and experimentation, I discovered that the ValidationSummary control looks at the ErrorMessage property on each validation control in order to figure out what to display in the summary. So it's important to use ErrorMessage with a summary in mind! Don't use text like "*" or "This field is required". Be more specific so the user can find her way up to the problem field, as in, "PostalCode is required".

But if you make ErrorMessage verbose so that it's helpful in a summary, it may make your form really ugly when displayed inline next to the control being validated. The trick is to use the body of the validation control element to specify the inline error message. Then you end up with two messages: a verbose one that's used in your summary, and a more localized, brief message that shows up right next to the control being validated. Note the asterisk that's in the body of the RequiredFieldValidator below:

<asp:RequiredFieldValidator
      ErrorMessage="Zip/postal code is required"
      ControlToValidate='txtPostalCode'
      ValidationGroup='BasicInfo'
      Display="Dynamic"
      runat='server'>*</asp:RequiredFieldValidator>

I've learned a lesson from all of this. In the future when I use validation controls I'll always provide a summary-friendly message in the ErrorMessage field, and if I need something different (typically shorter) to display inline, I'll put it in the body of the validation control element.

Hope this helps!