email article printer friendly more resources

Secure and Manage Windows Server 2003
Follow these recommended procedures to secure and manage the Windows Server 2003 Framework.
by Nils Odhner

Tech Ed 2003 Issue

Securing your enterprise infrastructure to ensure business uptime and maximum productivity is a chief concern. To make certain your enterprise is secured properly, you need to get basic sever security in full check. When you consider that security isn't traditionally something you can implement in your Web infrastructure or enterprise network out of the box, maintaining a high level of security can be a challenge.

Fortunately, Windows Server 2003, which was released this past April, will alleviate many of the headaches associated with securing your Windows-based enterprise, from the server to the application to the desktop, end-user level. By leveraging the newest features of the Windows Server 2003 and following a few simple security policies, your enterprise will be more secure—and profitable.

Securing and managing the many applications on your systems effectively isn't a simple task. It can be even more difficult to implement a secure system when an insecure application resides on the system. However, the .NET Framework has undergone rigorous development in recent months, and allows you to secure your system through the use of managed code, as dictated by Common Language Runtime (CLR) security rules.

Control Managed Code
Your programmers and software developers play a large role in securing the .NET platform throughout the enterprise, using the CLR security rules. Essentially, executing CLR along with managed code is a "structural precept" of eminent importance in developing a secure .NET application platform.

First, the programmer verifies the managed code to ensure type safety. Once verified, the server accepts the code as a 4-byte value, whereas the server will reject a call with an 8-type parameter as not type safe. The managed code verification process catches most common programming errors before they can sabotage the application platform. Also, common vulnerabilities, including buffer overruns and reading arbitrary memory, will no longer occur. The code that end users run is checked before it's executed, and your developers will be thankful they can now develop error-free code, devoid of the common bugs that have traditionally plagued the development of your Microsoft enterprise platform.

As an additional measure to execute managed code smoothly, developers can now use code access security (CAS) if an assembly method needs permission to access a resource. The code acts as a permission granter, initiating a stack walk to enable the CLR to check that each assembly in the call-chain has requested permission. This process prevents attacks where malicious code tries to trick legitimate code in other assemblies, and it rejects attempts to bypass security restrictions.

Imperative and declarative permission checks are two vitally important mechanisms your development staff must use in securing the .NET platform. Imperative checks request demands to override components of the stack walk operation through runtime method calls to the core security engine. Declarative checks, on the other hand, are implemented as customized security features, evaluated when compiled, and embedded in metadata. These two mechanisms allow developers to run protected, embedded code, which prevents intruders from exploiting the makeup of executed managed code.