Even though I went to bed early, still woke up exhausted, so I'll give a miss to the first session. Such a beautiful day, it's a crime to not have some of those sessions outside.

Here's a few things that went under my radar in the blogosphere about teched:

• Gill gives an overview of his first day, and think Barcelona is dirty at first sight
• Joao talks about the Influencer Community Camps pre-conference. He also talks about the CSD influencers dinner on monday, but I'm afraid I was not invited, neither was I on tuesday for the MVP (as you know, I'm not an MVP :)). But tomorrow I'll attend the MS Influencers Party, Wednesday the country party, and Thursday I'm meeting up with some people from the Windows Live team. So much to do, so little time!
• Sascha talks about the World of Warcraft IDE microsoft will release with their partner as an open source project based on Visual Studio shell that was demo'd during the keynote. Go and check it out. And Ronan let us know he'll be in the Ask The Experts for Team System.
• Andrei talks about the Microsoft Sync announcement, personally the one area I'm the most thrilled about, so thrilled the SDK is already installed and I'm coding away :)

Overall, not much noise so far. Maybe the PDC next year will be louder! More content to follow, and tomorrow pictures and videos!

[EDIT: By Michael Howard, definitely a legend in my book!]

Until 8 years ago, i was completely focused on security features. But a small group of us, around 1999, decided to split from the Windows group and focus on how to design software.

Security people suck. They only see things in black and white, you can either have secure or not secure. The real life doesn't work like that. Theres plenty of shades of gray, and security people don't see gray. What they're good at is to tell you when youre wrong, but they won't tell you how to do things.

We added the NX to WindowsXP SP2. The first wave of AMD devices supported the option of not executing data, as most security vulnerabilities get introduced as data that then get executed.

When something is not on by default, people don't turn it on. Also, if it's not on by default it won't get as much testing.

When we activated NX by default, Flash, Acrobat, Java VM don't work. So we had to choose between not running by default and not get used, or be on by default and nothing works. As a security guy I said break the applications. But my manager said that didn't work! So we decided to have NX on by default only for opt-in processes.

The one thing I learnt is that there are shades of gray.

References to books for Writing secure code for Windows Vista and Writing secure code.

So what is the SDL? It's a bunch of requirements and recommendations, and the post release process. It's taking the lifecycle and improve the security by reducing vulnerabilities and reducing the severity of the vulnerabilities.

Lot of people think you can improve the quality by adopting some process, you'll improve the security of the software: there's no evidence! You can't think of general quality stuff, you need to focus on security itself.

The matrix I use is the amount of bulletins post-shipping. Since Vista, we have fixed 70 vulnerabilities in XP, 33 in Vista. In a perfect world it would be 0, but I'm happy with the 50% reduction. IIS6 only had 3 bulletins, sql server had one 4 years ago. Even the analysts start recognizing this.

The SDL is made of two big chucks: Requirements and recommendations (must and should).

Some functionality was invented a long time ago and was fine 20 years ago. But today it doesn't work because of threats. For example CRT (C runtime). You can't write new code that uses the old APIs, 120 functions. You can include banned.h which works with gcc and others, or use VS2005 that puts a warning.

In the SDL, if you put forward a requirement, you need to be prescriptive about what the fix is. For the CRT, we recommend two libraries: Safe CRT and strsafe. VS also automatically replace the banned functions if it knows the destination buffer size.

One of my favourite tool is SAL, Standard Annotation Language. It helps static analysis tools. The shell team decided to annotate the shell headers. He ran the tools we have at microsoft again and found 100 bugs. It lets you annotate your header files with how attributes relate to each others, if they're optional, in, out, etc...

Integer arithmetic issues can be resolved in several ways. First, use the latest C++ compiler, it protects you against the operator::new overflows. It crashes your process but that's better than running code injection vulnerabilities. Second, review your memory allocation: Is there any calculation to calculate a buffer size? Does the bad guy controls one or more operations? Finally, you can use IntSafe (C) and SafeInt (C++).

Next thing is the no weak crypto. A lot of algorythm that were ok a few years ago are not ok anymore. No new code can use MD4 and MD5 (collision of 1 in a million in MD5), SHA1 is showing signs of weakness, so it's banned too. Use SHA2. Can't use DES or triple DES - use AES. RC4 is not allowed because it's a stream cipher, no symetric keys < 128bits, no RSA keys, no weak random number generation, no embedded secrets and be crypto agile: don't define which crypto you use in your code. You should also not have weak ACLs: we found a bug a couple of years ago where a vendor was intalling their device driver in ProgramFiles. They changed the ACL to Everyone full control. Michael's advice: don't touch ACLs. The defaults are very good, don't change them.

We also have requirements about compiler switches. The GS flag adds random numbers to the stack: you need to guess the cookie we've set because we check it, and if it's not what we expect we crash the process. When the blaster worm happened, win2000 and XP were infected. Windows Server 2003 wasn't infected but the coding was there. We detected the buffer overflow at runtime and crashed. It was affected but not infected. For some arguments we copy the data earlier in the stack. In Vista, we compile with the orcas compiler.

Safe exception handler would have prevented CodeRed. The PE header has the address of the exception handler. At runtime the OS checks the exception against the list in the PE header. NX is the No Execute, ad DynamicBase is base address randomization for OS code. Finally, /Strict MIDL generates safer IDLs.

Although tools are incredibly useful, they don't make the code secure. Bad code and bad developers won't be saved by tools. There shoudl be nothing special about security, each developer should include it as part of getting the job done.

In Vista there's an option to detect any heap corruption and kill you on the spot.

The only scenario in which reliability guys have a conflict with security guys is when we bluescreen the machine if the security event log is full.

There are also web-specific guidelines. A lot of people write a lot of rubbish code. Use the Xss library, don't let SQL injection happen. Deny access to the underlying tables, only allow views and stored procedures.

Gadgets are Html / javascript / Silverlight. If your gadget renders untrusted data, you can call anything. Any exploit code can run. The first thing you should do is validate all your incoming data, and code review for insecure use of innerHtml, document.write, and Eval (which is one letter away from evil and there's a reason for that).

Inspect your Gadget from Michale Howard & David Ross.