Ref. No.: CPP-IT-0301_V1_Company Engineering Principles for Information Technology.doc Company Engineering Principles for Information Technology.doc 

Prepared	W. Cundangan		05/17/2016
Approved	R. Eldridge		05/01/2017

• Users when developing and evaluating functional requirements, or when operating information systems within their organization. 

• System engineers and architects when designing, implementing, or modifying an information system. 

• IT specialist during all phases of the system life-cycle. 

• Project/Program Managers and Information System Security Officers to ensure adequate security measures have been considered for all phases of the system life-cycle. 

1. Initiation Phase 
   
1. During the initiation phase, the need for a system is expressed and the purpose of the system is documented
   
2. Activities include conducting a risk assessment 
   
2. Development/Acquisition Phase 
   
1. During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. 
   
2. Activities include determining security requirements, incorporating security requirements into specifications, and obtaining the system. 
   
3. Implementation Phase 
   
1. During implementation, the system is tested and installed or fielded. 
   
2. Activities include installing/turning on controls, security testing, certification, and accreditation. 
   
4. Operation/Maintenance Phase 
   
1. During this phase, the system performs its work. Typically, the system is also being modified by the addition of hardware and software and by numerous other events. 
   
2. Activities include security operations and administration, operational assurance, and audits and monitoring. 
   
5. Disposal Phase. 
   
1. The disposal phase of the IT system life-cycle involves the disposition of information, hardware, and software. Activities include moving, archiving, discarding or destroying information and sanitizing the media.
   

5.1 Security Foundation 

Principle 1: “Treat security as an integral part of the overall system design and lifecycle.” 

Security must be considered in information system design. Experience has shown it to be both difficult and costly to implement security measures properly and successfully after a system has been developed, so it should be integrated fully into the system life-cycle process. This includes establishing security policies, understanding the resulting security requirements, participating in the evaluation of security products, and finally in the engineering, design, implementation, and disposal of the system. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance 
   
5. Disposal
   

Principle 2: “Ensure that developers are trained in how to develop secure software.” 

It is unwise to assume that developers know how to develop secure software. Therefore, ensure that developers are adequately trained in the development of secure software before developing the system. This includes application of engineering disciplines to design, development, configuration control, and integration and testing. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation

5.2 Risk Based 

Principle 3: “Reduce risk to an acceptable level” 

Risk is defined as the combination of (1) the likelihood that a particular threat source will exercise (intentionally exploit or unintentionally trigger) a particular information system vulnerability and (2) the resulting adverse impact on organizational operations, organizational assets, or individuals should this occur. It is recognized that elimination of all risk is not cost-effective. The goal is to enhance mission/business capabilities by mitigating mission/business risk to an acceptable level. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance 
   
5. Disposal
   

Principle 4: “Assume that external systems are insecure” 

An external domain is one that is not under your control. In general, external systems should be considered insecure. Until an external domain has been deemed “trusted,” system engineers, architects, and IT specialists should presume the security measures of an external system are different than those of a trusted internal system and design the system security features accordingly. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 5: “Identify potential trade-offs between reducing risk and increased costs and decrease in other aspects of operational effectiveness.” 

To meet stated security requirements, a systems designer, architect, or security practitioner will need to identify and address all competing operational needs. It may be necessary to modify or adjust (i.e., trade-off) security goals due to other operational requirements. In modifying or adjusting security goals, an acceptance of greater risk and cost may be inevitable. By identifying and addressing these trade-offs as early as possible, decision makers will have greater latitude and be able to achieve more effective systems. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 6: “Implement tailored system security measures to meet organizational security goals.” 

In general, IT security measures are tailored according to an organization’s unique needs. While numerous factors, such as the overriding mission requirements, and guidance, are to be considered, the fundamental issue is the protection of the mission or business from IT security-related, negative impacts. Because IT security needs are not uniform, system designers and security practitioners should consider the level of trust when connecting to other external networks 

and internal sub-domains. Recognizing the uniqueness of each system allows a layered security strategy to be used – implementing lower assurance solutions with lower costs to protect less critical systems and higher assurance solutions only at the most critical areas. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance 
   
5. Disposal
   

Principle 7: “Protect information while being processed, in transit, and in storage.” 

The risk of unauthorized modification or destruction of data, disclosure of information, and denial of access to data while in transit should be considered along with the risks associated with data that is in storage or being processed. Therefore, system engineers, architects, and IT specialists should implement security measures to preserve, as needed, the integrity, confidentiality, and availability of data, including application software, while the information is being processed, in transit, and in storage (in production or for back up). 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance 
   
5. Disposal
   

Principle 8: “Consider custom products to achieve adequate security.” 

Designers should recognize that in some instances it will not be possible to meet security goals with systems constructed entirely from Commercial off the shelf (COTS) products. In such instances, it will be necessary to augment COTS with non-COTS mechanisms. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

5.3 Ease of Use 

Principle 9: “Where possible, base security on open standards for portability and interoperability"

Most organizations depend significantly on distributed information systems to perform their mission or business. These systems distribute information both across their own organization and to other organizations. For security capabilities to be effective in such environments, security program designers should make every effort to incorporate interoperability and portability into all security measures, including hardware and software, and implementation practices. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 10: “Strive for operational ease of use.” 

The more difficult it is to maintain and operate a security control, the less effective that control is likely to be. Therefore, security controls should be designed to be consistent with the concept of operations and with ease-of-use as an important consideration. The experience and expertise of administrators and users should be appropriate and proportional to the operation of the security control. An organization must invest the resources necessary to ensure system administrators and users are properly trained. Moreover, administrator and user training costs along with the life-cycle operational costs should be considered when determining the cost effectiveness of the security control. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

5.4 Increase Resilience 

Principle 11: “Implement layered security (Ensure no single point of vulnerability).” 

Security designs should consider a layered approach to address or protect against a specific threat or to reduce vulnerability. These layers may include the following elements Hardware, Software, Network and People) For example, the use of a packet-filtering router in conjunction with an application gateway and an intrusion detection system combine to increase the work-factor an attacker must expend to successfully attack the system. Adding good password controls and adequate user training improves the system’s security posture even more. 

The need for layered protections is especially important when commercial-off-the-shelf (COTS) products are used. Practical experience has shown that the current state-of-the-art for security quality in COTS products does not provide a high degree of protection against sophisticated attacks. It is possible to help mitigate this situation by placing several controls in series, requiring additional work by attackers to accomplish their goals. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   
5. Disposal
   

Principle 12: “Limit or contain vulnerabilities” 

Design systems to limit or contain vulnerabilities. If a vulnerability does exist, damage can be limited or contained, allowing other information system elements to function properly. Limiting and containing insecurities also helps to focus response and reconstitution efforts to information system areas most in need 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 13: “Isolate public access systems from mission critical resources (e.g., data, processes, etc.)” 

While the trend toward shared infrastructure has considerable merit in many cases, it is not universally applicable. In cases where the sensitivity or criticality of the information is high, organizations may want to limit the number of systems on which that data is stored and isolate them, either physically or logically. Physical isolation may include ensuring that no physical connection exists between an organization’s public access information resources and an organization’s critical information. When implementing logical isolation solutions, layers of security services and mechanisms should be established between public systems and secure systems responsible for protecting mission critical resources. Security layers may include using network architecture designs such as demilitarized zones and screened subnets. Finally, system designers and administrators should enforce organizational security policies and procedures regarding use of public access systems. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance

Principle 14: “Design and implement audit mechanisms to detect unauthorized use and to support incident investigations.” 

Organizations should monitor, record, and periodically review audit logs to identify unauthorized use and to ensure system resources are functioning properly. In some cases, organizations may be required to disclose information obtained through auditing mechanisms to appropriate third parties, including law enforcement authorities Many organizations have implemented consent to monitor policies which state that evidence of unauthorized use (e.g., audit trails) may be used to support administrative or criminal investigations. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 15: “Develop and exercise contingency or disaster recovery procedures to ensure appropriate availability.” 

Continuity of operations plans or disaster recovery procedures address continuance of an organization’s operation in the event of a disaster or prolonged service interruption that affects the organization’s mission. Such plans should address an emergency response phase, a recovery phase, and a return to normal operation phase. Personnel responsibilities during an incident and available resources should be identified. In reality, contingency and disaster recovery plans do not address every possible scenario or assumption. Rather, it focuses on the events most likely to occur and identifies an acceptable method of recovery. Periodically, the plans and procedures should be exercised to ensure that they are effective and well understood. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

5.5 Reduce Vulnerabilities 

Principle 16: “Strive for simplicity.” 

The more complex the mechanism, the more likely it may possess exploitable flaws. Simple mechanisms tend to have fewer exploitable flaws and require less maintenance. Further, because configuration management issues are simplified, updating or replacing a simple mechanism becomes a less intensive process. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 17: “Minimize the system elements to be trusted.” 

Security measures include people, operations, and technology. Where technology is used, hardware, firmware, and software should be designed and implemented so that a minimum number of system elements need to be trusted in order to maintain protection. Further, to ensure cost-effective and timely certification of system security features, it is important to minimize the amount of software and hardware expected to provide the most secure functions for the system. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 19: “Implement least privilege” 

The concept of limiting access, or "least privilege," is simply to provide no more authorizations than necessary to perform required functions. This is perhaps most often applied in the administration of the system. Its goal is to reduce risk by limiting the number of people with access to critical system security controls; i.e., controlling who is allowed to enable or disable system security features or change the privileges of users or programs. Best practice suggests it is better to have several administrators with limited access to security resources rather than one person with "super user" permissions. 

Consideration should be given to implementing role-based access controls for various aspects of system use, not only administration. The system security policy can identify and define the various roles of users or processes. Each role is assigned those permissions needed to perform its functions. Each permission specifies a permitted access to a particular resource (such as "read" and "write" access to a specified file or directory, "connect" access to a given host and port, etc.). Unless a permission is granted explicitly, the user or process should not be able to access the protected resource. Additionally, identify the roles/responsibilities that, for security purposes, should remain separate, this is commonly termed “separation of duties”. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 20: “Do not implement unnecessary security mechanisms” 

Every security mechanism should support a security service or set of services, and every security service should support one or more security goals. Extra measures should not be implemented if they do not support a recognized service or security goal. Such mechanisms could add unneeded complexity to the system and are potential sources of additional vulnerabilities. 

An example is file encryption supporting the access control service that in turn supports the goals of confidentiality and integrity by preventing unauthorized file access. If file encryption is a necessary part of accomplishing the goals, then the mechanism is appropriate. However, if these security goals are adequately supported without inclusion of file encryption, then that mechanism would be an unneeded system complexity. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   
5. Disposal
   

Principle 21: “Ensure proper security in the shutdown or disposal of a system.” 

Although a system may be powered down, critical information still resides on the system and could be retrieved by an unauthorized user or organization. Access to critical information systems must be controlled at all times. 

At the end of a system’s life-cycle, system designers should develop procedures to dispose of an information system’s assets in a proper and secure fashion. Procedures must be implemented to ensure system hard drives, volatile memory, and other media are purged to an acceptable level and do not retain residual information. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   
5. Disposal
   

Principle 22: “Identify and prevent common errors and vulnerabilities.” 

Many errors reoccur with disturbing regularity - errors such as buffer overflows, race conditions, format string errors, failing to check input for validity, and programs being given excessive privileges. Learning from the past will improve future results Applicability o Development/Acquisition o Implement o Operation/Maintenance 

5.6 Design with Network in Mind

Principle 23: “Formulate security measures to address multiple overlapping information domains.” 

An information domain is a set of active entities (person, process, or devices) and their data objects. A single information domain may be subject to multiple security policies. A single security policy may span multiple information domains. An efficient and cost effective security capability should be able to enforce multiple security policies to protect multiple information domains without the need to separate physically the information and respective information systems processing the data. This principle argues for moving away from the traditional practice of creating separate LANs and infrastructures for various sensitivity levels (e.g., security classification or business function such as proposal development) and moving toward solutions that enable the use of common, shared, infrastructures with appropriate protections at the operating system, application, and workstation level. 

Moreover, to accomplish missions and protect critical functions, government and private sector organizations have many types of information to safeguard. With this principle in mind, system engineers, architects, and IT specialists should develop a security capability that allows organizations with multiple levels of information sensitivity to achieve the basic security goals in an efficient manner. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 24: “Authenticate users and processes to ensure appropriate access control decisions both within and across domains. “ 

Authentication is the process where a system establishes the validity of a transmission, message, or a means of verifying the eligibility of an individual, process, or machine to carry out a desired action, thereby ensuring that security is not compromised by an untrusted source. It is essential that adequate authentication be achieved in order to implement security policies and achieve security goals. Additionally, level of trust is always an issue when dealing with cross-domain interactions. The solution is to establish an authentication policy and apply it to cross-domain interactions as required. Note: A user may have rights to use more than one name in multiple domains. Further, rights may differ among the domains, potentially leading to security policy violations.

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   

Principle 25: “Use unique identities to ensure accountability” 

An identity may represent an actual user or a process with its own identity, e.g., a program making a remote access. Unique identities are a required element in order to be able to: 

1. Maintain accountability and traceability of a user or process 
   
2. Assign specific rights to an individual user or process 
   
3. Provide for non-repudiation 
   
4. Enforce access control decisions 
   
5. Establish the identity of a peer in a secure communications path 
   
6. Prevent unauthorized users from masquerading as an authorized user. 

Applicability 

1. Initiation
   
2. Development/Acquisition
   
3. Implementation
   
4. Operation/Maintenance
   
5. Disposal
   

This document has been prepared using the following ISO270001 standard control as reference