Spliting WCF config files

ConfigSource attribute on system.serviceModel section

Increase the numbers of threads in the Threat Pool

If you have used the ThreadPool in .NET 1.x, you know that the threadpool defaults to ( 25 * number of processors ) threads per process.  It can be changed, but it is kinda complicated to track down how to change this.  Well, MS has made changing the threadpool to make this easily changeable.  Here is some example code:

ThreadPool.SetMaxThreads(Environment.ProcessorCount * 50, iThrdCompletionPT);

For .Net 2.0 / 3.0 

The first time that ThreadPool.GetMaxThreads is called, the value I recieved is 25, which is what I would expect from a system with 1 cpu.  I then call back to SetMaxThreads with the value of 50 times the number of cpus.  when I make the second call into ThreadPool.GetMaxThreads(), i get back the value of 50.

 So, if you have exhausted your threadpoll threads, this is a way to get more threads into your threadpool.

One thing that I want to mention, this will not change the number of threads that are used by the threadpool.  If the threadpool still thinks that you don't need any more threads, then you won't really get anything by increasing the number of threads in the threadpool.  This is only going to be useful if you have depleted the number of threads in your threadpool.

Use caution when changing the maximum number of threads in the thread pool. While your code might benefit, the changes might have an adverse effect on code libraries you use.

Setting the thread pool size too large can cause performance problems. If too many threads are executing at the same time, the task switching overhead becomes a significant factor.

For .Net  3.5

ThreadPool.GetMaxThreads(out iMaxThrds, out iThrdCompletionPT);
will return 500 for  iMaxThrds and 1000 for iThrdCompletionPT (for 2 cores processor)

This is amazing !!! So If your machine runs .Net 3.5 you do not have to increase the thread pool...

The primary reason for this change was to minimize the possibility of deadlocking the entire thread pool.  Apparently, the CLR team has been receiving many support requests from customers who have used all the thread pool threads for tasks (such as processing ASP.NET requests) and deadlocked while waiting for these requests to complete. 

For example, consider a parallel processing pipeline in which task N1 runs and then waits until task N2 completes, which runs and waits until task N3 completes and so forth (N1...NP).  If there are more tasks (P) than thread pool threads, the thread pool will eventually deadlock.  Introducing more thread pool threads means statistically reducing the frequency of a deadlock

While it is true that each thread consumes stack memory, it's not committed memory but reserved memory only.  Which means that 500 threads are not actively using 500MB of physical memory; they are reserving 500MB of virtual memory and actively using only a tiny part of it (perhaps even a single page per thread).  This is definitely not a problem on 64-bit because the virtual address space is practically infinite; on 32-bit, the reservation itself might be problematic and hence you might want to tune the behavior.

manu 

Promos for the TechEd in Eilat

You can listen today to the best promos of the best session of TechEd 2008

Alon Fliss - From ORPC to Services

Sasha _ Next Generation Production Debugging

Sasha Again - What can visual studio do for you

Manu (Myself) - Odysea to SOA

Tomer - Data Binding in WPF

Noam King - Sexy Web Development with ASP.Net MVC and Dynamic Data Controls  

Enjoy

Manu

Web Service Software Factories for VS2008 is here

The moment we have been waiting for so long had come:

Web Service Software Factories for VS2008 was released

Download and enjoy

manu 

Threat Modeling summary

Threat modeling is the heart of any application securuty design.

I am often being asked about threat modeling so I wanted to write about it:

Enjoy:

Threat Modeling

Goal: Describe what  is threat modeling, and how it should be implemented.

Terms:

• Attacker - Someone who could do harm to a system
• Threat - An attacker goal
• Vulnerability - A flaw in the system that could help an attacker realize a threat
• Mitigation - Something to do to protect against a threat.
• Attack - The process in which attackers takes advantage of a vulnerability
• Asset - Something of value to valid users vendors and attackers

Background: Application security is too complex to implement without a clear methodology.

One of the subject's most important methodology is the SDL - Secure Development Life Cycle.

An important part of the methodology is the Threat modeling which is the heart of the design phase.

Why Threat Modeling

Understand the motivation for threat modeling.

The Economic side of Threat Modeling

• It is easy to spend an endless amount of money on application security.
  Threat modeling should define the security objectives of the software and thus can help to control the budget spent on application security.

What should be protected?

• It is common that only in the threat modeling phase the company understands what are its assets. Understanding that there assets to protect is a key element is threat modeling.

Understand the attacks.

• It is well known that for a secure design you have to think out of the box, think like an attacker etc... but by the end of the day you do not know what to do. No one knows ALL the attacks. You can never cover everything...
  Threat modeling will helps you by creating a systematic method to review you system.

Not everything should be protected.

• Threat modeling takes as an assumption that "There is no and there will never be a perfect system that is protected against everything.
• It is the designers decision where to protect and where not to. What to secure and what to leave as is.
• One of Threat Modeling Goals is to prioritise security-related efforts

Everyone uses the outcome of threat modeling.

• The threat modeling outcome will be the basis for design decisions and documents.
• It will be used in the implementation phase (before writing code the programmer should read it)
• The threat modeling outcome will be the basis for the security test plan .
• Using the Threat modeling the developer can understand why the designer told him to use a certain Technology

From past experience approx 50% of security issues come from threat models

Threat Modeling Stages

 Identify Assets

• Ask yourself the following questions to figure out what are the assets you need to protect:
• What is most important to the end customer (the customer of your customer)
• What is most important to your customer
• What is most important to the vendor (you)
• What / who can damage the above
• What does the law / regulation tells you to protect

Create an Architecture Overview

• Look at the system you designed so far. This phase tells us that threat modeling cannot be done before initial design was achieved.
  Only after you have a view of the overall design you can think of threat modeling.

Decompose the System

• Threat modeling should be done on the "whole" system to enable a "Holostic (global) view" of the system but it must also be done on specific modules as well.

Identify the Threats

• After you know your assets. You know your system globally and specifically you can start identifying threat.
• There are different methods of how to do that

Document the Threats

• There are many threats. They must be documented. This documentation will be used later to identify the threats that will be mitigated

Rate the Threats

• Not all the threats can be mitigated form practical reasons (budget)
• Threats must be rated so only the important ones will be chosen to be mitigated.

Plan Mitigations

• For each threat that was chosen to be mitigated, the technology to implement the mitigation must be chosen.

How to identify threats

There are different methods of how to do the main part of the threat modeling phase.

Check lists.

• There are numerous check lists to use. These will assure you that you did not forget anything.

Brain storming

• They say that threat modeling is like penetration testing on the design. Take the relevant architects and designers put them around a round table and start "breaking" the system. Make them think like an attacker. A lot of value will come out of this meeting. Try to break their assumptions taken in the initial design.

Tools

• There are tools like "Microsoft Threat Analysis & Modeling v2.1" that can help you create a list of threat. You enter the high level design of the system into the tool in a Visio like diagram and the tool outputs numerous threats.

DFD - Data Flow Diagram

• A DFD is a great diagram from which you can extract a list of threats.
• The DFD shows where the data flows inside the system.
• Data is the most valuable of all. Understanding where the data flows can ease the process of indentifying threats.
• Make sure the DFD is not too specific. DFD level 0, level 1 and level 2 are usually enough.

Attacks classification

Another method to identify threats is to use attacks classification.

Attacks were classified into 6 groups.

Spoofing

• All the attacks in which someone uses someone else identity in the system.

Tampering

• All the attacks in which someone changes some information without permission.

Repudiation

• All the attacks in which someone denies a transaction that was performed. For example someone deny a purchase order after receiving the merchandise and denying the payment)

Information Disclosure

• All the attacks in which someone gets to see information she has no right to access.

Denial of Service

• All the attacks in which someone breaks the system and prevent it from working normally and supplying the service it should. The fact that the system does not work can serve for the interest of the attacker (or the one who sent him).
  There a numerous ways to implement such an attack.

Elevation of Privilege

• All the attacks in which someone enhance its capabilities by raising its privileges. For example: The attacker manages to get administrative rights.

Rating Threats 

It is very difficult to rate threats.

Finding an absolute scale to rate threats is nearly impossible as rating is a subjective matter.

The DREAD scale was designed to help.

In the DREAD scale we ask the following questions:

• Damage - How great can the damage be?
• Reproducibility - How easy is it to get the potential attack work?
• Exploitability - how much effort and expertise is required to mount the attack?
• Affected users - How many users will be affected?
• Discoverability - How easy is it to find the vulnerability?

For each question we answer with:
1 - Low    2 - Medium   3 - High

We sum up to divide the threats into 4 groups:

• Critical
• Important
• Moderate
• Low

Threat Trees

• A graphical representation of security-relevant pre-conditions in a system
• First outlined in Amoroso's "Fundamentals of Computer Security Technology"
• Based on hardware fault trees
• There are many "threat tree patterns"

Using threat trees it is possible to create patterns that we can use to search for threats and Vulnerabilities.

Each leaf is a secondary threat to be evaluated

1. Plan mitigation

After the threat was identified and rated mitigation should be planed. The following options are possible:

• Leave as is. The threat is not important enough to be mitigated. There is no money for the mitigation etc.
• Remove the feature that contains the threat from the product.
• Remedy with technology countermeasure
• Warn the user. (Must be done with care as most users do not have the knowledge to take good security decisions.

If technology mitigation was decided the proper technology for the project should be chosen. For example to prevent information disclosure SSL can be chosen but it is not always the right choice.

The phase of security design is out of scope of this document.

Resources:

Threat modeling book:
http://www.microsoft.com/MSPress/books/6892.asp

MSDN Threat Modeling

http://msdn.microsoft.com/security/securecode/threatmodeling

http://msdn.com/threatmodeling