Well, Fest 08 was a great success with 'Data Today, Data Tomorrow'. Loved the sessions and the usual Dave and Rich game show.

Here's a write up of the day:

http://www.nxtgenug.net/Article.aspx?ArticleID=283

and here's a shot of Dave McMahon giving a live demonstration of various yoga positions. Don't ask......

Google charts are an interesting tool for producing graphic representations of your data.. The Google Chart API returns a PNG-format image in response to a URL.

This is an extremely useful tool, and there is already more than one wrapper for the API so that you can call it from your code.

But how about the security aspects of this tool? Well, if you're worried about availaibility, you can store the resulting .png file on your own server, and provide your own resilience.

However, the confidentiality and integrity aspects are quite suspect. Only http is available, not https. This is a shame, as your business data deseerves better than this. You've provided HTTPS for your website, perhaps strong authentication and have protected your servers and database. Then you send that data unprotected across the internet.....

Also, you're at the mercy of Google for protection of the data while it's on their servers. I know all the techies are going to say "Yeah, but Google use xyz operating system and abc brand firewalls." Fine, but have they vetted the CVs of the admin staff that work on those servers? How do they dispose of the discs? How is the dev environment segregated from production?

If I was a hacker/criminal/hostile government, Google Charts would be a prime target for my attack.

I'd suggest the answer at present is to only send non-sensitive data across the internet to this service.

What's non-sensitive for your company? OK, answer the following question:

Can you print out the data on A4 paper, stand in your local shopping mall and hand it out to everyone passing? If the answer is NO, then don't use Google Charts for that data.

Microsoft have produced a beta of the WCF  Security Guide.

I'm chuffed to bits to see this appear. I've waited for quite a while to see some of the older guides updated, and this is very good quality.

I worked with a security consultancy last year that gave their graduates the older Patterns and Practices Guides on the first day at work. The new graduates all wondered why they'd not been given the documents at university!

One of the strengths of these documents is that they've been tried and tested. This is proven by the code samples that are included - so many questions are answered by providing this.

Several solutions are included, which can be mapped on to your requirements. This is what design patterns are all about for me - integrating parts of the application together, rather than being lost in classes and interfaces. This is extremely useful, as security often changes (fundamentally) the architecture of an application. Having a mapping from requirements to architecture saves a great deal of time and money, as there is less change later in development. The overall security integration can be done sooner.

What are the downsides? Well, they're vey few in number:

Only Microsoft products are considered. Shame, as MS are much stronger in the enterprise now. I'd like to see how a WCF service can be called from web server xyz, rather than just IIS. I'm not asking for all web servers to be covered (that would be duplication) but just some general guidelines.

IPSec. Several sections of the guidance sugest setting up IPSec for security. This just doesn't happen (usually) in ver secure environments. There are too many technical and beaurocratic reasons why you won't get this sort of connection set up when requested. For instance, many large organisations are moving toward application layer security as the hardware encryption accelerators just can't keep up with WAN traffic.

ASP.Net membership providers. They're a good suggestion, but they're not as useful in the enterprise as one might imagine. Generally, one would provide a heirarchy of roles and permissions within the application, and the roles would map to groups within the enterprise. The Asp.Net providers only allow the user to role mapping, which can lead to spaghetti code after a few releases (if user.isinrole("Manager") or user.isinrole("External") or user.isinrole("Support") etc. for each programmatic role check).

Then again, that's what MVPs like myself are for, isn't it? I humbly aim to fill in the gaps in some future presentations.

I was fortunate enough to be invited to the IMTC this year to speak on WCF security. Had a great time, but what a busy day!

I left my home at 7am and travlled continuously until 2.30pm, when I arrived. And I was speaking at 3.15!

Thanks to the (large) audience that came to see me. I promised to put up the slides and code, so here it is.

Last month saw the launch of stacks of new Microsoft technology, so to celebrate we gave away loads of swag (Vista, VS 2008 and more!). Barry even had the foresight to set up a raffle.

To top it all, we had the fabtastic Simon Sabin speaking on SQL development. Really enjoyed hearing about all the new facets of the world's best database, and the co-ordinates tool that Simon showed us was awesome.

The usual suspects:

Barry hurling swag:

Simon Sabin speaking on SQL Server 2008:

I had to laugh. I've worked on a Unix based application recently. The service account is also granted access to log on to the application. Production support is also performed using this account.

Apparently, I've been told, this is fine. It's on a Unix server. Unix is secure.

Look, you can make any OS insecure if you want. And these guys really have tried......

It's important to segregate the accounts. That service account will have a high level of access to the database. The production support person, using that account, can now read and write to the database containing production data. What if you were a bank and this was a trading system? You've just blown all your legal and compliance responsibilities!

The service account should only be used for the application to run.

Create another account with access to the files for support.

Don't let someone log on to the application with this account.

This is called least privilege. Doesn't matter whether it's Unix, Windows or xyz operating system, the principle is absolute.

What's security about? Well, the bottom line is that we're specialist risk managers.

Why bring this up? Well, I've recently sat through a talk on securing applications where the speaker said "You must always encrypt communications between the application and the server" and "You must always add PrincipalPermission checks on your components".

Not true. If you tried to apply security to every aspect of every application, you just wouldn't ever finish.

The important question is "What is the cost to the organisation of the breach?"

If the data within an application is of no value, can be released to the public, and will not cause the company harm if the integrity is breached, then I'd suggest there are some instances where you wouldn't apply security at all. Notice my italics.

There are lots of calculations and methodologies involved, but I'd suggest looking at ISO 27001 as a starting point.

Great news for me - Microsoft have renewed my MVP status for Visual Developer - Security. I'm really honoured to have received this renewal, and am very proud to be the recipient of this award.

Even better - my mate Barry Dorrans has been awarded his. He's a great speaker, so please make the effort to see him if he's visiting your user group.

Jean-Paul Boodhoo from Calgary, Canada spoke at Next Gen UG in Oxford on 17th September.

His subject was Generics, but he went much further than his, sharing his experience as both a presenter and a technical expert.

The audience were spellbound - Jean-Paul gave the presentation without slides, just code, all completely from scratch. This is no mean feat!

Here, Jean-Paul is speaking, taking questions, coding - and taking a quick bite of pizza when he got the chance!

This was one of the best evenings yet, and many thanks to Jean-Paul for coming all the way down from London to give the talk.

Another great night last night. Barry spoke on Duck Typing. Or Duct Taping, if like me you get your worms ..err... words mixed up. Is it the same as using the old vbs var? Not really, and Barry Dorrans gave a good overview of the specifics and its uses.

The main speaker was Dave McMahon, who gave a brilliant talk on office integration. He demonstrated how to use Access (an always underrated tool) to create queries across SQL, XML, text files, Excel spreadsheets.

He then went on with a demonstration of how to create a web service within the SharePoint site that queried lists.

This was my favourite talk so far at the Oxford NextGen.