Beginning Visual Basic 2005 (2006)

Appendix B

Managing Tradeoffs

To complete a successful project, you must be able to manage tradeoffs. You will find very quickly that your customer will ask you questions of the form “. . . Can you do that?” And your answer should be in almost every instance, “Yes, we can.” You will find that you can do just about anything. The problem is that it takes a certain amount of time and money for every project or change request. What your customer means to say is; “Can you do that for $50,000 by the end of this year?” So when you answer the “can it be done” question, make sure the customer knows that you can do it for the right price with enough time.

When you work with clients, internal or external, you have to make them aware of project tradeoffs. There are three tradeoffs (budget, deadlines, and functionality). A fourth tradeoff could be quality. You should never consider reducing quality to lower price, finish sooner, or add features to make a project successful. While you define the project scope, make sure that the project team and customers understand the priorities of tradeoffs. As you make changes to any one tradeoff, you will have to adjust at least one of the others.

For example, suppose you are working with the marketing department on a small application. You are the only resource available to work on the solution for the next two weeks during planning. While you are gathering the system requirements, you speak to the marketing vice-president, Tina, about the priorities of the solution. Very quickly she makes it clear that she needs the application by the end of the year and for a cost of under $50,000. As you pry more, you find that Tina cannot spend more than $50,000 this year. She wants the system to be live in three months with at least the core functionality in the first version. Next year, she may be able free up more money in her budget to finish the lower-priority features.

You quickly write down the tradeoffs to consider and the priorities. In order of priority, you write budget, deadline, and features. Take a look at the project priorities listed in Table B-1. You and Tina sign off on the tradeoff priorities, and now you know how to make the solution a success. Meeting the budget and deadline are required for success. For example, functionality will be moved to the next version if the project gets behind schedule.

Table B-1: Project priorities

Halfway through the project, Tina wants to add more core functionality to the system. You look at the budget and see that if you add more functionality to this release, you will need more resources to make the deadline. Adding another developer to meet the deadline will cost an extra $10,000. Looking back at the project priorities, you see that Tina cannot spend more than $50,000. You have set aside the entire $50,000 budget, and $10,000 more is too much. It is time to call Tina and explain the situation.

736

Implementing the Microsoft Solutions Framework

While talking to Tina, you explain the top priority for the project is budget. Adding the extra functionality will cost an additional $10,000, bringing the budget estimate to $60,000. During the discussion, you mention that the only way to add more functionality without increasing the deadline or budget is to drop some of the functionality already planned. After 30 minutes, she agrees that $50,000 is all she can spend, and the additional functionality can be part of a later version.

By understanding and agreeing on tradeoff priorities, you are able to work with customers to manage change. If a customer wants to change any of the tradeoff priorities, you will have to adjust one or both of the others.

Defining Success with the MSF

A successful project is hard to achieve. If you follow the framework, success can be achieved more easily. It all comes down to customer satisfaction and one simple question: Did you make the customer happy? This simple question can be hard to answer. Let me clarify how to find the answer to this question. To make the customer happy, you must succeed in most of these four areas; achieve system goals, meet release date, stay under budget, and manage trade offs.

With the Framework implementation, you will find defining success possible. The two milestones that are straightforward are meeting the budget and release date. Take a look at the project plan and make sure these milestones were met. System goals are also straightforward if you defined measurable goals. Test the system against the project goals to verify the system meets the standards agreed upon. The final milestone is change or tradeoff management. Pull out the final tradeoff chart and review it. For the project to be successful, you must have met the top priority of your customer. Changes may have caused you to miss the other milestones, but if you managed tradeoffs with the customer, the project will still be successful. Success can be that simple if you follow the game plan.

Summar y

As you grow in the information technology field, you will work on larger projects and have more responsibility. Use this appendix as a basis for further study. Always keep in mind how many steps you have to take to be successful managing a project. When you do get into a position to lead a project, take the time to plan and test, and always work toward making the customer happy. You will not always be successful by following the framework, so take misfortunes in stride and learn from them. As you complete projects, you will come up with your own interpretation of the SDLC or the MSF, and you will be a success.

737

Appendix C

Take a look at another example of a software bug that might be a security risk. Say you wrote an assembly or Web Service that would upload files to your company’s Web site. This application is for salespeople to upload comma-separated files of current sales data each night. The code allows the path and file name to be passed as parameters, and it can be used by numerous departments because of this flexibility. The problem is the flexibility allows a hacker to upload a Web page, place it into the root Web directory, and do almost anything to the server or network. You should change this Web Service to store files in a locked-down directory and modify the file name so that an attacker would not be able to access the file by name. Functions like this one are prevalent in many companies’ code libraries and create most of the security holes these companies will face.

In this appendix you will learn about security issues and how to handle them within the following topics:

Understanding Code Access Security

Secure Sockets Layer (SSL)

Where to look for security answers

Code Access Security (CAS)

The goal for Code Access Security is simple: Stop unwanted code from running or accessing resources. This is accomplished by the runtime’s security system. When an assembly needs access to a resource, all assemblies on the call stack should have permission to access that resource. Take a look at the following example.

An assembly is run from the Internet. By default, it is granted access to a permission set (explained in the next subsection) based on the Internet zone. The application has no access to the local file system. If that assembly were to call a public method on an assembly that did have access to the file system, the runtime would throw a security exception. When the permissions of each assembly on the stack were tested, the assembly that was run from the Internet would fail the permission check.

On the other hand, an administrator could grant a signed assembly more permissions. So, if this assembly had the correct digital signature, it could be granted access to a larger set of permissions.

CAS allows the system administrator to apply permissions to code rather than to users. Before CAS, if a hacker could get a user to run code or an attachment that contained a virus, it was granted security based on the user’s security level. If that user was an administrator on the machine, the virus had full access to do its dirty work. Now, a virus may be stopped by the Common Language Runtime and not have access to corrupt the file system, even if the user has permissions.

The way this works is through permissions, security policy, and evidence. When an assembly requests a file, for example, the runtime makes sure that file is available from a security aspect by checking permissions, security levels, and evidence. Let’s start with permissions.

740

An Introduction to Security

Permissions

Permissions are granted to resources based on trust and origination. Administrators can grant higher or lower levels of access to individual assemblies or zones. Here is a list of six common permissions used by the runtime.

EnvironmentPermission: Access control for system and user environment variables

EventLogPermission: Event logging control for code access permissions

FileDialogPermission: File system access control for file dialogs

FileIOPermission: File system access control

PrintingPermission: Controls access to printers

RegistryPermission: Controls access to the Registry

It would be hard to manage a large group of permissions without a way of grouping them. Grouping permissions is accomplished by using permission sets. The .NET Framework has of six predefined permission sets. You can use any of these sets listed here in your code.

Nothing: This named permission set will not allow code to run.

Execution: The Execution set allows the code to run, but no access is granted to protected resources.

FullTrust: The most forgiving permission set. Access to all resources is granted.

Internet: You can think of this as the access you would permit when browsing. This would be used when running code from the Internet or any nontrusted source.

LocalIntranet: This is for trusted code running on a trusted network.

Everything: This is a set of all standard permissions. The permission to skip verification is not granted to this set.

Your code can request any level of permission, and the runtime will verify before running the code that these permissions will be granted.

Security Policy

The runtime enforces policy based on the identity or evidence of the assembly. When loading an assembly, the assembly is inspected for evidence of its origin. Based on the origin, the runtime determines what permissions to grant the assembly.

Evidence

To determine the origin of an assembly, the CLR looks at many attributes of the assembly. This is known as the evidence. Table C-1 has a complete list of evidence types. The runtime may use any or all of these to determine the permissions to grant the assembly.

741

Appendix C

Table C-1: Types of Evidence

When permissions are tested, an intersection of zones and permissions is evaluated to verify that all permissions for every zone and assembly on the stack are met. If permission is not granted to the code, the zone, or the user, an exception is thrown and access is denied.

Secure Sockets Layer

Secure Sockets Laye (SSL) was a protocol developed to secure communication between a Web server and a browser. Today, 128-bit SSL encryption is the standard for secure data transmission over the Internet. If you need to secure parts of a Web site, your customers will expect this type of encryption. To promote the level security to the end user, Internet Explorer and Netscape display a locked lock similar to Figure C-1 at the bottom of the browser window.

Figure C-1

Another way users know a site is secure is by the URL. Looking at the URL of a SSL site shows https:// versus the standard http://. The user can also look at details of the certificate by double clicking the lock icon or viewing the page’s properties or info. Figure C-2 is an actual certificate info screen from a large Web site. We have removed the company’s name from the image.

Two of the largest companies that issue SSL certificates are Thawte and VeriSign. They are both well respected in the industry and offer free trial certificates for you to test with.

Trial certificates can be found at the following site.

verisign.com/products-services/security-services/ssl/index.html: Click the Try link for the certificate type you wish to try.

thawte.com/: Click the link for a 21 day trial.

742

An Introduction to Security

You should keep in mind that encryption slows down the experience for the user and creates more load for the server. Keep marketing and nonessential areas of your site unencrypted. Only encrypt pages that communicate data that would be considered private.

Figure C-2

Finding Answers

I will list some Web sites that can be helpful to do more research and find answers.

microsoft.com/security/: Microsoft’s security home page. Read the latest is security notes about Microsoft products.

microsoft.com/security/guidance/checklists/: Microsoft’s security checklists. Here you can print checklists to make sure your applications consider the appropriate security risks.

ftc.gov: The Federal Trade Commission Web site. Here you can see what types of scams are being reported.

owasp.org: Open Web Application Security Project (OWASP). This site has free tools, documentation, and standards available.

sans.org/rr/: The SANS Institute Information Security Reading Room. Read thousands of white papers on security issues.

webappsec.org: The Web Application Security Consortium. Read white papers on the latest news about Web site security.

743

Appendix C

Summar y

Security is the hottest topic in the information technology industry. Making applications 100 percent secure is not possible with the openness of the Internet, but minimizing risks to vital data should be a top priority in application design. As you build applications with VS 2005, know that you have the best tool available to create secure Windows applications, but it is your responsibility to maintain the security of the applications you write.

Administrators will be able to use CAS to stop many types of attacks. Being able to apply permissions to assemblies and validate the origination of the code makes implementing a secure network easier. The widespread use of certificates and code signing will make spoofing applications more difficult and keep users’ computers safer.

The world of application security is by no means perfect. You will probably have to design your applications around security risks forever. But you can win by keeping security at the top of the priority list in your application design. Soon you will begin to develop applications for wireless access, and more security implications will need to be understood. Keeping applications secure in a world where information access is expanding will continue to be a challenge.

Just make sure you keep your head up and pay attention. Security holes are announced throughout the media, and as a developer, you should pay attention and learn from the mistakes of the past. One of your applications may one day be under attack.

744