March 2008 - Posts
ConfigSource attribute on system.serviceModel section
The configSource attribute was firstly introduced in .NET framework 2.0 to support external configuration files.
This attribute can be added to any configuration section to specify a an external file for that section. Using an external configuration source can be useful in many scenarios. For instance, you could place a section into an external configSource if you need an easy method to swap settings for the section depending on the environment (development, test, or production), or you need granular control over permissions.
Unfortunately, the system.serviceModel section group does not support this attribute. If you try to add it, you will receive the following exception:
The attribute 'configSource' cannot be specified because its name starts with the reserved prefix 'config' or 'lock'
"configSource" attribute is a property comes from the section Information class.
Every ConfigurationSection in .net framework 2.0 configuration scheme system
has a property of a section Information where the config source is declared.
you can use this attribute on the different sections under system.serviceModel such as services, behaviors or bindings.
For instance, the configuration file could look like this,
<services configSource="Services.config" >
And then, each file contains the corresponding section.
<!-- this endpoint is exposed at: net.tcp://localhost:9000/servicemodelsamples/service -->
<!-- the mex endpoint is exposed at http://localhost:8000/ServiceModelSamples/service/mex -->
<transport clientCredentialType="Windows" protectionLevel="EncryptAndSign" />
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="False" />
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.GetMaxThreads(out iMaxThrds, out iThrdCompletionPT);
ThreadPool.SetMaxThreads(Environment.ProcessorCount * 50, iThrdCompletionPT); ThreadPool.GetMaxThreads(out iMaxThrds, out 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.
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
The moment we have been waiting for so long had come:
Web Service Software Factories for VS2008 was released
Download and enjoy
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:
Goal: Describe what is threat modeling, and how it should be implemented.
- 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
- 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.
- 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.
- There are numerous check lists to use. These will assure you that you did not forget anything.
- 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.
- 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.
Another method to identify threats is to use attacks classification.
Attacks were classified into 6 groups.
- All the attacks in which someone uses someone else identity in the system.
- All the attacks in which someone changes some information without permission.
- 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)
- 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.
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:
- 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
- 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.
Threat modeling book:
MSDN Threat Modeling