ISO 27001:2022 Statement of Applicability

 ISO/IEC 27001:2022 Annex A controlsAppliedControl applied/Justification of InclusionJustification for exclusionResponsibility
5Organization control    
5.1Policies for information securityYesExistence of a Policy is a demonstration of management intent, approach to manage ISMS. To be controlled by  Annual ReviewNAGeneral Manager
5.2Information security roles and responsibilitiesYesExistence of  ISMS organization structure provides defined roles & responsibilities to management staff. To be documented in Organization chart/JDNAISMR
5.3Segregation of dutiesYesSegregation of duties to be done to protect against any kind of fraud. It is to be demonstrated in the  organization chart/JDNAISMR
5.4Management responsibilitiesYesThis is to ensure all personnel do not misuse the information made available to them for the purpose of operations.It is Part of GM roles, IS policies and Objectives, Training in IS to employeesNA EM
5.5Contact with authoritiesYesPart of GM and EM Roles to ensure availability of emergency servicesNAISMR
5.6Contact with special interest groupsYesPart of IT role to ensure access to latest security information/vulnerabilitiesNAIT department
5.7Threat intelligenceYesPart of IT role to collect information about existing and emerging threat environment  and take appropriate mitigation actionNAIT department
5.8Information security in project managementYesPart of PM role to ensure security ‘of, by and for’ projectsNAPM and IT
5.9Inventory of information and other associated assetsYesTo ensure all informations and assets are identified and reasonable security controls are appliesNAEM and IT
5.10Acceptable use of information and other associated assetsYesTo ensure all personnel have accountability of secure usage of information and assetsNAAll users
5.11Return of assetsYesTo ensure all assets are returned to the ownerNAIT department
5.12Classification of informationYesTo provide appropriate level of security sensitivity to the Information/AssetsNAISMR
5.13Labelling of informationYesTo ensure labeling of Information/Assets in line with classificationNAISMR
5.14Information transferYesTo protect information from misuse from information recipients and the medium of information tranferNAPM and IT
5.15Access controlYesTo ensure ‘need to know’ principle in each access to prevent unauthorized access to information and other associated assets.NAEM and IT
5.16Identity managementYesTo ensure identification of individuals and systems accessing the organization’s informationNAEM and IT
5.17Authentication informationYesTo protect sensitive authentication informationNAIT department
5.18Access rightsYesto ensure access to information/ assets is defined and authorizedNAEM and IT
5.19Information security in supplier relationshipsYesTo protect organization interest in dealing with vendorsNAAdmin/Accounts
5.20Addressing information security within supplier agreementsYesTo protect organization interest in dealing with vendorsNAAdmin/Accounts
5.21Managing information security in the ICT supply chainYesTo protect organization interest in dealing with vendorsNAIT
5.22Monitoring, review and change management of supplier servicesYesTo protect organization interest in dealing with vendorsNAAdmin/Accounts
5.23Information security for use of cloud servicesN/ANACloud service not in use 
5.24Information security incident management planning and preparationYesTo ensure incidents are reported and managedNAISMR
5.25Assessment and decision on information security eventsYesTo ensure incidents are reported and managedNAISMR
5.26Response to information security incidentsYesTo ensure incidents are reported and managedNAISMR
5.27Learning from information security incidentsYesTo ensure incidents are reported and managedNAISMR
5.28Collection of evidenceYesTo ensure incidents are reported and managedNAISMR
5.29Information security during disruptionYesTo ensure security in crisisNAISMR
5.30ICT readiness for business continuityYesTo ensure security in crisisNAISMR and IT
5.31Legal, statutory, regulatory and contractual requirementsYesTo protect organization against any legal non compliance from copyright violationNAISMR
5.32Intellectual property rightsYesTo protect organization against any legal non compliance from copyright violationNAISMR
5.33Protection of recordsYesTo ensure availability of historical recordsNAISMR
5.34Privacy and protection of PIIYesTo protect organization against any legal non compliance related to privacyNAISMR
5.35Independent review of information securityYesTo ensure effectivness of the ISMSNAISMR
5.36Compliance with policies, rules and standards for information securityYesTo ensure accountability of managersNAISMR
5.37Documented operating proceduresYesTo ensure processing integrity/process availabilityNAISMR
 6 People control    
6.1ScreeningYesTo ensure people joining the organization are free from any criminal backgroundNAHR/Admin
6.2Terms and conditions of employmentYesEnsure all personnel do not misuse the information made available to them for the purpose of operations.NAHR/Admin
6.3Information security awareness, education and trainingYesEnsure all personnel do not misuse the information made available to them for the purpose of operations.NAHR/Admin
6.4Disciplinary processYesTo ensure a process of appropriate disciplinary action  in case someone is found guilty of information misusage.NAEM
6.5Responsibilities after termination or change of employmentYesProcess of termination involves information/access returnNAHR/Admin
6.6Confidentiality or non-disclosure agreementsYesTo ensure information protection from business partners/employeesNAEM
6.7Remote workingN/ANARemote working not permitted 
6.8Information security event reportingYesTo ensure security events are reported and managed All users
 7Physical control   
7.1Physical security perimetersyesTo ensure physical protection against unauthorized accessNAEM and IT
7.2Physical entryyesTo ensure physical protection against unauthorized accessNAEM and IT
7.3Securing offices, rooms and facilitiesyesTo protect against external and environmental controlsNAIT
7.4Physical security monitoringyesTo protect against external and environmental controlsNAAdmin
7.5Protecting against physical and environmental threatsyesTo protect against external and environmental controlsNAIT
7.6Working in secure areasyesTo protect against external and environmental controlsNAEM and IT
7.7Clear desk and clear screenyesTo protect against unauthorized access/shoulder surfingNAAll users
7.8Equipment siting and protectionyesTo protect physical infrastructureNAIT/Admin
7.9Security of assets off-premisesyesTo protect physical infrastructure PM
7.10Storage mediayesTo ensure only authorized disclosure, modification, removal or destruction of information on storage
media.
NAIT
7.11Supporting utilitiesyesTo ensure continuous power availabilityNAIT
7.12Cabling securityyesTo ensure protection of telecom and network cablesNAIT
7.13Equipment maintenanceyesTo protect physical infrastructureNAIT
7.14Secure disposal or re-use of equipmentyesTo ensure longer life of equipment/Environment protectionNAIT
8Technological Controls    
8.1User endpoint devicesyesTo ensure all information in Endpoint device are secureNAIT
8.2Privileged access rightsyesTo ensure ‘need to know’ principle in each access by ensuring priviledged access right is restricted.NAIT/EM
8.3Information access restrictionyesTo ensure ‘need to know’ principle in each access by ensuring priviledged access right is restricted.NAIT
8.4Access to source codeN/ANASource Code is not maintained by hence this control is not applicable. 
8.5Secure authenticationYesTo protect sensitive authentication informationNAIT/All users
8.6Capacity managementYesTo ensure high availability of Data storageNAIT
8.7Protection against malwareYesTo protect against new malware threatsNAIT
8.8Management of technical vulnerabilitiesYesTo ensure secure operating environmentNAIT
8.9Configuration managementyesTo ensure hardware, software, services and networks function correctlyNAIT
8.10Information deletionYesInformation stored in information systems should be deleted when no longer required.NAAll users
8.11Data maskingN/ANASensitive data not transferred 
8.12Data leakage preventionyesprevent the unauthorized disclosure and extraction of information by individuals or systemsNAIT
8.13Information backupYesTo ensure higher availability of data/associated configurationNAIT
8.14Redundancy of information processing facilitiesYesTo ensure redundancy in information processing infrastructure minimizing failureNAIT
8.15LoggingYesTo ensure accountability and non-repudiationNAIT
8.16Monitoring activitiesYesTo detect anomalous behaviour for potential security incidentNAIT
8.17Clock synchronizationYesTo ensure accountability and non-repudiationNAIT
8.18Use of privileged utility programsYesTo protect network from unauthorized accessNAIT
8.19Installation of software on operational systemsYesTo ensure secure and ligimate software are installed in  secure operating environmentNAIT
8.20Networks securityYesTo ensure protection of networksNAIT
8.21Security of network servicesYesTo ensure protection of networksNAIT
8.22Segregation of networksYesTo ensure minimal impact of network in case of a security attackNAIT
8.23Web filteringyesprevent access to unauthorized web resources and malwareNAIT
8.24Use of cryptographyN/ANACryptographic keys are not proceured or generated and their life cycle is not managed 
8.25Secure development life cycleN/ANANo software development. 
8.26Application security requirementsN/ANANo application 
8.27Secure system architecture and engineering principlesN/ANANo software development. 
8.28Secure codingN/ANANo software development. 
8.29Security testing in development and acceptanceN/ANANo software development. 
8.30Outsourced developmentN/ANANo software development. 
8.31Separation of development, test and production environmentsN/ANANo software development. 
8.32Change managementYesTo ensure control of changesNAISMR
8.33Test informationN/ANANo software development. 
8.34Protection of information systems during audit testingYesTo ensure accountability and non-repudiationNAISMR

Back to Home Page

If you need assistance or have any doubt and need to ask any questions 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:2022 A.5.8 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.
 Information security is to be addressed in project management regardless of the type of 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 a 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 the organization
  3. Understand end to end project flow from the 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, the project user sends and output file back to the 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 of 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 the Application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through the 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, the project has 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 the 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 the project’s many components, including personnel. Major elements of project management effort that require integration include the following processes:
    • Development of the initial project plan
    • Monitoring of progress as the project plan is executed
    • Control of revisions to the project plan
    • Control of changes made to resource allocations as measured performance causes adjustments to the project plan
  2. Project Scope Management
    Project scope management ensures that the project plan includes only those activities necessary to complete it. The scope is the quantity or quality of project deliverables expanding from the original plan and Includes the following processes:
    • Initiation
    • Scope planning
    • Scope definition
    • Scope verification
    • Scope change control
  3. Project Time Management
    Project time management ensures that the project is finished by identified completion date while meeting objectives.  Failure to meet project deadlines is among the most frequently cited failures in project management. Many missed deadlines are rooted in poor planning. Project Time Management includes the 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 the following processes:
    • Resource planning
    • Cost estimating
    • Cost budgeting
    • Cost control
  5. Project Quality Management
    Project quality management ensures that the project adequately meets project specifications. If project deliverables meet the requirements specified in the project plan, the project has met its quality objective. The 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 the project are effectively employed. Staffing project requires careful estimates of the required effort. In information security projects, human resource management has unique complexities, such as Extended clearances and Deploying technology new to the organization. Project  Human Resource Management includes the following processes:
    • Organizational planning
    • Staff acquisition
    • Team development
  7. Project Communications Management
    Project communications convey details of activities associated with the project to all involved. It includes the creation, distribution, classification, storage, and ultimately destruction of documents, messages, and other associated project information. Project Communications Management includes the following processes:
    • Communications planning
    • Information distribution
    • Performance reporting
    • Administrative closure
  8. Project Risk Management
    Project risk management assesses, mitigates, manages, and reduces the 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 the 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 the organization, project managers may simply requisition resources from the organization, or they may have to purchase. Project Procurement Management includes the 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 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 (Sec SDLC). Some aspects of information security are not project-based; rather, they have 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 a 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 has 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 an 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 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. 5.8 Information security in project management

Control

Information security should be integrated into project management.

Purpose

To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle.

ISO 27002 Implementation guidance

Information security should be integrated into project management to ensure information security risks are addressed as part of the project management. This can be applied to any type of project regardless of its complexity, size, duration, discipline or application area (e.g. a project for a core business process, ICT, facility management or other supporting processes). The project management in use should require that:

  • information security risks are assessed and treated at an early stage and periodically as part of project risks throughout the project life cycle;
  • information security requirements (e.g. application security requirements , requirements for complying with intellectual property rights, etc.) are addressed in the early stages of projects;
  • information security risks associated with the execution of projects, such as security of internal and external communication aspects are considered and treated throughout the project life cycle;
  • progress on information security risk treatment is reviewed and effectiveness of the treatment is evaluated and tested.

The appropriateness of the information security considerations and activities should be followed up at predefined stages by suitable persons or governance bodies, such as the project steering committee. Responsibilities and authorities for information security relevant to the project should be defined and allocated to specified roles. Information security requirements for products or services to be delivered by the project should be determined using various methods, including deriving compliance requirements from information security policy, topic-specific policies and regulations. Further information security requirements can be derived from activities such as threat modelling, incident reviews, use of vulnerability thresholds or contingency planning, thus ensuring that the architecture and design of information systems are protected against known threats based on the operational environment. Information security requirements should be determined for all types of projects, not only ICT development projects. The following should also be considered when determining these requirements:

  • what information is involved (information determination), what are the corresponding information security needs (classification) and the potential negative business impact which can result from lack of adequate security;
  • the required protection needs of information and other associated assets involved, particularly in terms of confidentiality, integrity and availability;
  • the level of confidence or assurance required towards the claimed identity of entities in order to derive the authentication requirements;
  • access provisioning and authorization processes, for customers and other potential business users as well as for privileged or technical users such as relevant project members, potential operation staff or external suppliers;
  • informing users of their duties and responsibilities;
  • requirements derived from business processes, such as transaction logging and monitoring, non- repudiation requirements;
  • requirements mandated by other information security controls (e.g. interfaces to logging and monitoring or data leakage detection systems);
  • compliance with the legal, statutory, regulatory and contractual environment in which the organization operates;
  • level of confidence or assurance required for third parties to meet the organization’s information security policy and topic-specific policies including relevant security clauses in any agreements or contracts.

Other information

The project development approach, such as waterfall life cycle or agile life cycle, should support information security in a structured way that can be adapted to suit the assessed severity of the information security risks, based on the character of the project. Early consideration of information security requirements for the product or service (e.g. at the planning and design stages), can lead to more effective and cost-efficient solutions for quality and information security. ISO 21500 and ISO 21502 provide guidance on concepts and processes of project management that are important for the performance of projects. ISO/IEC 27005 provides guidance on the use of risk management processes to identify controls to meet information security requirements.

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 into 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 needs 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 Project life cycle. 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 needs 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. The 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 the 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 is limited to those individuals with a business need to know. Organization IT Services or Technology (Network & Server) team is responsible for the 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 the 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, the 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. The 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 many permissions or just using the Windows OS (due to its popularity, it gets the most malware written for it). During the 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 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 artefacts 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 of the overall PLC process. However, many leaders manage to 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, a 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 risk are to (a) mitigate (reduce the probability of the 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 the 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 a 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 of 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 to 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 enables 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 a 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 the 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. The following should be considered in order to support access restriction requirements

  • Providing menus to control access to application system functions
  • Controlling which data can be accessed by a particular user
  • Controlling the access rights of users, e.g. read, write, delete and execute
  • Controlling the access rights of other applications
  • Limiting the information contained in outputs
  • Providing physical or logical access controls for the isolation of sensitive applications, application data, or systems.
  • 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 to 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 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 functions 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 interactively elaborated endeavor and security should be considered within each PM process or stage. Security checkpoints built into the project during several key processes will ensure progress toward the desired security end state at the 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 security system will avoid costly scope, budget and schedule impacts.

1.Develop Project Charter
The 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 smartphones 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 smartphone 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 hand off 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 of 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 myriads of communication channels PMs utilize every day: email, phone, VOIP, IM, numerous options for document sharing including cloud collaboration, and the newest threat to information security, social media. The ideal defence 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 the 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 a higher impact than publicly available email addresses. Information stolen by bad actors will likely have a higher impact than information inadvertently misdirected. Information that is actively misused will have a higher impact than information stolen with no evidence of intent to misuse. And the 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 smartphone 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 websites 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 on boarding and off-boarding personnel will not only improve the 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 plain text into a coded form referred to as cypher text. Encryption is an almost invisible part of many communications protocols, including web browsing, email, instant messaging, VoIP. Encryption can be especially valuable for the 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 bring 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 the quality of service and price if their privacy and security standards are not adequate. It has been reported that many organizations had experienced a breach of outsourced consumer data. The vendor should provide verifiable evidence that data is secure on their infrastructures 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 smartphones 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 fast 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 behaviour of the wireless card. Handhelds like smartphones 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 a 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 smartphone 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 the 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 wastebaskets/shredders.
  • Use security cables. Educate travellers about the 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 procurement. Requirements elicitation is often not straight-forward; security requirements elicitation maybe 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 a 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 life cycle, 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. Lessons 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 questions 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 are also welcome.

ISO 27001:2022 A.8.1 User Endpoint Device

As per definition in ISO 27002, user endpoint device is a endpoint device used by users to access information processing services. User endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, etc. According to ISO 27001,endpoint device is a network connected information and communication technology (ICT) hardware device. Endpoint device can refer to desktop computers, laptops, smart phones, tablets, thin clients, printers or other specialized hardware including smart meters and Internet of things (IoT) devices.

An endpoint device is a LAN- or WAN-connected hardware device that communicates across a network. Broadly speaking, the term can refer to any network connected device: desktop computers, laptops, smartphones, tablets, printers, or other specialized hardware like POS terminals or retail kiosks, that act as a user endpoint in a distributed network.One of the biggest issues with endpoint devices involves comprehensive security for a network or enterprise system. Security managers must determine whether various endpoint devices could be security gaps for a network – that is, whether unauthorized users can access an endpoint device and use it to pull off important or sensitive data. The endpoints are physical devices that can be linked to your network. The most common examples are laptops, mobile phones, and desktop computers. However, the list keeps growing and now includes many non-traditional gadgets that protect your network resources and limit access:

  • Laptops
  • Mobile phones
  • Desktop computers
  • Printers
  • Appliances
  • Cameras
  • Health trackers
  • Smartwatches
  • Navigation systems
  • Point of sale systems
  • Servers

If a device can connect to the internet, it can be a fully functional part of your endpoint protection. Intruders lurk behind every corner, hoping to catch you off-guard and steal your data.Data loss isn’t the only consequence of endpoint breaches. Intruders can also overwhelm your servers with unwanted web traffic to prevent other users from regaining access.The only way to capitalize on endpoint devices is to limit access. This means you should only allow administrators to adjust security controls and not all employees.endpoint devices can help you set up a bulletproof network. They detect suspicious traffic according to specific criteria. Once they alert you to unusual behavior, you can react on time and keep your organization unharmed.

A.8.1 User Endpoint Device

Control

Information stored on, processed by or accessible via user endpoint devices should be protected.

Purpose

To protect information against the risks introduced by using user endpoint devices.

Guidance

General
The organization should establish a topic-specific policy on secure configuration and handling of user endpoint devices. The topic-specific policy should be communicated to all relevant personnel and consider the following:

  1. the type of information and the classification level that the user endpoint devices can handle, process, store or support;
  2. registration of user endpoint devices;
  3. requirements for physical protection;
  4. restriction of software installation (e.g. remotely controlled by system administrators);
  5. requirements for user endpoint device software (including software versions) and for applying updates (e.g. active automatic updating);
  6. rules for connection to information services, public networks or any other network off premises (e.g. requiring the use of personal firewall);
  7. access controls;
  8. storage device encryption;
  9. protection against malware;
  10. remote disabling, deletion or lockout;
  11. backups;
  12. usage of web services and web applications;
  13. end user behavior analytics
  14. the use of removable devices, including removable memory devices, and the possibility of disabling physical ports (e.g. USB ports);
  15. the use of partitioning capabilities, if supported by the user endpoint device, which can securely separate the organization’s information and other associated assets (e.g. software) from other information and other associated assets on the device.

Consideration should be given as to whether certain information is so sensitive that it can only be accessed via user endpoint devices, but not stored on such devices. In such cases, additional technical safeguards can be required on the device. For example, ensuring that downloading files for offline working is disabled and that local storage such as SD card is disabled. As far as possible, the recommendations on this control should be enforced through configuration management or automated tools.

User responsibility

All users should be made aware of the security requirements and procedures for protecting user endpoint devices, as well as of their responsibilities for implementing such security measures. Users should be advised to:

  1. log-off active sessions and terminate services when no longer needed;
  2. protect user endpoint devices from unauthorized use with a physical control (e.g. key lock or special locks) and logical control (e.g. password access) when not in use; not leave devices carrying important, sensitive or critical business information unattended;
  3. use devices with special care in public places, open offices, meeting places and other unprotected areas (e.g. avoid reading confidential information if people can read from the back, use privacy screen filters);
  4. physically protect user endpoint devices against theft (e.g. in cars and other forms of transport, hotel rooms, conference centers and meeting places).

A specific procedure taking into account legal, statutory, regulatory, contractual (including insurance) and other security requirements of the organization should be established for cases of theft or loss of user endpoint devices.

Use of personal devices

Where the organization allows the use of personal devices (sometimes known as BYOD), in addition to the guidance given in this control, the following should be considered:

  1. a) separation of personal 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 acknowledged 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. In such cases, PII protection legislation should be considered;
  3. topic-specific policies and procedures to prevent disputes concerning rights to intellectual property developed on privately owned equipment;
  4. access to privately owned equipment (to verify the security of the machine or during an investigation), which can be prevented by legislation;
  5. software licensing agreements that are such that organizations can become liable for licensing for client software on user endpoint devices owned privately by personnel or external party users.

Wireless connections

The organization should establish procedures for:

  1. the configuration of wireless connections on devices (e.g. disabling vulnerable protocols);
  2. using wireless or wired connections with appropriate bandwidth in accordance with relevant topic-specific policies (e.g. because backups or software updates are needed).

Other information

Controls to protect information on user endpoint devices depend on whether the user endpoint device is used only inside of the organization’s secured premises and network connections, or whether it is exposed to increased physical and network related threats outside of the organization. The wireless connections for user endpoint devices are similar to other types of network connections but have important differences that should be considered when identifying controls. In particular, back-up of information stored on user endpoint devices can sometimes fail because of limited network bandwidth or because user endpoint devices are not connected at the times when backups are scheduled. For some USB ports, such as USB-C, disabling the USB port is not possible because it is used for other purposes (e.g. power delivery and display output).

Endpoint devices are an integral part of endpoint security. Endpoint security refers to protecting your mobile device, desktop computer, or other endpoints from cyber security attacks. Endpoints often provide perfect gateways to your organizational network, which can be exploited by intruders. Endpoint security minimizes this risk by shielding the points from criminals. It examines your network or enterprise system, processes, and files, for malicious and suspicious activity. If it notices anything fishy, it can alert your security managers so they can react on time and protect your data. One of the most impressive features of endpoint security is that it can be installed on numerous devices. Whether you use smart phones, tablets, laptops, or servers, this strategy helps keep malicious users from infiltrating your network with malware. It can also be deployed alongside other monitoring and detection tactics to mark suspicious actions and prevent data breaches. There are three ways of organizing endpoint protection:

On-location
The on-premise or on-location approach typically involves data on host computers that function as hubs for your management consoles. These devices communicate with your endpoints via different channels to help patch up security gaps. This strategy can work great, but it has a few drawbacks. Primarily, it’s a legacy system. It’s not as advanced as modern solutions since network owners can only manage it within a limited perimeter.

Cloud
If you want to ensure comprehensive security, consider setting up cloud-based endpoint devices. They allow you to manage and monitor nearly all network types in your cloud. Under this arrangement, endpoints are connected to your network remotely. Cloud-based solutions are superior to on-location endpoint security due to their greater scope. You can look past traditional perimeters and enhance your administrator reach.

Hybrid
Another way to safeguard your data assets through endpoints is to set up a hybrid network. It combines cloud and on-location technologies. The strategy has become more prevalent in recent years due to an uptick in remote workers. Organizations have streamlined their legacy systems and integrated with cloud-based endpoints to keep sensitive data intact.

Optimized endpoint security has emerged as a result of such combinations and contains the following software to combat unauthorized access:

  • Machine learning that detects threats
  • Firewall to safeguard against hostiles
  • Email gateways to reduce the risk of phishing
  • Insider protection to neutralize threats from within your network
  • Advanced anti-malware and antivirus to remove malware on your operating systems and endpoint devices
  • Proactive security for safe internet browsing
  • Disk encryption to shield company data

Establishing a User Endpoint Device:

The organisation must be able to demonstrate policy and supporting security controls to reduce the risk posed by user end point devices. As a result of this, it is the organisation’s responsibility to issue a user end point devices policy that should cover the registration/de-registration of devices, physical security requirements, technical security requirements including remote connections, software control, access control and encryption at rest/in transit. The user end point devices. policy should state the businesses requirements for use of devices and when they are appropriate. It is in this policy that the company should specify its 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 are too great. ISO 27001 requires that the organisation determines this, issues a policy stating their intentions and monitors compliance with this policy through an audit or technical controls. For example, a user end point 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 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.

A policy-based approach to network security is paramount when safeguarding a network. The policy should require endpoint devices to meet specific criteria before being granted access to network resources. Security architecture is designed to handle endpoint devices in order to safeguard the data assets accessed through these systems. Companies that allow employees to bring their own device, as in laptops or smartphones, frequently face endpoint device security issues. Without a well-considered bring your own device (BYOD) policy, employee-owned devices may compromise the security of company information, or of the network.

Organizations believe that close to 45% of corporate data is held on endpoint devices. These laptops, tablets and smartphones pose a huge risk to data security. The industry-wide growth of endpoint device exposure means that it’s easier than ever for data to be put at risk. Each time an employee connects over public WiFi, downloads a suspicious app, or is targeted by a phishing scam, the risk is amplified. This is especially important because endpoint devices not only expose their data to possible seizure, they also serve as a potential conduit for a network wide breach of security.
Security policies, especially as they relate to BYOD protections, are an essential part of protecting endpoint devices from being exposed to attack. But the largest contributor to vulnerability is the quality of training and awareness given to employees. Bad habits can have a serious effect on the integrity of a secure network:

  • Lost or improperly decommissioned devices: Employees who lose devices that are connected to the company network may expose that network to attacks.
  • Poor adoption of security updates: Out-of-date operating systems and applications can lead to any number of vulnerabilities within a device that has been given access to sensitive company information.
  • Employees switching encryption off/on: people are more likely to adjust the security controls on devices they own, and will rework settings to suit their needs. This can lead to unwanted access points.
  • With a proactive, always on’ technology, IT can avoid these types of issues, while maintaining compliance and mitigating risk.

Traditionally, endpoint security systems are built on the framework of a client-server model. The security program is managed by a central server that controls the client program installed on all network drives. More recently, with the increasing adoption of software as a service platforms (SaaS), the program and host server are both managed remotely by the SaaS provider. This business model gives organizations a chance to lower costs while ensuring constant updates to security parameters.

The steps involved in establishing the User End point Device Policy

Step 1: Define your scope.

1. Establishing rules people must follow (i.e., policies, standards, procedures) or non-binding recommendations (i.e., guidelines)? Some of both?

2. Do you have a clear definition of what a “user end point devices.” is for your organization?

  • Your organization must define “user end point devices.” as any portable technology running an operating system optimized or designed .
  • Strive to understand what user end point devices. your users actually have and use (including personally owned devices). There may be more of them out there than your expect!

3. Does ownership (i.e., personally owned vs. organization owned) of the device matter?

4. 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 devices. These devices may not work at all, or may break, or may stop working at the next operating system upgrade. Only purchase devices from reputable authorized dealers.
  • It’s A Hard World Out There: Many of the user end point devices 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.
  • 5. Requirements for the protection of digital data?
  • What Device Should You Support?
    It is hard to support “everything” well, and your users may end up more-or-less randomly selecting a 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 devices?
    If you want influence over device selection, are you willing to pay to obtain that influence (e.g., by subsidizing some 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 organizationally owned mobile Internet devices may allow you to do things such as: setting minimum device password length, complexity, the maximum time between changes, max failures before wiping, etc. adding or removing root certificates configuring organizational 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. 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 organizations treat these populations differently.
  • How about Spam and Malware Management On user end point devices.
    Recognize that spammers will target users on any user end point devices. What spam management options do users have for a given service? How can they report spam that slips through? Malware may target users of Your security team and/or operational support staff should talk about how they want to approach issues such as spam and malware on supported user end point devices..
  • How About Hardware and Data Encryption?
    Personally identifiable information (“PII”) is a material concern at many sites. Do the user end point devices. you’ve chosen to support have hardware encryption? Is that encryption solid enough to meet your PII protection requirements? Similarly, some user end point 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 organizational data. Make sure devices that store organizational 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 user end point devices, do you need the ability to remotely send the device 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)

5. Organizational Contact With Users’ Mobile Devices
Many Organizations ask their employees, vendors and customers to register their mobile numbers 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 user end point 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.

 6. Requirements for the protection of personal privacy?
user end point devices devices can potentially have profound privacy implications. By way of example, almost all 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. Most of the 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 devices need 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 the use of mobile devices while driving.

7. Defining acceptable use in general? You will likely want to treat employee devices differently from vendors devices. What about guests?

8. Does existing physical asset, technology or data-specific policy cover all or part of your defined scope?
If not, consider revising the existing policy. Doing so may be easier or more desirable than crafting a 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 the policy.

9. 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 some of the user end point devices. devices may be different from more familiar computing technologies.

Step 2: High-Level Threats and Vulnerabilities

User end point devices. typically need to support multiple security objectives. These can be accomplished through a combination of security features built into the devices and additional security controls applied to the devices and other components of the enterprise IT infrastructure. The most common security objectives for 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, user end point devices should be secured against a variety of threats. Before designing and deploying the device solutions, organizations should develop system threat models for these devices and the resources that are accessed through these devices. Threat modelling 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 modelling helps organizations to identify security requirements and to design the 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
Some of the user end point devices may be used in a variety of locations outside the organization’s control, such as employees’ homes, coffee shops, hotels, and conferences. The mobile nature of those devices makes them much more likely to be lost or stolen , so their data is at increased risk of compromise. When planning user end point device security policies and controls, organizations should assume that some of these mobile devices may 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 device or the organization’s resources accessible through the device. Many device usually has a single authentication—not a separate account for each user of the device—as it is generally assumed that the device only has one user. 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 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 device is always in the possession of its owner, there are other physical security risks, such as an attacker looking over a remote worker’s shoulder at a coffee shop and viewing sensitive data on the device’s screen (for example, a password is 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 devices, particularly those that are personally owned (bring your own device, BYOD), are not necessarily trustworthy. Some devices may 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 user end point devices devices not properly secured by the organization are not be be trusted unless the organization monitors their security continuously while in use with enterprise applications or data. There are several possible mitigation strategies related to using of untrusted devices. One option is to restrict or prohibit the use of BYOD devices, thus favoring organization-issued devices. Another effective technique is to fully secure each organization-issued device; this gets the 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
Many of the user end point devices. devices may use non-organizational networks for Internet access outside the premise of the organization, 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 user end point device will only be used on trusted networks controlled by the organization, organizations should plan their user end point devices security on the assumption that the networks cannot be trusted. The 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 the 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
Many of the user end point devices such as mobile phones are designed to make it easy to find, acquire, install, and use third-party applications from application stores. This poses obvious security risks, especially for the device platforms and application stores that do not place security restrictions or other limitations on third-party application publishing. Organizations should plan their device security on the assumption that unknown third-party applications downloadable by users should not be trusted. The 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 device, or implementing a secure sandbox/secure container that isolates the organization’s data and applications from all other data and applications on the device. Another possible mitigation is to perform a risk assessment on each third-party application before permitting its use on the organization’s devices. It is important to note that even if these mitigation strategies are implemented for third-party applications, users can still access not trusted web-based applications through browsers built into their devices. The risks inherent in this can be reduced by prohibiting or restricting browser access; by forcing 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 device’s built-in browser for other uses.

5. Interaction with Other Systems
Some user end point 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 wireless or via a cable for syncing. It can also involve tethering, such as using one device to provide network access for another 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, the 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 not trusted 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; the transmission of malware from device to device is also a possibility. There are also concerns regarding devices exchanging data with each other. The mitigation strategies depend on the type of attachment. Preventing an organization-issued device from syncing with a personally-owned device necessitates security controls on the device that restrict what devices it can synchronize with. Preventing a personally-owned device from syncing with an organization-issued computer necessitates security controls on the organization-issued devices. Preventing the use of remote backup services can possibly be achieved by blocking the use of those services (e.g., not allowing the domain services to be contacted) or by configuring the devices not to use such services. Users should be instructed not to connect their devices to unknown charging devices; they should carry and use their own charging devices. Finally, 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 not trusted Content
Many of the user end point devices. devices may use not trusted content such as a Quick Response (QR) codes. They are specifically designed to be viewed and processed by device cameras. Each QR code is translated to text, typically a URL, so malicious QR codes could direct 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 not trusted content and to discourage users from accessing not trusted content with any devices they use for work. Another mitigation is to have applications, such as QR readers, display the non obfuscated 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 devices, such as disabling camera use in order to prevent QR codes from being processed.

7. Use of Location Services
Some of the user end point devices with GPS capabilities typically run what is 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 applications. In terms of organizational security and personal privacy, 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 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 the 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 user end point devices.

Centralized user end point device management technologies are a growing solution for controlling the use of both organization-issued and personally-owned devices by enterprise users. In addition to managing the configuration and security of devices, these technologies offer other features, such as providing secure access to enterprise computing resources. 

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:

  1. Restrict user and application access to hardware, such as the digital camera, GPS, Bluetooth interface, USB interface, and removable storage.
  2. Restrict user and application access to native OS services, such as the built-in web browser, email client, calendaring, contacts, application installation services, etc.
  3. Manage wireless network interfaces (Wi-Fi, Bluetooth, etc.)
  4. 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
  5.  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 encrypted data communications between the 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 not trusted hands and is at risk of having its data recovered by an non trusted 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.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions 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:2022 A.6.7 Remote working

Remote working 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.). Remote working 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 Remote working 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 an 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 REMOTE WORKING

Both employers and employees have found remote working 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 a child and eldercare.
  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 the 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 Remote Working

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 remote working, 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 remote working 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.7 Remote working

Control

Security measures should be implemented when personnel are working remotely to protect information accessed, processed or stored outside the organization’s premises.

Purpose

To ensure the security of information when personnel are working remotely.

ISO 27002 Implementation guidance

Remote working occurs whenever personnel of the organization work from a location outside of the organization’s premises, accessing information whether in hard copy or electronically via ICT equipment. Remote working environments include those referred to as “teleworking”, “telecommuting”, “flexible workplace”, “virtual work environments” and “remote maintenance”.
NOTE: It is possible that not all the recommendations in this guidance can be applied due to local legislation and regulations in different jurisdictions.
Organizations allowing remote working activities should issue a topic-specific policy on remote working that defines the relevant conditions and restrictions. Where deemed applicable, the following matters should be considered:

  1. the existing or proposed physical security of the remote working site, taking into account the physical security of the location and the local environment, including the different jurisdictions where personnel are located;
  2. rules and security mechanisms for the remote physical environment such as lockable filing cabinets, secure transportation between locations and rules for remote access, clear desk, printing and disposal of information and other associated assets, and information security event reporting;
  3. the expected physical remote working environments;
  4. the communications security requirements, taking into account the need for remote access to the organization’s systems, the sensitivity of the information to be accessed and passed over the communication link and the sensitivity of the systems and applications;
  5. the use of remote access such as virtual desktop access that supports processing and storage of information on privately owned equipment;
  6. the threat of unauthorized access to information or resources from other persons at the remote working site (e.g. family and friends);
  7. the threat of unauthorized access to information or resources from other persons in public places;
  8. the use of home networks and public networks, and requirements or restrictions on the configuration of wireless network services;
  9. use of security measures, such as firewalls and protection against malware;
  10. secure mechanisms for deploying and initializing systems remotely;
  11. secure mechanisms for authentication and enablement of access privileges taking into consideration the vulnerability of single-factor authentication mechanisms where remote access to the organization’s network is allowed.

The guidelines and measures to be considered should include:

  1. the provision of suitable equipment and storage furniture for the remote working activities, where the use of privately-owned equipment that is not under the control of the organization is not allowed;
  2. a definition of the work permitted, the classification of information that can be held and the internal systems and services that the remote worker is authorized to access;
  3. the provision of training for those working remotely and those providing support. This should include how to conduct business in a secure manner while working remotely;
  4. the provision of suitable communication equipment, including methods for securing remote access, such as requirements on device screen locks and inactivity timers; the enabling of device location tracking; installation of remote wipe capabilities;
  5. physical security;
  6. rules and guidance on family and visitor access to equipment and information;
  7. the provision of hardware and software support and maintenance;
  8. the provision of insurance;
  9. the procedures for backup and business continuity;
  10. audit and security monitoring;
  11. revocation of authority and access rights and the return of equipment when the remote working activities are terminated.

Establishing Remote working

Allowing employees to work away from the office, i.e., outside of the physical premises of the organization know as “Remote working”) 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.
  • Hard copy material used at the remote worksite 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. The 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 work remotely (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 by remote working (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 remote workers 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 remote working. 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 Remote working program

Identify a Remote working Coordinator
If you plan to implement Remote working with 10 or more employees, it is recommended to identify one employee as the Remote working coordinator. This person should manage the overall Remote working program to help improve the quality and effectiveness of your organization’s program. The Remote working coordinator, typically an individual in human resources, is responsible for organizing Remote working schedules, arranging proper equipment for each remote worker, tracking program progress and promoting the benefits of Remote working among employees.

Establish a Remote working Committee
The first action for the Remote working 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 Remote working committee should be responsible for determining the three most important elements of your company’s program: policy, training and evaluation.

Create a Remote working Policy
Good communication is the essential element of a successful Remote working program and all employees should know the program’s guidelines and expectations. The Remote working policy should define program parameters, including which positions are best suited for Remote working. Additionally, the policy should include necessary forms or documentation, including a Remote working contract/agreement. Below is an outline of the most important elements for a Remote working 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 Remote working 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 Remote working typically involves a cultural change within the organization, each employee and manager should receive training on the Remote working 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 Remote working
One of the major challenges for supervisors is determining who is a candidate for Remote working. This can be a difficult task, as managers may experience employees who want to Remote working, but are not the best candidate to do so. Managers also may be concerned that if one person is allowed to Remote working, all employees will want to Remote working.

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 Remote working situation is to determine certain criteria to be eligible for Remote working, 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 remote working. The decision process to grant employees the option to Remote working 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 Remote working. This form should allow a manager to rate an employee on characteristics that lead to success in Remote working.

Job Suitability
In addition to determining if an employee possesses the right skills to handle a Remote working 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 Remote working arrangement; however, if the position is broken down into individual tasks, you may be able to identify tasks that could be accomplished in a Remote working setting. Remote working 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 Remote working opportunity. As an alternative, the employee may be able to Remote working one day a week, or half a day for two days a week.

Breaking the Cultural Barriers
A Remote working 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. Positions that are not suitable for teleworking typically require:also creates the challenge of keeping workers, whether they are teleworking or not, working as a team to achieve one common goal. Before implementing Positions that are not suitable for teleworking typically require: 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 Remote workers. 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

Trust your remote workers at all times and demonstrate this trust by assigning challenging projects once the employee delivers a strong performance

  • Include remote works in surveys and evaluations
  • Manager must try teleworking yourself when they have the opportunity. It will help increase personal effectiveness and improve understanding of the pros and cons of teleworking
  • Consider remote worker’s point of view in all situations. Understand the time frames involved in completing tasks and the resources required to complete them
  • Involve remote workers when setting work goals and objectives
  • Delegate assignments fairly among teleworkers and non-teleworkers
  • Include remote workers in day-to-day activities. Be aware of your remote workers’ attitudes and involvement to ensure they don’t feel isolated from the main office
  • Encourage informal communication within your team to keep remote workers 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 remote working if it is working well for the employee
  • Keep an open mind about remote working. Be flexible with the program’s policies and procedures in case they need to be adjusted for any reason

Choosing the Right Remote working Tools
Before launching a remote work 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 Remote work, 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 remote worker, and they do not address the “myths” or concerns that managers have when considering remote work. 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 remote worker and office worker with high-speed Internet, a Web camera, headset and collaboration software, managers can get in touch with Remote workers 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:  

  • Remote workers 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
  • Remote working employees during online meetings to avoid a fear of loss in productivity.
  • Management and Remote workers can see who is available online for a meeting or quick discussion via instant messaging with 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, white boarding, 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 Remote Working program.

Select a Collaboration Tool
After establishing specific policies, procedures and measurement methods for your Remote working 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 the 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 Remote working , 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 remote working 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 detection 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 add on, 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 Remote working program. However, if you approach this in a gradual fashion, giving time to work through new issues, success is highly achievable. When initiating a Remote working 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 Remote working 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 Remote working program and decide if they would like to participate or not, then you should move into launching the program.

Maintain Balance
Once a Remote working program is underway, it is important to emphasize equality between remote workers and office workers. 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 Remote working 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, behaviours 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 Remote working 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 remote workers are not in the office to receive quick, informal feedback, make a conscious effort to send an instant message to remote workers 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 an overall improvement in employee morale and productivity.

Evaluate the Program
In order to measure the success of the Remote working program, the Remote working 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 Remote working 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 Remote working, 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 remote workers and office workers on selected measures at one point in time. Also, conduct pre- and post-measurements on the remote workers 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 Remote working. 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 Remote working 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 Remote working program begins. In addition to these measures on individual employees, anecdotal data may also be helpful. In evaluating the costs of Remote working, allow sufficient time for implementation before studying costs. In the initial months of Remote working, 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 Remote working situation. In addition to looking at overall morale and retention, it is important to measure specific aspects of satisfaction with Remote working. 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 Remote working 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 Remote working

Remote working 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 centre, 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 the 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. The 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.

Security Issues for Protecting Internal Systems
In planning for the security of remote working, 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.

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 network 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 an 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 the access needs of telecommuters. For example, computers with high-risk organizational data (such as proprietary business plans) may be separated by the 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, the 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.

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 the email if it is relied on 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.

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 upon 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.

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.

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.

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:

  • 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.
  • Removable hard drives. If corporate data is stored on a removable hard drive (or floppy), then the risk is greatly reduced.
  • Data encryption. Corporate data can be kept encrypted on the hard disk. This will protect its confidentiality and will detect changes to files.
  • Dedicated use. If an organization requires this, it should recognize that it is difficult to enforce.

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, a 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.

Security Issues for Telecommuting Centers
Telecommuting centres, normally located in outlying suburbs, are another choice for organizations. From a security perspective, hey 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 centres. If communications encryption is supported by the centre, the netizen should be aware that data may not be encrypted while it is inside the centre. The encryption may occur at a modem pool.

Remote working – 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 the net
The Remote worker’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 the internet
Consider the nature of the access required by a Remote worker. 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 defenses. Hence, by extending the network to the Remote worker’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 authorization 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 have 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.

Security Policy

  • who may work remotely – identify the roles/jobs which may be considered for teleworking
  • services available to Remote workers – the types of network and application services which may be provided to Remote workers
  • information restrictions – are there classified information types which should not be made available to Remote workers?
  • 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 Remote worker’s PC configuration be protected, updated and monitored?
  • User guidelines – clarify the user’s role in protecting corporate resources – eg., appropriate use of resources; the 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 Remote working, how those risks are addressed, and the user’s role in minimizing the risks
  • 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.
  • 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.

Firewalls
The corporate perimeter defenses 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 certain home firewall products that are effective in blocking uninvited inbound traffic. However, there are also products that 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 that have not been specifically authorized 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. The 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.

Virus protection
Anti-virus software is an essential measure on any web user’s PC, whether or not they remote working. 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.

Data protection
If corporate data will be stored on the remote PC, then it should be protected by encryption software. There are packages that 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.

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.

Identify, authenticate and authorize remote connections
It is vital that only authorized 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 authorized. 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 authorized 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 behavior of a hacker might be effectively identified.

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 unauthorized 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 minimized 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.

Protect corporate resources from the remote PC

Monitor traffic and behavior
VPN technology is a powerful tool to ensure the gritty 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 behavior. 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. lso, 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.

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 authorization 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.

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.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions 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:2022 A 5.35 Independent review of information security, A 5.36 Compliance with policies, rules and standards for information security

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. 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.

A.5.35 Independent review of information security

Control

The organization’s approach to managing information security and its implementation including people, processes and technologies should be reviewed independently at planned intervals, or when significant changes occur.

Purpose

To ensure the continuing suitability, adequacy and effectiveness of the organization’s approach to managing information security.

ISO 27002 Implementation guidance

The organization should have processes to conduct independent reviews. Management should plan and initiate periodic independent reviews. The reviews should include assessing opportunities for improvement and the need for changes to the approach to information security, including the information security policy, topic-specific policies and other controls. Such reviews 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 competence. The person conducting the reviews should not be in the line of authority to ensure they have the independence to make an assessment. The results of the independent reviews should be reported to the management who initiated the reviews and, if appropriate, to top management. These records should be maintained. If the independent reviews identify that the organization’s approach and implementation to managing information security is inadequate [e.g. documented objectives and requirements are not met or are not compliant with the direction for information security stated in the information security policy and topic-specific policies , management should initiate corrective actions. In addition to the periodic independent reviews, the organization should consider conducting independent reviews when:
a) laws and regulations which affect the organization change;
b) significant incidents occur;
c) the organization starts a new business or changes a current business;
d) the organization starts to use a new product or service, or changes the use of a current product or service;
e) the organization changes the information security controls and procedures significantly.

Other information

ISO/IEC 27007 and ISO/IEC TS 27008 provide guidance for carrying out independent reviews.

The overarching aim is for management to create and implement processes that cater for independent reviews of their information security practices.The independent review should be conducted by the Management. An independent review is necessary to ensure the continuing suitability, adequacy and effectiveness of 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. 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. Reviews should focus on any changes that are required to improve an organisation’s approach to information security, including:

  • The information security policy.
  • Topic-specific policies.
  • Related controls.

If the independent review identifies inadequacies in the approach or implementation of information security, e.g. documented objectives and requirements are not met or not compliant with the direction for information security stated in the information security policies and standards, management should consider corrective actions. The organization that seeking for ISO 27001 certification (ISMS) must maintains a ‘Master List of Independent Information Security Reviewers. For each independent review, the certified ISO 27001 organization chooses reviewer(s) from its ‘Master List of Independent Information Security Reviewers’ and gets the review done. Reports submitted by the independent reviewers shall discussed immediately with the top management and the concerned department within the organization, and, necessary corrective and/or preventive actions are taken. The outcome of independent review and actions taken would be discussed in the subsequent management review as well. Alongside periodic reviews, it may be necessary to initiate ad-hoc reviews. These reviews can be justified across 5 key areas:

  • Any laws, guidelines or regulations are amended which affect the organisation’s information security operation.
  • Major incidents occur that have an impact on information security (data loss, intrusion etc).
  • A new business is created, or major changes are enacted to the current business.
  • The organisation adopts a new product or service that has information security implications, or makes underlying changes to a current product or service.
  • Major changes are made to the organisation’s bank of information security controls, policies and procedures.

Such an independent review is required to ensure that the organization ‘s approach to information security management remains consistent, appropriate, and efficient. The analysis will include an assessment of improvement opportunities and the need to change the security approach, including policy and control objectives. Such a review would need to be conducted by people independently of the area being reviewed, e.g. an internal audit function, an independent manager, or a specialized external party organization. Those who conduct these reviews should have the skills and experience needed. The independent review results must be recorded and reported to the management responsible for initiating the review. These records are to be maintained. When, for example, the defined aims and objectives and needs of the company are not met in compliance with the guiding principle for security of information as set out in the information security policy. Reviewers should seek to establish whether or not information security practices are compliant with the organisation’s “documented objectives and requirements” stated within the information security policy, or any topic-specific policies.Management should pursue corrective measures. 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. The objective is to ensure that information security is implemented and operated in accordance with the organizational policies and procedures. 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 organizations, an independent review may include representatives from legal counsel, an executive leadership team, and/or a system office.

A 5.36 Compliance with policies, rules and standards for information security

Control

Compliance with the organization’s information security policy, topic-specific policies, rules and standards should be regularly reviewed.

Purpose

To ensure that information security is implemented and operated in accordance with the organization’s information security policy, topic-specific policies, rules and standards.

ISO 27002 Implementation guidance

Managers, service, product or information owners should identify how to review that information security requirements defined in the information security policy, topic-specific policies, rules, 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:
a) identify the causes of the non-compliance;
b) evaluate the need for corrective actions to achieve compliance;
c) implement appropriate corrective actions;
d) review corrective actions taken to verify its effectiveness and identify any deficiencies or weaknesses.
Results of reviews and corrective actions carried out by managers, service, product or information owners 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.
Corrective actions should be completed in a timely manner as appropriate to the risk. If not completed by the next scheduled review, progress should at least be addressed at that review.

Department Managers have a 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. Department managers are responsible for all initial and recurring security incident policy training of workforce members, and for enforcing computer and data security policies and standards. Managers should identify how to review and assess that information security requirements defined in policies, standards and other applicable regulations are met. If any non-compliance is found as a result of the review, managers should:
a) Identify the causes of the non-compliance;
b) Evaluate the need for actions to achieve compliance;
c) Implement appropriate corrective action;
d) 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

Many organizations 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. ISMS managers should regularly review the compliance of information processing and procedures within their area of responsibility Managers will determine how information security criteria identified in policies, standards, and other regulations are to be assessed. For efficient routine analysis, automated measuring and reporting tools should be considered.If any failure to comply results from the review are detected, managers should:-

  • Identify the reasons of failure to comply;
  • Assess the need for compliance measures;
  • Implement effective remedial measures;
  • Review the steps taken to verify their efficiency and recognize any deficiencies or vulnerabilities.

Details of the managers’ assessments and disciplinary measures should be reported and documented. If an independent review takes place within its area of responsibility, administrators will report the findings to individuals conducting independent reviews

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 complies 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-conformity too.  Staff awareness and engagement is also important to tie into this part for compliance confidence.

Technical compliance should be reviewed, either by IT or as part of an independent review, 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. 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 to 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 life cycle (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:2022 A 5.29 Information security during disruption

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 organizations 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 mudslides that results in evacuations and inaccessibility to critical resources.
  • 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 tabletop 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.

Control

The organization should plan how to maintain information security at an appropriate level during disruption.

Purpose

To protect information and other associated assets during disruption.

ISO 27001 Implementation Guidance

The organization should determine its requirements for adapting information security controls during disruption. Information security requirements should be included in the business continuity management processes. Plans should be developed, implemented, tested, reviewed and evaluated to maintain or restore the security of information of critical business processes following interruption or failure. Security of information should be restored at the required level and in the required time frames. The organization should implement and maintain:
a) information security controls, supporting systems and tools within business continuity and ICT continuity plans;
b) processes to maintain existing information security controls during disruption;
c) compensating controls for information security controls that cannot be maintained during disruption.

Other information

In the context of business continuity and ICT continuity planning, it can be necessary to adapt the information security requirements depending on the type of disruption, compared to normal operational conditions. As part of the business impact analysis and risk assessment performed within business continuity management, the consequences of loss of confidentiality and integrity of information should be considered and prioritized in addition to the need for maintaining availability. Information on business continuity management systems can be found in ISO 22301 and ISO 22313. Further guidance on business impact analysis (BIA) can be found in ISO/TS 22317.

The objective of this control is Information security continuity should be embedded in the organization’s business continuity management systems.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. 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.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.

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. An organization should ensure that:

  1. 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;
  2. incident response personnel with the necessary responsibility, authority, and competence to manage an incident and maintain information security are nominated;
  3. 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:

  1. information security controls within business continuity or disaster recovery processes, procedures, and supporting systems and tools;
  2. processes, procedures and implement changes to maintain existing information security controls during an adverse situation;
  3. compensating controls for information security controls that cannot be maintained during an adverse situation.

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.

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. 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:

  1. 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;
  2. 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;
  3. 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.

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.

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 will already have broader Annex A controls that mitigate against a need to implement a disaster recovery process or business continuity plan .  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 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.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.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 learned, and Periodic review and change management to ensure that plans are maintained against change.

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 how, when, where, who, and what will be needed should a disruption of normal operations occur. 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.

Planning Information Security Continuity

Information security must be an integral part of all organizational policies, procedures, and practices. Information security should also be an integral element of a business continuity management system. Business continuity plans must recognize the need to strictly adhere to organizational security and privacy policies and regulations, even while the organization is functioning during extraordinary conditions. Good business continuity plans should be built in accordance with strong organizational 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 an 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 the 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. Organizational 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 organizations. 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 organization 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 Organizations has No Strategic Plans for Disaster Recovery. Data reveal that a large number of organizations 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 the 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 organization 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 organization.

Business Impact Analysis – Identify Critical Resources
A Business Impact Analysis (BIA) identifies the organization’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 the 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 the 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 the 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 websites, 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 elements 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 a critical time. Team coordinators should be involved in the 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 organization 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 organization 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 in the 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 the 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 the 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 the 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 the 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 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 the 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 text 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 organizational 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 organizational 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.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions 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:2022 ,A 5.24 Information security incident management planning and preparation,A 5.25 Assessment and decision on information security events, A 5.26 Response to information security incidents, A 5.27 Learning from information security incidents , A 5.28 Collection of evidence

Software complexity, near-universal worldwide connectivity, and the criminals determined to profit from these factors make information security incidents inevitable. The goal of an effective information security incident management strategy is a balance of driving the impact of the incidents down while processing incidents as efficiently as possible. Good incident management will also help with the prevention of future incidents. How this plays out is to develop a program that prepares for incidents. From a management perspective, it involves the identification of resources needed for incident handling, as well as developing and communicating the formal detection and reporting processes. An effective security program includes important aspects of detecting, reporting, and responding to adverse security events as well as weaknesses that may lead to events if they are not appropriately addressed. The primary elements of incident management are:

Effective incident response in many organizations other than IT, involve having trained personnel equipped and ready for response. So it is with information security incident management. Having trained individuals ready to respond with advance preparation is the first task. Designing an effective means of the detection of incidents is also essential and this often consists of trained users and administrators, together with technical controls. Effective, appropriate communication at all levels of an organization is essential for limiting the impact of security events, using formal detection and reporting processes. All members of the community should be trained and comfortable regarding procedures for reporting failures, weaknesses, and suspected incidents; methods to recognize and detect problems with security protections; as well as how to escalate reporting appropriately. In addition, technical controls must be implemented for the automated detection of security events, coupled with as near real-time reporting as possible, to investigate and initiate immediate responses to problems. For new IT systems, often the best time to develop automated detection of security events is when the preventive security controls are being architected. Confirmation of an adverse security event is an inevitable outcome in any organization. A formal management procedure and policy for incident response, including roles and responsibilities for each aspect of the response, is essential. Aspects include funding and cost models, analysis, containment, and recovery responsibilities, decision-making authority for notifications; legal and/or law enforcement involvement; forensic investigations; responsibility for after-incident debriefing; and policy, procedure, and process improvements.

No matter the extent of the defenses, it inevitable that Information Security Incidents will occur. For this reason, establishing, periodically assessing, and continually improving incident management processes and capabilities is very important. If you are just getting started in this area of your security program, then the following areas are very useful stepping stones that are covered in this chapter:
1. Define what constitutes an information security incident and review how varied incidents can be classified.
2. Consider what constitutes an information security incident that requires special handling (vs. common security events). Review incident classification schemes that allow for aligning handling procedures to potential impacts and risks.
3. Identify and establish essential roles and procedures needed for effective incident management.
4. Evaluate the technical and operational capabilities of your organization to detect and respond to security incidents. Consider how senior management support can be gained to formalize effective incident management processes. Formulate procedures and workflow for effectively addressing incidents throughout the life cycle
5. Create effective communication, coordination, and reporting plans for a broad spectrum of incidents including data breach events.
6. Identify key partners and stakeholders and levels of communication and engagement. Review the legal and contractual communication requirements associated with data types that may be involved in Information Security Incidents.
7. Adapt and learn from security incidents and strive for continual improvement by identifying and planning for training needs and enhancement of response capabilities.

The reality of security incidents, breaches, and loss of data has become all too familiar to a growing number of organizations. Efforts to be prepared need to be engaged prior to these episodes occurring through a comprehensive approach involving on-premise, qualified team construction, vendor participation, appropriate insurance or retainers, and organizational counsel. The best reaction to an information security incident is being proactive and the worst is proceeding without caution, expertise, and proper guidance. If qualified personnel does not exist on staff, external assistance needs to be contracted and ready to employ. Without previous agreements, even qualified vendors may have difficulties meeting your required timeline. Proceeding without a consistent, fully-developed response plan can lead to lost evidence, data, and inability to verify loss and recovery leading to a false sense of containment and resolution of the event. The incident management plan should be clear, concise describing the steps to be taken, resources utilized and their respective roles, and the timelines under which the tasks are to be performed. The getting started section included articles, papers, presentations, sample policies flowcharts, and checklists to help an organization get the process started. The remainder of this document provides resources and processes to help ensure that a proper and complete assessment, analysis, containment, and response are in order.

A 5.24 Information security incident management planning and preparation

Control

The organization should plan and prepare for managing information security incidents by defining, establishing and communicating information security incident management processes, roles and responsibilities.

Purpose

To ensure quick, effective, consistent and orderly response to information security incidents, including communication on information security events.

ISO 27002 Implementation Guidelines

Roles and responsibilities
The organization should establish appropriate information security incident management processes. Roles and responsibilities to carry out the incident management procedures should be determined and effectively communicated to the relevant internal and external interested parties.
The following should be considered:
a) establishing a common method for reporting information security events including point of contact;
b) establishing an incident management process to provide the organization with capability for managing information security incidents including administration, documentation, detection, triage, prioritization, analysis, communication and coordinating interested parties;
c) establishing an incident response process to provide the organization with capability for assessing, responding to and learning from information security incidents;
d) only allowing competent personnel to handle the issues related to information security incidents within the organization. Such personnel should be provided with procedure documentation and periodic training;
e) establishing a process to identify required training, certification and ongoing professional development for incident response personnel.
Incident management procedures
The objectives for information security incident management should be agreed with management and it should be ensured that those responsible for information security incident management understand the organization’s priorities for handling information security incidents including resolution time frame based on potential consequences and severity. Incident management procedures should be implemented to meet these objectives and priorities. Management should ensure that an information security incident management plan is created considering different scenarios and procedures are developed and implemented for the following activities:

a) evaluation of information security events according to criteria for what constitutes an information security incident;
b) monitoring , detecting , classifying , analysing and reporting of information security events and incidents (by human or automatic means);
c) managing information security incidents to conclusion, including response and escalation according to the type and the category of the incident, possible activation of crisis management and activation of continuity plans, controlled recovery from an incident and communication to internal and external interested parties;
d) coordination with internal and external interested parties such as authorities, external interest groups and forums, suppliers and clients ;
e) logging incident management activities;
f) handling of evidence;
g) root cause analysis or post-mortem procedures;
h) identification of lessons learned and any improvements to the incident management procedures or information security controls in general that are required.
Reporting procedures
Reporting procedures should include:
a) actions to be taken in case of an information security event (e.g. noting all pertinent details immediately such as malfunction occurring and messages on screen, immediately reporting to the point of contact and only taking coordinated actions);
b) use of incident forms to support personnel to perform all necessary actions when reporting information security incidents;
c) suitable feedback processes to ensure that those persons reporting information security events are notified, to the extent possible, of outcomes after the issue has been addressed and closed;
d) creation of incident reports.
Any external requirements on reporting of incidents to relevant interested parties within the defined time frame (e.g. breach notification requirements to regulators) should be considered when implementing incident management procedures.

Other information

Information security incidents can transcend organizational and national boundaries. To respond to such incidents, it is beneficial to coordinate response and share information about these incidents with external organizations as appropriate. Detailed guidance on information security incident management is provided in the ISO/IEC 27035
series.

Preparation involves the identification of resources needed for incident handling and having trained individuals ready to respond, and developing and communicating a formal detection and reporting process. Effective, appropriate communication at all levels of an organization is essential for limiting the impact of security events. The policy can have the following components:

  • Statement of management commitment
  • Purpose and objectives of the policy
  • Scope of the policy (to whom and what it applies and under what circumstances)
  • Definition of computer security incidents and their consequences within the context of the organization
  • Prioritization or severity ratings of incidents
  • Performance measures
  • Reporting and contact resources

Organizational structure and delineation of roles, responsibilities, and levels of authority should include the authority of the incident response team to confiscate or disconnect equipment, monitor suspicious activity, and the requirements for reporting certain types of incidents.

Prioritization of incidents is an important element, as are escalation procedures. Interestingly, incident priorities differ between organizations depending on their culture and other policies, and there are certain types of incidents that one organization may tolerate while another may not. In addition, policies are required to outline permitted monitoring of system and network activities, and under specific circumstances. It is also advisable to have policies that specify who can access data relating to an incident under what circumstances and what auditing is required to document the access. Separate policies should be considered describing the data retention of non-incident-related log data and data preserved during the investigation of an incident. The term forensic is used to describe a characteristic of evidence that satisfies its suitability for admission as fact and its ability to persuade based on proof (or high statistical confidence). This applies to Prioritization of incidents is an important element, as are escalation procedures. Interestingly, incident priorities differ between organizations depending on their culture and other policies, and there are certain types of incidents that one organization may tolerate while another may not. In addition, policies are required to outline permitted monitoring of system and network activities, and under specific circumstances. It is also advisable to have policies that specify who can access data relating to an incident under what circumstances and what auditing is required to document the access. Separate policies should be considered describing the data retention of non-incident-related log data and data preserved during the investigation of an incident. Once you have decided what types of data you are going to maintain, it is prudent to take steps to preserve their integrity and document their location, format, and any other associated details. A simple hash algorithm can be used to document the integrity of log files.  Documenting the location of important data sources, and outlining how these data can be accessed and interpreted, will help use the data efficiently when necessary. Marking the location of important data sources on a network topology map is a useful way to summarize this information graphically, facilitating evidence gathering during high-pressure incidents. This type of graphical view of data sources on a network can also be useful for finding gaps in coverage and developing better approaches to monitoring system activities and preserving existing data. In addition to preparing data sources for incidents, it is also important to be operationally prepared for incidents. This involves purchasing the necessary equipment and training at least one individual to handle incidents and use tools for recovering and examining data.

A. 5.25 Assessment of and decision on information security events

Control

The organization should assess information security events and decide if they are to be categorized as information security incidents.

Purpose

To ensure effective categorization and prioritization of information security events.

ISO 27002 Implementation guidance

A categorization and prioritization scheme of information security incidents should be agreed for the identification of the consequences and priority of an incident. The scheme should include the criteria to categorize events as information security incidents. The point of contact should assess each information security event using the agreed scheme. Personnel responsible for coordinating and responding to information security incidents should perform the assessment and make a decision on information security events. Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification.

Other information

The ISO/IEC 27035 series provides further guidance on incident management.

The point of contact should assess each information security event using the agreed information security event and incident classification scale and decide whether the event should be classified as an information security incident. Classification and prioritization of incidents can help to identify the impact and extent of an incident. In cases where the organization has an information security incident response team (ISIRT), the assessment and decision can be forwarded to the ISIRT for confirmation or reassessment. Results of the assessment and decision should be recorded in detail for the purpose of future reference and verification.

A formal management procedure and policy for incident response, including roles and responsibilities for each aspect of the response, is essential. Aspects to document include funding and cost models; analysis, containment, and recovery responsibilities; decision-making authority for notifications; legal and/or law enforcement involvement; forensic investigations; responsibility for after-incident debriefing; and policy, procedure, and process improvements. The primary goals of security incident response are to determine the cause and effect of incidents, including any sanctions which may be appropriate and any new preventive measures that may need to implement, as well as to restore the affected infrastructure to an operational state in a timely manner. The general activities or stages to an effective response and improvement are described in the table below. Some may of necessity be serially processed and some may run as concurrent activities. For example, once an event has been identified, the prioritization and assessment may occur at the same time as containment for an active intrusion situation.

Stages:Activities:

Identification and prioritization of incident, and performing a timely assessment of the situation

1. Determine the scope/impact. The number of users affected, or a number of devices or segments of the network should be considered. Is a single user or account involved?
2. Assess the severity. What is the sensitivity of the data involved? What is the criticality of the service, or system, or application? What is the potential for damage or liability? Is there potential for harm?
3. Assess the urgency of the event. Is it an active problem, threat, or event-in-progress? Was the problem discovered after the fact? Is the intrusion “dormant”, or completed? Does this involve the use of an account rather than a system? Is this involve the safety or privacy of individuals?
Containment of the event 1. Does the system need to be removed from the network? Does active memory need to be imaged or captured?
2. Are there user accounts or system-level accounts that need to be disabled or changed? Are there sessions that need to be dropped?

Investigation of what occurred and how (includes “root cause” analysis)

1. An incident tracking record needs to be created. If deemed necessary, due to the scope, seriousness, or complexity of the incident, an incident notes log should also be created.
2. Gathering and preserving relevant information should be conducted by trained security personnel.
3. Evaluation of evidence commences. It may be a “forensic” calibre assessment, or a less comprehensive analysis, depending on the type of incident and organization’s policies. Decisions with respect to the appropriate resolution and response should be discussed with decision-makers and key stakeholders.
Response (effect) 1. Eradication of the problem and associated changes to the system need to be applied. This includes technical actions such as operating system and application software installs new or changed firewall rules, custom configurations applied, databases created, backup data restored, accounts created and access controls applied
2. Recovery to a fully operational state always follows appropriate testing or assurance of the system integrity and stability. Effective customer service includes regular communications with stakeholders who may be anxious for recovery.
3.Outcomes, including possible sanctions, should be determined. Sanctions, if they are deemed appropriate to the response, maybe internal, such as disciplinary action, or they may be external, such as referral to law enforcement
Follow up (Improvements) 1. After incident debriefing. It is important to review the process and how it could have been better after an incident is closed. This is especially valid for new types of incidents, and particularly severe or costly incidents.
2. Consider policy and process changes. Were any procedures missing, communications unclear, or stakeholders that were not appropriately considered? Did the technical staff have appropriate resources (information as well as equipment) to perform the analysis and/or the recovery?
3.Consider controls improvements, leading to prevention. What can we do to ensure this does not happen again? What improvements can we implement to make our response and recovery more timely?

A.5.26 Response to information security incidents

Control

Information security incidents should be responded to in accordance with the documented procedures.

Purpose

To ensure efficient and effective response to information security incidents

ISO 27002 Implementation guidance

The organization should establish and communicate procedures on information security incident
response to all relevant interested parties.
Information security incidents should be responded to by a designated team with the required
competency (see 5.24).
The response should include the following:

  1. containing, if the consequences of the incident can spread, the systems affected by the incident.
  2. collecting evidence as soon as possible after the occurrence.
  3. escalation, as required including crisis management activities and possibly invoking business continuity plans.
  4. ensuring that all involved response activities are properly logged for later analysis.
  5. communicating the existence of the information security incident or any relevant details thereof to all relevant internal and external interested parties following the need-to-know principle.
  6. coordinating with internal and external parties such as authorities, external interest groups and forums, suppliers and clients to improve response effectiveness and help to minimize consequences for other organizations.
  7. once the incident has been successfully addressed, formally closing and recording it.
  8. conducting information security forensic analysis, as required.
  9. performing post-incident analysis to identify root cause. Ensure it is documented and communicated according to defined procedures.
  10. identifying and managing information security vulnerabilities and weaknesses including those related to controls which have caused, contributed to or failed to prevent the incident.

Other information

The ISO/IEC 27035 series provides further guidance on incident management.

It is always good to assign owners, be clear on actions and timescales, and as with everything for ISO 27001, retain the information for audit purposes (also essential if you have other stakeholders and regulators to consider). The individual placed in charge of dealing with the security event will be responsible for restoring a normal level of security whilst also:

  • collecting evidence as soon as possible after the occurrence;
  • conducting an information security forensics analysis (grand term but at least being clear on the root cause and related aspects or what happened and who was involved, why etc);
  • escalation, if required, for example to relevant regulators;
  • ensuring all that all involved response activities are properly logged for later analysis;
  • communicating the existence of the information security incident or any relevant details to the leadership for them to be further communicated to various individuals or organizations on a need-to-know basis; and
  • dealing with information security weaknesses found to cause or contribute to the incident.

In many cases, a more in-depth evaluation of the incident and circumstances is warranted. It may be to determine if confidential information was involved in, or stored on, the system in question. It may also be an effort to determine the vulnerability or action that enabled the incident to occur. This is typically where a forensic evaluation comes into play. Unfortunately, in some cases, an incident will involve or expose confidential information, such as PII (personally identifiable information) that is protected by law, other policy, or local practices. When this occurs there is often some sort of requirement in the response stage for notification to affected persons.

A. 5.27 Learning from information security incidents

Control

Knowledge gained from information security incidents should be used to strengthen and improve the information security controls.

Purpose

To reduce the likelihood or consequences of future incidents.

ISO 27002 Implementation guidance

The organization should establish procedures to quantify and monitor the types, volumes and costs of information security incidents.
The information gained from the evaluation of information security incidents should be used to:
a) enhance the incident management plan including incident scenarios and procedures.
b) identify recurring or serious incidents and their causes to update the organization’s information security risk assessment and determine and implement necessary additional controls to reduce the likelihood or consequences of future similar incidents. Mechanisms to enable that include collecting, quantifying and monitoring information about incident types, volumes and costs.
c) enhance user awareness and training by providing examples of what can happen, how to respond to such incidents and how to avoid them in the future.

Other information

The ISO/IEC 27035 series provides further guidance on incident management.

It is always good to assign owners, be clear on actions and timescales, and as with everything for ISO 27001, retain the information for audit purposes (also essential if you have other stakeholders and regulators to consider). The individual placed in charge of dealing with the security event will be responsible for restoring a normal level of security whilst also. There should be mechanisms in place to enable the types, volumes, and costs of information security incidents to be quantified and monitored. The information gained from the evaluation of information security incidents should be used to identify recurring or high-impact incidents.The evaluation of information security incidents may indicate the need for enhanced or additional controls to limit the frequency, damage, and cost of future occurrences, or to be taken into account in the security policy review process. With due care of confidentiality aspects, anecdotes from actual information security incidents can be used in user awareness training as examples of what could happen, how to respond to such incidents, and how to avoid them in the future.

This is an important control, and your policy needs to demonstrate that knowledge gained from analyzing and resolving information security incidents will be used to help reduce the likelihood or impact of any future incidents. As part of the commitment to continuous service improvement, you should ensure that you learn from the lessons of any security incident to therefore help evolve and adapt the ISMS to meet the changing landscape that is worked in. Once an incident has been resolved, it should be placed into a status of review and learning, where the lead responder for that incident will discuss any changes required to the processes of the ISMS policies as a result. Any relevant recommendations should then be put to the ISMS Board for further discussion. Once the review and learning have been completed, updates have been made to the policies as required, the relevant staff must be notified and re-trained if required, and the cycle of information security awareness and education continues. The purpose of metrics here is to identify the major causes and sources of incidents, to measure the damage caused by incidents, and to observe trends in both. If metrics show that a particular vulnerability is causing the most losses, you may decide to reconfigure the network to protect vulnerable systems and make an exerted effort to fix them. If an increasing number of attacks are coming through the VPN, you may decide to install a dedicated firewall and/or intrusion detection system to block these attacks. If metrics show that the total annual cost of incidents is increasing steadily, the organizations may decide to devote more resources to preventative security measures. Metrics may include the total incidents handled, time spent on incidents, the number of different types of incidents, and the number of Windows versus UNIX systems impacted. It is not sufficient to just count the number of incidents because as your program improves, these increase. Some useful incident measures to consider are:
• the number of detected but unsuccessful intrusion attempts to compare with the number of successful ones
• the damage/losses caused by disruptive incidents, to help develop plans for reducing outages and the staff hours spent responding to incidents
• reductions in downtime of the network or critical systems
• metrics for any special security initiatives such as alarms or monitoring of systems, to help in assessing their effectiveness

A. 5.28 Collection of evidence

Control

The organization should establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events.

Purpose

To ensure a consistent and effective management of evidence related to information security incidents for the purposes of disciplinary and legal actions.

ISO 27001 Implementation guidance

Internal procedures should be developed and followed when dealing with evidence related to information security events for the purposes of disciplinary and legal actions. The requirements of different jurisdictions should be considered to maximize chances of admission across the relevant jurisdictions.
In general, these procedures for the management of evidence should provide instructions for the identification, collection, acquisition and preservation of evidence in accordance with different types of storage media, devices and status of devices (i.e. powered on or off). Evidence typically needs to be collected in a manner that is admissible in the appropriate national courts of law or another disciplinary forum. It should be possible to show that:
a) records are complete and have not been tampered with in any way;
b) copies of electronic evidence are probably identical to the originals;
c) any information system from which evidence has been gathered was operating correctly at the time the evidence was recorded.
Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence.
Digital evidence can transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as digital evidence.

Other information

When an information security event is first detected, it is not always obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve legal advice or law enforcement early in any contemplated legal action and take advice on the evidence required.
ISO/IEC 27037 provides definitions and guidelines for identification, collection, acquisition and preservation of digital evidence.
The ISO/IEC 27050 series deals with electronic discovery, which involves the processing of electronically stored information as evidence
.

Internal procedures should be developed and followed when dealing with the evidence for the purposes of disciplinary and legal action. In general, these procedures for evidence should provide processes of identification, collection, acquisition, and preservation of evidence in accordance with different types of media, devices, and status of devices e.g. powered on or off. The procedures should take account of:

  • chain of custody;
  • safety of evidence;
  • safety of personnel;
  • roles and responsibilities of personnel involved;
  • competency of personnel;
  • documentation;
  • briefing.

Where available, certification or other relevant means of qualification of personnel and tools should be sought, so as to strengthen the value of the preserved evidence. Forensic evidence may transcend organizational or jurisdictional boundaries. In such cases, it should be ensured that the organization is entitled to collect the required information as forensic evidence. The requirements of different jurisdictions should also be considered to maximize the chances of admission across the relevant jurisdictions.Identification is the process involving the search for, recognition, and documentation of potential evidence. The collection is the process of gathering physical items that can contain potential evidence. The acquisition is the process of creating a copy of data within a defined set. Preservation is the process to maintain and safeguard the integrity and original condition of the potential evidence. When an information security event is first detected, it may not be obvious whether or not the event will result in court action. Therefore, the danger exists that necessary evidence is destroyed intentionally or accidentally before the seriousness of the incident is realized. It is advisable to involve a lawyer or the police early in any contemplated legal action and take advice on the evidence required.

The organization has to define and apply controls for the identification, collection, acquisition, and preservation of information, which can be used as evidence, especially if there are criminal or civil proceedings likely to happen from the incident. Where the organization suspects or knows that a security incident may result in legal or disciplinary action, they should carry out the collection of evidence carefully, ensure a good chain of custody and avoid any threat of being caught out by poor management. It’s sensible to tie information security incident management clearly to disciplinary procedures too. Everyone should know to take precautions whilst also being clear on the consequences for those who fail to take it seriously.

Recommended Tools and Resources for Incident Handlers

  1. Incident Handler Communications and Facilities:
    • Contact information including after hours (on-call) information
    • Incident reporting mechanisms
    • Pagers and/or cell phones
    • Encryption software
    • Secure storage location/area
    • Work area
  2. Incident Analysis Hardware and Software:
    • Computer forensic workstations and/or backup devices, laptops
    • Spare (workstations servers and networking) devices
    • Blank media, cables, housings, converters, and write blockers
    • Portable printer
    • Packet sniffers and protocol analyzers
    • Computer forensic software
    • Removable media
    • Evidence gathering accessories (such as notebooks, cameras, recorders, chain of custody forms, evidence collection bags)
  3. Incident Analysis Resources:
    • Port lists
    • OS documentation
    • Network diagrams
    • Lists of critical assets
    • Baselines
    • Cryptographic hashes of critical files
  4. Incident Mitigation Resources:
    • Media (OS and application software)
    • Security patches
    • Backup images

Back to Home Page

If you need assistance or have any doubt and need to ask any questions 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:2022 A 5.22 Monitoring, review and change management of supplier services

The objective is to maintain an agreed level of information security and service delivery in line with supplier agreements. Once operations of service providers have started, ensuring that the services delivered conform to the specifications of third-party contracts is important. This can include everything from availability levels of the service to something more granular, such as examining the security controls the service provider agreed to in the contract. If there is a great level of dependency upon third-party service providers, checking into service capabilities, plans for handling information security incidents or service disruptions, and business continuity testing may be warranted. Systematic monitoring and reviews of services and controls are also recommended, including scrutinizing service reports provided by the third-party to ensure the information is sufficient and relevant. As business or information technology requirements are modified, this may also require a change in the provision of third-party services, and procedures should be in place to handle any new requirements. Additionally, modifications may also call for a review of existing information security controls to ensure they are adequate.

Control

The organization should regularly monitor, review, evaluate and manage change in supplier information security practices and service delivery.

Purpose

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

ISO 27001 Implementation Guidance

Monitoring, review and change management of supplier services should ensure the information security terms and conditions of the agreements are complied with, information security incidents and problems are managed properly and changes in supplier services or business status do not affect service delivery. This should involve a process to manage the relationship between the organization and the supplier to:

a) monitor service performance levels to verify compliance with the agreements; b) monitor changes made by suppliers including:

  1. enhancements to the current services offered;
  2. development of any new applications and systems;
  3. modifications or updates of the supplier’s policies and procedures;
  4. new or changed controls to resolve information security incidents and to improve information security;

c) monitor changes in supplier services including:

  1. changes and enhancement to networks;
  2. use of new technologies;
  3. adoption of new products or newer versions or releases;
  4. new development tools and environments;
  5. changes to physical location of service facilities;
  6. change of sub-suppliers;
  7. sub-contracting to another supplier;

d) review service reports produced by the supplier and arrange regular progress meetings as required by the agreements;
e) conduct audits of suppliers and sub-suppliers, in conjunction with review of independent auditor’s reports, if available and follow-up on issues identified;
f) provide information about information security incidents and review this information as required by the agreements and any supporting guidelines and procedures;
g) review supplier audit trails and records of information security events, operational problems, failures, tracing of faults and disruptions related to the service delivered;
h) respond to and manage any identified information security events or incidents;
i) identify information security vulnerabilities and manage them;
j) review information security aspects of the supplier’s relationships with its own suppliers;
k) ensure that the supplier maintains sufficient service capability together with workable plans designed to ensure that agreed service continuity levels are maintained following major service failures or disaster
l) ensure that suppliers assign responsibilities for reviewing compliance and enforcing the requirements of the agreements;
m) evaluate regularly that the suppliers maintain adequate information security levels.

The responsibility for managing supplier relationships should be assigned to a designated individual or team. Sufficient technical skills and resources should be made available to monitor that the requirements of the agreement, in particular the information security requirements, are being met. Appropriate actions should be taken when deficiencies in the service delivery are observed.

Other information

See ISO/IEC 27036-3 for more detail.

This control describes how organizations regularly monitor, review their supplier service delivery. Conducting reviews and monitoring is best done based on the information at risk – as a one-size approach will not fit all. The organization should aim to conduct its reviews in line with the proposed segmentation of suppliers in order to therefore optimize their resources and make sure that they focus effort on monitoring & reviewing where it will have the most impact. Sometimes there is a need for pragmatism – you are not necessarily going to get an audit, human relationship review, and dedicated service improvements with AWS if you are a very small organization. You could, however, check (say) their annually published SOC II reports and security certifications remain fit for your purpose. Evidence of monitoring should be completed based on your power, risks, and value, thus allowing your auditor to be able to see that it has been completed and that any necessary changes have been managed through a formal change control process. The organization cannot overlook the need to manage the risk to their information assets that are accessed, processed, communicated to, or managed by external parties (partners, vendors, contractors, etc.). The service provider should be continuously monitored to assure that services provided are meeting the terms of the contract and security is maintained. There should be an ongoing review of service reports, a process to address concerns and issues, and periodic audits. This section also encompasses documentation and procedures for handling security incidents, including incident reporting, mitigation, and subsequent reviews. Finally, service capability levels must be monitored to ensure that the service provider continues to meet the contract terms and needs of the business. In addition to regular review and monitoring of the services provided, the contracting organization should:

  • Conduct audits of suppliers in conjunction with outside assessments
  • Require the supplier to promptly notify regarding security incidents
  • Provide regular audit trails and records for security events
  • Have a conflict resolution process that can be invoked if requirements are not met

Organisations need to take steps to ensure that employees who are responsible for managing SLAs and supplier relationships have the requisite levels of skill and technical resources to be able to adequately assess supplier performance, and information security standards are not being breached. Organisations should draft policies and procedures which:

1) Constantly monitor service levels in accordance with published SLAs, and any shortfalls are addressed.
2) Monitor any changes made by the supplier to their own operation, including but not limited to:

  • Service enhancements
  • The introduction of new applications, systems or software processes
  • Relevant and meaningful revisions to the suppliers internal governance documents
  • Any incident management procedural changes, or efforts intended to increase levels of information security

3) Monitor any service-specific changes, including (but not limited to):

  • Infrastructure amendments
  • The application of emerging technologies
  • The roll-out of product updates or version upgrades
  • Changes in the development environment
  • Logistical and physical changes to supplier facilities, including new locations
  • Any changes to outsourcing partners or subcontractors
  • The intention to subcontract, where the practice wasn’t previously in place

4) Ask for regular service reports, analyse data and attend review meetings in accordance with agreed levels of service delivery.
5) Audit outsourcing partners and subcontractors and pursue any areas for concern.
6) Review security incidents in accordance with agreed Incident Management standards and practices, and the supplier agreement.
7) Maintain a thorough record of information security events, tangible operational problems, fault logs and general barriers to the service delivery standards that have been agreed.
8) Proactively respond to and take remedial action towards information security-related events.
9) Highlight any information security vulnerabilities and mitigate them to the fullest extent.
10) Analyse any relevant information security factors inherent within the suppliers relationship with its own suppliers and subcontractors.
11) Ensure that service delivery is delivered to acceptable levels following significant supplier-side disruption, including disaster recovery.
12) Outline key personnel in the supplier’s operation who are responsible for maintaining compliance and adhering to the terms of an agreement.
13) Regularly audit a supplier’s ability to maintain a baseline information security standard.

Some external parties provide independent audits based on the Statement on Standards for Attestation Engagements which focuses on the design of controls and their operating effectiveness. When independent audit opinions are not available, the Organization might choose to evaluate the risk themselves. Monitoring can mean different things to different people. It can simply mean to assess, to watch, to keep track of, or to check, usually, with a special purpose. It does not mean or implies to verify or even to test. Actually, monitoring is more of a spectrum that ranges from just “keeping an eye” in the low end to requiring a site audit in the high end. Given the availability of resources at the Organization of higher education, verification could be an impractical and significantly costly requirement if applied to all or most suppliers
Effective monitoring of suppliers requires a process or methodology in place that defines the approach to take based on the risk of the supplier or engagement – activities should be more stringent and closer to the high end of the spectrum as risk increases or when exceptional situations warrant them. The organizational policy may refer to instances in which the sharing of sensitive data will result in a significant risk. Again, “significant” can mean a number of things but, ultimately, depends on the organization’s risk management practices and risk tolerance (i.e., what is an acceptable risk). Only in cases of very high risk or when exceptional situations may warrant it should supplier monitoring include a requirement to perform a site audit, or results of a Statement on Standards for Attestation Engagements audit, or results of an audit performed by an independent auditor. What should an organization do to monitor compliance with agreement requirements in most cases? Define the incremental risk to the organization when engaging a supplier as well as defining a due diligence process for mitigating those risks – third-party risk from remote access, data transmission and offsite storage. Consider the following as an outline for a contract monitoring process:
1. During System / Application / Process Implementation

a. Identify the individual(s) responsible for monitoring the relationship with the supplier.
b. During project status meetings:

  • i. Assess and review status reports regarding progress made in the implementation of the security requirements included in the contract and/or statement of work.
  • ii. Identify new areas or security requirements that may arise from changes in scope

c. If applicable, perform or request audit of vendor security practices and procedures and/or perform a penetration test. It may be necessary to include a legal review by general counsel, as well.
d. During final test and prior to sign-off

  • i. Test system/application/process security functionality required in the contract
  • ii. Review progress reports and determine if all security requirements included in the contract and/or statement of work were completed.

e. If applicable, perform application scan

2. Post Implementation

a. Follow up with system/application/process owner.

  • i. Require the owner to perform a risk assessment based on policy (annual if high risk or mission-critical and bi-annual for the rest)
  • ii. Review with the owner the risk assessment results. Any concerns? Any problems? Any unknowns that need to be addressed with the vendor?

b. Follow up with the supplier. Access logs available? Any pending items resolved? Are things on their end as expected? Any owner concerns? Risk assessment identified deficiencies?
c. Based on risk (annually or bi-annually), resubmit third-party information security risk assessment to assess what has changed, what needs closer scrutiny, or identify inconsistencies with previous assessments
d. Establish a working relationship with your supplier
e. Participate in supplier’s product improvement committee. What changes are been considered? How would they impact the organization’s risk and security postures
f. Review security incidents involving the system/application/process. Are these due to non-compliance?
g. If applicable, based on the contract, require subsequent assurance tests.

For currently established suppliers, assess their risk (if it has not already been done), and start with the steps listed in the Post Implementation section above as needed. It is important to keep in mind that supplier monitoring is the last step of a cascading progression. The initial identification of process and data impacted as well as initial security requirements are used to formulate purchasing requirements. The answers to the requirements are used to evaluate potential suppliers and refine security requirements. The evaluation and risk assessment of finalists refine the security requirements that will, in turn, be added as the language to the contract or statement of work. And, finally, it is the final contract and corresponding risk level that determine the appropriate supplier monitoring approach.

A good control describes how any changes to the provision of services by suppliers, including maintaining and improving existing information security policies, procedures, and controls, are managed.  It takes into account the criticality of business information, the nature of the change, the supplier type/s affected, the systems and processes involved, and a re-assessment of risks.  Changes to supplier’s services should also take into account the intimacy of the relationship and the organization’s ability to influence or control change in the supplier. All technology systems are undergoing a continuous upgrade, change, and repair. Changes to service provisions by suppliers should be managed and documented, taking into account the sensitivity of information and services and re-assessment of risks. The contracting organization should determine how to integrate its change management process with that of the supplier. Items to consider include:
• Service enhancements
• Bug fixes
• Use of new technology
• New development tools
• Enhanced security measures
• Change of subcontractor
• Change of physical sites
Where possible, supplier changes should be integrated with the contracting organization’s change management processes.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions 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:2022 A 8.29 Security testing in development and acceptance

Security testing is a type of Software Testing that uncovers vulnerabilities, threats, risks in a software application and prevents malicious attacks from intruders. The purpose of Security Tests is to identify all possible loopholes and weaknesses of the software system which might result in a loss of information, revenue, repute at the hands of the employees or outsiders of the Organization.Cyber criminals are constantly inventing new ways and are improving their strategies to infiltrate corporate networks and gain access to sensitive information assets. If an application, software, or IT system is deployed in the real world with vulnerabilities, this would expose sensitive information assets to the risk of compromise. Therefore, organisations should establish and implement an appropriate security testing procedure to identify and remedy all vulnerabilities in IT systems before they are deployed to the real world. Organisations to verify that all information security requirements are satisfied when new applications, databases, software, or code are put into operation by establishing and applying a robust security testing procedure. This helps organisations to detect and eliminate vulnerabilities in the code, networks, servers, applications, or other IT systems before they are used in the real world.

Control

Security testing processes should be defined and implemented in the development life cycle.

Purpose

To validate if information security requirements are met when applications or code are deployed to the production environment.

ISO 27002 Implementation Guidance

New information systems, upgrades and new versions should be thoroughly tested and verified during the development processes. Security testing should be an integral part of the testing for systems or components. Security testing should be conducted against a set of requirements, which can be expressed as functional or non-functional. Security testing should include testing of:

  1. security functions [e.g. user authentication, access restriction and use of cryptography ];
  2. secure coding ;
  3. secure configurations including that of operating systems, firewalls and other security components.

Test plans should be determined using a set of criteria. The extent of testing should be in proportion to the importance, nature of the system and the potential impact of the change being introduced. The test plan should include:

  1. detailed schedule of activities and tests;
  2. inputs and expected outputs under a range of conditions;
  3. criteria to evaluate the results;
  4. decision for further actions as necessary.

The organization can leverage automated tools, such as code analysis tools or vulnerability scanners, and should verify the remediation of security related defects. For in-house developments, such tests should initially be performed by the development team. Independent acceptance testing should then be undertaken to ensure that the system works as expected and only as expected. The following should be considered:

  1. performing code review activities as a relevant element for testing for security flaws, including un-anticipated inputs and conditions;
  2. performing vulnerability scanning to identify insecure configurations and system vulnerabilities;
  3. performing penetration testing to identify insecure code and design.

For outsourced development and purchasing components, an acquisition process should be followed. Contracts with the supplier should address the identified security requirements. Products and services should be evaluated against these criteria before acquisition. Testing should be performed in a test environment that matches the target production environment as closely as possible to ensure that the system does not introduce vulnerabilities to the organization’s environment and that the tests are reliable.

Other information

Multiple test environments can be established, which can be used for different kinds of testing (e.g. functional and performance testing). These different environments can be virtual, with individual configurations to simulate a variety of operating environments.Testing and monitoring of test environments, tools and technologies also needs to be considered to ensure effective testing. The same considerations apply to monitoring of the monitoring systems deployed in development, test and production settings. Judgement is needed, guided by the sensitivity of the systems and data, to determine how many layers of meta-testing are useful.

Security Testing is a type of Software Testing that uncovers vulnerabilities of the system and determines that the data and resources of the system are protected from possible intruders. It ensures that the software system and application are free from any threats or risks that can cause a loss. Security testing of any system is focused on finding all possible loopholes and weaknesses of the system which might result in the loss of information or repute of the organization. Security testing is a type of software testing that focuses on evaluating the security of a system or application. The goal of security testing is to identify vulnerabilities and potential threats, and to ensure that the system is protected against unauthorized access, data breaches, and other security-related issues.The goal of security testing is to:

  • To identify the threats in the system.
  • To measure the potential vulnerabilities of the system.
  • To help in detecting every possible security risks in the system.
  • To help developers in fixing the security problems through coding.
  • The goal of security testing is to identify vulnerabilities and potential threats in a system or application, and to ensure that the system is protected against unauthorized access, data breaches, and other security-related issues. The main objectives of security testing are to:
  • Identify vulnerabilities: Security testing helps identify vulnerabilities in the system, such as weak passwords, unpatched software, and misconfigured systems, that could be exploited by attackers.
  • Evaluate the system’s ability to withstand an attack: Security testing evaluates the system’s ability to withstand different types of attacks, such as network attacks, social engineering attacks, and application-level attacks.
  • Ensure compliance: Security testing helps ensure that the system meets relevant security standards and regulations
  • Provide a comprehensive security assessment: Security testing provides a comprehensive assessment of the system’s security posture, including the identification of vulnerabilities, the evaluation of the system’s ability to withstand an attack, and compliance with relevant security standards.
  • Help organizations prepare for potential security incidents: Security testing helps organizations understand the potential risks and vulnerabilities that they face, enabling them to prepare for and respond to potential security incidents.
  • Identify and fix potential security issues before deployment to production: Security testing helps identify and fix security issues before the system is deployed to production. This helps reduce the risk of a security incident occurring in a production environment.

Major Focus Areas in Security Testing:

  • Network Security
  • System Software Security
  • Client-side Application Security
  • Server-side Application Security
  • Authentication and Authorization: Testing the system’s ability to properly authenticate and authorize users and devices. This includes testing the strength and effectiveness of passwords, usernames, and other forms of authentication, as well as testing the system’s access controls and permission mechanisms.
  • Network and Infrastructure Security: Testing the security of the system’s network and infrastructure, including firewalls, routers, and other network devices. This includes testing the system’s ability to defend against common network attacks such as denial of service (DoS) and man-in-the-middle (MitM) attacks.
  • Database Security: Testing the security of the system’s databases, including testing for SQL injection, cross-site scripting, and other types of attacks.
  • Application Security: Testing the security of the system’s applications, including testing for cross-site scripting, injection attacks, and other types of vulnerabilities.
  • Data Security: Testing the security of the system’s data, including testing for data encryption, data integrity, and data leakage.
  • Compliance: Testing the system’s compliance with relevant security standards and regulations, such as HIPAA, PCI DSS, and SOC2.
  • Cloud Security: Testing the security of cloud-

Testing of security functionality needs to be carried out during development. Specific testing of security functionality for any development must be carried out and signed-off by an appropriate authority with security competency and responsibility. Security testing expected outcomes should be documented before testing commences and should be based on business requirements for security. The auditor will want to see that there is evidence that security-specific testing has been carried out in any development that is security-relevant. Acceptance testing programs and related criteria must be established for new information systems, upgrades and new versions. For acceptance testing, the tests and the criteria for demonstrating a successful test should be designed and developed based on business requirements prior to tests being carried out. Acceptance testing should also include security testing. The auditor will be looking for evidence that shows acceptance testing criteria and methods were designed according to business requirements and include provisions for security acceptance testing.

Basic principles of security testing:

  • Confidentiality
  • Integrity
  • Authentication
  • Authorization
  • Availability
  • Non-repudiation

Organisations should incorporate security testing into the testing process for all systems and they must ensure that all new information systems and their new/updated versions satisfy the information security requirements when they are in the production environment.

  • Security functions such as user authentication , access restriction , and cryptography.
  • Secure coding .
  • Secure configurations as prescribed . This may cover firewalls and operating systems.


When designing security testing plans, organisations should take into account the level of criticality and nature of the information system at hand. Security testing plan should cover the following:

  • Establishment of a detailed schedule for the activities and the testing to be conducted.
  • Inputs and outputs expected to occur under a given set of conditions.
  • Criteria to assess the results.

If appropriate, decisions to take actions based upon the results.

When IT systems are developed by the in-house development team, this team should carry out the initial security testing to ensure the IT system satisfies security requirements. This initial testing should then be followed by an independence acceptance testing .In relation to the in-house development, the following should be considered:

  • Carrying out code review activities to detect and eliminate security flaws, including expected inputs and conditions.
  • Carrying out vulnerability scanning to detect insecure configurations and other vulnerabilities.
  • Carrying out penetration tests to detect insecure code and design.

Types of Security Testing:

  1. Vulnerability Scanning: Vulnerability scanning is performed with the help of automated software to scan a system to detect the known vulnerability patterns.
  2. Security Scanning: Security scanning is the identification of network and system weaknesses. Later on it provides solutions for reducing these defects or risks. Security scanning can be carried out in both manual and automated ways.
  3. Penetration Testing: Penetration testing is the simulation of the attack from a malicious hacker. It includes an analysis of a particular system to examine for potential vulnerabilities from a malicious hacker that attempts to hack the system.
  4. Risk Assessment: In risk assessment testing security risks observed in the organization are analyzed. Risks are classified into three categories i.e., low, medium and high. This testing endorses controls and measures to minimize the risk.
  5. Security Auditing: Security auditing is an internal inspection of applications and operating systems for security defects. An audit can also be carried out via line-by-line checking of code.
  6. Ethical Hacking: Ethical hacking is different from malicious hacking. The purpose of ethical hacking is to expose security flaws in the organization’s system.
  7. Posture Assessment: It combines security scanning, ethical hacking and risk assessments to provide an overall security posture of an
  8. Application security testing: Application security testing is a type of testing that focuses on identifying vulnerabilities in the application itself. It includes testing the application’s code, configuration, and dependencies to identify any potential vulnerabilities.
  9. Network security testing: Network security testing is a type of testing that focuses on identifying vulnerabilities in the network infrastructure. It includes testing firewalls, routers, and other network devices to identify potential vulnerabilities.
  10. Social engineering testing: Social engineering testing is a type of testing that simulates phishing, baiting, and other types of social engineering attacks to identify vulnerabilities in the system’s human element.
  11. Tools such as Nessus, OpenVAS, and Metasploit can be used to automate and simplify the process of security testing. It’s important to ensure that security testing is done regularly and that any vulnerabilities or threats identified during testing are fixed immediately to protect the system from potential attacks. organization.

Organisations should follow a strict acquisition process when they outsource development or when they purchase IT components from external parties. Organisations should enter into an agreement with their suppliers and this agreement should address the information security requirements .Furthermore, organisations should ensure that the products and services they purchase are in compliance with the information security standards. Organisations can create multiple test environments to carry out various testing such as functional, non-functional, and performance testing. Furthermore, they can create virtual test environments and then configure these environments to test the IT systems in various operational settings. Effective security testing requires organisations to test and monitor the testing environments, tools, and technologies. Organisations should take into account the level of sensitivity and criticality of data when determining the number of layers of meta-testing.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions 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:2022 A 6.5 Responsibilities after termination or change of employment

This control covers the need for organisations to define the information security duties and responsibilities that remain valid should personnel stop work or move to a new department. These duties and responsibilities should be communicated to the employee as well as any other relevant party. To prevent unauthorized access to sensitive information, access must be revoked immediately upon termination/separation of an employee with access to such information. This also includes the return of any assets of the organization that was held by the employee. To protect the organization’s interests as part of the process of changing or terminating employment. This Annex says that, if the termination happened for any employee, they are legally bound to maintain he information security. Employees should sign a Return of Property form policy where they return all the properties of the company. This is not just about the exit and termination, it’s about confidentiality. The organization must advise the employee that they don’t have access to information asset and must be kept confidential.

A 6.5 Responsibilities after termination or change of employment

Control:

Information security responsibilities and duties that remain valid after termination or change of employment should be defined, enforced and communicated to relevant personnel and other interested parties.

Purpose

To protect the organization’s interests as part of the process of changing or terminating employment or contracts.

ISO 27002 Implementation Guidelines:

The process for managing termination or change of employment should define which information security responsibilities and duties should remain valid after termination or change. This can include confidentiality of information, intellectual property and other knowledge obtained, as well as responsibilities contained within any other confidentiality agreement. Responsibilities and duties still valid after termination of employment or contract should be contained in the individual’s terms and conditions of employment, contract or agreement. Other contracts or agreements that continue for a defined period after the end of the individual’s employment can also contain information security responsibilities. Changes of responsibility or employment should be managed as the termination of the current responsibility or employment combined with the initiation of the new responsibility or employment. Information security roles and responsibilities held by any individual who leaves or changes job roles should be identified and transferred to another individual. A process should be established for the communication of the changes and of operating procedures to personnel, other interested parties and relevant contact persons (e.g. to customers and suppliers). The process for the termination or change of employment should also be applied to external personnel (i.e. suppliers) when a termination occurs of personnel, the contract or the job with the organization, or when there is a change of the job within the organization.

Other information

In many organizations, the human resources function is generally responsible for the overall termination process and works together with the supervising manager of the person transitioning to manage the information security aspects of the relevant procedures. In the case of personnel provided through an external party (e.g. through a supplier), this termination process is undertaken by the external party in accordance with the contract between the organization and the external party.

TERMINATION OR CHANGE OF EMPLOYMENT

This control should be implemented when an employee or contractor leaves the organisation, or the contract is terminated before it expires. The purpose of this control is to protect the organisation’s information security interests as part of the process of changing or terminating employment or contracts. This control can also work to protect against the risk of employees who have access to sensitive information and processes, misusing their position for personal gain or malicious intent, particularly after they have left the organisation or job role. Control 6.5 aims to protect the organisation’s information security interests as part of the process of changing or terminating employment or contracts. This includes employees, contractors and third parties who have access to your sensitive information. Implementing the control means assessing whether any individuals (including those employed by a third party) who have access to your sensitive personal data are leaving your organisation and whether it is necessary to take steps to ensure that they do not retain and continue to access your sensitive personal data after their departure. If you find that someone is leaving and there is a risk that sensitive personal data may be disclosed, then you must take reasonable steps before they leave, or as soon as possible after they have left, so this does not happen. n order to meet the requirements for control 6.5, the terms and conditions of an individual’s employment, contract, or agreement should specify any information security responsibilities and duties that remain in effect after the end of the relationship.Information security duties may also be included in other contracts or agreements that extend beyond the end of an employee’s employment.

To ensure that employees, contractors, and third-party users exit the organization, or change employment responsibilities within the organization, in an orderly manner. Responsibilities for performing employment termination or change of employment should be clearly defined and assigned. The organization must implement and maintain a procedure or set of procedures to effectively manage departing employees or the withdrawal of assigned responsibilities for employees, contractors, and other third-party users. The procedure must also be included for the withdrawal of assigned responsibilities resulting from a change in employment status for employees, contractors, and other third-party users. The organization should ensure that important knowledge or operational skills have been transferred to other resources prior to the departure of the employee and/or contractor. Control includes:

  • changes of responsibilities and duties within the organization are processed as a termination (of the old position) and re-hire (to the new position), using standard controls for those processes unless otherwise indicated;
  • other employees, contractors, and third parties are appropriately informed of a person’s changed status; and
  • any post-employment responsibilities are specified in the terms and conditions of employment, or a contractor’s or third party’s contract;

Return of assets

All employees, contractors, and third parties should return all of the organization’s assets in their possession upon termination of the employment relationship or contract. Assets include all instances of information, data, documents, etc. The organization must establish procedures and processes to transfer Official Information contained on personal (home office or BYO) devices such as home computers and mobile devices to agency-owned information assets. Such procedures shall include a provision for the secure erasure of all Official Information (other than PUBLIC) that is stored on the personal device. Assets must be sanitized, secured and those assets not required must be safely disposed of.   Control includes:

  • formalization of the process for return (e.g., checklists against inventory);
  • inclusion in this requirement of the organization’s hardware, software and data of any kind; and
  • where the employee, contractor or third party use personal equipment, secure erasure of software and data belonging to the organization.

Removal of access rights

Access rights to information and information systems should be removed upon termination of the employment or contractual relationship. The organization must have an established and logged procedure for the withdrawal and/or modification of access rights for departing employees, contractors, and third-party users. Control includes:

  • changes of employment or contractual status include removal of all rights associated with prior roles and duties, and creation of rights appropriate to the new roles and duties;
  • removal or reduction of access rights prior to the termination, where risks indicate this step to be appropriate (e.g., where termination is initiated by the organization, or the access rights involved highly sensitive information or facilities).

Back to Home Page

If you need assistance or have any doubt and need to ask any questions 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.