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'!

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.......

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.

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!

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.

Data access moves on - LINQ for SQL and other technologies such as Hibernate can allow data access logic to be moved out of the database and into the application tier. Those of us with a dba background may recoil in horror, but I'm starting to accept that we have a new paradigm here, and we have to adjust.

There are mixed feelings – how can database access be tuned if the queries are taken away from the database? I don’t mean execution plans here (DLINQ is quite efficient in that respect), but rather implementation of proper indexes. If you don’t index properly, your million dollar SQL cluster scales down to a very expensive version of Access 2.0.

What happens when you have locking problems? A DBA can ensure that stored procs always access tables in the correct order. That dba won’t be able to look into your code.

In any case, the move is being made, and it’s proper to accept that we have to make the new paradigm work, rather than argue against it. The solution is to find new practices and patterns to allow this to work.

So, we move on to security. The traditional model, using stored procedures within the database, offers the following security advantages:

Defence against sql injection attacks – using command parameters prevents execution of rogue sql strings

 

Least privilege and segregation of duties are enforced at a more granular level

 

Table level permissions do not have to be granted

Granting execute permissions to stored procedures means that the security model is that of allowing exactly the access we wish to grant. Compare this to the execution of dynamic sql, where we have to validate against every possible attack that might occur.

How secure is LINQ to SQL? An article by Jason Schmitt demonstrates the parameterized queries created by the LINQ infrastructure can prevent SQL injection. Use of the sp_executesql command certainly prevents injection attacks of this type.

What about the granting of CRUD access to tables within the database? Well, here’s an issue.

The role based security at the database boundary breaks down. We lose some granularity of least privilege and separation of duties as we access the server.

Granting correct table/column access directly to tables becomes incredibly complex when you have more than perhaps three roles. The greater the complexity, the more prone to error your security strategy is.

Sprocs allow access to be restricted to certain rows, via joins and where clauses. Table access doesn't do this. Although you can restrict which rows you access in your LINQ code, you've lost that security granularity at the database server level. What if an internal user downloads the SQL utilities to his/her desktop?

There’s a way to work with this.

It seems that flowing the security context is probably going to be ruled out in applications that use LINQ to SQL. To have the flexibility to allow developers to put data access logic within the code, a fair few table permissions would be required.

A rogue user downloading, say, the SQL Management tools would be able to disrupt database activities due to the security barrier at the database server being relaxed.

What about a trusted subsystem approach? Database access would be restricted to an application, and the application would have to enforce the appropriate access to tables. This would mean granting the necessary access to a role that the application service account belongs to. And don’t think that means you can put the account into the dbo role!

This is the security context in which many web apps work, and is not exactly rocket science. It’s quite effective.

However, it will mean a change for Windows Forms apps that run in the context of the logged on user. You may have to write a component running in a separate process on the database server to handle data access, rather than just use the SQL provider to access directly. The Windows app would then access the component, perhaps via a web service. The Windows front end would stay dumb.

At the moment, this is more of a ‘thoughts of Chairman Chris’ rant, but perhaps it’s the seed of so far unwritten best practice. Please give me your thoughts, and perhaps we can achieve something more solid.

I had a fantastic day yesterday at DDD5 at MS Reading TVP. Thanks to everyone who organised this event. It had great presentations and a fantastic atmosphere.

I was pleased to have a full house for my talk 'Ten Top Tips for Securing Web Applications'.

Here are the slides and the code. Hope you enjoyed my talk if you were in Everest yesterday!

I'm now an independent IT consultant, specialising in application security. I've worked on securing many enterprise scale web applications, such as the Scottish Schools Digital Network and the Australian Taxation Office Business Portal.

My qualifications include

MVP Security

CISSP

ISO 27001 (BSI 17799) Lead Auditor

MCSD.Net

MCDBA

Network+

Here is a link to some of my security articles on MSDN. Here are the slides from various presentations that I've given.

If you need consultancy for securing your applications, please contact me on christopherseary@hotmail.com.