Soma announced some new stuff in his keynote, among which the release of Visual Studio 2008 and the .NET Framework 3.5. Unless you have been living in a cave for the last week, you already heard or read about this somewhere.
What is Next for the .NET Framework and Distributed Applications
My first session at TechEd 2007. Steven Martin tried to explain the vision of Microsoft on distributed application development for the next couple of years. To me it appeared kind of flue and fuzzy. He also briefly mentioned Oslo. In a nutshell, Oslo is
- not a new product.
- a set of existing products (the .NET Framework, Biztalk Server, etc. included).
- based on .NET
I had the impression that the speaker knew more than this, but couldn't tell the audience for some reason. Oslo primarily consists of services and models (talking about two overloaded terms here). To me a model is an essential part of software design as described in Domain-Driven Design: Tackling Complexity in the Heart of Software. From the stuff I heard in this session, I think that Microsoft means something else, but I'm not entirely sure.
The Security Development Lifecycle
Great session. Excellent speaker. Fantastic subject. One couldn't ask for more. Although Michael Howard only focused on the development part of the SDL, it was a great talk with lots of tips, tricks and best practices for both unmanaged and managed code. After the session, everyone could get a free copy of his book on this very topic surprisingly called The Security Development Lifecycle.
Some random notes I've made during the session:
- Security in software should be applied pragmatically.
- Optional security features won't work. They are never going to be used.
- Increasing the overall quality of software doesn't affect the quality of security.
- Don't use weak cryptography (MD4, MD, SHA1, DES, RC4).
- Don't use symmetric keys that are smaller than 128 bits.
- Don't use RSA keys that are smaller than 1024 bits.
- Use this VS2005 macro to detect weak cryptography.
- Be crypto-agile: no hard-coded encryption algorithms in your code.
- When your code detects a security violation, then let it kill the application. Its always better to kill the application by raising an exception than to execute code that is not trustworthy.
- Use static analysis tools like PREfast, SAL, FxCop, AppVerif, ... etc., but remember that tools can only take you so far. They are not a replacement for a human brain.
- Don't hire bad developers.
- Security is not something special. It should be part of building any kind of application.
- Don't nag about performance versus security. Measure it! Don't make any assumptions without it (this is one of my pet peeves for many years now).
I don't understand why there were so few people attending this session. I mean, this is such an important topic. Do you really think that the CLR is doing everything for you? Come on!
PS: I'm blogging this in retrospect as I couldn't get the blogger administrator web site to run on the CommsNet PCs because they had JavaScript turned off.
