Chris Seary's blog

Application service accounts

chris — Sun, 24 Jan 2010 12:57:08 -0800

Networking/infrastructure specialists often have a very different view to developers when it comes to security. To be quite frank, the network guys have a very good track record these days (setting up firewalls, locking down servers etc.). The developers, being relatively new to the game, are having to play catch up at a time when many malicious users have discovered the vulnerabilities within web application code (such as SQL injection, cross-site scripting).

It's difficult for developers because there are very few tools or standard configurations that can lock down the application. A developer has to ensure that each function written has the necessary layers of security. For instance, has the input been validated? Is the database being accessed securely via stored procedures when adding the data to the database? Has the user been authenticated somewhere on the web page?

The two points of view (infrastructure specialist and developer) sometimes lead to conflict due to misunderstanding.

A case in point is the use of service accounts. The infrastructure specialist is often, but not always, keen for the logged on user to be identified and authorised by the operating system in all components of the application, by flowing the identity. This can be achieved via kerberos, or simply re-supplying cached credentials to re-authenticate (IIS and its use of NTLM is a good example of this).

The developer sees this quite differently. By flowing the identity to the database, a new security context is used each time. This means that connection pooling (several instances using one database connection, that is retained between batches) is lost, and so performance grinds to a snail's pace very quickly. Also, if one is authenticating and authorising the caller at the database, then that user has direct rights to the database, and can access it without going through the application.

This is why internet facing web sites generally use an application service account. The web server authenticates the user. The web application then uses that identity for checking whether the user can access specific functionality. However, it does not run under the context of that user - it functions under contect of the service account. Only that service account is granted access to the database.

Although this improves performance and prevents users accessing the database directly, there are certain vulnerabilities that have to be controlled. Firstly, this service account has very high levels of access to the database. Compromise of the application can give a lot of potential pwoer to a malicious user. To control this, it's important that secure coding practices are used. Also, tools such as Code Access Security, which restrict what each component of the application can do, mitigate the potential damage. As well as this, the database access should be locked down as much as possible. Never give service accounts dbo or sysadmin privilege. It's always best to give execute permission to stored procedures only.

Secondly, accounting and auditing is reduced. The operating system will log that every operation was performed by the service account. This is where a lot of 'plumbing' has to be coded. Usernames have to be passed to stored procedures, history tables have to be created, database columns with the name 'created by' are added to almost all tables. This can, and usually is, tightly managed.

Architecture guides, such as the ones produced by SUN and Microsoft, give a good overview of the risks, architectural patterns, and implementations that will satisfy security requirements:
http://msdn.microsoft.com/en-us/library/aa302415.aspx
http://www.sun.com/security/index.jsp

The thoughts of Chairman Chris - 1:Browser Compatibility

chris — Tue, 24 Feb 2009 02:48:31 -0800

I was having problems with a site rendering properly in Internet Explorer. A friend of mine suggested that I use Firefox instead.

I thought I'd write this blog article to vent my annoyance, and put everyone right!

Now, I've used IE to access the following:

-sites containing Java applets
-eBay
-Amazon
-Flickr
-YouTube
-BBC web page
-various sites that use Javascript to mimic 1980s pub games (such as Space Invaders)
-a virtual, secure desktop environment of one of my clients, which is separated from the host operating system

IE has no problems whatsoever with any of these.

The very few sites I encounter that have display problems in IE don't do anything major. They really are simple. The problem is usually just rendering of stylesheets.

Why don't they work?

Enterprise Architects have an expectation now that a web site will work on a browser. That's that. No hassles.

Your web server can emit HTML and Javascript that will work on different browsers. Or it can pick up the type of browser, and send different output to each. You then test it on the last couple of versions of:
IE
Firefox
Opera
Safari

And then your web site will work. This is very simple, basic stuff. This is what websites have done for years, and it succeeds.

The website that I mentioned at the beginning of this article carried a notice stating 'IE is having problems rendering our pages'.

This isn't what is happening.

Only one thing is going on: 68% of their target audience is not able to do business through their web page.

If you can't get this right, then you're missing the point of having a web site.

Google and your data

chris — Tue, 27 Jan 2009 02:41:55 -0800

Another Google tool where you may be exposing your data across the internet, and have no control over where/how it's stored:

http://www.guardian.co.uk/technology/2009/jan/25/google-drive-gdrive-internet

How are they storing your data? Will it be encrypted? Doubtful, as this will slow down performance.

You're handing over your personal data to another company. In another country.

It was tried ten years ago, and never took off.

The private sector are the biggest users of PCs. Business will not use this, as they have to meet their legal and compliance responsibilities. That's why it ain't gonna fly.

Rant over.

25 most dangerous coding mistakes

chris — Sun, 18 Jan 2009 14:19:05 -0800

The US National Security Agency helped put together a list of the 25 most dangerous coding mistakes.

Here they are, in all their glory:

Improper Input Validation

Improper Encoding or Escaping of Output

Failure to Preserve SQL Query Structure

Failure to Preserve Web Page Structure

Failure to Preserve OS Command Structure

Cleartext Transmission of Sensitive Information

Cross-Site Request Forgery

Race Condition

Error Message Information Leak

Failure to Constrain Operations within the Bounds of a Memory Buffer

External Control of Critical State Data

External Control of File Name or Path

Untrusted Search Path

Failure to Control Generation of Code

Download of Code Without Integrity Check

Improper Resource Shutdown or Release

Improper Initialization

Incorrect Calculation

Improper Access Control

Use of a Broken or Risky Cryptographic Algorithm

Hard-Coded Password

Insecure Permission Assignment for Critical Resource

Use of Insufficiently Random Values

Execution with Unnecessary Privileges

Client-Side Enforcement of Server-Side Security

Looking down the list, we can see that a number of the issues have been around for a long time. SQL injection – why are web sites still allowing this, after all the publicity and information disseminated on prevention? Many large organisations are still suffering from these problems, so it isn’t just confined to smaller businesses.

Most of the flaws come into being during implementation (development), such as:

Injection attacks

Improper file access

Some occur during design, such as:

Poor authentication

Broken security

And some occur during the deployment/testing period, such as excess privilege for web applications. This is usually a result of developers running as administrator on their machines, and finding that the application won’t run any other way when it’s installed onto the production server.

There are also other categroies and flaws in the list, but I'm not going to be exhaustive in covering it. I'm focusing on initiatives to improve the development process.

So where do we start in tackling this? The problem really is a good example of how we must look at security as a process, rather than just trying to find a quick fix.

Concrete solutions that I have been involved in at various organisations have included the following:

Secure coding requirements

Training programs

Penetration testing

Code inspection

Validation frameworks

One generally has to target both .Net and Java, as large organisations will tend to use both.

Secure coding requirements seem to be continuously written over and over again at one organisation after another. A good basis for Microsoft products is the Building Secure Asp.Net Applications document, and Improving web application security This guidance can be used, with company specific guidance appended. Java documentation gives less of an integration overview, but this is because it will be more implementation specific. However, the Microsoft patterns are quite generic.

Once these documents are written, they will then feed into the development process, and end up being part of the specific non-functional requirements for the application.

Training programs are another essential part of the process. I have worked with a global client recently, creating a training program that was based on the secure coding requirements, and the processes involved in getting security sign-off. This training was computer based, so that all technology-based employees could learn how to integrate security.

Penetration testing may take place, depending on the criticality and vulnerability of the application. For instance, an internet facing application with extremely sensitive data would certainly need a pen test. This will usually reveal discrepancies, which then have to be prioritised and fixed. Let the development team know early on whether this will be necessary, as it will have to be budgeted for.

Code inspection can take many forms. An audit based approach, taking a sample and manually checking, is useful. Also, there are many code checking tools, such as CAT.Net.

From the cat.net code download site:

CAT.NET is a snap-in to the Visual Studio IDE that helps you identify security flaws within a managed code (C#, Visual Basic .NET, J#) application you are developing. It does so by scanning the binary and/or assembly of the application, and tracing the data flow among its statements, methods, and assemblies.

I’m planning to produce an article on this tool soon.

Finally, validation frameworks are becoming more popular. There are lots of types of invalid input, such as

Mistyped entry – simply something which is misspelled or wrongly formatted, such as a date

Broken business rules – Perhaps the email field for your external-facing web site needs more validation than just a regex to check the formatting. What if someone were to enter an internal email address, from within the organisation? This could perhaps be fraudulent.

Request manipulation – querystring manipulation to access the wrong data is common

Validation frameworks are libraries that are geared to checking for all of the above, and more, so that they can be plugged into an application, giving a reliable, tested implementation. They have to be lightweight (so that they don’t take up too much memory, especially in web applications) and efficient (many of the functions will be called repeatedly during a request). Unfortunately, due to the inability of .Net and Java to call each other’s libraries efficiently, two versions would have to be built and maintained.

The OWASP Enterprise Security API (ESAPI) Project is an attempt to produce a strong security framework. The ESAPI is the result of over a decade of code review and penetration testing of critical enterprise applications. At present, only the Java version is available. Efforts to build ESAPI in .NET and PHP are already underway.

Hopefully, this article will give you some clues where to start when introducing an application-level security regime to your organisation.

SQL Server 2008 Encryption - more details

chris — Mon, 10 Nov 2008 14:40:28 -0800

I've just had a piece published by the nextgenug on SQL Server encryption, which is an expansion of my previous post. Hope you find this useful.

SQL Server Transparent Data Encryption

chris — Wed, 15 Oct 2008 07:15:55 -0700

A major problem in the commercial world is getting people to look after their data. Too often, a staff member will save sensitive data in a document without adequate protection, bypassing all logical controls set up by the system administrator.

How do we solve this? Ask everyone to apply strong Access Control Lists to all data that they save? This would cause problems:

-A lot of wasted effort if the data is not sensitive

-For the sensitive data, how should one apply the ACLs? Which people should be allowed to access it?

A common solution has been to use the concepts of security classification from the defence world.

You’ll recall all those documents in James Bond movies marked ‘Top Secret’ and ‘For Your Eyes Only’. Well, this can be applied to the different types of data in an organisation. You can make up your own labels, but I’ll use these four:

Top Secret	-Could harm organisation if made public -Secret keys -Take over plans	-Store encrypted -Backup encrypted -Transmit encrypted
Secret	-Board meeting minutes -High value contracts	-Transmit encrypted -Backup encrypted
Restricted	-Low value contracts	-Transmit encrypted
Public	-All other material	-Unprotected

Now we have this, we can decide what type of data falls into each classification:

Top Secret	-Could harm organisation if made public -Secret keys -Take over plans	-Store encrypted -Backup encrypted -Transmit encrypted
Secret	-Board meeting minutes -High value contracts	-Transmit encrypted -Backup encrypted
Restricted	-Low value contracts	-Transmit encrypted
Public	-All other material	-Unprotected

This enables staff to know how to categorise data.

Now we add details of how the data is to be protected:

Top Secret	-Could harm organisation if made public -Secret keys -Take over plans	-Store encrypted -Backup encrypted -Transmit encrypted
Secret	-Board meeting minutes -High value contracts	-Transmit encrypted -Backup encrypted
Restricted	-Low value contracts	-Transmit encrypted
Public	-All other material	-Unprotected

So now staff can see how to handle each type of data. The table above would probably be a lot larger for most organisations, but you get the point. Staff can now identify the type of data, and from that they are able to use the correct safeguards.

Encryption of sensitive data at rest and in backups is very common for major institutions. This can be a very computationally intensive and difficult to implement control.

SQL Server 2008 introduces a new tool called Transparent Data Encryption. This encrypts data at the page level of the database, but decrypts it as it is read into memory. And it doesn’t increase the size of the database!

The encryption is performed by a database encryption key (DEK). This is a symmetric key, which is then encrypted by a certificate stored in the master database of the server. This is then protected using the DPAPI.

The following slide from MSDN makes things a little clearer.

This is great news for those of us who work in compliance related positions, such as security consultancy. A lot of effort has previously gone into development of solutions or selection of third party tools that provide this protection. Now SQL database administrators can provide this with minimal financial cost to the organisation.

Real World Application Security

chris — Mon, 13 Oct 2008 12:57:58 -0700

I gave this presentation at two events this week. The first was in front of a room full of MVPs (obviously stressful, but their comments were very kind).

Second was at the University of Surrey, where I presented to a class of Masters students for an Information Security module.

Apologies to everyone for the delay in posting the slides.

Why use WS-Security

chris — Wed, 03 Sep 2008 08:12:41 -0700

I was having a discussion with Eric Nelson on his blog the other day. I was having a rant about requirements, which I think is one of the most vital aspects of software today.

For instance, I've been told by a number of developers that MVC is the 'correct' way to develop a web application. However, I disagree strongly with this.

I don't doubt that Model View Controller is very useful for certain applications. It is a valid design pattern for solving certain problems.

However, it's not 'the correct' way to develop a web application. The only thing that is correct is the requirements. If you use MVC, and it either hinders achieving the requirements, or it adds nothing to those requirements, than MVC is not the correct design pattern to follow. Simple as that.

There have been similar patterns used in security that added no value. I worked on a project three years ago that used WS-Security, because it was the latest 'cool thing'. At the end of the day, it added no value, as SSL matched the security requirements more efficiently.

So, when should you use WS-Security? I wrote an article recently that is on the MSDN Developer Security page.

The article matches requirements to technologies, and has been used by various clients as I was writing it. I hope you find it useful.

Custom authentication with WS-Security

chris — Sun, 27 Jul 2008 12:25:27 -0700

The SOAP and WS-Security formats, although very verbose when compared to RESTful implementations, have a much more advanced security model. They give the ability to override the authentication used within IIS (which uses Active Directory). By moving the credentials (username and password) from the HTTP headers into the XML of the message, one can use the UserNamePasswordValidator class to implement custom authentication.

Here's an article I wrote for the Next Generation User Group giving all the technical details.

Requirements are king!

chris — Fri, 25 Jul 2008 04:50:01 -0700

I read a post on Eric Nelon's blog regarding Developers vs the "others". Eric is justifiably annoyed that various levels of managers expect:
-developers to do the managers' job as well as his/her own
-developers have to understand the end goal just as well as the managers
-developers have to agree with what the manager says, even if the developer's argument is backed up by facts
-developers have to accept that their needs are unimportant (course, books etc.), whereas managers go on whatever courses, conferences that are necessary

I think that the meeting of minds here should be achieved by defining requirements:
-agree requirements. This will involve both development team and management agreeing the end result. Not something vague - you need concrete bulet points, even if this is Agile development
-map the project plan to these requirements, breaking it down to individual work tasks

This will mean that both sides know what to expect. If the manager wishes to alter the requirements, then the developer can easily track which tasks need to be altered, and give a justified, detailed estimation of how much more time/resources will be needed. So often, I've seen unprepared developers bullied into accepting ridiculous timelines because they're not giving the full picture.

Unfortunately, there's just too little management of requirements in many projects. I've even heard people say "we don't define requirements, because we do Agile development". This is wrong - agile is all about defining requirements. See this post.

This is particularly relevant to security. If you define security requirements early (for instance, the roles/access matrix for the app), then this becomes a milestone on your project plan that the team works towards. If you engage with the security team late, then there's no management buy-in to that requirement. When you try to introduce it, you are seen as a blocker.

Security Wordle

chris — Tue, 15 Jul 2008 06:18:49 -0700

Decided to Wordle my blog. Glad to see that 'security' is prominent!

Next Generation User Group Fest 08

chris — Thu, 03 Jul 2008 05:55:36 -0700

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

chris — Wed, 11 Jun 2008 03:48:05 -0700

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.

Patterns and Practices for Securing WCF

chris — Mon, 09 Jun 2008 23:01:35 -0700

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.

Irish Microsoft Technology Conference

chris — Thu, 10 Apr 2008 12:39:33 -0700

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.

Next Gen Oxford Community Launch

chris — Tue, 01 Apr 2008 13:12:00 -0700

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:

Excess privilege

chris — Tue, 11 Mar 2008 14:36:23 -0700

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.

Production data and testing

chris — Wed, 20 Feb 2008 19:34:31 -0800

Testing is, perhaps, not the most exciting aspect for a security consultant. However, there have been some difficult issues commonly cropping up recently.

What data do you use for testing? A more difficult question than you would think.

You have to control access to production data, as in many instances disclosure could have serious legal and compliance issues. What if someone's personal data was taken and sold by someone who works in your development team?

The standard answer is to generate data by SQL scripts. Produce your own data, and there's no problem.

However, there are times when we need to use actual production extracts.

Some applications applying complex algorithms to business data (such as trading calculations) would need a spread of data similar to real ife, otherwise the algorithms could not be tested properly. In this instance, a process called sanitisation is often applied to production data extracts.

Sanitisation involves 'scrambling' any parts of the data that could be traced back to a person or organisation, so that it is unreadable. In a database table, the columns containing name and address of the client, for instance, would be scrambled, and all the other data (as long as it really unidentifiable, and one could not figure out details via aggregation of the other fields) could be left as it is. The spread of the data is true to life, but your compliance issues are satisfied.

If HMRC had used this when they had sent those discs through the post, then there would have been less risk of the names and addresses being compromised.

The algorithm used to scramble the data has to have a high degree of entropy, and have an element of randomness in it, so that the data cvan't be pieced back together again.

However, this doesn't solve everything. Some applications are reliant on others. In the banking world, you may have a payment system that needs data similar to production for testing. First option is to sanitise the data. However, the transactions may have to be reconciled against a number of systems. This would be problematic whether it's done manualy or through a batch process. For instance, how do you match organisation 'w4gbsdf435' against 'MetroBank' (the first is the sanitised version in your test app, the second is the name in the other app against which it has to be reconciled). So now you have to apply the same type of sanitisation against two or more different aplicatons? The randomness required in the algorithm is one of the problems here.

Bottom line is that you're going to have to manage the security of unscrambled production data in some applications. You're going to need to accomplish the following:
-check references of the people working on the development team when hiring
-apply access acontrols to all aspects of the application development. No more admin access for everyone
-make sure your dev environment is well segregated from other networks (either physically or logicaly)
-ensure someone is designated as the data owner
-work with the information security team of your organisation to ensure all possible controls are applied

Risk - what's your data worth?

chris — Sat, 16 Feb 2008 05:43:03 -0800

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.

MVPs galore

chris — Fri, 05 Oct 2007 08:41:50 -0700

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.

Next Gen UG goes international!

chris — Thu, 20 Sep 2007 11:59:06 -0700

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.

NextGen - Dave McMahon speaks on Office integration

chris — Wed, 22 Aug 2007 09:21:27 -0700

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.

Fame at last!

chris — Tue, 07 Aug 2007 03:51:18 -0700

I'm chuffed to bits to have one of my shots published as 'Photo of the Month' in Digital Camera magazine.

It's great to know that, just occasionally, I manage to click the shuter at the right time and in the right direction.

Please feel free to have a look at my gallery.

Chris Seary - LIVE!

chris — Tue, 07 Aug 2007 03:45:11 -0700

Carig Murphy has videoed my talk at DDD, and put it on the internet! Very strange to watch yourself speaking - I remember having to do this when I was doing teacher training.

Best to look at the slides as you watch. Enjoy!

Roger Whitehead speaking on Windows Mobile Development

chris — Mon, 06 Aug 2007 09:51:55 -0700

Last week's meeting saw Roger speak on a subject that's becoming increasingly relevant to all of us.

Roger not only has an incredibly strong, hands on knowledge of the subject, but he is also able to communicate across all levels on a very technical subject.

Here you can see Tim Leung at the front. Pay attention, Tim! Ignore the guy with the camera.

This was one of our best meetings yet at RM in Abingdon.

RM is one of our corporate sponsors. Roger works for Charteris, our other sponsor. Without these two organisations, we wouldn't be as successful as we are, and we very much appreciate their help.

More work for the developers and architects

chris — Tue, 31 Jul 2007 03:25:19 -0700

Hmmmmm......

Most of the time, when your application is accessing web services or databases, it's done within the same datacentre, right? This means that it's not a problem using network layer security (IPSec) to protect any data in transit across the network/subnet.

But what if you're accessing data across a MAN or a WAN? With the enormous bandwidth available now, this is happening more frequently. Also, what good's designing functionality as a service if it's only available to servers on the same subnet?

Well, the problem with applying network layer security is that accessing data across a MAN means that a huge amount of encryption power is required. Many hardware IPSec solutions become problematic and expensive as they reach 1GB.

Also, we've got MPLS to support over a fully meshed network, with the problems that may entail.

The result is that you, as a systems architect, may not be able to rely on the infrastructure people simply creating an IPSec security association for you.

That's right - security has made another step to the application layer. SSL should be fine, but don't rule out tools such as WS-Security.

No longer can architects rely on just annotating the link between the web app and the database with the words 'IPSec' and think that's enough.

And don't just think it's all covered by the magic words 'data security'!

What are you developing? I don't know, we do agile.......

chris — Tue, 17 Jul 2007 15:16:17 -0700

Ian Cooper, a developer who I respect very much, wrote an excellent article on agile and documentation. He states that documentation is clearly a part of agile development methodology.

Agile may favour lightweight documentation in many circumstances, but it is still a prerequisite. I've seen agile methods used very successfully with condensed documentation for a very large enterprise scale application. I've also seen agile used with very heavywieght documentation for a mission critical app using Telelogic DOORS.

One of the most annoying things in my current work, within a large Information Security team, is when a development team tell me "we don't have any documentation, we do Agile!". So how do we meet compliance requirements here, where we have to give assurance that standards have been applied to both process and application?
Well, I went to a conference recently where an agile evangelist declared that compliance is an outdated concept.

Fine. The bank I work for is thus outdated, as without compliance we're unable to trade.

Seriously, we use agile, and we do documentation. The agile team I mentioned earlier were told to go back and write some docco if they wanted their app to go live.

The point was that some people think that agile is an excuse not to do documentation.

I feel it's starting to go further than this. We're actually losing the practice of SOFTWARE ENGINEERING. Software engineering is where we do everything for a reason - all that we design, code, test is related to requirements.

Ten years ago, the 'software crisis' of increasingly unmaintainable code was attributed to programmers not introducing comments to their code. A couple of years ago, with some misinterpretations of agile, it became common to have applications developed without detailed design, component design etc.

I worked on a project last year where I was told that " we don't document requirements, because we use agile". Good grief! Agile is a methodology for MANAGING requirements. If you don't document them, then YOU CAN'T POSSIBLY BE DOING AGILE!

Where do we go next? In a few years' time, will we not even need someone to approve/describe a PROJECT before we start coding?

What are you developing? I don't know, we do agile.......

Royal International Air Tattoo

chris — Fri, 13 Jul 2007 12:05:12 -0700

The road's are choked up with traffic in our little village now, so we're housebound until Monday. That's the price you pay for being down the road from the Fairford airbase, which is hosting the world's biggest air show this weekend.

The nice thing is, we get to watch the whole thing from our back garden!

This is a fantastic event, and we've been watching the rehearsals today. I hope everyone who attends over the weekend has a great time.

Java is NOT the platform

chris — Thu, 12 Jul 2007 02:39:19 -0700

I've just been reading through a thread at Javalobby, where LINQ was discussed. The person who wrote the post was very open minded, but I was staggered by many of the the comments from Java developers. So many (about half) were dismissive of anything that Microsoft did, and they spoke about the Java language almost as though they were members of a cult.

One guy stated that 'While Java guys have only had one platform for the last ten years, Microsofties got nine! (soon to be ten)'.

There's a Java community view that the platform is abstracted away by the JVM, so you can port your app to any OS.

In my capacity as an IT Security consultant, I work on Java and .Net projects. When working on the security design for an application, one generally works with the technical architect to build security into the app. This inevitably entails many structural changes to the architecture.

Now, although there are a good number of excellent libraries in Java for providing security (such as JAAS for authentication and authorisation), much of the security for an enterprise application is in the implementation tool chosen. For instance, if you wish to secure a message bus, then you'd have to look at the documentation provided by WebSphere (or whichever product you're using) to know how to secure it. The security changes to the structure of the application are thus dependent on the OS and tools used.

So, the app is not independent of the OS in the case of enterprise applications that have to be secured. And that's that!

Splash of colour

chris — Fri, 06 Jul 2007 07:00:41 -0700

I think it's nice to have a photo or graphic on your blog - makes it so much nicer to look at.

My hobby/obsession is photography, so I thought I'd share with you one of my favourite pictures, taken soon after I bought my first digital camera.

If you'd like to see more of my photos, here's my gallery.