By Malcolm Gin
Consultant

Secure web application design is not product-specific: it is helpful in securely designing and implementing any Web application, regardless of the platform. This article, part of a series of security-related columns for the Macromedia Designer and Developer Center, is primarily intended for developers and application architects, but many of these concepts are relevant to any application development cycle, including non-Web applications.

What is the 'Security Mindset'?

• Risk Assessment
• Policies
• Platform Research, Modular Architecture and Delegation (Layering)
• Validation (Formal Trust)
• Vigilance

Bear in mind that individual links are provided for reference; they may not be applicable to your specific architecture or configuration. Be sure to carefully check whether the procedures suggested or described apply to your configuration before implementing them. Also, be sure to test any change to your current configuration or process in a testing environment prior to applying them in any production environment.

What is the 'Security Mindset'?

The ideal security architect is very cautious, even paranoid, diligent, suspicious, obsessive-compulsive and impossibly humble. In reality, they tend to be a little more human - which can be both a good and a bad thing - but in terms of ideal qualities, this description is closer to the truth than you might prefer to think.

Generally, it's a good idea for a security specialist to be suspicious and aggressively inquisitive about new things. She should be suspicious enough so that she'll feel comfortable prying into how new things work, how inherently secure new tools are, and how much she can trust these new things to keep her data safe. She should also be cautious about programming, configuration, and implementation, both her own and others'. Being this way helps her keep her edge, stay alert, and helps her identify and analyze subtle and tricky situations. It's often said that the same kinds of people who automatically case every store they enter, but never use the knowledge to steal, are perfect for the security field.

The security world demands vigilant discipline. Security, on the largest level, can easily slip through the cracks without the constant combined effort of many determined, perceptive minds paying attention to design and implementation. Passing data from one application or storage medium to another can easily threaten data safety and security. Unless architects for both applications and storage drivers pay careful attention to well-designed security protocols, no one but the perpetrator might be the wiser about data theft.

Most security vulnerabilities occur in areas of coding and design where secure design or implementation has lapsed. Sometimes the lapse comes from ill-considered design, sometimes it is the product of a rushed implementation, and sometimes it's the product of designer or developer arrogance. Regardless of how lapses occur, these vulnerabilities are consistently the most popular - and most devastating - openings for attacks. Attention to detail, combined with intelligent and careful design, can do a great deal to improve the security of every byte. This is a vital element of the security mindset.

An additional important aspect of the ideal security architect's mindset is humility. This trait can be in direct conflict with pride in all the knowledge and experience the ideal architect earns, but humility is her most important personality trait. Humility allows her to learn from other security-oriented experts and mentors. With humility, the security architect will seek peer review of her designs and implementations, and research secure starting points and design methodologies to round out her careful and meticulous planning.

Risk Assessment
Risk assessment should be among the first steps in your design process, and will help you frame your further efforts to design a secure system. Making risk assessment a priority will also help you make sure your executive officers are both informed about and integral to the beginnings of your securely designed project. During the risk assessment phase of design, you may find important supporters and champions among the executive officers: you should actively recruit their participation if they're not already involved.

Business majors and MBAs already know about the managerial aspects of risk assessment. This methodology is heavily used in most business plans, especially with respect to business planning. Risk assessment is no less important in secure, well-designed software or applications development projects. Take advantage of the fact that your managers and executives are probably already familiar with risk assessment methodology. Armed with a common language and methodology, you can inform your managers of the relative risks to which the application exposes you or your customers, and you can additionally leverage their involvement and buy-in. This will help you in the end: if there should ever be an attack on your application, you will already have a champion to go to bat for the integrity of your application and the care with which it was designed.

The basic steps of risk assessment are as follows:

1. Identify protected resources
2. Assign relative value
3. Identify possible attackers
4. Estimate relative frequency of each kind of attacker
5. Carry out attack tree analysis / Identify possible attack routes
6. Protect all possible attack routes / Protect most likely attack routes

For each resource, assign it a relative value (i.e. your customer credit card database will probably be more valuable than your vendor contact list). Next, identify possible attackers. Frequent examples are the bored teenager, the disgruntled ex-employee, the corporate spy, or the government intelligence agent.

Estimation of the skill, frequency and methods of the attacker all belong to a related process to risk assessment which Bruce Schneier calls 'attack tree analysis'. This process helps to formalize what's otherwise a significantly subjective process of analysis and assessment, and can help prioritize your project's security goals. (For more about attack trees, see chapter 21 of Bruce Schneier's book: Secrets and Lies: Digital Security in a Networked World, a highly-recommended resource on all aspects of digital security.)

Once you know what routes or attack you should be protecting (from your attack tree analysis), you already have organized information about the kind of security you will need to implement in your design. You may also find that this information will be helpful in writing security and privacy policies to accompany your application design efforts.

Please be very careful when carrying out your own research about risk assessment. It is very easy to confuse this process with another process, usually called 'security assessment'. A risk assessment is a process that people undertake (sometimes aided by organization-enhancing software) to determine risks surrounding their specific efforts. On the other hand, there are many software tools available for security assessments that will analyze your network and servers for known vulnerabilities. (Three tips for using these kinds of software tools: 1) research the producing company carefully so you will be sure you can trust them with the necessary access privileges before setting the software up on your network, 2) test the tool in an isolated testing environment before applying it, and 3) strongly consider petitioning your internal Information Technology department or Help Desk for permission to run this kind of tool on your company's internal networks.) Security assessment tools can be useful, but cannot be 100% effective, and though they may help you do risk assessment for extant problems with existing software, they will not be able to do the job for you in regard to designing and developing new software and applications.

The process of risk assessment is part of the security and auditing professions as well as being a common topic in MBA coursework. For more information about the topics of risk assessment and starting points in further research, please see the links provided below.

These links are provided for reference only and may not be applicable to your architecture or configuration. You are responsible for ascertaining whether any procedure suggested or described applies to your configuration, and for testing it in a testing environment before implementing it.

• Fred Cohen & Associates Web site
• Fred Cohen & Associates Auditors Checklists and Other Audit Information
• The Information Systems Audit and Control Association & Foundation Web site (see especially their Global Information Repository)
• Microsoft's Security and Privacy for Businesses
• AUSCERT's Improving Computer Security through Network Design

A policy, aside from giving you the ability to reassure your customers by publishing it on your Web site, will help you think out and plan your application design specifically with security in mind. Each time your requirements change, someone on your team should be responsible for reviewing the policy with executive team members and seeing to necessary changes in the document. This makes it easier to effect changes in your code that honor and protect your security policy's requirements.

Policy is more important than you may think. One of the more subtle but pernicious causes of security and privacy policy violation within a company comes from changing business requirements in the middle of a development cycle, or after an application has been deployed. For example, imagine a hypothetical company that makes its money from advertisement revenue generated by draw from downloads of top 40 song tracks. They start out with a solid privacy and security policy, but during their web application development, this hypothetical company switches business plan to a partnership with a tape and CD mail-order store that draws potential customers with preview song tracks. The hypothetical company's revenue now consists mainly of getting a cut of sales.

In this kind of situation, not only might earlier privacy policies be potentially violated if mailing lists and other customer contact information were shared with the new partner, but the previously secure architecture could be hacked to pieces for the sake of facilitating the new partnership. For example, suppose the hypothetical company above ended up having to modify its secure distributed architecture, opening more liberal access from the Internet so that the new partner could access the back-end databases. This sort of hasty change to architecture and application happens a lot more often than it should in order to accommodate the quickly shifting technology market, sometimes with disastrous consequences. One systematic way of reducing the chances that this will happen to your company is to make sure that policies are always considered, updated and designed in parallel with the applications to which they apply.

If you have time and resources to carry out this kind of effort, it is worth it. Security does not happen spontaneously, and it requires careful thinking and planning to design and implement security well. Policies can help bridge the gap between risk assessment and implementation. Again, Bruce Schneier's Secrets and Lies is a useful resource on this topic. For other resources, see the links below.

These links are provided for reference only and may not be applicable to your architecture or configuration. You are responsible for ascertaining whether any procedure suggested or described applies to your configuration, and for testing it in a testing environment before implementing it.

• Network Security Library's Policy section
• Computer Security Resource Center's Policies and Example Policies
• SANS Reading Room: Security Policy Issues

From this point of view, each module of the machine comprises a layer. It can be a bit tricky to visualize properly, and there's usually a lot of debate about how to divide any particular system, because each system architect visualizes the borders differently. From a high level, if you visualized the layering of a server, one person might divide it into categories of mandatory and optional hardware, drivers, and software, whereas another might divide it up into functional roles, like input, storage, display, processing and output.

The reason that layering is important -- no matter how you slice it -- is that ignoring it is incredibly facile and common. We all have a tendency to think that we can implement a certain function better than the people who came before us. However, in doing so, we may be compromising carefully designed security architecture that supports existing functions.

Delegation is very important in design and development. Ideal security architecture efforts involve doing research about the systems on which your applications and architecture are based. Once you know your platform(s), you delegate, and simply let it do its job. Trying to outthink and out-code your platform can have disastrous results.

Security specialists who do implementation earn their stripes. Successful developers who do security-related coding learn proper implementation by experience, enduring many years of failures and criticism. If security is your priority, and it should be, then you should respect the experience that these skilled specialist developers have invested in the platform by using their implementations wherever you can. This means that you should delegate functions in your application to pre-existing layers in your platform, and circumvent existing implementations provided by your platform only when there is no other choice.

The other important aspect of layering is that if done correctly, your properly secure implementations allow other programmers and developers to rely on your application (layer) to keep their data safe. This means that if you get data from somewhere else, it becomes your job, from a layering standpoint, to handle that data securely: making sure the data is protected from prying eyes or processes.

These links are provided for reference only and may not be applicable to your architecture or configuration. You are responsible for ascertaining whether any procedure suggested or described applies to your configuration, and for testing it in a testing environment before implementing it.

Note: Some of the links below are highly technical sources.

• Carnegie Mellon Software Engineering Institute's Essays on Software Architecture
• END-TO-END ARGUMENTS IN SYSTEM DESIGN
• Active Networking and End-To-End Arguments
• An Open Operating System for a Single-User Machine
• Macromedia Technical White Paper Secure Web App Development with ColdFusion 4.0
• Other research terms related to this topic are: 'information hiding', 'layering', 'modularity' and 'modular architecture'.

The simple summary of validation and its relation to the security term, 'formal trust', is that security professionals have a formalized process of defining and analyzing the act of trusting a person or thing.

This sounds like a foreign concept to those new to security. After all, most people just do a boolean equation with trust: "Do I or do I not trust something or someone?"

Security specialists, on the other hand, have a formal process for identifying what entities should be trusted. This formal trust carries no social or personal meaning. If a security process or specialist doesn't trust you, it doesn't mean that she thinks you are personally untrustworthy. Generally, it simply means that she has procedurally determined that your policies and procedures are not stringent enough for the formal trust standard she uses.

This process means that formal trust is very closely related to policy. Security policies often define what requirements must be satisfied for a certain resource or entity to be trusted. This means that the specific policies that define any company's formal trust process are mutable, and may depend strongly on the requirements set forth by that company's legal, executive and marketing departments.

But back to validation: what we learn from formal trust is that unless incoming data comes from a 'trusted resource' (a resource that passes all the tests of formal trust set forth by the policy), that data is not trustworthy. If data are not trustworthy, then validation is required.

Validation simply means verifying that input is what it says it is or is what it is supposed to be. If your application is expecting name and address information, but it gets SQL commands, for instance, it is remotely possible that the SQL commands can and will be executed in the middle of a CFQUERY call. A validation mechanism in your application, on the other hand, would check for and filter out SQL-specific characters and strings before passing the data to the CFQUERY tag.

These links are provided for reference only and may not be applicable to your architecture or configuration. You are responsible for ascertaining whether any procedure suggested or described applies to your configuration, and for testing it in a testing environment before implementing it.

• Macromedia Security Bulletin (MPSB99-04): Multiple SQL Statements in Dynamic Queries
• Macromedia Security Best Practice: Validating Browser Input
• CERT® Advisory CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests

As a web developer, you do not have to be directly involved in the war, but it behooves you to monitor the situation. One of the best ways to monitor security as it develops is to subscribe to vendor notification services. If you have time, subscribing to security discussion lists is very helpful, but many of such discussion lists are very high-traffic. If you find you do not have time to keep up even with the vendor notification services, however, you may want to consider contracting a security consulting firm to help you track risks and plan appropriate responses.