From Wikipedia, the free encyclopedia

Security engineering is the field of engineering dealing with the security and integrity of real-world systems. It is similar to systems engineering in that its motivation is to make a system meet requirements, but with the added dimension of enforcing a security policy. It has existed as an informal field for centuries, in the fields of locksmithing and security printing.

Security Engineering is the discipline of developing detailed engineering designs for security systems. Typical qualifications to be considered when interviewing a security engineer are Chartered Professional Engineer, ASIS CPP, ASIS PSP, BICSI RCDD. There is a need for appropriate licencing for security engineers (this differs from country to country).

Technological advances, principally in the field of computers, have now allowed the creation of far more complex systems, with new and complex security problems. Because modern systems cut across many areas of human endeavor, security engineers not only need consider the mathematical and physical properties of systems; they also need to consider attacks on the people who use and form parts of those systems using social engineering attacks. Secure systems have to resist not only technical attacks, but also coercion, fraud, and deception by confidence tricksters.

For this reason it involves aspects of social science, psychology and economics, as well as physics, chemistry and mathematics. Some of the techniques used, such as fault tree analysis, are derived from safety engineering.

Other techniques such as cryptography were previously restricted to military applications. One of the pioneers of security engineering as a formal field of study is Ross Anderson.

Contents 1 Security Stance 2 Sub-fields of security engineering 3 Methodology 3.1 Patterns & practices Security Engineering 4 Articles and Papers 5 See also 6 Further reading

A security stance is a default position on security matters.

Possible security stances:

"Everything not explicitly permitted is forbidden" (default deny) -- improves security at a cost in functionality. This is a good approach if you have lots of security threats. See secure computing for a discussion of computer security using this approach.

"Everything not explicitly forbidden is permitted" (default permit) -- allows greater functionality by sacrificing security. This is only a good approach in an environment where security threats are non-existent or negligible. See computer insecurity for an example of the failure of this approach in the real world.

• Computer security
• Physical security
• Information security
• Economics of security

The patterns & practices Security Engineering consists of the following activities:

• Security Objectives
• Security Design Guidelines
• Security Modeling
• Security Architecture and Design Review
• Security Code Review
• Security Testing
• Security Tuning
• Security Deployment Review

These activities help meet security objectives in the software life cycle.

• patterns & practices Security Engineering on Channel9
• patterns & practices Security Engineering on MSDN
• patterns & practices Security Engineering Explained

• Authentication
• Authorization
• Critical Infrastructure Protection
• Computer insecurity
• Cryptography
• Cryptanalysis
• Data remanence
• Deception
• Defensive programming
• Electronic underground community
• Fraud
• Full disclosure
• Hacking
• Kerckhoffs' principle
• Locksmithing
• Password policy
• Secrecy
• Secure computing
• Secure cryptoprocessor
• Security awareness
• Security through obscurity
• Security community
• Social engineering
• Software cracking
• Software Security Assurance
• Steganography
• Systems engineering
• Trusted system

• Ross Anderson (2001). Security Engineering. Wiley. ISBN 0-471-38922-6. 
• Ross Anderson (2001). "Why Information Security is Hard - An Economic Perspective"
• Bruce Schneier (1995). Applied Cryptography, 2nd edition, Wiley. ISBN 0-471-11709-9. 
• Bruce Schneier (2000). Secrets and Lies: Digital Security in a Networked World. Wiley. ISBN 0-471-25311-1. 
• David A. Wheeler (2003). Secure Programming for Linux and Unix HOWTO. Linux Documentation Project. Retrieved on 2005-12-19.