Security Testing

[Silver]

Figure 2.3 provides good understanding about what should our security target be. Since the more we go to the right of that scale affects performance, usability, time, and money, is there a way experienced programmers use to assess security if stringent or lax or to see the actual effect on performance, usability, time, and money once a site is fully developed but prior to officially launching it, or shortly after launching? In other words, are there some tests done, the results of which make the developer increases or decreases security levels?

[Larry]

Interesting question. There's no simple test, though, as each situation is so unique. Let's look at the four factors I mention in detail: performance, usability, time, and money. As for performance, what I normally do is develop to the required level of security first, then adjust other things to improve the performance when necessary. The fact is it's not that hard to improve a site's performance (through hardware or software changes) but trying to improve the security after having a security violation is a bad spot to be in. As a general rule, I would be aware of performance compromises being made but base decisions on the security level required. For example, HTTPS is more secure than HTTP, but requires a lot more of the server (to a magnitude of 12, on average). But sometimes you need HTTPS and sometimes you don't. Without any test, it's easy to make this choice. The same goes for using a hashing algorithm to represent stored data or actually encrypting and decrypting it. The latter is slower, but if you need to retain information in an encrypted format, you have no choice.

 

Usability vs. security is something you'd have to discuss with the client. In sites where the user expects the highest level of security (such as online banking), the user will also expect, if not demand, a more complex UI because they know, intuitively, that there's a relationship there. It should not be simple to move money out of my checking account online.

 

Time and money are related, of course, and also need to be discussed with the client (i.e., yes, we can take those extra security steps but it will cost more). Personally, I would never accept a job that doesn't have the budget to implement the right amount of security, because that reflects poorly on me.

 

As you can tell, in my mind, these aren't things you test when the site is fully developed and about to launch, but are decisions to be made before writing a line of code. Always develop to the level of security required by the project. Then, when you've got the site about done, you can benchmark and tweak the performance where applicable, without adversely affecting the level of security. That's how I see it anyway.