Gail Shaw wrote:
> 
> In addition to Andrews Rule 1 and 2... (and note that I am not an expert in
> security by any means)
> 
> The importance of good error checking, handling and reporting. Way too many
> hacks are possible because the program does something unexpected in an error
> condition (buffer overflow) or reports far too much info to users in the
> case of an error.
> 
> Password and key management. Possibly covered by your 'don't use predictable
> secrets'. Emphasis on how hard this really is to do properly.
> 
> Don't trust user input. A subset of your "don't execute code from untrusted
> users" This covers SQL injection, XSS, buffer overflows and probably more.
> 
> Use the principle of least permissions. The picture editing software does
> not need admin rights on the machine. The web app does not need to connect
> to the db server as sysadmin.
> 
> Defend in depth. Always check multiple times at different levels. Assume
> that the level above has been compromised. Similarly, harden the OS you're
> running on. A secure app on a vulnerable OS is like a castle on wet sand.
> 
> Always work on the assumption that you will be hacked and that the hacker
> knows your system. Security through obscurity doesn't work, and hoping you
> won't be hacked is a poor defense
> 
> It's scary how little some know. I was at a local MS event last year and the
> speaker (who is a security guru) was showing off some simple exploits. From
> the response of the audience, I would guess a large portion had never seen
> buffer overflow working before, and this was a room of several hundred, all
> IT people, most professional developers.
> 
> 
 I was about to post a similar reply; here's a snippet of it:

Client-side security doesn’t work.
You cannot securely exchange encryption keys without a shared piece of
information.
Malicious code cannot be 100 percent protected against.
Any malicious code can be completely morphed to bypass signature detection.
Firewalls cannot protect you 100 percent from attack.
Any intrusion detection system can be evaded.
Secret cryptographic algorithms are not secure.
If a key isn’t required, you do not have encryption—you have encoding.
Passwords cannot be securely stored on the client unless there is
another password to protect them.
In order for a system to begin to be considered secure, it must undergo
an independent security audit.
Security through obscurity does not work.

John

-- 
I will be brief but not nearly so brief as Salvador Dali, who gave the
world's shortest speech. He said, "I will be so brief I am already
finished," then he sat down.

Post a reply to this message