No Site Is Secure without Monitoring

Build Secure Apps — and Keep them Secure

Secure ASP.NET

LANGUAGES: ALL

ASP.NET VERSIONS: 2.0

 

No Site Is Secure without Monitoring

Build Secure Apps and Keep them Secure

 

By Don Kiely

 

Version 2.0 of the .NET Framework contains a slew of new security features. The new authentication and authorization features, such as membership management, get all the attention as sexy new features and they deserve it, because they provide common infrastructure that we ve had to implement over and over again in earlier Web development technologies.

 

It always amazes me to go into a client s office and explore with them all the great features they ve built into an application using these sexy features, only to discover they don t do any auditing or monitoring of the application. They know that they built a rock-solid, secure app, so what s to monitor?

 

What s to monitor?!? Listen, I ve been saying this for years to clients and students: If you re not monitoring an app, IT IS NOT SECURE. Period.

 

Here s the problem. Hackers are clever people, and they are constantly devoting their considerable talents to coming up with new ways to attack your app. No matter how bulletproof you build the app, unless you monitor it constantly you have no idea whether it is being probed for weaknesses, no idea that some junior developer changed one seemingly inconsequential web.config setting that opened a big security hole, no clue that your site is undergoing a brand new kind of attack (they almost always leave subtle traces that you can detect), no idea of any of the many early warning signs that almost always accompany a full-on attack.

 

Let me be very clear: Monitoring is crucial to the security of an application. You have to build it well and then watch it carefully to make sure that it stays secure. This usually means some combination of event logging and notifications. And, YOU HAVE TO LOOK AT THE LOGS! I m sorry for all the shouting in this column, but I ve also seen people set up elaborate logging to monitor an app (often way over-engineered), then never look at the logs, or have notification e-mails redirected automatically to an Outlook folder that they never read.

 

This is not a secure application.

 

Fortunately, ASP.NET 2.0 has a slew of new features that can help you monitor an application. They fall under the general category of health monitoring features. Essentially, ASP.NET health monitoring is a set of standard events and providers that can log or take other actions in response to an event. It also exposes the infrastructure so that you can create custom events and take some unique action in response to an event. Combined with log analysis tools (the subject of another column some day), this can provide you with some great information about the ongoing security of your application.

 

At the end of this column I ve listed a few references where you can get all the nitty-gritty details of health monitoring. If you re familiar with the Provider pattern and how events work in the .NET Framework, you ll pick it up quickly. As described in the VS 2005 documentation, here is how the health monitoring events are generated and fired:

  • When an application starts, ASP.NET builds a merged collection of configuration settings. If you have defined providers and events in the configuration files (mainly web.config), those events are included in the merged collection.
  • Some kind of monitored event occurs, such as when it detects a brute force authentication attack.
  • ASP.NET looks at what events you ve configured (or those for which you have not changed the default).
  • If the event is being listened for, ASP.NET builds an instance of the Web event class specified and raises it.
  • Your defined event provider consumes the event and creates a log entry, sends an e-mail, or whatever the provider is supposed to do in response to the event.

 

ASP.NET 2.0 provides a lot of great tools to build secure apps and keep them secure. It takes a little work, but the rewards are so very worth it. Do It Today!

 

What Happened to the .NET Configuration Tool?

If you ve used the .NET Configuration Tool to configure code-access security policy, you might be dismayed to find that in some installations of .NET the tool is nowhere to be found. That s because you re looking at a machine with only the .NET redistributable installed. Specifically, the .NET Framework SDK is not installed on that machine. For security reasons keep non-essential security-related utilities that aren t necessary for everyday operation off a machine the tool has moved to the SDK. Shawn Farkas of Microsoft has the details on the .NET Security Blog at http://blogs.msdn.com/shawnfa/archive/2006/02/08/527663.aspx.

 

References

 

Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at http://www.sqljunkies.com/weblog/donkiely/.

 

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish