I got invited to an interesting session this morning at TechEd - a security discussion panel for the benefit of the blogger community. On the panel were Michael Howard (http://blogs.msdn.com/michael_howard/) and Vinny Gullotto (GM, formerly of McAfee), both of Microsoft. The discussion was open and interesting, covering a variety of topics. Summary follows.

First topic (although I arrived a little late and may have missed something earlier) - computers on the internet are now being compromised more for the sake of criminal activity than for hacker street cred. Attacks are becoming less visible. Attacks are also becoming more targetted against specific companies. Hackers and criminals follow the money, and so much the better if the target is poorly defended (TJX comes to mind).

Next came the inevitable discussion of the User Account Control (UAC) feature in Vista. I was listening to a talk yesterday by Rafal Lukawiecki at TechEd. His advice to the audience is to leave on UAC and run as a regular user. That way, every elevation prompt requires admin password entry. That’s sensible advice, but there’s a flip side: most Windows users will continue to run as admins, and hence will see UAC prompts, but won’t be required to enter a password in order to elevate. The net result is that, over time, users become trained to always click Continue (just like the Firewall prompt trains users to always click Allow).

What to do about the UAC prompting issue? One suggestion was to continue to push application authors toward digital signing, thereby allowing application identity to be tracked. The theory is that, if the application has been vetted and signed by a trusted authority (i.e. which I suppose means Microsoft :)), don’t prompt for elevation; just do it. If the application isn’t signed or trusted, prompt when elevation is required. However, I don’t see how validating and signing even a representative set of PC based applications could scale in the consumer (non-managed machines) environment.

Returning to the topic of network attacks, the observation was made that DDoS attacks continue to become nastier and more disruptive, as more compromised machines (bots) are brought to bear. What to do about this? Answer: get IPv6 widely deployed on the internet. This is primarily because the huge (and non-contiguously allocated) address space makes scanning ineffective. How soon is IPv6 going to widely deployed, given the infrastructure upgrade requirements? Probably not very. An interim solution exists in IPsec via IPv4, but IPsec is too hard to configure and manage in general. Software companies could certainly do a better job at making technologies such as IPsec easier to deploy.

Security education for software developers at the University level was the next topic. Do widely used languages such as Java and C# make secure programming techniques easier to teach? Maybe, although they don’t seem to be having that affect. And, in the absence of such training, those languages are no more likely to result in secure code than C/C++.

The final topic discussed was spam. Spam has become so pervasive that client-side filters now tend to catch a noticeable amount of legitimate email. This is especially a problem for small & medium-sized businesses, who tend to have a smaller percentage of email sent between internal accounts. Depending on the number and type of business partners involved, setting up trusted/federated messaging beween them can either be challenging or impossible. One technology could play an alleviating role here: S/MIME (or PGP), but getting all parties is still a challenge.