ISO 27001:2013 ISMS Manual

Introduction

This section presents the Scope of the Information Security Management System (ISMS). This includes the purpose and the application of ISMS.

1.0 Scope

The Scope of the ISMS covers, XXX, its Server room and its management related to business applications, to implement the IT services provided to internal and external customers from its office location at XXXXXXX.

(Note: refer to Latest version of ISO 27001-2013-SOA .xlsxfor exclusions)

1.1 General

This ISMS manual specifies the requirements for establishing, implementing, monitoring, reviewing, maintaining, and improving documented ISMS within the context of the .’ overall Business requirements. It specifies the implementation of security controls customized to the needs of XXX.

The ISMS is designed to ensure adequate and appropriate security controls that maintain Confidentiality, Integrity and Availability (CIA) of information assets.

For applicability (with rationale) and exclusion (with justification) of controls refer Statement of Applicability (SOA). The SOA as applicable to XXX is enclosed. As certain controls are not applicable at project sites, project site specific SOA is also made.

1.2 References

The following documents were referred for the creation of this document. These include:

  • ISO/IEC 27001:2013, Information technology – Security techniques – Information security management systems – Requirements

1.3 Terms and Definitions

  • Asset – Anything that has a value to the organization.
  • Availability – The property of being accessible and useable upon demand by an authorized entity.
  • Business Continuity Plan (BCP) – A plan to build-in proper redundancies and avoid contingencies to ensure continuity of Business.
  • Computer Media – Includes all devices that can electronically store information. This includes but not limited to diskettes, CD’s, tapes, cartridges, and portable hard disks.
  • Confidentiality – Ensuring that information is accessible only to those authorized to have access.
  • Continual Improvement – Continual Improvement refers to stage improvement programs that facilitate rapid improvement phases with intermediate stabilized phases.
  • Control – A mechanism or procedure implemented to satisfy a control objective
  • Control Objective – A statement of intent with respect to a domain over some aspects of an organization’s resources or processes. In terms of a management system, control objectives provide a framework for developing a strategy for fulfilling a set of security requirements.
  • Disaster Recovery (DR) – A plan for the early recovery of Business operations in the event of an incident that prevents normal operation.
  • Fallback – Provisions to provide service in the event of failure of computing or communications facilities.
  • Information Security – Security preservation of Confidentiality, Integrity and Availability of Information.
  • Information Security Event – An identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be involved.
  • Information Security Incident – A single or series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security.
  • Information Security Management System (ISMS) – That part of overall management system based on business risk approach, to establish, implement, operate, monitor, review, maintain, and improve information security. The management system includes organizational structure, policies, planning activities, responsibilities, practices, procedures, processes and resources.
  • Integrity – Safeguarding the accuracy and completeness of information and processing methods.
  • Organization – Refers to XXX unless specified otherwise.
  • Risk – The combination of the probability of an event and its consequence.
  • Residual Risk – The risk remaining after risk treatment.
  • Risk Acceptance – Decision to accept risk.
  • Risk Analysis – Systematic use of information to identify sources and to estimate the risk.
  • Risk Assessment – Overall process of risk analysis and risk evaluation.
  • Risk Evaluation – Process of comparing the estimated risk against given risk criteria to determine the significance of the risk.
  • Risk Management – Coordinated activities to direct and control an organization with regard to risk.
  • Risk Treatment – Process of selection and implementation of measures to modify risk.
  • Statement of Applicability – Document describing the control objectives and controls that are relevant and applicable to XXX’s ISMS, based on the results and conclusions of the Risk Assessment and Risk Treatment Processes. It should clearly indicate exclusions with appropriate reasons.

2 About the Manual

This section presents a brief overview of the Information Security Management System (ISMS) manual of XXX.

2.1 Organization of the Manual

The ISMS manual is intended as a reference document describing the security framework adopted by XXX. It is organized as per the Table of Contents.

2.2 Document Availability

This document is available to all employees of the XXX in the form of web page on the intranet. This is a read-only copy and the relevant part of the documentation is available to only authorized users based on their business requirements.

2.3 Document Control Information

It is the responsibility of the XXX to release an approved document for the XXX.

3 Organization Overview

This section presents an overview of the XXX and its operations. XXX mission is to fulfill the promise of applying technology to enable the success of customer business by performing at a level of trust, partnership, and innovation that far exceed what you have come to expect from technology services providers. In the same way, we know that to achieve that aspiration, we must exceed what our professionals have come to expect from technology services employers.

4  Context of the Organization

4.1 Understanding the Organization and it’s Context

XXX shall determine external and internal issues that are relevant for delivering the services from Server Room and Business Operation that affect its ability to achieve the intended results of ISMS. The issues which are considered necessary for delivering the services to internal and external stakeholders are given in the table after section 4.2.

4.2 Understanding the Needs and Expectation from Interested Parties

XXX shall determine the following:

  1. Interested parties that are relevant to ISMS – All customers (Internal and External), Vendors, Supporting the Infrastructure in Server Room & other Business operation, All employees providing & getting services to Server Room & other Business operation.
  2. The requirement of these interested parties relevant to Information Security The needs and expectations from external as well as internal customers are considered as under, and will be reviewed and updated over a period of time as part of continual improvement.
Internal Stake holders Issues
Management Governance, Resource availability,  organization structure, roles and accountabilities,  Policies, objectives, and the strategies
  Employees Fulfillment of commitments, adherence to organization policies, processes and guidelines and to ensure seamless / uninterrupted operations. Expectation of employees in terms of commitment made by the organization need to be fulfilled.
  Shareholders Relationship with, and perceptions and values of, internal stakeholder’s
  Board of Directors  Maintaining commitment to customers, goodwill and repute of the organization, and maintaining return on investment committed on the business, in totality
  Corporate requirements Standards, guidelines and models adopted by the organization
  Users / Other departments Information technology related requirements to the organization such as access right, IT infra availability to internal users and other departments.
  HR Resource availability, resource competence, training, background verification etc.,
  Finance Approval of financial commitments
  Legal Vetting of Legal contracts and protecting the organization from non-compliance of legal, regulatory and contractual requirements
External Customers Service delivery
  Customers Supply of goods and services to enable the organization to meet the requirement of the customer
  Customer Risk Assessment & Risk Treatment Procedure for assessment the risk for internal as well as external customer
  Customer For managing the customer related security aspects, the organization has deployed few policies, process and procedure such as Password Policy, IT Access control Policy, VPN-Virtual Private Network Policy, IEM-Internet & Electronic Messaging Usage Policy, Antivirus Policy, Information Classification, Labeling and Handling Policy, Asset Handling Process, Business Continuity Plan Process, Physical Security Management Procedure and many more.
  Users / Public Information technology related requirements to the organization such as access right, IT infra availability to internal users and other departments.
  Government Submission of desired reports and statements and approvals to carry out the business.  Fulfilling the legal, and regulatory requirement.
  Society and environment  Natural and competitive environment, Key drives and trends having impact on the objectives of the organization, Political, financial status of the country.

4.3 Determining the scope of the Information security management System

The Scope of the ISMS covers,

  • The XXX Server Room, Business Operation and its management
  • To implement the IT services provided to internal and external customers

Server room is located at XXX
(Note: refer to SOA for exclusions)

4.4 Information Security Management System

 XXX shall establish, implement, Maintained and continually improve an information security management system, in accordance with the requirements of ISO 27001:2013.

5 Leadership

This section presents the XXX’s initiative and commitment to effective implementation and operation of ISMS. In addition, this section highlights the roles and responsibilities associated with ISMS operation.

5.1 Leadership and commitment

Top management shall demonstrate leadership and commitment with respect to the information Security management system by:

  1. Ensuring the information security policy and the information security objectives are established and are compatible with the strategic direction of the organization;
  2. Ensuring the integration of the information security management system requirements into the organization’s processes;
  3. Ensuring that the resources needed for the information security management system are available;
  4. Communicating the importance of effective information security management and of conforming to the information security management system requirements;
  5. Ensuring that the information security management system achieves its intended outcome(s);
  6. Directing and supporting persons to contribute to the effectiveness of the information security management system;
  7. Promoting continual improvement; and supporting other relevant management roles to demonstrate their leadership as it applies to their areas of responsibility.

5.2 ISMS Policy

XXX is committed to maintain high quality standards in delivering timely and cost effective solutions to our customers by continual improvement of our processes, instilling quality consciousness amongst all employees and recognizing the confidentiality, integrity and availability of information assets to relevant stakeholders including our customers. Risk management will be done as per ‘CP-05-ISMS-RART-Risk Assessment & Risk Treatment Procedure’ and the risk will be evaluated based on asset value, threat and vulnerabilities. If risk value is high, adequate controls will be implemented.

Action Guideline:

  1. XXX prevents leakage, destruction, and illegal use of all information relating to the customers, vendors, management etc. and builds the system to secure the confidentiality, integrity and availability of the information for daily operations.
  2. Company recognizes the value of the private information of all staff and secures it.
  3. XXX establishes a contingency plan to secure continuation of the business, assuming occurrences of a natural disaster, terrorism, a large scale infection disease etc.
  4. Company provides all staff with proper education and training to maintain and improve the effectiveness of the information security management system
  5. Company builds and manages an organization which grasps incidents, audits its operations and effectiveness of the information security management system, and attempts its continuous improvement.

To secure its information assets and its customer, XXX shall deploy procedures to maintain confidentiality, integrity and availability of all information assets

Business objectives and goals of  XXX  are

  1. Key Objective 1: Provide high quality services to our clients.
  • Goal 1 – Client Satisfaction Score of more than 90 %
  • Goal 2 – On time Delivery >80%
  • Goal 3 – No defects of showstopper/critical type in first release to the client. 
  1. Key Objective 2: Continuous focus on employee satisfaction and competency development so as to reduce and stabilize employee attrition.
  • Goal 1 – A minimum of 3 man days training in a year per employee.
  • Goal 2 Overall attrition rate <15% in year
  • Goal 3 – Employee satisfaction survey score of greater than 75%
  1. Key Objective 3: Continual improvement of services to our internal & external customers.
  • Goal 1 – Key process performance improvement of at least 10% per annum in all departments   
  1. Key Objective 4: To secure its information assets and of its customers, NST shall deploy procedures to maintain confidentiality, integrity and availability of all information assets.
  • Goal 1 – Number of security incidents of high severity to be less than 5% of total security incidents.
  1. Key Objective 5: To have year on year revenue increase while maintaining profitability
  • Goal 1 – Revenue growth of >=40% with respect to the previous financial year
  • Goal 2 – Profit before Tax to be >=20%

To meet these business goals, ISMS objective are defined. Which are given in section 6.2

5.3 Organizational Roles, Responsibilities & Authority for Information Security

XXX is committed to security. The management has constituted Information System Security Committee, which is responsible for defining and improving the ISMS. Management provides evidence of its commitment to the establishment, implementation, operation, monitoring, review, maintenance and improvement of the ISMS as defined in ISMS documentation, by

  1. Establishing an information security policy;
  2. Ensuring that information security objectives and plans are established;
  3. Establishing roles and responsibilities for information security;
  4. Communicating to the organization the importance of meeting information security objectives and conforming to the information security policy, its responsibilities under the law and the need for continual improvement;
  5. Providing sufficient resources to establish, implement, operate, monitor, review, maintain and improve the ISMS;
  6. Deciding the criteria for accepting risks and the acceptable level of risk;
  7. Ensuring that internal ISMS audits are conducted;
  8. Conducting management reviews of the ISMS.

1.SPONSOR 

  • Establishing an ISMS policy & integrated quality policy
  • Ensuring that ISMS objectives and plans are established.
  • Establishing roles and responsibilities for information security.
  • Communicating to the organization the importance of meeting information security objectives and conforming to the information security policy, its responsibilities under the law and the need for continual improvement:
  • Providing sufficient resources to establish, implement, operate, monitor, review, maintain and improve the ISMS.
  • Deciding the criteria for accepting risks and the acceptable levels of risk.
  • Ensuring that internal ISMS audits are conducted
  • Conducting security Committee meetings of the ISMS

2. CHIEF INFORMATION SECURITY OFFICER 

  • Responsible for defining ISMS Framework.
  • Responsible for implementing ISMS Framework
  • Responsible for Publishing ISMS Manual
  • Responsible for ensuring that security incidents are handled and resolved in efficient manner.
  • Define specific roles and responsibilities of information security across the XXX.

3. INFORMATION SYSTEM SECURITY COMMITTEE

  • Develop, maintain, and implement ISMS policies and procedures
  • Develop and maintain Business Continuity Management Plan for the region.
  • Approve and review the risk treatment plan, and accept residual risk
  • Design and deliver awareness program
  • Evaluate, implement and ensure utilization of up-to-date security technology and techniques
  • Review and monitor information security incidents
  • Ensure ISMS is in line with new legal, administrative, and business requirements
  • Ensures that security is part of the information planning process
  • Decide specific methodologies and processes for information security. For e.g. risk assessment, security classification system etc.
  • Drive XXX wide information security initiative
  • Assess new system and services for security before absorbing them into the system and identify and implement appropriate security controls 

4. MANAGEMENT REPRESENTATIVE

  • Responsible for defining policies and processes
  • Responsible for owning the security policy and reviewing and evaluating the same at least once in a year.
  • Responsible for reviewing current implementation of policies and processes and improving them if required
  • Responsible for reviewing security incidents and vulnerabilities and decide action to be taken on them
  • Responsible for reviewing any kind of hacking attacks and action taken to control them
  • Reviewing security audit reports and action taken to resolve NCs
  • Reviewing disciplinary action taken against employee (if there is any such case)
  • Review Backup audit reports and action taken on them.
  • Member of Information system Security Committee.
  • Co-ordinates with Information System Security Committee.
  • Organize security reviews and audits, with internal and external resources
  • Ensure implementation and tracking of ISMS plan
  • Organize management reviews of ISMS
  • To promote awareness amongst employees on ISMS.

5. MANAGER IT

  • Heading IT
  • Heading IT processes
  • Follow up daily tasks and tickets
  • Handling system security incidents and vulnerabilities
  • Handling virus attacks and hacking attacks and reporting them to Security Committee
  • Responsible for reviewing current implementation of policies and processes and improving them if required
  • Responsible for reviewing any kind of hacking attacks and action taken to control them
  • Reviewing security audit reports and action taken to resolve NCs
  • Reviewing disciplinary action taken against employee (if there is any such case)
  • Review Backup audit reports and take action on it
  • Member of Security Committee
  • Managing IT resources
  • To review and prioritize significant information Assets and security threats
  • Incidents Reporting

6. Sr.executive- HR

  • Heading HR Processes
  • Follow up daily tasks and HR Issues
  • Handling employee related incidents (misconducts, policy violations and other offences) and taking appropriate action against employees if required and reporting them to security Committee.
  • Take care of Human resource security clauses prior to employment, during employment and Termination or change of employment.

7. Admin Assistant

  • Heading Admin Processes
  • Follow up daily tasks and Admin Issues
  • Handling employee related admin issue (misconducts, policy violations and other offences) and taking appropriate action against employees if required and reporting them to security Committee
  • Managing Admin resources
  • Physical Security and Physical Access Control

8. MANAGER IT NETWORKS

  • Planning and monitoring networks
  • Handling network issues
  • Network setup and management
  • Reviewing server logs (which includes operator and administrator logs)
  • Client servers Monitoring support
  • Antivirus support
  • Handling network security incidents
  • Handling virus attacks and hacking attacks and reporting them to Information System Security Committee
  • Managing Network resources

9. System administrator

  • Ticket assignment
  • Ticket escalations from engineers
  • IMS Management
  • Data Backups
  • Server usage tracking
  • Helpdesk
  • Reports Management

10. Network Engineer

  • Ticket assignment, Ticket Handling
  • Desktop Issues
  • Maintaining Spare Parts details
  • Maintaining Software upgrade
  • Operating System patch management 

11. Vendors   

  • Provide services as per defined SLA
  • Provide Technical Support
  • Provide resources for upkeep of Data Center

11. Users   

  • Will follow the ISMS Policies
  • Will not share passwords
  • Will use application as per the scopes and access provided
  • Will maintain assets in good condition

The Security Committee will meet once every month, support and supervise the activities of the NST (P) LTD., taking informed decisions. It will be held responsible for achieving measurable progress. Process measurement metrics will be monitored to achieve continuous improvement.

12. Risk Assessment and BCP CORE TEAM

Review, test and reassess the strategy plan to determine the overall approach to business continuity. Responsible for reviewing security incidents and vulnerabilities and decide action to be taken on them

  • Identify and define plans to protect critical business process from the major failure of information system or disasters and to ensure timely resumptions of business activity
  • Review, test and reassess the strategy plan to determine the overall approach to business continuity.
  • Responsible for reviewing security incidents and vulnerabilities and decide action to be taken on them
  • Carry out RA and prepare RTP

Note: – Any two of the four members are mandatory to carry out this activity.

In addition, the group helps reduce the risk of disruption of business operation by providing advice on all aspects of security including:

  • Security Awareness
  • Data Confidentiality and Privacy
  • Logical Access
  • Data Communications
  • Systems and Data Integrity
  • Physical Security
  • Personal and Procedural Controls
  • Contingency and Disaster Recovery Planning

 13. EMPLOYEES

 Expected to follow security policy, processes, and procedures as documented in ISMS.

5.3.1 Security Domains addressed by ISMS

Following are the domains being addressed by ISMS:

  • Security Policy (A.5): Management direction and support for IS in accordance with business requirements and relevant laws and regulations.
  • Organization of Information Security (A.6): Maintain security of information within the organization and its processing facilities that are accessed, processed, communicated to, or managed by external parties.
  • Human Resources Security (A.7): Clear roles and responsibilities, IS awareness and trainings, exiting the organization in an orderly manner.
  • Asset Management (A.8): To appropriately classify and protect the organizational assets.
  • Access Control (A.9): Prevent unauthorized access to information systems, networked services, operating systems, application systems, and ensure IS when using mobile computing and teleworking facilities.
  • Cryptography (A10) deals with cryptographic controls.
  • Physical and Environmental Security (A.11): Preventing unauthorized physical access in the premises and loss/damage/theft of equipment’s.
  • Operational security (A12) Ensuring secured networks, maintaining appropriate third-party service delivery agreements, minimize risk of systems failures, and protect software and information integrity.
  • Communication Security (A13) Deals with Network communication, Information transfer and communication with suppliers.
  • Systems Acquisition, Development and Maintenance (A.14): Prevent errors, loss, unauthorized modification or misuse of information in applications, ensure security of system files and software, and reduce risks resulting from exploitation of published technical vulnerabilities.
  • Supplier Relationship (A.15) Information security in supplier relationship and supplier agreements
  • Information Security Incident Management (A.16): Timely communication of IS events and weaknesses and taking corrective actions.
  • Information Security aspects in Business Continuity Management (A.17): Counteract interruptions to business and protect critical business processes from effects of major failures or disaster, and to ensure timely resumption
  • Compliance (A.18): Complying with legal requirements, security policy and standards.

6 Planning

 6.1 Actions to address risks and opportunities

6.1.1 General

When planning for the information security management system, XXX shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to:

  1. Ensure the information security management system can achieve its intended outcome(s);
  2. relent, or reduce, undesired effects; and
  3. Achieve continual improvement.

XXX shall plan:

  1. Actions to address these risks and opportunities; and
  2. How to
    1. Integrate and implement the actions into its information security management system processes; and
    2. Evaluate the effectiveness of these actions.

6.1.2 Information security risk assessment

XXX shall define and apply an information security risk assessment process that:

  1. establishes and maintains information security risk criteria that include:
    1. the risk acceptance criteria; and
    2. criteria for performing information security risk assessments;
  2. ensures that repeated information security risk assessments produce consistent, valid and comparable results;
  3. identifies the information security risks:
    1. apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system; and
    2. identify the risk owners;
  4. analyses the information security risks:
    1. assess the potential consequences that would result if the risks identified  were to materialize;
    2. assess the realistic likelihood of the occurrence of the risks identified; and
    3. determine the levels of risk;
  5. evaluates the information security risks:
    1. compare the results of risk analysis with the risk criteria established and
    2. Prioritize the analyzed risks for risk treatment.

XXX shall retain documented information about the information security risk assessment process.

6.1.3 Information security risk treatment

XXX shall define and apply an information security risk treatment process to:

    1. select appropriate information security risk treatment options, taking account of the risk assessment results;
    2. determine all controls that are necessary to implement the information security risk treatment option(s) chosen;
      XXX can design controls as required, or identify them from any source.
    3. compare the controls determined in 6.1.3 b) above with those in Annex A of the standard ISO 27001:2013 and verify that no necessary controls have been omitted;

NOTE 1 Annex A of the standard ISO 27001:2013 contains a comprehensive list of control objectives and controls. Users of this International Standard are directed to Annex A of the standard ISO 27001:2013 to ensure that no necessary controls are overlooked.
NOTE 2 Control objectives are implicitly included in the controls chosen. The control objectives and controls listed in Annex A of the standard ISO 27001:2013 are not exhaustive and additional control objectives and controls may be needed.

  1. Produce a Statement of Applicability that contains the necessary controls and justification for inclusions, whether they are implemented or not, and the justification for exclusions of controls from Annex A;
  2. Formulate an information security risk treatment plan; and
  3. Obtain risk owners’ approval of the information security risk treatment plan and acceptance of the residual information security risks. The organization shall retain documented information about the information security risk treatment process.

The details of the RA process can be referred from ‘PROCEDURE FOR RISK ASSESSMENT AND TREATMENT’
The outputs of the RA process include:

  • Risk Assessment Report
  • Risk Treatment Plan
  • Statement of Applicability (inclusion with rationale /exclusion with justification)

Based on the RA report, Information System Security Council prepares the RTP, which includes selection of controls. The XXX then obtains management approval for RTP implementation and acceptance of residual risk.

6.2 Information security objectives and planning to achieve them

 XXX Shall establish information security objectives at relevant functions and levels. The information security objectives shall:

  • be consistent with the information security policy;
  • be measurable (if practicable);
  • take into account applicable information security requirements, and results from risk assessment and risk treatment;
  • be communicated; and
  • Be updated as appropriate.

XXX shall retain documented information on the information security objectives. Following are the ISMS Objectives established by senior management:

ISMS Objectives

  1. Protect information from deliberate or unintentional unauthorized acquisition or unauthorized access
  2. Maintain confidentiality of information.
  3. Maintain integrity of information by protecting it from unauthorized modification.
  4. Availability of information to authorized users when needed
  5. Meet regulatory and legislative requirements
  6. Produce, maintain and test Business Continuity plans as far as practicable.
  7. Train all staff on information security
  8. Report and investigate all breaches of information security and suspected weaknesses
  9. Monitor Risk Treatment Plan and measure effectiveness of selected controls.

When planning how to achieve its information security objectives, the organization shall monitor

  • Uptime of servers and Networks
  • Achievement of preventive maintenance planned schedule
  • Closure of Non conformities in defined time frame
  • Conducting of defined no of awareness program as per the process
  • Monitoring of security incidents as per process of incident Management
  • Mock drills of BCP as per process and achievement of targets :
  • Review of risks as per defined process and closure of actions as per last review.

The templates for each one of them is defined and frequency and thresholds for each of them is defined in the template.  For monitoring and analysis following

  1. Monitoring and measurement of the controls shall be done as per process mentioned in the template..
  2. System Administrator either himself or shall make one of the data center employee responsible for monitor and measurement of controls.
  3. The results from monitoring and measurement shall be analyzed and evaluated at least on monthly basis. However this analysis can be made early depending on the exigencies and system administrator shall decide the same.; and
  4. System Administrator shall analyses and evaluate these results.

7.Support

7.1 Resources

The management provides resources for the implementation, maintenance, and review of the ISMS. The resources include funds, tools, human resources and any other resources that may be required for the efficient performance of the ISMS. Periodically the XXX. evaluates resource requirements for improvements in security infrastructure based on RA, review /audit records. Based on resource requirements, the Management approves/ allocates the required resources.

7.2 Competence

Personnel who have experience and expertise in the application domain and in information security concepts are assigned to manage ISMS. Whenever feasible, experienced individuals are available and allocated appropriate responsibilities. When the required levels of skill and expertise are not available, trainings are provided to ensure skill / knowledge enhancement as per the XXX training process. The ISMS training should form an integral part of training curriculum of HR Dept. in association with Co-ordination Team. Refer PR-10-TRA-Training Process’

  • Identifying what training is needed, and how frequently, for specific positions.
  • Identifying qualified individuals/agency to conduct the training program.
  • Organizing the training program.
  • Maintaining attendance records, course outlines and course feedback of all trainings conducted.

The XXX maintains records of all training programs as mentioned in the training process.

7.3 Awareness

Persons doing work under the organization’s control shall be aware of:

  • the information security policy;
  • their contribution to the effectiveness of the information security management system, including the benefits of improved information security performance; and
  • The implications of not conforming to the information security management system requirements.
  • All updates in organization policies & procedure, which are relevant to their job function

7.4 Communication

Users shall be made aware about the risk of Information Security while exchanging information through Voice, Email, Fax, and Video Communication facility.

What to communicate When to communicate With whom to communicate Who shall communicate Processes by which communication shall be effected.
Technical Matters To seek clarification, communicate execution and discussing options of delivery Customer Delivery Manager / Technical Lead Email / Video Call/Phone
Non-Technical Business Development when communicating upgrades / updates and offers of NST Customer Account Manager Email / Video Call/Phone
Financial Information such as Invoices, Payment reminder, Proposal, upgrade offer etc. As and when the event takes place Customer Accounts Manager Email / Video Call/Phone
Technical Matters To get the action initiated on completion of delivery Accounts Manager / Business Head Delivery Manager / Technical Lead Email / Video Call/Phone
Performance Report Monthly / quarterly Business Head Account Manager and Delivery Manager PPT / Word / Excel  – Email/Phone
Technical Matters As and when the event takes place Project Manager Developer/Tester PPT / Word / Excel  – Email/Phone
Network Security Matters As and when the event takes place IT Team Employees Email/ Phone/ Face to Face
Server Security Matters As and when the event takes place IT Team Employees Email/ Phone/ Face to Face
Application Security Matters As and when the event takes place IT Team or PM Employees Email/ Phone/ Face to Face
Physical Security Matters As and when the event takes place Admin Employees Email/ Phone/ Face to Face

7.5 Documented information

7.5.1 General

The organization’s information security management system shall include:

  1. Documented information required by this International Standard; and
  2. Documented information determined by the organization as being necessary for the effectiveness of the information security management system.

NOTE: The extent of documented information for an information security management system can differ from one organization to another due to:

  1. The size of organization and its type of activities, processes, products and services;
  2. The complexity of processes and their interactions; and
  3. The competence of persons.

 7.5.2 Creating and updating

When creating and updating documented information the organization shall ensure appropriate:

  1. Identification and description (e.g. a title, date, author, or reference number);
  2. Format (e.g. language, software version, graphics) and media (e.g. paper, electronic); and
  3. Review and approval for suitability and adequacy.

7.5.3 Control of documented information

Documented information required by the information security management system and by this International Standard shall be controlled to ensure:

  1. it is available and suitable for use, where and when it is needed; and
  2. it is adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity).

For the control of documented information, the organization shall address the following activities, as applicable:

  1. distribution, access, retrieval and use;
  2. storage and preservation, including the preservation of legibility;
  3. control of changes (e.g. version control); and
  4. Retention and disposition.

Documented information of external origin, determined by the organization to be necessary for the planning and operation of the information security management system, shall be identified as appropriate, and controlled. Access implies a decision regarding the permission to view the documented information only, or the permission and authority to view and change the documented information, etc. To meet the requirement of 7.5, the documentation structure of Information security management System is as detailed below:

The components of ISMS Documentation are:
Level – 0 Corporate Information System Security Policy): It is the Top-level security policy of the XXX.
Level – 1 ISMS Manual): This document includes requirements of the ISO/IEC 27001:20132013 standard, and describes how the defined ISMS meet the requirements. The document details the XXX. approach towards management and implementation of ISMS.
Level – 2 Supporting Policies & Guidelines A complete set of supporting technical policies and guidelines as identified and defined by the XXX. within the scope of ISMS.
Level – 3 Procedures and Processes – Contains processes and procedures required for implementing and supporting the defined policies & guidelines.
Level – 4 Templates and Forms –XXX standard templates/forms used in the processes / procedures. These are used to streamline the operation of ISMS and form a basis for records.

Control of Documents

All documents related to ISMS requirements are controlled as per CP-03-ISMS-DRM-Document & Record Management Procedure. This includes:

  • Review and approval of documents for adequacy prior to issue / use
  • Updating, review and approval of necessary changes in controlled documents
  • Availability of current revisions of necessary documents
  • Withdrawal of obsolete documents from all points of issue or use to ensure guarding against unintended use.
  • All security documents are available on the Intranet for reference and use based on need-to-know requirements.
  • Any document if printed is considered obsolete. However, this excludes all the documents related to ‘Business Continuity Plan

Control of Records

Records are identified within each procedure in the ISMS to provide evidence of conformance to requirements and effective functioning of the ISSC. Master list of records is maintained. Refer ‘List of Format-Content Master’. Other attributes shall be as per PO-12-ISMS-CLH-Information Classification, Labeling and Handling Policy.docx

8 Operation

8.1 Operational planning and control

8.1.1 Implement and Operate the ISMS

Selected control objectives, and controls that are a part of RTP are implemented effectively in XXX and they are also capable of enabling prompt detection of and response to security incidents. XXX ensures that proper training and awareness on ISMS are conducted, and appropriate resources are assigned to manage ISMS. XXX maintains a suitable matrix of risk / incidence reduction against its major controls identified every year for monitoring purposes to ensure effectiveness of selected controls. Logs of risk reduction and/or incidence reduction are maintained for results comparison and reproduction.

8.1.2 Monitor and Review the ISMS

XXX. ensures that ISMS is properly monitored and reviewed periodically.

  1. For monitoring incidents, the XXX. has a well-defined Incident Management Procedure, which ensures that all problems, errors identified during processing of any information are handled promptly and effectively, and breach of security is appropriately addressed. Refer ISMS-IMP-Incident Management Process.
  2. A process for conducting Management Reviews and audit procedure of ISMS exists. The focus of the review is to ensure that ISMS is effective, and all policies, controls and security objectives are in line with business requirements. The audit focuses on the compliance of XXX’s practices as defined in ISMS. Refer ‘SEPG & ISMS Plan’
  3. Information System Security Committee reviews the level of residual and acceptable risks based on the changes in the deployed technology, new threats and vulnerabilities and business objectives. Refer CP-05-ISMS-RART-Risk Assessment & Risk Treatment Procedure
  4. The controls at appropriate intervals are monitored against the logs generated to arrive at the current risk exposure. This is compared with previous risk level to verify the effectiveness of controls. Refer ‘CEM-Control Effectiveness Measurement Process’

8.1.3 Maintain and Improve the ISMS

Based on the review reports and audit findings, appropriate corrective and preventive actions, as approved by the Information System Security Committee are implemented and incorporated into the ISMS. Inputs for improvement can be from:

  • Audit Reports
  • Management Review Reports
  • Incident Reports
  • RA report
  • Business Changes (Objectives, process, industry practices, legal/regulatory, etc)
  • Environmental Change (New threats and vulnerabilities, technology Changes, etc.)

XXX. maintains all inputs in an improvement database available for internal use’s XXX. consolidates the inputs, and reviews the ISMS for applicable improvements. For changes to be made, XXX prepares an action plan and communicates the results to all interested /affected parties. All improvements should be directed towards predefined organizational Business objectives.

8.2 Information security risk assessment

 The organization shall perform information security risk assessments at planned intervals or when significant changes are proposed or occur, taking account of the criteria established .  The organization shall retain documented information of the results of the information security risk assessments.

8.3 Information security risk treatment

 The organization shall implement the information security risk treatment plan. The organization shall retain documented information of the results of the information security risk treatment.

9 Performance evaluation

9.1 Monitoring, measurement, analysis and evaluation

XXX shall evaluate the information security performance and the effectiveness of the information security management system. XXX shall determine:

  1. what needs to be monitored and measured, including information security processes and controls;
  2. the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results;
  3. The details of what needs to be measured is given in. The methods selected should produce comparable and reproducible results to be considered valid.
  4. Monitoring and measurement of the controls shall be done on daily basis.
  5. System Administrator either himself or shall make one of the data center employee responsible for monitor and measurement of controls.
  6. The results from monitoring and measurement shall be analyzed and evaluated at least on monthly basis. However this analysis can be made early depending on the exigencies and system administrator shall decide the same.; and
  7. System Administrator shall analyze and evaluate these results.

 XXX shall retain appropriate documented information as evidence of the monitoring and measurement results. The templates where these evidences are maintained are defined in ‘ISMS-CEM-Control Effectiveness Measurement Process.docx’

9.2 Internal Audits

MR conducts internal ISMS audits quarterly to verify the adherence to ISMS. The audits are conducted to ensure that ISMS:

  • Conforms to the requirements of the ISO/IEC 27001:2013 standard
  • Ensure compliance with relevant legal, statutory and contractual requirements
  • Conform to the identified information security requirements
  • ISMS is effectively implemented and maintained
  • Performs as expected

Security Audits are conducted in accordance with the audit procedure defined in NST-CP-06-ISMS-IAP-Internal Audit Procedure’. Trained personnel, not having direct responsibility of the activity being audited, shall conduct audits. MR with the help of HODs will ensure that any non-conformance found is closed. MR is responsible for planning, scheduling, organizing and maintaining records of these audits.

9.3 Management Review

Top management shall review information security management system once every three months, or on an event-driven basis, to ensure its continuing suitability, adequacy and effectiveness. The management review shall include consideration of:

  1. The status of actions from previous management reviews;
  2. Changes in external and internal issues that are relevant to the information security management system;
  3. Feedback on the information security performance, including trends in:
  4. nonconformities and corrective actions;
  5. monitoring and measurement results;
  6. audit results; and
  7. Fulfilment of information security objectives;
  8. feedback from interested parties;
  9. Results of risk assessment and status of risk treatment plan; and
  10. Opportunities for continual improvement.

The outputs of the management review shall include decisions related to continual improvement opportunities and any needs for changes to the information security management system. XXX shall retain documented information as evidence of the results of management reviews.

10 Improvement

10.1 Non conformity and Corrective Action

 When a nonconformity occurs, XXX shall:

  1. react to the nonconformity, and as applicable:
    1. take action to control and correct it; and
    2. deal with the consequences;
  2. evaluate the need for action to eliminate the causes of nonconformity, in order that it does not recur or occur elsewhere, by:
    1. reviewing the nonconformity;
    2. determining the causes of the nonconformity; and
    3. determining if similar nonconformities exist, or could potentially occur;
  3. implement any action needed;
  4. Review the effectiveness of any corrective action taken; and
  5. Make changes to the information security management system, if necessary.

Corrective actions shall be appropriate to the effects of the nonconformities encountered. The organization shall retain documented information as evidence of:

  1. The nature of the nonconformities and any subsequent actions taken, and
  2. The results of any corrective action.

The procedure is created, for implementing and tracking the correcting action. Refer ‘CAPA-Corrective & Preventive Action Procedure’.

10.2 Continual Improvement

XXX is responsible for continual improvement of the ISMS for suitability and effectiveness. Inputs to continual improvement can be:

  • Change in security policies and objectives
  • Audit results and Management Review Reports
  • Incident Reports
  • Analysis of monitored events
  • Corrective and Preventive Actions
  • Business Changes
  • Environmental Change (New threats and vulnerabilities)
  • Best practices of industry

 11 ISMS Controls

This section describes the selection and implementation of controls by xxx. The control objectives and controls listed in this section are directly derived from the ISO/IEC 27001:2013 standard, based on Section 5.3.1 – Security Domains addressed in ISMS’ of this document. Controls applicable to XXX. have been mentioned and addressed in this section. Controls not applicable to XX. are mentioned in this section and exclusion with justification given in SOA. Refer ISO27001-2013-SOA-V2.0.xlsx

A.5 Information Security policies

The Information Security Policy establishes requirements to ensure that information security controls remain current as business needs evolve and technology changes. This policy is published and communicated to all employees and relevant external parties.

A.5.1 Management Direction for Information Security

The Chief Information Officer is responsible for establishing, issuing and monitoring information security policies.

Control Objective: To provide management direction and support for information security in accordance with business requirements and relevant laws and regulations.

A.5.1.1 Information Security Policy Document

A Corporate Information System Security Policy document approved by the management exists. Information security policy  has been published and communicated to all employees of XXX through the Intranet and mails, training and induction programs.The Information Security Policy contains operational policies, standards, guidelines and metrics intended to establish minimum requirements for the secure delivery of our Products/ services. Secure service delivery requires the assurance of confidentiality, integrity, availability and privacy of  information assets through:

  • Management and business processes that include and enable security processes;
  • Ongoing employee awareness of security issues;
  • Physical security requirements for information systems;
  • Governance processes for information technology;
  • Defining security responsibilities;
  • Identifying, classifying and labelling assets;
  • Ensuring operational security, protection of networks and the transfer of information;
  • Safe-guarding assets utilized by third parties;
  • Reporting information security incidents and weaknesses;
  • Creating and maintaining business continuity plans; and,
  • Monitoring for compliance.

The Chief Information Officer recognizes that information security is a process, which to be effective, requires executive and management commitment, the active participation of all employees and ongoing awareness programs.

A.5.1.2 Review of the policies for information security

The Information Security Policy must be reviewed on an annual basis and updated when required. The Purpose is too ensure information security policies remain current with evolving business needs, emerging risks and technological changes.

XXX. is responsible for the creation, maintenance and updating of the policy.  Information System Security Committee approves the policy prior to release. The review and evaluation of ISMS policy is conducted at least once in a year. The review guidelines state that the policy is to be reviewed against its effectiveness, compliance to business process, and compliance to technology changes. The Chief Information Officer is responsible for reviewing information security policies, standards and guidelines on an annual basis. Policies and standards reviews must be initiated:

  • In conjunction with legislative, regulatory or policy changes which have information security implications;
  • During planning and implementation of new or significantly changed technology;
  • Following a Security Threat and Risk Assessment of major initiatives (e.g., new information systems or contracting arrangements);
  • When audit reports or security risk and controls reviews identify high risk exposures involving information systems;
  • If threat or vulnerability trends produced from automated monitoring processes indicate the probability of significantly increased risk;
  • After receiving the final report of investigation into information security incidents;
  • Prior to renewing third party access agreements which involve major programs or services;
  • When industry, national or international standards for information security are introduced or significantly revised to address emerging business and technology issues; and,
  • When associated external agencies (e.g., Information and Privacy Commissioner, Ministry on Information Technology) issue reports or identify emerging trends related to information security.

A.6 Organization of Information Security

This  describes the management structure needed to coordinate information security activities, including who coordinates them and what agreements are required. Coordination of information security activities requires the support of a network of contacts in the information security community to elicit advice, monitor trends and deal with other external factors.

A.6.1 Internal organization

Control Objective: To manage information security within XXX.

A.6.1.1 – Information Security Roles and responsibilities

The Purpose is to ensure employees are informed of their information security roles and responsibilities. Security roles and responsibilities of employees, contractors and third party users are defined and documented in accordance with the organization’s information security policy. Security roles and responsibilities for employees must be documented.
a) Security roles and responsibilities
b) Communication of security roles and responsibilities

a) Security roles and responsibilities
Employees must be aware of their information security roles and responsibilities. Information Owners and Information Custodians must:

  • Document information security roles and responsibilities for employees in job descriptions, standing offers, contracts, and information use agreements where relevant; and,
  • Review and update information security roles and responsibilities when conducting staffing or contracting activities.

b) Communication of security roles and responsibilities
Supervisors must ensure employees are informed of their security roles and responsibilities by establishing processes for communicating security roles and responsibilities to protect information assets

A.6.1.2 – Segregation of duties

The Purpose is to reduce risk of loss, fraud, error and unauthorized changes to information.  In XXX duties have been segregated in order to reduce the risk of accidental or deliberate system misuse. Different individuals are responsible for their respective areas, and proper controls exist that take care of possibility of fraud in areas of single responsibility without being detected. Different areas and associated responsibilities are defined as per Roles and Responsibilities. Day to day administration & maintenance of IT Infrastructure is done by IT Department & HOF/IT review different logs & conduct periodic VA. Duties and areas of responsibility must be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of information systems.
a) Segregation of duties
b) Critical or sensitive information systems.

a) Segregation of duties
Information Owners must reduce the risk of disruption of information systems by:

  • Requiring complete and accurate documentation for every information system;
  • Requiring that no single individual has access to all operational functions of an information system (e.g., operating system administrators must not also have application administrator privileges);
  • Rotating job duties periodically to reduce the opportunity for single individuals to have sole control and oversight on key systems;
  • Automating functions to reduce the reliance on human intervention for information systems;
  • Requiring that individuals authorized to conduct sensitive operations do not audit the same operations;
  • Requiring that individuals responsible for initiating an action are not also responsible for authorizing that action; and,
  • Implementing security controls to minimize opportunities for collusion.

b) Critical or sensitive information systems
Where supported by a Security Threat and Risk Assessment or other formal assessment, Information Owners must employ two-person access control to preserve the integrity of the information system.

A.6.1.3– Contact with authorities

The Purpose is to facilitate timely response from and co-ordination with outside authorities during information security incidents or investigations. Appropriate contacts shall be maintained with local law enforcement authorities, emergency support employees.Appropriate contacts/ agreements are maintained with the following but not limited to:

Services                                                                      Responsibility 

  • Internet Service Provider (ISP)                                Head/IT
  • Hardware Maintenance contracts Head/IT
  • Telecom services department Head/IT
  • Electricity services department Admin/HR
  • Local Enforcement Agencies like Police, Fire Admin/HR

Responsibility for any other services which fall under Information Security preview, but not mentioned above, is assigned to Head/IT. This is necessary to ensure that appropriate actions can be promptly taken, and advice obtained in the event of any security incident. Organization’s legal department is consulted for all third party contracts and agreements. The Chief Information Security Officer must ensure that outside authorities, emergency support employees can be contacted by:

  • Maintaining and distributing as appropriate, a list of internal and external organizations and service providers.
  • Documenting emergency and non-emergency procedures for contacting authorities as required during information security incidents or investigations.

A.6.1.4 – Contact with special interest groups

The Purpose is to promote and further employee knowledge of information security industry trends, best practices, new technologies and threats or vulnerabilities. Appropriate contacts shall be maintained with specialist security forums and professional associations. Information security advice is obtained from vendors, legal advisors and technical experts on security matters to maximize the effectiveness of the ISMS. Internally MR shall act as Security Advisor. External advice shall only be sought by MR if required. All security incidents and breaches are reported to MR for necessary corrective and preventive actions. Information security specialists must maintain their knowledge of information security industry trends, best practices, new technologies and threats or vulnerabilities by:

  • Participating in information exchange forums regarding best practices, industry standards development, new technologies, threats, vulnerabilities, early notice of potential attacks, and advisories;
  • Maintaining and improving knowledge regarding information security best practices; and
  • Creating a support network of other security specialists.

The Chief Information Security Officer must promote professional certification and membership in professional associations for information security specialists throughout government.

A.6.1.5 – Information Security in Project Management

The Purpose is to ensure that information security risks are identified and addressed throughout the project life-cycle. Project Planning, Where projects involve information or information technology assets the information security is addressed in project management. Information Owners and Information Custodians must integrate information security into every phase of the organization’s project management method(s) to ensure that information security risks are identified early and addressed as part of the entire project. The project management methods in use should require that:

  • Information security objectives are included in project objectives;
  • An information Security Threat and Risk Assessment is conducted at an early stage of the project to identify necessary controls;
  • Information security is part of all phases of the applied project methodology.

Information security implications should be reviewed regularly in all projects. Responsibilities for information security should be defined and allocated to specified roles defined in project management methods.

A.6.2 Mobile Devices and Tele Working

Control Objective: To ensure information security when using mobile computing and teleworking facilities.

 A.6.2.1 – Mobile Device Policy

The Purpose is to protect information stored on mobile devices from loss or unauthorized access. XXX. has well defined policy and guidelines on the use of laptops. Refer ‘PR-17-ISMS-AHP-Asset Handling Process.docx’.Appropriate controls must be implemented to mitigate security risks associated with the use of mobile devices.
a) Information protection paramount
b) Service-specific risks and practices
c) Protection of credentials
d) Protection of network endpoint and physical device
e) Human factors
f) Risk assessment factors

a) Information protection paramount
The use of mobile devices such as laptops, tablets or smartphones to access, store, or process information increases the risk of information compromise. Mobile devices are typically small and portable, used in uncontrolled public environments, and easily lost, stolen or damaged. Information Owners  must ensure that use of mobile devices is managed and controlled. To ensure that sufficient safeguards are implemented to mitigate risks mobile devices must be enrolled in Mobile Device Management Service. Users of mobile devices must protect the information and information technology assets in their custody or control.

b) Service-specific risks and practices
Providers of mobile computing services (such as Technology Services Division) must perform regular risk assessments to identify service-specific risks (e.g., perform or update the risk assessments on an annual basis). Information Owners and Information Custodians must develop, document and maintain policies, standards, practices and guidelines that address these risks, and communicate them to employees.

c) Protection of credentials
User identifiers and user credentials must be protected to reduce the risk of unauthorized access to information and information technology assets. In particular, employees must protect against visual eavesdropping of passwords, PINs and other credentials, especially when in public places.

d) Protection of network endpoint and physical devices
Mobile devices are typically used to store information or remotely access government networks and services. The policies and procedures governing remote access apply to mobile devices. Where Remote Access services are used, the mobile device must be configured to prevent its use as a conduit between the non-government and government networks (e.g., VPN split tunneling must be disabled). Network access to mobile devices from non-government networks must be blocked by implementation of firewall or filtering technologies to protect against attack (e.g., to prevent network attacks against the mobile device). Mobile devices must be protected against mobile and malicious code. Mobile devices must be locked and/or secured when unattended to prevent unauthorized use or theft (e.g., use device locks, cable locks, physical container locks, PINs or screensaver locks).

e) Human factors
Information Owners and Information Custodians must provide employees using mobile devices with security awareness training to ensure that they are:

  • Aware of the additional risks and responsibilities inherent in mobile computing and when using mobile devices;
  • Familiar with operation of the protection technologies in use; and,
  • Familiar with the Information Incident Management Process.

f) Risk assessment factors
The Security Threat and Risk Assessment must consider threats to information and information technology assets, such as:

  • Physical theft;
  • Use of mobile devices to remotely access Government networks and systems;
  • Data interception;
  • Credential theft;
  • Unauthorized device use;
  • Device disposal;
  • Information disposal;
  • Covert key logging or password harvester programs; and,
  • Malicious and mobile code.

Information classification and sensitivity levels must be considered in the risk assessment. Storage of government information on mobile devices must be avoided and is allowed only in extenuating circumstances, as defined in the Appropriate Use Policy. Minimum information protection safeguards for the use of mobile devices must include:

  • Encryption of stored data to prevent information loss resulting from the theft of the mobile or remote device;
  • Encryption of data transmitted via public network;
  • Access control permissions on a mobile device to prevent unauthorized access to information by system users, particularly for multi-user mobile systems;
  • Regularly maintained data backups of information stored on mobile devices using government backup facilities to protect against information loss;
  • Physical security of the device at all times to protect against asset and information loss;
  • User authentication to the mobile device and user authentication for remote access from the device in accordance with authentication policies.

A.6.2.2 – Teleworking

The Purpose is to protect information accessed through teleworking arrangements from loss or unauthorized access .XXX. has a well-defined policy and guideline on the use of laptops for teleworking purposes.Teleworking must employ security controls to ensure that information resources are not compromised.
a) Teleworking security controls
b) Teleworking agreement
c) Ad hoc teleworking policy

a) Teleworking security controls based on risk assessment
Information Owners must ensure that information and information technology assets are adequately protected regardless of the type of access or physical location of employees. Teleworking security controls must consider:

  • The sensitivity and classification of information assets that may be accessed or stored at the teleworking location (e.g., paper files, mobile devices such as laptops, smartphones, USB drives);
  • The physical security of information, information technology assets and the teleworking location;
  • Unauthorized information access by people at the teleworking location, either inadvertent or deliberate;
  • Enrollment in Mobile Device Management Service;
  • Remote access threats if remote access is utilized;
  • Restriction of permitted information types and classifications at the teleworking location;
  • Provision of government-managed equipment, if appropriate, due to information sensitivity or volume;
  • Use of secure cabinets, shredders and other physical security equipment;
  • Security awareness training for protection of information and information assets, including clear desk policy, information handling rules, physical security issues and remote access training;
  • Monitoring and review of teleworking equipment for security events and incident response.
  • Sensitive and confidential information must be stored only on protected organizations systems, as defined in the Appropriate Use Policy.

b) Teleworking agreement
Teleworking arrangements must be formally authorized and documented. A documented teleworking agreement between the employer and employee must exist that specifies the following employee responsibilities, terms and conditions: 

The expectation that the employee will actively protect information and information technology assets;
 Reference to the BC Public Service Agency Human Resource Policies, Oath of Employment, Standards of Conduct, Appropriate Use Policy, Information and Communications Technology (ICT) Agreement, or contract terms as appropriate;

  • Restrictions on information asset types or classifications permitted at the teleworking location.
  • The requirement to protect information from inadvertent or deliberate disclosure to people at the teleworking location by use of secure cabinets, passwords or shredders;
  • The authorized teleworking location and contact information;
  • Information availability requirements;
  • What equipment and software is supplied by the employee and by the employer;
  • Completion of a Home Technology Assessment;
  • The terms of use for remote access, if applicable;
  • The requirement to meet or exceed specified wireless networking security controls, if wireless networking will be used at the teleworking location;
  • The requirement to report security events or unusual activity;
  • Arrangements for technical support; and,
  • The start date, end date, expected work hours and provision for termination of the teleworking arrangement.

c) Ad hoc teleworking policy
Ministries must develop and communicate policies and processes specific to their areas that govern ad hoc teleworking, in particular the practice of removing material from the workplace. Controls required for an ad hoc teleworking policy are:

  • Restriction of the information asset types and classifications that may be accessed or utilized while teleworking;
  • Use of secure cabinets, shredders and other physical security equipment; and,
  • Minimum technical security controls required for non-government computing equipment, in particular current anti-virus, personal firewall and current software patches.

Guidelines:
Teleworking employees should use the following security measures when accessing government information services:

  • Desktop Terminal Service (DTS) – preferred access method for non-government devices;
  • DTS or Virtual Private Network (VPN) for government devices; and
  • Application specific methods such as Secure Sockets Layer (SSL) enabled websites (e.g., Outlook Web Access).
  • Use of VPN access on non-government devices should be avoided, unless it is used with Remote Desktop Protocol (RDP) connection.

 A.7 Human Resource Security

This identifies the information security requirements for employees that have an employment relationship with government organizations. To reduce information security risks, the terms and conditions of employment must establish expectations for the protection of assets, information and services.It references the terms and conditions  for employees and identifies the conditions for external personnel such as contractors. Supervisors and employees have different security responsibilities and liabilities that apply prior, during, and at the time of termination of employment. Prior to employment, emphasis is on the awareness of expected roles and responsibilities, the screening of prospects and the existence of agreements. During employment, policies establish Supervisor responsibilities, education, training and formal processes to handle problematic security situations. This also establishes rules to ensure a secure transition when employment is ended or changed.

A.7.1 Prior to employment

Control objective: To ensure that employees, contractors and third party users understand their responsibilities, and are suitable for the roles they are considered for, and to reduce the risk of theft, fraud or misuse of facilities.

A.7.1.1 –Screening

The Purpose is to verify employment qualification claims made by prospective employees. XXX. has a documented recruitment process. The screening requirements form part of contract agreement with vendors. Employee security screening must be performed prior to entering a working relationship with the organization.
a) Screening for employees
b) Screening for contractors

a) Screening for employees
The process for employee screening is detailed in  Human Resource Policies.
b) Screening for contractors
The process for contractor screening is detailed in Core Policy and Procedures Manual – Procurement.

Guidelines:
The process for contractor screening can be used to screen other individuals such as volunteers. Applicants should be screened to assess their education, skills, knowledge, experience and past work performance. The screening should also confirm the applicant’s identity. The extent of the screening process should be commensurate with the sensitivity of the information and nature of work to be performed.
XXX may exempt applicants from the screening process where:

  • Employees have been previously screened for similar types of organizational work within the last 2 years; or,
  • The sensitivity of the information and nature of work to be performed does not warrant a complete screening process.
  • Procurement Manager should maintain a list of contractors and other individuals who have been screened and the dates.

A.7.1.2 – Terms and conditions of employment

The Purpose is to establish the terms and conditions of employment for information and information systems security. All employees of, XXX., at the time of joining, are required to agree and sign the Terms and Conditions of employment as detailed in Recruitment Process. The Terms and Conditions also state the employees’ responsibility for Information Security. The terms and conditions of employment must document the responsibility of employees for information and information systems security.
a) Terms and conditions of employment
b) Communication of terms and conditions of employment
c) Violation of terms and conditions of employment

a) Terms and conditions of employment
The terms and conditions of employment are defined in the Human Resource Policies, the Oath of Employment and the Standards of Conduct.The terms and conditions of employment defined in contracts must include:

  • Legal responsibilities and rights (e.g., laws relating to intellectual property rights, freedom of information, and privacy);
  • Confidentiality requirements that include responsibilities for the handling and storage of information assets; and,
  • Consequences of failing to adhere to the terms and conditions.

b) Communication of terms and conditions of employment
The Management must ensure terms and conditions of employment are agreed to by employees prior to employment or provision of services, including signing the Oath of Employment and receiving a copy of the Standards of Conduct.

c) Violation of terms and conditions of employment
Employees in violation of the terms and conditions of employment are subject to disciplinary action including dismissal, cancellation of contract or other legal remedies

A.7.2 During employment

Control Objective: To ensure that all employees, contractors and third party users are aware of information security threats and concerns, their responsibilities and liabilities, and are equipped to support organizational security policy in the course of their normal work, and to reduce the risk of human error.

A.7.2.1 – Management responsibilities

The Purpose is to establish Supervisor responsibilities for ongoing support and implementation of information security. Management shall require employees, contractors and third party users to apply security in accordance with established policies and procedures of the organization. Management must ensure employees comply with information security policies and procedures.
a) Management responsibilities
b) Review of security roles and responsibilities

a) Management responsibilities
Management must support the implementation of information security policies and practices by:

  • Ensuring employees are informed of information security roles and responsibilities prior to being granted access to information or information systems;
  • Supporting and encouraging employees to adhere to information security policies; and,
  • Requiring that employees conform to the terms and conditions of employment, including information security policies.

b) Review of security roles and responsibilities
Information security roles and responsibilities must be reviewed when staffing or restructuring public service or contract positions, or when implementing new, or significant changes to, information systems.

Guidelines:
Management should annually review and validate information security roles and responsibilities in job descriptions, standing offers, contracts and information usage agreements.

A.7.2.2 – Information security awareness, education and training

The Purpose is to increase employee awareness and understanding of security threats, risks and concerns and information security policies and procedures.  XXX.  ensures that users (employees and the relevant external parties) are made aware of their security responsibilities through ongoing awareness training programs. All employees are to adhere them while executing the Roles and Responsibilities as defined. A documented procedure for training exists. XXX., in association with HR Dept. ensures that all, personnel are imparted ISMS related training and that a training module on Information security policies becomes an integral part of induction training programs. Employees must receive appropriate information security training and be informed of changes to information security policy and practices.
a) Orientation for new employees
b) Ongoing information security awareness, education and training

a) Orientation for new employees
The management will include an information security awareness component in orientation processes that employees must complete prior to accessing information or information systems.

b) Ongoing information security awareness, education and training
Department heads must provide ongoing information security awareness, education and training, addressing topics including:

  • Protection of information;
  • Information privacy requirements;
  • Records management;
  • Known information security threats;
  • Legal responsibilities;
  • Information security policies and directives;
  • Reporting information security events;
  • Appropriate use of government resources;
  • Technology training;
  • Information on disciplinary processes; and,
  • How to obtain security advice.

Guidelines:
Resources on information security awareness, education and training are available from:

  • Information Security Officers;
  • Manager, HR department

A.7.2.3 – Disciplinary process

The Purpose is to ensure a process is in place to review the activities of employees who commit an information security breach or policy violation. Any violation of the signed documents is considered as a disciplinary offence and as such act as a deterrent to employees who might otherwise be inclined to disregard security procedures.  The procedure shall ensure correct, fair treatment for employees who are suspected of committing serious or persistent breaches of security. It is addressed by the reference to XXX. Conduct, Disciplinary and Appeal (CDA) Rules. Security breaches or policy violations caused by employees must be reviewed by the HOD.

Upon receipt of information identifying employees responsible for a potential or actual security breach or policy violation, HODs are responsible for:

  • Ensuring the Chief Information Officer has been informed of the outcome of the security incident and investigation;
  • Assisting in an investigation and verifying the details of the security breach or policy violation;
  • Determining, in consultation with the HR, if disciplinary action is warranted for employees; and,
  • Arranging for permanent or temporary removal of access privileges when appropriate.

 A.7.3 Termination or change of employment

Control Objective: To ensure that employees, contractors and third parties exit, XXX. or change employment in an orderly manner.

A.7.3.1 – Termination or change of employment responsibilities

The Purpose is to ensure information security responsibilities upon termination of employment are defined and assigned. Responsibilities for performing employment termination or change of employment are clearly defined and assigned. Refer to XXX. Conduct, Disciplinary and Appeal (CDA) rules. The Responsibilities for employment termination must be documented. Supervisors must advise employees of ongoing confidentiality responsibilities that continue to apply after termination of employment, as outlined in the Standards of Conduct.

A.8 Asset Management

Information and information systems services constitute valuable government resources. The asset management establishes the blueprint to identify the rules of acceptable use and the rules for protection: what assets to protect, who protects them and how much protection is adequate. To account for the assets that require protection, it specifies the requirement to designate who owns assets. Designated owners become responsible for protecting information and technology assets and to maintain the way assets are protected. It sets the foundation for a system that classifies information to identify different security levels, to specify how much protection is expected and how information should be handled at each level. Not all information requires the same level of protection because only some information is sensitive or confidential.

A.8.1 Responsibility for assets

Control Objective: To achieve and maintain appropriate protection of XXX and its assets.

A.8.1.1 – Inventory of assets

The Purpose is to identify organizational information assets and define appropriate protection responsibilities.

XXX.’s Assets have been classified as:

  • Hardware – Includes computer equipment (CPU, Peripherals etc.), communication equipment (routers, switches, etc.), magnetic media (CDs, Tapes, Disks), UPS/Inverters / power backup devices/Battery Bank, Air conditioner, Fire extinguisher etc.
  • Software – Includes various applications programs, system software, development tools and utilities.
  • Information –Databases, data files, archived information, documentation.
  • Services – Include communication services, general utilities like power, AC, Buildings (Rent Agreement- Renewal) Services (provided by org external/internal the group) etc.
  • Management System- Includes Borrowed Information, Copyright/IPR, The whole Organization
  • Human Resource- That include Technical Manpower & Administrative manpower

An inventory of all assets is maintained by the IT department in the form of . maintains appropriate protection of the organizational assets. It aims at confidentiality, integrity and availability. An inventory of all important assets associated with information systems must be documented and maintained.
a) Identification of assets
b) Documenting and maintaining asset inventories
c) Loss, theft or misappropriation of assets

a) Identification of assets
Information Owners must identify assets under their control including:

  • Software;
  • Hardware including mobile devices and tablets;
  • Services including computer and communications services and general utilities;
  • Information assets required to be inventoried in the personal information directory (required under the Freedom of Information and Protection of Privacy Act);
  • All other information assets including: database and data files, contracts and agreements, system documentation, research information, user manuals, training material, operational or support procedures, continuity plans, fallback arrangements, and archived information.

b) Documenting and maintaining asset inventories
Information Owners must document, maintain and verify asset inventories on a regular basis, depending on the criticality and value of the assets, and validate the measures taken to protect the assets as part of an enterprise risk management strategy. Information Owners must document, maintain and verify the personal information directory including the personal information bank and privacy impact assessment sections. The following information should be recorded to facilitate system planning and asset recovery in the case of interruption, corruption, loss, disposal or destruction:

  • Type of asset;
  • Ownership;
  • Format;
  • Location;
  • Back-up information and location;
  • License information;
  • Sensitivity and safeguards requirements;
  • Criticality for service delivery and maintaining business functions; and,
  • Consequences of loss.

Information Owners and Information Custodians are accountable for asset identification and inventory maintenance.

c) Loss, theft or misappropriation of assets
The loss, theft or misappropriation of assets must be reported immediately using the General Incident or Loss Report. Where the loss, theft or misappropriation involves information, the Information Incident Management Process must be followed.

A.8.1.2 – Ownership of assets

The Purpose: is to designate custodians for assets, with approved management responsibility, for the protection of organizational assets associated with information and technology systems or services.All information and assets associated with information processing facilities shall be owned by a designated part of the organization. The term ‘owner’ identifies an individual or entity that has approved management responsibility for controlling the production, development, maintenance, use and security of the assets. The term ‘owner’ does not mean that the person actually has property rights to the asset. Information Owners and Information Custodians must be designated for all assets associated with information systems.
a) Responsibilities for asset ownership
b) Designating Information Custodians

a) Responsibilities for asset ownership
All information assets must have a designated owner. An Information Owner is responsible for controlling the production, development, maintenance, use and security of information and technology assets within their jurisdiction. Information Owners are responsible for:

  • Ensuring the appropriate classification and safeguarding of information and technology systems or services;
  • Defining and regularly reviewing access restrictions, classifications and safeguards in accordance with applicable policies; and,
  • Designating Information Custodians and ensuring that they have the correct tools for protecting designated assets.

b) Designating Information Custodians
Information Owners may delegate responsibility for custody of information and technology systems or services to Information Custodians. Information Custodians will be responsible for:

  • Overseeing the functioning of information and technology assets;
  • Delivery of services in accordance with defined service requirements;
  • Regular reporting on designated information and technology assets.

Guidelines:
Ownership and custodianship responsibilities should be defined and monitored within the employee’s Performance Management tool “MyPerformance Profile”

A.8.1.3 – Acceptable use of assets

The Purpose is to prevent misuse or compromise of Organization’s information systems. All users of information systems must take responsibility for, and accept the duty to actively protect, government information and technology assets.Rules for the acceptable use of information and assets associated with information processing facilities are identified, documented, and implemented. Ref to ISMS-AUA-Acceptable Use of Assets Guidelines. Rules for the acceptable use of information systems must be identified, documented and implemented.

A.8.1.4 – Return of assets

The Purpose is to ensure employees return physical and information assets at termination or change of employment.All employees, contractors and third party users are required to return all of the organization’s assets in their possession upon termination of their employment, contract or agreement. HOD’s must document the return of  assets in the possession of employees upon termination of their employment using standard processes. These processes must ensure the return of

  • documents, files, data, books and manuals in physical or other media formats including other information assets
  • developed or prepared by an employee or contractor in the course of their duties,
  • computer hardware, software and equipment (e.g., mobile devices, portable media), and,
  • access devices, cards, vouchers and keys (e.g., credit cards, taxi cards, travel vouchers);

The HOD must ensure that 

  •  Returned items are verified against established asset inventories;
  • Recovery or compensation for assets not returned, based on established criteria regarding depreciation and replacement value for classes of items; and,
  • Identification of unreturned access devices, cards and keys that could permit unauthorized access or alteration, disposal or destruction of assets, so that information and security systems can be protected.

A.8.2 Information Classification

Control Objective: To ensure that information receives an appropriate level of protection.

A.8.2.1 – Classification of information

The Purpose is to define the information security classification system characteristics for information and information systems. There are four levels of information classification . Refer ‘PO-12-ISMS-CLH-Information Classification, Labeling and Handling Policy.docx’ The information security classification system must take into account the value, sensitivity and intended use of the information.
a) Information and information system security classification
b) Mandatory features of information security classification
c) Mandatory features of information system security classification

a) Information and information system security classification
Information Owners must use the Information Security Classification system to categorize information and information systems. The Chief Information Officer is responsible for definition, application and enforcement of the Information Security Classification system. Risk Manager is responsible for definition of Security Categories.
b) Mandatory features of information security classification
The Information Security Classification system must:
1)Apply to information types rather than discrete data elements;
2) Determine the relative value of information including factors such as:

  • Statutory or regulatory requirements,
  • Impact to health, life or personal safety,
  • Effects of data aggregation,
  • Impact to the Ministry service plan from loss of information confidentiality, integrity and availability, and,
  • Changes to information sensitivity over time;

3) Maintain compatibility with the Administrative Records Classification System (ARCS) and Operational Records Classification System (ORCS).

The Information Security Classification system must include processes for:

  • Defining information types for categorization;
  • Making decisions on categorization of information; and,
  • Periodic reassessment of the information security categorization processes.

c) Mandatory features of information system security classification

The Information Security Classification system must include processes for:

  • Categorization of information systems based on the security classification of information stored, handled or processed by the information system; and,
  • Inclusion of information and system security classification documentation in the System Security Plan.

Guidelines:
The Information Security Classification system is a cornerstone of security and risk assessment activities. The security categories communicate the value and classification of information in a way that allows for decisions to be made about risk management and information handling. Information Security Classifications assist in:

  • Consistent, comparable Statement of Sensitivity descriptions of the Security Threat and Risk Assessment describing the confidentiality, integrity and availability requirements of the assessed system.
  • The selection of system security controls – service providers can bundle system security controls into packages or service offerings based on the consistently defined protection requirements of the information.
  • The selection of, and consistent application of, information handling and labeling rules.
  • Information sharing agreements by indicating the relative value of information being exchanged in a consistent and comparable manner across government.

A.8.2.2 –Labeling of information

The Purpose is to protect information in accordance with its security classification.The guidelines for labeling and handling of Information. are documented and available in ISMS-CLH-Information Classification, Labeling and Handling Policy.docx. Information must be identified, labelled when appropriate and handled in accordance with the assigned information security classification.
a) Information labelling procedures
b) Information handling procedures

a) Information labelling procedures
Information Owners and Information Custodians must document procedures to label information with its information security classification as required by the government Information Security Classification system. Information labelling communicates the security classification and protection requirements to employees. Information types that must be considered for labelling include: printed or electronic records, reports, files, on-screen displays or messages. Information Owners must select and document the appropriate label type for each information type. Automatic information labelling must be used where possible (e.g., by use of document templates, standard report footers, printer watermarks, on-screen displays, or system-applied text). Where direct information labelling is not possible, alternate methods must be used to communicate the information security classification, such as marking storage media, description in information sharing agreements or system interface specifications, or use of metadata.

b) Information handling procedures
Information Owners and Information Custodians must document information handling procedures for secure processing, storage, transmission, declassification and disposal of information assets. Information protection procedures must take into account the information security classification, labelling and handling processes and the access control policies. Procedures must be defined for interpreting information security classification labels from, and handling information exchanged with, other jurisdictions.

Guidelines:
During systems development, specify the information security labelling requirements when defining business requirements for reports, screens and data storage.

A.8.2.3 –Handling of assets

The Purpose is to ensure that documented procedures are used for handling information assets and storage of media in accordance with the security classification of information stored on the media. XXX. has well defined guidelines for information labeling, handling and storage in order to protect information from unauthorized disclosure or misuse. Refer ‘PO-12-ISMS-CLH-Information Classification, Labeling and Handling Policy.docx’. Information assets must be handled and stored so as to prevent unauthorized information disclosure or misuse, in accordance with the information security classification system.
a) Asset handling procedures
b) Media handling procedures

a) Asset handling procedures
Information Owners must follow the procedures for information security classification when handling information assets. The following items must be considered when dealing with information assets:

  • Access restrictions supporting the protection requirements for each level of classification;
  • Protection of temporary or permanent copies of information to a level consistent with the protection of the original information;
  • Storage of IT assets in accordance with manufacturers’ specifications;
  • Clear marking of all copies of media for the attention of the authorized recipient.

Information sharing agreements must include:

  • Procedures to identify the classification of that information;
  • Interpretation of the classification labels from other organizations; and,
  • Level of protection required.

b) Media handling procedures
Information Owners must document media handling procedures that are compliant with the information security classification and handling requirements for information stored on the media. If information of various security classifications is stored on media, the media must be handled according to the highest classification of the information stored. Media handling documentation must include procedures for:

  • Marking of media to its highest information classification level label, in order to indicate the sensitivity of information contained on the media;
  • Access control restrictions and authorization;
  • Correct use of technology (e.g., encryption) to enforce access control;
  • Copying and distribution of media, including minimization of multiple copies, marking of originals and distribution of copies;
  • Operating the media storage environment and managing media lifespan according to manufacturer specifications;
  • Regular status accounting of media;
  • Maintenance of media transfer and storage records;
  • Media destruction and disposal; and,
  • Employee training.

Only approved media devices appropriate for the classification of the information being stored must be used.

A.8.3 Media handling

Control Objective: To prevent unauthorized disclosure, modification, removal or destruction of assets, and interruptions to business activities.

A.8.3.1 – Management of removable media

The Purpose is to ensure that risks to information introduced by portable storage devices are managed.All media should be stored in a safe, secure environment, in accordance with manufacturers’ specifications.  XXX. has defined procedure for the management of computer media containing sensitive data.  Refer ‘PR-17-ISMS-AHP-Media Handling Process.docx’. All removable computer media must be managed with controls appropriate for the sensitivity of the data contained on the media.
a) Management of records
b) Use of portable storage devices
c) Human factors
d) Risk assessment factors and controls
e) Mandatory controls

a) Management of records
CISO is responsible for the management and disposal of records according to records schedules approved under the Procedure for control of records.
b) Use of mobile or portable storage devices
The use of mobile or portable storage devices to store or transport information increases the risk of information compromise. These devices are typically small, and are easily lost, stolen or damaged, particularly when transported in public environments. Mobile or portable storage devices include, but are not limited to, USB drives, external hard drives, smartphones, tablets, laptops, and mp3 players. Information Owners must:

  • Ensure that use of mobile or portable storage devices is managed and controlled to mitigate risks;
  • Document processes for authorizing use of mobile or portable storage devices; and,
  • Ensure employees using mobile or portable storage devices protect information and information technology assets in their custody or control.

Information Owners must conduct a Security Threat and Risk Assessment on mobile devices or mobile computing services to determine the risk profile and suitability of the device or the service for use prior to deployment within the organization. Technical standards for each device type must be documented including product name, mandatory controls, permitted information classifications and strength of controls such as encryption key length. Device handling procedures should include instructions to minimize the amount of information stored on mobile or portable storage devices.

c) Human factors
Information Owners must ensure employees using portable storage devices are:

  1. Aware of the additional risks and responsibilities inherent with portable storage devices;
  2. Familiar with the required protection technologies and when they must be used; and,
  3. Familiar with the Information Incident Management Process and General Incident or Loss Reporting procedures.

d) Risk assessment factors
The Security Threat and Risk Assessment must consider the impact of disclosure or loss of information stored on portable media from threats such as:

  • Loss or physical theft;
  • Limited ability to control and log access to stored data;
  • Accidental media disposal or destruction;
  • Improper long term storage environment;
  • Exposure to malware; and,
  • Incomplete erasure of data prior to device disposal.

Information classification and sensitivity levels must be considered in the risk assessment.

e) Mandatory controls

Minimum information protection safeguards for the use of portable storage devices must include:

  • Disabling portable storage devices, media drives or connection ports where no business reason exists for their use;
  • Documented definition of information classifications or sensitivities permitted to exist on specific media types;
  • Not storing the only version of a document on portable storage devices;
  • Documented authorization processes for use of portable storage devices;
  • Encryption of stored data;
  • Contractual requirements for external parties that transport, handle or store portable storage devices; and,
  • Adherence to manufacturer specifications for use of portable storage devices.

Documented portable storage devices handling procedures include:

  • Off-site storage;
  • Third party transportation;
  • Information backup;
  • Protection against malware;
  • Logging of media custody and location to allow for accounting and audit;
  • Media labelling to indicate owner, classification and special handling restrictions;
  • Maintenance of information where the information storage requirement exceeds the expected media lifetime; and,
  • Secure erasure and disposal

A.8.3.2 – Disposal of media

The Purpose is to ensure that information cannot be retrieved from media that is no longer in use.XXX. has defined procedure for the disposal of computer media. Media must be disposed of securely and in a manner appropriate for the sensitivity of the data it contains. The Tapes, CDs and Hard Disks have been covered in ‘PR-17-ISMS-AHP-Media Handling Process.docx’.
Any asset capable of storing electronic information is considered a type of media, including mobile and portable storage devices, hard disks, CDs, DVDs, and tapes. Information Owners and Information Custodians must ensure that media that is no longer required operationally (e.g., due to expiry, surplus, damage or wear), is disposed of securely. Prior to disposal, the CISO office must be consulted. Media disposal procedures must:

  • Be documented and communicated to employees;
  • Specify erasure and disposal measures whose strength is based on information sensitivity and type of media (e.g., erasure software);
  • Include secure disposal or destruction of media if erasure is not sufficient, or not cost effective (e.g., destruction by shredding, incineration or chemical dissolution);
  • Include secure storage measures for media collected for and awaiting erasure or disposal, to avoid undetected theft of small amounts of media from large volumes awaiting disposal; and,
  • Include audit logs of media disposal.
  • Corporate Information and Records Management Office is responsible for ensuring secure disposal services are available to Information Owners and Information Custodians.

Guidelines:
A Corporate Supply Arrangement exists for provision of secure media disposal services. Secure disposal service companies should be used where practical to perform media disposal. Contact the Ministry Records Officer for further details.

A.8.3.3 – Physical media transfer

The Purpose is to protect information from unauthorized disclosure or loss during physical transport of media.Backup media, Floppy, CD, Hardcopy etc. being transported from one location to the other is protected from unauthorized access, misuse and corruption by sending them through trusted,  employee with proper authorization and adequate protection. Refer ‘PO-12-ISMS-CLH-Information Classification, Labeling and Handling Policy.docx’. The Chief Information Officer must document and implement security measures for the protection of media during transport that meet information classification and handling requirements. If information of various classifications is stored on media, the media must be protected according to the highest classification of the information stored. Minimum media transport requirements are:

  • Using couriers that are approved by government;
  • Inspecting identification credentials of couriers upon pickup and delivery of packages;
  • Obtain and retain receipts for media shipments;
  • Using packaging that will protect the media from loss or damage; and,
  • Packaging so that the classification of the media is not displayed.
  • Responsibility for specification of physical transport procedures are shared between Corporate Information and Records Management Office and the Risk Management Branch and Government Security Office.

Guidelines:
Where supported by a Security Threat and Risk Assessment, additional controls to protect media during transport include:

  • Using notifications of transport activities, such as o sender informing receiver of the impending shipment, and, receiver confirming receipt of the shipment;
  • Using two layers of packaging where the inner layer indicates the classification and handling requirements; and,
  • Using a locked container.

A.9 Logical Security /Access Control

This identifies the controls that restrict access to government information and information assets. Access control protects organizations from security threats such as internal and external intrusions. The controls are guided by legislation that protects particular types of information (e.g., personal and other types of confidential information) and by business requirements. Access control policies provide the blueprint for the management of employee access, authorizations and control requirements for computer networks, operating systems, applications and information. This identifies security best practices and responsibilities for administrators and employees.

A.9.1 Business requirement for access control

Control Objective: To restrict access to information and information processing facilities. 

A.9.1.1 – Access control policy

The Purpose is to ensure that information and information systems are available for authorized use and protected from unauthorized use. XXX. has implemented access control to information based on the business requirements and security requirements on ‘need-to-know’ basis. Well-documented access control policy and procedures are in place. Refer PO-07-ISMS-ACP-IT Access control Policy.docx’. Access to information systems and services must be consistent with business needs and be based on security requirements.
a) Access control policy
b) Access control policy management
c) Review of access control policy

a) Access control policy
Information Owners are responsible for establishing, documenting and approving access control policies which must:

  • Support and enable business requirements;
  • Be based on requirements identified in Privacy Impact Assessments and Security Threat and Risk Assessments; and,
  • Include classification of assets.

Access control policies must additionally:

  • Consider both physical and logical access to assets;
  • Apply the need-to-know and least privilege principles;
  • Set default access privileges to deny-all prior to granting access;
  • Require access by unique user identifiers or system process identifiers to ensure that all access actions are auditable;
  • Have permissions assigned to roles rather than individual user identifiers;
  • Access requirements should be determined at a functional, work unit level.

The access control policy must be communicated to employees as part of awareness training.

b) Access control policy management
Information Owners and Information Custodians are responsible for establishing processes to manage the access control policies, including:

  • Ensuring the process is communicated to all employees;
  • Documenting processes for employee registration and deregistration;
  • Segregating roles and functions (i.e. access requests, access authorization, access administration);
  • Defining rules for controlling access to privileged system functions;
  • Identifying roles and/or functions which require multi-factor authentication;
  • Identifying and justifying exceptional cases where there is a need for enhanced employee security screening for sensitive assets.

c) Review of access control policy
Information Owners must conduct periodic reviews of the access control policies as part of an ongoing process for risk management, security, and privacy. Annual reviews are recommended. Reviews must be conducted:

  • Prior to the introduction of new or significantly changed systems, applications or other services or major technology changes;
  • When the threat environment changes or new vulnerabilities arise;
  • Following significant government or Ministry re-organization as appropriate;
  • For sensitive and business critical assets, reviews should be conducted more frequently than annually, based on the Security Threat and Risk Assessment.

A.9.1.2 – Access to network and network services

The Purpose is to support the information system access control policy by limiting network access to authorized users of specific information systems.The access to internal and external network of XXX. is controlled. This includes any direct access to services that are business critical to users within the domain, and direct access to network from users in high-risk location like users through Internet. Users shall only have direct access to the services that they have been specifically authorized to use. A defined and documented policy for use of network services exists. Employees must only be provided access to the network services they have been specifically authorized to use.
a) Access to network services
b) Management controls and processes
c) Means for accessing networks and network services

a) Access to network services
Information Owners must enable network services needed to support business requirements (e.g., by explicitly enabling needed services and disabling unneeded services). Access to network services will be controlled at network perimeters, routers, gateways, workstations and servers. Information system network access must be restricted to the authorized users and systems, using the principle of least privilege, as defined in the access control policies for the information system.
b) Management controls and processes
Information Owners must document processes for management of network access, including:

  • Documentation and review of implemented network access controls;
  • Identification of threats, risks and mitigation factors associated with network services;
  • Testing of network access controls to verify correct implementation; and,
  • Assisting Information Owners to verify the principle of least privilege is used to minimize access, as specified in the access control policy.

c) Means for accessing networks and network services
Information Owners must define and implement:

  • Permitted network access methods for each network zone (e.g., direct connection, Virtual Private Network, Wi-Fi, remote desktop connection, desktop terminal services); and,
  • Minimum security controls required for connection to networks (e.g., patch levels, anti-virus software, firewalls, user and system authentication requirements).

A.9.2 User access management

Control Objective: To ensure authorized user access and to prevent unauthorized access to information systems. 

A.9.2.1 – User registration & deregistration

The Purpose is to ensure that all access actions are traceable to an identifiable individual or process. There must be a formal employee registration and de-registration process for granting access to all information systems.
a) Registration
b) De-registration

a) Registration

Information Owners are responsible for managing access to the assets under their control and must implement registration processes which:

  • Require approval for all access rights;
  • Ensure access requests are approved by the Supervisor of the employee requesting access;
  • Ensure the reasons for requesting access are consistent with job responsibilities;
  • Maintain records of access right approvals;
  • Ensure employees understand the conditions of access and, when appropriate, have signed confidentiality agreements;
  • Ensure access rights are consistent with the data uses documented in the approved Privacy Impact Assessment;
  • Ensure accesses are traceable to an identifiable individual or process;
  • Ensure each employee is assigned a single unique identifier for accessing information systems;
  • Ensure the responsibilities for authorizing access are segregated from the responsibilities for granting access;
  • Restrict access by using predefined role permissions;
  • Provide secure and separate transmission of the user identifier and password to the employee; and,
  • In exceptional cases, where warranted by the classification of the asset and supported by a Security Threat and Risk Assessment, ensure enhanced employee security screening or background checks are completed prior to authorizing access.

b) De-registration
Information Owners must formally assign responsibilities and implement processes to:

  • Remove access privileges for employees no longer with the organization within 5 working days;
  • Promptly review access rights whenever an employee changes duties and responsibilities;
  • Promptly review access rights whenever the employee’s branch or department is involved in significant reorganization;
  • Review access privileges for employees on extended absence or temporary assignments within 10 working days of the change of status;
  • Remove access privileges for employees terminated for cause concurrent with notification to the individual; and,
  • Quarterly check for and remove inactive or redundant user identifiers.

Authority and Exceptions:

Individual employees may have multiple identifiers when:

  • Required to meet limitations of technology (e.g., IDIR, MVS).
  • Required to meet unique business requirements provided the rationale is documented and approved by the Information Owner or Information Custodian as appropriate.

A.9.2.2 – User access provisioning

The Purpose is to ensure authorized user access and to prevent unauthorized user access to systems and services. A unique login id and password has been assigned to all users, with varying privileges, depending on roles, and requirements. User identification and authentication is implemented in accordance with privileges granted to the respective user. A formal employee access provisioning process must be implemented to assign or revoke access rights for all user types to all systems and services. Information Owners and Information Custodians must implement a formal employee access provisioning process. The provisioning process for assigning or revoking access rights granted to user IDs must include:

  • Obtaining authorization from the owner of the information system or service for the use of the information system or service. Separate approval for access rights from management may also be appropriate;
  • Verifying that the level of access granted is appropriate to the access policies and is consistent with other requirements such as segregation of duties;
  • Ensuring that access rights are not activated (e.g., by service providers) before authorization procedures are completed;
  • Maintaining a central record of access rights granted to a user ID to access information systems and services;
  • Adapting access rights of employees who have changed roles or jobs and immediately removing or blocking access rights of employees who have left the organization; and,
  • Periodically reviewing access rights with owners of the information systems or services.

Guidelines:
Employee access roles should be established based on business requirements that summarize a number of access rights into typical user access profiles. Access requests and reviews are more easily managed at the level of such roles than at the level of particular rights. Consideration should be given to including clauses in employees contracts and service contracts that specify sanctions if unauthorized access is attempted by employees.

A.9.2.3 – Management of Privileged Access rights (Password Policy)

The Purpose is to prevent unauthorized access to multi-user information systems.The allocation and use of privileges is restricted and controlled. Any privilege given onto any system of XXX is covered. The allocation and use of system privileges must be restricted and controlled.
a) Managing, restricting and controlling the allocation and use of system privileges
b) Managing the issuance of privileged user credentials
c) Managing the issuance of multiple factors of authentication credentials

a) Managing, restricting and controlling the allocation and use of system privileges

Information Owners are responsible for authorizing system privileges and must:

  • Identify and document the system privileges associated with each information system or service;
  • Ensure the process for requesting and approving access to system privileges includes Supervisor approval(s) prior to granting of system privileges;
  • Ensure processes are implemented to remove system privileges from employees concurrent with changes in job status (e.g., transfer, promotion, termination);
  • Limit access to the fewest number of employees needed to operate or maintain the system or service;
  • Ensure the access rights granted are limited to and consistent with employee job functions and responsibilities;
  • Maintain a record of employees granted access to system privileges;
  • Ensure use of system privileges is recorded in audit logs which are unalterable by the privileged user;
  • Implement processes for ongoing compliance checking of the use of system privileges; and,
  • Implement processes for regular review of authorizations in place to confirm that access is still needed and that the least number of users needed have access.

User identifiers with system privileges must only be used for performing privileged functions and not used to perform regular activities. User identifiers established to perform regular activities must not be used to perform privileged functions.

Guidelines:

  • The design of information systems should include processes for performing regular maintenance activities which avoid the requirement of system privileges.
  • Whenever possible system routines should be used to execute system privileges rather than granting system privileges to individual employees.
  • System acquisition and development should encourage use of programs which minimize the need for employees to operate with system privileges.

Privileged users should:

  • Not read the data of an information asset unless authorized;
  • Be able to alter user permissions for an information asset; and,
  • Be permitted to view, but not alter, user activity logs as part of security safeguards.

b) Managing the issuance and revocation of privileged user credentials
The issuance of privileged user credentials must have two levels of approval. Use of system privileges should require use of multi-factor authentication.

c) Managing the issuance of multiple factors of authentication credentials
The management of issuance of multiple factors of authentication credential is covered in the Cryptographic Standards for Information Protection.

A.9.2.4 – Management of Secrete Authentication information of users (Password Management)

The Purpose is to define the formal management processes for issuing passwords. XXX has a well-defined password policy and guidelines. The issuance and revocation of authentication credentials must be controlled through a formal management process. Ministries must formally designate individuals who have the authority to issue and reset passwords. The following applies:

  • Passwords must only be issued to employees whose identity is confirmed prior to issuance;
  • Individuals with the authority to reset passwords must transmit new or reset passwords to the employee in a secure manner (e.g., using encryption, using a secondary channel);
  • Whenever technically possible, temporary passwords must be unique to each individual and must not be easily guessable;
  • Passwords must never be stored in an unprotected form;
  • Default passwords provided by technology vendors must be changed to a password compliant with government standards during the installation of the technology (hardware or software); and,
  • The revocation of authentication credentials must follow a formal process.

A.9.2.5 – Review of user access rights

The purpose is to ensure that access rights only exist for users with a defined “need to know”.User privileges for XXX will be reviewed every three months and for global users it will be reviewed once every year. System Administrator shall review the access rights & respective Business Owner shall ratify the review report.Information Owners must formally review employee access rights at regular intervals.
a) Circumstances and criteria for formal access right review
b) Procedure for formal access right review

a) Circumstances and criteria for formal access right review
Information Owners must implement formal processes for the regular review of access rights. Access rights must be reviewed:

  • Annually;
  • More frequently for high value information assets and privileged users;
  • When an employee’s status changes as the result of a promotion, demotion, removal from a user group, re-assignment, transfer or other change that may affect an employee’s need to access information assets;
  • As part of a major re-organization, or the introduction of new technology or applications; and,
  • When Information Owners change the access control policy.

b) Procedure for formal access right review
Review of access rights must include the following:

  • Confirmation that access rights are based on the need-to-know and least privilege principles;
  • Confirmation that all members of the group/role have a need-to-know;
  • Reviews and verification of access control lists dated and signed by the reviewer and kept for audit purposes; and,
  • Confirmation that changes to access rights are logged and auditable.

Access control logs and reports are government records and must be retained and disposed of in accordance with approved record management schedules.

A.9.2.6 – Removal or adjustment of access rights

The purpose is to ensure physical and logical access rights to information systems and information processing facilities are managed in relation to the security responsibilities of the job requirements .The access rights of all employees, contractors and third party users to information and information processing facilities are removed upon termination of their employment, contract or agreement, or adjusted upon change.The access rights of employees to information systems must be removed upon termination of employment and reviewed upon change of employment.
a) Change of employment status
b) Action upon termination or change of employment
c) Reduction of access rights

a) Change of employment status
Dept HOD must review access to information systems and information processing facilities when employees change employment, including:

  • When employees assume new roles and responsibilities;
  • During restructuring of positional or organizational roles and responsibilities;
  • When employees commence long-term leave; and,
  • Updating directories, documentation and systems.

b) Action upon termination or change of employment
Dept HOD must ensure access to information systems and information processing facilities is removed upon termination of employment or reviewed upon change of employment by:

  • Removing or modifying physical and logical access;
  • Recovering or revoking access devices, cards and keys; and,
  • Updating directories, documentation and systems.

c) Reduction of access rights
Dept HOD must ensure access to information systems and information processing facilities is reduced or removed before the employment terminates or changes, based upon the evaluation of risk factors such as:

  • Whether the termination or change is initiated by the employee/contactor or by the HOD;
  • The reason for termination;
  • The current responsibilities of the employee/contractor; and,
  • The value of the assets currently accessible.

A.9.3 User Responsibilities

Control Objective: To prevent unauthorized user access, and compromise on theft of information and information processing facilities.

A.9.3.1 – Use of Secret Authentication Information

The purpose is to maintain the integrity of the unique identifier (user id) by ensuring employees follow security best practices. XXX. has a well-defined password usage guideline for users to follow. Employees must follow security best practices in the selection and use of passwords.
a) Selection of passwords
b) Password change
c) Privileged accounts
d) Protection and use of passwords

a) Selection of passwords

When selecting passwords employees must:

  • Select complex passwords, i.e., a mixture of characters as specified in the Standard;
  • Keep authentication information confidential;
  • Avoid recording authentication information; and,
  • Avoid using the same password for multiple accounts.

The effectiveness of access control measures is strengthened when employees adopt security best practices for selecting passwords.

b) Password change
Passwords must be changed:

  • During installation of hardware or software which is delivered with a default password;
  • Immediately if a password is compromised or if compromise is suspected. If compromise has taken place or is suspected the incident must be reported in accordance with the Information Incident Management Process; and,
  • In compliance with password change instructions issued by an automated process (e.g., password life-cycle replacement) or an appropriate authority.

c) Privileged accounts
Privileged accounts have wider and more powerful access rights to information assets. Employees authorized to create or who hold privileged accounts must use passwords which are at least 15 characters where technically feasible.

d) Protection and use of passwords
Passwords are highly sensitive and must be protected by not:

  1. Sharing or disclosing passwords;
  2. Permitting anyone to view the password as it is being entered;
  3. Writing down a password;
  4. Storing other personal identifiers, access codes, tokens or passwords in the same container;
  5. Keeping a file of passwords on any computer system, including mobile devices, unless that file is encrypted according to the Cryptographic Standards for Information Protection;
  6. Employing any automatic or scripted logon processes for personal identifiers; and,
  7. Using personal identifiers, access codes, or passwords associated with government accounts for non-government purposes.

Where a business need is defined to keep written records of passwords, a request for a policy exemption must be submitted to the Chief Information Security Officer.

Standards:
The Complex Password Standard for government systems requires that passwords must:

  1. Not contain the username or any proper names of the employee.
  2. Contain a minimum of 8 characters;
  3. Contain characters from three of the following categories:
    • English upper case characters (A to Z),
    • English lower case characters (a to z),
    • numerals (0 to 9), and,
    • non-alphanumeric keyboard symbols (e.g., ! $ # %); and,

For example, the complex password “T#ocitpi7”is derived from the phrase “The number of clowns in the parade is seven”. Complexity can be further increased by substituting numbers for vowels. For mobile devices connecting to the messaging server, the following password rules apply:

  • Passwords must contain a minimum of 6 characters;
  • Controls should be in place to prevent the use of overly simple passwords; and,
  • The use of a combination of numbers, symbols, upper and lower case characters is recommended to increase the password strength.

Guidelines:
Never divulge your password to anyone. Legitimate IT technical support employees such as systems administrators, helpdesk and security will not ask employees for their passwords.

Authority and Exceptions:
Exception is granted to RACF and VM Secure due to technical product limitations.

A.9.4 Operating system access control

Control Objective: To prevent unauthorized access to systems and applications.

A.9.4.1– Information access restriction

 The purpose is to restrict access to application systems functions and information to authorized individuals or systems. Unauthorized access to information is restricted. Access to information systems functions and information must be restricted in accordance with the access control policy.
a) Information access controls
b) System configuration
c) Publicly accessible information
d) Segregation of sensitive information systems

a) Information access controls
Information Owners are responsible for ensuring the implementation of the access control policy for their business applications. Every information system must have an access control policy that specifies access permissions for information and system functions. The access control policy must identify the information and system functions accessible by various classes of users. The application and information section of the access control policy must specify:

  • The information to be controlled;
  • The system functions to be controlled; and,
  • The roles authorized to access the resources and information and what types of access are permitted (e.g., Create, Read, Update/Write, Delete, Execute) based on business need.

b) System configuration
Information system access controls must be configurable to allow Information Custodians to modify access permissions without making code changes. System utilities or functions that can bypass user access controls must be specified in the access control policy. Access to these utilities and functions must be restricted.

c) Publicly accessible information
Information that is publicly accessible must be segregated from non-public information.

d) Segregation of sensitive information systems
Information Owners must conduct a Security Threat and Risk Assessment to determine the information system classification level. The information system classification level determines which network security zone the information system must reside in. Security zones must be established using physical or logical methods, which may include separate network segments, separate servers, firewalls, access control lists and proxy servers.

A.9.4.2 – Secure log-on procedures

The purpose is to ensure access to information systems is limited to authorized users and processes.All user machines are accessible through a user name and password. These are assigned to each authorized user and are unique in nature. Unauthorized access is not permitted. Access to information systems must use a secure logon process.
a) Information displayed during logon
b) Unsuccessful logon attempts
c) Password transmission

a) Information displayed during logon
CISO must ensure that Information owners configure logon processes to minimize the opportunity for unauthorized access, which includes:

  • Not displaying details about backend systems (e.g., operating system information, network details) prior to successful completion of the logon process to avoid providing an unauthorized user with any unnecessary assistance;
  • Validating logon information only on completion of all input data; and,
  • Not displaying passwords in clear text as they are entered.

b) Unsuccessful logon attempts
CISO must ensure that Information owners configure logon processes to:

  • Record unsuccessful logon attempts;
  • Allow a limited number of unsuccessful logon attempts;
  • Limit the maximum and minimum time allowed for the logon procedure, and if exceeded, the system should terminate the logon; and,
  • Force a time delay or reject further logon attempts if the limited number of consecutive unsuccessful logon attempts is reached.

c) Password transmission
Information Owners and must ensure logon processes are configured to prevent transmission of passwords in clear text.

Standards:
After three consecutive failed logon attempts for an account the logon process must:

  • Lock the account and require Administrator intervention; or,
  • Lock the account for 15 minutes and then allow a further three logon attempts.

Guidelines:
A general warning should be displayed that the information system is accessed only by authorized users. The logon procedure should permit users to monitor the security of their account by displaying the following information on completion of a successful logon:

  • Date and time of the previous successful logon; and,
  • Details of any unsuccessful logon attempts since the last successful logon.

A.9.4.3 – Password management system

The Purpose is to support the operating system access control policy through use of password management systems to enforce the password standard. .XXX has a well-defined password policy and access management process. A password management system must be in place to provide an effective, interactive facility that ensures quality passwords.

  1. Enforcing quality password rules
  2. Allocation of unique identifier
  3. Authentication of identity
  4. Shared user identifiers

1) Enforcing quality password rules
Information Owners  must ensure password management systems:

  • Enforce the use of individual user identifiers and passwords;
  • Support selection and change of passwords using the Complex Password Standard;
  • Enforce change of temporary passwords at first logon and after password reset by an Administrator;
  • Enforce regular user password change, including advance warning of impending expiry;
  • Prevent re-use of passwords for a specified number of times;
  • Prevent passwords from being viewed on-screen;
  • Store password files separately from application system data;
  • Ensure password management systems are protected from unauthorized access and manipulation; and,
  • Store and transmit passwords in protected (e.g., encrypted) form.

The password management system standard for government systems requires that users must be:

  • Prevented from re-using the same password within 12 months; and,
  • Provided with notification at least 10 days before their password will need to be changed.

2) Allocation of unique identifier
Information Owners must ensure employees are issued unique user identifiers (user ids) for their use only. The documented and approved process for allocating and managing unique identifiers must include:

  • A single point of contact to:
    • manage the assignment and issuance of user identifiers,
    • ensure that users, except for privileged users, are not issued multiple identifiers for any one information system or platform, and,
    • record user status (e.g., employee, contractor);
  • Identification of those individuals or positions authorized to request new user identifiers;
  • Confirmation that the user has been informed of appropriate use policies;
  • Automated linkages with the employees management system (i.e., CHIPS) to identify transfers, terminations and extended leave actions to initiate the suspension or cancellation of user identifiers;
  • Linkages with contract management offices and/or contract managers to identify and maintain the status of identifiers issued to contractors; and,
  • Conducting annual reviews to confirm the continued requirement for the user identifier.

To segregate roles or functions, privileged users may be issued multiple identifiers for an information system or platform.

2) Authentication of identity
Information Owners must ensure that user identifiers are authenticated by an approved authentication mechanism. User identifiers authenticated by means other than a password must use a mechanism approved by the Office of the Government Chief Information Officer.

3) Shared user identifiers
In exceptional circumstances, where there is a clear business benefit identified by the Information Owner or Information Custodian, the use of a positional user identifier for a group of users or a specific job can be used, provided:

  • Positional user identifiers are not used for privileged users; and,
  • The Supervisor responsible for the position using the positional user identifier:
    • Maintains a record of the name of the individual, the user identifier, and the start and end date of use, and,
    • Deactivates the user identifier when not in use by requesting a password reset.

Guidelines:
Processes for issuing and managing information system user identifiers should be coordinated with those for issuing and managing other identification credentials (e.g., building passes, user identifiers for telecommunications services provided to an individual).

A.9.4.4 – Use of system utilities (Privileged utility programs)

The purpose is to restrict and tightly control the use of utility programs, which may be used to override system and application controls.All system utility programs, which impact the operations of the systems, are installed with controlled access to administrative accounts. System Utilities are controlled. Use of system utility programs must be restricted and tightly controlled.
a) Restriction and control of system utility programs
b)Session time-out

a) Restriction and control of system utility programs
Information Owners must limit use of system utility programs by:

  • Defining and documenting authorization levels;
  • Restricting the number of users with access to system utility programs;
  • Annually reviewing the status of users with permissions to use system utility programs;
  • Ensuring that the use of system utilities maintains segregation of duties;
  • Requiring a secure logon process to be used to access system utilities;
  • Ensuring that all system utility programs are identified and usage logged;
  • Segregating system utilities from application software where possible; and,
  • Removing or disabling unnecessary and obsolete system utilities and system software.

Guidelines:
Use of system utility programs should be limited to privileged users. Use of system privileges should require use of multiple factors of authentication.

b) Session time-out
Information Owners must define and implement automatic termination or re-authentication of active sessions after a pre-determined period of inactivity. Government information systems must have session time-outs managed by operating system access, application or government infrastructure controls. Application and network sessions must be terminated or require re-authentication after a pre-defined period of inactivity commensurate with the:

  • Risks related to the security zone;
  • Classification of the information being handled; and,
  • Risks related to the use of the equipment by multiple users.

The session must be terminated or require re-authentication after a period of no more than 15 minutes of inactivity.

A.9.4.5 – Access control to program source code

The Purpose is to protect information systems from unauthorized access or modification.Source code and program libraries are not accessed by unauthorized people. Code management of IT related applications is being performed according to PR-08-SCM-Configuration Management Process’. Information Owners must implement procedures to control access to program source code for information systems to ensure that:

  • Program source code is isolated and stored separately from operational information systems;
  • Privileged users access is defined and monitored;
  • A change control process is implemented to manage updating of program source libraries and associated items;
  • Program source code contained on any media must be protected; and,
  • Accesses and changes to program source libraries are logged.

A.10 Cryptography

The use of cryptography for information controls needs to be based on the Security Threat and Risk Assessment and the level of harm caused by the loss of confidentiality and/or integrity. The cryptographic policies are under the direction of the Chief Information Officer.

A.10.1 Cryptographic Controls

Control Objective: To protect the confidentiality, authenticity, or integrity of information by cryptographic means.

A.10.1.1 – Policy on the use of cryptographic controls

The process is to manage the use of cryptography for protecting the confidentiality and integrity of electronic information. The use of cryptographic controls must be based on the risk of unauthorized access and the classification of the information or information system to be protected.
a) Cryptographic controls – Roles and responsibilities
b) Acceptable use of cryptography

a) Cryptographic controls – Roles and responsibilities
The Chief Information Officer provides direction and leadership in the use of cryptography and the provision of cryptographic services, such as those used for user registration services and key management services, by:

  • Establishing policy and providing strategic direction on the use of cryptography across the organization;
  • Instituting the approach to key management;
  • Establishing roles and responsibilities;
  • Setting standards for cryptographic algorithms and key length; and,
  • Approving the use of cryptographic services.

The Chief Information Security Officer supports the use of cryptography in organization by:

  • Defining and maintaining the Cryptographic Standard for Information Protection; and,
  • Providing technical advice on the use of cryptography.

Information Owners must document the use of cryptography in the System Security Plan for the information system.

b) Acceptable use of cryptography
The type and quality of cryptographic controls used in information systems must be based on a Security Threat and Risk Assessment, and include consideration of:

  • Confidentiality requirements, in accordance with information classification, labelling and handling requirements;
  • Integrity requirements (e.g., for financial payment instructions in excess of a specified dollar amount);
  • Non-repudiation requirements (e.g., for proof of the occurrence or non-occurrence of an event);
  • Authentication requirements (e.g., proof of identity);
  • Other security measures (e.g., for proof of origin, receipt, or ownership);
  • Legislation, regulations or policies requiring the use of cryptography;
  • Restrictions on the export or use of cryptographic products; and,
  • Risks relating to the long-term storage of electronic information (e.g., recovery of encrypted data, long-term key maintenance).

Information Owners must register the use of approved cryptographic products and services with the Chief Information Security Officer.

A.10.1.2 – Key Management

The purpose is to provide trustworthy key management processes for cryptographic services.A key management system based on policy, procedures and approved methods must be used to support and protect the use of cryptographic controls throughout their life-cycle. The Chief Information Officer is responsible for approving key management standards and processes, including:

  • Selection of cryptographic keys with sufficient lengths;
  • Distribution, storage and periodic updating of cryptographic keys;
  • Revocation of cryptographic keys (e.g., when a recipient changes job);
  • Recovery of cryptographic keys that are lost, corrupted or have expired;
  • Management of cryptographic keys that may have been compromised;
  • Archival of cryptographic keys and the maintenance of cryptographic key history; and,
  • Allocation of activation/de-activation dates.

A.11 Physical and environmental security

This identifies requirements for protection from environmental and man-made threats to employees and property. One of the principles used for protection is the use of a layered defense, with perimeters and security zones that place computers, people and information in secure areas. Requirements for the installation, operation, protection and maintenance of computer equipment are identified to preserve the security of information and information systems.

A.11.1 Secure areas

Control objective: To prevent unauthorized physical access, damage and interference to the organization’s premises and information.

A.11.1.1 – Physical security perimeter

The purpose is to prevent unauthorized physical access to government information processing facilities. XXX. has a well-defined policy on physical security and procedure on physical access control. XXX has implemented different security barriers to check the access into the premises.

  • XXX. has main entry and exit point manned by security personnel.
  • Entry to company premises for the employees is through biometric /access card and for visitors is through visitors pass.
  • Access to specific /secure areas like server rooms is monitored through access card.
  • Video Surveillance will be done through cameras installed at critical location. 

The information processing facilities must be protected by a physical security perimeter.
a) Security perimeter
b) Maintenance

a) Security perimeter
Information Owners must ensure that the perimeters of an information processing facility are physically sound in design and consider landscaping, lighting, fencing, and closed circuit television on the access routes to the building; that the roof, walls and flooring are of solid construction; and that exterior access points, windows, and doors are equipped with appropriate security controls (e.g., locks, alarms, bars). All information processing facilities are a Restricted Access Security Zone. Appropriate security controls must be applied to reduce the level of identified risks and include:

  • A structure that prevents external visual and audio observations and complies with all applicable building codes for structural stability (external walls, internal walls, ceilings and doors). Walls surrounding the facility must be extended from true floor to true ceiling (slab to slab), to prevent unauthorized entry and minimize environmental contaminations such as that caused by fires and floods. Appropriate control mechanisms (e.g., locks, alarms and bars on windows and doors) must be applied to prevent unauthorized access;
  • All information processing facilities must be equipped with physical intrusion alarm systems that automatically alert monitoring employees to take immediate action;
  • Information processing facilities must be equipped with doors that close automatically. These doors must set off an audible alarm when kept open beyond a certain period of time;
  • All fire doors must be equipped with crash bars to allow a quick exit in the event of an emergency. When the doors are opened an audible alarm may also be set off;
  • Alarm systems must be continuously monitored (i.e., 24 hours a day, 7 days a week); and,
  • The information processing facilities must be physically separated from those managed by third parties.

b) Maintenance
Information Owner must review, and where appropriate test, physical security and environmental control requirements at least annually. Security requirements for facilities must be evaluated prior to significant:

  • Alteration to exterior building layouts;
  • Changes to perimeter security controls;
  • Change in operations; and,
  • As part of any related security incident investigation.

Guidelines:
The following guidelines support physical and environmental security by establishing perimeter security for information processing facilities:

  • Information processing facilities should have a manned reception area to control access to the facility where feasible;
  • Common service spaces such as eating areas, washrooms, cloakrooms, boardrooms and storage areas should be located so that they cannot be used to circumvent physical security;
  • Visitor reception should be separate from entrance areas but provide an unobstructed view of the entrance; and,
  • When physical security is outsourced, the contract must require that contracted employees are security screened and bonded.

A.11.1.2 – Physical entry controls

The purpose is to prevent unauthorized physical access to government information.Secured areas are protected by appropriate entry controls to ensure that only authorized personnel are allowed access. Secure areas must be protected by appropriate entry controls to ensure that only authorized employees are allowed access.
a) Entry controls
b) Maintenance

a) Entry controls
Information Owners must establish the appropriate type and number of restricted zones to achieve the necessary conditions for employee safety, and for the protection of sensitive or valuable information and assets. Establishment of restricted zones must be supported by a Security Threat and Risk Assessment. Access to any information processing facility or areas where sensitive information is kept must be restricted. Access to restricted zones must be controlled, authorized and monitored as required by the applicable zone. Entry controls must identify, authenticate and log all access attempts to a Restricted Access Operations Zone or a Restricted Access Security Zone as follows:

  • Restricted Access Operation Zone access is limited to ministry employees and their escorted visitors (i.e., standard working areas, conference rooms, offices); and,
  • Restricted Access Security Zone access is limited to authorized employees and their escorted visitors (i.e., communication closets, server rooms).

Every person authorized to enter a facility, including visitors, must be issued an identification badge that contains identifying information (such as name and photograph) and their level of building access. Badge colour or some other bold identifier may be used to represent the level of access.

  • All badges must be checked prior to entry. A receptionist, security guard or electronic reader that logs the identity, time, date, and access privileges of each entry attempt must do such checking. Entry control may be achieved using keys, proximity card readers or other technologies;
  • Employees must challenge anyone in a secure area who is not displaying an identification badge;
  • Visitor or temporary access badges must be returned and accounted for at the end of each day;
  • Entry logs must be reviewed on a quarterly basis;
  • All entry logs must be secured and maintained according to the approved records retention schedule for the system or information asset; and,
  • Access rights to secure areas must be reviewed and updated regularly.

When physical security is outsourced (i.e., the use of security guards) the contract must require that contracted employees are security screened and bonded.

b) Maintenance
Information Owner are responsible for reviewing physical entry control requirements annually. All entry controls in place must be tested annually. Security requirements for facilities must be evaluated and a Security Threat and Risk Assessment completed prior to:

  • Alteration to interior building layouts;
  • Change to equipment/systems located in the facility;
  • Change in operations; and,
  • As part of any related security incident investigation.

Guidelines:
The following guidelines support physical and environmental security by establishing security within information processing facilities:

  • Common service spaces such as eating areas, washrooms, cloakrooms, boardrooms and storage areas should be located so that they cannot be used to circumvent physical security;
  • Visitor reception should be separate from entrance areas but provide an unobstructed view of the entrance;
  • When physical security is outsourced, the contract must require that contracted employees are security screened and bonded.

The effective use of restricted access zones in an open office environment depends on the implementation of appropriate security procedures, which may include:

  • Respecting the need-to-access principle and zone perimeters;
  • Escorting visitors;
  • Securing sensitive or valuable information and assets when leaving the work areas; and,
  • Taking precautions when discussing sensitive information.

A.11.1.3 – Securing offices, rooms, and facilities

The purpose is to enhance physical and environmental security of information processing facilities by considering all security requirements during the design of the facility.XXX has taken the following security measures:

  • All employees, visitors and contract staff is supposed to report for security check-in and check-out formalities
  • Entry is restricted to authorize personnel
  • Each workstation, cubicle and cabin is provided with storage space, with lock and key arrangement to keep official documents/company classified information belonging to the employee of the workspace.
  • Employees working after office hours enter their names, and sign –in and sign-out in a separate register maintained by the security guard on duty. 

Physical security requirements must be designed, documented and applied for all areas in and around an information processing facility. Information Owners must design, document and approve security controls for information processing facilities based on a Security Threat and Risk Assessment. Considerations must include:

  • Determining security perimeter and maintenance factors;
  • Considering the operational use and information processing requirements of the facility;
  • Establishing appropriate security zones;
  • Design and construction complying with health and safety regulations and standards;
  • Designed with environmental controls for the protection of information assets (e.g., fire suppression, HVAC, generators, alarms);
  • Selecting unobtrusive sites and keep signage to the minimum required for meeting fire and other safety requirements;
  • Limiting the identification of critical information processing facility locations, in publicly and internally available directories, to the minimum required; and,
  • Selecting sites so that public access to highly sensitive or critical locations can be strictly controlled or avoided.

A.11.1.4 – Protecting against external and environmental threats

The purpose is to enhance physical and environmental security by designing and applying physical security controls to mitigate damage from natural or man-made disaster. Physical protection against damage from fire, flood, earthquake, explosion, civil unrest, and other forms of natural or man-made disaster are designed and applied. Information Owners, site planners and architects must incorporate physical security controls that protect against damage from fire, flood, earthquake, explosion, civil unrest and other forms of natural disasters, malicious attacks and accidents. Consideration must be given to any security threats presented by neighboring premises or streets. In addition to meeting building code specifications and fire regulations, the following must be considered:

  1. Combustible or hazardous materials must be stored in purposely designed rooms and in appropriate containers;
  2. Installing intrusion detection and environmental alarm systems, fire suppression and firefighting systems must be included in the design phase; and,
  3. Fallback equipment (e.g., for Disaster Recovery Plan) and backup media must be sited at a safe distance to avoid damage from a disaster affecting the main site.

A.11.1.5 – Working in secure areas

The purpose is to prevent unauthorized physical access to government information by designing and applying additional security controls and procedures for employees working in secure areas. Physical protection and guidelines for working in secure areas are:

  • Unsupervised work within server room will be strictly prohibited for safety reasons.
  • Personnel shall only be aware of the existence of, or activities within, a secure area on a need to know basis
  • Eating and consuming other food products will be strictly prohibited in secure areas.
  • Photographic, video, audio or other recording equipment should not be allowed, unless authorized

Security controls and procedures must be used by employees working in secure areas.
a) Secure area requirements for employees
b) Other secure area requirements

a) Secure area requirements for employees
Information Owners must identify and document requirements that apply to employees authorized to work in secure areas. Information Owners must ensure that background checks including criminal records reviews are conducted for employees working in secure areas. Information Owners are responsible for informing employees working within a secure area that:

  • Activities within a secure area are confidential and must not be discussed in a non-secure area – sensitive information must not be discussed with persons without a need-to-know;
  • No type of photographic (including cameras in mobile devices), video, audio or other recording equipment is to be operated in a Restricted Access Security Zone unless authorized; and,
     Information security incidents must be reported immediately.

b) Other secure area requirements
Information Owners must identify and document requirements for other individuals who may need access to a secure area. Information Owners are responsible for ensuring that:

  1. Maintenance employees, cleaners and others who may require access on an ongoing basis to the secure area must be screened and their names placed on access lists;
  2. Visitors must obtain approval for visits, be screened, and their entry and departure times logged;
  3. Employees must escort visitors when they are within secure areas;
  4. Unoccupied secure areas must be physically locked and periodically checked; and,
  5. Physical intrusion alarms and detection devices must be installed to automatically alert monitoring employees of a breach.

A.11.1.6 – Delivery and loading areas

The purpose is to prevent unauthorized physical access to the organization information by controlling access to delivery and loading areas and separating them from information processing facilities whenever possible.The delivery and handling of material is strictly under the authorization control with material gate pass. Without proper gate pass, no material is allowed to enter or leave the premises. Access to delivery and loading areas must be controlled, and where possible, separated from information processing facilities. Information Owners  must ensure that access to delivery and loading areas or access from Reception Zones is controlled. The following factors must be considered:

  1. Delivery and loading areas must be designed so that supplies can be unloaded without delivery employees gaining access to restricted access zones;
  2. Protection of the delivery and loading areas must begin at the perimeter with continuous monitoring in place (e.g., gated fence, CCTV, separation from public access);
  3. Access to delivery and shipping areas must be restricted to authorized employees only;
  4. Setting and maintaining hours of operation for delivery and pick-up;
  5. A combination of internal and external locking doors or gates must be used to provide security;
  6. Incoming and outgoing shipments should be segregated when possible;
  7. Incoming material must be inspected for potential threats before being moved to or from the delivery and loading area. Inspections can be undertaken randomly if resources are not available to inspect every package;
  8. Hazardous materials must be appropriately packaged and identified as to safety precautions;
  9. Bills of lading must be compared to goods delivered;
  10. Loading docks and delivery areas must be regularly inspected and actively monitored;
  11. Records must be kept for internal and external deliveries and shipments;
  12. Reception areas must confirm the identification of all visitors for restricted zone access; and,
  13. All visitors must be accompanied while in restricted operational and security zones.

For facilities that include delivery and loading areas, and/or reception zones, a Security Threat and Risk Assessment and inspection must be conducted to determine that access can be adequately controlled.

A.11.2 Equipment

Control Objective: To prevent loss, damage, theft or compromise of assets and interruption to the organization’s activities.

A.11.2.1 – Equipment sitting and protection

The purpose is to reduce risks to equipment from unauthorized access, environmental threats and hazards. All equipment’s are physically protected from security threats and environmental hazards, by positioning them at secure areas. Only authorized personnel can enter secured areas. The controls are adopted to minimize the risk of potential security threats. The following practices are being followed.,

  • Business critical equipment are installed in server room, which is fully secured under lock and key
  • Fire and smoke alarms are deployed appropriately.
  • The information processing and storage facilities are fully secured
  • Users are not allowed to have drink, eatables & smoke in the server room.
  • Temperature and humidity levels are continuously monitored and maintained.
  • Power equipment is periodically serviced and checked.

Equipment must be protected to reduce the risks from unauthorized access, environmental threats and hazards.
a) Equipment siting
b) Equipment protection

a) Equipment siting
Information Owners must collaborate to ensure that the design and layout of information processing facilities provides protection for equipment from security threats as supported by a Security Threat and Risk Assessment. Safeguards must include:

  1. Locating servers and other centralized computing equipment within a Restricted Access Security Zone;
  2. Locating workstations, laptops and printers in a Restricted Access Operations Zone;
  3. Protecting information processing equipment from observation by unauthorized persons, including by observing through windows and walking through work areas;
  4. Locating shared printers, scanners, copiers, and facsimile machines away from public or reception areas, or in passageways or other areas where employees who do not have a need-to-know can access printed material.

b) Equipment protection
Information Owners must collaborate to ensure that the design and layout of information processing facilities provides protection from physical and environmental hazards. Safeguards must include:

  1. Using equipment designed for suppression of electromagnetic emanations that may be used to capture information, when the need is supported by a Security Threat and Risk Assessment;
  2. Ensuring that equipment is properly vented and that the temperatures and humidity in information processing facilities are appropriate for operating equipment safely;
  3. Providing lightning protection for information processing facilities which includes surge protection for power and communications;
  4. Assessing and protecting equipment to minimize damage from fire suppression and other safety systems;
  5. Protecting equipment from potential damage from environmental hazards such as water, dust, vibration, and sunlight;
  6. Providing employees with approved eating and drinking areas separate from work areas containing equipment;
  7. Briefing employees who work with equipment about safety practices in the workplace and emergency equipment procedures to prevent an escalation in equipment damage;
  8. Keeping information processing facilities free of biological pests that pose hazards to equipment and power systems; and,
  9. Regularly inspecting the information processing facility(s) for integrity of ceilings, walls, windows, and other infrastructure for damage from water and other environmental factors that may pose a threat to safe equipment operation.

A.11.2.2 – Supporting utilities

The purpose is to ensure continued availability by protecting equipment from disruptions caused by failures in supporting utilities. All IT equipment’s are protected from power failure and other electrical anomalies. Arrangements are made to provide uninterrupted power supply (UPS) to all critical information processing facilities. UPS are maintained as per the OEM’s instructions and covered under AMC contract. Lighting protection is provided to the building. Adequate capacity of DG sets is available which are turned on in case of failure or routine power cuts.Equipment must be protected from power supply interruption and other disruptions caused by failures in supporting utilities.
a) Planning and design
b) Maintenance

a) Planning and design
Information Owners , planners, architects and engineers must collaborate in the planning and design of an information processing facility to ensure that supporting utilities (e.g., water, power, sewage, heating, ventilation) are adequate to support employees and systems that will be located in the facility. This includes estimating current and future utility capacity requirements for the facility. In addition to meeting the building code and other regulations, the following must be included in facility planning and specifications:

  • Uninterruptible power supply, back-up generators, and fuel, as required by business and technical requirements;
  • Emergency power off switches located near emergency exits in equipment rooms;
  • Emergency lighting;
  • Alarms to indicate inadequate water pressure for fire suppression;
  • Alarms to indicate malfunctions in heating, ventilation, air conditioning, humidity control and sewage systems;
  • Multiple connections to the power utility for critical systems and equipment;
  • Multiple telecommunications connections to prevent loss of voice services; and,
  • Adequate voice communications to meet regulatory requirements for emergencies.

b) Maintenance
Information Owners must ensure that facilities are inspected regularly in accordance with building codes and other regulations. Evacuation and other emergency drills must be practiced regularly in collaboration with fire and emergency services. The facility requirements for utilities shall be re-evaluated:

  • During the planning phase for replacing or changing existing technology hardware;
  • When moving significant numbers of new employees into facilities;
  • During the planning of renovations or major changes to an existing facility;
  • Prior to leasing a facility; and,
  • When there are major changes to the surrounding area that may affect utilities, evacuation routes or other safety aspects.

A.11.2.3 – Cabling security

The Purpose is to ensure continued availability and integrity of information systems and information processing facilities by protecting power and telecommunications cabling from interception and damage.The power and data cables are well protected and isolated in order to protect from interception and damage. All the cables (data, telecommunication, and electrical) are laid using proper conduits, in order to protect them from external damage. Power cables and network cables are well separated to prevent any interference.

a) Protection
Information Owner, planners and architects must include the protection of power and telecommunications cabling from interception and damage when designing or leasing facilities. The following methods to increase protection must be considered:

  • Access to communication closets and server rooms must be highly restricted;
  • Power and telecommunications cabling must be underground and/or in a secure conduit;
  • Information cabling other than fiber optic must be protected with electromagnetic shielding when required;
  • When supported by a Security Threat and Risk Assessment, consideration must be given to the use of fiber optics for telecommunications cabling;
  • Cables must not be accessible in public areas;
  • Power and telecommunications cabling must be segregated in accordance with building codes and other regulations; and,
  • Inspection boxes, termination points, patch panels, control rooms and other facilities must be secured and located inside a Restricted Access Security Zone.

b) Inspection and monitoring
Information Owners must ensure that:

  • The integrity of power and telecommunications cables are monitored through regular inspections and reports;
  • Power cabling and telecommunication schematics and documentation must be maintained in order to support inspections;
  • Records of patches and other changes are maintained and inspected;
  • Power and telecommunications cabling and wiring closets are inspected regularly and monitored for unauthorized access or inappropriate activity. The frequency of monitoring activities must be supported by a Security Threat and Risk Assessment.

A.11.2.4 – Equipment maintenance

The purpose is to ensure the continued confidentiality, integrity and availability of equipment through correct maintenance.All equipment’s in  Server Room are being correctly maintained to ensure their continued availability and integrity. Adhering to the following steps ensures this:

  • All equipment’s are maintained in accordance with the OEM’s recommendations for service intervals and specifications.
  • All critical equipment’s are covered under AMC.
  • All equipment’s are under the regular preventive maintenance.

Equipment must be correctly maintained to enable continued availability and integrity.
a) Routine maintenance
b) Maintenance of systems, hardware or media containing government information

a) Routine equipment maintenance
Equipment being repaired or maintained must be protected commensurate with the sensitivity of the information it contains and the value of the equipment. Information Owners must determine if repair or maintenance can be conducted off-site. The need to protect sensitive information may justify equipment destruction and replacement rather than repair or maintenance. Information Owners are responsible for:

  • Ensuring the scheduling of routine, preventive maintenance of equipment by qualified, authorized employees;
  • Ensuring that maintenance is performed in accordance with the manufacturer’s specifications, in compliance with warranty requirements, and using safe practices as specified in building codes, other regulations and insurance policies;
  • Ensuring that, where possible, maintenance is scheduled to avoid interference with services or operations;
  • Notifying affected employees prior to taking equipment off-line for scheduled maintenance;
  • Ensuring that the value and sensitivity of the information contained on the device is considered prior to approval of off-site maintenance;
  • Equipment sent for off-site maintenance must be inspected and logged out;
  • Ensuring equipment returning from off-site repair or maintenance is inspected and logged in;
  • Maintaining detailed records to identify trends, weaknesses and additional maintenance requirements which must include:
    • Place, date, time, type of scheduled maintenance and technical employees,
    • Suspected and actual faults identified,
    • Diagnostics performed and corrective action taken,
    • Unusual or unexpected events, such as early failures or breakdowns, and,
    • Any other event that requires maintenance.
  • Ensuring maintenance on critical equipment is undertaken in such a manner that the system is not off-line due to scheduled maintenance; and,
  • Ensuring that when equipment is brought back on-line after scheduled maintenance that all operational specifications are satisfactory.

b) Maintenance of systems, hardware or media containing government information
Dept HOD must consult with Information Owners regarding the value and sensitivity of the information stored on hardware or media when determining whether repairs will be conducted. Dept HOD must ensure that information is safeguarded:

  • Maintenance on critical systems must be undertaken in such a manner that the system is not off-line due to scheduled maintenance;
  • Hardware or media sent for repairs or maintenance outside of the information processing facility must do so through pre-approved and screened bonded couriers;
  • Hardware or media containing confidential or personal information must not have maintenance or repairs conducted off-site;
  • Hardware or media containing confidential or personal information that cannot be repaired on-site must be destroyed in accordance with approved disposal standards commensurate with the sensitivity of the information held;
  • Maintenance must be factored into system availability requirements; and,
  • Repair or maintenance must be conducted within the country.

A.11.2.5 – Removal of assets

The purpose is to protect assets belonging to the Province from unauthorized removal.All the equipment’s that are taken out of the XXX follow a proper authorization process. A proper gate pass is to be signed by the IT Manager before taking any equipment out of the XXX. Equipment, information or software belonging to the XXX must not be removed from the premises without prior authorization.Information Owners must establish a formal authorization process for the removal of assets for re-location, loan, maintenance, disposal or any other purpose. Authorization forms for asset removal must include:

  • Description and serial numbers;
  • Information about where the asset will be located;
  • The removal date and return date;
  • The identity of the individual responsible for the asset;
  • Reason for removal of the asset.

The description and serial numbers must be verified when the asset is returned. Employees must be informed of, and accept responsibility for, protection of the asset (e.g., Terms and Conditions of Use).

A.11.2.6 – Security of equipment and assets off- premises

The purpose is to protect equipment in the custody of employees from loss or unauthorized access.The person carrying the equipment outside the premises is responsible for the security of the equipment. XXX has a documented policy for Laptops and portable media taken outside premises. Equipment must be protected using documented security controls when off-site from the premises. Information Owners must ensure that equipment being used off-site to access information is protected commensurate with the sensitivity and the value of the information it contains. Information Owners must ensure that:

  • Sensitive data is encrypted;
  • Equipment is protected from unauthorized access by the use of a logical or physical access control mechanism (e.g., password, USB key or smart card);
  • Equipment is protected from loss with a physical locking, restraint or security mechanism when appropriate;
  • Employees are familiar with operation of the protection technologies in use.

To provide further protection employees must:

  • Not leave equipment unattended in a public place;
  • Ensure that equipment is under their direct control at all times when travelling;
  • Use the physical locking, restraint or security mechanisms provided by the Information Custodian whenever possible;
  • Take measures to prevent viewing of sensitive information other than by authorized persons;
  • Not permit other persons to use the equipment; and,
  • Report loss of equipment immediately using the Information Incident Management Process and General Incident or Loss Report (GILR).

A.11.2.7 – Secure disposal or re-use of equipment

The purpose is to protect information from unauthorized disclosure.The information available on equipment’s is removed or erased before the equipment disposal. The information available on equipment’s, which is re-used for some other purposes, is removed or erased before the equipment is re-used. The information available on media, which is re-used for some other purposes, is removed or erased before the media is re-used. All defective computer media, to be disposed, is destroyed completely and all relevant information is made irrecoverable.Information, records and software must be protected against unauthorized disclosure when hardware and media are reassigned or destroyed.
a) Reassignment of hardware and media
b) Destruction of hardware

a) Reassignment of hardware and media
Information Owners must consider the value and sensitivity of the information stored on hardware or media when determining whether it will be reassigned within organizations or destroyed. Reassignment must only occur within or between departments. Prior to reassignment of hardware or media, Information Owners must ensure:

  • The integrity of the records is maintained by adhering to Records Management policies;
  • Information and software are erased using methods and standards approved by the Chief Information Officer;
  • Roles and responsibilities are documented;
  • Asset inventories are updated to record details of the erasure and reassignment including:
    • Asset identifier,
    • Date of erasure,
    • Names of employees conducting the erasure,
    • Date of transfer, and,
    • Name of new asset custodian.

Where information is erased by third parties there must be contractual and audit procedures to ensure complete destruction of the media. Third parties must certify that destruction has occurred.

b) Destruction of hardware
Information Owners are responsible for ensuring hardware media used to store information or software is destroyed in a secure manner. Management Representative is responsible for ensuring secure disposal or destruction services are available to Information Owners.

A.11.2.8 – Unattended user equipment

 The purpose is to reduce risk of unauthorized access, loss or damage to information and information systems.A well-defined policy exists at XXX. regarding equipment’s unattended for a long duration. Employees must ensure unattended equipment has appropriate protection. Information Owners must ensure that employees are aware of their responsibilities to secure unattended equipment to prevent unauthorized access to information systems by:

  • Locking or terminating information system sessions before leaving the equipment unattended;
  • Enabling password protection features on the equipment (e.g., screen savers on workstations);
  • Shutting down and restarting unattended workstations at the end of each workday;
  • Enabling password protection on mobile devices including portable storage devices;
  • Being aware of their responsibility to report security weaknesses where the above controls have not been applied.

Workstations and other devices used for information system access must automatically activate screen savers or equivalent locking systems after 15 or less minutes of inactivity.

A.11.2.9 – Clear Desk and Clear screen policy

The purpose is to reduce risk of unauthorized access, loss or damage to information by ensuring employees take reasonable security precautions. Personal computers are not left logged on when not in use and are protected by password. The screen saver is password protected. Employees must ensure the safety of sensitive information from unauthorized access, loss or damage.
a) Securing the work space.
b) Secure work habits . 

a) Securing the work space
Employees must secure their work space whenever it is not supervised by an authorized person, including during short breaks, attendance at meetings, and at the end of the work day. Securing the work space includes:

  • Clearing desk tops and work areas;
  • Securing documents and mobile or portable storage devices in a locked desk or file cabinet;
  • Ensuring outgoing and incoming mail is appropriately secured;
  • Enabling a password protected screen saver;
  • Shutting down and restarting workstations at the end of each work day;
  • Locking doors and windows;
  • Checking fax machines and printers to ensure that no sensitive information is waiting to be picked up.

b) Secure work habits
Employees must develop and implement security conscious work habits to reduce the likelihood of unauthorized viewing, access or disclosure of sensitive information. Security conscious work habits include:

  • Ensuring sensitive information is protected from accidental viewing by persons passing through the work space;
  • Ensuring that only the documents required for current work are out of their normal file cabinet;
  • Ensuring white boards, bulletin boards, flip charts do not contain sensitive information when the viewing audience cannot be defined;
  • Covering up, filing or storing paper documents when visitors are present in the work area;
  • Clearing, changing or turning off the computer screen (e.g., minimize open Windows) so that sensitive information is not displayed when visitors are present in the work area; and,
  • Not discussing sensitive information in open work spaces or public areas.

Guidelines:
Ensure that offices can be locked and that storage with locks is available.

A.12 Operations Security

This establishes a framework to support the integration of information security in the services provided by the information processing facilities. Planning and management of the day-to-day activities is required to ensure the availability and capacity of the resources that provide information services. This framework identifies requirements to control and monitor operations for service delivery and to manage changes as the operations evolve. For critical systems additional requirements are defined in the Critical Systems Standard. Controls for operations include documented processes, employee duties and formal methods to implement changes to facilities. This includes methods to protect information, create copies for back-up and to manage the media where those copies are stored. Network protection requirements from threats such as viruses or unauthorized disclosure are also described.

A.12.1 Operational procedures and responsibilities

Control Objective: To ensure the correct and secure operation of information processing facilities.

A.12.1.1 – Documented operating procedures

The purpose is to ensure correct operations of information systems and information processing facilities. XXX. has a set of defined operating manuals for processing the department functionality. All documented operating manuals are identified in the ‘PAL-Process Asset Library-Content Master’. Operating procedures and responsibilities for information systems and information processing facilities must be authorized, documented, and maintained. Information Owner must ensure that approved operating procedures and standards are:

  • Documented;
  • Consistent with government policies, standards and guidelines;
  • Reviewed and updated annually or when there are:
    • Alterations to building layouts,
    • Changes to equipment/systems located in the facility,
    • Changes in business services and the supporting information systems operations, and,
    • As part of any related security incident investigation.

Operations documentation must contain detailed instructions regarding:

  • Information processing and handling;
  • Last review and update;
  • Classification of document;
  • System re-start and recovery;
  • Back-up and recovery, including on-site and off-site storage;
  • Exceptions handling, including a log of exceptions;
  • Output and media handling, including secure disposal or destruction;
  • Audit and system log management;
  • Change management including scheduled maintenance and interdependencies;
  • Computer room management and safety;
  • Information Incident Management Process;
  • Disaster recovery;
  • Business continuity;
  • Operations, technical, emergency and business contacts.

A.12.1.2 –Change management

The purpose is to ensure changes to information systems and facilities are applied correctly and do not compromise the security of information and information systems.Whenever a change in the IT infrastructure is to be done, a proper evaluation and analysis is done which includes cost, security, technical functionality and compatibility. Any user can initiate change request. Manager/IT is authorized to initiate the change & Head/IT approves these operational and process changes. To control all operational changes XXX. has defined policy. Changes to information systems and information processing facilities must be controlled.
a) Planning changes
b) Change management process
c) Implementing change

a) Planning changes
Information Owners must plan for changes to information systems and information processing facilities by assessing the impact of the proposed change on security by conducting a security review based on the size of the change.

b) Change management process
Information Owners must plan, document and implement a change management process to control changes by:

  • Identifying and recording significant changes;
  • Assessing the potential impact, including the security impact, of the change by conducting a Security Threat and Risk Assessment;
  • Developing an implementation strategy;
  • Obtaining approval of changes from the manager(s) responsible for the information system;
  • Planning and testing changes including documenting fallback procedures;
  • Communicating change details to relevant employees;
  • Identifying the impact on agreements with business partners and third parties including information sharing agreements, Memoranda of Understanding, licensing and provision of services;
  • Evaluating that planned changes were performed as intended; and,
  • Training technical and operations employees if required.

c) Implementing changes
Information Owners must implement changes by:

  • Notifying affected parties, including business partners and third parties;
  • Completing re-certification and re-accreditation as required prior to implementation;
  • Training employees if required;
  • Documenting and reviewing the documentation throughout the testing and implementation phases;
  • Recording all pertinent details regarding the changes;
  • Checking after the change has been performed that only the intended changes took place.

A.12.1.3 – Capacity management

The purpose is to protect information and information systems from unauthorized access, theft or misuse. It is the responsibility of the individual managers to look for capacity demands for their projects in advance. This ensures that the required capacity can be arranged in time to minimize the risk of failure due to lack of capacity. It also ensures the continuous availability of operational systems. Utilization of existing resources is monitored regularly.Controls must be applied to limit opportunities for information leakage. Information Owners must implement processes to reduce the opportunity for information leakage in information systems by:

  • Scanning for malicious code;
  • Monitoring resource usage in information systems;
  • Identifying and limiting the trusted connections in and out of the government network;
  • Controlling third party network connections (e.g., only authorized traffic permitted);
  • Using software that is considered to be of high integrity;
  • Regular monitoring of information systems; and
  • Reviewing usage and access logs for irregularities.

Guidelines:
Scanning outbound media and communications for hidden information should be considered.

A.12.1.4 – Separation of development, test and operational facilities

The purpose is to reduce the risk of system failures and unacceptable performance levels by monitoring and optimizing resources to meet current and future information system capacity requirements. The development and testing activities shall not be done in production server.The use of information system resources must be monitored, optimized and projections made of future capacity requirements.
a) Resource capacity management
b) Resource capacity planning

a) Resource capacity management

Information Owners are responsible for implementing capacity management processes by:

  • Documenting capacity requirements and capacity planning processes;
  • Identifying and managing storage requirements;
  • Including capacity requirements in service agreements;
  • Monitoring and optimizing information systems to detect impending capacity limits;
  • Projecting future capacity requirements based on:
    • New business and information systems requirements,
    • Statistical or historical capacity requirement information,
    • Current and expected trends in information processing capabilities (e.g., introduction of more efficient hardware or software).

b) Resource capacity planning

Information Owner must use trend information from the capacity management process to identify and remediate potential bottlenecks that present a threat to system security or services. Information Owners must plan and budget for business and service capacity management.

Guidelines:
Resource capacity management processes should be automated where feasible.

A12.2 Protection from Malware

Control Objective: To protect the integrity of software and information processing facilities are protected against malware.

A.12.2.1 – Controls against malicious code

The purpose is to protect the integrity of information systems and software through requirements for the prevention and detection of network and host-based threats.Precautions are required to prevent and detect the introduction of malicious software. Software information processing facilities are vulnerable to the introduction of malicious software, such as computer viruses, network worms, Trojan horses, and logic bombs etc. XXX. has implemented several controls to address the threat:

  • XXX. has a policy for prevention against malicious software.
  •  XXX. has a policy for the use of networks or any other medium as a preventive measure against virus attacks.
  • Virus attacks and software malfunctions due to malicious software are treated as security incidents and handled.
  • To prevent loss of data due to malicious software regular backups of critical data are taken regularly.

Security awareness, prevention and detection controls must be utilized to protect information systems against network and host-based threats.
a) Prevention and detection controls
b) User awareness

a) Prevention and detection controls
Information Owners must protect government information systems from network and host-based threats by undertaking such activities as:

  • Installing, updating and consistently using software designed to scan for, detect and provide protection from network and host-based threats;
  • Prohibiting the use of unauthorized software;
  • Checking files, including electronic mail attachments and file downloads for malware before use;
  • Maintaining business continuity plans to recover from security incidents;
  • Regularly reviewing file and data content on critical systems to identify unapproved or unauthorized files and file changes; and
  • Scanning back-up media prior to restoration so that malware is not introduced or re-introduced into an information system and network.

The Chief Information Security Officer must ensure processes are implemented to:

  • Maintain a critical incident management plan to identify and respond to security incidents; and,
  • Maintain a register of specific threat countermeasures (e.g., blocked websites, blocked electronic mail attachment file types, blocked network ports, additional monitoring, etc.) including a description, the rationale, the approval authority and the date applied.

b) User awareness
The Chief Information Security Officer is responsible for developing user awareness programs for threat countermeasures. The Information Security Officers are responsible for communicating technical advice and providing information and awareness activities regarding network and host-based threats. Employees are required to complete the information protection courses provided by the CISO as part of their awareness training.

A.12.3 Back-up

Control Objective: To maintain the integrity and availability of information and information processing facilities.

A.12.3.1 – Information back up

The purpose is to enable the timely recovery of information and information systems.  Backup of informational Servers are taken regularly. XXX. has a well-defined procedure for Information backup and restoration. Information and information systems must be backed up and the recovery process tested regularly.
a) Defining requirements
b) Safeguarding backup facilities and media
c) Testing

a) Defining requirements
Information Owners must define and document backup and recovery processes that reflect the security classification and availability requirements of information and information systems including:

  • Confirming that the backup and recovery strategy complies with:
    • Business continuity plans,
    • Policy, legislative, regulatory and other legal obligations, and,
    • Records management requirements, including the Administrative Records Classification System (ARCS)
    • Operational Records Classification System (ORCS), and,
  • Documenting the backup and recovery processes including:
    • Types of information to be backed up,
    • Schedules for the backup of information and information systems,
    • Backup media management (e.g., retention period, pattern of backup cycles),
    • Methods for performing, validating and labelling backups, and,
    • Methods for validating recovery of the information and information system.

b) Safeguarding backup facilities and media
Information Owner must conduct a Security Threat and Risk Assessment to identify safeguards for backup facilities and media that are commensurate with the value and sensitivity of the information and information systems. Safeguards include:

  • Using encryption to protect the backed up information;
  • Using digital signatures to protect the integrity of the information;
  • Physical and environmental security;
  • Access controls;
  • Methods of transit to and from offsite locations (e.g., by authorized couriers, by encrypted electronic transfer);
  • Storage of media adhering to manufacturer recommendations for storage conditions and maximum shelf-life; and,
  • Remote storage of backup media at a sufficient distance to escape any damage from a disaster at the main site.

c) Testing
Information Owners must regularly test backup and recovery processes.

A.12.4 Logging and Monitoring

Control Objective: To detect unauthorized information processing activities

A.12.4.1 – Event logging

The purpose is t0 ensure usage of information systems can be monitored and audited. XXX. has defined policy for event logs.  All systems are monitored to detect deviation from access control policy. This audit trail serves as evidence in case of security breach, and is the basis for any action. Audit logs are maintained on servers and provide audit information related to User Id, Date and time of log-on and log-off, failed login attempts, Terminal Location. Audit logs must be produced, retained and regularly reviewed.
a) Audit logging
b) Review of monitoring activities
c) Audit log retention
d) Response to alarms

a) Audit logging
Information Owners must ensure that audit logs are used to record user and system activities, exceptions, and information security and operational events including information about activity on networks, applications and systems. Information Owners and Information Custodians will determine the degree of detail to be logged based on the value and sensitivity of information assets, the criticality of the system and the resources required to review and analyze the audit logs. Audit logs must include, when relevant, the following information:

  • User identifier;
  • Dates, times and details of key events (e.g., logon and logoff);
  • Logon method, location, terminal identity (if possible), network address;
  • Records of successful and unsuccessful system logon attempts;
  • Records of successful and unsuccessful data access (including record and field access where applicable) and other resource access attempts;
  • Changes to system configuration;
  • Use of privileges;
  • Use of system utilities and applications;
  • Files accessed and type of access (e.g., view, read, modify, delete);
  • For voice calls: source and destination telephone numbers, date, time, and length of call;
  • Name and size of file attachments that are part of or are included in data transmissions (e.g., email, instant messaging, unified communications platforms, etc.);
  • Network addresses (source and destination), ports (source and destination), protocols, and transferred network data traffic flow (packets and bytes);
  • Alarms raised by the access control system;
  • Activation and de-activation of protection systems (e.g., anti-virus, intrusion detection).

Audit logs may contain confidential data and access must be restricted to employees with need-to-know privileged access and be protected accordingly. Information Owners must not have the ability to modify, erase or de-activate logs of their own activities. If audit logs are not activated, this decision must be documented and include the name and position of the approver, date and a rationale for de-activating the log. Where required, the Privacy Impact Assessment and Security Threat and Risk Assessment must be updated to reflect this decision.

b) Review of monitoring activities
Information Owner must set up and document processes for the review of audit logs based on the Information Owners assessment of the value and sensitivity of the information assets, the criticality of the system and the resources required for review. Audit log reviews must:

  • Prioritize reviews of high value and highly sensitive information assets;
  • Be based on a documented Security Threat and Risk Assessment; and
  • Utilize automated tools to identify exceptions (e.g., failed access attempts, unusual activity) and facilitate ongoing analysis and review.

Monitoring must be tested at least annually to ensure that desired events are detected. Analysis of monitoring activities can indicate:

  • The efficacy of user awareness and training and indicate new training requirements;
  • Vulnerabilities that could be, or that are being, exploited; or
  • Increases or decreases in unauthorized access attempts or unauthorized use of privileges.

c) Audit log retention
Audit logs must be:

  • Retained according to the approved records retention schedule for the system or information asset; and,
  • Retained indefinitely if an investigation has commenced which may require evidence be obtained from the audit logs.

d) Response to alarms
Information Owners must establish and document alarm response procedures in collaboration with Information Owners to ensure alarms are responded to immediately and consistently. They should have documented authority to shut down all or part of a system or network when the alarm indicates new unacceptable threats are present. When exercising this authority, Information Owners must report the circumstances to the CISO as soon as possible .Normally, the response to an alarm will include:

  • Identification of the alarm event;
  • Isolation of the event including affected assets;
  • Identification and isolation or neutralization of the source;
  • Corrective action;
  • Forensic analysis of event;
  • Action to prevent recurrence; and,
  • Securing of audit logs as evidence.

A.12.4.2 – Protection of log information

The purpose is to preserve the integrity of information system logging facilities and log information. Logging facilities and log information are protected against tampering and unauthorized access.Information system logging facilities and log information must be protected against tampering and unauthorized access.
a) Protecting information system logging facilities
b) Protecting log information

a) Protecting information system logging facilities
CISO is responsible for ensuring periodic independent reviews or audits are conducted to confirm that Information Owners have implemented appropriate controls. They must implement controls to protect logging facilities and log files from unauthorized modification, access or disposal. Controls must include physical security safeguards such as situating logging facilities within a secure zone with restricted access.

b) Protecting log information
Information Owners must apply controls to protect log files from tampering or modification. Controls must include:

  • Consideration of multi-factor authentication for access to sensitive records;
  • Back-up of audit logs to off-site facilities;
  • Automatic archiving of audit logs to remain within storage capacity;
  • Scheduling the audit logs as part of the records management process; and,
  • Digital signing for detecting alteration or corruption where available.
  • All employees must not have permission to erase logs or de-activate logging of their own activities.

A.12.4.3 – Administrator and operator logs

The purpose is to protect information from unauthorized access, modification or deletion. Logging facilities and log information are protected against tampering and unauthorized access.Activities of privileged users must be logged, and the log must be subject to regular independent review.
a) Activities logged
b) Independent review
c) Repairing and logging fault
d) Analysis, resolution and corrective action

a) Activities logged
Privileged users typically have extensive system permissions not granted to most users. Information Owners must ensure that the activities of privileged users are regularly reviewed, including logging:

  • Event occurrence times;
  • Event details, such as files accessed, modified or deleted, errors and corrective action;
  • Identity of the account and the privileged user involved; and,
  • The system processes involved.

Privileged users must not have permission to erase logs or de-activate logging of their own activities.

b) Independent review
Information Owner must have a documented process to ensure that activity of privileged users is independently reviewed. Reviews must be conducted regularly and at random with the frequency being commensurate with the criticality, value and sensitivity of system and information assets. Following verification of logs, the individual checking them should digitally sign them and store or archive them securely in accordance with the approved records retention schedule. The audit logs must be reviewed prior to being discarded or overwritten.

c) Reporting and logging faults
Information Owners must implement processes for monitoring, reporting, logging, analyzing and correcting system faults reported by users and automated detection systems. Fault logging requirements should be determined through a Security Threat and Risk Assessment and Privacy Impact Assessments. Fault management reports must include:

  • Description of fault including date and time, location, extent of fault;
  • Analysis of probable source and cause;
  • Actions taken to respond to and resolve the fault; and,
  • Corrective action taken.

d) Analysis, resolution and corrective action
Information Owners must review fault logs to ensure that faults have been resolved and documented in a fault management report. They must provide the fault management report to CISO.
Analysis and corrective action includes:

  • Defining the fault and probable cause(s);
  • Assessing the effectiveness of corrective action(s);
  • Checking to ensure that corrective action has not introduced unforeseen vulnerabilities;
  • Identifying trends so that corrective action makes increasingly effective use of resources while improving results;
  • Recommending upgrades, replacement of components, software or other elements that create or cause faults;
  • Improving fault detection and reporting to reduce the time between fault occurrence and taking corrective action;
  • Measuring the exposure caused by the fault;
  • Reporting on performance impact(s); and,
  • Periodically re-assessing logging requirements.

A.12.4.4 – Clock synchronization

the purpose is to ensure the integrity of information system logs.The correct setting of critical computer clocks is important and carried out to ensure the accuracy of audit logs, which may be required for investigation or as evidence in legal or disciplinary cases.  One Server is identified as Time Master Server & other Servers of the network are synchronized with the Master.Computer clocks must be synchronized for accurate reporting.
a) Synchronization
b) Checking and Verification

a) Synchronization
System administrators must synchronize information system clocks to:

  • the local router gateway; or,
  • the Government approved clock host.

b) Checking and Verification
System administrators must confirm system clock synchronization:

  • Following power outages or brownouts;
  • As part of incident analysis and audit log review; and,
  • At least semi-annually in conjunction with Daylight Savings Time.

Time discrepancies must be reported to IT Helpdesk, Customer Service Centre. The clock hosts must be synchronized with a national time service

A.12.5 Control of operational software

Control Objective: To ensure the integrity of operational systems.

A.12.5.1 – Installation of software on operational systems

The purpose is to prevent compromise of operational information systems providing services from unauthorized software installation. To ensure secured implementation of Software on Operational System. The installation  of software on operational information systems providing services must be controlled.
a) Software changes to operational information systems
b) Software implementation controls
c) Protection of systems documentation

a) Software changes to operational information systems
Information Owners must implement procedures to control software installation on operational information systems providing services to ensure that:

  • Updates of operational information systems are planned, approved, impacts assessed, tested, logged and have a rollback plan;
  • Operations employees and end users have been notified of the changes, potential impacts and if required have received additional training;
  • New releases of software are reviewed to determine if the release will introduce new security vulnerabilities;
  • Modifications to operational software are logged;
  • The number of employees able to perform the updates is restricted and kept to a minimum;
  • Development code or compilers are not present on operational information systems;
  • Vendor supplied software is maintained at the supported level.

b) Software implementation controls:

  1. Pre-Implementation
    Before an updated or new information system is implemented into the operational environment, checks must be performed to ensure that:

    • A Security Threat and Risk Assessment has been carried out;
    • A Privacy Impact Assessment has been performed and approved;
    • Limitations of security controls are documented;
    • Performance and capacity requirements can be met and support organizations have the capacity to maintain the information system;
    • Development problems have been resolved successfully;
    • The effects on existing operational information systems are known;
    • Arrangements for fall-back have been established if the updated or new information system fails to function as intended;
    • Error recovery and restart procedures are established;
    • Business continuity plans are developed or updated;
    • Operating procedures are tested;
    • Changes are communicated to users who may be affected by the change;
    • Users are educated to use the information system correctly and securely; and,
    • Computer operators and system administrators are trained in how to run the information system correctly and securely.
  2. Implementation
    The installation process must include:

    • Validating the load or conversion of data files;
    • Installing executable code only, and not source code;
    • Providing ongoing technical support;
    • Implementing new or revised procedures and documentation;
    • Discontinuing old software, procedures and documentation;
    • Arranging for fallback in the event of failure;
    • Informing the individuals involved of their roles and responsibilities;
    • Transferring responsibility for the information system from development teams to operational teams to ensure segregation of duties; and,
    • Recording installation activity.
  3. Post-implementation
    Post-implementation reviews must include:

    • The efficiency, effectiveness and cost of security controls;
    • Lessons learned and scope for improvements of security controls; and,
    • Security incidents and mitigation.

c) Protection of systems documentation
Information Owners must ensure that documented procedures for the secure use and storage of systems documentation are established and followed. Procedures must:

  • Require information classification labelling of system documentation;
  • Establish lists of users authorized to access system documentation on a ‘need to know’ basis;
  • Establish handling rules for the information regardless of storage media (e.g., electronic, paper);
  • Require use of access controls, passwords, encryption or digital signatures as appropriate to the information classification; and,
  • Include a compliance monitoring process.

A.12.6 Technical Vulnerability Management

Control objective: To reduce risks resulting from exploitation of published technical vulnerabilities.

A.12.6.1 – Management of technical vulnerabilities

The purpose is to mitigate damage to government operations resulting from exploitation of published vulnerabilities. XXX. is using VA/PT to obtain information on new exposures while applying patches for earlier identified threats and vulnerabilities. The VA/PT shall be carried out as per Security Committee Review Procedure. Appropriate actions will be initiated based on threat assessment diagnosed from VA/PT.Assessments for known exposures must be conducted to evaluate information system vulnerabilities and the management of associated risks. Vulnerabilities which impact information systems must be addressed in a timely manner to mitigate or minimize the impact on government operations. Information Owners must establish processes to identify, assess and respond to vulnerabilities that may impact information systems by:

  • Monitoring external sources of information on published vulnerabilities;
  • Assessing the risk of published vulnerabilities;
  • Testing and evaluating options to mitigate or minimize the impact of vulnerabilities;
  • Applying corrective measures to address the vulnerabilities;
  • Completing a Security Threat and Risk Assessment to verify the risk has been mitigated; and,
  • Reporting to the Chief Information Security Officer on progress in responding to vulnerabilities.
  • Responsibilities for vulnerability response by service providers must be included in external party service agreements.

The Chief Information Security Officer must:

  • Evaluate vulnerabilities and provide advice on appropriate government responses;
  • Monitor progress in responding to vulnerabilities;
  • Publish summary reports on vulnerability response activities and costs; and,
  • When required, initiate incident response processes to address vulnerabilities.

A.12.6.2 – Restrictions on software installation

The purpose is to limit the installation of software to authorized employees to avoid security incidents. Users should not run any unauthorized or undocumented software on their desktops. IT department will approve on the recommendation of Department Heads, the installation of any software on Desktop/Laptop/Servers. Review of the rules governing the installation of software by employees must be established and implemented. Uncontrolled installation of software on computing devices can lead to introducing vulnerabilities and then to information leakage, loss of integrity or other information security incidents, or to violation of intellectual property rights. Employees must receive authorization prior to installing software on government devices. Software installation must be consistent with the requirements of the Appropriate Use Policy.

A.12.7 Information systems audit considerations

Control Objective: To maximize the effectiveness of and to minimize interference to/from the information systems audit process.

A.12.7.1- Information systems audit controls

The purpose is to prevent compliance checking activities from causing unplanned disruptions to operational information systems.Audit activities involving checks on operational system shall be carefully planned and agreed to minimize the risk of disruption to business processes. Audit requirements and activities involving checks on operational systems must be planned and approved to minimize disruption to business processes.Audit requirements and activities involving checks on operational systems must be planned and approved to minimize disruption to business processes.
a) Management of information systems compliance checking
b)Protection of information system audit tools

a) Management of information systems compliance checking
Prior to commencing compliance checking activities such as audits, risk and controls reviews, monitoring or security reviews of operational information systems, the Manager responsible for the compliance checking activity, Information Owners must define, document and approve the activities by:

  • Determining the scope, duration and level of detail of the compliance checking activity;
  • Limiting access rights to operational information systems for compliance checking employees to “read only”;
  • Determining handling requirements for copies of files made by compliance checking employees including:
    • establishing a separate environment for the analysis of files,
    • restricting access to those files,
    • logging the accesses made to those files, and,
    • erasing files at the conclusion of compliance checking activities unless needed to support report findings;
  •  Identifying special testing or processing which may impact the operational information system (e.g., penetration tests, server vulnerability assessments) and by:
    • notifying the Chief Information Security Officer prior to compliance checking activities to prevent triggering false security alarms from the infrastructure, and,
    • scheduling tests to minimize disruption;
  • Submitting the reports of penetration tests or vulnerability assessments to the Chief Information Security Officer immediately upon receipt; and,
  • Requiring that employees conducting compliance checking activities maintain a segregation of duty from the operational information systems being checked.

Guidance for compliance checking activities can be obtained from the Information Security Branch, Office of  Chief Information Officer.

b) Protection of information system audit tools
Managers responsible for compliance checking activities and Information Custodians must control the use of audit tools by:

  • Restricting access to authorized employees who have a need-to-know;
  • Installing or enabling specialized audit tools for the duration required by the compliance checking activity;
  • Removing information system access at the conclusion of the compliance checking activities; and,
  • Notifying the Chief Information Security Officer prior to the use of audit tools.

A.13 Communications and Operations Management

It identifies the information security requirements for network and communication services.

A.13.1 Network security management

Control Objective: To ensure the protection of information in networks and the protection of the supporting infrastructure.

A.13.1.1 – Network controls

The purpose is to ensure that network security controls and network security management practices are implemented and documented to maintain network security. XXX. has a dedicated team of employed professionals in network, who are responsible for the smooth and secure operation of the network. Policies of network usage are defined. 9.1.1 Controls must be implemented to achieve and maintain security within the government network.
a) Control and management of networks
b) Configuration control
c) Secured path
d) Wireless Local Area Networking
e) Equipment management
f) Logging, monitoring and detection
g) Coordination and consistency of control implementation

a) Control and management of networks
Information Owners must implement network infrastructure security controls and security management systems for networks to ensure the protection of information and attached information systems. Selection of controls must be based on a Security Threat and Risk Assessment, taking into account the information security classification determined by the Information Owners, and applicability to the network technology. The Security Threat and Risk Assessment must consider network-related assets which require protection including:

  • Information in transit;
  • Stored information (e.g., cached content, temporary files);
  • Network infrastructure;
  • Network configuration information, including device configuration, access control definitions, routing information, passwords and cryptographic keys;
  • Network management information;
  • Network pathways and routes;
  • Network resources such as bandwidth;
  • Network security boundaries and perimeters; and,
  • Information system interfaces to networks.

b) Configuration control
To maintain the integrity of networks, Information Owners must manage and control changes to network device configuration information such as configuration data, access control definitions, routing information and passwords. Network device configuration data must be protected from unauthorized access, modification, misuse or loss by the use of controls such as:

  • Encryption;
  • Access controls and multi-factor authentication;
  • Monitoring of access;
  • Configuration change logs;
  • Configuration baselines protected by cryptographic checksums; and,
  • Regular backups.

Status accounting must be regularly performed to ensure that configuration baselines reflect actual device configuration.

c) Secured path
Where required by information classification and a Security Threat and Risk Assessment, information must only be transmitted using a secured path. Secured paths for information transmission must use controls such as:

  • Data, message or session encryption, such as SSH, SSL or VPN tunnels; and,
  • Systems to detect tampering.

d) Wireless Local Area Networking
Wireless Local Area Network access points must be authorized by the Chief Information Officer for attachment to the government network. Wireless Local Area Networks must utilize the controls specified by the Chief Information Security Officer and must include:

  • Strong link layer encryption, such as Wi-Fi Protected Access;
  • User and device network access controlled by government authentication services;
  • The use of strong, frequently changed, automatically expiring encryption keys and passwords;
  • Segregation of wireless networks from wired networks by the use of filters, firewalls or proxies; and,
  • Port-based access control, for example use of 802.1x technology.

Where supported by the information classification or a Security Threat and Risk Assessment, additional controls for wireless networks may include:

  • Virtual Private Network tunnel technology;
  • The use of Desktop Terminal Services (DTS) technology; and,
  • Intrusion detection systems, firewalls and Media Access Control (MAC) address filtering.

e) Equipment management
Information Owners must document responsibilities and procedures for operational management of network infrastructure, including devices at network boundaries and in user areas.

f) Logging, monitoring and detection
To facilitate monitoring, response and investigation, logging to a centralized log management service must be enabled, including logging of:

  • Traffic traversing network security boundaries;
  • Traffic within networks housing sensitive or critical systems or information;
  • Security-relevant events on network devices, such as operator logon and configuration changes;
  • Security-relevant events on systems that provide authentication and authorization services to network infrastructure devices such as routers, firewalls or switches.

Logs must be continuously monitored to enable detection and response to security events and intrusions (e.g., automation of log monitoring and event alerting). Logs from available sources (including, but not limited to, network traffic, network firewalls, Intrusion Prevention Systems, routers, switches, content filtering, servers, applications, databases, application firewalls, authentication services) must be continuously correlated to enable detection and response to security events and intrusions, that otherwise would go undetected without such correlation and alerting.
In order to support the monitoring and correlation of logs from available sources, in cases when infrastructure or services are provided via a third-party, it must be ensured that security event logs from the respective outsourced infrastructure or services can be forwarded real-time to the centralized monitoring services to allow for the centralized monitoring, correlation and alerting across the organization. Information Owner must ensure there is a clear segregation of duties for employees involved in logging, monitoring or detection activities. Active automated surveillance of networks must be implemented to detect and report on security events (e.g., network intrusion detection systems). Sensors enabling on-demand capture of network traffic must be implemented at network security boundaries and within networks housing sensitive information or information systems as determined by a Security Threat and Risk Assessment.

g) Coordination and consistency of control implementation
Information Owners must document network security controls in the System Security Plan including:

  • A summary of risks identified in the Security Threat and Risk Assessment;
  • Roles and responsibilities for network security management;
  • Specific procedures and standards used to mitigate risks and protect the network;
  • Communication procedures for security-relevant events and incidents; and,
  • Monitoring procedures (including monitoring frequency, review and remediation processes).

A.13.1.2 – Security of network services

The purpose is to specify what security features are required for delivery of a network service. Security attributes for network services like Leased Line / Wireless Radio modem is taken care through SLA (Service Level Agreement) with ISP (Internet Service Provider) viz., STPI. Security configuration, service levels and management requirements of all network services must be documented and included in any network service agreement. Formal network service agreements must be established between network service providers and consumers of network services to specify service levels, services offered, security requirements and security features of network services. The network service agreement must include specification of:

  • The rules of use to be followed by consumers to maintain the security of network services;
  • The schedule for ongoing verification of network security controls;
  • The rights of either party to monitor, audit or investigate as needed;
  • Security incident response responsibilities, contacts and procedures; and,
  • The requirement to meet or exceed government Information Security Policy and standards.

Information Owners must confirm that the specified security features are implemented prior to commencement of service delivery.

A.13.1.3 – Segregation in networks

The purpose is to isolate information systems, users and networks based on risk and business connectivity requirements. Groups of information services, users and information systems must be segregated on networks.
a) Segregation based on risk and requirements.

a) Segregation based on risk and requirements
Information Order must segregate services, information systems and users to support business requirements for information system connectivity and access control based on the principles of least privilege, management of risk and segregation of duties. Information Order must establish network perimeters and control traffic flow between networks. Network traffic flow control points such as firewalls, routers, switches, security gateways, VPN gateways or proxy servers must be implemented at multiple points throughout the network to provide the required level of control. The techniques and technologies selected for network segregation must be based on Security Threat and Risk Assessment and Privacy Impact Assessment findings. Factors to consider include:

  • The information and information system security classification;
  • The trustworthiness of the network, based on the amount of uncontrolled malicious traffic present, the level of device identification and authentication in the networks, and sensitivity to eavesdropping (e.g., the Internet is a less trusted network than a controlled server network zone);
  • Transparency, usability and management costs of network segregation technologies; and,
  • The availability of compensating controls for detection, prevention and correction of malicious network traffic and unauthorized access attempts.

Network zones must be defined and network perimeters established, according to business requirements and risk as identified in the Security Threat and Risk Assessment and Privacy Impact Assessment (e.g., network zones, core network, wireless network). Information system operational management and business applications must be defined and separated by network flow control points.

Guidelines:
Security gateways should be used to verify the trustworthiness of devices attempting to connect to the network (e.g., VPN Quarantine systems, network switch isolation and admission control systems).

A.13.2 Exchange of Information

Control Objective: To maintain the security of information and software exchanged within an organization and with any external entity. 

A.13.2.1 – Information transfer policies and procedures

The  purpose is to protect information from unauthorized disclosure. The Electronic Office Systems like Telephone, Fax etc. are maintained by a 3rd Party. Security of Information available through such system is ensured through suitable clauses in the contract. Users shall be made aware about the risk of Information Security while exchanging information through Voice, Fax, and Video Communication facility. The Information exchange policies, procedures and controls must be documented and implemented to protect the exchange of information through all types of electronic communication services. The Chief Information Security Officer must document and implement procedures to protect information from interception, copying, misrouting and disposal when being transmitted electronically. Transmission methods include but are not limited to:

  • E-mail, including attachments;
  • Electronic file transfer (e.g., File Transfer Protocol (FTP), Electronic Data Interchange (EDI));
  • Use of mobile devices;
  • Telephone, cell, and other voice messaging;
  • Faxes; and,
  • Instant messaging.

A.13.2.2 – Agreements on information transfer

The purpose to protect information or software from loss or unauthorized disclosure. Agreements shall be established for the exchange of information and software between XXX and external parties like Oracle, MS, and IBM etc. Information and software exchange agreements between XXX and other organizations must address the secure transfer of information between parties.
a) Exchange agreements
b) Information and software exchange requirements

a) Exchange agreements
Information Owners must ensure the terms and conditions for secure exchange of information assets with external parties is documented in an agreement. The agreement must define:

  • Custody and control accountabilities;
  • Authority of a custodian to publish, grant access to or redistribute the information;
  • Purpose and authorized uses of the information or software;
  • Limitations on data linkage;
  • Duration, renewal and termination provisions;
  • Primary contacts for agreement, governance and management;
  • Requirements for:
    • Protecting information according to its security classification,
    • Handling information (e.g., recording authorized recipients, confirming receipt of transmitted data, periodically reviewing records of authorized recipients),
    • Labelling information (e.g., methods to be used to apply and recognize labelling),
    • Maintaining integrity and non-repudiation of information, and,
    • Media management and disposal;
  • Technical standards for transmission, recording or reading information or software;
  • Responsibilities for reporting privacy and security incidents and breaches;
  • Liability, accountability and mitigation strategies, for attempted, suspected or actual privacy and security incidents and breaches; and,
  • Problem resolution and escalation processes.

b) Information and software exchange requirements
Information Owners must ensure an approved Privacy Impact Assessment and a Security Threat and Risk Assessment are completed for the information or software covered by the exchange agreement. Exchange agreements must be reviewed by legal counsel for the Province prior to being signed.

A.13.2.3– Electronic messaging

The purpose is to  enable secure and trustworthy electronic messaging. The electronic mail systems are properly secured from unauthorized access by using Spam protection software & Anti-Virus firewall, and from viruses by deploying antivirus software. XXX. has a well-defined policy and guidelines on the use of electronic mail. Information transmitted by electronic messaging must be appropriately protected.
a) General requirements
b) Custody of electronic messages

a) General requirements
Electronic messaging services must be managed to protect the integrity of government messages by:

  • Protecting messages from unauthorized access, modification or denial of service;
  • Ensuring correct addressing and transportation of messages;
  • Providing reliable and available messaging infrastructure; and,
  • Conforming to legislative, regulatory and policy requirements.

The Chief Information Officer must approve implementation of, and significant modification to, electronic messaging systems. Employees must support the responsible use of electronic messaging services by:

  • Using only government electronic messaging systems for conducting government business, including systems for remote access to government messaging systems from publicly available networks;
  • Using only authorized encryption for e-mail or attachments;
  • Not automatically forwarding government e-mail to external e-mail addresses; and,
  • Maintaining the confidentiality and privacy of information being communicated in electronic messages as appropriate to the sensitivity and classification of the information.

Information Owners must authorize and approve the use of social media services and other non-government electronic messaging services for conducting government business.

b) Custody of electronic messages
Electronic messages created, compiled, sent or received on government information systems are records of the government. These records:

  • Are the property of XXX;
  • Must be managed in accordance with the Information Management Act and related regulations, policies, standards and procedures; and,
  • Are subject to the access and the protection of privacy provisions of the Freedom of Information and Protection of Privacy Act.

A.13.2.4 – Confidentiality or non-disclosure agreements

The purpose in to ensure employees understand their role in maintaining the confidentiality of information and information systems. All contractors and external parties are required to sign NDA as covered by respective contract guidelines. A confidentiality agreement reflecting organizational requirements for the handling of information must be in place and reviewed regularly. Information Owners must:

  • Ensure employees are informed of their obligation to maintain the confidentiality of information; and,
  • Ensure individuals other than employees accept and sign an agreement to maintain the confidentiality of information.
  • Confidentiality requirements must be reviewed and updated annually.

A.14 Systems acquisition, development and maintenance

This establishes requirements for incorporating security measures into the life-cycle of an information system. Security controls must be identified as part of the business requirements for new information systems or enhancements to existing information systems. Information security is integrated into the creation, modification, implementation and expansion by ongoing security practices such as the management of vulnerable points and securing system files. For applications, information security can be applied to the validation of data input and output and by encoding information using electronic keys.

A.14.1 Security requirements of information systems

Control Objective: To ensure that security is an integral part of information systems.

A.14.1.1 – Security requirements analysis and specification

The purpose is to integrate system security requirements into business processes supporting the development, maintenance and acquisition of information systems.XXX., will acquire and accept hardware and software. .Security controls must be identified as part of the business requirements for new information systems or enhancements to existing information systems.
a) Security requirements for information systems
b) Security requirements at implementation

a) Security requirements for information systems

Information Owners must conduct a Security Threat and Risk Assessment and a Privacy Impact Assessment during the requirements phase when developing, implementing major changes to, or acquiring an information system, to:

  • Identify the security requirements necessary to protect the information system; and,
  • Assign a security classification to the information and the information system.

The Information Owner must ensure that information system development or acquisition activities are done in accordance with documented requirements, standards and procedures which include:

  • Testing the information system to verify that it functions as intended;
  • Enforcing change control processes to identify and document modifications or changes which may compromise security controls or introduce security weaknesses; and,
  • Using common processes and services (e.g., authentication, access control, financial management).

b) Security requirements at implementation
Information Owners must ensure that sufficient controls are in place to mitigate the risk of information loss, error or misuse from information systems. Prior to implementation, information systems must be assessed to verify the adequacy of, and document the details of, the security controls used, by completing a security certification. Different tiers of applications need to be separated across different platforms or servers (e.g., web interface must be on a different server from the data base).Information systems should have a documented and maintained System Security Plan. The Plan should include:

  • A summary of risks identified in the Security Threat and Risk Assessment;
  • Results of the system certification;
  • Roles and responsibilities for information system security management;
  • Specific procedures and standards used to mitigate risks and protect the information system;
  • Communication procedures for security-relevant events and incidents; and,
  • Monitoring procedures.

While Security Threat and Risk Assessments are not required for all apps on mobile devices, where the app is used for processing government information, a Security Threat and Risk Assessment and Privacy Impact Assessment must be completed before the use of the app. Apps should be downloaded only from official vendor provided app stores. Mobile devices attached to the government network must be used according to vendor specifications (e.g., not removing vendor built-in restrictions). Employees should always consider potential risks before downloading apps on their mobile devices. Some apps have been found to have harmful effects and may inadvertently release information from the mobile device to third parties.

A.14.1.2 – Securing applications services on public networks

The Purpose is to enable secure electronic commerce for the delivery of services. Information in application services information systems must be protected from fraudulent activity, contract dispute, unauthorized disclosure and modification.
a) Electronic commerce
b) Electronic documents

a) Electronic commerce
Prior to initiating or implementing electronic commerce information systems, Information Owners  must:

  • Ensure that the Security Threat and Risk Assessment is conducted and addresses threats and risks related to electronic commerce;
  • Confirm that a Privacy Impact Assessment has been conducted and approved;
  • Determine the security classification of the information and information system involved;
  • Ensure that the user notification and acceptance of terms and conditions of use complies with policies and standards;
  • Ensure multi-factor authentication is used commensurate with the sensitivity and value of the information;
  • Develop and implement processes to maintain content currency;
  • Confirm the information system has received security certification and accreditation;
  • Develop Business Continuity Plans and supporting Disaster Recovery Plans.

b) Electronic documents
When accepting or submitting electronic documents, Information Owners  must:

  • Authenticate the users claimed identity;
  • Determine an authorization process for approving contents, issue or sign key documents;
  • Determine the requirements for confidentiality, integrity, proof of dispatch and receipt of key documents and the confidentiality of contracts; and,
  • Ensure the protection requirements of any confidential information.

A.14.1.3 – Protecting application services transactions

The Purpose is to maintain the confidentiality, integrity and availability of on-line transactions in information systems. Information systems utilizing on-line transactions must have security controls commensurate with the value and sensitivity of the information.
a) On-line transaction security
b) Payment card transaction security

a) On-line transaction security
Information Owners are responsible for ensuring information systems containing on-line transactions have implemented security controls commensurate with the value and sensitivity of the information. Security controls must be implemented to prevent incomplete transmission, misrouting, repudiation of transaction, unauthorized message alteration, unauthorized disclosure, unauthorized message duplication and replay. Security controls include:

  • Validating and verifying user credentials;
  • Using digital signatures;
  • Using cryptography to protect data and information;
  • Establishing secure communications protocols; and,
  • Storing on-line transaction details on servers within the appropriate network security zone.

b) Payment card transaction security
Information Owners are responsible for ensuring that information systems used for processing payment card transactions, or connected to payment card transaction processing systems, comply with the Payment Card Industry Data Security Standard. The Payment Card Industry Data Security Standard V3.0 has 12 high-level requirements:
 Install and maintain a firewall configuration to protect cardholder data

  • Do not use vendor-supplied defaults for system passwords and other security parameters;
  • Protect stored cardholder data;
  • Encrypt transmission of cardholder data across open, public networks;
  • Protect all systems against malware and regularly update anti-virus software or programs;
  • Develop and maintain secure systems and applications;
  • Restrict access to cardholder data by business need-to-know;
  • Identify and authenticate access to system components;
  • Restrict physical access to cardholder data;
  • Track and monitor all access to network resources and cardholder data;
  • Regularly test security systems and processes; and,
  • Maintain a policy that addresses information security for all employees.

 A.14.2 Security in development and support processes

Control Objective: To maintain the security of application system software and information.

A.14.2.1 – Secure development policy

The purpose is to ensure that information security is designed and implemented within the development life-cycle of information systems. Software development will be as per the agreed Software Development Lifecycle defined in ‘PR-09-SLC-Software Life Cycle Process.doc’. Policies, standards, and guidelines for the development of software and systems must be established and applied to developments within the organization.
a) Secure development process
b) Secure programming techniques

a) Secure development process
Information Owners  must ensure that software and systems developed internally follow established policies, standards and best practices for secure development process. The established policies and standards must be applied consistently to all developments within the organization. A secure development process is a necessity in developing a secure information system. Within a secure development life-cycle of information systems, the following aspects must be considered:

  • Security of the development environment;
  • Security in the software development methodology;
  • Secure coding guidelines for each programming language used;
  • Inclusion of security requirements starting from the design phase;
  • Security checkpoints within the development milestones;
  • Secure repositories;
  • Security in the version control and updates;
  • Required application security knowledge; and,
  • Developer capability of avoiding, finding and fixing vulnerabilities.

b) Secure programming techniques

Secure programming techniques must be used both for new developments and in code re-use scenarios where the standards applied to development may not be known or are not consistent with current best practices. Secure coding standards must be considered and where relevant mandated for use.

  • Program code must not be altered unless authorized to do so;
  • Any variations to program code must be documented; and,
  • All changes to existing code must ensure applicable standards have been applied for program security.

If development is outsourced, the organization must obtain assurance that the external party complies with the policies for secure development.

A.14.2.2 – Change control procedures

The purpose is to ensure that information systems are not compromised from changes to software..XXX. has a defined procedure to manage and control changes in the software developed and support systems, during the development life cycle. Changes to software must be controlled by the use of formal change control procedures.
a) Changes to software during information systems development
b) Changes to software for operational information systems 

a) Changes to software during information systems development
Information Owners must implement a change control process during development which includes:

  • Requiring that change requests originate from authorized employees;
  • Requiring that proposed changes are reviewed and assessed for impact; and,
  • Logging all requests for change.

b) Changes to software for operational information systems
Information Owners must implement a change control process during the maintenance phase including:

  • Requiring that change requests originate from authorized employees;
  • Performing an impact assessment considering items such as the System Security Plan and proposed modifications;
  • Documenting fallback plans;
  • Documenting approval of changes proposed prior to the commencement of the work;
  • Documenting the acceptance tests and approval of the results of acceptance testing;
  • Updating the System Security Plan and other system, operations and user documentation with the details of changes in accordance with records management policy;
  • Maintaining version control for all changes to the software; and,
  • Logging all requests for change.

A.14.2.3 – Technical review of applications after operating system changes

The purpose is to ensure information systems will not be disrupted or compromised. The application systems are reviewed to ensure that there is no adverse impact on operation and security due to changes in operating system. Information systems must be reviewed and tested when operating system changes occur. Information owners must notify CISO and other affected parties of operating system changes to allow:

  • Sufficient time for the review and testing of information systems prior to implementation;
  • Review of System Security Plans to ensure information systems will not be compromised by the change;
  • Significant changes to the operating system must have a completed Security Threat and Risk Assessment completed;
  • Information system testing with the changes to the operating system in a separate (i.e., test) environment; and,
  • Update of business continuity plans if required.

A. 14.2.4 – Restrictions on changes to software packages

The purpose is to reduce the risk of information system functionality loss.Modification to software package is not permitted without the consent of project team. To ensure that only desired changes are implemented after the approval, a process need to be followed for controlling the changes in software packages.Modification of commercial-off-the-shelf software is limited to essential changes that are strictly controlled and documented.
a) Modifying commercial-off-the-shelf software
b) Applying vendor supplied patches and updates

a) Modifying commercial-off-the-shelf software
Other than vendor supplied patches, commercial-off-the-shelf (COTS) software must not be modified except in exceptional circumstances when needed for a critical business requirement. This requirement must be documented and approved by the Information Owner. If changes to COTS software are required, the Information Owners must determine:

  • The effect the change will have on the security controls in the software;
  • If consent of the vendor is required;
  • If the required functionality is included in a new version of the software;
  • If government will become responsible for maintenance of the software as a result of the change; and,
  • Compatibility with other software in use.

if changes are made to COTS software the original software must be kept unaltered and the changes must be:

  • Logged and documented, including a detailed technical description;
  • Applied to a copy of the original software; and,
  • Tested and reviewed to ensure that the modified software continues to operate as intended.

b) Applying vendor supplied patches and updates
A software update management process must be maintained for commercial-off-the-shelf (COTS) software to ensure:

  • The most up-to-date approved patches have been applied; and,
  • The version of software is vendor supported.

A. 14.2.5 – Secure System Engineering Principles

The purpose is to ensure information security is designed in all architectural layers of information systems.Software development will be as per the agreed Software Development Lifecycle defined in ‘PR-09-SLC-Software Life Cycle Process.doc’. Principles for engineering secure systems must be established, documented, maintained and applied to any information system implementation efforts.
a) Secure engineering principles
b) Outsourcing engineering security
c) Application development

a) Secure engineering principles
Information Owners must establish and document secure information system engineering procedures based on security engineering principles and best practices. The procedures must be applied to all in-house information system engineering activities. Security must be designed into all architecture layers (business, data, applications and technology) balancing the need for information security with the need for accessibility. New technology must be analyzed for security risks and the design must be reviewed against known attack patterns. Secure engineering procedures must be reviewed regularly to ensure they remain current to reflect the changes in the environment and threat landscape.

b) Outsourcing engineering security

Information Owners must ensure that contracts and other binding agreements incorporate the secure engineering principles and procedures for outsourced information systems.

c) Application development
Application development procedures must apply secure engineering techniques in the development of applications that have input and output interfaces and provide guidance on user authentication techniques, secure session control and data validation, sanitization and elimination of debugging codes.

A. 14.2.6 – Secure Development Environment

The purpose is to ensure the security of information during the development and system integration process.To secure the selected product of development environment the process of configuration management need to be adopted so that the correct product is available to authenticated users. Organizations must establish and appropriately protect secure development environments for system development and integration efforts that cover the entire system development life-cycle. A secure development environment includes people, processes and technologies associated with system development and integration. Information Owners must assess the risks associated with individual system development efforts and establish secure development environments for system development, considering:

  • Sensitivity of data to be processed, stored or transmitted by the system;
  • Applicable external and internal requirements (e.g., from regulations, policies and standards);
  • The need for segregation between different development environments;
  • Security controls already in place that support system development;
  • Trustworthiness of employees working in the environment;
  • The degree of outsourcing associated with system development;
  • Control of access to the development environment;
  • Monitoring of changes to the environment and code stored therein;
  • Backups are stored at secure offsite locations; and,
  • Control over movement of data from and to the environment.

Once the level of protection is determined for a specific development environment, Information Owners must document corresponding processes in secure development procedures and provide these to all individuals who need them. Personal information must not be used in the testing or development phases without a valid policy exemption from the Office of the Chief Information Officer.

A.14.2.7 – Outsourced software development

The purpose is to ensure information systems perform as expected and meet security requirements.Controls must be applied to secure outsourced information system development.Information Owners must consider the following when outsourcing information system development:

  • Procurement policy for licensing, ownership and intellectual property rights;
  • Escrow arrangements in the event of the failure of the external party;
  • Testing of the information system for common vulnerabilities and malicious code;
  • Rights of access for audit and certification of the quality and accuracy of the work; and,
  • Contractual requirements for quality and security functionality of the information system.

Information Owners must ensure that the outsourced information system meets the requirements defined in the system development agreements.

A. 14.2.8 – System security testing

The purpose is to ensure that security functionality is carried out during the development process. Testing of security functionality must be carried out during development.Information Owners must ensure that new and updated systems undergo thorough testing and verification during the development processes. A detailed schedule of test activities, inputs and expected outputs under a range of conditions must be prepared as part of testing and verification processes.Independent acceptance testing must be undertaken to ensure that the system works as expected and only as expected. The extent of testing must be in proportion to the importance and nature of the system.

A.14.2.9 – System acceptance testing

The purpose is to ensure that new or upgraded information systems are tested against defined, agreed and documented criteria for acceptance, prior to becoming operational.New information systems, upgrades, and new versions are put through a system acceptance for their acceptability and interoperability. A separate environment comprising of hardware and software is used to carry out tests prior to deploying or upgrading the main system. Appropriate tests are carried out to confirm that all acceptance criteria are fully satisfied. The tests results are documented and operational, maintenance and usage procedure are established. Training is provided for use and operation of new system. Acceptance criteria for new information systems, upgrades and new versions must be established and suitable tests of the system carried out prior to acceptance.
a) System acceptance process
b) System acceptance criteria
c) Security certification
d) System accreditation

a) System acceptance process
Information Owners must ensure that system acceptance criteria are defined as part of the system development and acquisition process. Prior to implementing new or upgraded information systems, Information Owners must ensure:

  • Acceptance criteria are identified including privacy, security, systems development and user acceptance testing;
  • Security certification is attained, indicating the system meets minimum acceptance criteria; and,
  • Security accreditation to proceed with implementation is attained.

A Privacy Impact Assessment must be completed for new or upgraded information systems.

b) System acceptance criteria
Information Owners must document system acceptance criteria, including:
• Projected performance and resource capacity requirements;
• Disaster recovery, restart, and contingency plans and procedures;
• Impact on standardized routine operating procedures and manual procedures;
• Implementation of security controls;
• Assurance that installation of the new system will not adversely affect existing systems, particularly at peak processing times;
• Business continuity arrangements;
• Training requirements; and,
• User acceptance testing.

c) Security certification
The Information Owners must receive assurance that a new or updated information system meets minimum security acceptance criteria.Assurance should be obtained by conducting either an independent Security Threat and Risk Assessment or a Risk and Controls Review which determines whether a system includes adequate controls to mitigate security risks. This process will also determine the effect of the new system on the overall security of government information systems.

d) System accreditation
Information Owners must authorize the implementation of new or upgraded information systems based on the degree to which the acceptance criteria are satisfied.

A.14.3 Test Data

Control Objective: To ensure the protection of data used for testing.

A.14.3.1 – Protection of test data

The Purpose is to protect information from unauthorized access or use. System and acceptance testing usually requires substantial volumes of test data that are as close as possible to operational data, hence test data is carefully selected and controlled such that security violations do not occur. Test data must be protected and controlled using the same procedures as for data from operational information systems. Information Owners must implement procedures to ensure that:

  • Using test data extracted from operational information systems is authorized and logged to provide an audit trail;
  • Test data is protected with controls appropriate to the security classification of the information and information system; and,
  • Data from operational information systems is removed from the test environment once testing is complete.

Sensitive or personal information from operational information systems should not be used as test data. Where personal or sensitive data must be used for testing purposes, sensitive details and content should be removed, depersonalized or de-identified. In rare cases when sensitive or personal data from operational systems has to be used for testing purposes, the following conditions must be met:

  • Information Owners must provide a strong business case for the use of operational data containing sensitive or personal data for testing purposes;
  • Privacy Impact Assessment and Security Threat and Risk Assessment must be completed specific to the use of operational data in test;
  • Use of production data for testing purposes must be approved by the Executive Director and Chief Information Officer;
  • Testing with the use of operational data must occur only in a production-like environment;
  • The data to be used for testing purposes in the production-like environment must be handled with the same care and diligence as in the production environment with the same or more stringent security controls;
  • Access to test data must be limited to the minimum number of individuals required to perform testing activities and must be based on clearly defined roles and responsibilities, and formal approval process;
  • Information Owners must ensure that access to sensitive or personal information used for testing is monitored and reviewed on a regular basis to detect inappropriate or unauthorized access attempts, at a minimum once a week;
  • Where sensitive or personal information is used, Information Owners must ensure that only information fields necessary for testing be used (e.g., if successful results can be achieved using the last four digits of a Social Insurance Number, avoid using the whole number);
  • Information Owners must ensure that the smallest subset of sensitive or personal information is used, which is necessary to complete the testing (e.g., if successful results can be achieved using a small number of records, avoid using the whole dataset);
  • Information Owners must maintain detailed project documentation on testing activities and processes for audit purposes, including a list of employees involved in testing, date and time when testing began and ended, any deviations from the established processes or procedures that may affect the existing security controls, and any other relevant information; and,
  • The documentation must demonstrate why the use of sensitive or personal information is necessary.

Information Owners must ensure that the use of personal information for testing purposes does not contravene the requirements of the Freedom of Information and Protection of Privacy Act. Privacy. HR manager should be consulted when test data involves personal information.

Guidelines:
Output from test systems should be labelled “test”.

A.15 Supplier relationships

This covers the requirements for information security in supplier agreements. These are important to consider in outsourcing deals, awarding contracts and in IT procurement services.

A.15.1 Security in supplier relationship

Control Objective: To maintain the security of XXX.’s information and information processing facilities that are assessed, processed, communicated to, or managed by external parties or suppliers.

A.15.1.1 – Information security policy for supplier relationships

The purpose is to ensure that risks associated with external party access to information and information systems have been mitigated by applying security controls as determined by business needs.XXX has identified risks from third-party access mainly in two categories viz., Physical and Network. Risk areas have been identified and appropriate measures shall be taken to mitigate them. They have been addressed adequately in the following sections of this chapter.

  1. A.11.1.2 – Physical entry controls
  2. A.9.1.2 – Access to network and network services

 All contract personnel are given restricted access as per the requirement of the service they are providing and as per the contractual obligations. All third parties working at the premises have signed Non-Disclosure Agreement (NDA) at the time of contracts. Identified security requirements must be addressed, agreed upon and documented prior to granting external parties access to information, information systems or information processing facilities.
a) Security requirements
b) Cloud Computing Policy
c) Awareness requirements

a) Security requirements
Prior to granting access to non-public information and information systems for external parties Information Owners  must:

  • Determine that mitigation strategies have been implemented to address security requirements;
  • Review the Security Threat and Risk Assessment for asset protection requirements including:
    • Asset classification,
    • Legislative, regulatory and policy considerations, and,
    • Intellectual property rights obligations;
  • Complete a Privacy Impact Assessment;
  • Determine that security controls will not adversely affect target service levels; and,
  • Document the roles and responsibilities of the Information Owner and the external party in a formal agreement.

b) Cloud Computing Policy
Cloud computing relies on sharing resources rather than having local servers handle applications and storage. Cloud computing is a term used to describe on-demand resource pooling, rapid elasticity and measured services with broad network access (e.g., Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS)).
The Cloud Computing Policy is a documented corporate policy for the purchase and use of cloud services, which is:

  • Based on the  Chief Information Officer’s strategy;
  • Approved by executive  Director;
  • Distributed to all relevant individuals throughout the organization; and, 
  • Applied throughout the organization

Information Owners are responsible for determining the information security classification of the data to be moved to a cloud service and the security requirements in using cloud computing services. Information Owners must include the Chief Information Security Officer, or a designate, as part of the business functions (e.g., procurement and legal) for all cloud initiatives, and in the definition of standard and contractual requirements for the procurement and use of cloud services, to ensure that all controls and protection levels for cloud services have security by design.

c) Awareness requirements
Specific awareness activities must be performed to help ensure all employees:

  • Are aware of the corporate policy on the use of cloud services; and,
  • Are educated about the risks of using unapproved cloud services.

A.15.1.2 – Addressing security within supplier agreements

The purpose is to ensure external parties accessing information assets and information processing facilities are required to implement and use security controls. All agreements with the supplier who provides any type of services to XXX & have access to the premises of XXX shall have a clause related to security and Access Control as under

“The vendor will adhere to security guidelines of XXX while delivering the services and follow access privileges & rights provided with precaution and safety measures indicated for each of them.  Non-adherence of these guidelines may result in termination of the agreement and/ or claiming of liability/ damages caused due to non-adherence of these instruction.”

External party access to information, information systems or information processing facilities must be based on a formal contract containing necessary information security requirements.
a) External party access agreements
b) Security requirements
c) Service level continuity

a) External party access agreements

Information Owners and Information Custodians must ensure access to information assets and information processing facilities by external parties is only provided after an access agreement has been completed and signed. Access agreements must include:

  • Roles and responsibilities of the Information Owner, Information Custodian and the external party;
  • Non-disclosure agreements;
  • Sub-contracting requirements;
  • Specialized security controls (i.e., meet particular business and security arrangements, legal or regulatory requirements);
  • Conditions for contract termination;
  • Audit and compliance monitoring rights, responsibilities and processes;
  • Reporting obligations for suspected or actual security and privacy incidents;
  • Renewal and extension conditions; and,
  • Requirements for regular compliance reviews.

Approved forms of agreement include:

  • General Service Agreement for purchase of goods or services;
  • Agreements for Alternate Service Delivery;
  • Information Sharing Agreement; or,
  • Other forms of agreement as approved by Legal Services.

b) Security requirements

Information Owners must ensure the security requirements of external party access agreements include:

  • Notification of obligations of the parties to adhere to legislation and regulation;
  • Requirements to adhere to agreed information security policies and procedures;
  • Processes for amending the agreement;
  • Acknowledgement by the external party that ownership of information is retained by the Province;
  • Confidentiality obligations of the external party and their employees or agents;
  • Requirements for use of unique user identifiers;
  • Processes for conducting audits and compliance monitoring activities;
  • Responsibilities and processes for reporting security and privacy incidents; and,
  • Assurances that disciplinary action will be applied to employees or contractors who fail to comply with the terms of the agreement.

c) Service level continuity
Information Owners must ensure supplier service agreements document service level continuity requirements and include processes for:

  • Ongoing review of service level needs with business process owners;
  • Audit and compliance monitoring rights and responsibilities;
  • Communicating requirements to service providers;
  • Obtaining periodic confirmation from service providers that adequate capacity is maintained;
  • Reviewing the adequacy of the service provider’s contingency plans for responding to disasters or major service failures; and,
  • Establishing the metrics for service delivery levels (including risk profiles and audit trigger levels).

A.15.1.3 – ICT (Information and Communication Technology) Supply chain

The purpose is to identify security controls concerning supply chain security in supplier agreements.All agreements with the Information & Communication Technology service provider, who provides any such type of services to XXX, shall have the requirements to address information security risk in the agreement.Agreements with suppliers must include requirements to address the information security risks involving or associated with information and communications technology components, services and product supply chain. Information Owners must identify the security risks concerning the supplier chain relationships and specify the necessary controls in the agreements. Supply chain risk management practices should be built on top of general information security, quality, project management and system engineering practices but do not replace them. Information Owners must work with suppliers to understand their supply chain and any matters that have an impact on the products and services being provided. Agreements with suppliers must address the security requirements that involve other suppliers in the supply chain. Supply chain as addressed here includes cloud computing services. The following security controls must be considered for inclusion in supplier agreements concerning supply chain security:

  • Defining information security requirements that apply to information systems and information technology product or service acquisitions;
  • Requiring that suppliers apply security requirements throughout their supply chain if the services are further subcontracted as a whole or in part;
  • Requiring that suppliers apply appropriate security practices throughout the supply chain for products that include components purchased from other suppliers;
  • Implementing a monitoring process and acceptable methods for validating that delivered information and communication technology products and services are adhering to stated security requirements;
  • Implementing a process for identifying product or service components that are critical for maintaining functionality and therefore require increased attention and scrutiny when built outside of the organization especially if the top tier supplier outsources aspects of product or service components to other suppliers;
  • Obtaining assurance that critical components and their origin can be traced throughout the supply chain;
  • Obtaining assurance that the delivered information and communication technology products are functioning as expected without any unexpected or unwanted features;
  • Defining the rules for sharing of information regarding the supply chain and any potential issues and compromises among the organization and suppliers; and,
  • Implementing specific processes for managing information and communication technology component life-cycle and availability and associated security risks. This includes managing the risks of components no longer being available due to suppliers no longer being in business or suppliers no longer providing these components due to technology advancements.

A.15.2 Supplier service delivery management

Control Objective: To maintain an agreed level of information security and service delivery in line with supplier agreements.

A.15.2.1 – Monitoring and review of supplier services

The purpose is to ensure that services delivered by external parties maintain compliance with security and audit requirements. The services, reports and records provided by the third party are regularly monitored and reviewed regularly. Services provided by external parties must be regularly monitored and the reports and records reviewed. Information Owners must establish processes to manage and review the information security of external party delivered services by:

  • Assigning responsibility for monitoring to a designated employee;
  • Maintaining an inventory of agreements and associated access rights;
  • Monitoring for compliance through processes such as:
    • Conducting internal self-assessments of control processes,
    • Requiring external parties conduct and submit self-assessments,
    • Using embedded audit tools,
    • Requiring external parties to submit annual management assertions that controls are being adhered to,
    • Conducting independent security reviews, audits and updates to risk and controls reviews, and,
    • Analysis of audit logs;
  • Establishing a process, jointly with the service provider, to monitor, evaluate, investigate and remediate incidents; and,
  • Establishing performance measures within service plans to ensure adequate service levels are maintained and measured.

A.15.2.2 – Managing changes to supplier services

The purpose is ensure that changes to information system services delivered by external parties maintain or enhance security controls. Changes to the provision of services, including maintaining and improving existing information security policies, procedures and controls, shall be managed, taking account of the criticality of business systems and processes involved and re-assessment of risks. Changes to the provision of services by suppliers for information system services must take into account the criticality of the information systems, processes involved and reassessment of risks. Information Owners must ensure agreements with external party service providers include provisions for:

  • Amending agreements when required by changes to legislation, regulations, business requirements, policy or service delivery; and,
  • Requiring the service provider to obtain pre-approval for significant changes involving:
    • Network services,
    • New technologies,
    • Use of new or enhanced system components (e.g., software or hardware),
    • System development, test tools and facilities,
    • Modification or relocation of the physical facilities, and,
    • Sub-contracted services.

Information Owners must ensure the change management process for information systems services delivered by external parties includes, as required:

  • Reviewing and updating the Security Threat and Risk Assessment to determine impacts on security controls;
  • Implementing new or enhanced security controls where identified by the risk assessment;
  • Reviewing and updating the Privacy Impact Assessment;
  • Initiating and implementing revisions to policies and procedures; and,
  • Revising employee awareness and training resources.

A.16 Information security incident management

This establishes requirements for reporting a possible breach of information security as quickly as possible. This includes establishing procedures and processes so that employees understand their roles in reporting and mitigating security events. Information security incident management policies identify mechanisms to detect and report when information security events occur and the directives for the consistent management of such events. The information collected about the events can be analyzed to identify trends and to direct efforts to continually improve and strengthen the information security infrastructure of the Province.

A.16.1 Management of information security incidents and improvements

Control Objective: To ensure a consistent and effective approach to the management of information security incidents, including communication on security events and weaknesses. 

A.16.1.1 – Responsibilities and procedures

The purpose is to enable quick and orderly management of information security incidents. Incident management responsibilities and procedure exist to ensure a quick, effective, and orderly response to security incidents. Incident management responsibilities and procedures must be established to ensure a quick, effective and orderly response to information security incidents. Information Owners must adopt the Information Security Incident Management Process and ensure that those responsible for information security incident management understand the priorities for handling information security incidents. XXX must follow the established Information Incident Management Process for reporting, managing, responding to and recovering from information security incidents. The process must include:

  • Procedures for incident response planning and preparation;
  • Procedures for monitoring, detecting, analyzing and reporting of information security incidents;
  • Procedures for logging incident management activities; and,
  • Procedures for handling different types of information security incidents, including immediate action for containment, response escalation and contingency plans.

Employees with security incident management responsibilities must be appropriately trained and deemed qualified (e.g., in forensics and investigations), and their authorization for access to live systems and data must be delineated formally. Incident response processes must be documented, tested and rehearsed regularly to evaluate their effectiveness. In case of an information security incident, the Chief Information Officer must be provided access to all and any relevant primary data stores in a quick, effective and expedient manner to ensure an orderly response to incidents. The Information Incident Management Process includes the following documents:

  • Information Incident Management Process document;
  • Information Incident Report Form;
  • Easy Guide for Responding to Information Incidents;
  • Process for Responding to Privacy Breaches; and,
  • Information Incident Checklist.

Guidelines:
Potential types of security incidents to be reported include:

  • Suspected or actual breaches of privacy and/or confidentiality;
  • Denial of service;
  • Detection of network probing;
  • Detection of malicious code (e.g., virus, worm, Trojan horse);
  • Errors due to incomplete or inaccurate data;
  • Outgoing network traffic not associated with typical business processing;
  • Repeated attempts of unauthorized access;
  • Inappropriate use of government information resources;
  • Repeated attempts to e-mail unknown internal accounts;
  • System activity not related to typical business processing;
  • System failures and loss of service;
  • Privacy breaches of personal information;
  • Responses to phishing attacks;
  • Threatening or harassing communication; and,
  • Sharing of user credentials.

Employees who regularly ignore information security and privacy policies should be subject to a disciplinary process that includes notification of their Supervisor and suspension of privileges for repeated offences.

A.16.1.2 – Reporting information security events

The purpose is to enable prompt response to information security events and identify government wide trends.Security events are defined as incidents that could cause unauthorized disclosure, modification, or destruction of, XXX’s information assets, or loss or destruction of the physical equipment associated with the computer systems, it’s peripheral or network infrastructure components. Security incidents also include other aspects of security, such as carrying fire arms, or other lethal weapons on property, are as typically secured being left unlocked or unattended, fire or hazardous material spills, or witnessing someone performing an unsafe act, or committing a violation of security policies or procedures etc. All users in the, XXX are responsible to report any observed or suspected security incidents through email/help desk phone/on-line Incident reporting system available on Intranet. The security incidents are reported and are managed by the documented procedure. Information security events must be reported immediately.
a) Reporting information security events
b) Information security event logging

a) Reporting information security events
As required by the Information Incident Management Process, employees must immediately report all suspected or actual information security events as quickly as possible to their Dept. head. Dept. head will ensure that senior managers and  Chief Information Security Officer are also informed. CISO will seek further details and may give advice on next steps. All employees must be aware of:

  • Procedures for reporting information security events; and,
  • Points of contact for reporting.

Requirements for reporting events must be included in contracts and service agreements. Situations to be considered for information security event reporting include:

  • Ineffective security controls;
  • Breach of information integrity, confidentiality or availability expectations;
  • Breach of personal privacy;
  • Human errors;
  • Non-compliance with policies or guidelines;
  • Breaches of physical security arrangements;
  • Uncontrolled system changes;
  • Malfunctions of software or hardware; and,
  • Access violations.

b) Information security event logging
Information security event logs are logs that could be used in security investigations, auditing or monitoring and could give rise to a security incident. Security events may be any activities that can potentially impact the confidentiality, integrity or availability of government information in both paper and electronic format. Information security event logs are notification or alert that a device or software may be technically capable of producing, and are related to its status (e.g., configurations changes, log-on or log-off events), or its function and activities (e.g., data, traffic or sessions routed, transmitted, blocked, permitted). Information security event logging must always be enabled to provide context and data to support security investigation, audit, and monitoring. Information security event logging is not limited to security devices, but is applicable to any and all devices, systems, software or applications that can produce logs that can be used to validate the confidentiality, integrity or availability of government information whether in security investigations, auditing or ongoing monitoring. Examples of devices, systems, software or applications that can produce information security logs include, but are not limited to, routers, switches, content filtering, network traffic flow, network firewalls, Intrusion Prevention/Detection Systems, servers, applications, databases, operating systems, application firewalls, authentication services, directory services, DHCP, DNS, and hardware platforms. All devices, systems, software or applications that have logging capabilities must be configured to produce logs to enable the detection of security events and intrusions that otherwise would go undetected without such logging. If the logging that the device or software is technically capable of producing is disabled or only partially configured, then this decision must be documented and include the rationale for deactivating or only partially implementing the logging. The corresponding Security Threat and Risk Assessment must be updated to reflect this decision and must assess whether the risk introduced by the lack of logging is acceptable.

Guidelines:
The Information Incident Management Process should be part of the Business Continuity Program. The awareness program should build trust with employees and stress that “to err is human”. Positive reinforcement of good computing and reporting practices will help employees understand their responsibilities. Employees who commit errors that lead to security incidents should receive appropriate training and counselling.

A.16.1.3 – Reporting information security weaknesses

The purpose is to assist in maintaining the security of information system. Security weaknesses are defined as loopholes, weak points or vulnerabilities in the information system. These vulnerabilities or the loopholes may be exploited to gain unauthorized access to data or systems. All users in the, XXX. are responsible to note and report any such observed or suspected security weakness. Any user (viz., employee, contractor and third party) can report the incident using email/help desk phone/online system available on Intranet. Employees using the organization’s information systems must note and report any observed or suspected security weaknesses in those systems. All employees must report as quickly as possible any observed or suspected security weaknesses in information systems. Ministries must follow the Information Incident Management Process for responding to suspected or actual security weaknesses which includes:

  • Reporting to the Chief Information Officer, Risk Management and Security Office, as appropriate. The response process must:
    • ensure all reports are investigated and handled in a secure, confidential manner, and,
    • ensure the individual who reported the weakness is advised of the outcome when the investigation is complete; and,
  • A user awareness program on information security advising employees that:
    • they have a responsibility to report observed or suspected weaknesses to the Ministry point-of-contact,
    • suspected or observed weaknesses must not be tried or tested, and,
    • weaknesses should not be discussed, or made known, except through approved reporting channels.

Guidelines:
The reporting and response processes for all security weaknesses, threats, events and incidents should be consolidated to avoid duplication and establish a consistent approach.

A.16.1.4 – Assessment and decision of information security events

The purpose is to help assess and classify events to identify if they are information security incidents. All incidents occurring in the, XXX. are documented and stored and handled as per the procedure.The Chief Information Security Officer must assess each information security event using the agreed upon information security event and incident classification scale and decide whether the event should be classified as an information security incident. An information incident is a single or a series of unwanted or unexpected events that threaten privacy or information security. Information incidents include the collection, use, disclosure, access, disposal, or storage of information, whether accidental or deliberate, that is not authorized by the business owner of that information. Information incidents include privacy breaches. Results of assessments and decisions should be recorded in detail and provided to the Chief Information Officer.

A.16.1.5 – Response to information security incidents

The purpose is to identify in advance of an information security incident, the authority to respond in a controlled manner. All incidents occurring in the, Information security incidents must be responded to in accordance with the documented procedures. Information security incidents must be responded to by the Chief Information Security Officer and other relevant employees of the organization or external parties. The response should include the following:

  • Collecting evidence as soon as possible after the occurrence;
  • Conducting information security forensics analysis, as required;
  • Escalation, as required;
  • Ensuring that all involved response activities are properly logged for later analysis;
  • Communicating the existence of the information security incident or any relevant details thereof to other internal and external people or organizations with a need-to-know;
  • Dealing with information security weaknesses found to cause or contribute to the incident; and,
  • Once the incident has been successfully dealt with, formally closing and recording it.

The goals of incident response are to resume ‘normal security level’ and to initiate the necessary recovery. Post-incident analysis should take place, as necessary, to identify the source of the incident. Information security incidents must be responded to in accordance with the documented procedures. Information security incidents must be responded to by the Chief Information Security Officer and other relevant employees of the organization or external parties. The response should include the following:

  • Collecting evidence as soon as possible after the occurrence;
  • Conducting information security forensics analysis, as required;
  • Escalation, as required;
  • Ensuring that all involved response activities are properly logged for later analysis;
  • Communicating the existence of the information security incident or any relevant details thereof to other internal and external people or organizations with a need-to-know;
  • Dealing with information security weaknesses found to cause or contribute to the incident; and,
  • Once the incident has been successfully dealt with, formally closing and recording it.

The goals of incident response are to resume ‘normal security level’ and to initiate the necessary recovery. Post-incident analysis should take place, as necessary, to identify the source of the incident.

A.16.1.6 – Learning from information security incidents

The purpose is to identify and use information security incident trends to update the Information Security Policy and supporting security processes. All incidents occurring in the, XXX. are documented and stored in the Corrective and Preventive Actions database. The , XXX. consolidates the incident reports for root cause analysis and considers these as an input for appropriate actions and necessary controls to avoid reoccurrence of the incidents.Knowledge gained from analyzing and resolving information security incidents must be used to reduce the likelihood or impact of future incidents. The Chief Information Security Officer is responsible for monitoring and evaluating information security incidents by:

  • Using statistical analysis of incident frequency, type and location to identify trends;
  • Ensuring incident reports and trends are used to promote continuous improvement of security policies and processes, security awareness and training programs, and business continuity and disaster recovery plans;
  • Advising Information Owners and Information Custodians and Ministry Information Security Officers of evolving security exposures and mitigation strategies;
  • Evaluating the effectiveness of incident management, response and reporting; and,
  • Evaluating the effectiveness of information security technologies.

The Chief Information Security Officer must provide incident information to the Executive Director. as appropriate. The CISO  is the center of expertise and an essential capability in security incident protection, detection, response and correction where employees assigned responsibility for information incident management receive special training in managing crises across the spectrum of potential incidents. Information sharing with stakeholder and partner organizations. Information security incident response must be integrated within the broader requirements for business continuity and disaster recovery. Integration will simplify processes, maintain consistency and eliminate duplication. Continuous improvement of security incident management processes includes:

  • Monitoring incidents using statistical analysis of frequency, types and locations of security incidents;
  • Analysis of incidents, responses and successful containment;
  • Determining requirements for user awareness and training;
  • Improving the security of information systems through monitoring and reporting; and,
  • Integrating automated alarms and other security incident detection technology with user reporting, checking logs and auditing systems.

A.16.1.7 – Collection of evidence

The purpose is to ensure investigation processes preserve the integrity of evidence that may be required for legal or disciplinary action.All applicable laws and regulations have been identified by, XXX. wherever applicable, the records and documents that may be accepted as evidence shall be collected and maintained.  Shall ensure that all evidence collected in the process is:

  • Admissible as evidence – Acceptable to court and legal authorities
  • Complete – Present a complete trail of the incident
  • Meet quality requirements – Are readable, legible etc.

Investigations into information security incidents must ensure evidence is identified, collected, preserved, retained and presented in conformance with the rules for collection of evidence.
a) Information security incident investigation
b) Collection of evidence

a) Information security incident investigation
Information security incident investigation must be formalized and practiced in accordance with standard investigation techniques:

  • Information security incident investigation processes include:
    • identification of the incident cause,
    • planning of corrective action,
    • implementation of corrective action to prevent recurrence, and,
    • reporting action taken;
  • Employees with responsibilities for information security investigations (investigating officers) must be aware of processes for securing potential evidence such as technology assets, audit logs, audit trails, voice mail and e-mail accounts for analysis and as potential evidence in legal proceedings;
  • Inappropriate use of information and technology resources requires that within 48 hours the investigating officer contact:
    • in the case of an employee the individual’s excluded Supervisor  and,
    • in the case of a contractor or business partner the contract manager or relationship manager;
  • When criminal activity is suspected, the investigating officer must ensure that the appropriate law enforcement authorities are contacted. Before contacting law enforcement authorities, the Risk Management Branch and Security Office and Chief Information Officer must be consulted;
  • On resolution of an information security incident or weakness, the investigating officer must prepare a report that includes a detailed problem analysis, actions taken, and recommendations for corrective action or improvements; and,
  • Information security incident reports must be submitted to Information Owners, Information Custodians, Chief Information Officer  as part of security program management.

In order to enable quick, effective and immediate response to information security incidents and breaches, employees with responsibilities for security investigations (investigating officers) must be able to access security log data and security log data processing and reporting facilities immediately. This access will be for the purposes of evidence collection as well as security log parsing, searching, and reporting to enable identification, root cause analysis, and resolution of breaches and incidents. Access will be configured and enabled for on-line, real-time access to the GUI (Graphical User Interfaces)/Consoles/Interfaces of:

  • The systems that generate and produce security log data and feature an interface that has reporting, parsing or searching functions with relation to the security log data it generates;
  • The centralized log management system, service or facilities; and,
  • The centralized monitoring system, service or facilities.

If the specific technology does not have a GUI/Console/Interface available, and instead relies on raw log data generation, equivalent functionality that permits the timely and effective searching of the security logs produced must be implemented.

b) Collection of evidence
At the outset of an information security investigation it may not be known if legal or disciplinary actions will result and what evidence will be required. To ensure proper procedures, confidentiality and information privacy, evidence must only be collected by individuals authorized by the Chief Information Security Officer.

  • Evidence collection procedures must be documented by the Chief Information Security Officer;
  • Investigative processes must follow the rules of evidence to ensure relevance, admissibility and materiality; and,
  • Information Owners and Information Custodians in receipt of a legal order to produce electronic evidence must immediately contact the Chief Information Security Officer.

Guidelines:
In general, procedures for evidence collection should include identification, collection, acquisition and preservation of evidence in accordance with different types of media, devices and the status of devices (e.g., powered on or off). The procedures should take account of:

  • Chain of custody;
  • Safety of evidence;
  • Safety of employees;
  • Roles and responsibilities of employees involved;
  • Competency of employees;
  • Documentation; and,
  • Briefing.

A.17 Business continuity management

This provides direction from a security focus for planning the resumption of business or services where a man-made or natural disaster has occurred. The organizations are required to be prepared and to re-establish business or services as swiftly and smoothly as possible. Business continuity plans include the evaluation of security risks in line with the directions set by Emergency Management

A.17.1 Information security aspects of business continuity management

Control objective: To counteract interruptions to business activities and to protect critical business processes from the effects of major failures of information systems or disasters and to ensure timely resumption.

A.17.1.1 – Planning information security continuity

The purpose is to ensure XXX can continue to deliver essential services despite damage, loss, or disruption of business processes.Business continuity begins by identifying events that can cause interruptions to business processes, e.g. equipment failure, flood and fire. This is followed by a risk assessment to determine the impact of those interruptions (both in terms of damage scale and recovery period). This assessment considers all business processes and is not limited to the information processing facilities. Depending on the results of the risk assessment, a strategy plan is developed to determine the overall approach to business continuity. The organization must determine its requirements for information security and the continuity of information security management in adverse situations.
a) Business continuity planning
b) Business continuity risk assessment
c) Business continuity strategy
d) Business continuity plans
e) Coordination of business continuity plans

a) Business continuity planning
Information Owners must ensure business continuity and recovery plans address information security requirements consistent with the classification of the information. Processes for establishing business continuity and recovery plans are detailed in the Business Continuity Management Program Guidelines.

  • Information Owners must perform a business impact analysis for information security aspects to determine the information security requirements applicable to adverse situations; and,
  • Information security requirements remain the same in adverse situations, compared to normal operational conditions.

The Information Custodian must maintain the business continuity and recovery plans for information systems as part of the System Security Plan. The Organization policy on business continuity programs is defined in Core Policy and Procedures Manual – Business Continuity Management.

b) Business continuity risk assessment
The process for identifying, analyzing and evaluating risks, including information security risks, is detailed in the Business Continuity Management Program Guidelines – Identify, Analyze and Evaluate Risks. The process for analyzing and assessing business impacts, including those for information security risks, is detailed in the Business Continuity Management Program Guidelines – Review Business Functions and Analyze Business Impacts.

c) Business continuity strategy
The process for developing a business continuity strategy is detailed in the Business Continuity Management Program Guidelines, – Plan Mitigation Strategies and,  Plan Business Continuity Strategies.

d) Business continuity plans
Requirements for business continuity plans are defined in Core Policy and Procedures Manual 16 – Business Continuity Management. The process for developing and maintaining business continuity plans is detailed in the Business Continuity Management Program Guidelines.

e) Co-ordination of business continuity plans
Information Owners must ensure business continuity plans:

  • Include the classification of information assets to identify critical business operations;
  • Use organization-wide frameworks and processes; and,
  • Use information security processes which maintain approved security levels.

The Emergency Management BC must coordinate government-wide business continuity plans to reconcile recovery priorities, business impacts, security impacts and business resumption processes. The Chief Information Officer is responsible for protecting the privacy, confidentiality, integrity and availability of electronic information. This responsibility includes providing expert advice to Emergency Management BC on information security aspects of business continuity plans.

A.17.1.2 – Implementing information security continuity

The purpose is to ensure the required level of continuity for information security is maintained during an adverse situation.The organization must establish, document, implement and maintain processes, procedures and controls to ensure the required level of information security for business continuity during an adverse situation.
a) Implement required level of continuity
b) Information security continuity requirements
c) Processes and procedures
d) System redundancy

a) Implement required level of continuity
Information Owners must ensure that:

  • An adequate management structure is in place to prepare for, mitigate and respond to a disruptive event using employees with the necessary authority, experience and competence;
  • Incident response employees with the necessary responsibility, authority and competence to manage an incident and maintain information security are nominated; and,
  • Documented plans, response and recovery procedures are developed and approved, detailing how the organization will manage a disruptive event and will maintain its information security to a predetermined level, based on approved information security continuity objectives.

b) Information security continuity requirements
According to the information security continuity requirements, Information Owners must establish, document, implement and maintain:

  • Information security controls within business continuity or disaster recovery processes, procedures and supporting systems and tools;
  • Processes, procedures and implementation changes to maintain existing information security controls during an adverse situation; and,
  • Compensating controls for information security controls that cannot be maintained during an adverse situation.

c) Processes and procedures
Within the context of business continuity or disaster recovery, specific processes and procedures have been defined. Information that is handled within these processes and procedures or within dedicated information systems to support them must be protected. Information Owners must involve information security specialists when establishing, implementing and maintaining business continuity or disaster recovery processes and procedures.

d) System redundancy
Information security controls that have been implemented must continue to operate during an adverse situation. If security controls are not able to continue to secure information, other controls must be established, implemented and maintained to achieve an acceptable level of information security

A.17.1.3 – Verify, review and evaluate information security continuity

The purpose is to o ensure business continuity plans are current, functional and address information security requirements. Business continuity plans shall be tested regularly to ensure that they are up to date and effective. Such tests should also ensure that all members of the recovery team and other relevant staff are aware of the plans. Business continuity plans must be regularly exercised and updated. Information Owners  must review business continuity plans annually to ensure they are current, valid and readily accessible during a business interruption. Business Continuity Plans must be coordinated with security management and emergency preparedness and response plans. Business Continuity Plans must be exercised at least annually to the extent necessary to confirm plan effectiveness and to ensure employees are prepared and trained. All employees and key stakeholders must be aware of the  Business Continuity Management Program and understand its contents and their role. Information Owners must report the number and type of exercises completed, the training conducted and the status of the business continuity plans to Emergency Management BC semi-annually. Requirements for exercising business continuity plans are defined in Core Policy and Procedures – Business Continuity Management. The processes for exercising business continuity plans are detailed in the Business Continuity Management Program Guidelines – Train and Exercise. Requirements for the maintenance of the business continuity plan are detailed in Business Continuity Management Program Guidelines – Monitor and Review.

A.17.2 Redundancies

Control objective: To ensure availability of information processing facilities.

A.17.2.1 – Availability of information processing facilities

The purpose is to ensure the availability of information systems without interruption.Information processing facilities shall be monitored and sufficient redundancy shall be ensured by fixing the appropriate threshold level while maintain Control Effectiveness Measurement as defined. Information processing facilities must be implemented with redundancy sufficient to meet availability requirements.The implementation of redundancies can introduce risks to the integrity or confidentiality of information and information systems, which need to be considered when designing information systems. Information Owners  must identify business requirements for the availability of information systems. Where the availability cannot be guaranteed using the existing systems architecture, redundant components or architectures must be considered. Where applicable, redundant information systems must be tested to ensure the failover from one component to another component works as intended.

 A.18 Compliance

This describes requirements for verifying that information systems comply with relevant statutory, regulatory, and information security contractual clauses. Compliance policies identify what to do to ensure that the Province is in compliance with applicable laws and policies. Processes to monitor the extent to which information systems follow policies include conducting security reviews, assessments and the systematic analysis of logged information.

A.18.1 Information security reviews

Control Objective: To ensure that information security is implemented and operated in accordance with the organizational policies and procedures. 

A.18.1.1 – Independent review of information security

The purpose is to provide an assessment of the Information Security Program.Information System Security Committee is responsible for reviewing and auditing the ISMS for its compliance. All areas covered in the ISMS policy are considered for regular reviews and audits. MR prepares and publishes the annual audit/ review plan. Independent reviews of information security must be regularly conducted.
a) Independent review of information security
b) Remediation

a) Independent review of information security
Independent reviews are necessary to ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security. The review must include assessing opportunities for improvement and the need for changes to the approach to security, including the policy and control objectives. The Chief Information Security Officer must initiate an independent third party review of the Information Security Program every two years including:

  • Assessing the operational effectiveness of the Information Security Program;
  • Documenting the results; and,
  • Reporting the results of the review to senior management.

b) Remediation
Information Owners must address the identified weaknesses and non-compliant controls prior to the next review.

A.18.1.2 – Compliance with security policies and standards

The purpose is to ensure compliance of information systems with information security policy, requirements and standards. The XXX. with the help of the Security Committee and other Core Group members conducts periodic/event-driven review to ensure compliance with security policy & standards. Information Owners must ensure security procedures are followed in their areas of responsibility and facilitate regular reviews to ensure compliance with security policies and standards.
a) Compliance with security policies and standards
b) Review of controls
c) Review of implementation of information incident report recommendations

a) Compliance with security policies and standards
Information Owners must ensure security policies and processes are implemented and adhered to by:

  • Conducting periodic self-assessments;
  • Ensuring employees receive regular information security awareness updates; and,
  • Initiating independent assessments, reviews or audits to assess compliance with policy.

When review processes indicate non-compliance with policies, Information Owners must:

  • Determine cause(s);
  • Assess the threats and risks of non-compliant processes;
  • Document the marginal risks where required; and,
  • Develop plans to implement corrective action.

b) Review of controls
Information Owners must develop an annual plan which identifies information systems scheduled for a security review in each fiscal year. The information systems to be reviewed in each year should be:

  • Determined in conjunction with the Enterprise-wide Risk Management Plan;
  • Endorsed by the Audit Committee, or equivalent; and,
  • Reported as part of the annual information resource management plan.

Information Owners must ensure that critical information systems are reviewed at least every three years.

c) Review of implementation of information incident report recommendations
Information Owners and Information must ensure that recommendations from information incident reports are addressed. The Chief Information Security Officer may perform compliance reviews or audits of the implementation of recommendations from information incident reports, when necessary. The Chief Information Officer must ensure that Information Owners support the audit activities.

Guidelines:
When determining the review frequency for information systems consider:

  • The value of the information system as determined by a Security Threat and Risk Assessment or a Risk and Controls Review;
  • Frequency of changes or updates (as changes may introduce new risks, a system which has undergone frequent changes may have higher risks); and,
  • Results of previous reviews.

A.18.1.3 – Technical compliance checking

The purpose is to determine if technical controls meet established government standards. Periodic internal audits, third party audits and independent VA/PT shall be planned for and conducted according to Security Committee Review Procedure.Information systems must be regularly reviewed for compliance with security policies and standards.
a) Technical compliance checking
b) Authorization to conduct technical compliance checking
c) Reporting results

a) Technical compliance checking
Information Owners must regularly test information system technical control compliance by using automated tools to:

  • Detect network intrusion;
  • Conduct penetration testing;
  • Determine if information system patches have been applied;
  • Confirm that system technical controls have been implemented and are functioning as designed; and,
  • Perform technical compliance checking as part of the system change management process to verify that unauthorized connections and/or systems changes have not been made.

b) Authorization to conduct technical compliance checking
Supervisors responsible for technical compliance checking must ensure that:

  • Information Owners and operations employees are consulted prior to initiating tests;
  • The Chief Information Security Officer is notified prior to testing to prevent triggering false security alarms from the infrastructure; and,
  • Automated testing of operational systems is conducted by employees authorized by the Chief Information Security Officer.

Department HOD must consult with the Chief Information Security Officer prior to issuing Requests for Proposal or contracts for technical compliance checking.

c) Reporting results
Supervisors responsible for technical compliance checking and Information Custodians must:

  • Assess results of testing and promptly develop action plans to investigate and mitigate identified exposures in consultation with the Ministry Information Security Officer;
  • Provide Information Owners and the Chief Information Security Officer with copies of test results and action plans;
  • Provide the Chief Information Security Officer with the internal or external audit reports immediately upon receipt; and,
  • Maintain records, in accordance with established records schedules, of tests for subsequent review by internal and external auditors.

Guidelines:
The Chief Information Security Officer should:

  • Develop and maintain testing processes for authorizing/conducting tests, storing results and building on previous testing experience; and,
  • Provide summarized quarterly reports to the Chief Information Officer on the status and results of testing.

 A.18.2 Compliance with legal and contractual requirement

Control Objective: To avoid breaches of any law, statutory, regulatory or contractual obligations and of any security requirements.

A.18.2.1 – Identification of applicable legislation

The purpose is to ensure that the legal requirements of information systems are documented. All relevant statutory, regulatory, and contractual obligations pertaining to information systems are explicitly defined and documented. XXX. adheres to all the applicable laws and acts. It is the responsibility of the HR department to review compliance and identify new or unidentified legal obligations. All agreements entered by the company are duly vetted and approved by the HR department for this purpose. The legislative, statutory, regulatory and contractual requirements for each information system must be explicitly defined, documented and maintained. Information Owners are responsible for ensuring that legislative statutory, regulatory, policy and contractual requirements of each information system are:

  • Identified and documented when commencing a system development or enhancement initiative;
  • Reviewed prior to, or concurrent with, changes to legislation, regulation or policy; and,
  • Explicitly identified in contracts and service agreements, and included in:
    • Privacy Impact Assessments,
    • Security Threat and Risk Assessments,
    • System Security Plans,
    • Risk Management Plans, and,
    • Business Continuity Plans.

Privacy requirements for information systems containing or handling personal information are defined in the Freedom of Information and Protection of Privacy Act – Policy and Procedures Manual

A.18.2.2 – Intellectual property rights (IPR)

The purpose is to protect the intellectual property rights of information and software creators and owners.  XXX. ensures that all license agreements are respected and limits the use of the products to specified machines, and for specific purposes.

  1. The IPR of hardware, software and documentation belonging to , XXX  will not be disclosed to any outside party unless and otherwise cleared by XXX
  2. The IPR of programs and associated material supplied by outside organizations / collaborators will be used by, XXX. for only those purposes for which they are licensed.
  3. No unauthorized copies will be made for use within or outside, XXX 

Controls must be implemented to ensure compliance with legal, regulatory and contractual restrictions on the use of material with respect to intellectual property rights and proprietary software licensing.
a) Intellectual property rights of external creators and owners
b) Intellectual property rights for the organizational assets

a) Intellectual property rights of external creators and owners
Information Owners and Information Custodians must protect intellectual property by:

  • Ensuring that information and software is only acquired from reputable vendors;
  • Maintaining proof or evidence of ownership or right to use;
  • Adhering to the terms and conditions of use associated with intellectual property;
  • Ensuring the maximum number of users permitted is not exceeded;
  • Implementing processes to detect unlicensed information (e.g., ISO standards documents) and software or expired licenses;
  • Requiring the removal of unlicensed information and software from government information systems;
  • Informing employees of the policies, including the Appropriate Use Policy;
  • Ensuring licensed intellectual property is securely removed from electronic media prior to media disposition; and,
  • Complying with terms and conditions for information and software obtained from public networks (e.g., “free for personal use only”, open source).

b) Intellectual property rights for the assets
Policy for the intellectual property of information assets is in the Core Policy and Procedures Manual  – Corporate Supply and Disposal Arrangements which is managed by the Chief Information Officer

A.18.2.3 – Protection of documented information

The purpose is to ensure compliance with legislative and policy requirements for documented information.The important records are protected from loss, destruction and falsification. The following records of, XXX are safeguarded:

  • Master List of Documents
  • Master List of Records
  • Database records
  • Transaction logs
  • All contracts and agreements

All records are retained for a defined period as specified by the owner of the information. Storage and handling of all these records is in accordance with a defined procedure. The documented information  must be protected from loss, destruction and falsification, unauthorized access, release, and disposal in accordance with legislative, regulatory, contractual and business requirements. When deciding upon protection of specific organizational records, Information Owners must consider the information security classification. Information Owners must ensure the protection of records by:

  • Using organization guidelines on the retention, storage, handling and disposal of records and information;
  • Following a retention schedule identifying records and the period of time for which they should be retained; and,
  • Maintaining an inventory of sources of key information.

A.18.2.4 – Privacy and protection of personal information

The purpose is to To ensure the privacy and protection of personal information in compliance with legislation.. However, all personal records are maintained as hard copies and classified as ‘Confidential’. Only HR department has access to those files. Online personal information is maintained which is password protected, and the access is limited to the HR.Privacy and protection of personal information must be ensured as required in legislation and regulation.Information Owners must document and implement policies for privacy and the protection of personal information. The policy must be communicated to all employees involved in the processing of personal information. There must be Privacy Impact Assessment and Security Threat and Risk Assessment documents for all operations areas that are collecting, processing and storing personal information. The Freedom of Information and Protection of Privacy Act requires personal information to be protected using ‘reasonable security measures’. The Information Security Policy includes detailed controls which enable and support the protection of information and information systems.

A.18.2.5 – Regulation of cryptographic controls

The purpose is to prevent inappropriate use and unregulated importing or exporting of cryptographic controls.The cryptographic regulations as per IT Act of Government of (P) shall be followed for XXX operations. In case of usage of third party cryptographic devices compliance letter from the third party shall be secured.Cryptographic controls must be used in compliance with relevant agreements, legislation and regulations. When cryptographic controls are used, Information Owners  must:

  • Ensure that the use of cryptographic control(s) is supported by an Information Security Threat and Risk Assessment;
  • Consult with the Chief Information Officer regarding the records management, electronic commerce, information access, privacy and security issues prior to acquiring cryptographic controls;
  • Ensure encrypted information assets do not become unavailable due to unavailability or loss of cryptographic keys by implementing a process to manage cryptographic keys as defined by the Chief Information Officer; and,
  • When acquiring cryptographic controls from outside the country, the procurement must be from a reputable vendor who can provide reasonable assurance on the legality of import into country.

The Chief Information Officer will:

  • Develop and document cryptographic key management processes;
  • Provide guidance and assistance to the departments and agencies in the selection and use of cryptographic controls; and,
  • Establish and publish cryptographic standards

12.  ISMS Master list of Records and its Retention Period

Sl. No Record Name Responsibility Classification of Information Retention Period
          1. Security Council Meeting Minutes MR Restricted 1 Year
          2. Corrective Action Record MR Restricted 1Year
          3. Preventive Action Record MR Restricted 1 Year
          4. User Registration & Deregistration Record Restricted 1 Year
          5. Incident Log MR Restricted 3 Years
  6. Asset Record MR Restricted 3 Years
          7. Risk Assessment Record MR Restricted 3 Years
          8. List of Applicable Legislations MR Restricted 3 Years
          9. Server Logs System Administrator Internal 1 Year
       10. NC Reports MR Restricted 3 Years
       11. BCP Record IT Manager Restricted 3 Years
       12. Change Request Record System Admin Internal 3 Years
       13. Change Request Impact Analysis Record System Admin Internal 3 Years
       14. Software License Usage Monitoring Report System Admin Internal 1 Year
       15. Bandwidth Monitoring Report System Admin Internal 6 Months
       16. H/W and S/W Verification Records System Admin Internal 1 Year
 17. List of authorized persons for sensitive data MR/CISO Restricted 1 Year
 18. Antivirus record of user machines System Admin Internal 1 Year
 19. Backup logs System Admin Internal 1 Year
 20. Backup restoration logs System Admin Internal 1 Year
 21. Network Access Authorization Records System Admin Restricted 1 Year
 22. Media Disposal Records MR Internal 3 years
 23. Visitor Log Book System Admin Internal
 24. Management Authorization Approval sheet MR Confidential 3 years
 25. Contract for Power Supply MR Internal
 26. Contract for DG Set MR Internal
 27. Contract for Air Conditioner MR Internal
 28. Contract for Security Agency Admin Internal
 29. Contract for Fire prevention Admin Internal
 30. Contract for Leased Line MR Internal 3 years
 31. Contract for FM MR Internal
 32. Contract for Antivirus Protection MR Internal 1 year
 33. Third Party Contract & NDA documents MR Restricted 3 years
 34. IBM/MacAfee Service Level Agreement MR Restricted 3 years
 35. Background Verification Record HR Confidential
 36. KPI related records MR Internal
 37. ISMS Plan MR Internal

 

ISO 27001:2013 A.6 Organization of information security

by Pretesh Biswas

Security Program Development can be thought of as having an emphasis on establishing information security related roles and responsibilities throughout the organization. Two major areas are addressed in this section:

  1. Developing an effective Information Security Organization
  2. Mobile Computing and Teleworking standards (and the “BYOD challenge”)

Establishing an effective internal Information Security Organization can be further sub-divided into multiple topics of interest:

  • One of the key sub-topics is information security roles and responsibilities, which addresses the need to designate and assign accountability for information security across the organization to ensure that employee apply appropriate protection to assets and information under their direct control. Additionally, this topic addresses the need to establish an information security governance framework and designate a leader who will manage the information security program and develop program initiatives. This designation should be documented in a formal job description for the individual with the designated responsibility and such designation should be utilized in properly demonstrating compliance with applicable regulatory and compliance requirements such as HIPAA, GLBA, and PCI DSS.  Note that there are a variety of roles and responsibilities for information security leaders Avoiding conflicts of interest that can arise when segregation of duties is not considered. This is another area to be addressed to ensure that no single individual at an organization can escape detection if engaging in unauthorized activities or abusing access to information and technology systems.
  • The information security organization is also responsible for appropriate contact with authorities and contact with special interest groups.
  • Addressing information security in project management activities is important to ensure that risks are identified and addressed throughout the project management lifecycle.
  • The information security organization is typically also responsible for developing information security policies and creating a comprehensive risk-based information security program.
  • Mobile Computing and Teleworking relates to the risks of working with mobile devices in unprotected environments.

A. 6.1 Internal organization

Objective:

To establish a management framework to initiate and control the implementation and operation of information security within the organization.

A.6.1.1 Information security roles and responsibilities

Control
All information security responsibilities should be defined and allocated.

Implementation guidance
Allocation of information security responsibilities should be done in accordance with the information security policies. Responsibilities for the protection of individual assets and for carrying out specific information security processes should be identified. Responsibilities for information security risk management activities and in particular for acceptance of residual risks should be defined. These responsibilities should be supplemented, where necessary, with more detailed guidance for specific sites and information processing facilities. Local responsibilities for the protection of assets and for carrying out specific security processes should be defined. Individuals with allocated information security responsibilities may delegate security tasks to others. Nevertheless they remain accountable and should determine that any delegated tasks have been correctly performed. Areas for which individuals are responsible should be stated. In particular the following should take place:
a) the assets and information security processes should be identified and defined;
b) the entity responsible for each asset or information security process should be assigned and the details of this responsibility should be documented;
c) authorization levels should be defined and documented;
d) to be able to fulfil responsibilities in the information security area the appointed individuals should be competent in the area and be given opportunities to keep up to date with developments;
e) coordination and oversight of information security aspects of supplier relationships should be identified and documented.

Other information
Many organizations appoint an information security manager to take overall responsibility for the development and implementation of information security and to support the identification of controls. However, responsibility for resourcing and implementing the controls will often remain with individual managers. One common practice is to appoint an owner for each asset who then becomes responsible for its day-to-day protection.

A.6.1.2 Segregation of duties
Control

Conflicting duties and areas of responsibility should be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of the organization’s assets.

Implementation guidance
Care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization. The possibility of collusion should be considered in designing the controls. Small organizations may find segregation of duties difficult to achieve, but the principle should be applied as far as is possible and practicable. Whenever it is difficult to segregate, other controls such as monitoring of activities, audit trails and management supervision should be considered.

Other information
Segregation of duties is a method for reducing the risk of accidental or deliberate misuse of an organization’s assets.

A.6.1.3 Contact with authorities

Control

Appropriate contacts with relevant authorities should be maintained.

Implementation guidance
Organizations should have procedures in place that specify when and by whom authorities (e.g. law enforcement, regulatory bodies, supervisory authorities) should be contacted and how identified information security incidents should be reported in a timely manner (e.g. if it is suspected that laws may have been broken).

Other information

A. 6.1.4 Contact with special interest groups

Control
Appropriate contacts with special interest groups or other specialist security forums and professional associations should be maintained.

Implementation guidance
Membership in special interest groups or forums should be considered as a means to:

  1. improve knowledge about best practices and stay up to date with relevant security information;
  2. ensure the understanding of the information security environment is current and complete;
  3. receive early warnings of alerts, advisories and patches pertaining to attacks and vulnerabilities;
  4. gain access to specialist information security advice;
  5. share and exchange information about new technologies, products, threats or vulnerabilities;
  6. provide suitable liaison points when dealing with information security incidents.

Other information
Information sharing agreements can be established to improve cooperation and coordination of security issues. Such agreements should identify requirements for the protection of confidential information.

A.6.1.5 Information security in project management

Control
Information security should be addressed in project management, regardless of the type of the project.
Implementation guidance
Information security should be integrated into the organization’s project management method to ensure that information security risks are identified and addressed as part of a project. This applies generally to any project regardless of its character, e.g. a project for a core business process, IT, facility management and other supporting processes. The project management methods in use should require that:

  1. information security objectives are included in project objectives;
  2. an information security risk assessment is conducted at an early stage of the project to identify necessary controls;
  3. information security is part of all phases of the applied project methodology.

Information security implications should be addressed and reviewed regularly in all projects. Responsibilities for information security should be defined and allocated to specified roles defined in the project management methods.

Annex A.6.1 is about internal organization. The objective in this Annex A area is to establish a management framework to initiate and control the implementation and operation of information security within the organization. Organization need to establish a mechanism to manage information security across the entire enterprise and gain the support of  leadership to assist in providing overall direction.

Implementing a Security Strategy

An effective information security strategy for a organization must take into account the overall strategic objectives of the organizations and varied departments. Even when focusing on critical processes and legal mandates, it is necessary to extend protective measures beyond the underlying IT systems and associated staff. For example, many employees have access to critical customer records, and this access must be considered when assessing the security risks associated with these data. A failure to provide employees with securely configured workstations increases the risk of sensitive data being exposed via their computers. This risk can also be reduced by implementing a middleware solution to properly control which records each faculty member can access and to minimize the amount of sensitive data stored on their computers. Also, to be effective, security practices cannot rely completely on technological solutions. Continuing the example, policies are required to clearly define staff’ responsibilities relating to the data and the security of their workstations. Also, awareness programs aimed specifically at staff and their responsibilities to safeguard  information might be developed, possibly in conjunction with the organization’s s information officer.
To complicate matters, the operational needs of organization networks often directly conflict with security practices such as perimeter firewalls, port authentication, centralized configuration management, and strong authentication. The networks must therefore be designed to balance security and privacy requirements while accommodating a wide variety of end users and their needs – e.g., visitors, new employees arriving with computers, managers sharing large quantities of data with  other managers, remote access to a variety of network services for individuals who are traveling or telecommuting, and mobile users moving between different locations. Although firewalls are becoming widely used to protect critical systems on organizations networks, their use at the perimeter is less common because it is difficult to reconcile their restrictiveness with the need for an open networking environment that supports  high-speed networking. Although centralized management is feasible for certain hosts on a network, this approach is not suitable for most computers and many systems. In the end, security and privacy practices need to be integrated into operational practices in a way that makes the most sense for each locations. This is not to say that organization cannot be secured; many organization are successfully balancing the need for security and an open, collaborative networking environment.

Information Security Governance

Effective  governance of the information security function is critical to a successful program. It can be both the “proof of the pudding…” with regard to management commitment and provide necessary guidance when deciding where to allocate scarce resources.

  • What is Information Security Governance and What it is Not
  • Why Information Security Governance is Needed
  • How to Govern Information Security
  • Organizational Structure
  • Roles and Responsibilities
  • Strategic Planning
  • Policy
  • Compliance
  • Risk Management
  • Measuring and Reporting Performance
  • Governance Models and Success Stories

Information Security Roles & Responsibilities 

All information security responsibilities need to be defined and allocated. Information security is the responsibility of everyone at the institution. It is important to establish roles and responsibilities  so that everyone knows what is expected of them when handling information. Leadership is also very important, and many organizations have at least one person who is primarily responsible for organizing the information security program. Typically this is a Chief Information Security Officer (CISO), Information Security Officer (ISO), Director of Information Security, although the title may vary depending on the organizations. No matter what title is selected, there should be someone at the organizations who can provide a high level of decision-making support to organizations leadership when considering information security issues and solutions. Information security responsibilities can be general (e.g. protecting information) and/or specific (e.g. the responsibility for granting a particular permission). Consideration should be given to the ownership of information assets or groups of assets when identifying responsibilities. Some examples of the business roles which are likely to have some information security relevance include; Departmental heads; Business process owners; Facilities manager; HR manager; and Internal Auditor. The auditor will be looking to gain assurance that the organization has made clear who is responsible for what in an adequate and proportionate manner according to the size and nature of the organization.  For smaller organizations, it is generally unrealistic to have full-time roles associated with these roles and responsibilities. As such, clarifying specific information security responsibilities within existing job roles is important e.g. the Operations Director or CEO might also be the equivalent of the CISO, the Chief Information Security Officer, with overarching responsibility for all of the ISMS. The CTO might own all the technology related information assets etc.

Segregation of Duties

Segregation of duties is the concept of having more than one person required to complete a task. This is a best practice, especially in cases where sensitive data is being handled. Segregation of duties is a control put in place by many organizations to mitigate the risk of an insider threat or accidental employee mistakes. Sometimes this isn’t practical or possible, but the organizations should be aware of the risks of a single person having too much access. Ideally, critical processes or activities should be split up between multiple people. For example the initiation of a process, its execution, and authorization should be separated when possible. When this is not possible, monitoring and auditing critical processes is very important. Conflicting duties and areas of responsibility must be segregated in order to reduce the opportunities for unauthorized or unintentional modification or misuse of any of the organization’s assets. The organization needs to ask itself whether or not the segregation of duties been considered and implemented where appropriate. Smaller organizations may struggle with this, but the principle should be applied as far as possible and good governance & controls put in place for the higher risk/higher value information assets, captured as part of the risk evaluation and treatment.

Contact with Authorities

Relationships with law enforcement are important to an organization, and should be established prior to an emergency. Having a protocol for engagement established before there is an emergency will help in handling an incident appropriately. A protocol for engagement with law enforcement can be a part of the security incident response plan or a broader crisis management procedure. The plan should be clear about which situations require working with law enforcement, such as when laws are broken. The plan should also clearly state who contacts authorities and under what circumstances (e.g., when law enforcement should be contacted by the information security office or campus safety). Appropriate contacts with relevant authorities must be maintained. Remember when adapting this control to think about the legal responsibilities for contacting authorities such as the Police, the Information Commissioner’s Office or other regulatory bodies. Consider how that contact is to be made, by whom, under what circumstances, and the nature of the information to be provided.

Contact with Special Interest Groups

There are many groups that support Information Security that an organizations can collaborate and participate in. The information security threat landscape is ever changing and security professionals can benefit from collaborating together. Being connected to special interest groups allows for knowledge transfer and best practice development. Warnings about potential threats can also help security operations prepare and respond appropriately. Appropriate contacts with special interest groups or other specialist security forums and professional associations must also be maintained. When adapting this control to your specific needs remember that memberships of professional bodies, industry organizations, forums and discussion groups all count towards this control. It is important to understand the nature of each of these groups and for what purpose they have been set up (e.g. is there a commercial purpose behind it).

A.6.1.5 Information security in project management-For  more  on  project  management  click here

6.2 Mobile devices and teleworking

Objective:

To ensure the security of teleworking and use of mobile devices.

6.2.1 Mobile device policy- For more on mobile device click here

6.2.2 Teleworking-For more on Teleworking click here

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

ISO 27001:2013 A.6.1.5 Information security in project management

by Pretesh Biswas

For a project manager, a bad week might go something like this:

  • You open your email and see that one of your technical resources has inadvertently forwarded a network diagram to a competitor of your client.
  • You’re rolling out server builds during a weekend Go-Live and you realize your inventory spreadsheet is corrupted.
  • You’re about to walk into a meeting with your project sponsor and discover the laptop where you’ve stored the presentation you’ve been working on for three days has bluescreened.

Each scenario represents a security failure, a failure to maintain the CIA triad of information security:

  • Confidentiality
  • Integrity
  • Availability

Project managers have special interests in all three components of the CIA triad. IT projects warrant special consideration for maintaining confidentiality. The business case for any IT project will include strategic business goals whether the project delivers an exciting new technology or a mundane but essential upgrade to maintain enterprise productivity. IT project documentation also frequently includes intimate details of network and systems architecture that presents an attractive target for industrial espionage and hackers. Failed changes to IT systems can also impact availability and integrity. Special attention to backups, back-out plans and security risks early in the project will pay big dividends when project rollout leaves little time to consider how to undo the changes made during a Go-Live or react to an unexpected risk occurrence that may cause systems to go down, or cause data loss, corruption or breach. Project managers should develop plans to mitigate risks to the project documentation and methodology itself. Do you really want to go into that big meeting with the project sponsor and not be able to access crucial files or find that the most recent version of the project issues log was overwritten with the previous week’s version?

 A good week for a project manager might look something like this:

  •  You open your email and see that one of your technical resources has flagged an email containing a network diagram as confidential, preventing it from being forwarded to a competitor of your client.
  • You’re rolling out server builds during a weekend Go-Live and you realize your inventory spreadsheet is corrupted. Your change window gives you time to retrieve a pristine copy of the inventory from backup, verified with your document versioning system, and your team completes the builds successfully.
  • You’re about to walk into a meeting with your project sponsor and discover the laptop where you’ve stored the presentation you’ve been working on for three days has bluescreened. An authorized member of Operations Staff you’ve been working with closely since requirements gathering pulls up the file in the encrypted cloud storage backup for you and the presentation continues as planned.

PMs are not expected to be security experts, but by including security considerations in every phase and process of a project, especially in initiating and planning, communications and deliverables, PMs have the opportunity to deliver more secure systems in a more secure manner.
Security in project management is a completely new thing in the 2013 revision of ISO 27001.  Information security is to be addressed in project management regardless of the type of the project.

  1.  Understand what is “PROJECT” for your organization. Simple examples could be:
    • Implementation of DLP, Anti-Virus, Firewall, BYOD or any technology solutions
    • Buying new office location
    • Develop or procure new business application
    • Adding a new client or new process (depend upon size and complexity)
  2. Understand the business & security purpose of the PROJECT: You cannot start the project unless you know the Value (Benefits) project is going to contribute to organization
  3. Understand end to end project flow from respective owner. This could be data flow diagram, application architecture, network diagram, input-process-output etc
  4. Define security baseline for a particular project; Complete the Project; verify security baseline (project risk management)
    • Define security baseline for a particular project→Complete the Project → verify security baseline (project risk management)

Let’s take an example of “Implementation of DLP”

Purpose: Prevent organization’s IPR and customer’s information from information leakage.

Project Understanding:

  • Organization has developed / customized an internal application for processing customer’s information. Protection of application source code and customer information is utmost important
  • Customer sends input file through FTP, project user downloads file from FTP and upload on application to process. There are 50 users working on this project and has access to FTP and application. Once processing is completed, project user sends and output file back to customer through FTP.

Security Baseline for DLP Project

  • Data stored on Code Repository shall not go out of the organization (through any medium E-mail, FTP, internet, file upload etc)
  • Data stored on “File Server”→ Folder Name “Prising” shall not go out of the organization
  • Any data stored on “DB and App Server” shall not go out the organization.
  • User shall be able to send data with file extension .xml only
  • Any attempt to information leakage shall be logged in DLP server
  • Any attempt to Source code leakage shall be alerted to management immediately through email or SMS

Verification of baseline

  • Security professional to verify the compliance of each and every security baseline, in case there is any non compliance; same shall be documented in risk management methodology.

For example in this example, customer data (input and output file) can be leaked through FTP as FTP is accessible from anywhere

Project Management

Project Management Body of Knowledge defines project management as Application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through use of processes such as: initiating, planning, executing, controlling, and closing. Project management involves temporary assemblage resources to complete a project. Some projects are iterative, and occur regularly.

  • Benefits for organizations that make project management skills a priority include:
    • Implementation of a methodology
    • Improved planning
    • Less ambiguity about roles
    • Simplify project monitoring
    • Early identification of deviations in quality, time, or budget
  • Generally, project is deemed a success when:
    • Completed on time or early as compared to the baseline project plan
    • Comes in at or below planned expenditures for baseline budget
    • Meets all specifications as outlined in approved project definition
    • Deliverables are accepted by end user and/or assigning entity
  • In order to apply project management to information security, you must first identify an established project management methodology

Project Management Knowledge areas

  1. Project Integration Management
    Project integration management includes the processes required to ensure that effective coordination occurs within and between project’s many components, including personnel. Major elements of project management effort that require integration includes following processes:

    • Development of initial project plan
    • Monitoring of progress as the project plan is executed
    • Control of revisions to project plan
    • Control of changes made to resource allocations as measured performance causes adjustments to project plan
  2. Project Scope Management
    Project scope management ensures that project plan includes only those activities necessary to complete it.Scope is the quantity or quality of project deliverables expanding from original plan and Includes following processes:

    • Initiation
    • Scope planning
    • Scope definition
    • Scope verification
    • Scope change control
  3. Project Time Management
    Project time management ensures that project is finished by identified completion date while meeting objectives.  Failure to meet project deadlines is among most frequently cited failures in project management. Many missed deadlines are rooted in poor planning. Project Time Management includes following processes:

    • Activity definition
    • Activity sequencing
    • Activity duration estimating
    • Schedule development
    • Schedule control
  4. Project Cost Management
    Project cost management ensures that a project is completed within resource constraints.Some projects are planned using only a financial budget from which all resources must be procured. Project Cost Management includes following processes:

    • Resource planning
    • Cost estimating
    • Cost budgeting
    • Cost control
  5. Project Quality Management
    Project quality management ensures that project adequately meets project specifications. If project deliverables meet requirements specified in project plan, project has met its quality objective. Good plan defines project deliverables in unambiguous terms against which actual results are easily compared. Project Quality Management includes the following processes:

    • Quality planning
    • Quality assurance
    • Quality control
  6. Project Human Resource Management
    Project human resource management ensures personnel assigned to project are effectively employed. Staffing project requires careful estimates of required effort. In information security projects, human resource management has unique complexities, such as Extended clearances and Deploying technology new to organization. Project  Human Resource Management includes following processes:

    • Organizational planning
    • Staff acquisition
    • Team development
  7. Project Communications Management
    Project communications conveys details of activities associated with project to all involved. It includes creation, distribution, classification, storage, and ultimately destruction of documents, messages, and other associated project information. Project Communications Management includes following processes:

    • Communications planning
    • Information distribution
    • Performance reporting
    • Administrative closure
  8. Project Risk Management
    Project risk management assesses, mitigates, manages, and reduces impact of adverse occurrences on the project.  Information security projects do face risks that may be different from other types of projects. Project Risk Management includes following processes:

    • Risk identification
    • Risk quantification
    • Risk response development
    • Risk response control
  9. Project Procurement Management
    Project procurement acquires needed resources to complete the project. Depending on common practices of organization, project managers may simply requisition resources from organization, or they may have to purchase. Project Procurement Management includes following processes:

    • Procurement planning
    • Solicitation planning
    • Solicitation
    • Source selection
    • Contract administration
    • Contract closeout

The need for project management skills within the practice of information security may not at first be self-evident. It is emphasized  that information security is a process, not a project. However, each element of an information security program must be managed as a project, even if the overall program is perpetually ongoing. This implies, among other things, that the security of the information is present in any establishment of the organization, being a pillar of the same, and serving as a cross support to the entire organization. Project management involves identifying and controlling the resources applied to the project  as well as measuring progress and adjusting the process as progress is made toward the goal.  It is, in fact, a continuous series or chain of projects, each link in this chain could be a specific project, and each of these projects would be guided by the security systems development life cycle (SecSDLC). Some aspects of information security are not project based; rather, they are managed processes. These managed processes include the monitoring of the external and internal environments during incident response, ongoing risk assessments of routine operations, and continuous vulnerability assessment and vulnerability repair. These activities are called operations, and are ongoing.

  • Clear definition of project constraints, including time frame, budget, and minimum quality requirements increases the likelihood that the project stays within them.
  • Establishing measures of performance and creation of project milestones simplifies project monitoring.
  • Early identification of deviations in quality, time, or budget enables early correction.

Successful project management relies on careful and realistic project planning coupled with aggressive, proactive control. The project success may be defined differently in each organization, but in general a project is deemed a success when:

  • It is completed on time or early.
  • It comes in at or below the expenditures planned for in the baseline budget.
  • It meets all specifications outlined in the approved project definition, and the deliverables are accepted by the end user and/or assigning entity.

To lead information security projects, some organizations assign technically skilled IT or information security experts; others assign experienced project and general managers. Some organizations use both approaches simultaneously. Regardless of the approach, the goal is the same: to have all elements of the information security program completed with quality deliverables, on a timely basis, and within budget.

it is not the same to say that we are going to establish a methodology to manage projects in the field of information security (for example, use a methodology such as PRINCE2 project management to implement a project of ISO 27001), as to say that we are going to establish a methodology to treat the security of information in project management (for example, to use a risk management methodology to analyze security risks of the information relating to a project).
The ISO 27001:2013 standard talks about the second issue, and this will be what we will focus on, but we should take into account the order of the words – as you have seen, it is not the same. The information security will always be a component of the management of any project in the organization, and the organization will also comply with the requirement established by ISO 27001. This control also helps to provide greater importance and presence to the information security in the organization, which is always positive for this sector, since it is not seen as a simple requirement of a standard, but as a critical parameter in addressing and implementing any project in the organization.

A. 6.1.5 Information security in project management

Control

information security should be addressed in project management, regardless of the type of the project.

Implementation guidance

Information security should be integrated into the organization’s project management methods to ensure that information security risks are identified and addressed as part of a project. This applies generally to any project regardless of its character. e.g. a project for a core business process, IT. facility management and other supporting processes. The project management methods in use should require that:

  • information security objectives are included in project objectives;
  • an information security risk assessment is conducted at an early stage of the project to identify necessary controls;
  • information security is part of all phases of the applied project methodology.

Information security implications should be addressed and reviewed regularly in all projects. Responsibilities for information security should be defined and allocated to specified roles defined in the project management methods.

The operation of each company is determined by the constant execution of projects in the short, medium, and long term (internal projects to maintain the structure of the organization, and external projects to provide services to customers). But security is something that is usually forgotten in projects; i.e., when a project is addressed in an organization, it does not usually take into account the information security. However, I’ve found some organizations, mainly large companies, that have included the information security in their projects as just one more activity (for example, running a risk assessment, focused on information security, at the beginning of any project to identify threats/vulnerabilities and risks). And this is basically what ISO 27001 requests in Annex A.6.1.5 Information security in project management: Information security shall be addressed in project management, regardless of the type of the project.
All projects basically need resources, activities to develop, and established time objectives. Information security can be integrated into project management activities in several ways:

  • Include information security objectives in project objectives.
  • Perform a risk assessment in an early stage of the project.
  • Carry out treatment of the identified risks and implement security measures
  • Make the information security policy an indispensable part of all stages of the project

It’s particularly important (independent of the size of the organization) to include information security in project activities for those projects, e.g., which deal with or target integrity, availability, and confidentiality of the information.

To make security a higher priority, project teams or managers need to implement or address the following:

  1.  Secure development Policy (SDP)
    Secure development is a requirement to build up a secure service, architecture, software and system. Within a secure development policy, the following aspects should be put under consideration:

    1. Security of the development environment;
    2. Guidance on the security in the Project life cycle(PCL);
    3. Secure coding guidelines for each programming language used;
    4. Security requirements in the design phase;
    5. Security checkpoints within the project milestones;
    6. secure repositories; version control, access control
    7. Developers’ capability of avoiding, finding and fixing vulnerabilities.

    An Organization Information Security Governance Team need to create or document Secure Development Policy (This may be a part of corporate Information Security Policy). If there were no formal documented Policy, then organization personnel at any level would have no guidance on how to make decisions during entire PLC. This helps employees to initiate actions and take responsibility without constant reference to management. Increase the accountability of business or organization’s and its staff. In reality, however, the existence of Policy provides many benefits provided they are written well and kept up to date. This Policy  need to be reviewed at least once in a Year or update in case of any changes in Policy. After review and changes (if any), this should be approved by Chief Information Officer (CIO), Chief Information Security Officer (CISO) or Department Heads only.

  2. Standard Operating Procedures (SOP)
    Operating procedures shall be documented and made available to all developers/ users who need them. SOP should be in place so that Project (development) team should know the security requirements on each and every phase during project phases of the life cycle. All step by step instructions should be incorporated into the document with individual’s roles & responsibilities.The approved procedure is documented in a format that is easy to follow and reduces the chance of errors being made. The idea behind it is to reduce the possibility of human error and to provide guidelines for employees to follow.
  3. Segregation of Development, testing and production environments:
    Development, testing and production environment shall be separated to reduce risks and threats of unauthorized access or changes to the operational environment. The intent of this requirement is to ensure that development/ test functions are separated from production functions. For example, a developer may use an administrator-level account with elevated privileges for use in the development environment, and have a separate account with user-level access to the production environment. In environments where one individual performs multiple roles (for example application development and implementing updates to production systems), duties should be assigned such that no one individual has end-to-end control of a process without an independent checkpoint. For example, assign responsibility for development, authorization and monitoring to
    separate individuals. Reducing the number of personnel with access to the production environment minimizes risk and helps ensure that access islimited to those individuals with a business need to know. Organization IT Services or Technology (Network & Server) team is responsible for segregation of all environments i.e. Development, Testing and Production and access control as per business needs. Network team recommends separate VLAN for the environments and Server team is responsible for Server deployment in Data Center or Server Room. Security processes such as Change Management, Secure guidelines as per standard operating environment to be followed as per Industry best practices.
  4. Protection from Malware
    Malware is “malicious software.” This is software that is specifically designed to gain access or damage a computer without the knowledge of the owner. There are various types of malware including spyware, key loggers, true viruses, worms, or any type of malicious code that infiltrates a computer. Generally, software is considered malware based on the intent of the creator rather than its actual features. Malware creation is on the rise due to the sheer volume of new types created daily and the lure of money that can be made through organized internet crime. Malware was originally created as experiments and pranks, but eventually led to vandalism and destruction of targeted machines. Today, much of malware is created for profit through forced advertising (adware), stealing sensitive or confidential information (spyware), and spreading email spam. Various factors can make computers more vulnerable to malware attacks, including defects in the operating system design, having all of the computers on a network run the same OS, giving users to much permissions or just using the Windows OS (due to its popularity, it gets the most malware written for it). During Project Life Cycle (PLC), we need to ensure that information and information processing facilities are protected against malware. Detection, prevention and recovery controls shall be implemented to protect against malware. The best protection from malware continues to be the usual advice: be careful about what email attachments you open, be cautious when surfing and stay away from suspicious websites, and install and maintain an updated, quality antivirus programs such as : Symantec endpoint protection, McAfee Computer security etc.
  5. Change Management
    A proper Change Management Process should be followed in case of any changes during development up to till production. Threats may occur sometime in case of false changes are made without any testing (or staging). The development environment requires a level of security commensurate with the planned security level of the software product being produced. Appropriate controls and configuration management of the development artifacts are essential. There may be specific tools required, such as for static code analysis, to aid the production or testing of secure software. Change is a necessary part overall PLC process. However, many leaders manage change poorly, causing distrust or confusion for their employees and clients. Organization responsible team should write a change management plan, leaders intentionally design a process that helps everyone know what needs to change, why it needs to change, and how to go about  making the change take place smoothly.
  6. Risk Assessment
    Security Risks, threats and vulnerabilities are the potential attackers and are described in terms of (employee, business partner, contractor or supplier) with an objective (financial gain, project code, company’s IPR or obtaining proprietary corporate information, disabling essential business systems), and with a set of resources (personnel, computing software, tools, hardware,skill, knowledge of internal systems). A risk assessment explores how a component could be exploited by the identified threats and vulnerabilities (i.e., what could go wrong) and analyzes the possible responses to such attacks. The response options for a risk are to (a) mitigate (reduce probability of event, reduce impact, improve recovery), (b) transfer (insurance, contracted agreements), (c) ignore (for low impact and highly unlikely threats), or (d) avoid, which may require changes in requirements. The factors involved with a risk assessment that is done early in the development process are predominantly business rather than technical. Project management needs to ensure stakeholder participation in such activities. The attack patterns would be rather abstract for a preliminary system risk assessment and would become more detailed as the software architecture and detailed design are created. Risk management process to be followed by organization where Information Security experts need to identify, assess, and prioritize the risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities.
  7. Activities required to complete deliverables:
    Regulatory or contractual compliance may require demonstration that the software provides the necessary controls for accessing the information (i.e., the production of an assurance case). Security governance typically increases the complexity for
    meeting security requirements. For example, business process compliance may require showing that the composition and interactions of multiple applications maintain the required controls and feedback. Regulatory compliance , Contractual compliance, requirements are set by Customers only and vendors or suppliers should adhere those guidelines. Delivering “Secure” software requires demonstrating that the desired level of assurance has been achieved. While demonstrating that a system provides the required functionality is an essential aspect of software assurance, software security assurance depends more on demonstrating what a system does not do. An improper input leads to a system failure or enable an attacker to bypass authentication. The production of such an assurance case must be planned and managed. An assurance case provides an argument for how the software meets an identified threat. That argument typically is based on assumptions about how the software behaves under certain operating conditions. Hence, an early step in building an assurance case is to provide evidence that software behavior satisfies the assumptions of the assurance argument. The production of an assurance case is an incremental activity. The assurance case should describe the architecture’s role for meeting security requirements, and the architectural risk assessment and analysis should provide evidence that the architecture satisfies those requirements. Syntactic analysis of the source code reduces the probability of coding errors that might lead to security vulnerability. Risk-based testing can target the components and interfaces that are most likely to lead to a system compromise.
  8. Restrictions on software/ tools installation
    Procedures shall be implemented to control the installation of tools/ software’s on development, testing and production systems. The organization should define and enforce strict policy on which types of software users may install. The principle of least privilege should be applied. If granted certain privileges, users may have the ability to install software. The organization should identify what types of software installations are permitted (e.g. updates and security patches to existing software) and what types of installations are prohibited (e.g. software that is only for personal use and software whose pedigree with regard to being potentially malicious is unknown or suspect). These privileges should be granted having regard to the roles of the users concerned. Uncontrolled installation of software on computing devices can lead to introducing vulnerabilities and then to information leakage, loss of integrity or other information security incidents, or to violation of intellectual property rights.
    Note: Software licensing agreements that are such that organizations may become liable for licensing for client software on workstations owned privately by employees or external party users;
  9. System and application (code level) access control
    Access to information and application system functions should be restricted in accordance with the access control policy. Restrictions to access should be based on individual business application requirements and in accordance with the defined access control policy.

    1. The following should be considered in order to support access restriction requirements
    2. Providing menus to control access to application system functions
    3. Controlling which data can be accessed by a particular user
    4. Controlling the access rights of users, e.g. read, write, delete and execute
    5. Controlling the access rights of other applications
    6. Limiting the information contained in outputs
    7. Providing physical or logical access controls for the isolation of sensitive applications, application data, or systems.
    8. Secure log-on procedures
  10. Use of secret authentication information/source code:
    Users should be required to follow the secure coding guidelines/ practices in the use of secret authentication information. All users should be advised to:

    1. Keep secret code/ authentication information confidential, ensuring that it is not divulged to any other parties, including people of authority
    2. Avoid keeping a source code/ important records (e.g. on paper, hand-held device)
    3. Information, unless this can be stored securely and the method of storing has been approved (e.g. password vault)
    4. Change secret authentication information whenever there is any indication of its possible compromise
    5. When passwords are used as secret authentication information, select quality passwords with sufficient minimum length.
    6. Ensure proper protection of passwords when passwords are used as secret authentication.
    7. Information in automated log-on procedures and are stored.
    8. Not use the same secret authentication information for business and non-business purposes.
  11. Facilities and Staffing
    Security expertise on most projects is limited and may be an internal or a contracted service. The allocation of that resource is often difficult even when security activity is limited to networks, authentication, and access control, but when security has to be incorporated into application development, that expertise is spread much thinner. An increase in the level of assurance can significantly affect the both the security and software engineering expertise required. For this discussion, we divide security expertise into two categories. One category consists of knowledge of security functionality such as the specification and implementation of access control, authentication, and encryption functions. Such security functionality may be encapsulated in the system infrastructure. The second category of expertise consists of the skills to identify and mitigate exploitable system vulnerabilities. Historically, a significant number of the vulnerabilities that lead to a security failure were created by application errors and not by failures with the security infrastructure. Vulnerabilities may be in the least exercised parts of the system and depend on pathological aspects of the interface. Such vulnerabilities may be missed by application development teams, who normally concentrate on the core functionality. The security functionality for authentication, authorization, and encryption is typically composed of commercially supplied components that can be tailored for a specific operating environment. Those components must have the required assurance level. It would not be surprising to find the security knowledge associated with the first category to be concentrated within a few teams. The security specialists associated with that infrastructure should be aware of the security issues associated with development and project management. Unfortunately, application development teams rarely have the necessary security expertise. The resources in the second security knowledge category must be spread across multiple development efforts Tasks such as risk assessments, code reviews, threat modeling, Vulnerability assessment, require security expertise. On the other hand, there are security improvement practices that can be implemented without requiring extensive security experience. For example, although security knowledge may be necessary to configure a tool for the static analysis of the source code, the use of such a tool does not require a security background. Testing provides a second example. Penetration testing is often part of an acceptance test or certification process. Penetration testing might be implemented by what is called a red team: security experts who attempt to breach the system defenses. Fuzz testing is a simple form of penetration testing that finds software defects by feeding purposely invalid and ill-formed data as input to program interfaces. Fuzz testing does not replace the need for testing that targets explicit security risks, but it is an example of an approach that can be used without detailed knowledge of security vulnerabilities.
  12. Project and Product Risks
    Poor management of requirements scope is another frequent cause for project failure. Scope management is particularly important where the learning curve is a necessity because of the immaturity of the business usage or the supporting technology. Business integration requirements are pushing the connectivity of networked information systems beyond an organization’s IT systems. Meeting business requirements may depend on using relatively new protocols such as those for Web Services. Those protocols are currently a moving target, as they continue to be revised to reflect the experiences of early adopters. Best practices in this context have short lives, and the lack of well-defined and proven practices adversely affects planning. Plans for these circumstances might include a prototype or use of an iterative or incremental approach. Security mechanisms that mitigate a specific risk may create additional ones. For example, security requirements for managing identity for a large distributed system might be met by implementing authentication and authorization as infrastructure services shared by all applications, but the aggregation of authentication and authorization mechanisms into a shared service makes that service a single point of failure and a possible attack target. Such design decisions should involve a risk assessment to identify any new threats that require mediation, as well as the analysis of the operational costs after the system is deployed.

Security integrated into PM methodology

The Project Management Institute defines a project as an iteratively elaborated endeavor  and security should be considered within each PM process or stage. Security checkpoints built in to the project during several key processes will ensure progress toward the desired security end state at project closure. The best opportunity to ensure secure project delivery exists in the early stages of the project during initiating and planning. Beginning with the end in mind, i.e. the delivery of a secure system, will avoid costly scope, budget and schedule impacts.

  1. Develop Project Charter
    True business value of a security solution is the amount of risk mitigation provided compared to the cost of solution implementation and maintenance. For eg A project that proposes to give a sales force access to data on their smart phones may be implemented very differently if security is considered as a basic requirement of the final deliverables rather than an afterthought to be addressed when security breaches occur after implementation. If a particular smart phone that supports better security protocols becomes a requirement, cost and schedule may be impacted, but costly disclosures of intellectual property may be avoided. PMs can make a convincing case that security dollars will accomplish more if security is baked into the project from the outset, rather than applied as a Band-Aid to pass an audit during operational handoff, or worse, spent to recover from damage after a security incident. A security impact analysis as part of a larger cost-benefit analysis should be executed during the initiation phase of every IT project to make a sound financial decision. Security can be considered part of the larger Cost of Quality of the project. Cost of Quality includes both preventative measures and the costs of failure to create a quality product. In the context of security, preventative measures include just about everything that will be recommended in this paper, including planning, requirements collection, change management, risk management, and training. Additional internal costs will include appraisal costs to find quality problems such as inspections, tests and audits. The costs of failure include the costs to recover from a cyber-security incident like a data loss or theft. Those recovery costs would include external failure costs like loss of goodwill, lost sales, fines, liability costs, investigation of incidents and remediation as well as internal failure costs like wasted work, rework, and failed handoff to operations. Large organizations may have a project methodology that requires a security stage gate to be passed; small organizations may need to simply assign a capable reviewer to examine the project proposal at critical points in the project, especially prior to committing funds to the project
  2. Identify Stakeholders

    A standard Interest vs. Influence stakeholder analysis matrix focused specifically on security considerations may be revealing. Identify the organizational security office, and find out if they have security sign-off on deliverables for your project. Analyze your sponsor’s security attitude, especially if you anticipate the budget is inadequate for security. You may need to move key players higher on the security interest scale, including your project sponsor, technical teams and operations staff. Depending on the formality of the sponsoring organization, the PM may assign a standard list of security roles to project team members. Involving operations staff early in the project and soliciting their input on security requirements during planning will minimize the risk of last minute security fixes as the system rolls into production.
  3. Plan Communications
    The bulk of a PM’s work during the executing stage of a project has to do with communications. In fact, the PMBOK (Project Management Institute) states that “Communication has been identified as one of the single biggest reasons for project success or failure.” We will return for a deep dive into securing project communications in the next section of this paper, but the communications plan is the first step toward ensuring information security during project execution. A communications plan should include not only the method, frequency and audience for communications but may also consider guidelines and technical standards for a wide variety communication channels:

    • Secure project document sharing that uses adequate encryption and access control for data transfers and storage.
    • Telephone conference calls, including the requirement to password protect the meetings and/or use the roll call feature of the conferencing provider to ensure only those invited are on the line and periodically changing your meeting passcode, especially when a project closes.
    • Distribution of meeting minutes and other project documents via email, including the availability of an encryption mechanism like PGP for sensitive emails.
    • Instant messaging via a provider that meets your organization’s security standards.
    • Guidelines regarding forwarding work-related email to personal cell phones and what information is acceptable to be left in voice mailboxes and in auto-responders.
    • Desktop or application sharing/video conferencing via an approved provider.
    • Regular backups to guard against data loss due to computer crashes or user error.
    • Guidelines for use of social media.
  4. Develop Project Team
    Perhaps the most likely risk during project execution is inadvertent data leakage via one of the myriad of communication channels PMs utilize everyday: email, phone, VOIP, IM, numerous options for document sharing including cloud collaboration, and the newest threat to information security, social media. The ideal defense against inadvertent data leakage is a project team that is aware of the risk and uses secure information systems intelligently. To achieve that, security training may be needed. A review of the communications plan at a team kickoff meeting can set expectations. Periodic reviews of the plan will remind team members of their critical role in project security.
  5. Plan Risk Management
    Of the project management processes, “Plan Risk Management” often gets less attention than, say, “Create Work Breakdown Structure” or “Estimate Costs,” but information security, and ultimately project management, are fundamentally about risk management. A malware attack may or may not occur during your project; a resource may or may not be available when scheduled; how much time and money should be dedicated to reducing the negative impact of  an uncertain event? Risk management attempts to qualify and quantify potential impacts and choose effective mitigation strategies. Qualitatively, organizations may have particular risks they tend to avoid; for example, organizations subject to HIPAA regulations will avoid loss of protected data. Quantifying security risk is even more challenging and numerous models and techniques are available Technical experts  designing an IT system will likely use more sophisticated techniques for risk analysis than the PM will use to manage risks to the project, but both aspects of risk management are essential to successful project delivery. Each IT security risk to a project may require custom estimates. As an example, consider the potential impact of a data breach during project execution. Four factors are most important in determining the likelihood that a breach of private consumer data will result in litigation: data type, breach cause, evidence of misuse and size of incident . These four general factors may also be useful for evaluating the impact of a breach for other types of IT data. More valuable data such as account names and passwords or network details will have higher impact than publicly available email addresses. Information stolen by bad actors will likely have higher impact than information inadvertently misdirected. Information that is actively misused will have higher impact than information stolen with no evidence of intent to misuse. And loss of larger amounts of data will be higher impact than smaller amounts of data.
  6. Secure Communications
    Communication is at the heart of project management and every communication channel carries the risk of exposing confidential data. An email sent to the wrong person or worse, distribution list, a team member that stores project documents with an insecure cloud provider, a smart phone lost on the bus, a laptop left in a hotel room. Something as simple as neglecting to sanitize internal document meta-data before forwarding to external customers runs the risk of exposing confidential information.IT project managers often handle intellectual capital that is  the equivalent of the keys to the kingdom. IT project records are a rich source of valuable documents and due to the temporary and fast-moving nature of project work, access controls and records systems may not be maintained after the project closes and the team moves on. Industrial espionage targets blue chip companies and small and mid-sized businesses have also been targeted, especially as easy targets for banking fraud, so no organization is immune to the threat.
  7. Authentication and Password Management
    100% of breaches by Advanced Persistent Threat “bad actors” involve stolen credentials. APT groups are large, well-organized, and well-funded, sometimes by national military organizations. Their mission is to methodically gather broad categories of intellectual property like business plans, email addresses and contact lists of organizational leadership, technology blueprints, and proprietary manufacturing processes. Attackers frequently steal data to make reconnaissance faster, like network infrastructure data and sysadmin guides. In particular, VPN configuration files, systems documentation, and network documentation like firewall configuration files are specifically targeted during reconnaissance.Nearly every aspect of a hacked computer and a user’s online life can be and has been commoditized The argument that “no one would be interested in my data” has been thoroughly debunked. Hackers market lists of stolen credentials for online retailers by the gigabyte. Credentials for critical systems are a prized  commodity. LinkedIn, Yahoo, and Twitter are just a few of the many sites which have been high profile victims of password stealing attacks. Passwords that are reused on a variety of sites and are never changed are a big security risk.

    • Use long, complex passwords.
    • Don’t reuse passwords on multiple web sites or for multiple accounts.
    • Change passwords periodically.
    • Use a password manager so you can choose difficult to guess and unique passwords for each account.
    • Use two-factor authentication where appropriate.
  8. Access Management
    Members of the project team should have the access they need and only the access they need to systems. In the name of speed, credentials are sometimes handed out fast and loose. Defining and documenting a clear system for onboarding and off-boarding personnel will not only improve efficiency of these processes but also ensure credentials are current. Team member access rights need to be reviewed and updated periodically. If people leave the project or company, access should be revoked.

    • Document and use secure onboarding and off-boarding procedures.
    • Schedule periodic reviews of access permissions.
  9. Encryption
    Encryption protects sensitive and valuable data at rest and in motion by transforming plaintext  into coded form referred to as cipher text. Encryption is an almost invisible part of many communications protocols, including web browsing, email, instant messaging, VoIP. Encryption can be especially valuable for storage of data as another layer of protection against data theft or breaches on cloud infrastructure or mobile devices. The ease and convenience of cloud storage brings new challenges, including inadvertent data leakage during storage or transfer or even through deliberate data harvesting by the cloud provider, and challenges for the availability of project records.
    It’s a mistake to choose a cloud vendor based solely on quality of service and price if their privacy and security standards are not adequate. It has been reported that many organization had experienced a breach of outsourced consumer data. The vendor should provide verifiable evidence that data is secure on their infrastructure like security certifications that require audits of their practices with respect to NIST and FISMA standards by accredited organizations like Logyx and Veris group, or via STAR or FedRAMP certs . PM  must make sure that they are familiar with and understand the disaster recovery provisions, privacy terms and conditions, and long-term financial viability of the cloud provider before storing project records in the cloud. Cloud storage providers like Microsoft and Amazon have responded to being hacked by improving their default security configuration. However, even strong encryption is only as secure as the password(s) used to unlock the encryption.  Data on mobile devices like laptops and smart phones should be secured with encryption plus strong authentication since they are frequently lost or stolen.

    • Protect data in the cloud or on mobile devices with encryption.
    • Enforce strong authentication policies for accessing encrypted data.
    • Transmit data only with secure protocols.
  10. Wireless Attacks
    Employees on Road  will undoubtedly have been faced with the question of whether connecting to a hotel, airport or coffee shop wireless connection is “safe.” Connecting to an open wireless network provides a fat attack surface, including the possibility of bad actors potentially intercepting transmitted information, compromising the computer or smart device, or harvesting passwords or information about secure corporate VPN or wireless systems due to unsecured behavior of the wireless card. Handhelds like smart phones hold and transmit rapidly increasing amounts of data and deserve special scrutiny since they are easily and frequently lost or stolen and have in many cases
    minimal built-in provisions for security. If they do not conform to company security policies for passwords, encryption and virus protection they should not have access to company data, including email and voice messaging . The most common cause of data
    breaches due to smartphones is a lost device.

    • Require a secure configuration and security measures for all devices accessing internal data, especially smartphones and laptops, including: data encryption, password protection, anti-virus software and remote wipe ability.
    • Restrict end user administrative permissions.
    • Avoid using unsecured wireless networks in coffee shops, hotels and airports. If using unsecured networks is unavoidable, use VPN or another secure tunnel to access all data.
    • Keep smartphone software up-to-date by enabling automatic updates.
    • Backup smartphone data periodically to avoid losing data, especially contacts, if the device is lost, stolen or damaged.
  11. Physical security
    If your employer or client has locations in several countries, it is likely they are an attractive target for intellectual property theft or industrial espionage. Any work-related information on your laptop or smart phone will require special consideration for maintaining the confidentiality of that information. Physical security for project records should include not only physical access to the electronic systems that store data such as laptops but also physical access to printouts and paper filing systems. Recycling bin, printer and fax output trays and filing cabinets all need to be covered by security policy. Sensitive documents should never be left unattended in insecure  locations and should be shredded with cross-cut shredders when disposed of. Commercial software can now digitally reassemble most documents shredded on popular and inexpensive strip shredders

    • Secure hard copies of data in file cabinets, on fax machines, in printer trays and in waste baskets/shredders.
    • Use security cables. Educate travelers about risks of theft and data leakage.
  12. Secure Deliverables
    Requirements gathering is a critical stage for project security. Security requirements should consider the sponsoring organization’s security policy and regulatory environment. The PMBOK (Project Management Institute) notes that security requirements may impact project costs via the scope baseline and procurements. Requirements elicitation is often not straight-forward; security requirements elicitation may be even less well-defined. A systematic approach may help to achieve a consistent, complete set of security requirements.
  13.  Monitor and Control Risks – Change Control
    Information security is often identified only with hackers and malware, but basic system availability is impacted by a much broader category of events, including planned and even routine system changes. PMs tend to leave technical change management to their technical teams. However, technical change management presents risks to information security availability and integrity and PMs should be familiar with its risks and mitigation of those risks. If a system goes down during a Go-Live event and adequate time has not been reserved to back out changes, the availability of the system to support business functions is compromised. A good change control plan will include enough time to make all changes and complete testing, plus enough time to roll back all changes if the system doesn’t pass operational or functional tests at scheduled checkpoint(s). Similarly, information integrity is at risk if adequate measures aren’t in place to backup and then restore data from backup during the change window if necessary. Changes should be evaluated on a risk matrix, i.e., probability vs. impact, based on impact urgency, risk, benefits and costs, and managed to minimize impacts to business needs . Change windows should have longer lead times and be larger for higher risk changes.
  14. Verify Deliverables
    Operations may expect the project delivery team to deliver an inherently secure system, while the project delivery team may expect security to be the responsibility of operations management after the system is handed off. Consideration should be given to when and how security concerns are most efficiently and effectively addressed in the total system lifecycle, not just during project delivery. Ownership of security should rest with the project manager to the extent that the initial system setup is securable. An organization can either incorporate security guidance into its general project management processes or react to security failures.. If security has been included in requirements gathering with input from the operations team, operational hand-off will be organized around verifying security deliverables as specified and transferring ownership rather than reacting to security problems identified by operations staff as the system is being put into production.  Operational Acceptance Testing checklists  for non-functional components of a system (i.e., quality attributes such as performance, availability, and reliability) like backup/recovery, maintenance and security can guide the hand-off and ensure that operations staff have the documentation and verified configurations they need to support the system.
  15. Document Lessons Learned
    In the excitement of a completed project and the usual pressure to move on to a new one, it may be often overlooked, but capturing lessons learned is an important part of building Organizational Process Assets and your security expertise as a PM. Lesson learned can be one of the most effective ways to motivate secure behaviors and to establish a culture of security in your organization over the long-term. Any security experiences, risks or threats that materialized or not should be noted in the risk register and documented for future project evaluation and planning.

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at: preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion is also welcome.

ISO 27001:2013 A.6.2.1 Mobile Device Policy

by Pretesh Biswas

A mobile device (or handheld computer) is a computing device small enough to hold and operate in the hand. Typically, the device has a either flatscreen display with a small numeric keypad or alphanumeric keyboard, or a touchscreen providing a virtual keyboard and buttons (icons) on-screen. Many such devices can connect to the Internet and interconnect with other devices such as car entertainment systems or headsets via Wi-Fi, Bluetooth or near field communication (NFC). Integrated cameras, digital media players, mobile phone and Global Positioning System (GPS) capabilities are common. Power is typically provided by a lithium battery. Mobile devices may run mobile operating systems that allow third-party apps specialized for said capabilities to be installed and run. Strictly speaking, many so-called mobile devices are not mobile. It is the host that is mobile, i.e., a mobile human host carries a non-mobile smart phone device. Device mobility can be viewed in the context of several dimensions:

  • Physical dimensions and weight
  • Whether or not the device is mobile or some kind of host to which it is attached to is mobile
  • What kind of host devices can be bound to
  • How devices are attached to a host
  • When the mobility occurs

Teleworking (i.e., telecommuting), e-commerce, use of intranets, online education, and the increase use of portable computing devices (e.g., laptops, tablets, smartphones) are driving the need for access to information resources from any place at any time. Today’s mobile workforce or users are no longer just trying to check e-mail from home but part and full-time telecommuters, business partners, Employees and vendors who rely on access to organizations networks to accomplish day-to-day business functions. Information security controls specifically targeting mobile computing and remote access to information resources are becoming an increasingly critical component of any information security program ensuring the protection of the integrity of the organizational networks while allowing remote access to it. To enable remote access to institutional information resources, many organizations are implementing Virtual Private Networks (VPN) technology to provide a secure connection to the institutional network. VPNs send data securely through a shared network. VPNs can be established between remote users and a network or between two or more networks thus using the Internet as the medium for transmitting information securely over and between networks via a process called tunneling.
Mobile devices have been designed for many applications. They include:

  • Mobile computers
    • Mobile Internet devices
    • Tablet computers
    • Laptops
    • Wearable computers
      • Calculator watches
      • Smartwatches
      • Head-mounted displays
    • Personal digital assistants
    • Enterprise digital assistants
    • Calculators
    • Handheld game consoles
    • Portable media players
    • Ultra-mobile PCs
    • Digital media player
  • Digital still cameras (DSC)
  • Digital video cameras (DVC) or digital camcorders
  • Mobile phones
    • Smartphone
    • feature phones
  • Pagers
  • Personal navigation devices (PND)
  • Smart cards
  • Project Ara

The following definitions have been added  so as to be precise about the terms.

  1. Handheld device: A communication device small enough to be carried in the hand or pocket and variously known as a personal digital assistant or personal communication device. Handheld devices considered in this document provide a broad range of services beyond simple telephony, and are closer to mobile computers than legacy mobile phones. Examples of handheld devices: pocket PCs, smartphones, palmtops, the Blackberry.
  2. Pocket PCs: Handheld devices having a touchscreen and a stylus, in addition to smartphone functionality. For Windows Mobile Pocket PCs, two distinct versions exist that present functions in addition to Windows Mobile Standard:
    Pocket PC: Windows Mobile Classic
    Pocket PC Phone Edition: Windows Mobile Professional
  3. Smartphones: The principal difference with pocket PCs is that smartphones do not have a touchscreen. Sometimes this results in a slightly different implementation at the OS level. However, the word “smartphone” recently has become a universal term to designate all types of handheld devices (including both pocket PCs and smartphones). In this document, “smartphone” is synonymous with handheld devices.

A. 6.2.1 Mobile device policy

Control

A policy and supporting security measures should be adopted to manage the risks introduced by using mobile devices.

Implementation guidance

When using mobile devices, special care should be taken to ensure that business information is not compromised. The mobile device policy should take into account the risks of working with mobile devices in unprotected environments.
The mobile device policy should consider:

  1. registration of mobile devices;
  2. requirements for physical protection;
  3. restriction of software installation;
  4. requirements for mobile device software versions and for applying patches;
  5. restriction of connection to information services;
  6. access controls;
  7. cryptographic techniques;
  8. malware protection;
  9. remote disabling, erasure or lockout;
  10. backups;
  11. usage of web services and web apps.

Care should be taken when using mobile devices in public places, meeting rooms and other unprotected areas. Protection should be in place to avoid the unauthorized access to or disclosure of the information stored and processed by these devices, e.g. using cryptographic techniques and enforcing use of secret authentication information. Mobile devices should also be physically protected against theft especially when left, for example, in cars and other forms of transport, hotel rooms, conference centres and meeting places. A specific procedure taking into account legal, insurance and other security requirements of the organization should be established for cases of theft or loss of mobile devices. Devices carrying important, sensitive or critical business information should not be left unattended and, where possible, should be physically locked away. or special locks should be used to secure the devices. Training should be arranged for personnel using mobile devices to raise their awareness of the additional risks resulting from this way of working and the controls that should be implemented. Where the mobile device policy allows the use of privately owned mobile devices, the policy and related security measures should also consider:

  1. separation of private and business use of the devices, including using software to support such separation and protect business data on a private device;
  2. providing access to business information only after users have signed an end user agreement acknowledging their duties (physical protection. software updating. etc.), waiving ownership of business data, allowing remote wiping of data by the organization in case of theft or loss of the device or when no longer authorized to use the service.This policy needs to take account of privacy legislation.

Other Information

Mobile device wireless connections are similar to other types of network connection. but have important differences that should be considered when identifying controls. Typical differences are:

  1. some wireless security protocols are immature and have known weaknesses;
  2. information stored on mobile devices may not be backed~up because of limited network bandwidth or because mobile devices may not be connected at the times when backups are scheduled.

Mobile devices generally share common functions, e.g. networking, internet access, e-mail and file handling. with fixed use devices. information security controls for the mobile devices generally consist of those adopted in the fixed use devices and those to address threats raised by their usage outside the organization’s premises.

Establishing Mobile Device:

The organisation must be able to demonstrate a policy and supporting security controls to reduce the risk posed by mobile or remote devices. As a result of this, it is the organisations responsibility to issue a mobile device policy that should cover the registration/de-registration of mobile devices, physical security requirements, technical security requirements including remote connections, software control, access control and encryption at rest/in-transit. The mobile device policy should  state the businesses requirements for use of mobile devices and when they are appropriate. It is in this policy that the company should specify their expectations for topics such as bring your own device (BYOD). BYOD is a hot topic for information security, with many practitioners agreeing that the risks posed by unmanaged, personally owned devices is too great. However, ISO 27001 does not specify whether BYOD is or is not permitted – it simply requires that the organisation determines this, issues a policy stating their intentions and monitors compliance with this policy through audit or technical controls. For example, a mobile device policy may state that “only corporately issued and managed devices can be used to process company data” and that “unauthorized devices must not be used to access, store or process company data”. If this is the policy, the organisation must monitor for the use of unauthorized devices and specify what the consequences of not adhering to the policy may be e.g. disciplinary procedures. As well as BYOD, the mobile device policy should address technical subjects such as access control, secure configuration and remote access methods. For example, the organisation may require its employees to utilize secure authentication methods such as two-factor authentication and only connect over encrypted channels such as VPN’s. If these methods of connection are specified, as above, compliance with the policy should be enforced technically, monitored for compliance and reported on. In most cases, if the technical capability is not there to support the policy users will not adhere with it so making device builds include VPN clients and reminding users of the need for secure authentication goes a long way.  Other considerations should include physical security of devices in public areas, shoulder surfing and other physical security issues. Employees should be aware of the need to protect their device from unauthorized access at all times, especially when in public places such as on trains and coffee shops. The policy should include a section addressing these requirements. Once the policy has been issued, signed-off by management and communicated to all employees the organisation should continue to monitor compliance through auditing and technical controls. For example, mobile device management (MDM) tools may be used to enforce policy and monitor for policy violations. Furthermore, logs may be reviewed periodically to identify unauthorized access attempts.

The steps involved in establishing Mobile Device Policy

Step 1: Define your scope.

  • Establishing rules people must follow (i.e., policies, standards, procedures) or non-binding recommendations (i.e., guidelines)? Some of both?
  • Do you have a clear definition of what a “mobile Internet device” is for your organization?
    • Your organization must define “mobile Internet devices” as any portable technology running an operating system optimized or designed for mobile computing, such as Android, Blackberry OS (RIM), Apple’s iOS, Windows Mobile, and Symbian. To avoid confusion, your definition should exclude technology running traditional/ classic or more general-purpose operating systems such as any of the Microsoft Windows desktop or server operating systems, versions of MacOS, or Linux.
    • Strive to understand what mobile Internet devices your users actually have and use (including personally owned devices). There may be more of them out there than your expect!
  • Does ownership (i.e., personally owned vs. organization owned) of the device matter?
  •  Requirements for the protection of physical assets?
    • Fake or Stolen Hardware: Organizations and users should also be alert that they may encounter fake or stolen mobile Internet devices. These devices may not work at all, or may break, or may stop working at the next operating system upgrade. Only purchase mobile Internet devices from reputable authorized dealers.
    • It’s A Hard World Out There: Mobile Internet devices live in the real world, and are subject to a panoply of environmental threats ranging from being dropped to getting wet, or getting cooked in hot cars or frozen in cold ones. You may want to encourage users to keep their device on their person, and to consider purchasing and using a case or holster to minimize at least some of those threats.
  • Requirements for the protection of digital data?
    • What Mobile Internet Devices Should You Support?
      It is hard to support “everything” well, and your users may end up more-or-less randomly selecting a mobile Internet device based on word-of-mouth or aggressive salesmanship. Should you be making some specific recommendations? In fact, should you have a standardized list of supported mobile Internet devices?
      Does the cellular connectivity matter from a security point of view? Do you want to standardize on GSM? CDMA? How about iDEN? Do you have opinions about 3G and 4G protocols?
      If you want influence over mobile device selection, are you willing to pay to obtain that influence (e.g., by subsidizing some mobile Internet device choices), or do you just want to try influencing those decisions via policy?
    • What About Enterprise Device Management?
      Some Organizations require all personal computers to be centrally managed. If you’re from one of those sites, will you be comfortable if mobile Internet devices aren’t also centrally managed? Central management of institutionally owned mobile Internet devices may allow you to do things such as: setting minimum device password length, complexity, maximum time between changes, max failures before wiping, etc. adding or removing root certificates configuring institutional WiFi and VPN controlling installation of third party applications, recreational uses, etc.
      If you’re planning to centrally manage mobile Internet devices, you may want to review device enterprise management feature support options as part of deciding what mobile Internet devices you want to endorse and support. Specifically, what options are available for securely and scalably pushing policy to your users’ mobile Internet devices?Also consider that it may be desirable to use different policies for vendors and Guest than for employees. Network access control policies on your residence hall networks as compared to faculty and staff networks may be a good illustrative example of how some institutions treat these populations differently.
      If your intention is to enforce policy on any mobile Internet device connecting to your infrastructure (however you define that), be aware that this will almost certainly include personally owned devices. Decide in advance how you will address inevitable questions, challenges and concerns regarding this decision. Unless your organization is requiring use of personally owned devices to perform official duties, there is likely no obligation for anyone to do so. In other words, it may be entirely at the discretion of the device owner to connect to your organization’s infrastructure. If an individual does not agree with or accept your organization’s terms for doing so they can choose not to use their mobile Internet device to interact with your institution. This may be similar to how many organizations explicitly prohibit the use of personal computers in designated areas, for specific roles or when accessing specific systems or data. In short, you may wish to think of mobile Internet devices connected to your organization’s network in the same way as laptops. That is, if you have specific requirements (e.g., network access control enforcement; no unauthorized Internet connection sharing; etc.) for laptops connecting to your wireless (or wired) network, you will very likely want those same requirements enforced on mobile Internet devices for the same (or similar) reasons. Similarly, you may wish to think about mobile Internet devices not connected to your organization’s wired or wireless networks as any other non-trusted computer on the Internet, even though these devices may be physically present on your campus.
    • What About Mobile Device App Choices, Web Site Readiness and New Features?
      Mobile Internet devices have a far more constrained application development environment than traditional desktops and laptops. Thus, for example, while you may have standardized on one web browser for use on desktops and laptops, such as Firefox, perhaps, you may be surprised to find that choice may not even be available on some mobile Internet devices. Is this a problem for you or your applications
      You should also take time to look at how critical  online resources look on a mobile Internet device. A home page that’s optimized for a large screen and a high-speed connection may not work well on a mobile device with more modest capabilities. For example, try viewing your organizational web sites via simulators such as http://www.testiphone.com/ — are your web pages still usable? Should you create a mobile version of your home page? (If http://www.example.com is your normal home page, you might create a simplified home page at m.example.com for mobile users). Recognize, too, that mobile devices bring some new capabilities, such as QR (“quick response”) codes, the square dot-like codes that are readable by camera-equipped mobile Internet devices. They’re cool, aren’t they? But how do you know what a code points to? Should you be using them yourself to increase ease of use for your mobile Internet device users? Or do they represent a security threat that should be discouraged? You should begin having these conversations at your site.
    • How about Spam and Malware Management On Mobile Internet Devices
      Recognize that spammers will still target users even if they’re on mobile Internet devices. What spam management options do users have for a given service? How can they report spam that slips through? Malware may still target users of mobile devices, but due to the device architecture, traditional antivirus software may not be needed (or may not even be available!) Your security team and/or operational support staff should talk about how they want to approach issues such as spam and malware on supported mobile Internet devices.
    • How About Hardware and Data Encryption?
      Personally identifiable information (“PII”) is a material concern at many sites. Do the mobile devices you’ve chosen to support have hardware encryption? Is that encryption solid enough to meet your PII protection requirements? Similarly, some mobile Internet devices may forgo the use of on-device storage and store all data “in the cloud.” You likely already have requirements in place to protect sensitive or important institutional data. Make sure devices that store institutional data in the cloud meet applicable security and privacy requirements for doing so.
    • And Remote Wipe Capabilities?
      If you lose control over an Organizational owned mobile Internet device, do you need the ability to remotely send the device a magic “kill code?” (Note that even if you can remotely wipe the device, there may still be off-site backups floating around, or the device may get taken offline before the kill code can be sent and processed by the device, so don’t depend too much on being able to send remote kill codes)
    • Jailbreaking Apple iPhones, Rooting Android Devices
      Normally only Apple-approved applications run on the iPhone. However, some users have developed hacks (NOT blessed by Apple!) that will allow users to “break out of that jail” and run whatever applications they want. Jailbreaking your iPhone violates the license agreement and voids its warranty, but it is estimated that 5-10% of all iPhone users have nonetheless done so.
      Because jailbreaking is operating system version specific, many users of jailbroken iPhones hesitate to upgrade their iPhones even when important patches are released, because upgrading will reverse the jailbroken status of their phone. Users who want to jailbreak their iPhones may also be specifically targeted by malicious applications masquerading as jailbreaking tools. For that matter, any sort of application for a jailbroken iPhone obtained from a third party source may not have been subject to any security review or auditing, unlike applications from Apple’s official AppStore, and may include malicious routines.
      “Rooting” can be understood as the Android equivalent of jailbreaking. As described above, rooting Android based devices can introduce new or unexpected security and/or privacy risks to data stored on the device. For all these reasons, your site may want to discourage or forbid jailbreaking or rooting of institutionally supported mobile devices.
    • Institutional Contact With Users’ Mobile Devices
      Many Organizations ask  their employees, vendors and customers to register their mobile numbers with the school for purposes such as emergency notification. Be careful not to abuse the numbers entrusted to you solely for emergency purposes for unrelated activities, such as routine announcements or push marketing purposes.
      Expectations should also be set for work-related contacts over mobile devices. That is, unless an employee is officially on call (and paid for that status), or it’s a real emergency, avoid calling employees outside of work hours. Let employees have some time off to spend with their families and their friends, or to just sleep and recuperate! Please don’t treat employees as if they’re on unpaid call status 24×7, or you may find a sudden increase in “cellular connectivity issues” spontaneously arising, potentially at some very inopportune times.
  •  Requirements for the protection of personal privacy?
    Mobile Internet devices can potentially have profound privacy implications. By way of example, almost all mobile Internet devices have the ability to have their physical location tracked by a variety of means, a wonderful invention if you’re having a heart attack and have just called 911 for an ambulance, but potentially a huge invasion of your privacy if this service gets abused by a stalker, or by an intrusive marketer.
    Mobile Internet devices also emit cellular radiation. While those emissions are limited by law, and are believed to be at safe levels, some phones emit less radiation than others, and use of hands-free devices may also reduce (or shift) the amount of radiation you receive. If this issue is important to you, we encourage you to make appropriate choices.
    Users of mobile Internet devices needs to be careful when it comes to where and when they use their devices. In particular, please  NOT use your mobile Internet device while you’re driving. Driving while distracted can be as bad as driving while under the influence of alcohol, and you don’t want to see cool mobile Internet devices result in totally avoidable tragic accidents. Many organizations may want to explicitly forbid use of mobile Internet devices while driving.
  • Defining acceptable use in general? You will likely want to treat employee devices differently from vendors devices. What about guests?
  • Does existing physical asset, technology or data-specific policy cover all or part of your defined scope?
    If not, consider revising existing policy. Doing so may be easier or more desirable than crafting new policy. If at all possible, implement a technology-agnostic policy framework that allows you to create more specific standards, procedures or guidelines without having to modify policy.
  • Communicate what you are trying to accomplish and a high-level implementation plan with your constituents.
    Help your executives understand residual risks associated with your chosen approach and why/how mobile Internet devices may be different from more familiar computing technologies.

Step 2: Defining Mobile Device Characteristics

Mobile device features are constantly changing, so it is difficult to define the term “mobile device”. However, as features change, so do threats and security controls, so it is important to establish a baseline of mobile device features. The following hardware and software characteristics collectively can be define as the baseline

  • A small form factor
  • At least one wireless network interface for network access (data communications). This interface uses Wi-Fi, cellular networking, or other technologies that connect the mobile device to network infrastructures with connectivity to the Internet or other data networks.
  • Local built-in (non-removable) data storage
  • An operating system that is not a full-fledged desktop or laptop operating system
  • Applications available through multiple methods (provided with the mobile device, accessed through web browser, acquired and installed from third parties)
    The list below details other common, but optional, characteristics of mobile devices. These features do not define the scope of devices included in the publication, but rather indicate features that are particularly important in terms of security risk. This list is not intended to be exhaustive, and is merely illustrative of common features of interest as of this writing.
  • Network services:
    • One or more wireless personal area network interfaces, such as Bluetooth or near-field communications
    • One or more wireless network interfaces for voice communications, such as cellular
    • Global Positioning System (GPS), which enables location services
  • One or more digital cameras/video recording devices
  • Microphone
  • Storage:
    • o Support for removable media
    • Support for using the device itself as removable storage for another computing device
  • Built-in features for synchronizing local data with a different location (desktop or laptop computer, organization servers, telecommunications provider servers, other third party servers, etc.)

High-Level Threats and Vulnerabilities

Mobile devices typically need to support multiple security objectives. These can be accomplished through a combination of security features built into the mobile devices and additional security controls applied to the mobile devices and other components of the enterprise IT infrastructure. The most common security objectives for mobile devices are as follows:

  • Confidentiality—ensure that transmitted and stored data cannot be read by unauthorized parties
  • Integrity—detect any intentional or unintentional changes to transmitted and stored data
  • Availability—ensure that users can access resources using mobile devices whenever needed.

To achieve these objectives, mobile devices should be secured against a variety of threats. Mobile devices often need additional protection because their nature generally places them at higher exposure to threats than other client devices (e.g., desktop and laptop devices only used within the organization’s facilities and on the organization’s networks). Before designing and deploying mobile device solutions, organizations should develop system threat models for the mobile devices and the resources that are accessed through the mobile devices. Threat modeling involves identifying resources of interest and the feasible threats, vulnerabilities, and security controls related to these resources, then quantifying the likelihood of successful attacks and their impacts, and finally analyzing this information to determine where security controls need to be improved or added. Threat modeling helps organizations to identify security requirements and to design the mobile device solution to incorporate the controls needed to meet the security requirements. Major security concerns for these technologies that would be included in most mobile device threat models are listed below.

  1. Lack of Physical Security Controls
    Mobile devices are typically used in a variety of locations outside the organization’s control, such as employees’ homes, coffee shops, hotels, and conferences. Even mobile devices only used within an organization’s facilities are often transported from place to place within the facilities. The devices’ mobile nature makes them much more likely to be lost or stolen than other devices, so their data is at increased risk of compromise. When planning mobile device security policies and controls, organizations should assume that mobile devices will be acquired by malicious parties who will attempt to recover sensitive data either directly from the devices themselves or indirectly by using the devices to access the organization’s remote resources. The mitigation strategy for this is layered. One layer involves requiring authentication before gaining access to the mobile device or the organization’s resources accessible through the device. A mobile device usually has a single authenticator—not a separate account for each user of the device—as it is generally assumed that the device only has one user.3 So there is no username, just a password, which is often a PIN. More robust forms of authentication, such as token-based authentication, network-based device authentication, and domain authentication, can be used instead of or in addition to the built-in device authentication capabilities. A second mitigation layer involves protecting sensitive data—either encrypting the mobile device’s storage so that sensitive data cannot be recovered from it by unauthorized parties, or not storing sensitive data on mobile devices. Even if a mobile device is always in the possession of its owner, there are other physical security risks, such as an attacker looking over a teleworker’s shoulder at a coffee shop and viewing sensitive data on the mobile device’s screen (for example, a password being entered). Finally, another layer of mitigation involves user training and awareness, to reduce the frequency of insecure physical security practices.
  2. Use of Untrusted Mobile Devices
    Many mobile devices, particularly those that are personally owned (bring your own device, BYOD), are not necessarily trustworthy. Most current mobile devices lack the root of trust features (e.g., trusted platform modules, TPMs) that are increasingly built into laptops and other types of hosts. There is also frequent jailbreaking and rooting of mobile devices, which means that the built-in restrictions on security, operating system use, etc. have been bypassed. Organizations should assume that all mobile devices are untrusted unless the organization has properly secured them and monitors their security continuously while in use with enterprise applications or data. There are several possible mitigation strategies related to use of untrusted mobile devices. One option is to restrict or prohibit use of BYOD devices, thus favoring organization-issued devices. Another effective technique is to fully secure each organization-issued mobile device; this gets the mobile device in as trusted a state as possible, and deviations from this secure state can be monitored and addressed. There are also technical solutions for achieving degrees of trust in BYOD devices, such as running the organization’s software in a secure, isolated sandbox/secure container on the mobile device, or using device integrity scanning applications.
  3. Use of Untrusted Networks
    Because mobile devices primarily use non-organizational networks for Internet access, organizations normally have no control over the security of the external networks the devices use. Communications systems may include wireless mechanisms such as Wi-Fi and cellular networks. These communications systems are susceptible to eavesdropping, which places sensitive information transmitted at risk of compromise. Man-in-the-middle attacks may also be performed to intercept and modify communications. Unless it is absolutely certain that the mobile device will only be used on trusted networks controlled by the organization, organizations should plan their mobile device security on the assumption that the networks between the mobile device and the organization cannot be trusted.Risk from use of untrusted networks can be reduced by using strong encryption technologies (such as virtual private networks, VPNs) to protect the confidentiality and integrity of communications, as well as using mutual authentication mechanisms to verify the identities of both endpoints before transmitting data. Another possible mitigation is to prohibit use of insecure Wi-Fi networks, such as those running known vulnerable protocols. Also, all network interfaces not needed by the device can be disabled, thus reducing the attack surface.
  4. Use of Untrusted Applications
    Mobile devices are designed to make it easy to find, acquire, install, and use third-party applications from mobile device application stores. This poses obvious security risks, especially for mobile device platforms and application stores that do not place security restrictions or other limitations on third-party application publishing. Organizations should plan their mobile device security on the assumption that unknown third-party mobile device applications downloadable by users should not be trusted. Risk from these applications can be reduced in several ways, such as prohibiting all installation of third-party applications, implementing whitelisting to allow installation of approved applications only, verifying that applications only receive the necessary permissions on the mobile device, or implementing a secure sandbox/secure container that isolates the organization’s data and applications from all other data and applications on the mobile device. Another possible mitigation is to perform a risk assessment on each third-party application before permitting its use on the organization’s mobile devices. It is important to note that even if these mitigation strategies are implemented for third-party applications, users can still access untrusted web-based applications through browsers built into their mobile devices. The risks inherent in this can be reduced by prohibiting or restricting browser access; by forcing mobile device traffic through secure web gateways, HTTP proxy servers, or other intermediate devices to assess URLs before allowing them to be contacted; or by using a separate browser within a secure sandbox/secure container for all browser-based access related to the organization, leaving the mobile device’s built-in browser for other uses.
  5. Interaction with Other Systems
    Mobile devices may interact with other systems in terms of data exchange (including synchronization) and storage. Local system interaction generally involves connecting a mobile device to a desktop or laptop wirelessly or via a cable for syncing. It can also involve tethering, such as using one mobile device to provide network access for another mobile device. Remote system interaction most often involves automatic backups of data to a cloud-based storage solution. When all of these components are under the organization’s control, risk is generally acceptable, but often one or more of these components are external. Examples include connecting a personally-owned mobile device to an organization-issued laptop, connecting an organization-issued mobile device to a personally-owned laptop, connecting an organization-issued mobile device to a remote backup service, and connecting any mobile device to an untrusted charging station. In all of these scenarios, the organization’s data is at risk of being stored in an unsecured location outside the organization’s control; transmission of malware from device to device is also a possibility. There are also concerns regarding mobile devices exchanging data with each other. The mitigation strategies depend on the type of attachment. Preventing an organization-issued mobile device from syncing with a personally-owned computer necessitates security controls on the mobile device that restrict what devices it can synchronize with. Preventing a personally-owned mobile device from syncing with an organization-issued computer necessitates security controls on the organization-issued computer, restricting the connection of mobile devices. Preventing the use of remote backup services can possibly be achieved by blocking use of those services (e.g., not allowing the domain services to be contacted) or by configuring the mobile devices not to use such services. Users should be instructed not to connect their mobile devices to unknown charging devices; they should carry and use their own charging devices. Finally, mobile devices can be prevented from exchanging data with each other through logical or physical means (blocking use of services through configuration or physical shielding, etc.)
  6. Use of Untrusted Content
    Mobile devices may use untrusted content that other types of devices generally do not encounter. An example is Quick Response (QR) codes. They are specifically designed to be viewed and processed by mobile device cameras. Each QR code is translated to text, typically a URL, so malicious QR codes could direct mobile devices to malicious websites. This could allow for targeted attacking, such as placing malicious QR codes at a location where targeted users gather.
    A primary mitigation strategy is to educate users on the risks inherent in untrusted content and to discourage users from accessing untrusted content with any mobile devices they use for work. Another mitigation is to have applications, such as QR readers, display the unobfuscated content (e.g., the URL) and allow users to accept or reject it before proceeding. Depending on the network configuration, it may also be possible to use secure web gateways, HTTP proxy servers, or other intermediate devices to validate URLs before allowing them to be contacted. In high security situations, it is also possible to restrict peripheral use on mobile devices, such as disabling camera use in order to prevent QR codes from being processed.
  7. Use of Location Services
    Mobile devices with GPS capabilities typically run what are known as location services. These services map a GPS-acquired location to the corresponding businesses or other entities close to that location. Location services are heavily used by social media, navigation, web browsers, and other mobile-centric applications. In terms of organization security and personal privacy, mobile devices with location services enabled are at increased risk of targeted attacks because it is easier for potential attackers to determine where the user and the mobile device are, and to correlate that information with other sources about who the user associates with and the kinds of activities they perform in particular locations. This situation can be mitigated by disabling location services or by prohibiting use of location services for particular applications such as social networking or photo applications. Users may also be trained to turn off location services when in sensitive areas. However, a similar problem can occur even if GPS capabilities or location services are disabled. It is increasingly common for websites and applications to determine a person’s location based on their Internet connection, such as a Wi-Fi hotspot or IP address range. The primary mitigation for this is to opt out of such location services whenever possible. Organizations should be aware that keeping location services enabled can also have positive effects on information security. For example, different security policies can be enforced depending on whether the mobile device is being used within the organization’s facilities or outside the organization’s facilities.

Step 3: Establishing the required Technologies for Mobile Device Management

Centralized mobile device management technologies are a growing solution for controlling the use of both organization-issued and personally-owned mobile devices by enterprise users. In addition to managing the configuration and security of mobile devices, these technologies offer other features, such as providing secure access to enterprise computing resources. This section provides an overview of the current state of these technologies, focusing on the technologies’ components, architectures, and capabilities.

  1. Components and Architectures
    There are two basic approaches to centralized mobile device management: use a messaging server’s management capabilities (often from the same vendor that makes a particular brand of mobile device operating system), or use a product from a third party, which is designed to manage one or more brands of mobile device operating systems.It may be possible with the latter approach to have a single product that can manage multiple brands of mobile device operating systems desired for use within an enterprise. However, a product provided by a mobile device manufacturer may have more robust support for the mobile devices than third party products.Both approaches can provide the necessary centralized management functionality. Architecturally, both approaches to centralized mobile device management are quite similar. The typical solution has a straightforward client/server architecture. The enterprise contains one or more servers that provide the centralized management capabilities, and one or more client applications are installed on each mobile device and configured to run in the background at all times. If the device is organization issued, the client application typically manages the configuration and security of the entire device. If the device is BYOD, the client application typically manages only the configuration and security of itself and its data, not the entire device. The client application and data should be sandboxed from the rest of the device’s applications and data in a secure container, both helping to protect the enterprise from a compromised device and helping to preserve the privacy of the device’s owner. The centralized mobile device management may make use of other enterprise services, such as domain authentication services and VPN services. If there is not a centralized management solution, or certain mobile devices cannot use it, then mobile devices have to be managed individually and manually. In addition to the additional resources expended, there are two major security problems with this:

    • The security controls provided by a mobile device often lack the rigor of those provided by a centralized mobile device management client application. For example, a mobile device often supports only a short passcode for authentication and may not support strong storage encryption. This will necessitate acquiring, installing, configuring, and maintaining a variety of third-party security controls that provide the missing functionality.
    • It may not be possible to manage the security of the device when it is not physically present within the enterprise. It is possible to install utilities that manage devices remotely, but it will require significantly more effort to use such utilities to manually apply updates and perform other maintenance and management tasks with out-of-office mobile devices.

    To avoid these problems, organizations may choose to prohibit the use of any mobile devices that are not centrally managed.

  2. Capabilities
    Now let us describes security services commonly needed for security management of mobile devices. These services may be provided by the mobile device operating system, enterprise mobile device management (MDM) software, or other security controls. These services apply to the entire mobile device (if it is fully managed) or to the mobile device’s secure sandbox/secure container, unless explicitly noted otherwise. These services are equally relevant for centrally managed or individually managed mobile devices. Most organizations will not need all of the security services listed in this section. Organizations deploying mobile devices should consider the merits of each security service, determine which services are needed for their environment, and then design and acquire one or more solutions that collectively provide the necessary services.

    1. General policy. The centralized technology can enforce enterprise security policies on the mobile device. General policy restrictions of particular interest for mobile device security include the following:
      • Restrict user and application access to hardware, such as the digital camera, GPS, Bluetooth interface, USB interface, and removable storage.
      • Restrict user and application access to native OS services, such as the built-in web browser, email client, calendaring, contacts, application installation services, etc.
      • Manage wireless network interfaces (Wi-Fi, Bluetooth, etc.)
      • Automatically monitor, detect, and report when policy violations occur, such as changes from the approved security configuration baseline, and automatically take action when possible and appropriate
      •  Limit or prevent access to enterprise services based on the mobile device’s operating system version (including whether the device has been rooted/jailbroken), vendor/brand, model, or mobile device management software client version (if applicable). Note that this information may be spoofable.
    2.  Data Communication and Storage
      • Strongly encrypt data communications between the mobile device and the organization. This is most often in the form of a VPN, although it can be established through other uses of secure protocols and encryption.
      • Strongly encrypt stored data on both built-in storage and removable media storage. Removable media can also be “bound” to particular devices such that encrypted information can only be decrypted when the removable media is attached to the device, thereby mitigating the risk of offline attacks on the media.
      • Wipe the device (to scrub its stored data) before reissuing it to another user, retiring the device, etc.
      • Remotely wipe the device (to scrub its stored data) if it is suspected that the device has been lost, stolen, or otherwise fallen into untrusted hands and is at risk of having its data recovered by an untrusted party
      • A device often can also be configured to wipe itself after a certain number of incorrect authentication attempts.
    3.  User and Device Authentication
      • Require a device password/passcode and/or other authentication (e.g., token-based authentication, network-based device authentication, domain authentication) before accessing the organization’s resources. This includes basic parameters for password strength and a limit on the number of retries permitted without negative consequences (e.g., locking out the account, wiping the device).
      • If device account lockout is enabled or the device password/passcode is forgotten, an administrator can reset this remotely to restore access to the device.
      • Have the device automatically lock itself after it is idle for a period (e.g., 5 minutes).
      • Under the direction of an administrator, remotely lock the device if it is suspected that the device has been left in an unlocked state in an unsecured location.
    4. Applications
      • Restrict which app stores may be used.
      • Restrict which applications may be installed through whitelisting (preferable) or blacklisting.
      • Restrict the permissions (e.g., camera access, location access) assigned to each application.
      • Install, update, and remove applications. Safeguard the mechanisms used to perform these actions. Keep a current inventory of all applications installed on each device.
      •  Restrict the use of operating system and application synchronization services (e.g., local device synchronization, remote synchronization services and websites).
      • Verify digital signatures on applications to ensure that only applications from trusted entities are installed on the device and that code has not been modified.
      • Distribute the organization’s applications from a dedicated mobile application store.

Step 4: Security for the Enterprise Mobile Device Solution Life Cycle

Organizations may follow a project management methodology or life cycle model  in the model presented here. The phases of the life cycle are as follows:

Phase 1: Initiation.

This phase involves the tasks that an organization should perform before it starts to design a mobile device solution. These include identifying needs for mobile devices, providing an overall vision for how mobile device solutions would support the mission of the organization, creating a high-level strategy for implementing mobile device solutions, developing a mobile device security policy, and specifying business and functional requirements for the solution. The initiation phase involves many preparatory actions, such as identifying current and future needs, and specifying requirements for performance, functionality, and security. A critical part of the initiation phase is the development of a mobile device security policy for an organization. A mobile device security policy should define which types of the organization’s resources may be accessed via mobile devices, which types of mobile devices are permitted to access the organization’s resources, the degree of access that various classes of mobile devices may have (for example, organization-issued devices versus personally- owned devices), and how provisioning should be handled. It should also cover how the organization’s centralized mobile device management servers are administered, how policies in those servers are updated, and all other requirements for mobile device management technologies. The mobile device security policy should be documented in the system security plan. To the extent feasible and appropriate, the mobile device security policy should be consistent with and complement security policy for non-mobile systems.

  1. Restrictions on Mobile Devices and Access Levels
    An organization’s mobile device security policy often limits the types of mobile devices that may be used for enterprise access; this is done for a variety of reasons, including security concerns and technology limitations. For example, an organization might permit only organization-owned mobile devices to be used. Some organizations have tiered levels of access, such as allowing organization-issued mobile devices to access many resources, BYOD mobile devices running the organization’s mobile device management client software to access a limited set of resources, and all other BYOD mobile devices to access only a few web-based resources, such as email. This allows an organization to limit the risk it incurs by permitting the most-controlled devices to have the most access and the least-controlled devices to have only minimal access. Some organizations also maintain lists of approved mobile devices (by operating system version, by brand/model of phone, etc.) Each organization should make its own risk-based decisions about what levels of access should be permitted from which types of mobile devices. Factors that organizations should consider when setting mobile device security policy for this include the following:

    • Sensitivity of work. Some work involves access to sensitive information or resources, while other work does not. Organizations may have more restrictive requirements for work involving sensitive information, such as permitting only organization-issued devices to be used. Organizations should also be concerned about the issues involved in remotely scrubbing sensitive information from BYOD mobile devices
    • The level of confidence in security policy compliance. Meeting many of an organization’s security requirements can typically be ensured only if the organization controls the configuration of the mobile devices. For devices not running the organization’s mobile device management client software, some requirements can possibly be verified by automated security health checks conducted by the mobile device management server when mobile devices attempt to connect, but other requirements cannot be verified. Organizations may decide to require mobile devices to run the specified mobile device management software.
    • Cost. Costs associated with mobile devices will vary based on policy decisions. The primary direct cost from a security perspective is issuing mobile devices and client software. There are also indirect costs in maintaining the security of mobile devices and in providing security-related technical support for users.
    • Work location. Risks will generally be lower for devices used only in the enterprise environment than for devices used in a variety of locations.
    • Technical limitations. Certain types of mobile devices or operating systems may be needed, such as for running a particular application. Also, an organization’s mobile device management client software may only support certain types of mobile devices (e.g., particular operating system versions).
    • Compliance with mandates and other policies. Organizations may need to comply with mobile device-related requirements from mandates and other sources, such as a Federal department issuing policy requirements to its member agencies. An example of a possible requirement is restrictions on using mobile devices in foreign countries that have strong known threats against Federal agency systems; in such cases, it may be appropriate to issue “loaner” mobile devices or to prohibit mobile device use altogether.

    Organizations may choose to specify additional security requirements that are tied to factors such as the sensitivity of work. Many organizations require more stringent security controls for work situations that are particularly high-risk, such as permitting the work only from organization-issued and secured mobile devices, and requiring the use of multi-factor authentication for access to the mobile device and to enterprise resources. Another possible security control is to migrate high-risk resources to servers that assume responsibility for protecting them; for example, a mobile device could connect to a server that holds sensitive data that the user needs to access, instead of the sensitive data being stored locally on the mobile device. In high-risk situations, organizations may also choose to reduce risk by prohibiting mobile devices from accessing particular types of information, such as sensitive personally identifiable information (PII).
    There are frequent changes in mobile device capabilities, the security controls available to organizations, the types of threats made to different types of devices, and so on. Therefore, organizations should periodically reassess their policies for mobile devices and consider changing which types of mobile devices are permitted, what levels of access they may be granted, and which security controls are required. Organizations should also be aware of the emergence of new types of mobile device solutions and of major changes to existing mobile device management technologies, and ensure that the organization’s policies are updated accordingly as needed.

  2. Additional User Requirements
    Organizations often have additional security considerations for mobile devices that, while helpful in mitigating threats, cannot necessarily be directly enforced by the organization. Organizations should educate users on the importance of these additional security measures and define users’ responsibilities for implementing these measures in policy and mobile device agreements.
    One possible security consideration involves wireless personal area networks (WPAN), which are small-scale wireless networks that require no infrastructure to operate. Examples of WPAN technologies are using a wireless keyboard or mouse with a computer, printing wirelessly, synchronizing a mobile device with a computer wirelessly, and using a wireless headset or earpiece with a smart phone. Commonly used types of WPAN technologies include Bluetooth and near-field communications. For devices within proximity of significant threats, mobile device users should enable these technologies only when needed to prevent misuse by unauthorized parties.

Phase 2: Development.

In this phase, personnel specify the technical characteristics of the mobile device solution and related components. These include the authentication methods and the cryptographic mechanisms used to protect communications and stored data. The types of mobile devices (brands, operating systems, etc.) to be authorized for use should also be considered, since they can affect the desired policies. Care should be taken to ensure that the mobile device security policy can be employed and enforced by all authorized clients. At the end of this phase, solution components are procured. Once the organization has established a mobile device security policy, identified mobile device needs, and completed other preparatory activities, the next steps are to determine which types of mobile device management technologies should be used and to design a solution to deploy. There are many considerations for designing a solution, most of which are generally applicable to any IT technology. Major considerations include the following:

  • Architecture. Designing the architecture includes the selection of mobile device management server and client software, the placement of the mobile device management server and other centralized elements, and the architecture of any virtual private network (VPN) solutions.
  • Authentication. Authentication involves selecting device and/or user authentication methods, including determining procedures for issuing and resetting authenticators and for provisioning users and/or client devices with authenticators. Authentication includes access to or integration with existing enterprise authentication systems.
  • Cryptography. Decisions related to cryptography include selecting the algorithms for encryption and integrity protection of mobile device communications, and setting the key strength for algorithms that support multiple key lengths. Configuration requirements. This involves setting minimum security standards for mobile devices, such as mandatory host hardening measures and patch levels, and specifying additional security controls that must be employed on the mobile device, such as a VPN client.
  • Device provisioning. It is important to determine how both new and existing devices will be provisioned with client software, authenticators, configuration settings, etc.
  •  Application vetting and certification requirements. This sets security, performance, and other requirements that applications must meet and determines how proof of compliance with requirements must be demonstrated.

The security aspects of the mobile device solution design should be documented in the system security plan. The organization should also consider how incidents involving the mobile device solutions should be handled and document those plans as well.

Phase 3: Implementation.

In this phase, equipment is configured to meet operational and security requirements, including the mobile device security policy documented in the system security plan, installed and tested as a pilot, and then activated on a production network. Implementation includes integration with other security controls and technologies, such as security event logging and authentication servers. After the mobile device solution has been designed, the next step is to implement and test a pilot of the design, before putting the solution into production. Aspects of the solution that should be evaluated for each type of mobile device include the following:

  • Connectivity. Users can establish and maintain connections from the mobile device to the organization from the locations they are expected to use. Users can connect to all of the organization’s resources that they are permitted to and cannot connect to any other organization resources.
  • Protection. Information stored on the mobile device and communications between the mobile device and the organization are protected in accordance with the established requirements.
  • Authentication. Authentication is required and cannot be readily compromised or circumvented. All device, user, and domain authentication policies are enforced.
  • Applications. The applications to be supported by the mobile device solution function properly. All restrictions on installing applications are enforced. All restrictions on uninstalling applications (such as enterprise mobile device management software) are enforced.
  • Management. Administrators can configure and manage all components of the solution effectively and securely. The ease of deployment and configuration is particularly important. Another concern is the ability of users to alter device/client software settings, which could weaken mobile device security.
  • Logging. The mobile device solution logs security events in accordance with the organization’s policies. Note that the security logging capabilities of mobile devices vary widely.
  • Performance. All components of the solution provide adequate performance during normal and peak usage. It is important to also consider the performance of intermediate devices, such as routers and firewalls.
  • Security of the Implementation. The mobile device implementation itself may contain vulnerabilities and weaknesses that attackers could exploit. Organizations with high security needs may choose to perform extensive vulnerability assessments against the mobile device solution components. At a minimum, all components should be updated with the latest available patches and configured following sound security practices. The organization should also take basic measures to prevent the user from circumventing the device’s security features. Also, jailbroken or rooted mobile devices should be automatically detected to prohibit their use, for cases in which detection is feasible.
  • Default Settings. On a per-OS version basis, implementers should carefully review the default values for each mobile device setting and alter the settings as necessary to support security requirements. Implementers should also ensure that the mobile device solution does not unexpectedly “fall back” to insecure default settings for interoperability or other reasons.

Organizations should fully secure each organization-issued mobile device before allowing a user to access it. Any already-deployed mobile device with an unknown security profile (e.g., unmanaged device) should be fully secured to a known good state (for example, through deployment and use of enterprise mobile device management technologies). Supplemental security controls should be deployed as risk merits, such as antivirus software and data loss prevention (DLP) technologies.

Phase 4: Operations and Maintenance.

This phase includes security-related tasks that an organization should perform on an ongoing basis once the mobile device solution is operational, including patching, log reviews, and attack detection. Operational processes that are particularly helpful for maintaining mobile device security, and thus should be performed regularly, include the following:

  • Checking for upgrades and patches to the mobile device solution components (including mobile device infrastructure components, mobile device operating systems, and mobile device applications), and acquiring, testing, and deploying the updates
  • Ensuring that each mobile device infrastructure component (mobile device management servers, authentication servers, etc.) has its clock synced to a common time source so that its timestamps will match those generated by other systems
  • Re-configuring access control features as needed based on factors such as policy changes, technology changes, audit findings, and new security needs
  • Detecting and documenting anomalies within the mobile device infrastructure through continuous monitoring, including unauthorized configuration changes to mobile devices. Such anomalies might indicate malicious activity or deviations from policy and procedures. Anomalies should be reported to other systems’ administrators as appropriate.
  • Keeping an active inventory of each mobile device, its user(s), and its applications
  • Providing training and awareness activities for mobile device users on threats and recommended security practices
  • Revoking access to or deleting an application that has already been installed but has subsequently been assessed as too risky to use
  • Scrubbing sensitive data from mobile devices before reissuing them to other users

Organizations should also periodically perform assessments to confirm that the organization’s mobile device policies, processes, and procedures are being followed properly. Assessment activities may be passive, such as reviewing logs, or active, such as performing vulnerability scans and penetration testing.

Phase 5: Disposal.

This phase encompasses tasks that occur when a mobile device solution or its components are being retired, including preserving information to meet legal requirements, sanitizing media, and disposing of equipment properly.
Before a mobile device component permanently leaves an organization (such as when a leased server’s lease expires or when an obsolete mobile device is being recycled) or is reassigned to another user, the organization should remove any sensitive data from the mobile device. The task of scrubbing all sensitive data from storage devices such as hard drives and memory cards is often surprisingly difficult because of all the places where such data resides and the increasing reliance on flash memory instead of magnetic disks.

An example of Mobile Device Policy

  1.  Introduction                                                                                          Mobile devices, such as smartphones and tablet computers, are important tools for the organization and Company supports their use to achieve business goals. However, mobile devices also represent a significant risk to data security as, if the appropriate security applications and procedures are not applied, they can be a conduit for unauthorized access to the organization’s data and IT infrastructure. This can subsequently lead to data leakage and system infection.
    has a requirement to protect its information assets in order to safeguard its customers, intellectual property and reputation. This document outlines a set of practices and requirements for the safe use of mobile devices and applications.
  2. Scope
    1. All mobile devices, whether owned by or owned by employees, inclusive of smartphones and tablet computers, that have access to corporate networks, data and systems are governed by this mobile device security policy. The scope of this policy does not include corporate IT-managed laptops.
    2. Exemptions: Where there is a business need to be exempted from this policy (too costly, too complex, adversely impacting other business requirements) a risk authorized by security management must be conducted.
    3. Applications used by employees on their own personal devices which store or access corporate data, such as cloud storage applications, are also subject to this policy.
  3.  Policy
    1. Technical Requirements
      1. Devices must use the following Operating Systems: Android 2.2 or later, iOS 4.x or later.
      2. Devices must store all user-saved passwords in an encrypted password store.
      3. Devices must be configured with a secure password that complies with ’s password policy. This password must not be the same as any other credentials used within the organization.
      4. Only devices managed by IT will be allowed to connect directly to the internal corporate network.
      5. These devices will be subject to the valid compliance rules on security features such as encryption, password, key lock, etc. These policies will be enforced by the IT department using Mobile Device Management software.
    2. User Requirements
      1. Users may only load corporate data that is essential to their role onto their mobile device(s).
      2. Users must report all lost or stolen devices to IT immediately.
      3. If a user suspects that unauthorized access to company data has taken place via a mobile device, they must report the incident in alignment with ’s incident handling process.
      4. Devices must not be “jailbroken” or “rooted”* or have any software/firmware installed which is designed to gain access to functionality not intended to be exposed to the user.
      5. Users must not load pirated software or illegal content onto their devices.
      6. Applications must only be installed from official platform-owner approved sources. Installation of code from untrusted sources is forbidden. If you are unsure if an application is from an approved source contact IT.
      7. Devices must be kept up to date with manufacturer or network provided patches. As a minimum patches should be checked for weekly and applied at least once a month.
      8. Devices must not be connected to a PC which does not have up to date and enabled anti-malware protection and which does not comply with corporate policy.
      9. Devices must be encrypted in line with ’s compliance standards.
      10. Users may must be cautious about the merging of personal and work email accounts on their devices. They must take particular care to ensure that company data is only sent through the corporate email system. If a user suspects that company data has been sent from a personal email account, either in body text or as an attachment, they must notify IT immediately.
      11. The above requirements will be checked regularly and should a device be non-compliant that may result in the loss of access to email, a device lock, or in particularly severe cases, a device wipe.
      12. The user is responsible for the backup of their own personal data and the company will accept no responsibility for the loss of files due to a non compliant device being wiped for security reasons.
      13. (If applicable to your organization) Users must not use corporate workstations to backup or synchronize device content such as media files, unless such content is required for legitimate business purposes.

      *To jailbreak/root a mobile device is to remove the limitations imposed by the manufacturer. This gives access to the operating system, thereby unlocking all its features and enabling the installation of unauthorized software.

    3. Actions which may result in a full or partial wipe of the device, or other interaction by IT
      1. A  device is jailbroken/rooted
      2. A device contains an app known to contain a security vulnerability (if not removed within a given time-frame after informing the user)
      3. A device is lost or stolen
      4. A user has exceeded the maximum number of failed password attempts
    4. Use of particular applications which have access to corporate data
      1. Cloud storage solutions: Company X supports the use of the following cloud storage solutions xxxxxx
      2. The use of solutions other than the above will lead to a compliance breach and the loss of access to the corporate network for the user

—————————End of example—————————————

 

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

ISO 27001:2013 A.6.2.2 Teleworking

by Pretesh Biswas

Teleworking is a practice in which an employee works at a location—usually, but not always, one’s home—that is remote from the actual business facility at which he/she is employed. Under this arrangement, the employee maintains close contact with coworkers and supervisors via various forms of computer, Internet, and communication technology (i.e, electronic mail, telephone, computer disks, etc.). Teleworking is an increasingly popular work option in many businesses and industries, and its usage is expected to increase in the future, boosted by new innovations in computer and communication technology. This trend is driven by several factors. The reason for teleworking is that the labor pool of employees with specific talents is shrinking, making employers more willing to make concessions to keep valued employees happy. A smaller labor pool combined with an increasing demand for highly skilled laborers has fueled employee-driven change in working environments. Scarce, highly skilled workers have begun to demand more flexible work arrangements, especially as they choose to live farther and farther from their employers.The new generations of workers are less willing to sacrifice time with family than their counterparts of previous eras. This desire to spend more time at home and avoid long commutes is touted as a key factor in making telecommuting an attractive benefit. Finally, new technologies have made working from home a viable alternative. With the advent of high speed modems, fax machines, voice mail, powerful personal computers, electronic mail and the like, workers can now perform their jobs without losing touch with employers and customers.

ADVANTAGES OF TELEWORKING

Both employers and employees have found teleworking to be a mutually beneficial arrangement in many instances. Proponents cite several positive factors in particular:

  1. Happier employees. Teleworking arrangements can help workers realize a general improvement in their personal “quality of life.” They avoid long, stressful commutes, thus gaining more time for pleasurable activities and more flexibility for changeable tasks like child and elder care.
  2. Increased retention of valued employees. Many businesses lose workers when those employees undergo significant life changes, such as starting a family or relocating to another region or state because of a spouse’s career. Teleworking is one way in which a business may be able to continue to utilize the services of an otherwise unavailable worker. It is also touted as a tool that permits workers to minimize use of “personal days” in instances where they have to stay home and care for a sick child, etc.
  3. Increased employee productivity. Business studies and anecdotal evidence both suggest that employees are often much more productive at home, where “drop-in” interruptions and meetings are not distractions. Instead, the teleworker can focus on the job at hand. Of course, productivity at home is directly related to the employee’s level of self-discipline and abilities.
  4. Cost savings. Businesses can often gain significant savings in facilities costs like office space and parking space requirements when staff members telecommute.

DISADVANTAGES OF TELECOMMUTING

But while telecommuting programs have been highly successful for many businesses of all shapes, sizes, and industry orientations, there are potential pitfalls associated with them. Commonly cited drawbacks include the following:

  1. Lack of oversight. Direct supervision of teleworkers is not possible.
  2. Diminished productivity. Some people are unable to be productive in at-home work settings, either because of family distractions or their own limited capacity to focus on tasks when more pleasurable activities (bicycling, gardening, watching television, etc.) beckon.
  3. Security problems. “The remote access needs of telecommuters and other mobile staff … create a hole in security walls with every connection,” cautioned Kevin McNeely in Providence Business News. “Procedures should be implemented to allow employee access while keeping out unwanted intruders. This includes periodically updated password protection and informing employees concerning the need for remote access security.”
  4. Isolation. “The freedom of working alone comes with a price—the burden of solitude,” commented one executive in Association Management. “We all have wished for days where people would just leave us alone, and with telework, we get our wish—in spades.” Partial teleworking arrangements, in which the employee spends a portion of each week (1-3 days) in the office and the remainder working from home, can sometimes be an effective means of addressing this problem.
  5. Erosion of company culture and/or departmental morale. Many businesses include certain employees who have a major positive impact on the prevailing office environment. When these employees enter into telecommuting programs, their absence is often deeply felt by the staff members left behind. In some cases, this departure from the company’s everyday operations can even have a deleterious effect on the operation’s overall culture.
  6. Loss of “brainstorming” ability. “Given that much of the value added to the production process in Western economies is at the ‘knowledge’ end of the spectrum, the dispersal of brains could be a problem,” wrote Richard Thomas in Management Today. “The informal bouncing around of ideas is difficult, or even impossible, without the face-to-face contact of a shared workplace.”
  7. Perceived damage to career. A common perception among employees of businesses that embrace teleworking options is that telecommuters are placed at a disadvantage in terms of career advancement and opportunity. Certainly, some professional avenues—such as supervisor positions—may be shut off to workers who want to continue telecommuting, but employers should make every effort to avoid an “out of sight, out of mind” perspective from taking shape.
  8. Legal vulnerability. Some analysts have expressed concern that some employer liability issues regarding telecommuting practices have yet to be completely settled. They cite issues such as employer liability for home-office accidents under common law; applicability of the employer’s  insurance  coverage when they work at home; and responsibility for equipment located in the home as particular concerns.

A.6.2.2 Teleworking

Control

A policy and supporting security measures should be implemented to protect information accessed processed or stored at teleworking sites.

Implementation guidance

Organization allowing teleworking activities should issue a policy that defines the conditions and restrictions for using teleworking. Where deemed applicable and allowed by law, the following matters should be considered:

  1. the existing physical security of the teleworking site, taking into account the physical security of the building and the local environment;
  2. the proposed physical teleworking environment;
  3. the communications security requirements. taking into account the need for remote access to the organization’s internal systems. the sensitivity of the information that will be accessed and passed over the communication link and the sensitivity of the internal system;
  4. the provision of virtual desktop access that prevents processing and storage of information on privately owned equipment;
  5. the threat of unauthorized access to information or resources from other persons using the accommodation. e.g. family and friends;
  6. the use of home networks and requirements or restrictions on the configuration of wireless network services;
  7. policies and procedures to prevent disputes concerning rights to intellectual property developed on privately owned equipment;
  8. access to privately owned equipment (to verify the security of the machine or during an investigation),which may be prevented by legislation;
  9. software licensing agreements that are such that organizations may become liable for licensing for client software on workstations owned privately by employees or external party users;
  10. malware protection and firewall requirements.

The guidelines and arrangements to be considered should include:

  1. the provision of suitable equipment and storage furniture for the teleworking activities, where the use of privately owned equipment that is not under the control of the organization is not allowed;
  2. definition of the work permitted. the hours of work. the classification of information that may be held and the internal systems and services that the teleworker is authorized to access;
  3. the provision of suitable communication equipment, including methods for securing remote access;
  4. physical security:
  5. rules and guidance on family and visitor access to equipment and information;
  6. the provision of hardware and software support and maintenance;
  7. the provision of insurance;
  8. the procedures for backup and business continuity;
  9. audit and security monitoring;
  10. revocation of authority and access rights, and the return of equipment when the teleworking activities are terminated.

Other Information

Teleworking refers to all forms of work outside of the office, including non-traditional work environments, such as those referred to as “telecommuting”, “flexible workplace”. “remote work” and “virtual work” environments.

Establishing teleworking

Allowing employees to work away from the office, i.e., outside of the physical premises of the organization (otherwise known as “teleworking”) is becoming a common practice in the way to do business today. The ability to work remotely is seen as both a source of incentive for an employee’s productivity and cost savings for organizations, not to mention the possibility for the organization to reach the right professional it wants in any part of the world. But, this scenario of information outside the direct control of the organization also poses significant risks to information security that should be handled properly. The characteristics of teleworking is

  • The worker is outside of the organizations environment.
  • Information and communication technologies are used to stay linked to the office.

Considering this, we can have these possible scenarios for teleworking:

  • People are working from home or from a place that neither is their home or the organization (e.g., coffee shops, hotels, planes, etc.).
  • People are using fixed or mobile devices (e.g., PCs, notebooks, tablets, smartphones, etc.).
  • People are using public or private communication networks (e.g., Internet and Extranet).

Knowing these scenarios is critical to identify the most probable situations that can put your information at risk. From the scenarios previously presented, an information security risk assessment  could raise the following risks:

  • An employee’s family or friends can use the device accessing the organization’s systems and see sensitive information.
  • Hardcopy material used at the remote work site can be lost or stolen.
  • The device itself can be lost or stolen.
  • A device lost or stolen can be used to gain unauthorized access to the organization’s systems.
  • Information can be intercepted during transmission between the organization and the device.
  • An outdated device can be compromised and used to invade the organization’s systems.
  • Information could be copied and extracted from the organization’s environment without anyone knowing.he communication channel can be intercepted and used to invade the organization’s environment.

It’s important to note that, although all devices are at risk of being lost or stolen, the nature of mobile devices (e.g., size, portability, and value) increases this risk. An organization can establish the rules for the implementation of safeguards to protect information accessed, processed, or stored outside the organization, such as:

  • who may telework (e.g., IT staff, sellers, managers on travel, etc.)
  • which services are available for teleworkers (e.g., development environment, invoicing systems, etc.)
  • which information can be accessed through telework (e.g., performance dashboards, list of customers, etc.)
  • which access controls shall be applied before access to information and resources is granted (e.g., password, two-factor authentication, use of VPN on communication channels, etc.)
  • how devices and remote sites should be configured, protected, and used (e.g., devices with cryptography, no use of shared rooms to work, information backup, etc.)

Additionally, by implementing an information security awareness, education, and training program based on control A.7.2.2, an organization can structure its efforts to enhance the secure behavior of its teleworkers by instructing them to take safety precautions related to opening emails, setting strong passwords on their devices, and making clear that information compromise related to a lack of caution could result in disciplinary proceedings and even legal action. No matter in what industry you work, at some point your organization, or at least part of it, will start relying on telework. The connectivity provided by information and communication technologies not only allows employees to work from anywhere, increasing productivity and improving response time, but also enables organizations to count on trained professionals from anywhere in the world. But, by exposing your infrastructure, systems, and information in this way, an organization needs to take precautions for the high risks involved, and with the help of the requirements of ISO 27001 for information security risk management, and the security controls of its Annex A, this task can become less complex and allow you to take full advantage of teleworking with the least risk.

Implementing a Telework Program

  1. Identify a Telework Coordinator
    If you plan to implement telework with 10 or more employees, it is recommended to identify one employee as the telework coordinator. This person should manage the overall telework program to help improve the quality and effectiveness of your organization’s program. The telework coordinator, typically an individual in human resources, is responsible for organizing teleworker schedules, arranging proper equipment for each teleworker, tracking program progress and promoting the benefits of telework among employees.
  2. Establish a Telework Committee
    The first action for the telework coordinator is to establish a planning committee composed of representatives from human resources, legal, information technology and management. This group can help establish program goals, objectives, written policies and procedures and develop an implementation plan and schedule with milestones. The telework committee should be responsible for determining the three most important elements of your company’s program: policy, training and evaluation.
  3. Create a Telework Policy
    Good communication is the essential element of a successful telework program and all employees should know the program’s guidelines and expectations. The telework policy should define program parameters, including which positions are best suited for telework. Additionally, the policy should include necessary forms or documentation, including a telework contract/agreement. Below is an outline of the most important elements for a telework plan:
  • General policy statement with program definitions
  • Program goals and objectives
  • Explanation of the process for program participation
  • Review of program benefits
  • Identification of positions or aspects of positions appropriate or not appropriate for a telework arrangement
  • Review of time, pay and attendance issues
  • Sample agreement to be completed by the employee and supervisor
  • Checklist of technology and equipment needs
  • Train Employees and Managers
    Since telework typically involves a cultural change within the organization, each employee and manager should receive training on the telework policy, procedures and techniques for managing remote workers. Discuss work schedules, communication methods, required technology, success strategies and proper organization to ensure all employees are fully aware of what is expected of them when working remotely.
  • Determining Who Should Telework
    One of the major challenges for supervisors is determining who is a candidate for telework. This can be a difficult task, as managers may experience employees who want to telework, but are not the best candidate to do so. Managers also may be concerned that if one person is allowed to telework, all employees will want to telework.
  • Employee Suitability
    A good starting point is to review all positions and employees within your organization and determine which have the most potential as teleworkers. The best way to determine who is best suited for a telework situation is to determine certain criteria to be eligible for telework, and then evaluate each employee’s working style against these criteria. Those employees who are highly focused, self-sufficient, flexible, have great organization skills and enjoy the solitude of working at home may be the most adaptable to teleworking. The decision process to grant employees the option to telework could be facilitated by completing a “screening” form that both managers and employees can review and complete together. This process can help the employee understand why he or she may not be a suitable candidate for telework. This form should allow a manager to rate an employee on characteristics that lead to success in telework.
  • Job Suitability
    In addition to determining if an employee possesses the right skills to handle a telework arrangement, managers also need to consider the position or job this person has within the organization. Initially, a particular position may not appear to be compatible with a telework arrangement; however, if the position is broken down into individual tasks, you may be able to identify tasks that could be accomplished in a telework setting. Telework is feasible for:

    • Work that requires thinking and writing, such as data analysis, reviewing grants or cases, and writing regulations, decisions, or reports;
    • Telephone-intensive tasks, such as setting up a conference, obtaining information, and contacting customers; and
    • Computer-oriented tasks, such as programming, data entry, and word processing.

    Positions that are not suitable for teleworking typically require:

    • The employee’s physical presence on the job at all times;
    • Extensive face-to-face contact with their supervisor, other employees, clients, or the public;
    • Access to material that cannot be moved from the main office; and
    • Security issues that prevent the work from being accomplished at an alternative worksite.

    Managers should consider each position thoroughly and determine whether there is potential to create a telework opportunity. As an alternative, the employee may be able to telework one day a week, or half a day for two days a week.

  • Breaking the Cultural Barriers
    A telework program challenges management traditions, as it fundamentally changes how a manager should think about supervising employees. With teleworkers, managers should evaluate an employee’s performance by results, not by physical presence. However, this type of management style brings forth issues of employee trust and empowerment – two key elements of a strong working relationship. Telework also creates the challenge of keeping workers, whether they are teleworking or not, to work as a team to achieve one common goal. Before implementing telework and to help break down any cultural or procedural barriers, managers may need to initiate the following practices to maximize your  effectiveness at supervising teleworkers:

    • Maintain a sense of control even when people are out of sight
    • Develop increased levels of trust and use trust as a purposeful tool
    • Use technology for staying in touch with teleworkers
    • Rethink and redesign the way certain jobs are performed
    • Plan further in advance for meetings and other team activities
    • Focus objectives and expectations on short-term, project-based goals
    • Adopt location-independent ways of measuring performance and results
    • Transition teamwork toward more electronic-based collaboration

    For teleworking to be effective, managers must demonstrate trust and support to teleworkers. Most of the time, the people you trust will live up to that trust and respond to it by exceeding your expectations. While entrusting your employees is vital to an effective telework program, employees who telework must also have trust in you. Some employees fear that not being visible may mean being passed up for promotions or project opportunities. To avoid this, be sure to include teleworkers in all group activities such as staff meetings and recognition events, and ensure that teleworkers are evaluated and rewarded just as equally as non-teleworking employees. Non-teleworking employees also have trust issues that supervisors must consider. They must trust that teleworkers will meet their commitments and be as accessible as if they are in the office. They also need to know that their workload won’t increase with some staff teleworking, and that tasks usually performed at a specific company location will be assigned equally. This concern can be relieved by ensuring that all employees, whether they’re teleworking or not, have access to each other at all times through innovative technology methods. Below are a few tips to help a manager make the right decisions to ensuring telework is successful within the organization.

    • Trust your teleworkers at all times and demonstrate this trust by assigning challenging projects once the employee delivers a strong performance
    • Include teleworks in surveys and evaluations
    • Try teleworking yourself when you have the opportunity. It will help increase your personal effectiveness and improve your understanding of the pros and cons of teleworking
    • Consider your teleworker’s point of view in all situations. Understand the timeframes involved in completing tasks and the resources required to complete them
    • Involve teleworkers when setting work goals and objectives
    • Delegate assignments fairly among teleworkers and non-teleworkers
    • Include teleworkers in day-to-day activities. Be aware of your teleworkers’ attitudes and involvement to ensure they don’t feel isolated from the main office
    • Encourage informal communication within your team to keep teleworkers and co-workers in touch and up-to-date. Consider establishing a “virtual water cooler” via a shared e-mail folder or organizational Intranet
    • Communicate on a regular basis with all technology methods, including phone, e-mail, instant messaging and online meetings
    • Be flexible and open to increasing the frequency of teleworking if it is working well for the employee
    • Keep an open mind about teleworking. Be flexible with the program’s policies and procedures in case they need to be adjusted for any reason
  • Choosing the Right Telework Tools
    Before launching a telework program, an organization should determine a teleworker’s technology needs in order to be just as sufficient working remotely as he or she would be in the main office. There are several technology options to help implement telework, some of which you are already familiar with and others you may need to research further before making the right decision. The inherent  technology needs for a teleworker include the following:

    • Computer
    • Internet connectivity (high-speed broadband is best)
    • E-mail program
    • Telephone
    • Fax machine
    • Collaboration software

    In looking at these necessities, few allow for quality interaction between an employer and teleworker, and they do not address the “myths” or concerns that managers have when considering telework. Management’s highest concern is the fear of having less control over employees who work from home, and not being able to reach a teleworker when you need them. Both of these concerns, among others, can be addressed with a collaboration software program.

  • Consider Collaboration
    By equipping each teleworker and non-teleworker with high-speed Internet, a Web camera, headset and collaboration software, managers can get in touch with teleworkers at all times—and in return, teleworkers can contact managers, employees, vendors and clients. An effective and useful tool, a collaboration program should include such features as real-time video, telephone quality audio and presence detection systems to allow better interaction between the main office and teleworkers. With a collaboration program, the following can be accomplished:

    • Teleworkers can better replicate an in-person meeting and easily contribute to the discussion when joining meetings at the main office via the Internet.
    • Managers can see and hear teleworking employees during online meetings to avoid a fear of loss in productivity.
    • Management and teleworkers can see who is available online for a meeting or quick discussion via instant messaging with the presence detection and status indicators. This will help alleviate the ‘out of sight, out of mind’ concern with managing a remote workforce, as the manager will quickly be able to determine which of their workers are online, offline, in meetings, away from their computer, or do not wish to be disturbed.

    Additionally, a collaboration tool should have more in-depth interactive components of its system to help the teleworker further engage in activities occurring at the main office. Such components include instant messaging, joint editing, whiteboarding, live view, chat and secure file sharing/storing. By harnessing these features, the following can occur:

    • Confidential documents are stored in the application’s secure file cabinets for sharing, rather than the teleworker’s computer
    • Teleworkers can instantaneously communicate with the main office
    • Multiple employees are able to view, discuss and edit documents simultaneously
    • Employees are able to take notes during meetings for all participants to view

    Using a combination of communication methods, such as online meetings, e-mail, fax and phone, will provide a comprehensive telework program.

  • Select a Collaboration Tool
    After establishing specific policies, procedures and measurement methods for your telework program, you should next select the right technology. The most interactive and secure method for communications with teleworkers is a collaboration software program that is designed specifically for your industry and company structure. The following questions can help you select a collaboration tool that best meets your organization’s teleworking needs:

    1. Does the collaboration solution offer everything a teleworker needs to work effectively from home, such as real-time document editing, audio, video, instant messaging, etc.?
    2. Are all the necessary services integrated into one package or would we need to consider other alternatives (and expenses) such as conference calls for the audio?
    3. Will the solution maintain total privacy and confidentiality of video, audio and data?
    4. Does the system use a high level of encryption methods, such as Advanced Encryption Standard (AES)?
    5. How does the provider protect the data and where is it stored?
    6. Does the system operate through firewalls? This is critical when it is important to communicate with external audiences.
    7. Is security included in the overall price of the solution, or is it an add-on cost?
    8. Is education and training about how and when to use the service readily available and/or customized for the teleworker?
    9. What type of support will be available to the teleworker? Is the support included, or must you pay for telephone calls to client services?
    10. What are the contractual arrangements? Does the provider offer one price for multiple participants, sometimes called “seats”?

    The organization find the best solutions for telework, but also find ways to save costs on implementing the program. To minimize technology expenses, look for a collaboration program that allows you to purchase “seats,” which means you can purchase licenses for a group of participants rather than having to pay for each minute you are online using the program for a meeting.

  • Ensuring Security at Home
    Oftentimes, organizations overlook the potential security risks when allowing an employee to work from home. While your office may have security measures in place, your employee’s home may not. The Computer Security Institute, a San Francisco-based association of information security, recently conducted its 10th annual “Computer Crime and Security Survey.” According to the survey, large corporations and government agencies acknowledged more than $130 million of financial losses due to computer breaches. Therefore, it is imperative to consider technology tools that provide stringent security standards to ensure your company’s information is not compromised from a teleworker’s computer.
  • Protect E-mail Systems
    E-mail can still be an effective, easy and paperless way to communicate, but organizations need to understand the threats to security when relying solely on e-mail for communications. For teleworking purposes, your e-mail system should be fully encrypted to avoid security breaches. Additionally, it is helpful to have a junk e-mail folder and virus detections to protect your systems against any potential e-mail viruses. Highly confidential information, such as financials, salary data, strategic plans or budgets, should not be transmitted via unprotected e-mail methods. Opt instead for an encrypted method of sharing and storing sensitive information.
  • Secure Online Meetings
    A collaboration software program provides organizations with a cost-effective method for transferring important files over a secure channel. While most products have security as an addon, others build strong security specifics within the tool to provide better protection. All components of a collaboration tool – including audio, video, data and files – should be protected with the strongest levels of encryption. Some of the security factors you should look for include:

    • Lock-tight password protection
    • Comprehensive encryption system using Advanced Encryption Standard (AES) Public key encryption
    • Encrypted file storage
  • Stay in Control
    Perhaps the most effective way to protect sensitive files is by having the control in your hands. Any form of communication, and specifically a collaboration tool, should provide you with the control to grant employees access to certain information. A collaboration product should let you designate which of your employees has access and to what files, and it should handle details surrounding need-to-know and right-to-know permissions.
  • Secure Networks and Applications
    Lastly, you should consider ways to secure both the network you are transmitting information with and the application being used to communicate. This is especially important for teleworkers who use a wireless network, as the security implications with a Wi-Fi network are still being discovered and the vulnerabilities are endless. Acting as two security layers, if your network is breached and you have a secure application, the hacker can only get access to encrypted files, which prevents the hacker from reaching any confidential information.
  • Launching the Program
    Initially, managers will feel somewhat overwhelmed with the changes and challenges in launching a telework program. However, if you approach this in a gradual fashion, giving time to work through new issues, success is highly achievable. When initiating a telework arrangement, managers need to help employees adapt to this culture change in the beginning stages of implementation. Share information about the program as it is developed, and ensure that employees receive training on the organization’s telework policies, procedures and any new technologies that need to be utilized on a daily basis. Once all employees are given an opportunity to review the telework program and decide if they would like to participate or not, then you should move into launching the program.
  • Maintain Balance
    Once a telework program is underway, it is important to emphasize equality between teleworkers and non-teleworkers. Be sure to communicate frequently with employees in the main office and those who are working remotely to maintain a cohesive team. While managers can maintain communications with conference calls and e-mails, if your organization has a collaboration program, you can also touch base via instant messaging and online meetings. Managers could host regular staff meetings via online, which allows the teleworker to stay involved and included without having to commute to the office. This is especially important if the organization has employees working in another city, state or even overseas, as it would be very costly to transport them to the main office for each staff meeting. Additionally, an online meeting allows the teleworker to not only hear other participants in the meeting, but also see everyone in the meeting, allowing for more quality interaction with managers and employees.
  • Set Expectations
    Before beginning a telework program, managers should clearly define expectations from an employee’s performance before he or she begins working remotely. Focus on results, such as accomplishments, products, or services provided to measure their performance since it will be difficult to observe activities, behaviors or demonstrated competencies. Performance plans also should include standards that are measurable, observable and at least verifiable. Whether an employee works at the main office or at home, they should know what they are supposed to do, and how well they are supposed to do it, in order to ensure successful performance.
  • Monitor Performance
    Monitoring performance includes measuring performance and providing feedback. In a telework situation, measuring the results of employees’ efforts rather than their activities can be more efficient and effective. Quantity, quality, timeliness, and cost-effectiveness are four general measures that should be considered at all times for all employees, whether they work from home or in the office. After establishing performance measures, communicate where an employee stands on performance frequently. Since teleworkers are not in the office to receive quick, informal feedback, make a conscious effort to send an instant message to teleworkers so they know they are doing a good job. During the first few months of implementing the program, managers may experience a few glitches here and there, but once you find solutions for any minor problems, the organization will soon experience benefits such as decreased sick leave from employees, a reduction in workers’ compensation cases and overall improvement in employee morale and productivity.
  • Evaluate the Program
    In order to measure success of the telework program, the telework committee should develop an evaluation plan before implementation. This plan should be based on quantifiable program goals and objectives to measure and compare results. When evaluating the organization’s telework program, it is recommended to first analyze the key  issues that affect the organization, such as productivity, operating costs, employee morale, recruitment and retention. While you also can evaluate external issues impacted by telework, such as traffic flow, air pollution, and mass transit use, these factors are usually evaluated through a community effort by a consortium of interested organizations. There are several measurement strategies managers might want to include in the evaluation plan. For example, compare teleworkers and non-teleworkers on selected measures at one point in time. Also, conduct pre- and post-measurements on the teleworkers alone, analyzing performance before and after they begin working remotely. To evaluate productivity, develop various levels of performance to measure each employee. Identify quantifiable tasks and determine which can be accomplished in an office setting and which can take place via telework. For example, it may take an employee two weeks to write the office newsletter when working in the office, but only one week in the telework setting because of fewer interruptions. To measure operating costs, you should measure sick leave taken, workers’ compensation costs, office space needs, and/or transit subsidy expenses before and after the telework program begins. In addition to these measures on individual employees, anecdotal data may also be helpful. In evaluating the costs of telework, allow sufficient time for implementation before studying costs. In the initial months of telework, there are typically increased costs for logistical support; however additional noteworthy cost savings are normally realized after a sufficient period of time. To evaluate morale, recruitment and retention, managers can utilize focus groups, questionnaires and surveys with employees. For example, ask employees to rate their degree of satisfaction with their working conditions, productivity and telework situation. In addition to looking at overall morale and retention, it is important to measure specific aspects of satisfaction with telework. Similar to measuring costs, it is important to take enough time to evaluate satisfaction with the program, and it may take asking the same questions at several points in time, such as three months, six months, etc. One approach is to develop a small survey asking employees how they believe telework will benefit them before implementation. After six months, ask them to look at the initial survey and identify if they did or did not experience these benefits.

Security Issues for Teleworking

Teleworking is the use of telecommunications to create an “office” away from the established (physical) office. The telecommuting office could be in an employee’s house, a hotel room or conference center, any site an employee travels to, or a telecommuting center. The telecommuter’s office may or may not have the full computer functionality of the established office. For example, an employee on travel may read email. On the other side of the spectrum, an employee’s house may be equipped with ISDN and the employee may have full computer capability at high speeds.. Teleworking is becoming accepted as the way to do business. However, opening up corporate systems to dial-in and other forms of access presents three significant security risks.

  1. The first risk is that intruders will be able to access corporate systems without having to be on site. Hackers armed with war dialers, electronic eavesdroppers at conference sites, or shoulder surfers watching employees enter IDs and passwords are all very real threats in today’s environment. In addition to intruders whose goal may be mischief, hacking is attractive to people trying to steal or misuse corporate information. Electronic access to records is often more anonymous than trying to bribe employees or gain physical access.
  2. A second risk of telecommuting, closely related to the first, is that corporate information can be read, and potentially modified, while it is in transit.
  3. Telecommuting also presents organizations with more pedestrian risks. These include the risk of losing corporate information and resources when they are outside the protective shell of the organization.
  1. Security Issues for Protecting Internal Systems
    In planning for the security of telework, the first step is to examine what type of access is needed. What systems and data do employees need? What is the sensitivity of these systems and data? Do they need system administrator privileges? Do they need to share files with other employees? Is the data confidential? From a security perspective, the critical determinations are:

    • What would happen if an intruder gained the same access as the employee?
    • What would happen if an intruder were able to use the employee’s account, but gain more access than authorized for that user?

    If the answer to either of these questions is “uh-oh,” then security is important.

    1. Firewalls/Secure Gateways
      A secure gateway, often called a firewall, blocks or filters access between two networks, often between a private network and a larger more public networks such as the Internet or public switched network (i.e., the phone system). For telecommuting, the trick is to decide what to make available to telecommuting employees using public networks, what degree to ensure that only authorized users can get to the internal network, and how to ensure that the secure gateway works properly. If possible, it can be more secure to put all the resources needed by telecommuting employees outside of a secure gateway. However, this is only possible if employees do not need access to corporate databases. For example, employees may only need to send reports in or access public databases, such as product/sales information or government forms. However, most telecommuting employees will need more access. For traveling employees, this may be limited to needing email. There are many firewall implementations that use a email proxy to allow access to the files on a protected system without having to directly access that system. Once again, many telecommuting employees will need more access. They need access to internal resources. The employees may need to use a variety of resources such as LAN applications, mainframe applications, run client software, use TCP/IP services. A secure gateway, or series of gateways, can be used to divide internal resources based on access need of telecommuters. For example, computers with high-risk organizational data (such as proprietary business plans) may be separated by router from systems with a lower level of risk.
      A series of routers can be used to further restrict access to the highest-risk systems. For some situations, current firewall technology can be used to give virtual access by using proxies. In addition, current firewall can use IP filtering to permit access to only certain types of resources. However, for many organizations, the primary security function of the secure gateway is to provide robust authentication of users. Secure gateways may also provide additional auditing and session monitoring. The gateway can perform an intrusion detection function. For example, the secure gateway could monitor a session for keystrokes which may indicate someone trying to exceed access.
    2. Robust Authentication
      For most organizations, robust authentication should be required if access is given to internal systems. However, many organization should require robust authentication even for email if it is relied to discuss business decisions (i.e., if the organization would care if someone else read your email). Robust authentication can increase security in two significant ways: 1) It can require the user to possess a token in addition to a password or PIN and 2) it can provide one-time passwords. Tokens when used with PINs provide significantly more security than passwords. For a hacker or other would-be impersonator to pretend to be someone else, the impersonator must have both a valid token and the corresponding PIN. This is much more difficult than obtaining a valid password and user ID combination (especially since most user IDs are common knowledge).
      Robust authentication can also create one-time passwords. Electronic monitoring (eavesdropping or sniffing) or observing a user type in a password is not a threat with one-time passwords because each time a user is authenticated to the computer, a different “password” is used. (A hacker could learn the one-time password through electronic monitoring, but it would be of no value.)
      Most commercial robust authentication systems use smart tokens. The user provides a PIN which unlocks the token and then uses the token to create a one-time password. However, it is possible to use software-only one-time password schemes. (Tokens which do not provide for one-time passwords, such as ATM cards, are less common for telecommuting because they require hardware at the remote site and, without physical security, are vulnerable to electronic monitoring.)
      Telecommuting employees who directly access internal systems should be robustly authenticated and should be routed to specific computer systems. The combination of routing and robust authentication can greatly increase security and reduce the costs associated with robust authentication by limiting it to employees with the greatest access.
    3. Port Protection Devices
      A port protection device (PPD) is fitted to a communications port of a host computer and authorizes access to the port itself, prior to and independent of the computer’s own access control functions. A PPD can be a separate device in the communications stream, or it may be incorporated into a communications device (e.g., a modem). PPDs typically require a separate authenticator, such as a password, in order to access the communications port. One of the most common PPDs is the dial-back modem. A typical dial-back modem sequence follows: a user calls the dial-back modem and enters a password. The modem hangs up on the user and performs a table lookup for the password provided. If the password is found, the modem places a return call to the user (at a previously specified number) to initiate the session. The return call itself also helps to protect against the use of lost or compromised accounts. This is, however, not always the case. Malicious hackers can use such advance functions as call forwarding to reroute calls.
  2. Security Issues for Data Transfer
    In addition to intruders possibly gaining access to internal systems, it is also possible to eavesdrop on an entire session. Eavesdropping is not technically difficult if there is physical access to cable or wire used for communication or logical access to switching equipment. If a telecommuting employee will be transferring data for which someone would go to the trouble of eavesdropping to get, then encryption may be necessary. Another scenario when eavesdropping is more likely is if an employee is at a large conference or other location where an eavesdropper may set up equipment in hopes of hearing something useful. Some conferences offer equipment to attendees to use to check email, transfer files, etc. This is useful to attendees, since they do not need to provide laptops; however, this could be a target for electronic eavesdropping. Software- or hardware-based encryption provides strong protection against electronic eavesdropping. However, it is more expensive (in initial and operating costs) than robust authentication. It is most useful if highly confidential data needs to be transmitted or if even moderately confidential data will be transmitted in a high threat area. It is, however, unlikely that employees will always know when they are in a high threat area. It is incumbent on management to train employees.
  3. Security Issues for Telecommuting from Home
    Many employees telecommute from home, which raises an additional set of
    issues. Some of these concerns relate to whether employees are using their own computers or using computers supplied to them by the organization.

    1. Home Data Storage Integrity and Confidentiality
      Other members of the employee’s household may wish to use the computer used for telecommuting. Children, spouses, or other household members may inadvertently corrupt files, introduce viruses, or snoop. Organizations can take several approaches:

      1. Employee accountability. Some organizations may choose not to have specific rules forbidding household members from using PCs, but hold the employee responsible for the integrity and confidentiality of the data. Obviously, this is not a good choice if the data is highly confidential.
      2. Removable hard drives. If corporate data is stored on a removable hard drive (or floppy), then the risk is greatly reduced.
      3. Data encryption. Corporate data can be kept encrypted on the hard disk. This will protect its confidentiality and will detect changes to files.
      4. Dedicated use. If an organization requires this, it should recognize that it is difficult to enforce.
    2. Home System Availability
      In addition to the possibility of a home computer breaking or being stolen, it may not be compatible with office configurations. For example, the home computer may use a different operating system. This may complicate set up, software support, troubleshooting, or repair. It is in the best interest of the organization to ensure that policy covers all these situations.
  4. Security Issues for Telecommuting Centers
    Telecommuting centers, normally located in outlying suburbs, are another choice for organizations. From a security perspective they may offer hardware for encryption, removable hard drives, and increased availability. However, by concentrating telecommuters, they may make themselves a more attractive target for eavesdropping. At a minimum, organizations should require robust authentication from telecommuting centers. If communications encryption is supported by the center, organization should be aware that data may not be encrypted while it is inside the center. The encryption may occur at a modem pool.

Teleworking – the threats

With the increased freedom afforded us by teleworking there also comes increased information risk. The risk may be considered in two layers – the risk at the remote PC and the risk at the corporate network.

  1. Exposure of remote PC on Internet
    The teleworker’s PC cannot be protected by the company at all times. When not connected to the office network, the teleworker’s PC will be used for Web surfing, new software will be installed, old software reconfigured, e-mail attachments opened and Internet files downloaded. Hence, the system build is clearly not compliant with the corporate standard, which raises questions on the effectiveness of any security software running on the remote PC, and the risk of virus infection is increased. There is also the risk of physical access to corporate information stored on the remote PC. A corporate PC is situated within the office premises, where it is generally protected by multiple layers of building access controls, 24 hour on-site security personnel and surveillance equipment (for larger companies, at least.) On the other hand, the remote PC is likely to have only one layer of physical access control (ie., the front door) and is unlikely to have 24 hour on-site protection or surveillance. The risk of the PC and/or the information it contains being stolen or otherwise exposed is hence increased. All of this activity is generally restricted by the company security policy but this cannot be enforced on a private PC. Hence, when the user next logs in to the office, the damage may already have been done – information may already have been accessed directly from the remote PC, and/or a compromised/infected PC becomes part of the office network.
  2. Exposure of corporate resources on Internet
    Consider the nature of the access required by a teleworker. The aim is to allow them to work from home as effectively as they might in the office. Hence, they need access to the data available in the office environment. This may require mapping network drives to the remote PC, access to confidential databases, intranet web servers, or corporate applications. Ordinarily, these services would never be made available outside the corporate network. In fact, the teleworker’s remote PC effectively becomes part of the corporate network but it sits outside the traditional network perimeter and information defences. Hence, by extending the network to the teleworker’s home via the Internet, the risk of these services being exposed on the Internet is increased. The exposure may be direct or indirect – direct to the Internet by presenting service interfaces at the corporate network perimeter and transmission of corporate information over public lines; or indirect by use of the remote PC to bridge between the Internet and the corporate network. Direct exposure can be mitigated by strong identification, authentication and authorisation at the corporate firewall or DMZ and the use of encryption technology to protect data integrity and confidentiality. (Typically, a virtual private network [VPN] is employed to provide aspects of all of the above.) Indirect exposure can be mitigated by protecting the remote PC by deploying standard security measures on the PC but, as discussed above, the security status of the remote PC cannot be guaranteed and hence the corporate network must be protected against a compromised remote PC.
    Let us look at the following example. The typical home broadband connection will connect the teleworker to both the Internet and the corporate network. Hence, the possibility exists for a hacker to access corporate resources via the remote PC. Malicious IRC Bots, commonly known as Zombies, are a particularly dangerous example of how a hacker might create such a bridge. Zombies are modified Trojan horse viruses which act as IRC (Internet Relay Chat) agents. The machine is typically infected by opening a file posted to a chat room or via an e-mail attachment. Once the infected PC is booted, the Zombie will attempt to “phone home” to an IRC server, announcing its availability to the hacker who distributed it. It will provide details of the IP address and port on which it can be contacted. The hacker can then contact the Zombie via the IRC channel and tell it to launch denial of service attacks on any given IP address. With hundreds or possibly thousands of these Zombies available to a hacker, massive distributed DoS attacks are possible. It is worth noting that broadband, always-on connections are particularly sought after by the Zombie hacker community and hence are more likely to be targeted for further investigation if the machine becomes infected. The hacker will often use the Zombie to download the Sub7 Server Trojan. Once installed, Sub7 will also attempt to connect to the Internet and post its connection details to an IRC server or via e-mail. If successful, the hacker now has access to watch everything that is happening on the infected PC and can even take control of the machine, run applications, download and upload files, restart Windows, and so on. The complete list of Sub7’s functionality is impressive but frightening – just about anything is possible. Obviously, if a telecommuter’s PC was to be infected by such a Zombie, the hacker may have direct access to the corporate network every time the user logs in. Even if the PC is default configured to prevent simultaneous Internet and corporate access  the power of Sub7 could allow the hacker to reconfigure or to install software to workaround that protection. Sub7 is also capable of logging keystrokes even while the hacker is not connected to the compromised PC. The keystroke log can then be downloaded at the hacker’s leisure. Hence, the teleworker’s activity could be monitored even if the hacker is locked out of the system while it is connected to the corporate network.

Mitigating the threats

As demonstrated there are some very real security issues to be considered around teleworking. These issues are wide-ranging – the accidental introduction of viruses to the office environment; increased exposure to Internet attacks; even acting as a backdoor into the heart of the corporate network. To protect against these issues, security must be taken seriously by the teleworker and his or her company. The remote PC must be protected against the Internet and the corporate network should be protected from the remote PC. This final section discusses the vital areas which must be tackled in protecting the teleworker and the company.

  1. Security Policy

    As ever, good security begins with the security policy. Security policy must cover telecommuting/teleworking. In particular it should consider –

    • who may telework – identify the roles/jobs which may be considered for teleworking
    • services available to teleworkers – the types of network and application services which may be provided to teleworkers
    • information restrictions – are there classified information types which should not be made available to teleworkers?
    • Identification/authentication/authorisation – how should teleworkers be identified, authenticated and authorised before accessing corporate resources
    • Equipment and software specifications – are there any specific equipment or software products which must be deployed on the teleworker’s PC? (eg., firewall or encryption software)
    • Integrity and confidentiality – consider how the connection to the remote PC should be protected (ie., VPN) and how data on the machine should be protected
    • Maintenance guidelines – how should the teleworker’s PC configuration be protected, updated and monitored?
    • User guidelines – clarify the user’s role in protecting corporate resources – eg., appropriate use of resources; user should not modify security configurations; use of anti-virus software; storage of corporate data on local drives; use of encryption tools
    • User education – ensure that users understand the possible information risks associated with teleworking, how those risks are addressed, and the user’s role in minimising the risks
  2. User Education
    User education is essential. Users must understand that teleworking does entail genuine security risks and that they have a role to play in protecting corporate resources from attack, damage or loss. It is also to their own benefit that they understand the risks to their own PC and private data of their behaviour while accessing the web in their own time, and how to mitigate those risks.
  3. Protect the remote PC
    The remote PC must be protected from the Internet and corporate information stored locally should be protected from prying eyes. (Note, however, that ideally corporate information should not be stored on the teleworker’s own PC – this should be considered in the security policy.)

    1. Firewalls
      The corporate perimeter defences need to be extended to bring the remote PC within the perimeter – ie., firewall software should be installed on the remote PC. However, there are several issues around the effectiveness of the firewall. The firewall software must be properly maintained – this means software patches must be implemented as appropriate and the firewall must be correctly configured. Bear in mind that the remote PC probably belongs to the user and hence he or she has full administrator access to the machine – the system configuration may change regularly which could leave the firewall disabled. Hence, you should consider implementing an automated audit process when the user logs into the corporate network. This audit should check that the software is operational, correctly configured and that patches have been applied. If necessary, patches should be applied before allowing the user to continue. There is also the question of the choice of firewall product. There are certainly home firewall products which are effective in blocking uninvited inbound traffic. However, there are also products which will allow most or all outbound connections, opening the PC up to the Zombie attack discussed earlier, for example. Hence the firewall product should preferably be capable of monitoring and blocking all network traffic from applications which have not been specifically authorised to access the network/Internet. The user’s education should include an understanding of the role played by the firewall and how important it is that the firewall is running correctly. The user should be encouraged to have the firewall running whenever they are connected to the Internet, even when not connected to the corporate network. This will help to protect the user’s own files and ultimately protects corporate resources. A home firewall is an essential precaution on the remote PC. However, designing a standard configuration which is maximally effective for every home PC is essentially impossible. Manual configuration could be considered but this could prove time consuming and expensive if it is to be handled by qualified personnel, while most end users do not have the experience to handle this unaided. Hence, it should not be assumed that the remote firewall is fireproof. Multiple layers of security will be required – strength in depth is the key.
    2. Virus protection
      Anti-virus software is an essential measure on any web user’s PC, whether or not they telework. As per the firewall, the anti-virus product must be properly maintained – the software must be patched as and when necessary, the virus definition files must be regularly updated, and the software must be configured correctly. It should be configured for automatic scanning of e-mails and files opened. Entire system scans should be performed at regular intervals. Again, it is possible that the software could be disabled as a result of user action. Hence, consider performing an automatic audit of the virus software at login, ensuring that the software is running, that definition files are up to date and that patches have been applied. If possible, check the time of the last system scan. New definition files or patches should be applied and the last system scan should be confirmed as recent before the user is allowed to continue. The user’s education should include an understanding of the importance of the antivirus software and the correct operation of the product. Teach good practice in the handling of downloads and attachments. The user should be encouraged to keep the product operational at all times, whether connected to the Internet or not.  However, it is always possible that a virus will be missed by the software and the remote PC will be infected anyway, spreading to the corporate network at the next login. To counter this possibility, consider running anti-virus software in the DMZ back at the office.
    3. Data protection
      If corporate data will be stored on the remote PC, then it should be protected by encryption software. There are packages which will encrypt disk partitions or individual files as required. If the data will be stored on removable media then not only should it be encrypted but it should also be removed from the PC and locked away when not in use. Also, bear in mind that information security does not only refer to protection from deliberate attack or theft. Information can be lost due to hardware or media failures and hence backups should be kept. Since the typical home PC is unlikely to have an automated backup network attached, the teleworker should be careful to make backups as required. Also, information security is about availability. Information stored on the remote PC is not likely to be available from the office. For these reasons, it is preferable that corporate information should be stored on the corporate network and not at home.
  4. Protect corporate resources from the Internet
    If the remote PC is compromised by a hacker and/or infected by a virus, then the corporate network is at risk. Alternatively, the link between the remote PC and the office could be compromised directly. Hence, precautions should be taken to control the PC’s access to corporate resources and to monitor the contents of the traffic.

    1. Identify, authenticate and authorise remote connections
      It is vital that only authorised personnel are able to access corporate resources remotely. All attempts to connect to corporate services should be captured within the DMZ until the source of the connection has been identified and authenticated. Strong authentication technology should be employed. At the least, this should be strong passwords – ie., of appropriate length, not easily guessed, and containing non-alphanumeric characters. These requirements should be enforced automatically. Given that Trojans such as Sub7 can provide a hacker with your userID and password, you should also require that passwords are changed frequently. One-time password technologies make it almost impossible for the hacker to steal a usable password, and hence these technologies are far preferable. Typical one-time password technologies involve the use of a password combined with a passcode. The passcode is generated using an electronic token, and is based on a hash generated from the current time or from a randomly generated challenge provided by the corporate authentication server. Since the hacker does not have access to the token he or she cannot reply with the correct passcode and hence cannot be authenticated. Once identified and authenticated the user should be permitted access only to services and resources for which they have been authorised. This is particularly important in order to protect against the possibility of a hacker compromising the remote PC and posing as the authenticated user. Ideally, each individual service/resource request will be authorised separately, rather than simply allowing access to an area of the corporate network. It is only if the user’s access rights are understood at this level of detail that the inappropriate behaviour of a hacker might be effectively identified.
    2. Protect the remote link
      The remote link should be protected against surveillance and interference by the use of VPN tunnel technology. VPN creates a secure link (known as a tunnel) between the remote host and corporate DMZ. Data confidentiality is protected by encrypting the payload of the TCP/IP packets in transit. Data integrity is ensured by including a hash of the payload in the header. Source and target IP addresses on the private networks are also protected. Since no unauthorised party can read or interfere with the payload, we effectively have a secure tunnel through the public network. The use of VPN’s is becoming very popular as a solution for secure teleworking communications. However, it should be remembered that the VPN only protects the data in transit and is not an entire solution in its own right. It is essential to protect against unauthorised VPN connections to the corporate network, and to monitor/authorise remote behaviour via the VPN connection in case it has been hijacked. The configuration of the VPN client on the remote PC is also essential. In particular, the risk of bridging between the Internet and the corporate network can be minimised by configuring the VPN to disable access to the Internet while connected to the corporate network. In this mode, while VPN is active, the PC’s default route is to the VPN server at the office and the Internet is not visible. Similarly, communications services on the PC are not made available on the Internet.
  5. Protect corporate resources from the remote PC
    1. Monitor traffic and behaviour
      VPN technology is a powerful tool to ensure integrity and confidentiality of data on the remote link. However, if the user’s PC is compromised, then the VPN tunnel allows the cracker, posing as the authenticated user, direct access to the corporate information network, and may actually be effective in disguising the cracker’s behaviour. Hence, it is important that the VPN is terminated within a DMZ. The external firewall, facing the Internet, will authenticate and authorise the connection to the telecommuter’s machine. However, data packets are encrypted within the VPN and hence the cracker’s activities are disguised at this firewall. Beyond the end of the VPN, network-based IDS should be deployed before the internal firewall in order to monitor the user’s activity. This should watch for unusual or inappropriate behaviour, such as network activity outwith the user’s typical working hours, uploading or downloading of large amounts of data, or the use of network scanning tools. The use of SSL to access the corporate intranet over VPN should also be considered carefully. Since SSL is encrypted “end-to-end”, it may be used to hide a cracker’s activity. Hence, the use of web proxies should be considered. The proxy should be located within the DMZ, and the IDS should monitor the intranet traffic.Also, the teleworker’s network traffic should be scanned for viruses within the DMZ. This will help to protect the office network from any virus which may have slipped past the scanners on the remote PC.
    2. Restrict remote service functionality at source
      In some cases there is no better protection than to prevent access to a service or resource altogether. For example, some corporate databases or internal applications may be considered too sensitive to risk any form of external access. Any such application or information should be carefully segregated from the remote access systems by appropriate use of access control and authorisation systems, network firewalls and IDS. Some degree of control over the movement of data to and from the corporate network can also be provided by thin client technology such as Citrix WinFrame/Meta Frame or Microsoft Windows Terminal Server. Thin client technology allows the remote PC to act as an interactive “window” onto the corporate network, without providing direct access to the network. For example, applications such as word processors, spreadsheets, databases, and so on, can be run on the corporate server while making their user interface (text or GUI) available on the remote PC. The teleworker can see and interact with the application but all processing is performed on the office server, and the data files remain on the corporate network. In this way, the teleworker can access information and even create/update information without having access to download large amounts of data or upload malware. (Note that the thin client server must be configured correctly to ensure that files cannot be downloaded to the remote PC or uploaded to the server. Thin client servers generally provide the capacity for file transfer if required.) The protection provided is limited – files can be updated or contents entirely deleted, while macro viruses could be cut and pasted into a document. However, it does limit the damage that can be done in a given time.
    3. Refuse remote access if necessary
      Bear in mind that it may be necessary to completely refuse remote access. This may a blanket ban across the entire firm. Or simply a restriction on the job roles which may request remote access – eg., individuals handling cash transfers cannot use remote access, and so on. The key to making this decision, as ever, is to weigh the benefits of remote access against the perceived risks and impact.

AN EXAMPLE TELECOMMUTING POLICY

The following can be used as a template for your organization if you are considering implementation of telecommuting or teleworking as a powerful recruitment and retention tool. Consider the specifics of your own organization and follow the normal review protocols used for implementation of a new policy to ensure that it meets your organizational needs and complies with all current internal policy and external legislation.

1. Policy Statement

As stated in its Policy on Equal Opportunities: ‘the Organization confirms its commitment to develop, maintain and support a comprehensive policy of equal opportunities in employment within the Organization’. To assist in this the Organization will actively support Teleworking where it is reasonable and practical to do so and where operational needs will not be adversely affected.

2.  Definition of Teleworking

Telework is defined as working at home or at other off-site locations that are linked electronically (via computer, fax, etc.) to a central office or principal place of employment. Teleworking is a cooperative arrangement between the Organization and an employee, based upon the needs of the job, work group, and the Organization. This policy does not apply to situations where a supervisor occasionally allows an employee to work at home on a temporary, irregular basis.

3. Aims and Objectives

The Organization is committed to equality of opportunity for all its staff regardless of the number of hours worked. In order to facilitate this the Organization may create working arrangements, in accordance with managerial interests, whereby it can widen its recruitment pool and retain the valuable skills of existing employees.

4.  Eligibility

To be eligible for consideration of a telework arrangement, an employee must have no record of performance problems or disciplinary actions within the preceding two (2) years. In the case of a new hire, the Organization will conduct a thorough reference check with past employers to determine whether he/she meets the requirement.
Criteria for consideration of Teleworking Arrangement

  • Is the employee a good candidate for teleworking?
  • Proven ability to perform;
  • No disciplinary action;
  • High job knowledge;
  • Ability to establish clear objectives;
  • Flexibility;
  • Ability to work independently;
  • Dependability.
  • Does the nature of the work lend itself to teleworking?
  • Jobs that entail working alone or with equipment that can be kept at the alternate work site
  • Clearly defined tasks and objectives;
  • Little face-to-face communication needed;Measurable work activities

5.  Job Responsibilities

Employee job responsibilities will not change due to teleworking. Professionalism in terms of job responsibilities, work output, and customer orientation will continue to follow the standards set by the Organization.  The amount of time an employee is expected to work will not change due to teleworking.  Employee work hours will be mutually agreed upon by the supervisor and the employee.  In the event that business conditions require the teleworking employee’s presence at a central work location function, meeting, or other event, the employee is expected to report to the central work location, even if such occurs during normally scheduled home-work area hours.

6.  Contact With the Central Work Location

Once a teleworking arrangement has been approved, the teleworking employee is responsible for maintaining regular contact with his or her Supervisor. The Supervisor shall be the teleworking employee’s primary contact within the central work location. It is expected that the Supervisor and the teleworker will act together to keep each other apprised of events or information obtained during the working day.

7.  Alternate Work Area

The Organization shall provide workers’ compensation and liability protection as obligated by State statues for the employee while in the course of employment within the agreed upon location and defined work schedule.  The Organization assumes no responsibility for any activity, damages, or injury which is not directly associated or resulting from the official job duties for which the Organization has no ability to exercise control.  The Organization assumes no responsibility for the employee’s personal property.

In addition, the following must be adhered to:

  1. A designated workspace should be maintained by the employee in a clean, professional, and safe condition.
  2.   Any change in the approved job assignment, location or defined work schedule must be reviewed and approved by the supervisor in advance.
  3.   As liability may extend to accident5s which could occur in the alternative work location, the Organization retains the right to make on-site inspections of this work area, at a mutually agreed upon time, to ensure that safe work conditions exist.
  4. Employee tax implications related to alternate work locations are the responsibility of the employee.
  5. Employee expenses not specifically covered in this policy will be dealt with on a case-be-case basis between the employee and his/her supervisor.
  6. Employees who work at home will manage dependent care and personal responsibilities in a way that allows them to successfully met job responsibilities.

8.  Equipment

  1. Any hardware of software purchased by the Organization remains the property of the Organization and will be returned to the Organization should the alternative work arrangement be terminated.
  2. Software owned by the Organization may not be duplicated except as formally authorized by policy.
  3.   Employees using Organization software must adhere to the manufacturer’s licensing agreements.
  4.   Restricted access materials (such as payroll, personnel files, etc) may not be taken out of the office, copied, or compromised in any way.  Employees working at alternate sites will take all precautions necessary to secure sensitive information and prevent unauthorized access to the Organization.
  5.   Organization equipment located at an alternative work location may not be used for personal activities.

—————————End of example—————————————

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

ISO 27001:2013 A.18 Compliance

The Organizations are subject to numerous laws, regulations, and contractual obligations that specify requirements related to the appropriate management and protection of diverse information sets. Understanding and maintaining compliance with these different requirements is sometimes a difficult road. The path to establishing compliance takes a complete look at the areas in which your Organization has responsibilities, whether legal, regulatory, contractual, or self-imposed. Important elements to consider when developing a plan for compliance  include the following:

  • Awareness of relevant regulations/laws. (Do you know what you need to follow?)
  • Awareness of relevant policies. (Do you know what  policies apply to information use?)
  • Awareness of relevant contractual agreements. (Do you know what agreements your organization has made that impose conditions on the use of data?)
  • Awareness of relevant standards or best practices. (Do you know what standards or best practices your organization chooses to follow with respect to information use?)
  • Management of institutional records. (Do you know what you need to keep and for how long?)
  • Awareness of how records are managed by your organization.
  • Approach to complying with each item. (Do you know what your organization is doing to follow the law?)
  • Awareness of internal and/or external audit activities. (Do you know what internal/external audits exist and what is required to meet or pass these reviews?)

The initial process in developing compliance initiatives is to identify which laws, regulations, and policies are applicable to your institution. To that end, confer with your legal and/or audit departments, and review the most common federal and State data protection laws.
1. Identify key stakeholders and/or partners across the organization who regularly deal with organizational compliance issues (e.g., legal, risk management, privacy, audit). Key stakeholders may vary from campus to campus.
2. Perform a high level gap analysis of each compliance requirement that is applicable to determine where progress needs to be made.
3. Develop a prioritized action plan that will help you organize your efforts (one section of your Information Security plan).
4. Develop a policy, standard, roles and responsibilities, and/or procedures in collaboration with other key stakeholders at your organization.
5. 6. Familiarize yourself with common standards and regulations that address specific requirements
7. Determine whether Governance, Risk, and Compliance (GRC) solutions can assist you with managing compliance.

A.18.1 Compliance with legal and contractual requirements

Objective:
To avoid breaches of legal, statutory, regulatory or contractual obligations related to information security and of any security requirements.

A.18.1.1 Identification of applicable legislation and contractual requirements

Control

All relevant legislative statutory, regulatory, contractual requirements and the organization’s approach to meet these requirements should be explicitly identified, documented and kept up to date for each information system and the organization.

Implementation guidance

The specific controls and individual responsibilities to meet these requirements should also be defined and documented. Managers should identify all legislation applicable to their organization in order to meet the requirements for their type of business. If the organization conducts business in other countries, managers should consider compliance in all relevant countries.

A.18.1.2 Intellectual property rights

Control
Appropriate procedures should be implemented to ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products.

Implementation guidance

The following guidelines should be considered to protect any material that may be considered intellectual property:
a) publishing an intellectual property rights compliance policy which defines the legal use of software and information products;
b) acquiring software only through known and reputable sources, to ensure that copyright is not violated;
c) maintaining awareness of policies to protect intellectual property rights and giving notice of the intent to take disciplinary action against personnel breaching them;
d) maintaining appropriate asset registers and identifying all assets with requirements to protect intellectual property rights;
e) maintaining proof and evidence of ownership of licenses, master disks, manuals, etc.;
f) implementing controls to ensure that any maximum number of users permitted within the license is not exceeded;
g) carrying out reviews that only authorized software and licensed products are installed;
h) providing a policy for maintaining appropriate license conditions;
i) providing a policy for disposing of or transferring software to others;
j) complying with terms and conditions for software and information obtained from public networks;
k) not duplicating, converting to another format or extracting from commercial recordings (film, audio) other than permitted by copyright law;
l) not copying in full or in part, books, articles, reports or other documents, other than permitted by copyright law.

Other information

Intellectual property rights include software or document copyright, design rights, trademarks, patents and source code licenses. Proprietary software products are usually supplied under a license agreement that specifies license terms and conditions, for example, limiting the use of the products to specified machines or limiting copying to the creation of backup copies only. The importance and awareness of intellectual property rights should be communicated to staff for software developed by the organization. Legislative, regulatory and contractual requirements may place restrictions on the copying of proprietary material. In particular, they may require that only material that is developed by the organization or that is licensed or provided by the developer to the organization, can be used. Copyright infringement can lead to legal action, which may involve fines and criminal proceedings.

A.18.1.3 Protection of records

Control
Records should be protected from loss, destruction, falsification, unauthorized access and unauthorized release, in accordance with legislator, regulatory, contractual and business requirements.

Implementation guidance
When deciding upon protection of specific organizational records, their corresponding classification based on the organization’s classification scheme, should be considered. Records should be categorized into record types, e.g. accounting records, database records, transaction logs, audit logs and operational procedures, each with details of retention periods and type of allowable storage media, e.g. paper, microfiche, magnetic, optical. Any related cryptographic keys and programs associated with encrypted archives or digital signatures, should also be stored to enable decryption of the records for the length of time the records are retained. Consideration should be given to the possibility of deterioration of media used for storage of records. Storage and handling procedures should be implemented in accordance with manufacturer’s recommendations. Where electronic storage media are chosen, procedures to ensure the ability to access data (both media and format readability) throughout the retention period should be established to safeguard against loss due to future technology change. Data storage systems should be chosen such that required data can be retrieved in an acceptable timeframe and format, depending on the requirements to be fulfilled. The system of storage and handling should ensure identification of records and of their retention period as defined by national or regional legislation or regulations, if applicable. This system should permit appropriate destruction of records after that period if they are not needed by the organization. To meet these record safeguarding objectives, the following steps should be taken within an organization:

  1. guidelines should be issued on the retention, storage, handling and disposal of records and information;
  2. a retention schedule should be drawn up identifying records and the period of time for which they should be retained;
  3. an inventory of sources of key information should be maintained.

Other information
Some records may need to be securely retained to meet statutory, regulatory or contractual requirements, as well as to support essential business activities. Examples include records that may be required as evidence that an organization operates within statutory or regulatory rules, to ensure defense against potential civil or criminal action or to confirm the financial status of an organization to shareholders, external parties and auditors. National law or regulation may set the time period and data content for information retention.

A.18.1.4 Privacy and protection of personally identifiable information

Control
Privacy and protection of personally identifiable information should be ensured as required in relevant legislation and regulation where applicable.

Implementation guidance
An organization’s data policy for privacy and protection of personally identifiable information should be developed and implemented. This policy should be communicated to all persons involved in the processing of personally identifiable information. Compliance with this policy and all relevant legislation and regulations concerning the protection of the privacy of people and the protection of personally identifiable information requires appropriate management structure and control. Often this is best achieved by the appointment of a person responsible, such as a privacy officer, who should provide guidance to managers, users and service providers on their individual responsibilities and the specific procedures that should be followed. Responsibility for handling personally identifiable information and ensuring awareness of the privacy principles should be dealt with in accordance with relevant legislation and regulations. Appropriate technical and organizational measures to protect personally identifiable information should be implemented.

Other information
ISO/IEC 29100 provides a high-level framework for the protection of personally identifiable information within information and communication technology systems. A number of countries have introduced legislation placing controls on the collection, processing and transmission of personally identifiable information (generally information on living individuals who can be identified from that information). Depending on the respective national legislation, such controls may impose duties on those collecting, processing and disseminating personally identifiable information, and may also restrict the ability to transfer personally identifiable information to other countries.

A.18.1.5 Regulation of cryptographic controls

Control
Cryptographic controls should be used in compliance with all relevant agreements, legislation and regulations.

Implementation guidance

The following items should be considered for compliance with the relevant agreements, laws and regulations:

  1. restrictions on import or export of computer hardware and software for performing cryptographic functions;
  2. restrictions on import or export of computer hardware and software which is designed to have cryptographic functions added to it;
  3. restrictions on the usage of encryption;
  4. mandatory or discretionary methods of access by the countries’ authorities to information encrypted by hardware or software to provide confidentiality of content.

Legal advice should be sought to ensure compliance with relevant legislation and regulations. Before encrypted information or cryptographic controls are moved across jurisdictional borders, legal advice should also be taken.

Annex A.18.1 is about compliance with legal and contractual requirements. The objective is to avoid breaches of legal, statutory, regulatory or contractual obligations related to information security and of any security requirements. It’s an important part of the information security management system (ISMS) . The goal here is to help outline effective practices for identifying compliance obligations, as well as the roles and responsibilities, activities, and controls needed to manage all of the organization’s legal, contractual, and records management requirements.

Identification of Applicable Legislation & Contractual Requirements

A good control describes how all relevant legislative statutory, regulatory, contractual requirements, and the organization’s approach to meet these requirements should be explicitly identified, documented and kept up to date for each information system and the organization. Put in simple terms, the organization needs to ensure that it is keeping up to date with and documenting legislation and regulation that affects achievement of its business objectives and the outcomes of the ISMS. It is important that the organization understands the legislation, regulation and contractual requirements with which it must comply and these should be centrally recorded in register to allow for ease of management and coordination. The identification of what is relevant will largely depend on; Where the organization is located or operates; What the nature of the organization’s business is; and The nature of information being handled within the organization. The Identification of the relevant legislation, regulation and contractual requirements is likely to include engagement with legal experts, regulatory bodies and contract managers. This is an area that often catches organizations out as there is generally far more legislation and regulation impacting the organization than is first considered.  The auditor will be looking to see how the organization has identified and recorded its legal, regulatory and contractual obligations; the responsibilities for meeting such requirements and any necessary policies, procedures and other controls required for meeting the controls. Additionally, they will look to see that this register is maintained on a regular basis against any relevant change – especially in legislation across common areas that they would expect any organization to be impacted by.  Legal requirements need to be explicitly identified and recognized and a plan in place for meeting applicable requirements. To meet this part of compliance, controls should be developed which:

  1. Identify the persons or person responsible for ascertaining the legal requirements. Those requirements should then be placed against the other controls that exist in some sort of matrix which shows controls in place to meet the requirements. Each state has breach laws, personal information protection laws, social security protections laws, or other laws related to technology furnished at every institution. Each state must be taken as its own legal island and an institution must know if any of the following impact or enhance security efforts.
  2. Identify the persons or person responsible for reviewing contracts to determine any information security requirements, whether they are requirements of the institution or requirements of the vendor. Those requirements should then be placed against the other controls that exist in some sort of matrix which shows controls in place to meet the requirements.

Every contract that involves organizational data must be documented and any controls specified in that contract must also be documented. It is crucial to know what your contractual responsibilities are so that you can look at the physical and technical controls you have in place and determine if they are adequate for the assumed contractual liability. In instances where contracting parties have access to organizational data, you want to be sure that you can audit the contractual controls and protections that the other party has agreed to follow.

Intellectual Property Rights

Intellectual Property (IP) rights are a dominant issue at any Organizations. Organizations may  have many different types of research and proprietary information that can be protected via these rights. These rights are also attached to the different technologies that an institution might buy or license from others (and the rights are then protected via contract provisions). A good control describes how the appropriate procedures ensure compliance with legislative, regulatory and contractual requirements related to intellectual property rights and use of proprietary software products. Put into simple terms, the organization should implement appropriate procedures which ensure it complies with all its requirements, whether they are legislative, regulatory or contractual – related to its use of software products or intellectual property rights. Policies, processes and technical controls are likely to be needed for both of these aspects. Within asset registers and acceptable use policies it is likely that IPR considerations will need to be made – e.g. where an asset is or contains IPR protection of this asset must consider the IPR aspect. Controls to ensure that only authorized and licensed software are in use within the organization should include regular inspection and audit. The auditor will want to see that registers of licenses owned by the organization for use of others’ software and other assets are being kept and updated. Of particular interest to them will be ensuring that where licenses include a maximum number of users or installations, that this number is not exceeded and user and installation numbers are audited periodically to check compliance. The auditor will also be looking at how the organization protects its own IPR, which might include; Data loss and prevention controls; Policies and awareness program targeting user education; or Non-disclosure and confidentiality agreements that continue post termination of employment. Appropriate controls to identify and protect intellectual property include:
• An intellectual property rights compliance policy (which meets copyright policy requirements of certain laws);
• Ensuring proper use of software and other technology licenses;
• Education and awareness on respecting IP rights;
• Keeping track of IP assets.

Protection of Records

A good control describes how records are protected from loss, destruction, falsification, unauthorized access and unauthorized release, in accordance with the legislator, regulatory, contractual and business requirements. Different types of record will likely require different levels and methods of protection. It is critical that records are adequately and proportionality protected against loss, destruction, falsification, unauthorized access or release. The protection of records must comply with any relevant legislation, regulation or contractual obligations. It is especially important to understand how long records must, should or could be kept for and what technical or physical issues might affect these over time – bearing in mind that some legislation might trump others for retention and protection. The auditor will be checking to see that considerations for the protection of records has been made based on business requirements, legal, regulatory and contractual obligations. The organizations deals with the issues inherent in managing organizational records and data, whether electronic or in paper. As part of the compliance controls at every institution, important records as well as records we are legally obligated to retain need to be protected from loss, destruction, and falsification. ISO has a separate standard, ISO 15489 “Information and Documentation — Records Management.” This standard goes into greater detail about how an organizations recognizes the context in which records are created, received, used, stored, and destroyed as an implicit part of the data governance process. This “records management” function may be placed anywhere in an organizations, and sometimes it is part of an organization’s IT structure. Regardless, records management has components of compliance that are unavoidable. Organization’s policies and guidelines on retention, storage, handling, and disposal of records should be reviewed. Oftentimes this will require a security control to ensure that these policies and guidelines are carried out properly. (Refer to the Records Retention and Disposition Toolkit for additional information and templates.). Policies that protect records from loss, destruction, or falsification.

Privacy & Protection of Personally Identifiable Information

A good control describes how privacy and protection of personally identifiable information is assured for relevant legislation and regulation. Any information handled that contains personally identifiable information (PII) is likely to be subject to the obligations of legislation and regulation. PII is especially likely to have high requirements for confidentiality and integrity, and in some cases availability as well (e.g. health information, financial information). Under some legislation (e.g. the GDPR) some types of PII are defined as additionally “sensitive” and require further controls to ensure compliance.  It is important that awareness campaigns are used with staff and stakeholders to ensure a repeated understanding of individual responsibility for protecting PII and privacy. The auditor will be looking to see how PII is handled, if the appropriate controls have been implemented, are they being monitored, reviewed and where necessary improved. They will also be looking to check that handling requirements are being met, and audited suitably. Additional responsibilities exist too, for example GDPR will expect a regular audit for areas where personal data is at risk. Smart organizations will tie these audits up alongside their ISO 27001 audits and avoid duplication or gaps.

Regulation of Cryptographic Controls
Cryptographic controls should be used in compliance with all relevant agreements, laws, and regulations.A good control describes how cryptographic controls are used in compliance with all relevant agreements, legislation and regulations. The use of cryptographic technologies is subject to legislation and regulation in many territories and it is important that an organization understands those that are applicable and implements controls and awareness programs that ensure compliance with such requirements. This is especially true when cryptography is transported or used in territories other than the organization’s or user’s normal place of residence or operation. Trans-border import/export laws may include requirements relating to cryptographic technologies or usage. The auditor will be looking to see that considerations for the appropriate regulation of cryptographic controls have been made and relevant controls and awareness program implemented to ensure compliance.

A. 18.2 Information security reviews

Objective:

To ensure that information security is implemented and operated in accordance with the organizational policies and procedures.

A.18.2.1 Independent review of information security

Control
The organization’s approach to managing information security and its implementation (i.e. control objectives, controls, policies, processes and procedures for information security) should be reviewed independently at planned intervals or when significant changes occur.

Implementation guidance

Management should initiate the independent review. Such an independent review is necessary to ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security. The review should include assessing opportunities for improvement and the need for changes to the approach to security, including the policy and control objectives. Such a review should be carried out by individuals independent of the area under review, e.g. the internal audit function, an independent manager or an external party organization specializing in such reviews. Individuals carrying out these reviews should have the appropriate skills and experience. The results of the independent review should be recorded and reported to the management who initiated the review. These records should be maintained. If the independent review identifies that the organization’s approach and implementation to managing information security is inadequate, e.g. documented objectives and requirements are not met or not compliant with the direction for information security stated in the information security policies, management should consider corrective actions.

A.18.2.2 Compliance with security policies and standards

Control
Managers should regularly review the compliance of information processing and procedures within their area of responsibility with the appropriate security policies, standards and any other security requirements.

Implementation guidance

Managers should identify how to review that information security requirements defined in policies, standards and other applicable regulations are met. Automatic measurement and reporting tools should be considered for efficient regular review. If any non-compliance is found as a result of the review, managers should:

  1. identify the causes of the non-compliance;
  2. evaluate the need for actions to achieve compliance;
  3. implement appropriate corrective action;
  4. review the corrective action taken to verify its effectiveness and identify any deficiencies or weaknesses.

Results of reviews and corrective actions carried out by managers should be recorded and these records should be maintained. Managers should report the results to the persons carrying out independent reviews  when an independent review takes place in the area of their responsibility.

A.8.2.3 Technical compliance review

Control

Information systems should be regularly reviewed for compliance with the organization’s information security policies and standards.

Implementation guidance

Technical compliance should be reviewed preferably with the assistance of automated tools, which generate technical reports for subsequent interpretation by a technical specialist. Alternatively, manual reviews (supported by appropriate software tools, if necessary) by an experienced system engineer could be performed. If penetration tests or vulnerability assessments are used, caution should be exercised as such activities could lead to a compromise of the security of the system. Such tests should be planned, documented and repeatable. Any technical compliance review should only be carried out by competent, authorized persons or under the supervision of such persons.

Other information
Technical compliance reviews involve the examination of operational systems to ensure that hardware and software controls have been correctly implemented. This type of compliance review requires specialist technical expertise. Compliance reviews also cover, for example, penetration testing and vulnerability assessments, which might be carried out by independent experts specifically contracted for this purpose. This can be useful in detecting vulnerabilities in the system and for inspecting how effective the controls are in preventing unauthorized access due to these vulnerabilities. Penetration testing and vulnerability assessments provide a snapshot of a system in a specific state at a specific time. The snapshot is limited to those portions of the system actually tested during the penetration attempt(s). Penetration testing and vulnerability assessments are not a substitute for risk assessment.

A good control describes the organization’s approach to managing information security and its implementation (i.e. control objectives, controls, policies, processes and procedures for information security) is reviewed independently at planned intervals or when significant changes occur. Ensure that information security compliance requirements are effectively addressed and maintained over time. In order to meet compliance requirements, it is necessary to continually review compliance methods, systems, and processes of departments that are affected by various policies, regulatory requirements, and laws to ensure that their approach to compliance is effective. For example, a particular credit card Point of Sale system (POS) can be implemented at a point in time on your campus, and your reviews may indicate that the application is in full compliance with PCI DSS. However, two years later, the payment application may no longer be considered fully compliant by the PCI SSC and if reviews aren’t conducted on a recurring basis, this could result in noncompliance with PCI DSS requirements. It is good to get an independent review of security risks and controls to ensure impartiality and objectivity as well as benefit from fresh eyes. That doesn’t mean it has to be external, just benefit from another colleague reviewing policies in addition to the main author/administrator.  These reviews should be carried out at planned, regular intervals and when any significant, security relevant changes occur – ISO interprets regular to be at least annually. The auditor will be looking for both regular independent security review and review when significant changes occur, as well as take confidence there is a plan for regular reviews. They will also require evidence that reviews have been carried out and any issues or improvements identified in the reviews are appropriately managed.

Independent Review of Information Security
It is important to have unbiased reviews of information security organization programs and initiatives on a recurring basis in order to measure and ensure effectiveness. Often, these reviews are carried out by multiple parties: internal audit departments, external auditors, and assessments performed by contractors or consultants. It is also important that individuals performing reviews and assessments are qualified to do so. The primary objective of independent reviews is to measure effectiveness and ensure continuous improvements are made. In the event that your organization does not have an internal audit function, you may be able to develop a cooperative agreement with another organization or hire a consulting firm to conduct an audit and/or assessment of specific areas you need to have assessed. Note: For some organization, an independent review may include representatives from legal counsel, an executive leadership team, and/or a system office.

Compliance with Security Policies and Standards
Managers have compliance responsibility to make sure that applicable security procedures related to their area of control are implemented and performed correctly to achieve compliance with internal security policies and standards. Many organization are considering the implementation of Governance, Risk, and Compliance (GRC) solutions to automate compliance reviews and reporting, as well as assisting with determining corrective actions that need to be managed. Take a look at Governance, Risk, and Compliance (GRC) Systems to help you determine if a GRC system is a good investment for your information security program. ISMS managers should regularly review the compliance of information processing and procedures within their area of responsibility. Policies are only effective if they are enforced and compliance is tested and reviewed on a regular periodic basis. It is usually the responsibility of the line management to ensure that their subordinate staff comply with organizational policies and controls but this should be complemented by occasional independent review and audit. Where non-compliance is identified, it should be logged and managed, identifying why it occurred, how often it is occurring and the need for any improvement actions either relating to the control or to the awareness, education or training of the user that caused the non-compliance. The auditor will be looking to see that both; Proactive preventative policies, controls, and awareness programs are in place, implemented and effective; and Reactive compliance monitoring, review, and audit are also in place. They will also be looking to see that there is evidence of how improvements are made over time to ensure an improvement in compliance levels or maintenance if compliance is already at 100%. This dovetails into the main requirements of ISO 27001 for 9 and 10 around internal audits, management reviews, improvements, and non-conformities too.  Staff awareness and engagement in line with A 7.2.2 is also important to tie into this part for compliance confidence.

Technical Compliance Reviews
Information systems should be regularly reviewed for compliance with the organization’s information security policies and standards. Automated tools are normally used to check systems and networks for technical compliance and these should be identified and implemented as appropriate. Where tools such as these are used, it is necessary to restrict their use to a few authorized personnel as possible and to carefully control and coordinate when they are used to prevent compromise of system availability and integrity. Adequate levels of compliance testing will be dependent on business requirements and risk levels, and the auditor will expect to see evidence of these considerations being made. They will also expect to be able to inspect testing schedules and records.Technical compliance reviews are also performed by many organizations. From vulnerability and DLP (data loss prevention) assessments to penetration testing, there are a number of technical solutions available to help information security teams conduct effective reviews of IT infrastructure and the information lifecycle (processing, transmitting, storing). Some of these tools can disrupt business and IT operations if used by untrained individuals, which leads some campuses to use third parties for these purposes. However, these examinations are just a ‘snapshot’ at a point in time and must be repeated at recurring intervals in order to become an effective method or process.

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.

ISO 27001:2013 A.17 Information security aspects of business continuity management

Organizations are vulnerable to a variety of natural and man-made emergencies, disasters, and hazards. Recognizing that not all events can be prevented and some risks may be deemed acceptable, proper planning is essential to maintain or restore services when an unexpected or unavoidable event disrupts normal operations. Business continuity planning includes the identification of vulnerabilities, priorities, dependencies, and measures for developing plans to facilitate continuity and recovery before, during, and after such a disruption. Comprehensive business continuity plans are designed and implemented to ensure continuity of operations under abnormal conditions. Plans promote the readiness of institutions for rapid recovery in the face of adverse events or conditions, minimize the impact of such circumstances, and provide means to facilitate functioning during and after emergencies. The development process is usually based on a single framework, and involves key individuals in the functional areas. Plans are based on a risk assessment and business impact analysis and include a process for regular maintenance, including training, testing/drills, and updates. In addition, information security and privacy should be integrated within plans. Examples of Incidents that Activate Business Continuity Plans

  • A fire in a building with critical resources would prohibit normal functioning in a localized facility.
  • An electrical power loss may cover  an extended time period. The organization may experience an extended power loss during and after a snow/ice storm, Super Storm Sandy, and the numerous blizzards/ice storms/fires/floods.
  • Floods, massive fires, blizzards, tornadoes, hurricanes, tsunamis, earthquakes, pandemics, ice storms, or mud slides that results in evacuations and inaccessibility to critical resources.
  • A criminal activity or terrorist incident may impact a wide geographic area for an extended period of time.
  • A pandemic, nuclear, chemical, or biological incident may limit the mobility and accessibility of individuals for extended time periods.

Measures must be taken to ensure the integrity, security, accuracy, and privacy of all systems and data. Such measures include adherence to all governmental regulations and directives. As major disasters have brought acute awareness to the organization, the management recognizes the need for extensive planning and coordination to assure preparedness by developing, testing, and refining plans to handle all types of disruptions to normal services. Use the following steps to get started with a business continuity plan.
1. Obtain commitment and authority from Organization Leadership. High level support is essential for building the cross functional teams that are needed to prepare and deploy the plan.
2. Establish a planning team for each business unit.
3. Perform a risk assessment in each unit.
4. Identify critical resources:

a. People – Identify all support staff, and establish a chain of succession for key personnel.
b. Places – Identify key buildings, and plan alternate locations for workers and equipment.
c. Systems – Perform a business impact analysis to prioritize systems in terms of criticality.
d. Other – Identify other critical assets required for normal business operations.

5. Determine continuity and recovery strategies within each unit.
6. Train students, faculty, and staff on what to do in case of a disaster.
7. Test, test, test! Test system recovery procedures. Generate scenarios and simulate them with table top exercises.
8. Create a communication plan.
9. Review the business continuity plan annually.
A well prepared organization should develop a plan addressing all key services and their administration, delivery, and support. The Organization should  be considering or embarking on the development of a plan, including commitments, procedures, technologies, resources, methodologies, and communications essential to planning development, support, and deployment.

A.17.1 Information security continuity

Objective:

Information security continuity should be embedded in the organization’s business continuity management systems.

A.17.1.1 Planning information security continuity

Control

The organization should determine its requirements for information security and the continuity of information security management in adverse situations, e.g. during a crisis or disaster.

Implementation guidance

An organization should determine whether the continuity of information security is captured within the business continuity management process or within the disaster recovery management process. Information security requirements should be determined when planning for business continuity and disaster recovery. In the absence of formal business continuity and disaster recovery planning, information security management should assume that information security requirements remain the same in adverse situations, compared to normal operational conditions. Alternatively, an organization could perform a business impact analysis for information security aspects to determine the information security requirements applicable to adverse situations.

Other information

In order to reduce the time and effort of an ‘additional’ business impact analysis for information security, it is recommended to capture information security aspects within the normal business continuity management or disaster recovery management business impact analysis. This implies that the information security continuity requirements are explicitly formulated in the business continuity management or disaster recovery management processes.

A.17.1.2 Implementing information security continuity

Control

The organization should establish, document, implement and maintain processes, procedures and controls to ensure the required level of continuity for information security during an adverse situation.

Implementation guidance

An organization should ensure that:
a) an adequate management structure is in place to prepare for, mitigate and respond to a disruptive event using personnel with the necessary authority, experience and competence;
b) incident response personnel with the necessary responsibility, authority and competence to manage an incident and maintain information security are nominated;
c) documented plans, response and recovery procedures are developed and approved, detailing how the organization will manage a disruptive event and will maintain its information security to a predetermined level, based on management-approved information security continuity objectives.

According to the information security continuity requirements, the organization should establish, document, implement and maintain:
a) information security controls within business continuity or disaster recovery processes, procedures and supporting systems and tools;
b) processes, procedures and implementation changes to maintain existing information security controls during an adverse situation;
c) compensating controls for information security controls that cannot be maintained during an adverse situation.

Other information

Within the context of business continuity or disaster recovery, specific processes and procedures may have been defined. Information that is handled within these processes and procedures or within dedicated information systems to support them should be protected. Therefore an organization should involve information security specialists when establishing, implementing and maintaining business continuity or disaster recovery processes and procedures. Information security controls that have been implemented should continue to operate during an adverse situation. If security controls are not able to continue to secure information, other controls should be established, implemented and maintained to maintain an acceptable level of information security.

A. 17.1.3 Verify, review and evaluate information security continuity

Control

The organization should verify the established and implemented information security continuity controls at regular intervals in order to ensure that they are valid and effective during adverse situations.

Implementation guidance

Organizational, technical, procedural and process changes, whether in an operational or continuity context, can lead to changes in information security continuity requirements. In such cases, the continuity of processes, procedures and controls for information security should be reviewed against these changed requirements. Organizations should verify their information security management continuity by:

a) exercising and testing the functionality of information security continuity processes, procedures and controls to ensure that they are consistent with the information security continuity objectives;
b) exercising and testing the knowledge and routine to operate information security continuity processes, procedures and controls to ensure that their performance is consistent with the information security continuity objectives;
c) reviewing the validity and effectiveness of information security continuity measures when information systems, information security processes, procedures and controls or business  continuity management/disaster recovery management processes and solutions change.

Other information

The verification of information security continuity controls is different from general information security testing and verification and should be performed outside the testing of changes. If possible, it is preferable to integrate verification of information security continuity controls with the organization’s business continuity or disaster recovery tests.

Business Continuity Plans are an integral part of all organized Information Security activities. The plans are a well-reasoned, step-by-step approach to determine the how, when, where, who, and what will be needed should a disruption of normal operations occurs. Recent history has demonstrated that plans are a necessity regardless of the size, location, or mission of an organization. And the plan must address the continuity of security and privacy under less than ideal circumstances. Below are some references to further describe the intent of such plans.

1

Planning Information Security Continuity

Information security must be an integral part of all institutional policies, procedures, and practices. Information security should also be an integral element of business continuity management system. Business continuity plans must recognize the need to strictly adhere to institutional security and privacy policies and regulations, even while the institution is functioning during extraordinary conditions. Good business continuity plans should be built in accordance with strong institutional security and privacy policies as well as state and federal regulations. This will allow important security and privacy practices to continue to be practiced, even during and after a disruptive event. Such practices should be elements of all planning, implementation, testing, and evaluation efforts.

Organization Commitment: Obtain commitment and authority from Organization leadership
A plan should begin with a organization-wide commitment to develop, staff, and support efforts that will be activated when circumstances clearly indicate that business has been or will be disrupted for more than a brief or acceptable time. A plan is not intended to address routine disruptions such as planned or routine maintenance. On the contrary, well-developed and tested plans are essential during and after catastrophic events that preclude resumption of normal business functioning within well defined time frames. Begin the planning process by obtaining the buy-in from the executive level of the organization. This high level mandate establishes the ability, authority, and support to build the cross functional teams needed for the preparation and the deployment of the plan, facilities and resources, necessary redundancy of services and resources, and commitment from units for ongoing participation. Institutional support for business continuity should include funding for plan development, staffing, training, testing, updating, deployment, and transitioning to normal operations. Note that a business continuity plan is not just a technology plan. It is not just what to do about unavailable IT resources. It is a much broader view of the functions and information resources of the institutions. IT resources are a necessary part, but not a sufficient part. People are the most important element. Commitment, leadership, preparation and practice are key factors of a business continuity plan. Business continuity can be viewed as an added expense at a time when funding is limited. It is important to realize that having a business continuity plan is a critical function that needs continuous funding. However, even if your institution determines that it cannot afford to support a full plan for everything that is needed, it is important to develop and have a plan in place. Developing a plan forces priorities to be identified and implemented and identifies which risks are acceptable and which must be addressed. And when possible, additional components of a plan should be implemented. Some plan is better than no plan at all. Many Organization have No Strategic Plans for Disaster Recovery. Data  reveal that a large number of organization do not have strategic plans for disaster recovery. Just under 10% of the organization participating in the fall 2015 survey report a strategic plan for IT disaster recovery. Some sectors have shown only small increases in the percentage of organization reporting a strategic plan for IT disaster planning between 2008 and 2015.

Framework and Planning Cycle

Having a framework assures a defined structure for the planning process, the development of a plan, priorities and dependencies within a plan, testing of a plan, procedures for maintaining and updating the plan, and responsibilities of individuals and units before, during, and after the activation of a business continuity plan. Choose a framework to be used as the basis for the plan.

  • Create the plan
  • Train the participants
  • Perform drills
  • Do post mortems on the drills
  • Review the plan
  • Revise the plan

Who Should be Involved and in What Role – Establish a planning team for each business unit

At its core, business continuity management is a well-coordinated, well-tested, cross-functional effort. Representatives from each functional area or business unit are responsible for the identification, prioritization, documentation, and updating of their aspects of the plans, covered services, and facilities. Remember to include academic and their support areas in the list of units to be included. Members of a business continuity team are responsible for the compilation and integration of all input from each functional area into the overall plan. Team coordinators are responsible for the overall coordination of the plan, its deployment, and its refinement. They must be good, dependable managers with strong leadership and problem solving skills, capable of keeping the effort organized according to procedures, yet able to be creative when things don’t go as planned.

Scope of the Plan
A Business Continuity Plan cannot be unlimited in scope, so it’s important to define the comprehensiveness of the plan: whether it covers contingencies for all major potential threats (severe weather events, terrorist threats, fire, shooter, cyber-attacks, pandemic) or a subset of these disruptions. Define whether the plan covers the entire organization, parts of the location or multiple Locations. Define what critical functions are covered as part of the plan and what activities are not essential. Define the time scope of the plan – does it plan for a disruption that lasts hours, days or weeks? The Business Impact Analysis should heavily inform the plan’s scope. Defining the scope does not negate the concept that BCP should broadly account for any business disruption. It’s a practical measure acknowledging that the continuity planning process is impacted by budgetary restraints.

Business Continuity and Risk Management – Perform a risk assessment in each unit
It is important to determine the impact of risks on the functioning of the institution under normal operating conditions as well as under the extraordinary conditions during which a business continuity plan will be activated. Risk Management is an activity directed towards the assessing, mitigating, and monitoring of risks to an organization. In Business Continuity Management, it is important to determine what activities are vulnerable under what conditions, what measures should be taken to reduce risk and at what cost, what risks are acceptable, and what measures should be taken to facilitate functioning during and immediately after incidents that disrupt normal operations of the institution.

Business Impact Analysis – Identify Critical Resources
A Business Impact Analysis (BIA) identifies the institution’s critical services and resources and the maximum tolerable downtime (MTD) for these critical services. The BIA must identify vulnerabilities, threats and risks and prioritize the order of events for restoration of key business processes. The BIA is distinguished from Risk Assessment in that it defines the window of time available to restore services. First determine the organization’s key functions and resources that must be continuously available, during and immediately after major disruptive events. Business units must identify their key resources, prioritize them, and assess the risks to determine how long these key resources can be unavailable and factors that impact that duration. Each unit must perform a risk assessment to identify measures to be taken to reduce risks as well as identify acceptable risks where the cost of mitigation is higher than the cost of the consequence. Each unit must also assess the priority of resources and services. This prioritization should be identified by the unit itself. Alternate resources may be identified for use should the primary resources become unavailable or inaccessible. The results of the business impact analysis are input to the development of the business continuity plan.

Documentation
All required information pertaining to the plan, key resources, facilities, management structure, priorities/dependencies, documentation, and personnel should be kept in secure locations which can be physical, virtual, or cloud-based. This information should also be made available to key personnel who will be responsible for coordinating continuity efforts during and after the incident or event. Operational information will assist those directly working to keep/restore functions. Individuals most familiar with applications may not be able to respond. Documentation will assist others in performing required tasks. Emergency templates for all functions included in the plan should include a summary of business impact analysis data, required resources (hardware, software, data) for the application to run, dependencies on other applications and resources, vendor contacts, people who should be kept apprised of status of the recovery, and the list of key individuals and how to reach them.

Contact Information

The inability to contact key team members can hamper the most well designed plan. Contact information must include all means for reaching people at all times. This list must include alternate people should a key individual be unavailable or unreachable. Contact information must be kept current at all times and include alternative means such as home and cell phone numbers, alternate email addresses, and social networking, text, and twitter contact information.

Checklists

Checklists should be created to document the inventory of everything kept in designated physical, remote, virtual, and/or cloud locations for coordinating efforts – contact information, documentation, resources/systems, backup power, communications equipment, food, water, vendor contacts, etc.

Keep Track of Activities

While testing a plan or during an actual deployment, remember to keep track of who is doing what. This can be done via conference calls, texting, alternative web sites, and actual staff reporting in to track all activities as well as make sure that people are safe and getting sufficient food, water, and rest. Communication may be difficult, but it is essential. Not everything will work as scripted, and communicating with other team members may help solve the unexpected or undocumented.

Personnel

People are the key element of the plan. Being able to communicate during a crisis may not be easy due to loss or overloading of infrastructure. Continuity plan leaders or coordinators should be good leaders and managers, capable of keeping the effort organized according to procedures, yet able to be creative when things don’t go as planned. Have at least two people scheduled at all times as team coordinators for the continuity effort. Never have a single point of failure! Someone may not be available at the critical time. Team coordinators should be involved in monthly assessment of the resources and facilities. Establish a substitution procedure for team coordinators should one be unavailable due to schedule conflicts, illness, or vacations. Substitution should be communicated carefully to avoid confusion. Because people are key, it is important to care for their needs as the institution is heavily dependent on their skills and ability to perform. Be cognizant of their needs for food, water, and rest as well as their ability to communicate with their families. Support them as they help the institution get through the crisis.

Communication

Being able to communicate during a crisis is essential. Stakeholders such as Employees, Customers and Vendors  need to know what is happening as well as what they can/cannot do. Relatives of employees want to know about the safety of individuals on organization. Employees involved in continuity need to know how, when, and where they should report. Continuity plan personnel need to communicate with campus executives on the status of services and resources. Everyone needs to know what they should/should not do and when circumstances are expected to change. Determine alternative means for communication. “Normal” communication means and data feeds for supplying such information such as phone numbers may not be available. Plans should include alternative technologies for communicating and availability of key data. Social networking sites should be considered as an alternative means of communication, but not necessarily as a primary method. Power losses (regardless of cause) may result in disruption of services – cell towers, Internet access, and the campus network. Other failures have equally disruptive consequences. During 9/11 in New York City, dial tone was lost, cell service was spotty and overloaded, and most internet access was disrupted due to loss of the carriers. No services were maintained during Hurricane Katrina. Super Storm Sandy presented major disruptions to infrastructure (electricity, natural gas, communications, roads), routine and emergency services, life/safety services, housing, deliveries (food/water/fuel) and facilities. Many of its impacts are still being experienced today. Identify alternative means (cell phone, text, email, etc.) for contacting individuals needed to manage the process and to provide continuity services. Consider digital signage, landlines or speakers in locations where cell signals are weak/unavailable, CATV, text messaging, social media, and new technologies as they proliferate in classroom, residential, administrative, and service buildings. People need to know what the emergency is, how to react, and what to expect in order to prevent a bad situation from becoming worse. No information, or worse, bad information can transition a bad situation into a crisis. Emergency responders must be contacted, know if/when they are needed, what roles they will play, and where you want them to perform tasks. Remember, people are the key component to business continuity and communication with and among them is absolutely necessary. Communication is also a life/safety concern for the community, not just for first responders. Timely consistent communications are essential before, during, or after natural disasters, weather/natural disasters, lockdowns, and any event that impacts the life/safety of individuals and the availability of services and facilities. It is also important to be able to determine who is ok after an incident. A preset, known means for communication is essential. The Common Alerting Protocol provides a means for dissemination of consistent information via a multitude of technologies. As more systems are built or upgraded to CAP, a single alert can trigger a wide variety of public warning systems, increasing the likelihood that intended recipients receive the alert by one or more communication pathways. CAP provides the capability to include rich content, such as photographs, maps, streaming video and more as well as the ability to geographically-target alerts to a defined warning area, limited only by the capacity of the delivery system used. Because CAP provides the capability to incorporate both text and equivalent audio, CAP alerts can better serve the needs of hearing or visually impaired persons.  Details about CAP, its implementation, terminology, elements, messaging, standards, and implementations can be seen at the above web address. Its intent is to support a means for disseminating consistent, timely messages via multiple technologies to reach as many people as possible. In summary, communications should involve a suite of products/technologies, be activated for life/safety reasons, and must quickly reach as many people as possible.

Training, Maintaining, and Re-assessing Business Continuity Plans

Business continuity plans must include managed, organized procedures for the development of procedures to assure the continuity of operations under extraordinary circumstances including the maintenance of measures to assure the privacy and security of its information resources. It includes training individuals with responsibilities for the plan’s implementation, having regular reviews and updates to keep the plan correct, and for testing the plan to evaluate its feasibility, thoroughness, and effectiveness even under the most unusual of circumstances while maintaining the privacy and security of its information resources.Training of all plan coordinators and key personnel should take place at least once a year. Training should include:
The process, expectations of individuals, applications and resources, priorities, contact information and methods, procedures, documentation, facilities, and schedules. At least once a year a drill should be conducted. This can be a table-top exercise or a “live” test. At the conclusion of the drill, a review of responses and actions should be completed to determine next steps such as modifications to the plan, additional training, and further testing. In addition to drills to test the plan, its components/procedures, and its people, it is critical to test all methods of emergency communication with members of the organizations. Organizations should have multiple methods for contacting members in the event of an emergency or urgent change in regular functions. Everyone (Employees, Customers, contractors, and suppliers) should be enrolled in an emergency communication alert list, including all cell phones which would likely be used for texting messages. Data collected should not be limited to campus supplied phones and email addresses. All information collected will only be used in the event of an emergency and should not be shared outside the organization. Everyone should be prompted at least semi-annually to review/update their data. Drills should be scheduled at least quarterly to test this emergency alert system. Events  in the last year can  demonstrate the necessity for such emergency alert systems using personal communication devices as well as other technologies.

Document and Review Activities – Review the business continuity plan annually
Business Continuity plans are living documents that must change and evolve to reflect institutional changes. To be effective, plans must be continually revised and improved to be in alignment with the current environment. A review should be conducted annually (or more frequently) to document all institutional changes that will impact the plan including:

  • Information gleaned from recent incidents.
  • Information gleaned from plan training and testing.
  • Changes in the Business Impact Analysis.
  • Implementation of new equipment and technology.
  • Organizational restructuring.
  • Major additions or changes to facilities.

A.17.1.1 Planning Information Security Continuity

The organization must determine its requirements for information security and the continuity of information security management in adverse situations, e.g. during a crisis or disaster. The best ISMS’s will already have broader Annex A controls that mitigate against a need to implement a disaster recovery process or business continuity plan in line with A.17.  Despite that effort, more significant disruptive incidents may still happen so planning for them is important.  What happens when a major data center with your information and applications in it becomes unavailable?  What happens when a major data breach occurs, a ransomware attack is made or a key person in the business is out of action, or perhaps Head Office suffers a major flooding ?  Having considered the various events and scenarios that need to be planned for, the organization can then document the plan in whatever detail is required to demonstrate it understands those issues and the steps required to address them.

A.17.1.2 Implementing Information Security Continuity

The organization needs to establish, document, implement and maintain processes, procedures and controls to ensure the required level of continuity for information security during a disruptive situation.  Once requirements have been identified, the organization must implement policies, procedures and other physical or technical controls that are adequate and proportionate in order to meet those requirements. Description of the responsibilities, activities, owners, timescales, mitigating work to be undertaken (beyond risks and policies already in operation e.g. crisis communications). A management structure and relevant escalation trigger points should be identified to ensure that if and when an event increases in severity the relevant escalation to the appropriate authority is made effectively and in a timely manner. It should also be made clear when there is a return to business as usual and any BCP processes stop.

A.17.1.3 Verify, Review & Evaluate Information Security Continuity

The organization must verify the established and implemented information security continuity controls at regular intervals in order to ensure that they are valid and effective during these situations. The controls implemented for information security continuity must be tested, reviewed and evaluated periodically to ensure they are maintained against changes in the business, technologies and risk levels. The auditor will want to see that there is evidence of; Periodic testing of plans and controls; Logs of plan invocations and the actions taken through to resolution and lessons learnt; and Periodic review and change management to ensure that plans are maintained against change.

17.2 Redundancies

Objective:

To ensure availability of information processing facilities.

17.2.1 Availability of information processing facilities

Control

Information processing facilities should be implemented with redundancy sufficient to meet availability requirements.

Implementation guidance

Organizations should identify business requirements for the availability of information systems. Where the availability cannot be guaranteed using the existing systems architecture, redundant components or architectures should be considered. Where applicable, redundant information systems should be tested to ensure the failover from one component to another component works as intended.

Other information

The implementation of redundancies can introduce risks to the integrity or confidentiality of information and information systems, which need to be considered when designing information systems.

A good control describes how information processing facilities are implemented with redundancy sufficiency to meet availability requirements. Redundancy refers to implementing, typically, duplicate hardware to ensure availability of information processing systems. The principle is that if one or more items fail, then there are redundant items that will take over. Critical to this is the testing of redundant components and systems periodically to ensure that fail-over will be achieved in a reasonable time-frame. Redundant components must be protected at the same level or greater than the primary components. Many organizations use cloud based providers so they will want to ensure redundancy is addressed effectively in their contracts with suppliers and as part of the policy in A.15. The auditor will expect to see that testing is carried out on a periodic basis, where redundant components & systems are in place and in the control of the organization.

As a critical element of maintaining continuity of services, there needs to be adequate redundancy of facilities, people, communications, documentation, training, and services. Business Continuity Plans must anticipate a multitude of failures, causes, loss of data or facilities, unavailability of trained personnel, communications losses, powers losses, and more. Plans must assess the risks associated with each critical component and identify redundant/alternative means for providing for continuity of services under all conditions. Due to the nature of business continuity management, it is essential that all elements of a plan have adequate redundancies available, knowing that some elements may be compromised by the nature of the disruption. Redundancies include cross training of personnel, alternate facilities at locations that do not share vulnerabilities, redundant communications methods and providers, power sources, physical access, and more.

BC PLAN – AVOID POTENTIAL SINGLE POINTS OF FAILURE

LOCATION/GEOGRAPHY metro area, flood plain/river bank, avalanche, hurricane or tornado prone, unreliable power source, poor transportation/communication systems, etc.
FACILITIES and INFRASTRUCTURE Power, generators/fuel supplies/suppliers, air conditioning, communications lines-data, voice, multiple high speed network connects, network topology, environmental conditions/hazards, central organization, schools, or admin units
SYSTEMS Lost, damaged, can’t be “touched” or “reached”
DATA Lost, not accessible
PEOPLE Not 24×7 staffing; off hours not on campus, no/limited transportation, not reachable via communications-voice, Internet, cell, text, etc., facilities disabled, unsafe conditions, evacuated, can’t leave campus – government enforced, not cross trained, insufficient backup of skills
DOCUMENTATION must document critical/emergency procedures and recovery procedures, must assume that “usual” trained people are unavailable, need for depth of cross training, docs must be available to all potential users – not just on one, local system or in one place, vendor contacts – office, cell, text, social networking, IM, etc.

Key Considerations

Data is Essential and Must Be Replicated
Data is more important than hardware. Data should be replicated by a variety of means and should be retrievable as needed. Hardware can always be replaced. Be aware of dependencies between software and data. Cloud services may provide viable options for replication as long as security and privacy are maintained.

Alternate Sites for Web Hosting

Consider the impact of a hurricane on physical facilities (which become uninhabitable), life-safety issues (evacuations, flooding, disease, lack of potable water and food, etc.), electrical power/network infrastructures, and an extended prognosis for the restoration of “normal operating conditions.” A business continuity plan should identify alternative means to be used to provide essential services under such unthinkable circumstance. Services should include means for communicating information on the status and safety of the institution and its people to the rest of the world. Consider contracting for an alternate service for communicating key information with on and off campus people while normal institutional web services cannot be provided.

Availability of Information Processing Facilities
Despite the emergency or disruptive circumstances, information processing facilities must continue to function, be accessible for critical processing, and maintaining the security, integrity, and privacy of information. In creating plans, many variables need to be considered when choosing alternative sites, services, personnel, vendors, power/communication means, and accessibility.

Choosing the Right Locations for Locating Emergency Equipment and Locations to Serve as Continuity Centers
First and foremost, consider all types of factors when evaluating locations to house emergency equipment such as electricity generators. As learned from Super Storm Sandy, never locate generators in basements, locations below 100 year flood lines, or locations likely to be inaccessible for fuel deliveries. NYU Medical Center lost the use of all of its power generators when the East River overflowed its banks. Patients had to be evacuated to other hospitals because all power sources were down and all its generators were underwater. Restoration of power took weeks. Physical damage and lost revenues were beyond any expectations as no one expected the water level to rise to the extent it did. Only now are plans being made that consider rising water levels that are likely to recur more frequently. A plan should include the identification of physical locations that will be used to coordinate during and immediately after an incident. Ideally, several locations should be chosen at increasingly distant locations from the organization. This allows for a disruption in a key building, a metropolitan area, and a significant geographic designation while minimizing the impact on a continuity effort. Be cautious and exercise due diligence when considering locations and technologies for potential sites to serve as continuity centers. While some locations and facilities may seen to have some very positive attributes that would seems to make them cost effective choices, there are many critical issues that should be explored. Categories of considerations include:

  • Physical locations .
  • Virtual locations (address security and privacy concerns).
  • Cloud resources (address security and privacy concerns).
  • Availability of sufficient communications excellent/redundant/multi-vendor cell capacity, land lines, internet bandwidth from more than one vendor and physical supply (not all coming through the same conduit, following the same path), and satellite access.
  • Availability of alternative power sources – generators with adequate fuel supply and delivery. (Natural gas is ideal, if available, as long as the location is not prone to flooding, hurricanes, tornadoes, or earthquakes. It minimizes delivery issues.) Multiple suppliers should be contracted for other types of fuel supply. Remember that generators need routine maintenance and testing.
  • Sufficient physical access during emergency situations (not located along a major evacuation route, yet highly accessible).
  • Proximity to locations that contain hazardous material, or are near river banks/flood plains, avalanche zones, mud slide zones, frequent forest fires, or earthquake prone locations.
    Security and support for personnel staffing the continuity effort.

It is not critical that hot sites (physical, virtual, or cloud) be as extensive or as fast as normal resources. They are for emergency use, not daily operations. Communications facilities and contact information must be as accurate and complete as those used for daily operations. They provide the lifeline for all coordination of communication.

Good Vendor Relationships are Important
Establishing good, working relationship with key vendors can help in times of crisis. Resources may need to be replaced. Good relationships may help move your needs to the head of the queue of waiting orders. While there may be many others facing similar problems related to the same or other crises, vendors are sensitive to the problems and will try to assist however and whenever possible when there is an existing relationship.

After the Resumption of Normalcy
While everyone may be tired and anxious to get back to business as usual, bringing all the key individuals to a session to discuss how the plan worked or failed is important. This is a unique opportunity to get direct feedback on the usefulness of the plan. Scheduling a “postmortem” is invaluable in getting constructive feedback as well as complaints that need addressing. Drills are helpful, but a postmortem shares real experiences and feedback.

Back to Home Page

If you need assistance or have any doubt and need to ask any question contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comments and suggestion are also welcome.