System Security

From SEBoK
Jump to navigation Jump to search

Security engineering is concerned with building systems that remain secure despite malice or error. Security engineering focuses on the tools, processes, and methods needed to design and implement complete systems that proactively and reactively mitigate vulnerabilities. Security engineering is a primary discipline used to achieve system assurance.

Multidisciplinary Reach

Security engineering incorporates a number of cross-disciplinary skills, including cryptography, computer security, tamper-resistant hardware, applied psychology, supply chain management, and law. Security requirements differ greatly from one system to the next. System security often has many layers built on user authentication, transaction accountability, message secrecy, and fault tolerance. The challenges are protecting the right items rather than the wrong items and protecting the right items but not in the wrong way.

Robust Security Design

Robust security design explicitly rather than implicitly defines the protection goals. The Certified Information Systems Security Professional (CISSP) Common Body of Knowledge (CBK) partitions robust security into ten domains (Tipton 2006):

  1. Information security governance and risk management addresses the framework, principles, policies, and standards that establish the criteria and then assess the effectiveness of information protection. Security risk management contains governance issues, organizational behavior, ethics, and security awareness training.
  1. Access control is the procedures and mechanisms that enable system administrators to allow or restrict operation and content of a system. Access control policies determine what processes, resources, and operations users can invoke.
  1. Cryptography can be defined as the principles and methods of disguising information to ensure its integrity, confidentiality, and authenticity during communications and while in storage. Type I devices are certified by NSA for classified information processing. Type 2 devices are certified by NSA for proprietary information processing. Type 3 devices are certified by NSA for general information processing. Type 4 devices are produced by industry or other nations without any formal certification.
  1. Physical (environmental) security addresses the actual environment configuration, security procedures, countermeasures, and recovery strategies to protect the equipment and its location. These measures include separate processing facilities, restricted access into those facilities, and sweeps to detect eavesdropping devices.
  1. Security architecture and design contains the concepts, processes, principles, and standards used to define, design, and implement secure applications, operating systems, networks, and equipment. The security architecture must integrate various levels of confidentiality, integrity, and availability to ensure effective operations and adherence to governance.
  1. Business continuity and disaster recovery planning are the preparations and practices which ensure business survival given events, natural or man-made, which cause a major disruption in normal business operations. Processes and specific action plans must be selected to prudently protect business processes and to ensure timely restoration.
  1. Telecommunications and network security are the transmission methods and security measures used to provide integrity, availability, and confidentiality of data during transfer over private and public communication networks.
  1. Application development security involves the controls applied to application software in a centralized or distributed environment. Application software includes tools, operating systems, data warehouses, and knowledge systems.
  1. Operations security is focused on providing system availability for end users while protecting data processing resources both in centralized data processing centers and in distributed client / server environments.
  1. Legal, regulations, investigations, and compliance issues include the investigative measures to determine if an incident has occurred and the processes for responding to such incidents.

Given the variety of security needs and various domains that contribute to system security, a commonly applied architecture and design approach is known as “defense in depth.” This approach implements multiple layers of defense and countermeasures, making maximum use of certified equipment in each layer to facilitate system accreditation.


Works Cited

Tipton, H.F. (ed.). 2006. Official (ISC)2 guide to the CISSP CBK, 1st ed. Boston, MA, USA: Auerbach Publications.

Primary References

Anderson, Ross J. 2008. Security Engineering: A Guide to Building Dependable Distributed Systems, 2nd Ed. New York, NY, USA: John Wiley & Sons.

Additional References

Allen, Julia; Barnum, Sean; Ellison, Robert; McGraw, Gary; and Mead, Nancy. 2008. Software security engineering: a guide for project managers. New York, NY, USA: Addison Wesley Professional.

ISO. 2005. Information technology -- Security techniques -- Code of practice for information security management. ISO/IEC 27002. Geneva, SW: ISO.

ISO. 2007. Information technology -- Security techniques -- Systems Security Engineering -- Capability Maturity Model® (SSE-CMM®) ISO/IEC 21827. Geneva, SW: ISO.

Jurjens, J. 2005. "Sound Methods and effective tools for model-based security engineering with UML." Proceedings of the 2005 International Conference on Software Engineering. Munich, GE: ICSE, 15-21 May.

MITRE. 2012. "Systems Engineering for Mission Assurance." In Systems Engineering Guide. Accessed 19 June 2012 at [].

< Previous Article | Parent Article | Next Article >
SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

Error in widget DISQUS: unable to write file /var/www/sebokwiki/mediawiki/extensions/Widgets/compiled_templates/wrt62f04798263fa3_96496263