Difference between revisions of "System Security"

From SEBoK
Jump to navigation Jump to search
Line 4: Line 4:
 
NATO AEP-67 (Edition 1), Engineering for System Assurance in NATO Programmes, defines system assurance as:
 
NATO AEP-67 (Edition 1), Engineering for System Assurance in NATO Programmes, defines system assurance as:
  
…the justified confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle... This confidence is achieved by system assurance activities, which include a planned, systematic set of multi-disciplinary activities to achieve the acceptable measures of system assurance and manage the risk of exploitable vulnerabilities.  (NATO February 2010, p. 1)
+
<blockquote>''…the justified confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle... This confidence is achieved by system assurance activities, which include a planned, systematic set of multi-disciplinary activities to achieve the acceptable measures of system assurance and manage the risk of exploitable vulnerabilities.'' (NATO February 2010, p. 1)</blockquote>
  
 
The document is organized based on the life cycle processes in ISO/IEC 15288:2008 and provides process and technology guidance to improve system assurance.  (ISO/IEC 2008)
 
The document is organized based on the life cycle processes in ISO/IEC 15288:2008 and provides process and technology guidance to improve system assurance.  (ISO/IEC 2008)
  
Since most modern systems derive a good portion of their functionality from software, software assurance becomes a primary consideration in systems assurance.   As Goertzel and Winograd point out:
+
Since most modern systems derive a good portion of their functionality from software, software assurance becomes a primary consideration in systems assurance. According to CNSS (2009), "Software assurance (SwA) is the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner" (Committee on National Security Systems (CNSS). Instruction No. 4009, National Information Assurance Glossary. Revised June 2009). Goertzel and Winograd point out: "The reason software assurance matters is that so many business activities and critical functions—from national defense to banking to healthcare to telecommunications to aviation to control of hazardous materials—depend on the on the correct, predictable operation of software (Goertzel, Winograd, and et al. October 2008, p. 8)."
 
 
The reason software assurance matters is that so many business activities and critical functions—from national defense to banking to healthcare to telecommunications to aviation to control of hazardous materials—depend on the on the correct, predictable operation of software. (Goertzel, Winograd, and et al. October 2008, p. 8)
 
  
 
This is not to say that hardware and the supply chain itself are not also concerns of security engineering.  In fact, 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 explicitly rather than implicitly defines the protection goals.
 
This is not to say that hardware and the supply chain itself are not also concerns of security engineering.  In fact, 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 explicitly rather than implicitly defines the protection goals.

Revision as of 16:57, 31 August 2011

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.

System Assurance

NATO AEP-67 (Edition 1), Engineering for System Assurance in NATO Programmes, defines system assurance as:

…the justified confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle... This confidence is achieved by system assurance activities, which include a planned, systematic set of multi-disciplinary activities to achieve the acceptable measures of system assurance and manage the risk of exploitable vulnerabilities. (NATO February 2010, p. 1)

The document is organized based on the life cycle processes in ISO/IEC 15288:2008 and provides process and technology guidance to improve system assurance. (ISO/IEC 2008)

Since most modern systems derive a good portion of their functionality from software, software assurance becomes a primary consideration in systems assurance. According to CNSS (2009), "Software assurance (SwA) is the level of confidence that software is free from vulnerabilities, either intentionally designed into the software or accidentally inserted at any time during its life cycle, and that the software functions in the intended manner" (Committee on National Security Systems (CNSS). Instruction No. 4009, National Information Assurance Glossary. Revised June 2009). Goertzel and Winograd point out: "The reason software assurance matters is that so many business activities and critical functions—from national defense to banking to healthcare to telecommunications to aviation to control of hazardous materials—depend on the on the correct, predictable operation of software (Goertzel, Winograd, and et al. October 2008, p. 8)."

This is not to say that hardware and the supply chain itself are not also concerns of security engineering. In fact, 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 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):

  • 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.
  • 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.
  • Cryptography is 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Application development security is the controls applied to application software in a centralized or distributed environment. Application software includes tools, operating systems, data warehouses, and knowledge systems.
  • 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.
  • 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.

A good web-based resource for System and Software Assurance is the U.S. Department of Homeland Security’s Build Security In web site (DHS 2010). The site provides resources for best practices, knowledge, and tools for engineering secure systems. Elements of security are summarized in Table 1.

Table 1. Security Ontology (Permission Status Unknown)

Ontology Element Name Ontology Element Attributes Relationship to Security Threat identification Sources of misuse or malicious behavior Required attribute Threat detection Mechanisms to detect potential attacks as they happen Required attribute Deterrence Mechanisms to prevent attacks Required attribute Mitigation Means to control damage after an attack Required attribute Target hardening preventing penetration by unwanted or unauthorized persons by adding user authentication, transaction accountability, message secrecy, and fault tolerance Standard practices to elevate security

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

List all references cited in the article. Note: SEBoK 0.5 uses Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Primary References

All primary references should be listed in alphabetical order. Remember to identify primary references by creating an internal link using the ‘’’reference title only’’’ (title). Please do not include version numbers in the links.

Additional References

All additional references should be listed in alphabetical order.


Article Discussion

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

--Bkcase 19:09, 22 August 2011 (UTC) (on behalf of Dick Fairley)