Design with security and safety in mind

Don't assume that you will be able to add security or safety to your software as an add-on after it is finished or - worse - released. These are not features of a program, but properties that emerge from the way the software product is designed and built. They are also influenced by the environment where the program runs, such as the operating system and the type of network. For many programs, porting them from one operating system to a different operating system requires a careful examination of security-related aspects. Moreover, your decisions on the cryptographic algorithms to use, their parameters, the length of the cryptographic keys, etc., should depend on the nature and value of the information that you want to protect and on the way this information is used.

Design for quality

It is a good idea to develop your application following a rigorous methodology for high-quality software. As an example, the Radio Technical Commission for Aeronautics (RTCA) DO-178B standard provides guidelines for the production of software to be used in airborne systems and describes many techniques and methods appropriate to ensure the integrity, reliability, and safety of such software. This standard is general enough to be useful in assessing the quality of many other kinds of applications.

Use formal methods and languages

Formal methods can be used at all stages of a software development project. Different methods and languages cover different aspects of a software system, from requirements definition to system specification, down to low-level design and implementation. The main benefit to using formal methods and languages is the ability to exploit tools to verify the correctness of the system description at each abstraction level. Moreover, each of the resulting descriptions can be manually reviewed and checked against earlier, higher-level descriptions to ensure consistency as details are progressively added. All this helps to eliminate ambiguities and limit the introduction of defects at each stage, and makes it easier to identify and remove any existing defects as early as possible.

Limit software complexity

Complexity is an enemy of security and safety, so it should be limited as much as possible. Given a set of requirements for an application, good design methodologies can help reduce the complexity of the software product.

Ensure that all the operations (both normal and exceptional) in your application are safe and secure

Your application should always behave in a secure and safe way, both when it is operating normally and when it is handling exceptional conditions. Unfortunately, certain systems become less safe or less secure when they are reacting to a failure. This should be avoided. Actually, a system that becomes insecure when handling exceptional conditions cannot be considered secure at all. An example of a well-known methodology for assessing the safety of systems is "Fault tree analysis". Fault tree analysis is a top-down approach to the identification of process hazards, aimed at systematically identifying and graphically displaying the many ways something can go wrong.

Use only well-known cryptographic algorithms

Whenever there is a need to implement confidentiality and integrity in your application, it is always better to use an established cryptographic algorithm than invent your own algorithm. No cryptographic algorithm can be mathematically proven to be resistant to all possible attacks (current and future), so the only way that an algorithm can be considered secure enough is by relying on the existing community of cryptography experts, who scrutinize algorithms and are often highly motivated to discover weaknesses in them.

Don't assume that you can increase security by keeping the source code of your algorithms hidden

Not providing source code can help protect your interests as a software vendor, but it is hardly effective in protecting any secrets that may be embedded in your program. Attackers are often very able at reverse-engineering machine code and reconstructing "hidden" algorithms. Sometimes this reverse-engineering is not even necessary. Certain cryptographic algorithms, used by well-known applications, have proved so naive that crypto-analysts were able to reproduce them just by observing the program's behavior. Hiding the source code of a poor cryptographic algorithm doesn't make it any more secure. Again, it is much better to rely on a well-known algorithm.

Don't rely on the users of your application to select the appropriate (more secure) security settings

Few people bother to read manuals or to play with the configuration. Common users are non-proactive and system administrators are often too busy to do these things. If the secure modes of your application (for example, encryption) are not set by default, most users will never be aware of their existence and will never enable them. The result is that your application will needlessly run in an insecure mode on most systems. So in general it is better to enable security by default and require positive action to disable it.

Verify exchanged digital certificates and involve the user as much as possible in this process

When using public key cryptography and receiving a certificate from a third party, make sure your program checks the certificate against your trusted certificate files and certificate revocation lists, and provide the user with the ability to view the third party's certificate. The program should be able to ascertain the identity of the third party automatically in most cases, otherwise it should display the third party's certificate to the user (with clear warnings and instructions) whenever appropriate.. You shouldn't simply rely on the user requesting the display of the certificates , as most users won't remember to do such a thing even if they are aware of the potential risks (for example, the web server they are talking to may not be what it says it is or what it looks like).

Limit the internal data redundancy and manage the existing redundancy

Document all the existing dependencies among the data managed by the application and include in your design specific operations that verify the consistency of these data.

[ Table of Contents ]