A Cornucopia of Threats and Solutions

Table 4-13 describes common threats you'll come across when designing your applications, possible mitigation technologies, and some of the disadvantages of using each mitigating technology, assuming the major advantage of each is the mitigation of the threat to some degree. The entries in the table are neither prescriptive nor exhaustive; their purpose is to whet your appetite and give you some ideas.

Table 4-13. Some Common Threats and Solutions
Threat	Threat Types	Mitigation Technique(s)	Issues
Access to or modification of confidential HTTP data.	T & I	Use SSL/TLS, WTLS (wireless TLS), or pos- sibly IPSec.	Need to set up the HTTP server to use a private key and a certificate. Configuring IPSec can also be a cumbersome process. Large performance hit when establishing the connection. Small performance hit for rest of the traffic.
Access to or modification of confidential RPC or DCOM data.	T & I	Use integrity and privacy options.	Might require code changes. Small performance hit.
Read or modify e-mail-based communications.	T & I	Use Pretty Good Privacy (PGP) or Secure/ Multipurpose Internet Mail Extensions (S/MIME).	PGP is not easy to use. S/MIME can be hard to configure.
A device that contains confidential data might be lost.	I	Use personal identifi- cation number (PIN) on device. Lock out after too many attempts.	Don't forget the PIN!
Flood service with too many connections.	D	Provide throttling based on, perhaps, IP address. Require authentication.	IP address checking will not work correctly through proxies. Need to give users accounts and passwords.
Attacker attempts to guess passwords.	S, I & E	Use increasing delays for each invalid password. Lock out after too many attempts. Support strong passwords.	Attacker might create a DoS attack by guessing and then force the account to lock out so that a valid user cannot access her account. In which case, lock the account out for a small amount of time, say, 15 minutes. Need to add code to enforce password strength.
Read confidential cookie data.	I	Encrypt cookie at the server.	Need to add encryption code to the Web site.
Tamper with cookie data.	T	MAC or sign cookie at the server.	Need to add MAC or digital signature code to the Web site.
Access private, secret data.	I	Don't store the data in the first place! Or perhaps try using an external device to store the data. If that won't work, consider hiding the data on a best effort basis, leveraging the operating system. Use good access con- trol lists.	Can be a difficult problem to solve. Refer to Chapter 9 for information.
Attacker spoofs a server.	S	Use an authentication scheme that supports server authentication, such as SSL/TLS, IPSec, or Kerberos.	Configuration can be time consuming.
Attacker posts HTML or script to your site.	D	Limit what can be posted using regular expressions.	Need to define appropriate regular expressions and determine what is valid input. Refer to Chapter 10, All Input Is Evil! for information.
Attacker opens thousands of connections but does nothing with them.	D	Expire oldest connections, using a scoring algorithm. Admin connections do not time out.	You'll waste time perfecting the scoring algorithm.
Unauthenticated connection can consume memory.	D	Require authentication. Treat unauthenticated connections with dis-dain; never trust them. Be aggressive, and never allocate lots of resources to an unknown connection.	Need to support authentication and impersonation in your application.
Your data packets can be replayed.	T, R, I & D	One approach is to use SSL/TLS, IPSec, or RPC/DCOM privacy to hide data. However, you can also enforce a packet count or timeout on the packets. Do this by appending a time- stamp to the packet in the clear text and hashing the timestamp with the MAC on the packet. When the recipient software receives the packet, it can deter- mine whether the packet is time worthy.	Can be tricky to get right. But it's worth the effort!
Attacker attaches debugger to your process.	T, I & D	Restrict which accounts have the SeDebugPrivilege privilege.	Refer to Chapter 7 for more information.
Attacker gains physical access to hardware.	S, T, R, I, D & E	Physical security. Encrypt sensitive data, and do not store key on the hardware.	Never a fail-safe solution.
Attacker shuts down your process.	D	Authenticate all admin-istrative tasks. Require local administrator group membership to shut process down.	Need to perform Windows NT style access checks in code. Refer to Chapter 23, General Good Practices, to learn about checking for group membership correctly.
Attacker modifies configuration data.	S, T, R, I, D & E	Authenticate all con- nections accessing the data. Strong ACLs on the data, and support digital signatures.	Signing the data can be time consuming and difficult to implement.
Error message leaks too much information and helps an attacker learn what to do next.	I	Don't tell the attacker too much. Give a brief synopsis of the error, and log the real error in a log file.	Valid users get poor messages, which might lead to support phone calls.
In a shared workstation environment, an attacker accesses or uses data cached by a previous user.	T & I	Don't cache sensitive data for example, anything provided to the user using SSL/ TLS or IPSec.	Can inconvenience valid users.
A malicious user accesses or tampers with lookup data on the Web server.	T & I	Use file-based encryption, such as EFS. Make sure the encryption keys are secure from attack.	Keeping the encryption keys secure is a complex task. EFS in a domain environment is more secure than in a stand-alone environment.