Engineering Process For Information Technology security

Principle 1. Establish a sound security policy as the “foundation” for design.

The policy identifies security goals (e.g., confidentiality, integrity, availability, accountability, and assurance).

The policy also should require definition of critical assets, the perceived threat, and security-related roles and responsibilities.

Principle 2. Treat security as an integral part of the overall 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.

Principle 3. Clearly delineate the physical and logical security boundaries governed by associated security policies.

Information technology exists in physical and logical locations, and boundaries exist between these locations.

An understanding of what is to be protected from external factors can help ensure adequate protective measures are applied where they will be most effective.

Principle 4 (formerly 33). 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.

Principle 5 (formerly 4). Reduce risk to an acceptable level.

Risk is combination of

• the likelihood that a particular threat source will exercise (intentionally exploit or unintentionally trigger) a particular information system vulnerability and
• the resulting adverse impact on organizational operations,organizational assets, or individuals should this occur

Elimination of all risk is not cost-effective.

Principle 6 (formerly 5). Assume that external systems are insecure.

An external domain is one that is not under your control. 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.

Principle 7 (formerly 6). 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.

Principle 8. Implement tailored system security measures to meet organizational security goals.

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

Principle 9 (formerly 26). Protect information while being processed, in transit, and in storage.

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.

Principle 10 (formerly 29). 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 COTS products. In such instances, it will

be necessary to augment COTS with non-COTS mechanisms.

Principle 11 (formerly 31). Protect against all likely classes of “attacks.”

Examples of “attack” classes are: Passive monitoring, active network attacks, exploitation by insiders, attacks requiring physical access or proximity, and the insertion of backdoors and malicious code during software development and/or distribution.

Principle 12 (formerly 18). 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.

Principle 13 (formerly 19). Use common language in developing security requirements.

When a “common” evaluation process is based upon common requirements or

criteria, a level of confidence can be established that ensures product security functions conform to an organization’s security requirements.

Principle 14 (formerly 21). Design security to allow for regular adoption of new technology, including a secure and logical technology upgrade process.

Each security mechanism should be able to support migration to new technology or upgrade of new features without requiring an entire system redesign. The security design should be modular so that individual parts of the security design can be upgraded without the requirement to modify the entire system.

Principle 15 (formerly 27). 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.

Principle 16 (formerly 7). Implement layered security (Ensure no single point of vulerability).

Security designs should consider a layered approach to address or protect against a specific threat or to reduce vulnerability. 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.

Principle 17 (formerly 10). Design and operate an IT system to limit damage and to be resilient in response.

Information systems should be resistant to attack, should limit damage, and should recover rapidly when attacks do occur.

Principle 18 (formerly 13). Provide assurance that the system is, and continues to be, resilient in the face of expected threats.

Assurance is the grounds for confidence that a system meets its security

expectations. These expectations can typically be summarized as providing sufficient resistance to both direct penetration and attempts to circumvent security controls.

Principle 19 (formerly 14). 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.

Principle 20 (formerly 16). Isolate public access systems from mission critical resources (e.g., data, processes, etc.).

Physical isolation may include ensuring that no physical connection exists between an organization’s public access information resources and an organization’s critical information.

Principle 21 (formerly 17). Use boundary mechanisms to separate computing systems and network infrastructures.

To control the flow of information and access across network boundaries in

computing and communications infrastructures, and to enforce the proper separation of user groups, a suite of access control devices and accompanying access control policies should be used.

Principle 22 (formerly 20). 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.

Principle 23 (formerly 28). 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

Principle 24 (formerly 9). 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.

Principle 25 (formerly 11). 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.

Principle 26 (formerly 24). Implement least privilege.

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. .

Principle 27 (formerly 25). Do not implement unnecessary security mechanisms.

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.

Principle 28 (formerly 30). Ensure proper security in the shutdown or disposal of a system.

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.

Principle 29 (formerly 32). 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.

Principle 30 (formerly 12). Implement security through a combination of measures distributed physically and logically.

It is important to associate all elements with the security service they provide. These components are likely to be shared across systems to achieve security as infrastructure resources come under more senior budget and operational control.

Principle 31 (formerly 15). Formulate security measures to address multiple overlapping 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.

Principle 32 (formerly 22). Authenticate users and processes to ensure appropriate access control decisions both within and across domains.

It is essential that adequate authentication be achieved in order to implement

security policies and achieve security goals.

Principle 33 (formerly 23). 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:

• Maintain accountability and traceability of a user or process

• Assign specific rights to an individual user or process

• Provide for non-repudiation

• Enforce access control decisions

• Establish the identity of a peer in a secure communications path

• Prevent unauthorized users from masquerading as an authorized user.