David Boschmans' Weblog

SecurityChecker complaints

Tim Weaver is definitely not happy with DevPartner SecurityChecker 1.0, Compuware's new product designed to detect security issues in ASP.NET applications. Me too, I had some issues, though not the ones Tim is complaining about. Anyone listening from Compuware technical support?

Here are some tips if you're struggling with the performance of SecurityChecker.

SecurityChecker takes a long time to complete analysis. How can I reduce the Analysis time?

Several factors contribute to the analysis time:

Application Size – How many projects are there in the Solution
The size of your application is a determining factor in how long the analysis will take. If you have many projects within your solution, consider analyzing each project separately. You can do this by manually navigating the application using Manual discovery, or by modifying a discovery map to only analyze certain pages within the application.

Number of ASP.NET pages being analyzed
If your application contains many pages, consider using Manual discovery and limiting the session to specific pages.

Number of functions on each page being analyzed
If there are data grids on the pages of your application, integrity analysis (specifically) will take a long time to run. To effectively analyze the application it is important to test for vulnerabilities in the grid. Be advised that this will take time.

Automatic or Manual discovery
Because Automatic discovery is designed to test all aspects of your application, it will take a long time on large applications. Consider using Manual discovery to limit the parts of the application analyzed, or consider running each type of analysis (Compile-time, Run-time, and Integrity) individually.

Automatic Discovery Session Settings
If running with the default settings is producing long analysis times, you can reconfigure the Automatic discovery settings. These settings may have an affect on the analysis time.
Use the SecurityChecker Settings dialog to reconfigure the settings. Open the settings dialog from the SecurityChecker menu:SecurityChecker -> Settings -> Discovery Map.In the “Automatic Discovery Map” section there are “Link Visitation Limit”, “Crawl Depth” and “Maximum Links per Page” settings.

By default, the values are:

Link Visitation Limit – 2 visits
Crawl Depth – 10 levels
Maximum Links per Page - 25

By decreasing the values of these settings, analysis time will be shortened. Most often, it is the Crawl Depth setting that has the most affect.

Type of Analysis being run
There are 3 types of analysis that can be run in SecurityChecker; Compile Time analysis, Run Time analysis, and Integrity analysis.

Compile time analysis is the quickest to complete.
Run time analysis generally does not take long to complete.
However, because SecurityChecker Integrity analysis simulates extensive attacks on your application, this type of analysis can take a while to complete.

If all 3 analysis types are selected, the session will take longer to complete. If the application being analyzed is large, running only 1 session type at a time will reduce the time to complete the analysis.

The total number of Vulnerabilities / Rules being analyzed
By default, all of the Rules are selected to be checked during a SecurityChecker session. If you are reusing a discovery map you can select only certain Vulnerability categories and Severities to be used in the next session. Selecting one severity or category per session will reduce the analysis time.

Thoughts on Enterprise Library and its dependencies

Tom Hollander, one of the product managers working for the Microsoft patterns & practices group, started blogging.
As he's currently spending most of his time on Enterprise Library, he asks for your input: how would you like to see dependencies managed in future versions of the enterprise library?

Today all blocks have two dependencies:

• one to the new Configuration Application Block (includes the configuration tool), and
• one to the Common assembly.

Currently these are included in the Enterprise Library package. But once - and I expect pretty soon - Microsoft and the community start to build their own blocks and block libraries, managing the dependencies - allowing updates and versioning of the Config block - should be easy to do. Tom lists a number of ways this could be done:

1. Make every new block or block library dependent on Enterprise Library. These blocks and libraries do not include the Configuration Application Block or Common assembly, so they will not work unless you install Enterprise Library first
2. Include any dependencies (Config block and Common) with every new block and block library. Enterprise Library is not a prerequisite for any block or library, but it is possible that people will end up with multiple versions of the dependencies installed at once (possibly even different versions)
3. Break out the Config block and Common out of Enterprise Library and ship them as a new "Core" library. The next version of Enterprise Library wouldn't include this core functionality. Every block and block library, including Enterprise Library, needs the core to work
4. Same as #3, but we ship the core, as a separate MSI, with every deliverable. People can choose to install or not install the core, but they always get it zipped up with every block or library.

I would go for the third solution: breaking them out of Enterprise Library and ship the Configuration Block and Common assembly as a new "Core" library. The major advantages I see are:

• once the "Core-library" has been installed, no reinstall (distribution) is by default needed. Of course, if new functionalities were added a reinstallation/redistribution is necessary. 
• the Configuration Block can be (re)used for other (community) projects without using Enterprise Library.
• the Enterpise Library and its contained application blocks can evolve separately from the "Core-Library".
• a loosely coupling between both, will make the building of scenario-specific application blocks (Smart Client & Service-Oriented-Apps) more easy.
• ... Other?

Which would you like to see? Can you think of any other options that may work well? Have you dealt with this issue on any of your own projects or open source projects? Let Tom know!

[Updated January 29^th] The lastest release (January 2005) of Microsoft Patterns & Practices Enterprise Library is available for download.

Fault-injection with DevPartner Fault Simulator & Holodeck

I recently got some feedback and a lot of mails on my blog post that announced the general availability of DevPartner Fault Simulator. A lot of people are interested to find out what the differences are beween Compuware's DevPartner Fault Simulator and Security Innovation's Holodeck.

I have been using Fault Simulator for more than 2 months now and (only) recenly I also gave Holodeck a try. That said, I have a far better idea of Fault Simulator capabilities than Holodeck's one. So don't consider this list with differences as an official Compuware vs Security Innovation comparison or statement and feel free to correct me if I'm wrong. I love to hear your thoughts!

Holodeck and Fault Simulator utilize fault-injection techniques to emulate real-world application errors and scenarios. Both tools test and debug error handling code without disrupting the operating or debugging environment by safely injecting simulated faults into the application code. The simulator “tricks” the target application into believing a fault is present and the reaction can be monitored. Any other running applications are not effected. The results of a simulation show how the error handling code works in the application.
This way IT & QA people are able to ensure correct feature functionality as well as how their application will respond to an error condition. In most cases, error handling code is ignored and is neither debugged in development nor tested by QA. Catastrophic production failures occur and the results are undesirable and costly.

Some of the errors that these tools report are:

• include bad parameters (user inputs incorrect data into a form on a web page),
• operating system errors,
• environmental problems (lost network connection, server offline, disk full, etc.) 

How well an application responds to a fault is controlled by an error handler. With best practices, developers should create error handling as they are developing feature code. With these tools developers verify the functionality of the coded error handlers. This way issues are addressed earlier than in a production environment.

Some of the differences I noticed between both tools:

• Holodeck is a stand-alone tool. Fault Simulator integrates with the Visual Studio .NET IDE, which allow developers to seamlessly test and verify their error handling code during development. However Fault Simulator also has a standalone UI which facilities use by QA testers. Through this UI, Fault Simulator can be used as a diagnostic tool for applications already deployed in production.
• Fault Simulator simulation results can lead a developer directly to the line of source code where error handling was exercised.
• In Fault Simulator developers can simulate and use debugging tools simultaneously.
• Fault Simulator captures detailed results giving the developer a complete view of  error handling within the application.
• In Fault Simulator source code highlighting allows developers to quickly identify where errors handlers are required in their code.

Both have common key features:

Belgian Geek Dinner

The third Belgian Geek Dinner, which took place last Friday, was great fun. Some good food, a lot of drinks, many interesting talks etc. Thanks Roy for organizing it! As far as I know the following Belgian bloggers were there: