Category list

.NET Development Security Solutions - page 30

Summary

This chapter has presented some of the human error issues you need to consider for your next coding project. It’s shown you how many of these errors creep in because developers lack time or simply don’t think about code from a cracker’s perspective. Once you see some of the exploits presented in this chapter, it becomes painfully obvious that none of them requires a rocket scientist to figure out—you just need to think outside the box.

Now that you’ve spent time looking at these human error issues, it’s time to create a hit list of your own. One of the best ways to produce more secure applications is to use a checklist to ensure you have all of the bases covered. Of course, this isn’t the only step you need to take, but many developers leave this step out of their plans for any of a variety of reasons. Good security begins with a standardized and measured approach to maintaining application quality.

Chapter 4 shows how to use various rule-based security approaches to maintain a secure environment for .NET applications. It pursues a detailed description of some of the relevant .NET Framework namespaces and demonstrates the differences between declarative and imperative security. You’ll also see techniques for testing your desktop application. Chapter 4 also covers essentials such as using the .NET Framework Configuration Tool and signing your components and applications to make it harder for people to tamper with their content.

Part II: Desktop and LAN Security

Chapter List

Chapter 4: .NET Role-Based Security Techniques
Chapter 5: Policies and Code Groups in Detail
Chapter 6: Validation and Verification Issues
Chapter 7: .NET Cryptographic Techniques
Chapter 8: LAN Security Requirements

Chapter 4: .NET Role-Based Security Techniques

Overview

Defining the Differences in .NET Role-Based Security
Detecting Permissions with the Permission View Tool
Working with the .NET Framework Configuration Tool
Developing Applications that Use Declarative Security
Developing Applications that Use Imperative Security
Creating a Secure Registry Environment
Creating a Secure Desktop Application Installation
Developing Managed Components and Controls
Testing Your Desktop Application

The vast majority of the non-code security problems that you’ll encounter are user oriented because users are unpredictable and they don’t follow rules particularly well. Users cause problems by writing down their passwords, believing crackers performing social engineering exploits, and downloading materials that look interesting, but contain deadly code. However, a program is essentially useless without a user. Why write something that someone can’t use to perform useful work? One of the ironies in life is that the applications designed to service user needs are the very applications that require the greatest protection from the user.

Note

Social engineering is an extension of psychology where the cracker exploits a common human attribute such as curiosity to obtain useful information, convince the user to comply with specific requests , simply use the person as a tool for breaking into the system. You can find an excellent paper on the topic of social engineering at http://www.securityfocus.com/infocus/1527 .

This chapter won’t show you how to control users—that’s impossible . While it’s true that training can help users become more aware of the consequences of their actions, it’s very hard to convince a user to apply the training they’ve received unless the user is willing to do so. (A good whip can also help, but don’t let human resources catch you in the act.) However, this chapter does show how you can use role-based security to reduce the risk to applications, resources, and data from users by giving the user access based on the role they must perform. In some cases, the chapter also discusses how you can attempt to mitigate some of the problems that stem from less reliable and dependable users. For example, you can issue some types of access based on the user’s ability and willingness to use the access carefully . In many cases, you can base your assessment of the user’s behavior on their historical pattern of use.

You’ll also learn a few code access techniques in this chapter. These techniques relate to the use of code access to offset some of the problems that role-based security can’t address adequately. If you can’t keep the user from creating a security breach, perhaps the code can at least make the security breach less severe or even prevent it from occurring in the first place. Code access security is an essential tool in the war on security problems. You really do need to combine both security techniques, along with good coding practice, to achieve a secure system. (Make sure you read about the problems developers have in Chapter 3 before you judge the user too harshly based on this introduction—developers can play a big part in security problems too.)