T7.2.1 - SECURITY REQUIREMENTS ANALYSIS AND SPECIFICATION

Back to T7.2.1 - P3 - SECURITY REQUIREMENTS ANALYSIS AND SPECIFICATION

Information security requirements should be identified using various methods such as regulations and policies, reviews threat modeling and vulnerability thresholds/vulnerably remediation. Results from the identification should be documented merging views of all stakeholders.

Security requirements and controls should reflect the business value of the information involved and the potential negative business impact which might result from lack of adequate security.

System requirements for information security and processes for implementing security should be integrated in the early stages of information system projects. Controls introduced at the design stage are significantly cheaper to implement and maintain than those included during or after implementation.

The sizing of information systems should take into account enabling all security features in that system; i.e. higher specifications model of Security-Systems so that when security features are enabled they do not cause slow-down and degradation in the information systems performance.

For applications systems providing services or transferring information over public networks, the system requirements should also consider the following:

• A. The level of confidence each party requires in each other’s claimed identity, e.g. through authentication
• B. Authorization processes associated with who may approve contents of, issuing or signing key transactional documents
• C. Ensuring that communicating partners are fully informed of their authorizations for provision or use of the service
• D. Determining and meeting requirements for confidentiality, integrity, proof of dispatch and receipt of key documents and the non-repudiation of contracts, e.g. associated with tendering and contract processes
• E. The level of trust required in the integrity of key documents
• F. The confidentiality of any confidential information
• G. The confidentiality and integrity of any order transactions, payment information, delivery address details and confirmation of receipts
• H.The degree of verification appropriate to verify payment information supplied by a customer
• I. Selecting the most appropriate settlement form of payment to guard against fraud
• J. The level of protection required to maintain the confidentiality and integrity of order information;
• K. Avoidance of loss or duplication of transaction information;
• L. Liability associated with any fraudulent transactions;
• M. Insurance requirements;
• N. Transaction related requirements such as authenticity, confidentiality and integrity of transaction related data, non-repudiation and protection of any transaction related data.

If products are acquired, a formal testing and acquisition process should be followed. Contracts with the supplier should address the identified security requirements. Where the security functionality in a proposed product does not satisfy the specified requirement then the risk introduced and associated controls should be reconsidered prior to purchasing the product.

Available guidance for security configuration of the product aligned with the final software / service stack of that system should be evaluated and implemented.

Criteria for accepting products should be defined e.g., in terms of their functionality, which give assurance that the identified security requirements are met. Products should be evaluated against these criteria before acquisition. Where additional functionality is supplied and causes a security risk, this should be disabled or the proposed control structure should be reviewed to determine if advantage can be taken of the enhanced functionality available.

Back to T7.2.1 - P3 - SECURITY REQUIREMENTS ANALYSIS AND SPECIFICATION