What are the best security controls and design patterns?

Question

There are many safety recommendations to tell programmers what not to do. What, in your opinion, is the best practice that should be followed when coding for good security?

Please add the suggested security / design control template below. The proposed format is a bold title that summarizes the idea, followed by a description and examples, for example:

Reject Default

Deny anything that is clearly not allowed ...

Please vote or comment on the improvements, and do not duplicate the existing answer. Please also put various templates and controls in your own answer, rather than adding an answer with 3 or 4 preferred controls.

edit: I create this community wiki to encourage voting.

Answer 1

The principle of least privilege - the process should contain only those privileges that it really needs, and should retain these privileges only for the shortest necessary time. So, for example, it is better to use sudo make install than su to open a shell and then work as a superuser.

Answer 2

All of these ideas that people list (isolation, least privilege, white list) are tools.

But first you need to know what “security” means for your application. Often this means something like

• Availability The program will not be able to serve one client because another client sent bad data.
• Confidentiality The program will not pass one user data to another user.
• Isolation . The program will not interact with data that the user did not intend to use.
• Review The program, obviously, functions correctly - the desired property of the vote counter.
• Safe Way : The user knows which entity they are interacting with.

Once you know what security means for your application, you can start developing around this.

One design practice, which is not mentioned as often as it is, is the facility .

Many secure systems must make authorization decisions - if this piece of code can access this file or open a socket for this machine.

Access control lists - one way to do this is to specify files that can be accessed. However, such systems require significant maintenance costs. They work in security agencies where people have permissions, and they work in databases, where a company deploys a database, hires a DBA. But they do not work well for secure end-user software, as the user often has neither the skills nor the inclination to constantly update lists.

The capabilities of the object solve this problem by making decisions about access to copying via object links - using all the work that programmers already do in well-designed object-oriented systems to minimize the amount of authority that any single piece of code has. See CapDesk for an example of how this works in practice.

DARPA conducted an experiment to develop secure systems called the DARPA Browser project, which found that a system designed in this way, although it had the same error rate as other object-oriented systems, had a much lower vulnerability to exploit . Since designers followed POLA using the capabilities of the object, it was much harder for attackers to find a way to use the error to compromise the system.

Answer 3

White list

Choose what you know you accept

(Yes, I know this is very much like "deny the default", but I like to use positive thinking.)

Answer 4

Threat to the model before making security design decisions - think about possible threats and how likely they are. For example, if someone steals your computer, most likely with a laptop than with a desktop. Then be alarmed by these more likely threats.

Answer 5

Limit the "attack surface". Provide your system with as many attacks as possible using firewalls, limited access, etc.

Answer 6

Remember physical security. If someone can take your hard drive, this may be the most effective attack of all.

(I recall the exercise of the red invasion team, in which we appeared with the clipboard and the official form, and left with the entire "safe" system.)

Answer 7

Encryption & ne; security.

Answer 8

Reuse verified code

Use proven encryption algorithms, cryptographic random number generators, hash functions, authentication schemes, access control systems, and not create your own.

Answer 9

Hire Security Professionals

Security is a specialized skill. Do not try to do it yourself. If you cannot afford to agree on your safety, then at least hire a professional to verify your implementation.

Answer 10

Set security from the start

It is much easier to get security if you add it to an existing system.

Answer 11

Insulation. The code must have strong isolation between, for example, processes, so that failures in one component cannot easily compromise others.

Answer 12

Express risk and danger in terms of cost. Money. He miraculously concentrates the mind.

Answer 13

A good understanding of the basic assumptions about crypto blocks can be important. For example, stream ciphers, such as RC4, are very useful, but can be easily used to create an insecure system (i.e., WEP and the like).

Answer 14

If you encrypt your data for security, your keys will be the most important data in your enterprise. Lose your keys and data will be lost; compromise the keys and all your data is compromised.

Answer 15

Use risk to make security decisions. Once you determine the likelihood of various threats, think about the harm that everyone can do. Risk by definition

R = P _e × N

where P _e is the probability of a lower event, and H is the danger, or the amount of harm that may result from an undesirable event.

Answer 16

Separate problems. Archive your system and create your own code so that protected from critical components can be stored together.

Answer 17

KISS (Keep It Simple, Stupid)

If you need to make a very complex and difficult argument in favor of why your system is protected, then it is probably unsafe.

Formal security constructs sometimes refer to a thing called TCB (Trusted Computing Base). But even an informal design has something like this - a part that ensures the security of your code, a part that you cannot but rely on. It should be well encapsulated and as simple and small as possible.