Security Life Cycles

The Information Life Cycle

The life cycle of information has three main stages which attract different IA activities:

1. Acquisition

   • planning

   • identification

   • classification

   • provenance

2. Utilization

   • storage

   • processing

   • transmission

   • validity

   • integrity

3. Disposal

   • validity

   • disposal

   • transfer

   • auditing

Development

The development process is another area that benefits from day-one stakeholder consultation (stakeholder management). This ensures that user requirements are accurately captured and that the security requirement can be aligned with them. Additionally, maintaining good intra-organization relationships can increase the credibility and trust in the IA roles.

The security requirement must be part of the overall statement of requirements to ensure assurance requirements are captured at the start of the project. The security requirement may capture:

• defensive coding (ensure only valid and accurate data is processed)

• periodic functional testing with accurate and comprehensive reporting (this also encompasses regression testing)

• recovery capability and securing data against loss or damage

• assurance of availability

• compliance with legal/regulatory requirements

• security of communications

• effective auditing of activity

Data accuracy

Data Accuracy can be promoted in the following ways:

• ensure a correct design, values should reflect the right information, data relationships should be meaningful and relevant

• use proven code review techniques

• check values are in acceptable ranges and data relationships are valid

• train users in correct procedures

• audit the system regularly for anomalies

• allow data owners to easily report errors, review the causes and implement measures against recurrence

Testing, audit, and review

Systems must be repeatedly tested, reviewed, and audited as part of a continuous risk management process. In particular these should produce an ongoing review and analysis of vulnerabilities in the form of comprehensive and accurate reports consisting of technical details and an executive summary. The vulnerability findings should be prioritised by level of impact and level of difficulty.

Change control

There must be an effective formal change control process. The start of a change requires the submission of an outline of proposed changes to the change review board. One of the members of this board should be a member of the assurance team who will determine changes to risks arising from those changes.

If the proposal is approved, the board may specify additional conditions in order to manage risks arising from such changes. Any changes must then go through appropriate functional and acceptance testing before final acceptance and sign-off. This process must be applied to software, hardware, and documentation.

Acceptance Testing and Deployment

Deliverables must perform their desired function securely without unintentional adverse impact; RA should be part of the design process and these forecasts should be checked against actual testing outcomes. Some methods of testing include functional and regression testing, code review and inspection, and automated analysis of logs and network traffic. These methods will also safeguard against covert channels and rogue code.

All new (and changed) systems should go through acceptance testing before deployment in the production domain. It is best practice to separate these domains in order to protect production data. In practice there are often three domains: development, testing, and production. The development domain can also be leveraged for additional user training while minimising risk to production assets. Final authorization for promotion to the production domain requires endorsement from all of the acceptance testers who should be representatives of:

• project team

• end users

• business management

• assurance team

Acceptance testing must be conducted in a secure way and should consider:

• compliance of code with standards

• effectiveness of defensive coding

• protection against malicious code and injection via interfaces

• backup and recovery arrangements

• access control

• auditing and behavioural analysis

• communications security

• resilience

Additional Issues

Outsourcing development

Outsourcing may realise cost savings but incurs additional risks:

• introduction of malicious code

• loss of intellectual property

• legal disputes (contracts should provide processes for resolution including the jurisdiction for such)

It’s advised to choose a supplier that has reached level 5 in the Capability Maturity Model (CMM).

Security patching

Patches should be tested like other changes before promotion to the production domain. Patch application should always be attempted: the risk of installing a patch fixing a known vulnerability is much lower than the risk of accidentally introducing a vulnerability at the same time.

Use of certified systems

When systems are certified to some security standard (such as the Common Criteria) they are assessed against a well defined security target (’target of evaluation’). Ensure that this target includes the features that are desired for use.

Use of escrow to reduce risks of source loss

Use of escrow to transfer source code can transfer some of the risk of a supplier not providing such code and reducing dependency on them. A neutral third party can hold the source. A legally binding agreement details the conditions under which that source will be released to the organization (eg. the supplier going out of business) and ownership of that code along with relevant rights (including right to modify and further develop) is transferred to the organization.

The role of accreditation

All system changes must go through the same change control and acceptance process. Additionally they may require periodic review and re-accreditation. This is either performed by a formal accreditation function (internal or external) or another role in the organization. Frequently the business owner performs the accreditation function by sign-off on documented residual risks and vulnerabilities. This function is aligned with the role and so any new business owner would inherit this accreditation decision. The security manager should not perform this function.

Additional best practices for IT infrastructure

• ensure commercial off-the-shelf (COTs) solutions are patched, come from a reputable supplier, and are genuine and legal

• separation of systems, an alternative is limited-access via an inter-domain connector (IDC), separate systems are less complex to maintain

• ensuring conformity with policies, standards, and guidelines

• maintaining control of privileged access (eg. users should not be able to modify their own privileges via such a function)

• ensuring correctness of input and accuracy of stored data

• installing documented baseline controls (standards defining how systems should be configured, including patches, applications, etc)

• establishing configuration management

---