Process Standards (and Process Improvement)

1. Process Standards (and Process Improvement)

2. Wireless Security Survey Update Standard Format for all Protocols • Identity • Authentication • Session key • Message/data encryption • DoS, Location detection • Discussion of strengths & vulnerabilities • Discussion of planned enhancements

3. Example for GSM • Identity: • Fixed identity (IMSI) used when first turned on • Temporary identity (TMSI) given when turned on and other times • 128bit authentication key (Ki) • {IMSI, Ki} in removable SIM card and known to provider • Authentication: • 128bit challenge/32bit response, A3 algorithm using Ki • A3 unspecified, providers typically use Comp-128 for A3 • Session key: • 64bit cypher key (Kc) • Kc computed in client with A8 algorithm using challenge and Ki • Kc given to base station by provider • A8 unspecified, common for last 10 or more bits to be zero • Message/Data Encryption: • A5 114bit stream cypher using Kc and 22bit frame number • A5/1 for use in Europe • A5/2 for export • A5/3 based on Kasumi now available • Decryption at level ?? of protocol stack in base station • Location detection • Possible by triangulation, but identity changes

4. Additions • New Protocols • WiMax and Mobile WiMax • EV-DO • New military wireless protocols • New domains • Vehicle system wireless (as a variant of shopfloor) • Map of spectrum usage • Updates (i.e., wrt. advances in cryptography)

5. ISO/IEC 17799:2005(E) Information technology — Security techniques — Code of practice for information security management Second edition 2005-06-15

6. Intent of the Standard “This International Standard establishes guidelines and general principles for initiating, implementing, maintaining, and improving information security management in an organization.” “The control objectives and controls of this International Standard are intended to be implemented to meet the requirements identified by a risk assessment. This International Standard may serve as a practical guideline for developing organizational security standards and effective security management practices and to help build confidence in inter-organizational activities.”

7. 39 Categories in 11 Clauses • Security Policy (1) • Organizing Information Security (2) • Asset Management (2) • Human Resources Security (3) • Physical and Environmental Security (2) • Communications and Operations Management (10) • Access Control (7) • Information Systems Acquisition, Development and Maintenance (6) • Information Security Incident Management (2) • Business Continuity Management (1) • Compliance (3)

8. Structure of a Category • a control objective stating what is to be achieved; • one or more controls that can be applied to achieve the control objective. Control descriptions are structured as follows: • Control: Defines the specific control statement to satisfy the control objective. • Implementation guidance: Provides more detailed information to support the implementation of the control and meeting the control objective. • Other information: Provides further information that may need to be considered, for example legal considerations and references to other standards.

9. Applicable to development? (Section #: topic covered) 5: Security policy 8: Human resources security 10: Communications and operations management 11: Access control (i.e., to source code) 13.2: Management of information security incidents and improvements

10. 12. Information systems acquisition, development and maintenance 12.1 Security requirements of information systems 12.2 Correct processing in applications 12.3 Cryptographic controls 12.4 Security of system files 12.5 Security in development and support processes 12.6 Technical Vulnerability Management

11. 12.2 Correct processing in applications Objective: To prevent errors, loss, unauthorized modification or misuse of information in applications. Controls should include the validation of input data, internal processing and output data The design and implementation of applications should ensure that the risks of processing failures leading to a loss of integrity are minimized. Specific areas to consider include:

12. 12.5 Security in development and support processes Objective: To maintain the security of application system software and information. 12.5.1 Change control procedures 12.5.2 Technical review of applications after operating system changes 12.5.3 Restrictions on changes to software packages 12.5.4 Information leakage 12.5.5 Outsourced software development

13. 12.5.1 Change control procedures The implementation of changes should be controlled by the use of formal change control procedures. Introduction of new systems and major changes to existing systems should follow a formal process of documentation, specification, testing, quality control, and managed implementation.

14. 12.5.1 Change control procedures c) reviewing controls and integrity procedures to ensure that they will not be compromised by the changes; d) identifying all software, information, database entities, and hardware that require amendment; e) obtaining formal approval for detailed proposals before work commences;

15. 12.5.2 Technical review of applications after operating system changes When operating systems are changed, business critical applications should be reviewed and tested to ensure there is no adverse impact on organizational operations or security.

16. 12.5.3 Restrictions on changes to software packages Modifications to software packages should be discouraged, limited to necessary changes, and all changes should be strictly controlled. As far as possible, and practicable, vendor-supplied software packages should be used without modification.

17. 12.5.4 Information leakage Opportunities for information leakage should be prevented. (includes preventing trojan code) a) scanning of outbound media and communications for hidden information; b) masking and modulating system and communications behaviour to reduce the likelihood of a third party being able to deduce information from such behaviour; c) making use of systems and software that are considered to be of high integrity, e.g. using evaluated products (see ISO/IEC 15408);

18. 12.5.5 Outsourced software development Outsourced software development should be supervised and monitored by the organization. a) licensing arrangements, code ownership, and intellectual property rights (see 15.1.2); b) certification of the quality and accuracy of the work carried out; c) escrow arrangements in the event of failure of the third party; d) rights of access for audit of the quality and accuracy of work done; e) contractual requirements for quality and security functionality of code; f) testing before installation to detect malicious and Trojan code.

19. 12.6 Technical Vulnerability Management Objective: To reduce risks resulting from exploitation of published technical vulnerabilities. These considerations should include operating systems, and any other applications in use. Timely information about technical vulnerabilities of information systems being used should be obtained, the organization's exposure to such vulnerabilities evaluated, and appropriate measures taken to address the associated risk. A current and complete inventory of assets … Appropriate, timely action should be taken …

20. Observations and Analysis • Some wireless stuff • Focus is on in-house IS/IT support group • Does not address development activities (some items can apply to development team) • Has category for OS evolution. Less attention to impact of emerging networking options • Addresses only 2nd of Leveson’s 4 levels

21. Leveson’s Types of Causes • Technical • Human • Organizational • Regulatory