When preparing and maintaining policies it is vital to ensure they are consistent.
This is helped by not having too many policies and by having some overall structure to them.
For example the ISMS Management Plan should provide the policy architecture.
However, large policy documents are seldom ‘user friendly’.
The key is documents designed for their users that clearly tell them what they have to do, when they have to do it and what they must not do.
Policies that are incompatible with an organisation’s culture are likely to fail.
There may be a corporate security policy, which comprises the security principles and directives for all aspects of security throughout the agency, as part of the broader corporate policies.
Often this is prepared in a strategic context taking into account the financial, operational, customer, legal and regulatory aspects of the agency’s functions and activities.
The information security policy may involve both internal and external stakeholders, and must be part of the contract if IT is outsourced.
Within its scope effective ISMS Policy must be: • achievable by agency members with clearly defined responsibilities and actions for at least users, IT staff and management; • enforceable both procedurally and technically, and with sanctions when breaches occur; and • implementable through procedures, technical controls or other methods, via clearly documented directives, guidelines, instructions and the like.
There are no definitive ISMS policies that can be readily adopted by all organisations.
Ideally each agency should develop its policies in its own style to reflect its own culture and circumstances.
The best approach is to document existing practices then rationalise, integrate and improve them to meet security needs.
This approach minimises the subsequent training and awareness raising effort.
However, adapting another organisation’s ISMS policies, particularly lower level ones, may sometimes be the most cost effective solution.
Detailed operating policies, particularly for security technology, developed by third parties may prove useful. ISO/IEC 27001:2005 A.5.1.2 The information security policy shall be reviewed at planned intervals or if significant changes occur to ensure it remains appropriate. The ISMS policies may become inadequate as changes occur in technology, laws and regulations, threats or operations.
As a minimum, policies should be assessed annually, as part of the PDCA cycle, to ensure their currency and adequacy.
Procedures should be established to ensure that the relevant parts of the Policy and any revisions are issued to all existing and new employees and contractors, perhaps even requiring them to sign to acknowledge receipt.
This ensures that ignorance cannot be used in defence of a breach. Information Security Guidelines Version 6.0 Page 18 of 111 3.4 Configuration Management An operating ISMS must have effective configuration management.
Configuration management is also explicitly referenced in some safeguards.
Ideally a configuration management system already exists in an agency, and will do so in agencies that comply with AS/NZS ISO 9001 Quality management systems – Requirements or the Information Technology Infrastructure Library (ITIL).
The standard for configuration management is AS ISO 10007:2003 Quality management systems – Guidelines for configuration management.
The main elements of configuration management are: • formal plan and procedures; • a system of configuration item (CI) identification; • change control arrangements; • configuration status accounting; and • configuration audit.
CIs may include hardware, software, networks and documents of all types.
Change control necessitates change management including organisation and processes.
ITIL is widely recognised as providing authoritative guidance on this change management.
The mechanics of a change control process require that: • The need for a change is identified and a formal Change Request is raised. • The Change Request is evaluated to understand its implications. • A change control authority formally decides to accept or reject the change. • If accepted the change is implemented. 3.5 Management Commitment A key factor for successful information security in any organisation is the: visible support and commitment from all levels of management This will not guarantee success but lack of it will guarantee failure.
Executive management direction on, and commitment to, information security can influence the culture of the agency.
Executive management interest helps ensure that information security is taken seriously at lower organisational levels.
Management’s commitment to information security can be demonstrated by ensuring that: • Effective and functioning governance arrangements originating at the highest level of the organisation. • The ISMS Charter reflects executive commitment. • The ISMS management plan establishes detailed organisation, management responsibilities and accountabilities and has executive level endorsement. • An ISMS is established, implemented and maintained. • Adequate resources are allocated to information security. • The performance of the ISMS is reported to executive management for review and as a basis for improvement, taking into account any regulatory reporting requirements. Information Security Guidelines Version 6.0 Page 19 of 111 Management commitment can be developed and sustained by providing regular reports and status information. ‘Dashboard’ style is recommended for this. 3.6 Critical Success Factors In addition to management commitment the successful implementation of information security within an agency will depend on several factors, notably: • Information security policy, objectives and activities reflect business objectives. • Recognition that information security is a business issue not an IT problem. • An approach and framework to implementing, maintaining, monitoring, and improving information security that is consistent with the organisational culture and involves stakeholders. • A realistic assessment of the security risks. • Provision of resources for information security management. • The existence and use of an agency security architecture. • Effective promotion of information security to all managers, staff and other parties to achieve awareness. • Appropriate awareness training and education to all staff. • Establishing an effective information security incident management process. • Processes to measure the ISMS, evaluate its performance and feed into the improvement process.
Indicators of an effective ISMS include: • The Board or equivalent requires and receives regular reports about information security performance and events. • Information security is a standing item on the agendas of risk management committees up to executive level. • Information security risk levels are set by the executive level and reflect the agency’s risk appetite. • Business unit managers are responsible for the security of the information underpinning their operations. • The inherent information risks in critical business processes are understood and documented. • Individuals are held accountable for any security breaches in which they participate, whether intentional or accidental. • Regular review of information security products and services to ensure they are cost effective. • Regular review of information security arrangements to ensure continued relevance and continuous improvement.
An effective information security risk management process is essential for the successful implementation of the program.
The basic ISMS framework is shown in the following figure. Information Security Guidelines Version 6.0 — This section describes the safeguards relating to the secure, correct and reliable functioning of the ICT Facilities.
Operational safeguards can be implemented by instituting organisational procedures.
Most operational control will be the result of policy decisions arising from information security polices. Information Security Guidelines Version 6.0 Page 92 of 111 4.1 Communications and Operations Management Responsibilities will be established in information security policies.
Operational procedures and responsibilities ISO/IEC 27002:2007 10.1 To ensure the correct and secure operation of information processing facilities. Documentation includes all types of security ‘policy’, including operating procedures and contingency plans.
Configuration management includes change management organisation and the processes and procedures that control changes to configurations.
This ensures that changes to ICT systems do not introduce security vulnerabilities by reducing the effectiveness of existing safeguards.
AS ISO 10007:2003 Quality management systems – Guidelines for configuration management provides authoritative information.
The key to configuration management is identification of configuration items (CIs).
They may be synonymous with some individual information assets but also include documents, and the rules and settings of ICT security devices.
The standard provides a format for a configuration management plan that addresses the major elements of configuration management: configuration identification, change control, configuration status accounting and configuration audit.
ISO/IEC 20000-2:2005 Information technology – Service management – Part 2 – Code of practice (ITIL) is recognised as providing good guidance on change management.
Change management should ensure that the movement of code from development to testing and production (operations) is done in a controlled and authorised manner.
Segregation of duties is desirable so as to reduce the risk of accidental or deliberate change or unauthorised access to operational software and data.
Operational libraries should only be updated by authorised operational staff.
Audit logs should be maintained for all access to Operational program source and object libraries.
Third party service delivery management ISO/IEC 27002:2007 10.2 To implement and maintain the appropriate level of information security and service delivery in line with third party service delivery agreements. Concerns the security aspects of operational or development services delivered by third parties.
Outsourced IT facilities can introduce security exposures, such as unauthorised access, damage or loss of data at the outsourced facility.
Risks should be identified and addressed in the outsourcing agreement.
Specific security issues that need to be addressed are: • Determining whether sensitive data and or applications can be outsourced. • Defining the security standards to be applied and how compliance is to be measured. • Obtaining authorisation from information owners. • Defining security roles and responsibilities for monitoring, reporting and handling incidents. • Business continuity requirements and responsibilities Information Security Guidelines Version 6.0 Page 93 of 111 Outsourced software development requires consideration of the following issues: • Quality assurance procedures to be applied, including the rights and obligations of the Agency and Outsourcer. • Licensing arrangements and ownership of code. • Rights to software in the event of financial failure of the outsourcer.
Monitoring and review of third party services should be integrated with similar internal activities.
Typically, change management, including configuration management, will be a joint activity between the parties.
Systems planning and acceptance ISO/IEC 27002:2007 10.3 To minimise the risk of system failures. Capacity planning should be used to avoid failures due to inadequate capacity.
In planning future capacity requirements for a system, current trends should be taken into account.
Potential bottlenecks should be avoided that could cause a threat to system security or user access.
System Testing, which tests that the system meets its System Requirement, must be completed, before the system is handed over to the business users for Acceptance Testing.
System Testing must be planned and comprehensive in scope.
Live data should not be used for System Testing.
During System Testing, safeguards over test data need to be implemented.
These safeguards may include: • All actual data should be changed prior to use • Authorisation should be obtained every time copies of actual data are made • Where live data is used it should be deleted after use • Logs should be updated when copying of operational data is made.
System Testing must ensure that security functional and non-functional requirements are met, including fail-soft modes.
Acceptance Testing should include the useability of the security safeguards.
Protection against malicious code ISO/IEC 27002:2007 10.4 To protect the integrity of software and information. Viruses, trojans, worms and spyware are all examples of malicious code.
Malicious code may also compromise confidentiality, integrity or availability.
Safeguards involve both technology and user awareness, including social engineering aspects.
Safeguards need to be in place to avoid, protect, detect and correct the effects of malicious code.
The malicious software threat is very varied, dynamic and pervasive, single point solutions are unlikely to sufficiently reduce the risk.
While external email is the most pervasive threat channel, there are other routes for malicious software to enter an organisation.
The threat of targeted attack is increasing, and attacking a ‘low risk’ agency as path to others is a possibility. Information Security Guidelines Version 6.0
Read more about ITIL : Ideally a configuration management system already exists in an agency….: