External Context

The interconnected and digitalised world requires a constant alignment of an enterprise’s mission, objectives, and functions with the larger context of the national, regional, and sectoral ecosystem in which the enterprise or organisation operates. The external context of an entity includes the customers/ users of an entity’s services, as well as the suppliers, service providers, auditors and supporting agencies. In the case of regulated entities and CSEs, the national bodies, viz, the government, regulators, nodal agencies, and other authorities, are important stakeholders/ interested parties, having legal, regulatory, oversight and advisory responsibilities over the entities.

Business and Digital Ecosystems

In modern business, it is very rare that a CSE operates in isolation. They engage with their customers and users, suppliers and service providers, regulators and national nodal agencies, and in the case of PSUs, their administrative ministries. The CSEs and their business partners use a variety of business systems to provide and use services, and to process and exchange information within their respective organisations and across the business ecosystem.

The business systems of an entity are conceptual or logical systems. In practice, the business processes and information flows of business systems are enabled by technology through digital transformation initiatives. The resulting digital systems comprise of ICT infrastructure, software platforms, applications and data repositories that the CSE’s workforce and automation engines use to carry out the CSE’s business functions. The CSEs interacts with their users, customers, partners, service providers and national bodies through the larger digital ecosystem.

The business and digital ecosystems of a CSE in the Indian context is pictorally shown below:

Each organisation in the digital ecosystem is responsible for its own IT and information security. The organisations however must be aware and responsive to the information security needs of other participating entities within the federated ecosystem, and comply with directions, guidelines and standards prescribed by law, regulation, and mandates of nodal agencies. Every organisation in the complex, federated ecosystem is ultimately responsible for carrying out due diligence, not only about its own information security but also with respect to all parties in its external context.

The National Cyberspace

The digital ecosystem is a manifestation of the national cyberspace. A pictorial view of the national cyberspace is shown below:

The digital ecosystem elements (blobs) give visual representation of the national cyberspace from an usage and ownership perspective (who uses, owns, provides, manages and controls what). Ownership, management and control of elements of the digital ecosystem are important criteria to assess the trustworthiness and risk associated with the elements, specifically from the perspective of external threats.

Decomposing the Ecosystem

The business and digital ecosystems of CSEs are highly complex and continually evolving. However, for ease of understanding, they can be decomposed into the following four levels:

• Governance
• Business
• Technology
• Physical

The pictorial ecosystem is further decomposed into the four levels and described in greater detail.

Governance Level

The governance level ecosystem of a CSE in the Indian context is pictorally shown below:

Enterprises and organizations are successful in the long run, only when they have a strong and capable governance mechanism at the top-most level. CSEs, additionally, have to adhere to regulatory, administrative and legal compliances that are mandated for their respective sectors.

Many small and mid-sized CSEs do not have in-house expertise and competence to design, implement, operate, manage and support a Governance, Risk and Compliance (GRC) program and would depend on external consultancy organisations for the same. Highly regulated sectors like Banking and Financial Services have a well-developed ecosystem of GRC consultancy organisations, certification and audit bodies. Regulators of other critical sectors like Power and Telecom are also developing GRC focused ecosystems for their respective entities. The NCIIPC-QCI Scheme for Consultancy Organisations has two GRC-specific workheads, namely WH-1 and WH-4. The CSEs can use the services of accredited Consultancy Organisations for these Work Heads. The regulators can use the Scheme for development of GRC ecosystems for their respective sectors.

Business Level

The business level ecosystem of a CSE in the Indian context is pictorally shown below:

Every CSE performs a set of business and/ or industrial functions to provide services and/ or capabilities to the consumers. The functions, services and capabilities are typically delivered through business and/ or industrial systems. Almost all the business and industrial systems leverage technology, platforms and digital infrastructure for delivery of the functions, services and capabilities.

One of the core responsibilities of a CSE’s top and senior management is to evaluate, direct and monitor the digital transformation initiatives. Large scale and complex digital transformation of business systems is usually undertaken by consulting and technology firms with expertise across business strategy, technology integration, automation, AI, cloud, sector and industry-specific experience.

Digital transformation initiatives introduce a variety of challenges, threats and risks during both the lifecycle stages - acquisition and operation. Some of the important risks that business level stakeholders must understand and manage are:

• System integrity and trustworthiness risks triggered by gaps in the digitalisation of business processes and controls. For example, a weak implementation of segregation of duties (SoD) can lead to fraud, misuse or malicious manipulation of information.
• Data confidentiality and privacy risks triggered by misconfiguration of roles and permissions assigned to human users and automation agents.
• Cybersecurity risks triggered by an expanded attack surface, and by exposing legacy systems to new attack vectors opened up via integration.
• Vendor and supply chain risks related to technology products and services, and dependency on a multitude of third-party vendors.
• Operational risks triggered by the lack of digital skills in both users and the technical workforce that operates, manages, maintains and secures the digital systems.

Business level stakholders seek information, guidance and support from the process and technology experts on how to i) implement robust governance, audit and compliance mechanisms, ii) protect the business systems from being harmed, iii) continuously monitor and detect unauthorised and malicious actitivities within the business systems, iv) respond to and recover from unauthorised and malicious actions that impact the integrity, confidentiality and trustworthiness of business systems.

Technology Level

Business systems are composed of software applications and sevices that run on a digital infrastructure. The digital infrastucture and systems are managed and secured by the technology level stakeholders. The technology level ecosystem of a CSE in the Indian context is pictorally shown below:

Generally, the executive, senior and mid-level managers of CSEs have a good grasp and understanding of the business complexities and are able to handle them well. However, the complexities of technology and digital infrastructure are not well understood by them and it is left to the CIOs, CISOs and their teams to handle the same. In many cases the technical and project teams adopt a technology-first approach, which can lead to misalignment between the business needs and the use of digital ecosystem technologies.

Many small and mid-sized CSEs have limted in-house expertise and competence to design, implement, operate, manage, support and secure their digital infrastructure. Usually, this work is carried out by their OEMs, System Integrators and other service providers. Thus, these third-party suppliers become an extended workforce of the entities. Automation agents and bots further provide an hugely scalable non-human workforce that can supplement the limited human workforce. However, the CSEs need competent technical personnel within their extended workforce to manage and secure the agents and bots.

Entities must ensure that their entire composite workforce, comprising of own employees, contracted manpower, and third-party suppliers have the required competence (knowledge, skills and expertise) to do their job functions efficiently and effectively. Entities are encouraged to use the NCIIPC-QCI Schemes for Cybersecurity Professionals, Consultancy Organisations and Training Bodies to assess the competencies and capabilities of their composite workforce. The identified gaps in competencies must be filled up by the concerned HR teams through resources hiring, training and certification.

CSEs are mandated to adopt the guidelines and directives from national nodal agencies like NCIIPC and CERT-In. They also have well-defined reporting obligations to these agencies. The regulators and national nodal agencies also have an important role related to third-party cybersecurity audits of CSE’s information infrastructure. VAPT and audits carried out by CERT-In empanelled auditors, risk assessments carried out by NCIIPC and special audits carried out under the aegis of the NCSC, together provide vital insights about the cyber resilience of a CSE’s digital infrastructure.

Physical Level

The physical level ecosystem of a CSE in the Indian context is pictorally shown below:

CSEs are usually required to adhere to specific mandates for physical security, access control and 24x7 monitoring of their critical infrastructure. Typically, in many CSEs, IIoT technologies like digital access control and CCTV systems are used for securing the physical space. However, these systems are not under the ambit of the more competent technical teams under the CIO and CISO. The top management of CSEs must therefore involve their IT and cybersecurity teams in the design, implementation, operation, protection and monitoring of their physical security systems.

Chapter XI of the Central Electricity Authority (CEA) draft regulations gives specific directions to Responsible Entities of the Power sector on the physical security of all identified cyber and non-cyber critical assets.

Many of the physical processes controlled by OT systems have the potential to create hazardous situations to human life and safety, property, and the environment. Health, Safety and Environment (HSE) is a framework of actions that organisations having OT must take to ensure the protection of the environment without harming the health and safety of their employees or local communities. Manufacturers, implementers, operators, maintainers and regulators of OT systems typically give the highest priority to HSE at the physical level.

There are several types of safety systems related to OT environments, which typically use instrumentation systems that operate at the physical level for activities like emergency shut down (ESD), process safety shutdown (PSS), and fire and gas systems (FGS). One of the more well-known types of safety system is the safety instrumented system (SIS).

Common Vocabulary

The glossary of terms and definitions provides a common vocabulary that all stakeholders can understand and use. The glossary is divided into the following sub-sections, to align with the ecosystem levels:

• Conceptual terms
• Governance terms
• Business terms
• Technology terms
• Other terms

The common vocabulary helps to avoid misunderstanding between the stakeholders. As an example, the terms “cyber incident”, “cyber security incident” and “cyber security breach” are often used interchangeably. However, the use of these terms must be based on their definitions given in sections 2(g), 2(h) and 2(i) of G.S.R 20(E) - Information Technology (The Indian Computer Emergency Response Team and Manner of Performing Functions and Duties) Rules, 2013.

The common vocabulary also provides a very effective way for interactions amongst the stakeholders across the four levels. Technical terms are best used within the Technology level. However, when the outcome of technical analysis has to be conveyed to the stakeholders at the Governance and Business levels, the technical teams must use appropriate terms like business functions, business impact, risk, compliance, protection from harm and so on.

Capability Framework

The capability framework for the nation’s digital ecosystem describes the people, processes and technology related capabilities in a manner that is agnostic of specific products and solutions. It enunciates the IT and information security capabilities that the digital ecosystem participants should acquire, maintain, and continually improve so as to achieve their objective of cyber resilience. It also describes how organisations can ensure the effective use and sustenance of IT and information security capabilities through a lifecycle approach.

The target audience for the capability framework includes:

• Business and GRC Heads, CIOs, Heads of OT, CISOs and their respective teams within CSEs.

• Sectoral Regulators, who are mandated to oversee and ensure the cyber resilience of business and IT practices in their regulated entities.

• Consultancy Organisations, System Integrators, OEMs, MSPs and MSSPs engaged by the CSEs.

• Empanelled bodies, who carry out cyber security verification & validation (V&V), VAPT and technical audit of systems and networks of CSEs.

Governing bodies and top management of entities (through the Technology Strategy and Perspective Planning Group, the IT, OT and Information Security Divisions) can use this guidance to use, secure and sustain their IT for delivery of business functions, operations, and services.

Smart, Resilient and Sustainable Digital Ecosystem

In the current information age, data and communication technologies along with smart devices are deeply integrated into almost all aspects of our lives. The nation today runs on well-orchestrated and integrated IT and is therefore critically dependent upon the cyberspace and its underlying infrastructure (systems, networks, applications and data). Hence, it is vital that the Indian cyberspace is secure and protected against cyber-attacks that could jeopardise the benefits it offers to national security, economic prosperity, governance, constitutional processes, and social well-being.

The integration of IT at the sectoral, regional, and national levels will only increase in future. Hence, at the national level, there is need to develop capabilities for a smart, resilient, and sustainable digital ecosystem. These terms are described below.

• Smart: describes the high levels of automation, analytics and decision support capabilities that are enabled by the use of IT. Smart technologies can significantly improve the functioning, performance and resilience of the digital ecosystem. In the context of information and cyber security, these capabilities are typically achieved by the use of intelligent devices, analytics, AI and machine learning for preventing, protecting, detecting and responding to cyber-attacks on IT and OT.

• Resilient: ‘Resilient’ describes the ability of the business and digital ecosystems to not only withstand large scale attacks and mitigate its destructive power but also the capability to recover from a successful attack in the shortest possible time with minimal damage or disruption. It is a key component of business and organisational needs and achieved through well-designed operating procedures, processes, and practices.

• Sustainable: ‘Sustainable’ describes the ability of the CSEs and the nation as a whole to be able to use and sustain IT for delivery of national critical functions and business services efficiently and effectively over a long period of time that extends into decades. It can be achieved through a combination of institutional structures, people, policies, governance, risk, and compliance (GRC) mechanisms.

Terms

The following terms establish a common vocabulary for communication of capabilities, objectives, activities and outcomes. They may be used within the organisations, from the executive level to the operations level, and with external stakeholders for business and technology level communication.

Information Technology (IT) capability is described as an organisation’s ability to identify IT business needs, to deploy IT to improve business process in a cost-effective manner, and to provide long-term maintenance and support for IT-based systems.

Information Security (IS) capability is defined as “an organisation’s ability to carry out a set of inter-related cybersecurity functions to secure, protect, defend and sustain its mission and business functions that run on underlying IT and OT infrastructure in the cyberspace”.

Cyber resilience is a key outcome expected from a full-fledged capability development program. A smart, resilient, and sustainable digital ecosystem is achieved at the national level only when all the stakeholders achieve a minimum level of cyber resilience through their individual capability development initiatives.

Functions represent sets of management and technical activities that organisations must carry out daily or periodically to achieve their cyber resilience objectives. The objectives are described using action-verbs defined below. Organisations can implement the functions through institutionalised practices and processes that must be carried out by the workforce, enabled by technology and tools.

Management Objectives and Activities

The action verbs describing the five management objectives are Govern & Administer, Acquire & Provision, Operate & Maintain, Analyse & Investigate, and Train & Enable. Activities to achieve the management objectives are usually owned, managed and carried out by different units and departments across the organisation.

Technical Objectives and Activities

The action verbs describing the five technical objectives are Identify, Protect, Detect, Respond and Recover. Activities to achieve the technical objectives are usually owned, managed and carried out by the IT, OT, IIoT and IS workforce of the organisation.

The technical objectives are derived from NIST CSF, and the guidelines issued by multiple regulators and national agencies. There are minor variations in the definitions of the action-verbs by these different bodies, which can lead to confusion and misunderstanding in conversations between the practitioners of different guidelines. Hence, it is suggested that the definitions given in this document be used as the base for generic discussions.

Description of Functions

A diagrammatic representation of the technical and management functions is given below.

The individual functions are further described below.

Identify

This technical function addresses the need for organisations to identify things of value that need to be secured and protected from harm. The key practices and processes under this function are:

• Asset lifecycle management: Identify and catalogue all the business and digital systems of the organisation, their physical and virtual assets, both in-store and in-use, across their lifecycle from acquistion till decommissioning.

• Information and data lifecycle management: Identify and catalogue all the business and technical information, data and documentation of the organisation, along with parameters that help define their sensitivity, organisational value, ownership, restrictions etc, across the lifecycle from creation till disposal.

• Identity lifecycle management: Identify all individuals, machines, devices, systems and applications along with their functions, roles, privileges, credentials, and access rights (to assets, information, data and documents) across the active lifecycle from onboarding till retirement.

The Identify function is a continuously running activity and needs regular review and update. The data managed through this activity is used by all other functions and is therefore a fundamental pillar of the framework. Automation of data collation and analysis activities under this function would be extremely useful to organisations, depending upon their size, budget, and risk profile.

Protect

This technical function addresses the need for organisations to establish and maintain robust defences by continuously searching for, discovering and acting upon vulnerabilties and weaknesses. A robust defensive action minimises the vulnerabilities and weaknesses and reduces the possibility of their exploitation by threat actors. The key processes under this function are:

• Protection of in-store and in-use assets spanning across geographies of the organisation’s operational structure. This is typically achieved through hardening of in-use systems, networks, applications, databases, and other components of the information infrastructure.

• Protection of data (at rest, in transit, in use) to achieve confidentiality, integrity and availability.

• Protection of identities of people, machines and devices.

• Protection of physical premises and safety of OT and IIoT systems.

A layered defence for business and digital systems with adequate monitoring and reporting is essential for achieving protection from a large variety of attack vectors. This requires a lifecycle approach that incorporate secure by design, secure in implementation and secure during operation. Custom-developed systems and software additionally require to be secure during manufacture/ development.

Detect

This technical function addresses the need for organisations to continuously observe, monitor, analyse, detect and classify threats emanating from anomalous events, activities, incidents, user behaviours, policy violations, infrastructure weaknesses, bypass of security controls, failures of security processes etc.

Continuous monitoring, analysis and detection of Indicators of Compromise (IoCs) and Indicators of Attacks (IoAs) is possible only through a proper collection and management of logs and other artefacts generated by the digital ecosystem.

The detect function at the organisation level must provide its observations to the central agencies for sectoral and national level situational awareness of potentially malicious activities in the national cyberspace.

Respond

This technical function addresses the need for organisations to act upon detected cyber incidents and cyber-attacks and respond to the same in order to contain/ mitigate their adverse impact.

Effectiveness of the Incident Response (IR) strategies is based on prior planning, having clearly earmarked responsibilities/ actions, and periodic testing of standard operating procedures (SOPs).

National agencies have an important role of supporting the CSEs in their response to debilitating, high impact cyber-attacks.

Recover

This technical function addresses the need for organisations to rapidly restore the business, IT and OT functions and/ or services that were impaired due to cyber-attack. This function is deemed to be successfully achieved when the services are restored with consistent data and the process is completed within the mandated “Time to Recovery”.

Incident analysis of breaches and cyberattacks on CSEs is essential, not only for rapid recovery within the affected CSEs but also for prevention of similar attacks on other organisations. National agencies have an important role to play in this regard and should implement mechanisms to ensure availability of essential logs (evidence) for carrying out necessary analysis. Automation of evidence recording by the technical functions is critical for rapid and effective incident handling.  

Entities should also endeavour to maintain voluntary information security sharing policy to enable broader cyber security awareness. Further, lessons from such information shared by other entities must be carefully perused to evaluate influence on internal cyber security functions.

Govern & Administer

This management function requires organisations to develop policies, practices and oversight mechanisms for governance and administration of people, processes, and systems on a day-to-day and periodic basis. It is based on establishing and maintaining an enterprise cybersecurity program and an ISMS that provides governance, planning, and operations support to the organisation’s cybersecurity activities. It includes practices and processes for planning and design of applicable guidelines and cyber security policies for the cyber-governance program and identification of risk to formulate mitigation strategy. Audit and compliance requirements are also covered under this function.

Acquire & Provision

This management function requires organisations to develop policies, practices and oversight mechanisms for acquisition and provisioning of trustworthy systems. It is primarily focused on conceptualisation, design, acquisition, and engineering of secure and trustworthy systems through a project-driven approach. It also includes supply chain risk management, covering systems, software, services, and workforce resources.

Regulators and national nodal agencies have a role in shaping policies, practices and guidelines for CSEs, specifically for acquisition of their critical systems, processes, services, and workforce. National initiatives for trusted supply chains are under design for supporting the CSEs through regulatory mechanisms.

Operate & Maintain

This management function requires organisations to develop policies, practices and oversight mechanisms for secure operations and maintenance of systems. It covers the entire gamut of people, processes, systems, and services.

Many entities assign the IT security functions to their IT operations workforce, whose primary responsibilities are to ensure the functionality, availability and performance of digital systems. Organisations must assign the IT security responsibility to a separate IT security team, distinct from the IT operations team. The team must be given separate resources for operation and management of IT security functions.

Analyse & Investigate

This management function requires organisations to continually analyse threats and risks and design, develop, test, implement, analyse, and improve the functions, thereby improving the cyber resilience of the organisation. Threat modelling, performance measurement and evidence collection are essential for any analysis to be effective. The evidence collection should also support investigations that may be triggered by multiple events like cyber incident report, new acquisition, observations during internal / external VAPT etc.

Train & Enable

This management function requires organisations to train the IT Operations, IT Security and Cybersecurity workforce and other employees (users of IT services) in the technical and management functions applicable to them. Workforce enablement is achieved through the development of organisational culture in which the workforce is encouraged to operate as a team, be accountable and empowered to take decisions within their scope of responsibility and authority.

Application of Capability Framework

There is a generalised relationship between the five management functions and the broader capability framework:

• The functions ‘Acquire & Provision’ and ‘Operate & Maintain’ represent the two major lifecycle stages of business and digital systems in CSEs. These functions will help the CSE to become “smart”, efficient and effective over time.

• The functions ‘Analyse & Investigate’ and ‘Train and Enable’ will help enhance the CSE’s organisational culture for developing “resilience” through continuous improvement.

• The ‘Govern & Administer’ function encompasses everything and enables the CSEs to have a long term “sustainability” approach.

Elements of Resilience and Sustainability

In general, cyber resilience is achievable through well-designed operating procedures, processes, and practices, while sustainability is achievable through a combination of institutional structures, people, policies, governance, risk, and compliance (GRC) mechanisms. High levels of cyber resilience and sustainability are largely achievable using technology and automation operated by skilled personnel. These are further described below.

Resilience Drivers

In the context of cybersecurity, resilience is usually achieved through:

• well-designed cyber secure architecture that incorporates the concepts of defense-in-depth and supports the processes and people responsible for its protection.

• responsive operating practices and processes to achieve resilience, such as:

  • keep the defenses and all possible attack routes under 24 x 7 watch (Logging, SOC).

  • quick response to anomalous activities that are observed by the SOC (IR).

  • rapidly carrying out defensive actions against materialized attacks (EDR, XDR, SOAR).

  • mitigate the impact of any successful penetration through the defenses (CCMP, BCP).

• a skilled and trained workforce is essential for successfully executing the operating processes.

Sustainability Drivers

In the context of cybersecurity, sustainability is usually achieved by:

• having the right cybersecurity policies in place.

• smart mechanisms to monitor the effectiveness of implementation and operation of the policies on ground.

• a culture of continuous improvement within the entities.

Strategic Program Management

Resilience and sustainability of IT and Information Security are strategic goals of organisations. Hence, they must be driven by the top leadership and management, who must take a long-term strategic view of both the use of IT to achieve business objectives and use of Information and Cyber Security to protect IT and business. Governing bodies and top leadership should assess whether they have adequate in-house capabilities to strategise on these two goals or they require external expertise to support their leaders and teams.

A smart, resilient, and sustainable digital ecosystem is achieved only when it is driven by the top leadership. It is a good practice to have a strategic oversight team that regularly consults, analyses and reports to the top management whether the organisation’s digital ecosystem sufficiently:

• Enables and supports the business requirements.
• Protects information and information infrastructure in cyberspace.
• Minimises weaknesses, vulnerabilities and risks through defensive actions.
• Detects failures and cyber exploits.
• Responds rapidly and effectively to IT and cyber incidents.
• Recovers quickly from disruptions and cyber-attacks with minimal damage.
• Is governed, administered, engineered, operated, maintained and managed by a competent workforce, through institutionalised practices and processes, supported by technology, platforms and tools.

A right combination of people, processes, technology and governance is essential for organisations to leverage the digital ecosystem to accomplish the organisation’s mission, fulfil the legal and regulatory requirements, maintain the day-to-day functions, and protect the assets and individuals.

Capability Maturity Models

This is described in detail here.

Internal Context

Operational Structure

Business Units

In the modern business and operational context, information technology has become a key business enabler. It is frequently the case that business units, also called line units, generate their own business requirements, consume external IT services, or get systems dedicated to their own units.

Departments

Departments, also called staff units, perform staff functions to support the entity’s mission. In the context of IT and Information Security, most staff functions are performed through multiple departments with complex interdependencies. Some of the departments involved in a typical CSE for smooth delivery of these functions are:

• Administration department manages personnel and physical security.

• Finance department manages the procurement.

• Workforce (HR) department ensures that people have the right competencies and critical positions are always staffed by candidates with the right mix of skills and experience.

• Legal and Corporate Governance department manages legal and regulatory compliance.

• Internal Audit department provides an independent view of compliance of processes and people.

• Technical functions related to IT are carried out by the IT Department 

• Information Security related functions are carried out by the Information Security Department.

It is also well-established that Information technology is a key enabler for non-IT staff functions. The functional requirements of various departments are typically enabled through IT. The IT department is usually responsible for the design, development and/ or procurement, implementation and deployment, operation and management of the IT infrastructure, operations, and support. The departments themselves focus on the usage side of IT, covering the users, applications, and data.

Further, the Information Security Department usually works closely with the IT and the Legal and Corporate Governance Departments as part of its responsibility and accountability towards the governance, risk, policies, compliance, and assessment of information security of the entity’s IT infrastructure.

Sites and Locations

Large enterprises are typically spread across multiple sites or geographical locations, typically referred to as remote or branch offices. Sectors such as Power and Energy have OT Sites in the form of substations and regional command and control centres. Enterprises with such geographically separated ICTs must ensure governance mechanisms and controls for the holistic cybersecurity of the entity.

Organisational Structure

Board of Directors

The Board of Directors of CSEs is ultimately accountable for cybersecurity in the organisation and its responsibilities would include:

• approving strategic goals, business objectives, and policies related to IT, Business Continuity, Information Security, Cyber Security, and Cyber Crisis Management, 

• approving the cyber risk appetite as part of the overall risk appetite,

• approving and overseeing the cybersecurity programme, strategy, and policy to manage cyber risks,

• ensuring the implementation of the cybersecurity program,

• being aware of and ensuring compliance with legal and regulatory obligations related to cyber security risks,

• supporting the culture of awareness of cybersecurity in the organisation,

• allocating adequate budget and resources for fulfilling cybersecurity requirements.

The Board of Directors of the CSEs should set up appropriate board level and other high-level empowered committees for the purpose of Governance of Enterprise IT and Information Security to support both strategic and operational goals while addressing the unique risk and compliance requirements in these areas. The governance structures should be kept in mind while framing these committees. Board should have independent director with substantial IT expertise in managing / guiding information technology initiatives. Further technically competent members should be there in the Committees formed. 

In case, any CSE doesn’t have a Board of Directors, then it would be the responsibility of the top management or executive leadership to set up appropriate high-level empowered committees for the purpose of Governance of Enterprise IT and Information Security and ensure their effective functioning.

CSEs having “Protected System” are mandated to constitute an Information Security Steering Committee (ISSC) under the Chairmanship of the Chief Executive Officer/ Managing Director/ Secretary of the organisation as per the Information Technology (Information Security Practices and Procedures for Protected System) Rules, 2018 notified vide Gazette Notification S.O. 2235(E) dated 22 May 2018.   

Top-Level Management

The top management of entities, led by the Chief Executive (Managing Director or CEO) is accountable to the governing body (or Board) with respect to the effective and efficient use of Information, Communication and Operational Technologies and Information Security. Most entities usually have permanent leadership roles, with teams under them, that constitutes enterprise-level top management. Typical leadership roles in a CSE are Chief Risk Officer (CRO), Chief of Operations/ Chief Operating Officer (COO), Chief Technology Officer (CTO), Chief Information Officer (CIO), Chief Strategy Officer (CSO), Chief Information Security Officer (CISO), Chief Human Resource Officer (CHRO) and, if required by law, a Data Protection Officer (DPO).

Top-level management’s responsibilities in CSEs will centre around strategic alignment, value delivery, risk management, resource optimization, and stakeholder engagement to leverage IT for competitive advantage and sustainable business performance.

The essential top-level management functions for Enterprise Governance of IT (EGIT) and Information Security Governance (EISG) are:

• Aligning IT and infosec goals and objectives with the overall business strategy and vision set by the Board of Directors. This involves

  • setting objectives and initiatives in line with the overall business goals.

  • establishing governance structures by creating committees and steering groups to oversee the alignment between business, IT and cyber resilience.

  • establishing entity-wide policies and programs.

  • ensuring stakeholder involvement.

• Providing leadership, direction and oversight for the IT and Infosec departments. This includes defining the IT operating models, planning, organising and implementing projects to achieve the desired business outcomes, budgeting, organisational structure, roles and responsibilities, and project management oversight.

• Resource Management - This entails ensuring optimal allocation and utilization of IT and infosec resources (e.g., personnel, technology, budgets), capacity planning, developing strategies for internal and external sourcing of IT and infosec services and solutions, exercising oversight on contracts with third-party service providers, outsourcing of work to Managed Service Providers (MSP), etc. Adequate resources should be designated specifically for cybersecurity, separate from those allocated for general IT needs. Allocation of such resources may widely vary based on the business objective and risk management of each CSE. However, based on global best practice, it is recommended that at least 10% of the total IT budget should be allocated to cybersecurity. This should progressively increase as per the cybersecurity risks faced by the entity. Such allocation should be mentioned under a separate budget head for monitoring by the Board of Directors, Governing Body

• Risk Management - This involves

  • establishing a risk management framework that identifies, assesses and mitigates risks associated with the use of technology, and ensures compliance with the relevant laws, regulations, and policies.

  • analysing and managing the business impact of degradation, failure and non-availability of IT, OT and IIoT systems, and safety of operational technologies (OT).

• Monitoring and measuring IT performance and value delivery - This involves

  • maintaining oversight using management systems for all IT, OT and Information Security aspects that can adversely affect the organisation.

  • establishing and tracking key performance indicators (KPIs) for IT and infosec services and activities.

  • using performance data to drive continuous improvement in services and processes.

  • benchmarking to compare IT and infosec performance against industry standards and best practices.

• Fostering effective communication, collaboration and partnership between business and IT stakeholders. Communicate regularly within and outside the entity to ensure coherence. This is especially important during crisis management related to high-impact IT and cybersecurity incidents.

The Enterprise Information Security Governance (EISG) functions are usually led by the CRO or the Enterprise CISO, who is responsible for the implementation of enterprise-wide information security policies, and exercising information security-related oversight on the business groups and business units of the enterprise.

A CISO should have knowledge and experience of information security governance, risk and compliance management, ISMS and related issues. The CISO’s responsibilities typically includes cyber resilience and cybersecurity planning, development and rollout of ISMS, coordinating the cyber security related issues within the organisation and with relevant external agencies. The CISO must be capable of performing the duties as per “Roles and Responsibilities of CISOs” as defined by NCIIPC, CERT-In and Regulators.

CSEs must clearly define the roles, responsibilties and teams for governance of enterprise IT and information security, as appropriate to their organisational structures. The leadership and teams must be given the required authority and resources to carry out their functions and held accountable for the required outcomes. A key factor for success is the ability of the leaders, their teams, business units and departments to work collaboratively to address the shared concerns of all stakeholders. Adequate thought must be given to behavioural aspects and conflict resolution mechanisms while assigning responsibilities to leaders and teams. Further, each team must have a proper mix of expertise and experience and should use technology to carry out the functions effectively.

Committees

Entities usually have different formal and semi-formal structures to support the governing body and the top management in their IT and information security governance functions. These structures are in the form of committees, groups, task forces etc, and typically carry out evaluation, monitoring, and oversight functions to support the governing body and the top management.

Many Sectoral Regulators have prescribed the frameworks for the Governance of Enterprise IT and Information Security for their regulated entities. The governance frameworks and governance related guidance of the important regulators of the country emphasise the need to have a good governance framework for enterprise IT and Information Security of entities using ICT for achieving their business mission and objectives.

Information Security Division/ Department (ISD)

The ISD of an entity is responsible for planning, implementing and continually improving the technology-driven capabilities, processes, and workforce to achieve cybersecurity.

Each business group or unit in the CSE may have its own ISO (Information Security Officer) and a team under him who may hierarchically report to the CISO. Together, they constitute the entity’s Information Security Division/ Department with appropriate resources and manpower based on the size and business of the CSE.

Technology Strategy and Perspective Planning

All modern enterprises use technology to carry out their business functions. A good practice followed by many organisations is to have a Technology Strategy and Perspective Planning (TS&PP) programme for planning, implementing and continually improving the technology-driven capabilities, processes, and workforce.

The technologies and processes are typically deployed through individual projects that are conceived, designed, and implemented by different business units and departments. In many cases, this leads to duplication or inadequate optimisation of enterprise resources, operations, and workforce utilisation.

The use of IT, OT and Information Security should therefore be evaluated, directed, and monitored from an entity-wide perspective that enables the governing bodies and top management to holistically evaluate the achievement of mission and business objectives. This will ensure that the individual IT, OT and IS projects of different business units and departments are aligned with the enterprise’s strategic IT and Information Security objectives and compliant with all enterprise policies and processes. Further, it helps in the optimisation of investments, IT and cybersecurity workforce competency development, exploitation of the latest technologies and practices, continuous improvement of cybersecurity maturity etc. 

Organisations will benefit from having an entity-wide TS&PP programme that provides enterprise-wide strategic direction and decisions on the use of IT, OT, and information security. The CTO, CIO, Heads of OT and CISO should be a part of Technology Strategy and Perspective Planning committee. Typically the committee should

• evaluate the objectives and expected outcomes of different projects within the overall technology adoption roadmap of the organisation.

• synergise activities and investments across multiple projects.

• provide oversight and guidance to individual project management teams.

• oversee the cyber resilience aspects.

Performance and Effectiveness Monitoring

Governing bodies and top management should have a well-defined mechanism for monitoring and measurement of IT, OT and Information Security performance and effectiveness of management systems and processes at the strategic, tactical, and operational levels. The monitoring and measurement mechanism should cover all processes, both automated and manual, with the objective of providing actionable evidence to take preventive and corrective actions at each level.

Metrics are tools designed to enhance the performance and accountability through collection, analysis, and reporting of relevant performance related data. Metrics in information security track the achievement of set goals and objectives by measuring the degree to which security measures are applied, as well as assessing the controls’ efficiency and efficacy, evaluating the sufficiency of security measures, and pinpointing potential areas for improvement. Entities should develop Key Performance Indicators (KPIs) for evaluation of their IT and Information Security programmes and periodically evaluate the implementation and effectiveness of their IT and Information Security Governance programmes by measuring the defined KPIs.

Organizations will benefit significantly from having a Performance and Effectiveness Monitoring (P&EM) programme to assist the governing bodies and top management in their function of enterprise-wide monitoring and measurement of IT, OT and infosec performance and effectiveness. The Governance, Risk and Compliance team should work with the business units, IT, OT and Infosec Heads and other stakeholders to develop KPIs that monitor and measure vital aspects of IT, OT and Information Security processes, people and technologies. The KPIs should address the concerns of the governing body and top management.

CSEs should put in place a structured process of reporting cybersecurity related matters to the Board or the Board Level Committees through the CISO. Structured reporting should inter alia include, key cyber risks faced by the organisation, cyber security preparedness, cyber security postures, organisational initiatives to enhance the cyber security resilience, status of compliance with regulatory guidelines, reporting of cyber security events and incidents.

Governance

Organisational governance is defined as “a system by which an organisation makes and implements decisions in pursuit of its objectives.” Organisational governance is achieved by a mix of standards, rules, processes, practices, and technology platforms that support maturity in governance.

In view of enhanced role of ICT for achieving the business mission and objectives, governance of IT and information security are considered as a subset or domain of organisational (entity) governance. Definitions of governance in specific context of IT and Information security are provided in ISO/IEC 26000, ISO/IEC 38500:2015¹ and ISO/IEC 27014:2020².

• Governance of Enterprise IT (ISO/IEC 38500:2015) deals with resources required to acquire, process, store and disseminate information.

• Enterprise Information Security Governance (ISO/IEC 27014:2020) deals with assurance of information confidentiality, integrity and availability and effective communication of the same with various external stakeholders.

Governance of Enterprise IT

 A model for good governance of IT shall assist those at the highest level of the entities to understand and fulfil their legal, regulatory and other obligations in respect of their entity’s use of IT.  Further it assists governing bodies to ensure that the use of IT contributes positively to the performance of the organisation. Governing bodies should exercise their authority to ensure that their organisations follow a well-defined and suitable model for governance of IT, based on global best practices, to ensure that the risks arising from the use of IT can be managed and opportunities can be exploited.

ISO/IEC 38500:2015 describes the principles and practices for good governance of IT and provides a baseline for each entity to develop their own model. The six core principles are:

1. Establish responsibility.

2. Define strategy for IT to support business.

3. Make acquisitions as appropriate.

4. Ensure performance.

5. Ensure conformance.

6. Achieve appropriate human behaviour.

Further, three main practices through which the governing bodies can continuously evolve governance of IT are:

1. Evaluate the current and future use of IT in the context of the business need.

2. Direct preparation and implementation of strategies and policies to ensure that use of IT meets business objectives.

3. Monitor performance against the strategies particularly regarding their business objectives and conformance to external obligations and internal work practices.

Governance of Information Security

Governance of information security ensure effective implementation of information security controls and provides the following assurance:

• Directives concerning information security will be followed.

• The governing body will receive reliable and relevant reports about information security related activities.

The framework for governance of information security will assist the governing body to make decisions concerning the strategic objectives for the organisation. It further provides information about information security that can affect these strategic objectives. It also ensures that information security strategy aligns with the overall objectives of the entity.

ISO/IEC 27014:2020 defines six objectives for information security governance that provide a baseline for overall direction and control by the governing bodies and the top management. The detailed description of each objective and process is given in the ISO document. The practical application of each objective within an entity is briefly described below:

1. Establish integrated comprehensive entity-wide information security

Objective 1 calls for the establishment of an integrated comprehensive entity-wide information security framework. In practice, this would generally be addressed as under:

• Organisations should define and document an enterprise level context for their Information Security Management System (ISMS). Further, the context, scope, external elements etc. of each of their individual ISMS implementations (business-unit or site-based) should flow from and be fully aligned with the enterprise context.

• Organisations should define and document an enterprise level ISMS objective and policy. The ISMS policies of each of the individual ISMS implementations should be aligned with the enterprise context.

An enterprise level approach would provide the following benefits:

• Governing bodies and top management can evaluate, direct, and monitor that information security is consistent across the enterprise.

• Regulators and national nodal agencies can validate that the policy directives and regulatory guidelines provided to the regulated and critical sector entities are incorporated into the enterprise level ISMS framework, which further gets applied uniformly into all the ISMS implementations in the entities.

• Auditors can easily assess and verify whether all the mandated policies have been incorporated in each of the ISMSs audited by them.

2. Make decisions using a risk-based approach

Objective 2 calls for using a risk-based approach for decisions. A risk-based approach is recognised world-wide as an effective mechanism for inter-se prioritisation of the following:

• Investment in protection functions that includes business continuity.

• Allocation and use of resources.

• Work related to tracking and monitoring functions.

• Incident response and crisis management activities.

In general, risk is a function of impact and likelihood. However, entities may decide that the potential impact of some of the disruptions are so devastating that they have the highest risk even if their likelihood is very low. In all other cases, risk reflects the organisation’s ability to accomplish its assigned mission, protect its assets, fulfil its legal responsibilities, maintain its day-to-day functions, and protect individuals.  

Regulated and critical sector entities would benefit from using the ISO, IEC, NIST and other well-known standards to design, develop and implement risk management system within their organisations. A risk-based approach helps entities correctly identify all the controls that are applicable in their ISMSs.  An enterprise level approach to risk management would provide the following benefits:

• Governing bodies and top management can evaluate the information security risks with the use of IT to achieve business objectives and further incorporate them into the enterprise level ISMS framework. This will help them direct and monitor the individual ISMSs effectively.

• Regulators and national nodal agencies can validate that all the additional controls prescribed by them are consolidated into the enterprise level ISMS framework, which further gets applied uniformly into all the ISMS implementations in the entities.

• Cybersecurity auditors can use the comprehensively defined Statement of Applicability (SoA) to verify that all risks have been considered for their technical audit.

3. Set the direction of acquisition

Objective 3 calls for setting the direction of acquisition of IT, OT, and Information Security capabilities in a comprehensive and consistent manner.

The enterprise level risk assessment carried out as part of Objective 2 will help in the prioritisation of investments and allocation of resources. The Information Security Steering Committees (ISSC) of critical sector entities can provide right guidance to the top management when there is a common understanding of risk.

4. Ensure conformance with internal and external requirements.

Objective 4 calls for ensuring conformance with internal and external requirements.

One of the objectives of regulators and national bodies is to standardise information security management and its audit across various entities, particularly the critical sector entities. A common approach and methodology of audit of IT Security can be achieved through the guidelines given in various national / international standards.

Entities should evaluate and adopt an internationally accepted methodology for audit of the implemented IT and Information Security Management System at agreed frequency and scope (this frequency and scope should be compliant with the minimum baseline promulgated vide various rules and regulations). The audit scope, audit objective, audit criteria and the competency of the auditors should be such that it provides adequate assurance to the stakeholders on the objectivity and impartiality of the results. The results of the audit are to be reviewed at an appropriate level in the entity / controller / regulator. The causal analysis and corrective action plan for any non-conformities observed in the audit are also to be reviewed and tracked for acceptable closure.

5. Foster a security-positive culture

Objective 5 calls for fostering a security-positive culture, which is largely a people-driven activity. This requires the top management to focus on building a positive information security culture within the entity through security education, training and awareness programs and integrating the information security responsibilities into the roles of employees and managers.

6. Ensure the security performance meets current and future requirements of the entity

Objective 6 calls for ensuring that the security performance meets current and future requirements of the entity.

A data-driven analytical approach for security performance monitoring and measurement would be highly beneficial for entities. This approach requires entities to identify and use software applications and automation platforms for data acquisition, evidence collection and analysis of both IT and information security performance. The acquired measurement data would help the internal, external, and special audit teams to review and assess the information security processes and activities.

National nodal agencies can further evolve platforms and processes for machine-processing of data from different entities to carry out sectoral and cross-sectoral analysis of audit compliance, audit effectiveness and grading of auditors. 

The governing bodies and the top management may apply following four main processes repetitively to achieve the above objectives:

1. Evaluate

2. Direct

3. Monitor

4. Communicate

Essential Top Level Management Governance Functions

The key processes for governance of Enterprise IT and Information Security are depicted in the pictorial below.

A harmonised view of the governance functions are covered here.

Summary

The governance frameworks provide the core principles, objectives and processes in IT and Information Security for the governing bodies and top management to implement effective governance in their respective business context. The focus of governance of IT is on managing resources to acquire, process, store and disseminate information (this may include OT and IIoT). This functionality is complemented by the governance of Information Security, which focuses on confidentiality, integrity, and availability of information (including the safety of OT and IIoT).

The governing bodies and top management of all regulated and critical sector entities are accountable for the Governance of Enterprise IT and Information Security. They have the responsibility to evaluate and direct the specific actions required to implement the principles within their organisations and monitor their efficacy. In short, Governance of Enterprise IT and Information Security are board-level agendas.

Communication is an important Information Security governance process since it enables entities to be held accountable to interested parties. As part of this function, the critical sector entities must maintain continuous information flow with the national nodal agencies and the sectoral regulators. This communication is necessary for the national nodal agencies to evaluate the effectiveness of their risk management and information security management.  The entities are also required by law to report information security incidents to appropriate national nodal agencies and regulators, as applicable.

Assurance aspect is overseen by the sectoral regulators and the national nodal agencies bodies, who exercise their authority to audit the regulated and critical sector entities for compliance to law, regulation and directives issued by them.

It is also important to recognise that, while the authority for specific aspects of IT and Information Security may be delegated to managers within the organisations, the accountability for effective, efficient, and acceptable use of IT and Information Security within the entity and all its organisations remains with the governing body and top management in case of CSEs. This responsibility and accountability cannot be delegated.

The governance of enterprise IT and information security in the internal context (within the jurisdiction of the entity) is fairly straightforward. All entities typically implement their IT, OT and IS infrastructure to align with their business functions. The operational structure is usually in the form of business units, departments, sites/ branches, and locations. The organisational structure is closely aligned with the operational structure in the form of a governing body or board, top or executive management, senior, middle-level, and lower-level management.

Acquisition of capabilities

The acquisition of capabilities to enable and support business needs is an important activity within organisations and also in the larger ecosystem. This section focuses on information and guidance related to acquisition of business and technology capabilities by the stakeholders.

The audience for this section includes:

• Business Unit heads, CIOs, CISOs.
• Technology strategy and perspective planning team.
• Project management and procurement teams.
• Technical implementation teams.
• OEMs and System Integrators (SI), service and support providers, consultancy organisations, inspection and audit bodies.

Overview

All capabilities are acquired through project or incremental procurement based approach, using capital or revenue budgets. Business and technology capabilities typically have two major lifecycle stages:

• Acquire and Provision.
• Operate and Maintain.

The Acquire and Provision stage has a shorter lifespan of a few months, as compared to the Operate and Maintain stage, which typically extends into a few years for IT or tens of years for OT. A “Go-Live” event typically separates the two stages.

Government, public sector entities and large enterprises have two broad frameworks for acquisition of capabilities, namely, Detailed Project Reports (DPR) and Request for Proposal (RFP).

The DPR framework is used when the requirement is for large scale and complex use of IT for transformation of business functions. RFPs are more focused and are typically used for incremental improvement of business functions using IT.

Technology Strategy and Perspective Planning

A study of various DPRs indicate that they reflect the strategic direction of the organisations in the use of IT and cover a period of 7 to 10 years. However, each DPR is usually treated as a standalone document and the strategic thinking recorded in one DPR is not fully carried into other DPRs.

Entities may consider the development of a common “Technology Strategy and Perspective Planning (TS&PP)” document that captures the entity-wide strategic use of technology by the organisation. All DPRs and RFPs must then be aligned with the TS&PP document.

The following aspects of strategic direction that is typically recorded in the DPRs, may be moved into the TS&PP document:

• Mission, functions, business capabilities and business processes of the organisation.
• External context – other organisations with whom governance, business and IT-driven interactions are carried out. This should also include the likely sources of threats and liabilities created by the external partners.
• Internal context – organisational hierarchy and structure, sites and locations, line, staff and functional units, roles and responsibilities of departments and key personnel.
• Current state of use of IT and information security to support the business functions.
• Expectations from the use of IT in terms of enhancement of capabilities, efficiency, and effectiveness in carrying out the business functions.
• Expected or desired future state of use of IT and information security.

Some examples of strategic directions regarding the use of IT are given below:

1. Selection of data centre and cloud service providers:

• owned by the organisation.
• provided by a government-owned or public sector entity.
• provided by a private entity with India-based data centres.
• multi-country-based data centres.

2. Models of cloud deployment:

• IaaS
• PaaS
• SaaS
• XaaS

3. Data access concerns:

• data access is required only for India based users and systems.
• data access is required for users and systems located outside India.

4. Data localisation concerns:

• data can reside in any country.
• data can reside in any country, but one copy must reside in India for accessibility to regulatory and legal authorities.
• data must reside within India only and not move out of Indian jurisdiction.

5. Models of workforce supply chain:

• entity’s own employees.
• contracted employees hired from manpower provider entities.
• outsourced work to service providers using their own employees.

6. Data classification and handling methodologies for data that is created, stored, and shared in electronic form.

7. Information Security Assurance and ISMS:

• entities to have a trusted mechanism of internal and external audits, undertaken and reported by competent independent auditors.
• the audit scope, audit objectives, and audit criteria to be defined by the entity in consultation and direction of the concerned controlling / regulating body.
• the audit methodologies adopted to be in accordance with internationally accepted practices.
• the competency of the auditors to be ensured and ascertained through recognised trainings and evaluation criteria.

8. Information security capabilities to enable smart, resilient, and sustainable digital ecosystem.

9. Systems and security engineering lifecycle approaches.

10. Technologies, practices, and operating processes.

Enterprise Architecture

Organisations acquire off-the-shelf, custom-developed or SaaS-based business systems like ERP, CRM etc, to automate the business and industrial processes that deliver their business needs. The business systems run on underlying technology systems, which may be off-the-shelf, custom-built or in the cloud.

A well-defined and well-designed architecture is crucial for the long-term resilience of an organisation’s business and technology systems. The mandatory governance, risk, compliance, and audit requirements prescribed by the regulators and nodal bodies are best achieved when they are embedded into the enterprise business and technology architectures of the entities.

The Enterprise Architecture Framework provides common information and guidance to create good architecture documents for use by various stakeholders responsible for design, engineering, implementation, maintenance and incremental enhancements of systems.

Enterprise architects are the best people to create the business and technology architectures. The Technology Strategy and Perspective Planning Group may be assigned responsibility for its creation, periodic review and update. The group should also advise the advise the top management on providing the required strategic direction. Once accepted by the top management, the architecture can be used as a common base framework in DPRs and RFPs.

Ontology of Tags

Entities use a wide variety of methods to depict and describe their enterprise business and technology architectures. However, there is no commonality on this aspect amongst the CSEs of different sectors.

The ontology of tags provides a common mechanism for business and technical managers to express distinct characteristics or features of various architectural elements. The common ontology helps different stakeholders to evaluate the impact, risk, compliance, governance, security, monitoring, and oversight aspects of the architecture elements. A combined view of all the evaluations can help the top management to decide and direct the most appropriate use of IT and prioritisation for investments.

The business and technology operation levels of the entity hierarchy can further use the ontology of tags to evaluate, decide, design, procure, implement, deploy, operate, manage, support, and monitor the digital ecosystem resources over their operating lifecycle.

The common ontology also helps the Government ministries, regulators, and national nodal bodies to focus their policies, regulations, oversight, and monitoring mechanisms on the vital components of the enterprise architecture.

Engineering of ICT and Security

The engineering aspects describe “how” ICT and cyber resilience capabilities can be implemented by proper conceptualisation and execution of IT and OT projects as well as through incremental engineering improvements during a project’s operating lifecycle. It delves into systems engineering and systems security engineering in IT, OT and IIoT systems. It also delves into cyber resiliency engineering, an emerging specialty system engineering discipline to develop survivable, trustworthy secure systems.

The audience for this chapter includes:

• Business Heads, CIOs, CTOs, CISOs and their respective teams within CSEs.
• Sectoral Regulators, who are mandated to oversee/ regulate the cybersecurity related issues of their regulated entities.
• Consultancy organisations, System Integrators, OEMs and MSPs/ MSSPs engaged by the CSEs.
• Empaneled bodies, who carry out cyber security verification & validation (V&V), VAPT and technical audit of systems and networks of CSEs.
• the lower levels of management, who are responsible for project execution and maintenance of systems in the operations phase.
• project design and implementation teams, who conceptualise, design and implement the ICT and cyber security elements for protection of their IT, OT and IIoT.
• engineering support teams, who support the operations teams during the use of ICT, OT and IIoT.

An engineering lifecycle approach is essential for successful delivery of business and technology systems. Readers may refer to relevant material included in the standards section of this document.

Engineering requires the knowledge of concepts and technologies related to the use of IT and information security. The resources section provides links to well-known public documents.

Systems Engineering

It is globally recognised that large and complex IT and OT systems need to be engineered and secured using a life cycle approach. The design and engineering teams are expected to apply the knowledge, concepts, and principles from international work on systems engineering. The publications cover the principles and processes of systems engineering and systems security engineering, connecting the governance, program management, technology (systems) and operations layers within enterprises.

Systems and software engineering lays the groundwork for a disciplined and organised approach towards building reliable, trustworthy secure systems. It is a collection of system life cycle technical and nontechnical processes with associated activities and tasks. The technical processes apply engineering analysis and design principles to deliver a system with the capability to satisfy stakeholder requirements and critical quality properties. The nontechnical processes provide engineering management of all aspects of the engineering project, agreements between parties involved in the engineering project, and project-enabling support to facilitate execution of the engineering project.

Systems Security Engineering

The systems security engineering discipline is applicable at each stage of the system life cycle and provides security considerations towards the engineering of systems. The system security engineering processes are designed to address cybersecurity aspects in IT, OT and IS projects. These processes are typically carried out by design and engineering teams during the project implementation phase, and by field engineering teams during the operations phase.

Systems security engineering ensures that stakeholder protection requirements, and security issues associated with the system are accurately recognized and addressed in all systems engineering tasks throughout the system life cycle.

An organisation adopting systems security engineering lifecycle approach will be able to incorporate security by design and engineering during all the lifecycle stages of IT and OT systems, right from conceptualisation to design, procurement, installation, commissioning, acceptance, operations, and retirement.

Cyber Resiliency Engineering

Cyber resiliency engineering is an evolving specialised discipline within system engineering, employed together with systems security engineering and resilience engineering to develop systems that are secure, dependable, and capable of withstanding threats.  This is predicated on the assumption that adversaries will breach defences and establish a long-term presence in organisational systems. Hence, the focus should be on assuring the continuity of mission or business functions and reducing the risk of potentially compromised cyber resources.

Guidance on Systems and Security Engineering

Currently, implementing cybersecurity in large and complex systems is generally a bolt-on activity. The conventional VAPT carried out prior to acceptance of systems happens shortly before the system is put into production. At this stage, the time pressure typically impacts the level of testing of the robustness of security of the system.

The systems security engineering approach must be incorporated in every stage of the system cycle, covering both business systems and technology systems. This will ensure that the security architecture is of high quality and is based on the rigour with which the fundamental security design principles have been applied in the system lifecycle.

The following aspects must be considered while acquiring any new software/ application:

• complete cybersecurity life cycle support for the software system.
• appying the principles of Dev-Sec-Ops in the custom-development of software applications.
• mechanisms for software enhancements and bug fixing activities to avoid adverse impact of software weaknesses and vulnerabilties.
• skillsets required (in-house or through support services) for secure operations of the acquired system.
• carrying out VAPT and all vulnerabilities removed/ patched before any system goes live.
• accountability of OEMs and suppliers to follow the Information Security Engineering Lifecycle approach in the manufacturing/ assembly/ development of their products.
• non-acceptance of products/ solutions which have not followed the system security and cyber resiliency engineering best practices in the product development and in providing maintenance support services.

Senior management, business heads, operations and support teams must develop in-house expertise or hire experts to help adopt systems security engineering lifecycle approach within their enterprise projects, starting with securing their CII.

Operations, Maintenance and Management of ICT and Security

The operations aspect focuses on “how” ICT and cyber resilience capabilities can be achieved during the operation phase of business and technology systems, through well-designed operating processes enabled by technology and tools, and by a workforce that is adequately trained on the processes and tools.

The audience for this chapter includes:

• Business Heads, CIOs, CTOs, CISOs and their respective teams within CSEs.
• Sectoral Regulators, who are mandated to oversee/regulate the cyber security related issues of their regulated entities.
• Consultancy Organisations, System Integrators, OEMs and MSPs/ MSSPs engaged by the CSEs.
• Empaneled Organiszations to carry out cyber security verification & validation (V&V), VAPT and technical audit of systems and networks of CSEs.
• the lower levels of management, who are responsible for day-to-day business and technology operations.
• process design teams, who conceptualise and design ICT and cyber security operating processes for day to day use and for protection of ICT, OT and IIoT.
• operations teams, who implement and execute the day to day business and technology operating processes.
• workforce development teams, who train and enable the workforce to absorb and adopt technology and the day to day operating processes designed for achieving business and cyber resilience.

Operations and Management Practices

There is an intrinsic association and a high degree of interdependence between the practices of IT Operations (IT-Ops), IT Operations Management (ITOM), AI-driven operations (AI-Ops), site reliability engineering (SRE), information security operations (IS-Ops), Dev-Sec-Ops and CI/CD pipeline activities.

At the macro level all operating and management practices have a generic purpose to help improve visibility, observability, compliance, control, responsiveness, and reporting within the critical sector entities themselves, as well as in the larger federated digital ecosystem.

At a granular level, the execution steps of operating and management processes would be sector/ entity and context specific, depending on generic and sector/ entity-specific factors. These factors include the entity type, size, geographical spread, heterogeneity of the technology layer, proportion and maturity of IT and OT implementations, the overall maturity of the prevailing cybersecurity implementation etc.

Further, all processes need to be monitored regularly for their effectiveness.

Guidance on IT and Cybersecurity Operations

Establishing Good Practices and Processes

One of the key aspects of operations is the distribution of responsibilities and associated practices between the inward-looking IT operations and IT security teams and the outward-looking Information Security (Infosec) teams.

• The IT Operations and IT Security teams form the first line of defence. They carry out defensive and protective activities such are patch, vulnerability and compliance management, system hardening, configuration baselining and change management, backup management, network access control, domain management, identity and role-based access management, service desk, ticketing and case management.
• The Information Security GRC and SOC teams form the second line of defence. They observe the internal and external environments, monitor the risk and detect cyber threats to the digital infrastructure.
• The IT Operations and IT Security teams also carry out many of the incident response and recovery activities, in close coordination with the SOC teams.

Resilience of business, technology and cybersecurity operations and support essentially depends upon good operating and management practices and processes. These can be based on an Integrated Service Management (ISM) framework that combines both ITSM and ISMS and draws upon well-defined national/ international standards. Readers may refer to relevant material included under standards.

Developing Workforce Competencies

Modern IT Systems are reasonably large and complex, and the teams require different skill sets and expertise levels to handle the entire gamut of IT and Information Security operations effectively. The competency framework provides a broad structured approach and guidance to CSEs on how to establish a strategic program for ensuring cybersecurity competence in their workforce across their respective organisations.

Leveraging Technology as an Enabler

A critical element for every organisation is the proper and effective use of technology by its workforce to achieve different cybersecurity functions. The following teams will benefit from technologies and platforms:

• Enterprise Governance, Risk and Compliance (GRC) team, who are responsible for enterprise-wide governance, policies and management of risk and compliance.
• The CIO, IT Operations and IT Security teams and management personnel, who are responsible for day-to-day management of the digital infrastructure.
• The CISO, Information Security SOC teams, who are responsible for SOC operations.

Besides the teams listed above, the following teams and groups require information and guidance on IT, OT and IS technologies, products, platforms, and solutions:

• The Technology Strategy group, systems engineering and systems security engineering teams, who are responsible for conceptualisation, design, and implementation of systems.
• The acquisition and provisioning teams, who are responsible for preparation of RFPs and evaluation of solutions.
• Persons responsible for tracking and enhancing cybersecurity performance and maturity since technology usage is essential for achieving higher levels of cybersecurity capabilities.

The technologies and platforms need to be selected based on relevance to the organisation’s business functions and processes. Readers are advised to refer to the resources section and Techsagar, the national repository of India’s cybertech capabilities, for identification of suitable ‘Made in India’ IT resources to meet IT/ IS requirements.

Automating the Processes using Technology

Given the increased use of IT by CSEs, many of the manual and semi-automated IT and information security processes of yore need to be enhanced to higher levels of automation using technology. The Dev-Sec-Ops and CI/CD pipeline used in software development lifecycles are examples of modern process automation. Automation frameworks are also being developed for content-based processes such as governance, risk, compliance, audit, information sharing and AI/ML enabled decision support.

CSEs can improve the efficiency of its workforce significantly by using standard operating processes (SOPs) for routine jobs and employing technology to run the standardised processes. Enabling manpower with technology to meet IT and IS, is strongly recommended.

To achieve automation and workforce enablement, it is essential for an organisation to have suitable manpower with adequate enablement through training, technology, and availability of resources to undertake jobs at levels as mentioned below:

• Operating Level: This is the basic workforce of most Organizations that is capable of “doing things” at the operating level.
• Operational Analytics Level: Competent workforce with capability to analyze issues at the operational, tactical, and strategic levels and suggest mitigation measures. This workforce needs IT-enabled analytical support tools to demonstrate reliability and efficiency in their operations.
• Design Level: This level requires experienced specialists with skills and competence to design the operating and analytical processes and configure the platforms, to execute them.

Automation in CTI Sharing

The critical success factors for cyber resilience and sustenance of the nation’s digital ecosystem are:

• The speed and quality of detection of compromise and cyber-attacks within the entities.
• The rapidity by which information and guidance is disseminated to all the actual and potential targets.
• The speed and effectiveness of response within entities as well as across sectors and cross-sectors.

Conventional paper-based and email-based methods of sharing are not capable of achieving the required speed in information sharing amongst all the stakeholders and participants, since they are less amenable for automated processing. Use of standardised STIX, TAXII and TLP protocols (or equivalent protocols) is a recommended for sharing CTI with speed and objectivity to counter cyber-attacks. Details of such protocols are covered in protocols section.

Community-driven MISP platform and OASIS STIX/TAXII protocols with TLP based classification is considered well suited for the Indian IT ecosystem at this stage. A coherent approach is required for adopting TLP, MISP and STIX/ TAXII as the core elements for operational cybersecurity information sharing. Standardisation in this aspect can help achieve balance between speed (with ambiguity or inaccuracy) and correctness (with delays) in sharing of CTI.

Workforce

Organisational Structure

Workforce responsible for IT, OT, IIoT and Information Security within organisations can be generically divided into four levels of hierarchy, as given below. Typical job titles at each level are also mentioned, which are indicative of the associated job roles, tasks, and responsibilities.

• Governing board and top management level – Board of Directors, MD, CEO.

• Senior management level – Vice Presidents, CFO, CRO, CHRO, CTO, CIO, CISO, CSO, Heads of Business Units, Divisions, and Departments.

• Middle and lower management level – IT Project Managers, Technology Managers, IT Operations Managers, IT Security Managers, Cyber Defence, NOC, and SOC Team Leads, GRC Managers, Workforce Development Managers etc.

• Individual Contributor level – Operators, Analysts, Administrators, Specialists, Engineers, Technicians, Architects, Developers, Testers, QA, Apprentices, Associates, Interns. Individual contributors may also include MSP/ MSSP personnel and contractors etc, working in the CSEs.

The middle and lower management, as well as individual contributors, are accountable and responsible for day-to-day operational activities and tasks.

Workforce Competencies

The overall workforce in an organisation, having accountability and responsibility for cybersecurity, would typically comprise of a composite mix of employees, contracted/ hired resources, and external providers of products (OEMs/ ISVs) and services (OEM partners, System Integrators, consultants, other service providers). The essential competencies and focus of the composite workforce are summarised in the table below, along with the applicable knowledge, skills, expertise, and experience.

Ownership of Activities and Tasks

All operating processes within organisations are owned and carried out by designated teams, each having middle and lower-level managers overseeing the operations on a day-to-day and periodic basis.

Typically, the team compositions include different individuals with specialized skills and knowledge. Given the size and complexity of IT, OT, IIoT and cybersecurity ecosystems, the CSEs and other organisations usually have a composite workforce which is a mix of own employees, contracted workforce, resources of SIs, OEMs, ISVs, Partners, consultants, MSPs, SaaS and other service providers, who work together to carry out the organisations’ activities and tasks. A must have practice for an outsourced workforce is to have senior and middle-level managers of the organisation oversee the outsourced work.

Cybersecurity practices and processes can map across multiple cybersecurity support functions due to the interconnected nature of cybersecurity operations, where different aspects of a process may support various functions simultaneously. Considering the interconnected nature of cybersecurity activities, entities should assign the primary ownership and support roles to the activities related to each practice/ process.

Primary ownership indicates the team or role with overall responsibility for executing a particular cybersecurity process or function. The primary team or role is accountable for the required outcomes and decision-making. The support (collaborative() role identifies the supporting teams or roles that contribute to the overall objectives of the practice or process. They may be required to provide necessary data, analysis, or assistance to ensure the process’s success.

The top and senior management of CSEs may use well-known mechanisms like RACI matrix to outline the roles and responsibilities of individuals and teams. The primary owners must be clear about their responsibility and accountability while the collaborative teams and roles must know what support is expected from them.

It is essential that the top and senior management clearly communicate the overarching objectives of cybersecurity and how each team’s efforts contribute to them. Cyber resilience can be enhanced when there is a shared sense of purpose and reduced friction between teams that usually arises due to overlapping or conflicting purposes.

Organisations will accrue significant benefits if their workforce understands the end goal of the practices and processes, and how the activities and tasks help or harm the accomplishment of the goal. Training and enablement of the workforce should focus on this aspect so that the workforce has a clear understanding of their ownership and responsibility for achieving the objectives.

Enterprise Architecture Framework

Enterprise Architecture is a discipline that provides a holistic and integrated view of an organisation’s strategy, processes, information, and technology. This enterprise approach enables the alignment of various components of the business to work cohesively towards common goals. Within the Enterprise Architecture Framework, ‘enterprise’ can be understood in two key contexts:

• The broad spectrum of the enterprise, inclusive of all people, processes, and technology
• A particular domain within the enterprise, such as a specific business unit or functional area.

In both scenarios, the architecture spans multiple of systems and encompasses numerous departments within the organisation. When the objective is to create a cohesive network that includes the extended enterprise, it involves not only the internal divisions but also external entities such as partners, suppliers, and customers.

The aim of enterprise architecture as a framework is to optimise the often-fragmented legacy of processes across the enterprise (both manual and automated) into an integrated and secure environment that is responsive to changes and supportive of the delivery of the business strategy.

This section provides a reference framework to governing bodies and top management of regulated and critical sector entities to establish ‘due diligence’ on the use of IT in their respective entities. It describes the Enterprise Architecture Framework (EAF) at two levels, viz:

• Enterprise Business Architecture Framework (EBAF).
• Enterprise Technology Architecture Framework (ETAF).

The business architecture context is about how the organisation delivers value to its stakeholders. The technology architecture frameworks are about using technology to support the business mission, goals, objectives, and functions.

Enterprise Business Architecture Framework

Overview

The Enterprise Business Architecture Framework (EBAF) presents an end-to-end methodology that strategically aligns an organisation’s goals with its operational activities. Serving as an architectural blueprint, it guides leaders in shaping the processes, systems, and data flows central to the enterprise’s functioning. By integrating various components of business—ranging from customer interactions to technological infrastructure—EBAF aims to create an environment that is both streamlined and agile, fostering a business structure that is efficient and swiftly responsive to evolving demands.

At its core, the purpose of EBAF is to provide a structured yet flexible means for articulating and implementing a business’s architecture that resonates with its strategic imperatives. This involves offering clear guidance for continuous improvement of operational processes, aligning every business move with strategic goals. Beyond merely enhancing operational effectiveness, the framework serves as a catalyst to reduce process redundancies and drive enterprise-wide efficiency, ensuring that all actions taken are deliberate and goal-oriented.

Incorporating a strong emphasis on security, EBAF also propels organisations to proactively address potential risks and integrate robust security measures into their business architecture. This security-minded approach is essential in safeguarding critical information and systems, ensuring resilience against threats, and maintaining trust with stakeholders. To reinforce business resilience and foster innovation, EBAF pursuits with compliance and governance, permitting the safe exploration of new technologies and practices within a secure architectural landscape. Effectively, EBAF not only ensures that organisations meet regulatory requirements but also establish a secure foundation for growth and transformation.

The Business Ecosystem

The business ecosystem of an entity describes its environment in terms of its functions and activities in relation to and with the participation of other entities and national bodies. The business ecosystem of an entity can also be described in terms of the use of IT in the provisioning and consumption of business services, the underlying business processes and information flows between the entity and its users, customers, partners, service providers and national bodies.

Business ecosystem of regulated and critical sector entities in Indian context is pictorially shown here.

Enterprise Technology Architecture Framework

The federated digital ecosystem of a CSE is manifested through an information infrastructure that runs the business, industrial and operational processes. Most of the currently available technical literature and knowledge focuses on differentiating the characteristics and technical architectures of IT, OT, IIoT and Information Security systems and networks. In contrast, this documentation attempts to synergise and harmonise the differentiated concepts and frameworks into a common representation that can help in better communication amongst the business, non-technical and technical stakeholders, both within and outside the organisations.

The enterprise technology architecture framework outlined in this section offers a unified reference for top and senior management of organisations and national nodal bodies. It is designed to facilitate informed decision-making on leveraging technology to achieve desired business results, establish best practices, and provide comprehensive guidance on functional, performance, operational, managerial, and security considerations. It may be noted that the word “technology” here refers specifically to IT, OT, and Information Security related technology, as well as IIoT technology used for physical access control and monitoring (e.g., smart cards, biometrics, CCTVs etc).

Concepts

Requirements for use of Technology

The enterprise technology architecture framework of organisations should address the following requirements so that IT and OT are used efficiently, effectively, safely and securely:

• Functional: Deliver the business and industrial objectives through functions, processes, operations, and services.

• Quality: Deliver the required quality of systems and software.

• Performance: Deliver required performance of the functions and processes.

• Trustworthiness: Assurance that the functionality is implemented and configured correctly and is operating as intended.

• Cybersecurity: There are no weaknesses and vulnerabilities in hardware/ firmware/ software that could be exploited by malicious actors to cause harm.

• Confidentiality: The information and data are handled as per its security classification.

• Integrity: The data and processes are trustable.

• Availability: The functions and performance are available to the users at required levels of availability. 

• Safety: Specific to OT and IIoT, the assurance that the operational processes are safe for humans and the environment.

• Privacy: Privacy of individuals and organisations is maintained, with regard to sensitive and private information.

• Supply chain: Assurance that the entire supply chain is secure and not exploitable for causing harm.

• Management: People, process, and technology governance, which oversees and assures that the above parameters are consistently achieved throughout the life cycle.

• Ecosystem: The organisation’s digital infrastructure does not cause harm to other organisations that are part of the federated digital ecosystem.

Architectural Principles

The IT, OT and IS infrastructure implementation is based upon a common set of engineering and architectural principles, namely:

• Segmentation: Zoning of assets, network, and resources (security by design, security in implementation).

• Multi-layered security: Implementing a layered security cover to achieve defence in depth.

• Reliability: Ability to assure a required level of functionality and performance in normal circumstances.

• Robustness: Ability to deliver a minimum level of functionality and performance in the face of adversity.

• Resilience: Ability to prevent the degradation of functions, performance, and trustworthiness; ability to minimise the impact of degradation (if it occurs) and ability to quickly recover from a degraded condition to the normal condition.

Patterns of a CSE’s Information Infrastructure

Almost all CSEs implement their information (IT, OT and IS) infrastructure through separate projects. Typical elements of an CSE’s information infrastructure, its operation, management, and use are described below:

• A common information infrastructure across the entity, whose elements include hardware and software (end-user devices, mail, web, and portal servers), network and security systems, and information services (email, portal, common user applications, databases etc). The in-store and in-use assets are usually managed through ERP/ ITAM/ ITOM/ CMDB platforms.

• The common information infrastructure is managed through pan-organisation IT Operations/ Service management (ITOM/ ITSM) and Information Security management systems (ISMS).

• The platforms have their own IT infrastructure, viz, devices and runtime platforms to carry out IT and IS management functions related to asset configurations, availability and performance, patches and upgrades, compliance to hardening baselines, identity and access, authentication and authorisation, systems and network management, security management, logs and audit trails (evidence management), vulnerability and compliance management, security incident and event management (SIEM), incident response management, (IR, EDR/ XDR, SOAR), analytics etc. 

• Devices, systems, platforms, networks, security, applications, and databases of critical processes are usually segregated into secure logical or physical (air-gapped) high-trust zones.

• Air-gapped high-trust zones would typically have their own management systems, while non-air-gapped high-trust zones may be managed through the pan-organisation management systems.

• Integration of the security related components of physical infrastructure, viz physical access control (biometrics and smart cards), physical surveillance (CCTV networks) and management of critical non-IT asset dependencies (BIMS, UPS, Generators etc) of data centres.

• Workforce required to operate, manage, and secure the information infrastructure.

• Users, both humans and machines, who access the information infrastructure for i) consuming services, ii) carrying out system administration and management, or iii) providing service, such as technical support or customer service.

A generic deployment is pictorially represented below. It depicts the computer resources and management/ operational platforms of an entity’s IT/ OT/ IIoT infrastructure. The terms ‘non-critical’ and ‘critical’ are only indicative of how entities classify their processes and thereby, the underlying IT/ OT/ IIoT infrastructure of the processes.

The “levels” in the diagram represent the functional aspect of the infrastructure components, as tabulated below.

Terms and Definitions

The following terms and definitions are used in this document to describe an entity’s enterprise-wide information infrastructure in a generalised manner.

• Resources: These are the physical and logical assets that are in-use by an entity or user for computing, storage, networking and other IT, OT and IS functions. It corresponds to the term “Computer Resource” in the IT Act 2000 (revised 2008).

• Data Centre premises: a generic term to describe a geographical site, which hosts the computing, storage, internal networking, and other resources that an entity uses to deliver business services and carry out its business functions and operations. Server rooms are equivalent to micro data centres.

• User premises: a generic term to describe a geographical site, which hosts the computing, storage, internal networking, and other resources that are used by users (human and machine) to connect to the data centres to access services. Users may be consumers of service, systems administrators, or providers of service. The providers of service include technical support and customer service teams etc.

• Data Centre constituents: a generic term to describe the different constituents of a typical data centre, such as the property on which the data centre is built, the data centre facility, non-IT and IT constituents within the data centre and connectivity from/to the data centre. Typically, each of the constituents are evaluated when strategic decisions are taken regarding the data centres.

• Network Infrastructure Resources: the in-use network infrastructure resources can be described on the basis of the following characteristics:

  • Communication media: copper, optical fibre (OFC), power line carrier communication (PLCC), Optical Power Ground Wire (OPGW) on power transmission lines, HF/ VHF/ UHF, microwave, and satellite links.

  - WAN communication protocols: PDH, SONET/ SDH, Metro Ethernet, xDSL, AON/PON, MPLS, IP, power sector communication protocols like IEC 60870 and 61850 series/ DNP/ Modbus/ RTU, OSGP, Low Power Wide Area (LPWA), GPRS, 4G, 5G.

  • Network topologies: point to point, point to multipoint star, mesh, or bus topology.

  • Network device functions: transmission, switching, routing, element and network management, network security etc.

• Network Provider infrastructure: a generic term to describe one or many geographical sites, which hosts the network infrastructure resources that lies outside of the data centre and user premises. The network infrastructure is owned by a network provider entity (TSP, ISP). The data centre and user premises use customer premises equipment (CPEs) to connect to the network provider infrastructure. The CPEs themselves may be customer-owned or provider-owned.

• Zone: a generic term zone is defined as a grouping of logical or physical assets that share common security requirements based on factors such as criticality and consequence. This definition has been generalised in this document to describe groups of in-use IT, OT and IS resources within data centre or user premises, the physical or logical grouping being done as per functional, operational, management or security requirements.

• Perimeter: a physical or logical boundary wall between two zones, which also has access controls (gates) for ingress into and egress out of the zones. Physical access control is relevant for premises, while logical access controls are relevant for systems and networks.  

• Conduit: a generic term conduit is defined as grouping of assets dedicated exclusively to communications and which share the same security requirements. In this document it describes the communication channels connecting the zones and also the tunnels through the perimeter that separates two zones. Examples of the latter are VPN tunnels and data diode.

Ontology of Tags for Enterprise Information Infrastructure

Governing bodies, top and senior management and the technical heads in entities are provided with a common vocabulary to represent the use of IT within the entity. The ontology for tagging an enterprise’s information infrastructure has three tag-groups, viz resource categorisation tag group, hierarchical level tag group and trust level tag group.

The ontology is technologically agnostic so that it can understood by both business and technical persons. The tags are meant to be used in architecture diagrams and presentations of business and technical management to describe the use of IT, both for their internal decision processes and for communication with external entities. The tagging enables non-technical personnel to assimilate the context and participate in decision-making.

Resource Categorisation Tags

The resource categorisation tags help the stakeholders to represent the ownership and control that an entity has over its information infrastructure elements. The following tags are in this group:

1. Resource zones - central (S) or end-user (U).
2. In-use resources purpose and use – functional (FS, FU) or governance/ management/ administration (GS, GU).
3. Connectivity zones (V).
4. Data centre ownership (SA, SB, SC, SD).
5. Connectivity ownership (VA, VB, VC, VD).
6. Connectivity purpose and use (XA, XB, XC, XD).
7. End user resource ownership (UA, UB, UC, UD).
8. End user role (NU, OU).
9. Control over human workforce (WA, WB, WC, WD).
10. Services (DC, IS, OS, TS, SS, FM).
11. Service ownership (JA, JB, JC, JD).
12. Data centre segmentation (ML1 to ML4).
13. Cloud services segmentation (YL0 to YL4)

Sample Use Case for Resource Categorization Tags

Scenario:

A CSE wants to implement a new Enterprise Architecture Framework (EAF) to streamline its IT infrastructure, operations, and governance.

Challenge:

The organisation’s resources are diverse and distributed across various departments, zones, and functions. The complexity of managing these resources often leads to inefficiencies, lack of clarity in ownership, and difficulty in governance. There is an immediate need for a system that can simplify the categorisation and understanding of these resources for all relevant stakeholders, while also supporting the implementation of the new EAF.

Solution:

To address this challenge, the organisation decides to employ a set of resource categorization tags within their EAF. These tags act as labels that allow for easy identification and categorisation of resources, helping stakeholders to better understand the purpose, ownership, governance and threat modelling of each resource within the enterprise infrastructure.

Implementation:

• Resource Zones Tags: Tags like ‘Central (S)’ for shared resources and ‘End-User (U)’ for individual user-specific resources simplify the location and accessibility of resource classification for stakeholders.

• Purpose and Use Tags: Tags such as ‘functional (FS, FU)’ for operational resources and ‘governance/management/administration (GS, GU)’ for resources related to the oversight and control efficiently distinguish between the functional aspects of resources and their governance.

• Connectivity and Ownership Tags: Tags like ‘Connectivity zones (V)’ and ‘Data centre ownership (SA, SB, SC, SD)’ offer clarity on the connective infrastructure and its proprietors, expediting responsibility allocation and incident resolution. Similarly, ‘Connectivity ownership (VA, VB, VC, VD)’ and ‘End user resource ownership (UA, UB, UC, UD)’ tags provide precise ownership details.

• Purpose Specific Tags: With the inclusion of ‘Connectivity purpose and use (XA, XB, XC, XD)’ and ‘End user role (NU, OU)’ tags, the utility function and user role associated with the resources are effortlessly communicated, ensuring right access and use.

• Workforce and Services Tags: Tags regarding ‘Control over human workforce (WA, WB, WC, WD)’ denote the degree of control and structure within the workforce, while ‘Services (DC, IS, OS, TS, SS, FM)’ and ‘Service ownership (JA, JB, JC, JD)’ deliver insights regarding the service allocation and control, amplifying the operational management.

• Segmentation Tags: Finally, tags related to ‘Data centre segmentation (ML1 to ML4)’ and ‘Cloud services segmentation (YL0 to YL4)’ offer clear distinctions within data management and cloud service levels, promoting effective and secured data governance.

Benefits:

• Clarity and Control: The tags provide clear direction on resource governance, enabling stakeholders to make informed decisions regarding the resources they oversee.

• Streamlined Infrastructure Management: The use of tags streamlines the complexity associated with managing an extensive array of resources.

• Effective Governance: With tags categorising resources based on their purpose and governance, it becomes easier to enforce policies and maintain compliance.

• Enhanced Stakeholder Communication: Tags serve as a common language simplifying communication between technical and non-technical stakeholders regarding resource management.

• Agile Resource Allocation: Tags enable agile and accurate resource allocation, matching resources to needs more effectively.

An illustrative use of resource categorisation tags is given below.

Hierarchical Level Tags

The hierarchical level tags are designed to have a common classification of the information infrastructure into well-defined hierarchical zones. Appropriate trust levels can be assigned to the zones. This will help the project design and engineering teams, procurement, and provisioning teams, IT and information security operations management teams and the service providers in better risk analysis and allocation of various resources. The following tags are in this group:

1. Central resource hierarchy of zones (HL0 to HL5).
2. Perimeter zones between hierarchical zones (PHL1 to PHL4.5).
3. Perimeter zones in data centre segments (PM1 to PM4).
4. Perimeter zones in cloud environment (PYL0 to PYL4).

Sample Use Case for Hierarchical Level Tags

Scenario:

An organisation is in the process of adopting a new Enterprise Architecture Framework (EAF) to bolster its IT and OT infrastructure’s efficiency, security, and governance. A key challenge they face in this deployment is managing the complexity and diversity of their information infrastructure, which includes various hierarchical zones, data centre segments, and cloud environments.

Challenge:

Project design and engineering teams, alongside procurement, provisioning, IT and OT operations management, and service providers, struggle with conducting effective risk analysis and resource allocation due to the intricate nature of the infrastructure layout and the varying levels of trust associated with each zone. The IT and OT teams must also be able to converge onto a common representation of their respective hierarchies.

Solution:

In addressing these challenges, the organisation opts to implement hierarchical level tags within their EAF. These tags help to classify the information infrastructure into hierarchical zones with assigned trust levels. This tagging enables the stakeholders to clearly segment the IT and OT resources, aiding in threat modelling, risk analysis and the strategic allocation of resources across zones.

Implementation:

• Central Resource Hierarchy Tags: Tags ranging from ‘Central resource hierarchy of zones (HL0 to HL5)’ clearly delineate the core infrastructure zones, establishing a graded structure of trust and access controls that escalate with each hierarchy level.

• Perimeter Zone Tags: ‘Perimeter zones between hierarchical zones (PHL1 to PHL4.5)’ tags facilitate a distinct border identification between hierarchical zones, serving as checkpoints for security assessments and transitions in trust levels.

• Data Centre and Cloud Perimeter Tags: Tags like ‘perimeter zones in data centre segments (PM1 to PM4)’ and ‘perimeter zones in cloud environment (PYL0 to PYL4)’ categorize resources within data centres and cloud segments. These tags help stakeholder teams evaluate and address specific security concerns more accurately within these venues based on the designated trust levels.

Benefits:

• Improved Risk Management: Hierarchical tags aid in identifying and managing potential risks associated with the varying zones, thus enhancing the overall security posture.

• Streamlined Resource Deployment: The tags create an organized structure that simplifies the understanding of where resources reside and their respective trust levels.

• Informed Decision-Making: Teams gain insights into infrastructure vulnerabilities and strengths, enabling them to make more strategic decisions about resource deployment and protection.

• Effective Collaboration: A common classification system assists diverse teams in synchronizing their efforts, thus facilitating collaboration, and reducing inconsistencies.

• Enhanced Security Profiles: Each resource carries a clear security profile through tagging, accommodating tailored security measures.

An illustrative use of resource categorisation tags is given below.

Trust Level Tags

The trust level tags represent the level of trust that can be assigned to a zone. This will help the project design and engineering teams, IT and information security operations management teams and the service providers to design, implement, operate and manage zoning, segmentation and zero trust architecture. The following tags are in this group:

‒         Trust level (TL0 to TL5)

Sampe Use Case for Trust Level Tags

Overview:

An organization plans to implement zero trust in its enterprise IT. Stakeholders include IT architects, security officers, network administrators, and management teams who must understand and enforce the security policies, zoning and segmentation within the organization’s operations effectively.

Challenge:

Varied levels of data sensitivity and diverse IT systems across the enterprise create a complex security landscape that requires a clear and uniform approach to managing trust and control levels. Stakeholders require a reliable method for identifying, at a glance, the security trust levels and enforcement strength for each zone to correctly implement and adhere to security policies, controls, and compliance requirements.

Solution:

Trust level tags serve as a simple and effective way to categorise and label the components of the organisation’s resource and connectivity zones based on defined security policies and the level of control the entity has or requires. These tags help stakeholders instantly recognise the importance and sensitivity of each zone, ultimately guiding their risk management and policy enforcement actions.

Implementation:

• Defining Trust Levels: Categorise and define security trust levels ranging from TL0 to TL5. Establish criteria for each level based on the level of control the entity has/ can have over the zone

• Evaluating and Tagging Resource Zones: Assess each resource zone within the organisation and determine the appropriate trust level. Apply the respective trust level tag to systems, databases, and networks accordingly.

• Evaluating and Tagging Connectivity Zones: Analyse network segments and connectivity frameworks for security enforcement capability and requirements. Assign trust level tags that match their security policy framework.

• Incorporating into EAF documentation: Update all related architecture diagrams, policies, and procedural documents with the applied trust level tags to create a standard reference across the organisation, ensuring coherence and mutual understanding among all stakeholders responsible for zero trust.

Benefits:

• Enhanced Risk Management: Trust levels guide stakeholders toward adequately securing each zone according to its criticality and the organization’s risk tolerance.

• Clear Communication: The standardized tagging system reduces complexity and eases the communication of security and compliance statuses across departments and teams.

• Streamlined Policy Enforcement: Clearly identified trust levels support consistent application of security measures and rapid adjustment to evolving threats.

• Efficient Compliance Monitoring: Tags make it easier to monitor adherence to internal and external compliance standards, enabling swift corrective measures as needed.

• Optimized Security Investments: By identifying zones with higher trust levels, the organization can prioritize security investments and focus resources where they are most impactful.

An illustrative use of trust level tags in a business ecosystem diagram is given below. The trust level tags can be similarly used in a federated digital ecosystem diagram.

Ontology of Tags

Business and technical stakeholders, both within and outside the CSEs, need a common vocabulary to describe different perspectives of IT and cybersecurity within the national cyberspace. This section defines an ontology of tags that categorises various characterstiscs of a federated digital ecosystem. The tags will enable a common specification, representation and communication of the use of IT and cybersecurity amongst the governing bodies, top and senior management and technical teams, both within entities and the external organisations interacting with the entities.

Three tag-groups are defined, as under:

A. Resource categorisation

B. Hierarchical level

C. Trust level

The ontology is designed in a technology-agnostic manner so that it can understood by both business and technical persons. The tags are meant to be used in architecture diagrams and presentations to give the business and technical management a common mechanism to specify the characteristics of IT and cybersecurity elements in the federated digital ecosystem. They are also to be used in discussions with external organiations. The objective is to facilitate common understanding of situations and enable appropriate decision-making.

A. Resource Categorisation Tags

The resource categorisation tags are designed for use by the technology level practitioners to establish a common understanding with the goveranance and business levels about the type and level of control they have over their information infrastructure elements. The list of tags in this group are as under:

• Resource zones - central (S) or end-user (U).
• In-use resources purpose and use – functional (FS, FU) or governance/ management/ administration (GS, GU).
• Connectivity zones (V).
• Data centre ownership (SA, SB, SC, SD).
• Connectivity ownership (VA, VB, VC, VD).
• Connectivity purpose and use (XA, XB, XC, XD).
• End user resource ownership (UA, UB, UC, UD).
• End user role (NU, OU).
• Control over human workforce (WA, WB, WC, WD).
• Services (DC, IS, OS, TS, SS, FM).
• Service ownership (JA, JB, JC, JD).
• Data centre segmentation (ML1 to ML4).
• Cloud services segmentation (YL0 to YL4)

Resource Zones

The resource zones are of two types:

Central Resource Zones (S Zones): These zones host the in-use operating resources (servers, applications, databases) of different business processes and management systems, as well as the local networking and security infrastructure. The central zones are located physically within the data centres or the local server rooms in regional/ branch offices. These zones are tagged as System or ‘S’ zones.

End User Resource Zones (U Zones): These zones host the in-use operating resources (computing devices, applications, data repositories) of end users and their local networking and security infrastructure. The users may be human or machine and are typically identified by their credentials (user and machine ids) that are linked to centrally managed user and system accounts. The user zones are generally located physically within the office premises of organisations or work/ home premises of remote users. These zones are tagged as User or ‘U’ zones.

In-Use Resources

Computer resources (assets) of entities may lie in the store or be deployed for use. The resources deployed and in-use in central and end-user zones can be categorised as under, based on their purpose and use. The tags are derived from the primary tag ‘S’ or ‘U’:

Notes:

1. Typically, the resources used for operational and management functions are physically and logically segmented into separate sub-zones within the hierarchical levels described in later sections.

2. The in-use computer resources (assets) of an organisation can be categorised and tagged based on their functions and capabilities, as well as by the zones in which they are deployed. The tags can be used to apply detailed guidance on the information security imperatives and requirements of each in-use resource based on its function and the zone in which it is deployed.

Types of Functional Resources (FS, FU Tag)

The detailed categorisation of computer resources based on the functions and capabilities is described in a separate section. The in-use computer resources can usually be tagged as under.

End User Resources:

• User and machine credentials stored in smart cards, USB tokens or 2FA through mobile devices.
• Endpoint computing devices (desktop, laptop, tablet, mobile)
• Audio and video conferencing devices
• Wired and wireless network access devices, Bluetooth, Zigbee, WLAN
• SSL VPN termination, VPN clients
• Applications and data repositories
• Endpoint agents installed on compute devices.

Cloud Services and Resources:

• Subscription Services: Cloud Access Security Broker (CASB), As-a-Service Applications (email, portal, eOffice etc), CTI Feeds.

Perimeter Devices:

• Perimeter zones will have connectivity devices that provide physical and logical conduit between the two zones and physical (human) and logical (network) ingress/ egress control devices (gateway), data diode.
• Firewall, IDS, IPS, UTM, NAC appliance, Router, switch, VPN gateway, SSL terminator, communication network termination device, OT: GPRS modem, FO modem, smartcard/ biometric readers, network taps, IPSEC/ SSL VPN termination points.

Data Centre Resources:

• Web Proxy, Email Proxy, API gateway, Load Balancer, Data Leakage Protection, Content Disarm & Reconstruct (CDR), Switch
• Enterprise Zone Data Centre (segmented into multiple trust zones (VLANs), based on functional and security design): server cluster, server farm, VMs and containers, storage, consoles, SW stack, business systems (ERP)
• Datacentre network (DCN), compute, VMs and containers.

Zones specific to OT and IIoT:

• OT supervisory L2: Industrial PCs, SCADA, DCS, HMI, FEP, Historian, Engineering Workstation, switch
• OT basic control L1: PLC, RTU, IED, BCU
• IIoT edge devices L1: surveillance cameras, biometric and smart card readers
• OT L0: relay, sensor, actuator, generic OT process devices

Types of Governance and Management Resources (GS Tag)

These resources can be broadly categorised as:

• Platforms that discover, provision, configure, monitor, manage functionality, performance, and security, visualise, control, analyse, govern, and report the trustworthiness (functionality and assurance) of operational systems (computer resources).
• Cloud Services Management (Infrastructure, Platforms, Software, Security, Backup, BCP, DR services), Domain management, SMIME/ SSL certificate management, email, and web services.
• Subscription feeds: OEM Patches and Feeds, OEM telemetry collectors, AV/ EPP management, Domain manager, Certificate Authority, OAuth IdPs.
• Datacentre network (DCN) management: physical access control, CCTV monitoring, BIMS, UPS & Generators DNS, DHCP, RADIUS, network access control (NAC) management.
• Management platforms and tools: IT/OT asset management (ITAM), asset configuration management (CMDB), asset discovery, IdAM (AD) & privileged identity and access management, LDAP, credential management, API secrets management, certificate management, NMS/EMS, patch management, vulnerability & compliance management, database activity monitoring (DAM), key lifecycle management (KLM), policy management, SSH management, log & flow collectors, SIEM, EDR, NDR, XDR, SOAR, endpoint/ AV protection (EPP), forensic tools, ITSM, ISMS, BCMS, data backup.
• Log collection from all in-use computer resources and flow collection from all networks.

Connectivity Zones

These zones host the Wide Area Network (WAN) network provider infrastructure that provide the conduits for voice, video, and data connectivity between the resource zones. The connectivity zones are usually owned and managed by TSPs and ISPs and are accessed by means of customer premises equipment (CPE) that are installed in the resource zones connecting to the WAN. These zones are tagged as ‘V’ zones, say Connectivity Zone.

The connectivity (V) zone of an entity is, in effect, a resource (S) zone of the TSP and ISP.

Data Centre Ownership

All data centres and server rooms hosting the central resources are categorised as under, based on their ownership. The tags are derived from the primary tag ‘S’:

Notes:

The above categorisation helps the governing bodies and top management of entities to evaluate the governance, risk and compliance aspects of data centre and cloud service providers, while providing strategic direction to the use of IT. For example, the risk of non-compliance of data localisation requirement is higher in the case of Type SD as compared to Type SC.

Tag SA entity owned private cloud is exclusive to the organisation, which may be hosted on-premises or in a site hired from a property owner. This corresponds to the pattern where an organisation provides its own captive cloud services.

Tag SB GOE owned cloud is typically mandated for almost all the critical business functions of CSEs. Many common services like email, portals, eOffice and other IaaS/ PaaS/ SaaS/ DRaaS are provided as cloud services to the Govt Community.

Tag SC private cloud service providers with India-only data centres are easily able to comply with data localisation requirements that can be verified using lower levels of audit effort. Such CSP data centres are preferable when data localisation requirement as well as control over data storage outside of India is of high priority.

Tag SD private cloud service providers with multi-country data centres include the i) the likes of global CSPs like AWS, Azure, GCP, IBM, Oracle, SAP; ii) OEM service management related to OEM patches, vulnerability feeds and sending system telemetry back to the OEMs, specifically relevant to OT OEM support services that are provided from OEM support cloud installations.; iii) third-party managed services (MSPs and MSSPs) covering both Indian and non-Indian ownership and control; iv) content delivery network (CDN) providers; v) domain name providers, digital certificate issuers, PKI management providers like DigiCert, DNS and other security service providers like Cloudflare etc.

The key advantages of tag SD CSPs are that they can provide very high levels of infrastructure scaling, availability, and business continuity. A large pool of trained and experienced professionals is also available for such CSPs, and these professionals can be easily hired to manage and secure the zones implemented in these CSP data centres. These CSPs can comply with data residency within the Indian geography but cannot easily prove compliance that data is not also residing outside of India. Significant audit effort is required to verify the same. Hence, such CSP data centres are relevant when an organisation requires very high and dynamic scalability or has to provide its services beyond the national boundaries or when there are no major concerns related to copies of data being stored outside of India.

Connectivity Ownership

These zones host the Wide Area Network (WAN) network provider infrastructure that provide the conduits for voice, video, and data connectivity between the resource zones. These zones are tagged as ‘V’ zones.

The connectivity providers are categorised as under, based on their ownership. The tags are derived from the primary tag ‘V’:

Notes:

The above categorisation helps the governing bodies and top management of entities to evaluate the governance, risk, and compliance aspects of connectivity providers (TSPs/ ISPs), while providing strategic direction to the use of IT. For example, the national security risk due to misuse of the monitored traffic patterns is higher in the case of Type VD as compared to Types VA, VB, or VC.

Connectivity Use

The connectivity can be categorised as under, based on the purpose and use. The tags are derived from the primary tag ‘X’, to identify the network topography:

Tag XA is typically used for high security closed user groups, which use captive networks or encryption devices on less secure networks. Entities also use VPN to create closed user groups for privileged users, who typically have to connect to the data centres to provide remote support.

Tag XB is typically used for intranet connectivity of regional and branch offices through MPLS Cloud, Leased Lines or Site-to-Site VPNs. This also includes remote OT cells/ areas within an OT Site that typically connect to the OT site operations/ DMZ on wired LAN.

Tag XC is typically used for extranet connectivity through MPLS Cloud, Leased Lines or Site-to-Site VPNs. Examples are RBI Infinet, NIC NKN, Power sector grid operation networks between substations and control centres etc.

Tag XD is typically used for internet connectivity through wired/ wireless broadband and mobile networks provided by the Internet Service Providers (ISPs).

End User Resource Ownership

The end user resource ownerships are categorised as under, based on the organisation to which the human user or machine belongs. The tags are derived from the primary tag ‘U’:

Notes:

The above categorisation helps

• the design and implementation teams and the operations managers to establish and ensure appropriate controls in different end user zones.
• the top and senior management to monitor the risks.
• the audit teams to check policy non-compliances.

Entities have a high level of control over tag UA resources, whether they are used for connecting through the Internet or Intranet. The organisation can enforce that the end-user devices must have adequate endpoint protection (AV, anti-malware etc) and comply with organisational policies (patches/ updates, upgrades, password policy enforcement, authorised applications, VPN usage etc). These controls can even be enforced and centrally managed on the Bring Your Own Device (BYOD) of remote workers.

Entities have a lower level of control over tag UB, UC resources that belong to other Organizations. In most cases, the user’s organisation is responsible for configuring, securing, and managing the end user resources. Other organisation’s users (humans and machines) typically connect to one’s own organisation’s information infrastructure through the Extranet. Other organisation users may also connect using IPSEC or SSL VPNs over the Internet. One’s own organisation must depend upon the other organisation’s policies and processes of control over the end-user devices in terms of their endpoint protection and compliance to policies. Formal and established relationships between entities help to increase the trust in the human users and machines of the other entities.

Entities do not have any control over tag UD resources, the end-user devices of public users, who connect to organisation’s information infrastructure through the Internet, typically using browser or mobile applications. Machine to machine connections from public users/ Organizations to an organisation’s systems are generally API-based.

End User Role

The end user resources are categorised as under, based on the role of the human user or machine. The tags are derived from the primary tag ‘U’:

Notes:

End user zones with privileged users (OU) are a higher risk to the entity than those with normal users (NU) only. Such zones therefore need to be governed and managed with greater focus and may call for increased surveillance and compliance.

Privileged Users (OU) can be grouped as

• technical persons and machines (administrators, OEM remote support etc).
• business and special users accessing sensitive information (e.g., regulatory & statutory auditors).

Human Workforce Control

The human workforce for operating and managing the central resources and connectivity of entities are categorised as under, based on the entity’s level of control on the technical, administrative, physical and IT access control aspects of the workforce. The tags are derived from the primary tag ‘W’:

Notes:

The technical functions related to the workforce covers aspects of skill assessment and verification during workforce hiring, tasking of individuals, leave management and management of replacements during leave or exit. This is done by the organisation themselves for resource categories WA and WB or by the service provider for resource categories WC and WD. Some Organizations also invest into the technical skill development of their WB resources (contractual employees).

The administrative functions related to the workforce covers aspects of skill verification and documentation during workforce onboarding, contract management, compliance to laws and regulation. This is done by the organisation itself for its own employees under resource category WA or by the resource/ service provider for resource categories WB, WC, and WD. Some Organizations manage the compensation payments and payment of GST for resource categories WB by themselves, while others let the workforce resource provider do the same.

The physical and IT access control of the workforce covers aspects of physical entry into the organisation’s premises and places of work within the organisation. It also covers access to IT and OT resources, both on-premises and remotely through the network. All Organizations control the physical access of people resources under resource categories WA, WB, and WC. The Organizations also control the IT access of people resources under resource categories WA, WB, and WC when they are on the organisation’s premises. In case of remote working of WC and WD category workforce, the service providers decide which person is assigned to remotely manage their customer organisation’s IT / OT infrastructure and further controls the IT access of the assigned resource as per the SLAs signed with the customer organisation.

The above workforce control categorisation helps the governing bodies and top management of entities to evaluate and provide strategic direction on the governance, risk, and compliance aspects of i) the workforce employed to operate and manage their central resources in data centres, and ii) the workforce employed by their outsourced and managed service providers (WC and WD).

For example, the risk of data leakage is higher from those providers of outsourced and managed services (WC, WD), who do not have good due diligence processes to hire, train and monitor their own and contractual employees, or they are further outsourcing the work to second tier service providers. Due diligence is especially important for workforce having privileged user (OU) rights.

A strategic assessment of the level of control available to an entity with regard to the outsourced workforce (WC and WD) operating and managing its resource and connectivity zones would help the entity identify the SLAs that should be in place with the outsourced and managed service providers. The SLAs should especially cover the control, monitoring, and oversight on the privileged users (OU) of the service providers since these highly skilled users generally work remotely.

Service Ownership

The modern federated digital ecosystem is largely driven by services. In general, a Service Provider Entity (SPE) delivers a service to a Customer Entity (CE), who acquires the service. The relationship between the SPE and the CE may be formal, semi-formal or informal, depending upon the type of service agreements that exist between them.

The services related to IT, OT and Information Security infrastructure are categorised as under:

• Data Centre Services (DC): These are typically provided by Cloud Service Provider Entities (CSP).
• Telecom and Internet Services (IS): These services include voice, video and data communication services that are provided by telecom and internet service provider entities (TSP, ISP).
• Operation Support Services (OS): These services include NOC, SOC, call centres, customer service centres etc.
• Technology Support services (TS): These services include L1 to L3 support services and managed services that are usually provided by second- or third-party entities such as OEMs and/or their partners, SIs, MSPs, MSSPs etc. These services are usually contracted with formal service level agreements between the customer (CE) and the service provider entity (SPE).
• Subscription services (SS): These services include all types of subscriptions and are typically in the form of cyber threat intelligence (CTI) feeds, vulnerability, and compliance (SCAP) feeds, open-source intelligence (OSINT) feeds, remote health monitoring service etc. These services may either be i) contracted by the CE with formal service level agreements with the SPE, or ii) non-contracted best effort services that have no formal SLAs between the CE and the SPE. The SPEs themselves may be source (feed) owners or feed aggregators.
• Non**-IT Facility Management Services** (FM): These services include power supply, site, and facility management (physical security, non-IT infrastructure) services etc.

In the modern federated digital ecosystem, the SPE and the CE may be different entities by themselves or may be different business units within large Organizations and the Government (e.g. NIC and SDCs are SPEs to govt departments (CEs)).

The SPEs are categorised as under, based on their ownership and location. The tags are derived from the primary tag ‘J’:

Notes:

Tag JA SPE corresponds to the pattern where an entity has its own captive services.

Tag JB SPEs usually provide DC, IS, OS, TS, SS and FM services by government owned entities to CSEs.

Tag JC SPEs deliver their services from India based facilities.

Tag JD SPEs deliver their services from outside India facilities.

The above categorisation helps the governing bodies and top management of entities to evaluate the governance, risk, and compliance aspects of service provider entities, while providing strategic direction to the use of IT, OT, and Information security services. For example, the risk of disruption of service caused by changes in the local country regulations is higher in the case of type JD as compared to type JC, while it is very low for types of JA and JB.

Many Govt owned SPEs (tag JB) such as CERT-In, NCIIPC, CSIRTS etc provide Cyber Threat Intel feeds that are aggregated and enhanced by them.

Segmentation of Data Centres

It is evident that data centres and server rooms of entities are the most critical elements of an entity’s use of IT for achieving business objectives.

Data centre premises and contents can be segmented, based on the legal ownership of the i) physical property that hosts the data centre, usually managed by the property manager (FM-SPE), ii) the data centre facility or site itself, including the IT and non-IT infrastructure installed in the facility and owned by the Data Centre Service Provider Entity (DC-SPE), iii) supporting infrastructure of the facility (power, telecom, physical security) provided by the Facility Management Service Provider Entity (FM-SPE), and iv) platforms and services provided by the DC-SPE to the customers and users (CE). The segmentation levels are defined in the table below. The levels are prefixed with the tag ‘ML’.

In almost all cases, the legal owners are responsible for the operations, management, security, legal and regulatory compliance functions of their segments. They are also responsible for the workforce handling these functions. For example,

ML1 is owned, operated, managed, and secured by the Property Manager (FM-SPE), who is responsible for ingress/ egress control into the property, campus security and safety. The workforce handling these functions are contract workforce (WB) or outsourced services (WC).

ML2 is owned by the DC-SPE and managed by the DC Site Manager, who is responsible for DC operations and management. The workforce handling these functions are a mix of the DC-SPE’s own employees (WA), contract workforce (WB) or outsourced services (WC).

ML3 is owned by the FM-SPE, who are responsible for operations and management of their services. The workforce handling these functions are a mix of the FM-SPE’s own employees (WA), contract workforce (WB) or outsourced services (WC).

ML4 is owned by the Customer Entity (CE), who is responsible for the operations and management of their platforms and subscribed services. The workforce handling these functions are a mix of the CE’s own employees (WA), contract workforce (WB) or outsourced services (WC).

In the case of entity owned data centres and server rooms (SA), the entity is both the DC-SPE and the CE. In case the entity also owns the inter-data centre and customer connectivity (VA), then the entity is also the IS-SPE for its intranet connectivity facilities.

In other cases (SB, SC, SD), there is a supplier and acquirer relationship between the DC-SPE and CE regarding the provisioning and use of cloud services. Cloud service customers can also consider multiple cloud service providers together as a cloud services supply chain.

The IS/ISO/IEC 27036: Part 4:2016 provides guidance on supplier relationship between the cloud service customer (acquirer) and the cloud service provider (supplier). IS/ISO/IEC 27002 clause 15 “Supplier relationships” provides controls, implementation guidance and other information for managing information security in supplier relationships. IS/ISO/IEC 27017:2015 provides guidelines on information security controls suitable for cloud services provision and usage, that can provide guidance to the DC-SPE and the CE. The DC-SPEs also obtain certification of compliance to various standards that are applicable to cloud services, such as IS/ISO/IEC 20000-1, SOC-2 etc. These standards are described in the compendium.

As per industry practice, the resource provisioning and orchestration functions are carried out by the DC-SPE. However, the responsibility of operation, management and security of customer subscribed data centre resources is shared between the DC-SPE and CE based on the type of cloud computing model that the CE has subscribed to from the DC-SPE. These are broadly classified into IaaS, PaaS, SaaS, XaaS etc. NIST SP 800-145, SP 500-292, and SP 500-332 provide detail guidance on cloud computing models.

Segmentation of Cloud Services

The cloud computing resource types given in the table below are adapted from the industry practice in a manner that it can also be applied to entity-owned captive data centres and GOE owned data centres. The tags are derived from the primary tag ‘Y’.

B. Hierarchical Level Tags

The hierarchical level tags are designed to provide a common classification mechanism for different zones of the information infrastructure. This will help the project design and engineering teams, procurement, and provisioning teams, IT and information security operations management teams and the service providers in better risk analysis and allocation of various resources. The tags in this group are as under:

• Central resource hierarchy of zones (HL0 to HL5).
• Perimeter zones between hierarchical zones (PHL1 to PHL4.5).
• Perimeter zones in data centre segments (PM1 to PM4).
• Perimeter zones in cloud environment (PYL0 to PYL4).

Central Resource Zones

The central resource zones can be categorised into different hierarchical levels, which correspond to the hierarchy defined in the Purdue Enterprise Reference Architecture (PERA) and other models. The hierarchical levels defined in the table below. The levels are prefixed with the tag ‘HL’.

Notes:

The hierarchical level tags can be used to tag various zones in system and network diagrams to establish a common framework for analysis and discussion on the IT, OT and IS aspects.

The Industrial IoT Reference Architecture (IIRA)¹ is one of the foundational documents published by the Industry IoT Consortium (IIC) that describes the business & technology perspectives in the IIoT industry. Typically, IIoT system implementation is done in a generic three-tier architectural pattern that comprises of edge, platform, and enterprise tiers.

The tags described above can be broadly applied to the IIoT-based physical access control and monitoring setup in different entities as under:

• HL4 – enterprise tier, typically located in a separate zone within the entity’s central data centre.
• HL3 -platform tier, typically located in a separate zone within the entity’s OT site/ branch office.
• HL2 – edge tier, typically located within the entity’s area that is being secured and/ or observed.
• HL1/HL0 – edge nodes (IIoT devices like CCTV cameras, biometric and smart-card readers etc), typically located within the entity’s area that is being secured and/ or observed.
• XB - proximity network, typically the OT cell/ area/ site LAN or branch LAN
• XB, XC, XD – access network and service network, typically the intranet, extranet, internet

Perimeter Zones between Hierarchical Levels

Perimeter zones lie between two resource zones or between a resource zone and a connectivity zone. The perimeter zones host the security devices and systems (L3 and L7 firewalls, IDS, IPS), which control the network (electronic) and the physical ingress and egress through conduits between the two zones separated by the perimeter zone. These perimeter zones are tagged as ‘P’ zones.

The network perimeter zones typically host VPN gateways, jump servers, bastion servers and other systems that secure the electronic conduits established through the perimeter zones.

The physical perimeter zones typically host IT-enabled and IT-managed access control systems, such as biometric and smart-cards, for securing the physical ingress and egress of users and external devices into the operational resource zones.

Perimeter zones can be tagged based on different aspects of their deployment characteristics.

Perimeter tags defined below are in the context of separation between zones at different hierarchical levels or within the same hierarchical level. The PHLx.y tag indicates that the perimeter is of the zone at hierarchical level HLx.y, towards a zone that is of a higher level or same level.

Notes:

Remote management of in-use resources is unavoidable in case service availability and uptime is of the order of 99.9% or higher. Modern best practices for OEM remote support focus on having well-designed and secure perimeters at different HLs and privileged access management processes that i) enforce compliance by the OEM support teams to the agreed remote management terms and conditions, ii) authenticate and authorise the OEM support teams to access the zones requiring remote support, iii) closely observe and record all the remote management activities of the OEM support teams, and iv) quickly respond to any anomalous behaviour.

Perimeter Zones in Data Centre Segments

Perimeter tags defined below are in the context of the data centre segment (ML) in which it exists, physical or logical.

Perimeter Zones in Cloud Environment

Perimeter tags defined below are in the context of the cloud computing management.

Notes:

Perimeters in the cloud environment are usually configured, secured, and managed by the organisation responsible for the same.

Zone-based Tags for Resources

The in-use computer resources (assets) of an organisation can also be categorised and tagged based the zones in which they are deployed. This tagging can be used to apply the detailed guidance on the information security imperatives and requirements of each in-use resource based on the zone in which it is deployed. A sample table for tagging of computer resources based on their zones of deployment is given below.

C. Trust Level Tags

The trust level tags are designed to provide a common classification mechanism for evaluating and assigning a trust level to each zone of the information infrastructure. This will help the project design and engineering teams, cybersecurity experts, service providers, regulators and national bodies to converge on defining and ensuring a trustworthy digital ecosystem. The tags in this group are as under:

• Trust level (TL0 to TL5)

The resource and connectivity zones can be categorised into different trust levels based on

• the level of control an entity requires on a zone, or
• the level of control that an entity can assuredly implement on the resources within a zone.

The trust levels are defined in the table below. The levels are prefixed with the tag ‘TL’.

Notes:

The trust level tags can be used to tag various zones in the functional, system and network diagrams to establish a common framework for analysis and discussion on IS aspects.

Colour tagged table of trust levels may be downloaded here.

Categorisation of Zones based on Trust Levels

Each Resource and Connectivity Zone described above can be assigned a Trust Level. The characteristics of trust that is applicable to a resource or connectivity is described below along with examples of the same.

Every computer resource has to:

• be configured for functionality, performance, and assurance (controls)
• provide visibility and observability.
• be controlled.
• be governed through org policies.

The trust level is a function of the ability of an entity to execute the above requirements.

Characteristics of Trust Levels

Untrusted Zone

Characteristics:

When applied to a Resource Zone, it indicates that the organisation has no control over the users and systems in the Zone.

When applied to a Connectivity Zone, it indicates that both the organisation and the network connectivity provider have no control over enforcement of any security policies in the Zone.

Applicable to:

Public users and systems connecting through public networks. The organisation cannot enforce security policies on the users and systems. Neither the organisation nor the ISP can enforce any security policies for network traffic that passes through the public network.

Examples:

Public users anonymously accessing an organisation’s website over the Internet or mobile network.

Low Trust Zone

Characteristics:

When applied to a Resource Zone, the organisation defines a minimal set of security policies that users and systems in the Resource Zone should comply with to be permitted to operate within the Zone. Typically, no anonymous access is provided, and all users and systems must be registered with an organisation, using their username & password or allocated API secret.

When applied to a Connectivity Zone, the organisation defines a set of security policies for the network that will be applied to users and systems while connecting through the Zone to other resource zones of the organisation. Typically, this would be in the form of VPNs controlled by the organisation or a trustworthy network connectivity provider, who has well defined network security policies for the Connectivity Zone.

Applicable to:

External users and systems that can connect to an organisation’s zone after pre-registration and through session-based authentication, they are also required to use browser-based (https) or client-based VPNs, which are controlled by the organisation and governed by the organisation’s security policies.

External users and systems of other Organizations connecting through trusted extranet connectivity providers.

Examples:

Public users connecting to an organisation’s website through the Internet or mobile network using a browser or app-based SSL VPN and further logging into their user account before doing any further activity.

Applications on the devices of public users and Organizations, which connect to an organisation’s API gateways by using registered API secrets.

NICNET and NKN based extranets that provide network interconnectivity between different Organizations. The network connectivity provider defines the set of security policies that the organisational users and systems should comply with when they are connected to the network.

Remote management and support provided by OEMs, System Integrators, Managed Service Providers (MSPs & MSSPs) from their support zones, which are governed by their own security policies. In these cases, the remote support providers either connect through VPN clients installed on their devices or there would be well-managed site-to-site VPNs between the customer and support provider Organizations.

Standard Trust Zone

Characteristics:

When applied to a Resource Zone, the organisation defines a mandatory set of security policies that users and systems in the Resource Zone should comply with, to be permitted to operate within the Zone. Typically, the organisation has mechanisms to verify that the systems are compliant to the mandatory set of policies (systems are patched, have anti-virus software with latest update, username and password are as per security policy etc) before they are permitted to access other Resource Zones.

When applied to a Connectivity Zone, the organisation defines a mandatory set of security policies for the network that will be applied to users and systems while connecting through the Zone to other resource zones of the organisation. Typically, these well-defined network security policies are implemented and continuously verified for compliance either by the organisation or by a trusted network connectivity provider.

Applicable to:

Internal users and systems of the organisation connecting through the organisation’s Intranet, which may be managed by the organisation itself or by trusted network connectivity providers.

Users and systems of different Organizations connecting through trusted network, all of which are governed by a common set of security policies.

Examples:

Organisation’s Intranet for its own users and systems.

INFINET, a Closed User Group network governed and secured by RBI.

Enhanced Trust Zone

Characteristics:

When applied to a Resource Zone, the organisation defines an enhanced set of security policies that users and systems in this Resource Zone should comply with to be permitted to operate within the Zone. Typically, the users and systems are in a Closed User Group (CUG) with extended control and monitoring of their activities.

When applied to a Connectivity Zone, the organisation defines an enhanced set of security policies for the network that will be applied to users and systems while connecting through the Zone to other resource zones of the organisation. Typically, this would be in the form of highly secure VPNs and well-defined network security policies that are implemented and continuously verified for compliance either by the organisation or by a trusted network connectivity provider.

In general, the resource zones connected through an enhanced trust connectivity zone should themselves have enhanced trust.

Applicable to:

Internal users and systems of the organisation operating within Closed User Groups.

Users and systems of different Organizations connecting through trusted network, all of which are governed by a common set of enhanced security policies.

Examples:

Organisation’s privileged users like system administrators managing the IT and OT resources.

Internal LANs for high security operations, systems, and network administration.

Some Government and Defence captive networks.

High Trust Zone

Characteristics:

When applied to a Resource Zone, the organisation defines a maximal set of security policies that users and systems in this Resource Zone should comply with to be permitted to operate within the Zone. The organisation also specifies physical security and access controls for this zone and usually enforces network airgap for high security. All activities in this zone are monitored closely for any policy violation.

When applied to a Connectivity Zone, the organisation defines an enhanced set of security policies for the network that will be applied to users and systems while connecting through the Zone to other resource zones of the organisation. Typically, this would be in the form of highly secure VPNs and well-defined network security policies that are implemented and continuously verified for compliance either by the organisation or by a trusted network connectivity provider. Data diodes may be used for one-way communication from/to lower trust zones.

In general, the resource zones connected through a high trust connectivity zone should themselves have high trust and vice versa.

Applicable to:

Internal high security users and systems of the organisation operating within Closed User Groups.

High security users and systems of different Organizations connecting through high trust network, all of which are governed by a common set of enhanced security policies.

Examples:

Some Government and Defence Organizations’ high security operations.

High trust zones for ensuring the integrity and privacy of critical databases, such as Aadhaar demographic data, PKI infrastructure, HSMs etc.

Very High Trust Zone

Characteristics:

When applied to a Resource Zone, the organisation defines a maximal set of security policies that users and systems in this Resource Zone should comply with to be permitted to operate within the Zone. The organisation also specifies physical security and access controls for this zone and always enforces network airgap for high security. All activities in this zone are monitored closely for any policy violation.

When applied to a Connectivity Zone, the organisation defines a maximal set of security policies for the network that will be applied to users and systems while connecting through the Zone to other resource zones of the organisation. Typically, this would be in the form of custom hardware-based VPNs and detailed network security policies that are implemented and continuously verified for compliance either by the organisation or by a trusted network connectivity provider. Data diodes may be used for one-way communication from/to lower trust zones.

In general, the resource zones connected through a very high trust connectivity zone should themselves have very high trust and vice versa.

Applicable to:

Internal high security users and systems of the organisation operating within Closed User Groups.

High security users and systems of different Organizations connecting through high trust network, all of which are governed by a common set of enhanced security policies.

Examples:

Government and Defence Organizations’ very high security operations.

Very High trust zones for ensuring the integrity and privacy of extremely critical databases, such as Aadhaar biometric data, CCA and CA root certificates etc.

Using Trust Level Tags

The trust levels can be applied to various tags so as to establish a common understanding between different teams and organisational hierarchies. Examples are given below.

Data Centre and OT Zones

Notes:

Data centre, remote/ branch office and cloud setups are typically segmented into multiple resource zones, each with its own trust level tag. Resource zones can be Operation zones or Management zones. Connectivity between DC zones is configured, secured & managed via DC networking infrastructure.

Colour tagged table of trust levels may be downloaded here.

End User Zones

Notes:

Resources in User zones are typically configured, secured, and managed by the organisation/ user owning the resource (user account and/ or device).

Colour tagged table of trust levels may be downloaded here.

Connectivity Zones

Notes:

A connectivity zone is typically configured, secured, and managed by the network provider, data centre provider or, in some cases, by the organization.

Colour tagged table of trust levels may be downloaded here.

Perimeter between Trust Zones

Perimeter tags defined below are in the context of separation between trust zones (tagged with the higher trust zone)

It may be noted that Critical Information Infrastructure (CII) of entities should typically be in Resource zones with trust levels TL3, TL4 or TL5. Also, they should never be connected directly through a Connectivity Zone with trust level TL0.

Perimeters between zones with different trust levels should implement security policies that are aligned with the required trust levels of the separated zones.

Colour tagged table of trust levels may be downloaded here.

Mapping Trust Levels to Government Classification

The Ministry of Home Affairs has defined the following security classification tags:

• Top Secret: Information, unauthorized disclosure of which could be expected to cause exceptionally grave damage to the national security or national interest. This category is reserved for nation’s closest secrets and is to be used with great reserve.
• Secret: Information, unauthorized disclosure of which could be expected to cause serious damage to the national security or national interest or cause serious embarrassment in its functioning. This classification should be used for highly important information and is the highest classification normally used.
• Confidential: Information, unauthorized disclosure of which could be expected to cause damage to the security of the organisation or could be prejudicial to the interest of the organisation or could affect the organisation in its functioning. Most information, on proper analysis, will be classified no higher than confidential.
• Restricted: Information, which is essentially meant for official use only and which would not be published or communicated to anyone except for official purpose.
• Unclassified: Information that requires no protection against disclosure. e.g. public releases.

Government organisations may want to establish a standardised mechanism to map classification tags to trust levels of resource and connectivity zones in government IT infrastructure. A sample mapping is illustrated below:

Capability Maturity Models

Capability development is not a point in time activity. It must be sustained and improved throughout the life of an organisation. This requires mechanisms for continually monitoring and measuring the capability maturity of the organisation. A mature governance framework enables the leadership to set objectives, monitor performance, match performance with internal and external drivers and constraints to derive future projections.

A capability maturity model typically comprises of a set of characteristics, attributes, indicators, or patterns that represent capability and progression in a particular discipline. Principally, the models must be able to provide insights to some of the concerns of CSEs and national bodies, as listed below:

• What are the maturity levels of CSEs in comparison with established benchmarks in governance, risk management, enterprise architectures, system lifecycle management, IT and infosec capabilities, technology implementations, operations and support processes, workforce characteristics?

• What must be improved?

• What needs to be measured and assessed to enable improvement?

• How comprehensive are the enterprise policies, practices and processes?

• How good is the visibility, oversight, and control across the enterprise on the compliance to policies?

In general, CMMs have the following characteristics:

• collect the best practices.

• are developed by a collaboration of experts from diverse backgrounds.

• consider the dispersion in size, knowledge, skills, abilities, and experience of organisations that use the model.

• take a life cycle and continuous improvement approach.

There are prominent capability maturity models in the domains of cybersecurity and SOC operations, which are described below.

Capability Maturity Modelling (CyberCMM)

Cybersecurity Capability Maturity Modelling (CyberCMM) is globally acknowledged as a practical and successful approach to measure and improve the cyber resilience of enterprises. It helps organisations of all sectors, types, and sizes to evaluate and make improvements to their cybersecurity programs. It focuses on the implementation and management of cyber security practices associated with the information technology (IT) and operations technology (OT) assets and the environments in which they operate. A CyberCMM can:

• enable organisations to evaluate and benchmark their cybersecurity capabilities effectively and consistently and prioritize actions and investments to improve their cybersecurity capabilities.

• enable national bodies to share knowledge, best practices, and relevant references across organisations to help them improve their cybersecurity capabilities.

• enable national bodies to carry out data-driven analytics from sectoral, cross-sectoral and trends-over-time perspectives.

Cybersecurity capability maturity models are typically designed and engineered to provide a self- assessment platform for individual CSEs. National bodies are developing central systems that aggregate data from individual CSEs to carry out data-driven analytics from sectoral, cross-sectoral, and trends-over-time perspectives.

US DoE C2M2

The US energy industry led the development of C2M2 to help organisations in the energy sector to assess their cybersecurity maturity and make optimum investments towards that end. The model can also be used by other organisations, irrespective of their size and domain.

The target sectors that have leveraged C2M2 include energy, critical manufacturing, government, healthcare, defence industrial base and financial services.

The C2M2 leverages a set of proven cybersecurity practices, focusing on both IT and OT assets and environments. The C2M2 domains are:

• Asset Change & Configuration Management.

• Threat & Vulnerability Management.

• Risk Management.

• Identity & Access Management.

• Situational Awareness.

• Events and Incident Response.

• Third Party Risk Management.

• Workforce Management.

• Cybersecurity Architecture.

• Cybersecurity Program Management.        

US DoD CMMC

The model was developed for the Dept of Defense by Software Engineering Institute, Carnegie Mellon University (SEI-CMU) in collaboration with the Johns Hopkins University Applied Physics Laboratory with the intent to protect sensitive national security information and to protect the Defense Industrial Base from frequent and complex cyberattacks.

The intent of the framework is to assess and improve the overall cyber resilience of the Defence Industrial Base (DIB). The cybersecurity capabilities of DIB organisations can be rigorously measured using CMMC. This can be used by the DoD to make risk-informed decisions regarding the information it shares with DIB contractors. The CMMC thus helps the DOD in establishing levels of confidenece with regard to the security of defense contractors and the DIB.

The CMMC framework draws on maturity processes and cybersecurity best practices from multiple standards as well as input from DIB entities and the DoD. It is primarily designed to secure the Defense Industrial Base (DIB) supply chain. The DIB organisations have to be certified by a CMMC third-party assessment organisation (C3PAO) at a particular level prior to bidding on contracts.

The CMMC defines the following:

• a practice is a specific technical activity or activities that are required and performed to achieve a specific level of cybersecurity maturity for a given capability in a domain.

• a process is a specific procedural activity that is required and performed to achieve a maturity level.

CMMC version 2.0 Dec 2021 defines 14 domains, three levels with practices for each level for the DIB, as under:

• Level 1 – Foundational (level 1 of v1.0) - 17 practices 48 FAR 52-204-21 Oct 2016

• Level 2 – Advanced (level 3 of v1.0) – mirrors NIST SP 800-171 (110 practices)

• Level 3 – Expert (level 5 of v1.0) – based on subset of NIST SP 800-172.

The 14 domains are aligned with the families specified in NIST SP 800-171

• Access Control (AC)

• Awareness & Training (AT)

• Audit & Accountability (AU)

• Configuration Management (CM)

• Identification & Authentication (IA)

• Incident Response (IR)

• Maintenance (MA)

• Media Protection (MP)

• Personnel Security (PS)

• Physical Protection (PE)

• Risk Assessment (RA)

• Security Assessment (CA)

• System & Comn Protection (SC)

• System & Info Integrity (SI)

An organisation must meet both the process and practice level requirements to achieve that level of certification within CMMC.

IEC 62443 Maturity Levels

From an organisational perspective, the IEC 62443 standard series describes four “Maturity Level” ratings (ML 1 – ML 4). The ML rating system is used to evaluate how well an organisation defines and describes security processes and how well the processes are followed by the personnel involved. The maturity levels are distinct from security levels (SL-T).

CERT Resilience Management Model (CERT-RMM)

The CERT Resilience Management Model (CERT-RMM), developed by the CERT Division of SEI, Carnegie Mellon University defines 26 processes areas grouped into 4 categories - Enterprise Management, Operations Management, Engineering and Process Management. The resilience strategy translates to evolving measures to protect and sustain the assets viz. people, information, technology and facilities.

ReBIT Cybersecurity Maturity Model (CMM)

The RBI Cyber Security Maturity Model (CMM) is developed in Oct 2017 as an industry initiative coordinated by ReBIT. The CMM is closely aligned with RBI-CSF, which is harmonious with international standards, such as NIST CSF, COBIT 5.0, ISO 27000 and other standards.

RBI CMM focuses on i) implementation and adoption of the mandated cybersecurity framework uniformly in the financial firms, ii) understanding of the firm’s cybersecurity maturity in terms of the adoption of the regulatory cybersecurity framework, iii) benchmarking, and iv) regulatory tracking.

The CMM provides guidance through i) a methodical approach to measurement of risk, planning of controls and governance and security strategy execution to strengthen cybersecurity posture of financial firms, and ii) metrics-based treatment, benchmarking and prioritizing risk driven investment in security.

Secure Controls Framework’s™ (SCF)

SCF’s Cybersecurity & Data Privacy Capability Maturity Model (C|P-CMM) is an undertaking by SCF contributors to define maturity levels for the SCF’s control catalogue. The SCF leverages an existing framework, namely the Systems Security Engineering Capability Maturity Model v2.0 (SSE-CMM) and provides control-level criteria to an existing CMM model.

SOC-CMM

SOC-CMM, evolved from a research project to become a well-used standard for measuring capability maturity in Security Operations Centres. The SOC-CMM model was initially created to determine characteristics and features of SOCs, such as specific technologies or processes. It evolved to become the defacto standard for measuring capability maturity in Security Operations Centers.

At the core of the assessment tool lies the SOC-CMM model. This model consists of 5 domains and 26 aspects, that are each evaluated using a number of questions. The domains ‘Business’, ‘People’ and ‘Process’ are evaluated for maturity only (blue colour), the domains ‘Technology’ and ‘Services’ are evaluated for both maturity and capability (purple colour).

Maturity

SOC-CMM is a continuous maturity model, allowing improvements across all domains simultaneously and independently. The SOC-CMM uses maturity stages based loosely on the CMMI:

• Non-existent. At this level, the aspect is not present in the SOC

• Initial. The aspect is delivered in an ad-hoc fashion

• Managed. The aspect is documented and delivered consistently

• Defined. The aspect is managed using ad-hoc feedback on the quality and timeliness of deliverables

• Quantitatively Managed. The aspect is systematically being measured for quality, quantity and timeliness of deliverables

• Optimizing. The aspect is continuously being optimized and improved.

Capability

The SOC-CMM uses a continuous approach to measuring technical capability across the technology and services domains. These can be technical features, such as the existence of certain tooling options or other features such as service artefacts. Capabilities can be expressed at any maturity level. Just like with maturity scoring, capability scoring is continuous. Similar to the CMMI, the SOC-CMM supports 4 capability levels:

• Incomplete. The capability is missing or lacking essential features

• Performed. The capability is performed, but not standardised

• Defined. The capability is deliverd in a standardised fashion

• Managed. The capability is active managed and improved.

Methodology

The methodology used to create the SOC-CMM is a scientific research approach called Design Science Research. This type of research has a focus on bridging the gap between theory and practice and works well for areas that have not been extensively (scientifically) studied and clearly defined, as is the case for SOC capability and maturity. The goal of Design Research is the creation of a tangible result of the research effort. In this case, two artefacts were created: the SOC-CMM model, which is an abstract representation of SOCs and the self-assessment tool based on that model to evaluate capability maturity in a SOC.

The SOC-CMM self-assessment tool is available for download here.

National Guidelines

This compendium of national guidelines for cybersecurity is summarised from the original sources for information only. Readers must consult the authoritative sources for the actual guidelines.

Ministry of Electronics and Information Technology (MeitY)

National Cyber Security Policy 2013

Overview & Purpose

The National Cyber Security Policy 2013 provides vision “to build a secure and resilient cyberspace for citizens, businesses and Government” and mission “to protect information and information infrastructure in cyberspace, build capabilities to prevent and respond to cyber threats, reduce vulnerabilities and minimize damage from cyber incidents through a combination of institutional structures, people, processes, technology and cooperation”. It gives an overview of what it takes to effectively protect information, information systems & networks and an insight into the Government’s approach and strategy for protection of cyber space in the country. It also outlines some points to enable the collaborative working of all key players in public & private to safeguard the nation’s information and information systems.

Audience

The audience includes government ministries and departments, government and non-government entities, large, medium and small enterprises, decision-makers, procurement teams, service providers and other stakeholders.

Usage

This policy aims to create a cyber security framework, which leads to specific actions and programmes to enhance the national security posture for its cyber space.

India Enterprise Architecture (IndEA) Framework

Overview & Purpose

The IndEA framework 2018 comprises of a set of architecture reference models, which can be converted into a Whole-of-Government Architecture for India, Ministries, States, Govt. Agencies etc. IndEA is a structured combination of several Reference Models that, together, enable a boundary-less flow of information across the length and breadth of the government and facilitate the delivery of integrated services to the stakeholders, namely, the citizens, businesses and employees. Strictly speaking, IndEA is not an Enterprise Architecture as its name seems to connote. It is a comprehensive and convenient framework for developing Enterprise Architecture to support ICT enabled transformation across governments. It is an authoritative reference providing an integrated, consistent and cohesive view of strategic goals, business services and enabling technologies across the entire organisation. The Agile IndEA framework infuses agile practices into IndEA and simplifies the understanding of IndEA to promote widespread adoption.

Audience

Ministries, States, Govt. Agencies and large organisations in the public sector.

Usage

The IndEA and Agile IndEA frameworks , are based on federated architecture approach and recognise the need to accommodate both greenfield (new) and brownfield (existing/ legacy) eGovernance initiatives.

Policy on Adoption of Open-Source Software for Government of India

Overview & Purpose

The Government of India endeavours to adopt Open-Source Software (OSS) in all e-Governance systems implemented by various Government organisations, as a preferred option in comparison to Closed Source Software (CSS).

Audience

All Government of India organisations under the Central Governments and those State Governments implementing e-Governance applications.

Usage

The policy encourages the formal adoption and use of Open-Source Software (OSS) in Government Organisations.

National Policy on Software Products (2019)

Overview & Purpose

The purpose of the policy is to develop India as a Software Product Nation and a global leader in the conception, design, development and production of intellectual capital driven software products, thus, accelerating growth of entire spectrum of IT Industry of the country.

Audience

Micro, Small and Medium Enterprises, Indian Software Product Companies (ISPC) and Startups.

Usage

To promote the creation of a sustainable Indian software product industry, driven by intellectual property (IP), leading to a ten-fold increase in share of the Global Software product market by 2025; To nurture 10,000 technology startups; To create a talent pool; To build a cluster-based innovation driven ecosystem and In order to evolve and monitor schemes & programmes for the implementation of this policy, National Software Products Mission is set up with participation from Government, Academia and Industry.

Email Policy of Government of India, 2024

Overview & Purpose

The policy complements the framework that applies to the security of email solution(s) utilised to provide email services.

Audience

All Government of India organisations.

Usage

This policy applies to use and use-related security aspects governing email services.

Public Procurement Order 2018 for Cyber Security Products

Overview & Purpose

The Cyber Security Products notification encourages ‘Make in India’ to promote manufacturing and production of goods and services in India with a view to enhancing income and employment. Cyber Security Product means a product or appliance or software manufactured/produced for the purpose of protecting, information, equipment, devices computer, computer resource, communication device and information stored therein from unauthorized access, use, disclosure, disruption, modification or destruction. Cyber Security being a strategic sector, preference shall be provided by all procuring entities to domestically manufactured/ produced Cyber Security Products.

Audience

Domestically manufactured/ produced Cyber Security products covered in turnkey/ system integration projects.

Usage

For preference to domestically manufactured/ produced Cyber Security products, forming part of the turnkey/ system-integration projects.

Government of India (GI)-Cloud (Meghraj)

Overview & Purpose

To utilize and harness the benefits of cloud computing, the Government of India embarked upon an ambitious initiative – “GI Cloud” which has been named as ‘Meghraj’. The focus of this initiative is to accelerate delivery of e-services in the country while optimizing ICT spending by the Government. A set of guidelines have been published on the Ministry of Electronics and Information Technology website , which are briefly described below.

Guidelines for Enablement of Government Departments for Adoption of Cloud

The guidelines, provide a structured framework to facilitate the seamless transition of government entities to cloud-based solutions. These guidelines aim to promote the adoption of cloud technologies by addressing key aspects such as readiness assessment, capacity building, service selection, and risk management. They outline a phased approach for cloud adoption, ensuring alignment with operational requirements, security standards, and compliance obligations. By offering best practices and a roadmap for cloud enablement, the document empowers government departments to leverage the benefits of cloud computing, such as scalability, cost efficiency, and enhanced service delivery, while mitigating associated risks.

Software Development & Re-Engineering Guidelines for Cloud Ready Applications

The guidelines provide a comprehensive framework to design and modernize applications optimized for cloud environments. These guidelines emphasize creating scalable, interoperable, and flexible applications that adhere to open standards and leverage modular design principles, ensuring seamless integration across diverse platforms. They promote the development of Common Application Software (CAS), allowing states and departments to configure applications for specific needs without altering core functionalities, reducing duplication of efforts. The guidelines advocate for the adoption of open-source tools and configurable components to enhance innovation, minimize vendor lock-in, and streamline development processes. Additionally, they address metadata standards, multi-language support, and adherence to software engineering protocols to ensure consistency, security, and quality. By fostering reusability, scalability, and rapid deployment, the guidelines aim to facilitate the creation of robust, cloud-ready applications that align with MeitY’s vision for a digitally empowered society, enhancing efficiency and reducing costs for government and critical sectors.

Cloud Security Best Practices

The guidelines provide a detailed framework to ensure the secure adoption and management of cloud services by government entities and other stakeholders. The document outlines essential security measures to protect data integrity, confidentiality, and availability in cloud environments. It covers areas such as access control, data encryption, incident response, compliance, and governance, emphasizing the shared responsibility model between cloud service providers (CSPs) and users. The guidelines aim to address risks like unauthorized access, data breaches, and compliance violations while ensuring that cloud deployments align with regulatory requirements and international security standards. By following these best practices, organizations can minimize vulnerabilities, enhance trust in cloud technologies, and ensure the secure handling of sensitive information.

Guidelines for Procurement of Cloud Services

The guidelines provide a comprehensive framework to help government departments transition to cloud-based solutions while ensuring compliance with security and regulatory standards. These guidelines aim to standardize the procurement process, enabling government entities to adopt scalable, cost-efficient, and flexible cloud services effectively. They emphasize critical aspects such as Service Level Agreements (SLAs), data security, privacy, contractual terms, and risk management. The document offers a Master Service Agreement (MSA) template to address key concerns like data ownership, exit strategies, and dispute resolution while highlighting the differences between traditional IT and cloud service procurement. By outlining roles and responsibilities for stakeholders, such as cloud service providers (CSPs) and system integrators (SIs) and recommending best practices for safeguarding data integrity and availability, the guidelines ensure that digital transformation initiatives in the public sector are aligned with national objectives and operational requirements. These guidelines empower government departments to make informed decisions, promoting transparency, efficiency, and consistency in cloud adoption.

Guidelines for Government Departments on Contractual Terms Related to Cloud Services

The guidelines provide a structured framework to assist government entities in drafting and negotiating contracts with cloud service providers (CSPs). These guidelines aim to address critical contractual elements such as data ownership, security, privacy, liability, indemnity, termination, and exit management to safeguard the interests of government departments. By focusing on risk mitigation and compliance with regulatory and operational requirements, the guidelines ensure that cloud contracts are robust, clear, and enforceable. They empower government departments to establish fair and balanced agreements that protect sensitive data, ensure service continuity, and foster accountability, thereby enabling secure and efficient cloud adoption.

Guidelines for User Departments on Service Level Agreement for Procuring Cloud Services

The guidelines provide a structured approach for government departments to draft, evaluate, and enforce SLAs when adopting cloud services. These guidelines aim to ensure clarity and accountability between government users and cloud service providers by defining key performance metrics, responsibilities, and penalties for non-compliance. They address critical areas such as service uptime, data security, response times, and disaster recovery, ensuring that the agreed service levels meet operational and regulatory requirements. By offering a detailed SLA framework, the guidelines empower government departments to establish measurable expectations, monitor service performance, and safeguard their interests in cloud procurement agreements.

Master Service Agreement for Procurement of Cloud Services

The MSA provides a standardized contractual framework to facilitate transparent and efficient cloud service procurement by government entities. It outlines the terms and conditions governing the relationship between government departments and cloud service providers (CSPs), addressing critical aspects such as service delivery, data ownership, security, privacy, termination clauses, and exit management. It ensures that cloud services are procured with clearly defined responsibilities, measurable performance metrics, and robust dispute resolution mechanisms. By providing a comprehensive and legally sound agreement template, the MSA enables government departments to safeguard their interests, ensure compliance with regulatory requirements, and build trust with CSPs while transitioning to cloud technologies.

Audit Criteria for Cloud Service Providers

The audit criteria document establishes a comprehensive framework to evaluate and ensure that CSPs meet the required standards for delivering secure, reliable, and compliant cloud services to government entities. These criteria outline essential audit parameters across areas such as data security, privacy, service availability, incident management, compliance with legal and regulatory requirements, and operational efficiency. The purpose of the guidelines is to provide a standardized evaluation mechanism to assess the capabilities and performance of CSPs, ensuring they align with the stringent requirements of government projects. By implementing these audit criteria, government departments can identify trustworthy CSPs, mitigate risks, and uphold the integrity of their cloud-based operations.

Audience

Ministries of GoI, States and organisations in the public sector.

Usage

The guidelines enable ministries, government departments and others to use the GI Cloud services offered by the empaneled cloud service providers.

Ministry of Home Affairs (MHA)

NISPG 5.0

Overview & Purpose

The National Information Security Policy and Guidelines (NISPG) version 5.0, issued by the Ministry of Home Affairs (MHA), Government of India, focuses on establishing guidelines to help secure “information” that may impact internal security and national security. These guidelines are based on the analysis of existing global security standards and frameworks and the emerging trends and discourse in the wake of persistent threats, and cyber-attacks on critical infrastructure of nations globally.

Audience

Various government organisations in India.

Usage

The NISPG guides Government and Public Sector organisations and associated entities and third parties, in protecting the information under their control or ownership during the information’s lifecycle that includes creation, storage, processing, accessing, transmission and destruction.

Cyber Security Guidelines for Government Employees

Overview & Purpose

These guidelines are meant to sensitize the government employees and contractual/ outsourced resources and build awareness amongst them on what to do and what not to do from a cyber security perspective.

Audience

All government employees, including temporary, contractual/ outsourced resources

Usage

Develop awareness amongst the government employees and contractual/ outsourced resources.

Reserve Bank of India (RBI)

Information Security, Electronic Banking, Technology Risk Management

Overview & Purpose

Addresses various issues arising out of the use of Information Technology in banks and makes recommendations in nine broad areas, namely, IT Governance, Information Security, IS Audit, IT Operations, IT Services Outsourcing, Cyber Fraud, Business Continuity Planning, Customer Awareness programmes and Legal aspects.

Audience

Elements in the Banking Sector.

Usage

Provides a focused project-oriented approach towards implementation of guidelines and to put in place a time-bound action plan to address the gap and comply with the guidelines.

Cyber Security Frameworks in Banks

Overview & Purpose

To enhance the resilience of the banking system by improving the current defences in addressing cyber risks, arising from the low barriers to entry, evolving nature, growing scale/ velocity, motivation, and resourcefulness of cyber-threats to the banking system.

Audience

Elements in the Banking Sector.

Usage

Put in place an adaptive Incident Response, Management and Recovery framework to deal with adverse incidents/ disruptions, if and when they occur.

Outsourcing Information Technology Services

Overview & Purpose

The Reserve Bank of India (Outsourcing of Information Technology Services) Directions, 2023 was introduced to regulate the outsourcing of IT services by financial institutions, ensuring that such practices do not compromise their operational integrity or customer security. These guidelines are effective from October 1, 2023,

Audience

Elements in the Banking Sector. These directions are applicable to all entities regulated by the RBI, including banks, non-banking financial companies (NBFCs), and credit information companies.

Usage

Designed to enhance the operational resilience of financial institutions, ensuring that they remain compliant with regulatory requirements even when IT services are outsourced.

IT Governance, Risk, Controls and Assurance Practices

Overview & Purpose

The RBI Master Direction on Information Technology Governance, Risk, Controls, and Assurance Practices (ITGRCA) was introduced in November 2023 and is effective wef 1st April 2024. It provides a comprehensive framework for banks, NBFCs, and other regulated entities to improve their IT governance, cybersecurity, and risk management practices.

Audience

Elements in the Banking Sector. These directions are applicable to banks, NBFCs, and other regulated entities.

Usage

These guidelines aim to enhance the operational resilience, data security, and risk management capabilities of financial institutions, ensuring they meet the growing challenges of digital transformation and cybersecurity threats.

Digital Payment Security Controls

Overview & Purpose

The RBI Master Direction on Digital Payment Security Controls directions, 2021 provides a detailed framework aimed at strengthening the security of digital payment systems across India for regulated entities to set up a robust governance structure for such systems and implement common minimum standards of security controls for channels like internet, mobile banking, and card payments, among others. While the guidelines are technology and platform agnostic, it aims to create an enhanced and enabling environment for customers to use digital payment products in a safe and secure manner.

Audience

These directions are applicable to regulated entities.

Usage

These guidelines are designed to ensure that digital payment systems remain secure, scalable, and resilient, meeting global security standards and safeguarding customer data and transaction integrity.

Security and Exchange Board of India (SEBI)

SEBI has issued several Cybersecurity & Resilience guidelines for their constituent entities. These are listed below.

CSCRF for SEBI Regulated Entities (REs) 2024

Overview & Purpose

The Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI REs has been formulated in consultation with the stakeholders to strengthen the cybersecurity measures in Indian securities market, and to ensure adequate cyber resiliency against cybersecurity incidents/ attacks.

Audience

Stockbrokers and Depository Participants, Mutual Funds (MFs)/ Asset Management Companies (AMCs), KYC Registration Agencies (KRAs), Qualified Registrar to an Issue and Share Transfer Agents (QRTAs), Portfolio Managers.

Usage

The CSCRF aims to provide standards and guidelines for strengthening cyber resilience and maintaining robust cybersecurity of SEBI REs.

Guidelines for Market Infrastructure Institutions (MIIs) 2023

Overview & Purpose

Market Infrastructure Institutions (i.e. Stock Exchanges, Clearing Corporations and Depositories) are systemically important institutions as they, inter-alia, provide the infrastructure necessary for the smooth and uninterrupted functioning of the securities market. As part of the operational risk management, these Market Infrastructure Institutions (MIIs) need to have a robust cyber security framework to provide essential facilities and perform systemically critical functions relating to trading, clearing and settlement in securities market .

Audience

Market Infrastructure Institutions (MIIs).

Usage

By MIIs to establish and continuously improve their Information Technology (IT) processes and controls to preserve confidentiality, integrity and availability of data and IT systems.

Adoption of Cloud Services by SEBI Regulated Entities (REs) 2023

Overview & Purpose

The major purpose of this framework is to highlight the key risks, and mandatory control measures which REs need to put in place before adopting cloud computing . The document also sets out the regulatory and legal compliances by REs if they adopt such solutions.

Audience

Stock Exchanges, Clearing Corporations, Depositories, Stockbrokers through Exchanges, Depository Participants through Depositories, Asset Management Companies (AMCs)/ Mutual Funds (MFs), Qualified Registrars to an Issue and Share Transfer Agents, KYC Registration Agencies (KRAs).

Usage

This framework provides baseline standards of security and for the legal and regulatory compliances by the REs.

For Stock Brokers / Depository Participants

Overview & Purpose

Guidelines and clarifications to create a framework on cyber security and cyber resilience.

Audience

All Stock Brokers and Depository Participants registered with SEBI.

Usage

Helps create a robust cyber security and cyber resilience framework to provide essential facilities and perform systemically critical functions relating to securities market.

For Stock Exchanges, Clearing Corporations & Depositories

Overview & Purpose

Creates Cyber Security Operation Center (C-SOC) for Market Infrastructure Institutions (MIIs), i.e., Stock Exchanges, Clearing Corporations and Depositories.

Audience

All Stock Exchanges, Clearing Corporations and Depositories (except Commodities Derivatives Exchanges and their Clearing Corporations).

Usage

Helps in prevention of cyber security incidents through proactive actions.

For Mutual Funds/ Asset Management Companies (AMCs)

Overview & Purpose

Extension of framework on cyber security and cyber resilience to Mutual Funds/ Asset Management Companies (AMCs).

Audience

Mutual Funds/ Asset Management Companies (AMCs).

Usage

Includes Mutual Funds/ Asset Management Companies (AMCs) in Cyber Security and Cyber Resilience framework.

For KYC Registration Agencies

Overview & Purpose

Creation of a framework on cyber security and cyber resilience for KYC Registration Agencies.

Audience

KYC Registration Agencies.

Usage

Helps in creation of a Cyber Security and Cyber Resilience framework for KYC Registration Agencies.

For Qualified Registrars to an Issue/ Share Transfer Agents

Overview & Purpose

Guidelines for submission of report / information containing information on cyber-attacks and threats experienced by QRTAs.

Audience

KYC Registration Agencies.

Usage

Helps in protection of the interests of investors in securities and to promote the development and regulation of the securities market.

Central Electricity Authority (CEA)

Cybersecurity Compliance Guidelines

Overview & Purpose

Interim guidelines till such time the “Regulation on Cyber Security in Power Sector” is released.

Audience

All Responsible Entities, System Integrators, Equipment Manufacturers, Suppliers/Vendors, Service Providers, IT Hardware and Software OEMs engaged within the Indian Power Supply Ecosystem.

Usage

The Objectives of these guidelines, as stated within the document are: a) Creating cyber security awareness b) Creating a secure cyber ecosystem c) Creating a cyber-assurance framework d) Strengthening the regulatory framework e) Creating mechanisms for security threat early warning, vulnerability management and response to security threats f) Securing remote operations and services g) Protection and resilience of critical information infrastructure h) Reducing cyber supply chain risks i) Encouraging use of open standards j) Promotion of research and development in cyber security k) Human resource development in the domain of Cyber Security l) Developing effective public private partnerships m) Information sharing and cooperation n) Operationalization of the National Cyber Security Policy.

National Critical Information Infrastructure Protection Centre (NCIIPC)

NCIIPC has issued the following key guidelines, which are available on the website . ‒ Guidelines for Protection of CII. ‒ Evaluating Cyber Security in CII. ‒ SOP: Incident Response. ‒ SOP: Audit of CII/Protected Systems.

The contents of the above documents have now been suitably subsumed into the NCRF. Hence, the NCRF is now intended to be used as the base document for guidelines for protection of CIIs.

CERT-In

Guidelines on Information Security Practices for Government Entities. 2023

Overview & Purpose

The guidelines provide a comprehensive framework to enhance the cybersecurity posture of government organizations. These guidelines outline structured protocols and best practices to safeguard government information systems from cyber threats, emphasizing risk assessment, incident response, and continuous monitoring. The purpose of the guidelines is to strengthen cyber resilience, ensuring government entities can effectively prevent, detect, and respond to cyber incidents while minimizing operational disruptions. They aim to protect the confidentiality, integrity, and availability of sensitive government data through robust security controls and standardized access management practices. Additionally, the guidelines promote a consistent approach to security across departments, enhancing compliance with national laws and cybersecurity standards. By fostering cybersecurity awareness and providing targeted training for government personnel, the guidelines help build a culture of security within governmental operations. Ultimately, they assist in ensuring secure, efficient, and uninterrupted public service delivery while maintaining compliance with relevant regulations.

Audience

The audience includes government departments, public sector organizations, IT administrators, security professionals, and policymakers responsible for safeguarding government information systems.

Usage

The guidelines provide a standardized framework for securing government information systems, enabling effective risk management, incident response, and compliance with cybersecurity laws, while fostering consistent security practices and resilience against cyber threats.

Reporting of Security Incidents 2022

Overview & Purpose

Cyber incidents and cyber security incidents have been and continue to be reported from time to time and in order to coordinate response activities as well as emergency measures with respect to cyber security incidents, the requisite information is either sometime not found available or readily not available with service providers/data centres/body corporate and the said primary information is essential to carry out the analysis, investigation and coordination as per the process of law. Outlines the triage mechanism when any aspect of a computer system is threatened by loss of confidentiality, disruption of data or system integrity, denial of service availability.

Audience

Service providers, intermediaries, data centres, bodies corporate and Government organisations.

Usage

By reporting cybersecurity incidents to CERT-In the System Administrators and users receive technical assistance in resolving these incidents. This also helps CERT-In to correlate the incidents, analyse them, draw inferences, disseminate up-to-date information and develop effective security guidelines to prevent the occurrence of the incidents in future.

Empanelment of Information Security Auditing Organisations

Overview & Purpose

Guidelines and procedures for empanelment of Information Security Auditors by CERT-In.

Audience

All Information Security Consulting Organisations.

Usage

Assist Information Security Auditors in understanding and meeting the requirements of empanelment with CERT-In.

Guidelines on Software Bill of Materials (SBOM), 2024

Overview & Purpose

The Software Bill of Materials (SBOM) Guidelines are a critical step toward strengthening software supply chain security in India. These guidelines aim to provide a detailed inventory of software components, including libraries, dependencies, and third-party modules, to enhance transparency, accountability, and risk management. By offering a comprehensive understanding of the components within a software application, the SBOM facilitates the identification of vulnerabilities and ensures compliance with cybersecurity standards. The purpose of these guidelines is to manage software supply chain risks, protect organizations from insecure or outdated libraries, and promote secure software development practices. They also assist in vendor risk management by enabling organizations to assess third-party risks and establish accountability in the software lifecycle. Additionally, SBOMs support organizations in responding swiftly to cyber threats and incidents by providing detailed knowledge of software components, thus enabling efficient vulnerability management. These guidelines are particularly significant for sectors like critical infrastructure, government services, finance, and healthcare, where cybersecurity is paramount. MeitY’s SBOM framework promotes industry best practices, ensuring secure software procurement, development, and maintenance while building trust in the software ecosystem.

Audience

The audience includes government entities, critical sector organizations, software developers, vendors, regulatory bodies, auditors, security professionals, and policymakers responsible for software security and compliance.

Usage

The guidelines provide organizations with a standardized framework for identifying, managing, and mitigating risks in their software supply chains. It enables transparency in software components, facilitates compliance with cybersecurity standards, enhances the ability to respond to vulnerabilities, ensures vendor accountability, and promotes secure software development practices. This policy is designed to improve risk assessment, regulatory compliance, and overall cybersecurity posture in critical sectors and government operations.

Secure Application Design, Development, Implementation & Operations 2024

Overview & Purpose

The prime objective of this guideline is to establish a firm and robust application security baseline in application development lifecycle. This approach is crucial for ensuring the application’s security right from the initial phase and progressively strengthening every phases of application development lifecycle.

Audience

Entities engaged in developing or outsourcing application development (especially for Government sector entities).

Usage

The secure application development practices outlined in this document have been crafted to enable organisations to customize them according to their specific requirements and seamlessly integrate them into their application lifecycle right from the outset of an application development project. The establishment of context of the security in design process is addressed which underscores all security considerations, encompassing not only secure application design but also secure architectural design, by considering the environment to which the application will be integrated, and outlining strategies to ensure its comprehensive security.

Information Security Practices for Government Entities

Overview & Purpose

The purpose of these guidelines is to establish a prioritized baseline for cyber security measures and controls within government organisations and their associated organisations. The guidelines should assist security teams to implement baseline and essential controls and procedures to protect their cyber infrastructure from prominent threats. These guidelines shall also act as a baseline document for administration and audit teams (internal, external/ third-party auditors) to evaluate an organisation’s security posture against cyber security baseline requirements.

Audience

Ministries, Departments, Secretariats and Offices specified in the First Schedule to the Government of India (Allocation of Business) Rules, 1961, their attached and subordinate offices, and all government institutions, public sector enterprises and other government agencies under their administrative purview (hereinafter collectively referred to as “government entities”).

Usage

These guidelines cover the best practices segregated in different security domains such as Network Security, Application Security, Data Security, Auditing, Third Party Outsourcing. Due to the ever-evolving threat landscape, this document is envisaged to be an organic document and would be updated as per changing threat landscape.

Standards and Frameworks

This compendium of IT and Information Security standards and frameworks is summarised from the original sources for information only. Readers must consult the authoritative sources for the actual guidelines.

Standards relevant to Critical Sector Entities

The table below gives an illustrative list of the IS/ISO/IEC standards that are relevant to critical sectors.

International IT and Information Security Standards

The table below gives an overview of the international standards and frameworks that are useful to critical sectors.

Explanatory Notes

Many of the IS, ISO, IEC and ITU-T standards are mandated by the regulatory bodies and national nodal agencies. Any guidance that is based on IS, ISO, IEC, ITU-T standards provides the following advantages:

• These standards are maintained and regularly updated by an international panel of experts, which also has Indian participation.

• The ISO standards can be easily extended to include any additional requirements, especially those that are defined under the Indian law and regulation, or available in global frameworks like NIST, CIS, CSA etc. 

• The standards can provide a common baseline reference amongst all the NCRF stakeholders, especially in the i) definition and usage of various terms, ii) governance, management, risk, compliance and audit frameworks, iii) implementation and continual improvement approaches, and iv) standardisation of processes related to verification, validation, measurement and audit. The common baseline reference will ensure that the possibility of misunderstanding amongst the stakeholders is minimal.

• Entities can get their organisations certified against specific management standards. The entities can also procure and use the other guidance and technical standards to help them in maximising the effectiveness during implementation.

• There will be synergy between the entities and their internal/ external experts, consultants, implementers and auditors, since everyone refers to the same set of standards. In practice, this is already being done with regard to popular standards such as ISO 9000, ISO 27000 and IEC 62443 series.

• The oversight mechanism of Government bodies, regulators and national nodal agencies is easily harmonised when all bodies adopt a commonly accepted set of standards.

• There is already a large pool of consultants, implementers and auditors in India, who have the knowledge, expertise and experience in implementing and auditing entities based on these standards. Capacity building of this pool, both in terms of quantity of personnel and quality of expertise, can be taken up through various national and international forums. Both ISO and IEC invest in strengthening the skills of its members, both at the human and the organisational level, through extensive training and technical assistance programmes. The capacity building programmes of ISO and IEC may be explored further.

• BIS, a member of ISO and IEC, has a mechanism in place for standardisation and supply of standards at reasonable prices within the Indian ecosystem. Similarly, Department of Telecom (DoT) represents India at the ITU-T and QCI is a member of the International Accreditation Forum (IAF), a worldwide association of accreditation bodies and other bodies interested in conformity assessment. Through these organisations, the Indian Government and ecosystem can maximise the effectiveness of use of globally recognised standards and frameworks.

• The ISO and IEC are exploring new ways to provide dynamic deliverables that adapt to the needs of users in a much more flexible way. Together, they are developing a common vision for Standards that are Machine Applicable Readable and Transferable (SMART)⁵,⁶. The SMART standards will be modular, machine readable, and eventually, machine interpretable and executable. The corresponding Indian Standards can hugely benefit from this initiative.

In view of the advantages listed above, the concepts and guidance have been built upon and aligned with a selected set of IS, ISO, IEC and ITU-T reference standards that are relevant and applicable to the Indian ecosystem. All the stakeholders are encouraged to develop their understanding of the core principles, approaches, methods and processes described in these base set of standards, so that the concepts and guidance can be used effectively. 

The regulated and critical sector entities will benefit significantly if they obtain further guidance from the IS/ISO/IEC and other standards listed below:

• Governance of IT and information security, based on ISO/IEC 38500, 27014, COBIT etc

• Service Management System (SMS) that are typically based on IS/ISO/IEC 20000 family.

• Information Security Management System (ISMS) that are typically based on IS/ISO/IEC 27000 family, including sector specific standards.

• ISO 27013 standard that assists organisations in implementing both ISO 27001 and ISO 20000-1 concurrently or in implementing one where another is already in place.

• OT Security that are typically based on IEC 62443 series.

• Other standards related to IT asset management, audit etc.

• Other frameworks such as NIST, CIS, CSA etc.

Formats and Protocols

This compendium of IT and Information Security formats and protocols is summarised from the original sources for information only. Readers must consult the authoritative sources for the actual guidelines.

Open automation formats and protocols are essential tools that facilitate interoperability and integration among various systems, devices, and software applications. Designed to enable standardised communication, these formats and protocols provide a common language for systems in industries such as cyber security, telecommunications, and IT, allowing for seamless automation processes across diverse platforms. Some of these relevant for cyber security are referred in subsequent paras with purpose and usage.

STIX

Overview: To share CTI, it is imperative that the underlying platform converts the data into a form that is ready for being sent through the network. To that end a process is required to convert the data-object (a combination of code and data) in a form so that the state of the object is saved in a transmittable format. This is known as Serialization . Once the data is received at the destination in a Serialized form, it is Deserialized before further processing. STIX stands for Structured Threat Information Expression. It is an open source, XML based “language and serialization format used to exchange” CTI. STIX is a standardized language for representing and sharing cyber threat intelligence (CTI) in a consistent, machine-readable format. Developed by MITRE and now managed by OASIS, STIX enables organisations to share detailed threat information, including attack patterns, tactics, techniques, and procedures (TTPs), indicators of compromise (IOCs), and threat actor profiles. The structured nature of STIX allows cybersecurity tools to process threat data automatically, enhancing detection, analysis, and response capabilities across systems

Purpose: Leveraging STIX, organisations can collaborate effectively while exchanging CTI because of the consistency and machine readability that STIX provides. Consequently, security communities benefit as anticipation to attacks improve and agility in response mechanisms is enhanced. Further, its design is such that it augments capabilities, such as “collaborative threat analysis, automated threat exchange, automated detection and response” .

Usage: STIX at its core architectural layer contains “observables” that it refers to as “stateful properties or measurable events”, pertaining to the “operation of computers and networks”. For example, it could be stopping a service, reboot of a system or establishing a connection. Storage of these “observables” is done in XML using “CybOX language, another MITRE project”. Further, as a part of the framework, these “observables can be linked to indicators, incidents, TTPs, specific threat actors, adversary campaigns, specific targets, data markings, and courses of action” - that it evolves into a “complete threat intelligence management system”.

TAXII

Overview: TAXII stands for Trusted Automated Exchange of Intelligence Information. It is an “application protocol for exchanging CTI over HTTPS, defining “a RESTful API (a set of services and message exchanges) and a set of requirements for TAXII Clients and Servers” . An API, or an Application Programming Interface plays the role of a mediator between the Client and the Web Service. The advantage here is that information sharing is done “maintaining security, control, and authentication—determining who gets access to what”. A RESTful (or REST - representational state transfer) API “conforms to the constraints of REST architectural style and allows for interaction with RESTful web services”. For an API to be a RESTful API, it needs to comply with certain criteria like “Client-server architecture”, with HTTP based requests, “Stateless Client-Server communication”, “Cacheable data” etc.

Purpose: It enables sharing CTI “across product, service and organisational boundaries” and acts as a “transport vehicle for STIX structured threat information”.

Usage: The two primary services TAXII provides are: (a) Collection and (b) Channel. The TAXII server has a repository of CTI objects that it allows its Users to host, which can be accessed by consumers. Collection is an interface to this repository. A Channel can be viewed as a many to many interface - that allows a producer to push data to many consumers and a consumer to receive data from many producers.

Traffic Light Protocol (TLP)

Information Sharing

The critical success factors for cyber resilience and sustenance of a digital ecosystem are: a) The speed and quality of detection of compromise and cyber-attacks within the entities. b) The rapidity by which information and guidance is disseminated to all the actual and potential targets. c) The speed and effectiveness of response within entities as well as across sectors and cross-sectors.

Conventional paper-based and email-based methods of sharing are not capable of achieving the required speed in information sharing amongst all the stakeholders and participants, since they are less amenable for automated processing. Traffic Light Protocol is a standardised mechanism for sharing information. TLP version 2.0 is the current version of TLP standardized by FIRST. The Traffic Light Protocol (TLP) was created to facilitate greater sharing of potentially sensitive information and more effective collaboration. Information sharing happens from an information source, towards one or more recipients. TLP is a set of four labels used to indicate the sharing boundaries to be applied by the recipients.

TLP definitions

Community: Under TLP, a community is a group who share common goals, practices, and informal trust relationships. A community can be as broad as all cybersecurity practitioners in a country (or in a sector or region).

Organisation: Under TLP, an organisation is a group who share a common affiliation by formal membership and are bound by common policies set by the organisation. An organisation can be as broad as all members of an information sharing organisation, but rarely broader.

Clients: Under TLP, clients are those people or entities that receive cybersecurity services from an organisation. Clients are by default included in TLP:AMBER so that the recipients may share information further downstream in order for clients to take action to protect themselves. For teams with national responsibility this definition includes stakeholders and constituents.

TLP Labels

TLP:RED = For the eyes and ears of individual recipients only, no further disclosure. Sources may use TLP:RED when information cannot be effectively acted upon without significant risk for the privacy, reputation, or operations of the organisations involved. Recipients may therefore not share TLP:RED information with anyone else. In the context of a meeting, for example, TLP:RED information is limited to those present at the meeting.

TLP:AMBER = Limited disclosure, recipients can only spread this on a need-to-know basis within their organisation and its clients. Note that TLP:AMBER+STRICT restricts sharing to the organisation only. Sources may use TLP:AMBER when information requires support to be effectively acted upon, yet carries risk to privacy, reputation, or operations if shared outside of the organisations involved. Recipients may share TLP:AMBER information with members of their own organisation and its clients, but only on a need-to-know basis to protect their organisation and its clients and prevent further harm. Note: if the source wants to restrict sharing to the organisation only, they must specify TLP:AMBER+STRICT.

TLP:GREEN = Limited disclosure, recipients can spread this within their community. Sources may use TLP:GREEN when information is useful to increase awareness within their wider community. Recipients may share TLP:GREEN information with peers and partner organisations within their community, but not via publicly accessible channels. TLP:GREEN information may not be shared outside of the community. Note: when “community” is not defined, assume the cybersecurity/defence community.

TLP:CLEAR = Recipients can spread this to the world, there is no limit on disclosure. Sources may use TLP:CLEAR when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:CLEAR information may be shared without restriction.

OSCAL

Overview: In the context of NIST, an ATO or an Authorization (to operate) is defined as “The official management decision given by a senior organisational official to authorize operation of an information system and to explicitly accept the risk to organisational operations (including mission, functions, image, or reputation), organisational assets, individuals, other organisations, and the Nation based on the implementation of an agreed-upon set of security controls” . In essence there has to be a formal declaration by a designated authority that authorises operation of an IT product, which includes all the caveats around Risk. Apart from the inherent complexity in handling cyber threats, addressing ATO requirements coupled with the extensive manual processes in handling Risk Management increases the challenges of an Entity’s Information Security Team. The four key challenges in this regard stated by NIST are: - (a) Complexity of Information Technology (b) Omnipresent Vulnerabilities (c) Burdensome nature of Regulatory Frameworks (d) Esoteric nature of Risk Management (e) Accelerated rate of obsolescence of Documentation .

Purpose: The open source, Open Security Controls Assessment Language - or OSCAL, was developed by NIST in collaboration with industry to address the concerns around this space. To overcome the challenges around usage of word processing and spread sheet utilities to handle RMF requirements, improved automation was an imperative. There was a need, therefore, to evolve “a shared language for authorization systems to communicate”.

Usage: OSCAL uses XML, JSON, and YAML formats, providing “machine-readable representations of control catalogs, control baselines, system security plans, and assessment plans and results”. The advantages of OSCAL formats as stated by NIST are: - “Easily access control information from security and privacy control catalogs, Establish and share machine-readable control baselines, Maintain and share actionable, up-to-date information about how controls are implemented in your systems, Automate the monitoring and assessment of your system control implementation effectiveness” .

OpenSCAP

Overview: In any enterprise, the IT systems deployed need to be constantly monitored for vulnerabilities so that remediation measures in terms of configuration changes, patch updates and / or application of upgrades are done in a timely manner. This minimizes risk exposure of the assets within, and the enterprise is better guarded against security threats. The Security Content Automation Protocol - SCAP, is a collection of “number of open standards that are widely used to enumerate software flaws and configuration issues related to security”. In order to associate a metric or measure the possible impact due to the vulnerabilities within the system, applications written for security monitoring leverage these standards. Thus the “SCAP suite of specifications standardize the nomenclature and formats”, that is leveraged by these vulnerability management tools.

Purpose: OpenSCAP is an auditing tool that utilizes security check-list content in a defined format called the Extensible Configuration Checklist Description Format (XCCDF). Combing with other specifications it creates a SCAP-expressed checklist that can be processed by SCAP-validated products.

Audience: IT / IT Security Administrators, Auditors

Usage: The OpenSCAP stack consists of different products that can help with “assessment, measurement, and enforcement of security baselines”, maintaining “flexibility and interoperability” and “reducing the costs of performing security audits” . A few of the Tools in the stack include: - (a) OpenSCAP Base: A Command line tool for performing configuration & vulnerability scanning (b) OpenSCAP Daemon: Evaluating Infrastructure’s compliance to SCAP Policy (c) SCAP Workbench: Helps create a custom security profile and facilitates remote scanning.

Open Command & Control (OpenC2)

Overview: Attackers are in a position to conduct and coordinate various stages of an attack with remarkable sophistication and speed. If Defenders are to sustain their operations, they need to respond with equal alacrity; plan and conduct defense operations in a timeframe that matches the adversary so as to ensure that the latter fails to attain their objectives. But the penetrability of an attack surface is determined by a range of factors that include “complexity, functionality, connectivity” etc. Further, most enterprises do not have an integrated cyber defense implementation; the systems operate in siloes and generally have static configurations. This results in very inefficient cybersecurity operations. Such an environment, by default creates a lag in incident-response-remediation, which gives an adversary “asymmetric time advantage”, to ensure the success of their attack. In a large enterprise there would be number of heterogenous platforms, technologies, devices, and systems. Effective incident response, getting into the root cause, assessing remediation measures, and mitigating them etc. become complex. In such a context, few challenges of integrating the various components of cyber defense include: - (a) Prohibitive costs (b) Tailored Communication Interfaces” (c) Extent of tight-coupling and cohesiveness of the chosen products for integration (d) Need for a middleware etc. As a consequence, scaling of such a solution would depend on ability to get suitable interfaces written or easily available APIs for the different products in use. Paradoxically though, while OEM diversity of solutions do provide an additional layer of security - as attack on one system does not guarantee attack on another, achieving cyber defense integration becomes complex and prohibitive in terms of costs. From an attack perspective, when an attacker penetrates a system and installs a malware which is leveraged to send remote commands from a C2 (Command & Control) Server to infected devices, it is termed a C2 attack. In other words, “command and control infrastructure” is used by attackers to issue “command and control instructions” to their victims. From a cyber-defense viewpoint, an assessment of the C2 approach and methods that an attacker uses could be leveraged to identify and associate attackers and attacks, and disrupt malicious activity that are ongoing.

Purpose: The limitations in integrating cyber defense solutions, stated earlier was the trigger for development of Open Command and Control (OpenC2) . It “is a suite of specifications that enable command and control of cyber defense systems and components” - facilitating “machine to machine communication”, through a “common language”. More important, it does it at very high speeds and in such a way “that is agnostic of the overall underlying technologies utilized”. But for this standard, every new device would need manual configuration or individual commands sent in real time, which apart from increasing the lag in incident response times, would also have human intervention, making it error prone.

Software Bill of Materials (SBOM)

Overview: The entire source code of a software is referred to as its codebase. It is a common practice for developers to integrate with their code, third party components that are licensed and either commercially available or are open source. A SBOM or software Bill of Materials is an inventory of all the “open source and third-party components” that are present, providing details of their versions and status of the patches within the codebase of a software application / product. Information security teams can use this information to assess security & license related risks. Akin to the Manufacturing industry’s Bill of Material (from where SBOM has been derived) where the codification schemes of the parts provided by OEM and Suppliers are distinct, based on which a successful trace to the correct supplier happens when a part goes defective; here too a trail to the accurate third party is established by virtue of the SBOM. There are four stages of an SBOM life cycle. They are: (a) Produce SBOM - Collating the information required for an SBOM at each stage of the software lifecycle from existing tools and solutions. Such solutions normally include: - “intellectual property review”, “license management workflow tools”, “version control systems” etc. (b) Deliver - In the case of opensource tools, the SBOM information can be held as metadata, while for compiled versions the SBOM and the software product are bundled together. (c) Update - If the software is updated in any manner, then any changes in SBOM too needs to be recorded. (d) Consume - In order to utilise SBOM, the SBOM data should be in a machine readable format. However, the decision on choosing the appropriate format that should be adopted for SBOM needs to be taken. The three standard and common formats in use are CycloneDX, SWID and SPDX.

CycloneDX

Purpose: “OWASP CycloneDX is a lightweight” SBOM specification “designed for use in application security contexts and supply chain component analysis”, created in 2017 . The intent was to create a “fully automatable, security-focused SBOM standard”. Existing specifications like Package URL, CPE, SWID etc., have been incorporated into CycloneDX. Each such SBOM can have (a) Bill of Material Metadata (supplier, manufacturer, firmware etc. that it describes), (b) Components - detailed inventory of the software components, which includes type, identity, license etc. (c) Services - description of external APIs, that the utility may invoke (d) Dependencies - interrelationship between components (e) Compositions - that describes the ‘completeness’ of the SBOM. (f) Extensions - For building rapid prototyping of enhancements.

Usage: Software Inventory description, Analysis, Analysis of vulnerabilities and their mitigation, Supply Chain (Software) risk assessments, Compliance of License requirements, Traceability of updates and modifications, Integrity checks of signed components etc.

SWID

Purpose: To enhance transparency in monitoring Software installed within the enterprise, Software Identification (SWID) tags were conceptualised and defined originally by ISO (2012) and later updated as ISO/IEC standard (2015). Description of a specific software release is held in the SWID Tag files. The standard further “defines a lifecycle where a SWID Tag is added to an endpoint as part of the software product’s installation process and deleted by the product’s uninstall process”. In order to capture the lifecycle of a software component, the SWID specification defines following types of Tags: (a) Primary Tag (b) Patch Tag (c) Corpus Tag and (d) Supplemental Tag. SWID Tag that identifies and describes: - (a) a software product installed on a computing device is called a Patch Tag (b) a patch that was installed for making a change of the software installed on the device is referred to as a Patch Tag (c) the pre-installation state of a software product is called a Corpus tag and finally a SWID Tag that permits “additional information to be associated with any referenced SWID tag” is referred to as a Supplemental tag.

Usage: Few use cases are: (a) It can be used as Software Bill of Material for the software products and applications installed (b) Inventory of installed software can be regularly monitored (c) Software vulnerability identification at end points can be carried out (d) Ensures proper patch management (e) Detects unauthorized or corrupt software prior to their installation and prevents their installation.

SPDX

Purpose: SPDX or Software Package Data Exchange , is an ISO /IEC standard. It is used for communicating software bill of material information that includes components, licenses, copyright and security information. It is an evolving “set of data exchange standards” that would assist enterprises with their software supply chain ecosystem by allowing each of them “to share human-readable and machine-processable software metadata” with one another. Like in the case of SWID, stated earlier, work here too began because of limitations that existed in the earlier days of sharing opensource components, resulting in duplication of efforts. Also, collaboration was difficult then. SPDX project created “a common metadata exchange format” which allowed details about software packages and associated content to be collected, shared and made effective automation of the related tasks, feasible. The file formats used here include JSON, XML and YAML. A valid SPDX document has a defined structure with defined sections as stated in the SPDX specification. The section that is mandatory is the “Creation Information’ (version numbers, license of data etc.) - primarily provided for forward and backward compatibility of the tools. The others include “Package Information”, “File Information”, “Snippet Information” and “Other Licensing Information.

Usage: Description of software components and their interrelationships; Tracking licensing, copyright information related to IP; Tracking executables to the source files etc.

OpenIOC

Overview: Like in the case of collating evidence, analyzing them and then weaving it together to reconstruct a crime scene, a cybersecurity analyst too as a part of her function tries to gather data around different events related to new and emerging threats. The nature of this data could be “metadata elements or much more complex malicious code and content samples that require advanced reverse engineering”. The final output of this action is what is generally referred to as IOC or Indicators of compromise. In other words, IOC can be defined as “a forensic artifact or remnant of an intrusion that can be identified on a host or network”.

Purpose: OpenIOC is an XML based open framework used for sharing CTI.

Usage: The format used is machine-readable and assists sharing threats related to the latest IOCs, with other enterprises, helping achieve real-time protection. OpenIoc provides a pre-defined set of indicators as a part of the framework. The extensible nature of the base schema allows add on indicators from different sources. The IOC use cases include: (a) Finding Malware - Used to find known malware (b) Methodology - These IOCs help find suspicious utilities that are unknown. For instance, writing an IOC for a specific condition of an unsigned dll that was loaded from a folder that did not have “windows32system” in its path (c) Bulk - Used for exact matches (d) Investigative - Tracking information like, metadata related to “installation of backdoors”, “execution of tools” etc. in an IOC and using that to prioritise the systems that would be taken up to be analysed.

OpenEDR

Overview: Endpoint detection and response or EDR is a technology that focuses on endpoints and network related events. The agent on the host system helps log the information generated and stores it in a database. This repository is what is leveraged for event monitoring and generating reports. Different EDR solutions package their functions and features differently. Some focus more at the agent level, some have different way of handling schedules for collection and analysis, some others carry out integration tasks with a difference. Functions of EDR are: (a) Traffic and data monitoring from endpoints and checking for anomalies hinting a breach. (b) Automated responses - Removal of malicious files and alerts to information security teams. (c) Search for threats and their signatures through analytics. The core functions of all tools in this space are the same - “continuous monitoring and analysis” for being proactive to respond to threats.

Purpose: OpenEDR is an EDR tool that is both free and its source code available in public domain. It consists of the following components: - (a) Core Library (b) Service (c) Process Monitoring (d) System Monitor (e) File-System Mini-Filter (f) Network Monitor (g) Low-Level Registry Monitoring Component (h) Self-Protection Provider (i) Low-Level Process Monitoring Component.

Usage: One of OpenEDR’s strengths is to enable a user to affect an accurate RCA. Without a clear understanding of root cause, mitigation measures would prove inadequate. The output from the tool provides “actionable knowledge” which helps speed up response. Further its, “Integrated Security Architecture” helps deliver a “Full Attack Vector Visibility including MITRE Framework”.

OpenDXL

Overview: Proliferation of different technologies from various IT Infra and Security Vendors over time, with different upgrade paths, coupled with several home-grown initiatives – all, connected through an underlying network, has made IT Security Management a complex task. Achieving seamless integration between security products from different Vendors has been a constant challenge. API driven integration comes with major maintenance issues. Integration of products from different Vendors also has administrative overheads that includes external dependencies. For instance, getting a buy in from each of the Vendors, their prioritization, commercial interests etc. An application’s limitations for easily accessing emerging CTI data becomes an impediment for each, to apply the insights on emerging threats, making the environment vulnerability prone. As a result, the cyber resilience posture is affected adversely. The mechanism through which security solutions are connected and integration of disparate security systems are achieved is termed as Orchestration. Since substantial volume of output logs are created by security tools currently, SOCs tend to miss intrusions. Security Orchestration addresses this concern.

Purpose: Open Data Exchange Layer or OpenDXL has been developed with the intent of enabling “security devices to share intelligence and orchestrate security operations in real time”. It facilitates the developer community to establish handshakes between security products and minimize lead times of threat defense, by improving “context of analysis”, shortening “workflows of the threat defense lifecycle” etc. The key goals of OpenDXL can be summarized as follows: (a) Enhance flexibility (b) Make integration easier (c) Accelerate development by providing appropriate toolsets (d) Increase Sec Ops ability in creating “cross-product, cross-vendor security automation” and (e) Ensure that API changes by Vendors do not adversely impact integration.

Usage: Use Cases include: “Deception threat events, File and application reputation changes, Mobile devices and assets discovered, Network and user behavior changes, High-fidelity alerts, Vulnerability and indicator of compromise (IoC) data”.

Infrastructure as Code (IaC)

Overview: Like all disciplines in IT, managing IT Infrastructure has gone through its own evolution process. In the past it was customary for manually addressing all aspects of configuration, whether it was hardware or software over which the applications were required to run on. Costs, scalability, availability were all challenges that the organisations had to surmount. Monitoring performance of IT Infra or pinpointing the problem during troubleshooting continued to be an Achilles heel for the IT Infra team. Due to the human intensive nature of deploying configurations, inconsistencies crept in. Therefore, there was a need to explore the possibility of automating configuration management and thereby managing and provisioning IT Infrastructure through code. In that context, two file formats are defined here: (a) JSON: JSON or JavaScript Object Notation originated as a page scripting language in the Netscape Navigator era, for its web browser. It is a format with a defined set of rules that is “text-based, human-readable”, leveraged for data exchange between “web clients and web servers”, sometimes used as an alternative to XML. (b) YAML: YAML or yet another markup language (referred to also as, ain’t another markup language) - A human readable, easily comprehensible language, used for data and not documents is a “data serialization language” which is regularly leveraged while writing configuration files.

Purpose: Infrastructure as Code or IaC, is defined as “The process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools”. In effect it leverages a DevOps approach to deploy IT infrastructure - networks, VMs etc. Akin to a codebase generating identical binary every time, here too the same environment is generated during every deployment. There are two approaches to IaC: (a) Declarative - Where the required state of the system is defined. An environment would need a tailored definition with regards its components and configuration. The definition file describes that. Depending on the kind file formats that the Platform supports - be they JSON, YAML or XML, syntax for describing IaC can be decided. (b) Imperative - “defines the specific commands needed to achieve the desired configuration”.

Usage: Some of the advantages of using IaC are: (a) Reduce Cost (b) Accelerate deployment (c) Less Errors (d) Enhance consistency (e) “Eliminate configuration drift”. More insights can be gleaned from studying Server automation and config management tools like Chef, Puppet, Saltstack etc.

Policy-as-Code

Overview: In a growing tech landscape, it is inevitable not to think of automation when rolling out policies. As proliferation of IT driven solutions take place, protecting the systems from threats is an imperative. For which, rules and procedures are defined as a part of security policy formulation - be it, access control, authorization, network security etc. In essence, a policy is a rule that stipulates the criteria for code deployment against the backdrop of the security control implemented or a set of steps to be executed automatically when there is a particular security event.

Purpose: Policy-as-code is the use of a high-level declarative language to automate managing rules and policies centrally. Leveraging this approach, users write the policies using Python, YAML or Rego - a high-level declarative language “built for expressing policies over complex hierarchical data structures”, depending on the kind of policy-as-code tool that is being used. While IaC benefits the IT operations team where automated provisioning of Infrastructure is involved, policy-as-code focuses on security operations and compliance management. To leverage policy-as-code the user may choose to use a tool like Open Policy Agent or OPA, purpose of which is to provide a common framework while applying policy-as-code to any domain. OPA is a “general-purpose policy engine that enables unified, context-aware policy enforcement across the entire stack”. It allows authoring of policies through Rego. OPA can be leveraged to outsource policy decisions from the relevant service. Eg: Boolean decisions of whether an API call should be allowed, Quota left for a user, the updates to be applied for a particular resource etc.

Usage: The advantages of using policy-as-code are: (a) Enhanced efficiency of enforcement and sharing of policies vis-a-vis the manual route (b) Accelerated operations because of automated policy enforcement (c) Swifter reviewing of policies as there is no requirement for engineers to discuss, they need to only examine the code (d) Improved collaboration within and across teams (e) Accuracy (f) Well defined version controlling of the policies and ability to roll back to the previous version (g) Helps reduce critical errors in production environments.

OMG Requirements Interchange Format (ReqIF)

Overview: Requirements management has been in vogue across different industries for a while. The collaboration requirements in the manufacturing industry – car manufacturing, for instance, uses dedicated authoring tools for their requirement management. Since collaboration requirements are intense, requirements management cross organisational boundaries - and different entities using different authoring tools find it a challenge to work on the same requirements repository. There was a compelling case, therefore, for a “generic, non-proprietary format” for information exchange. Hence, The Requirements Interchange Format or ReqIF was created for enterprises to exchange requirements data, by transferring XML documents that comply to the ReqIF format.

Purpose: Any product development during the initial stages has a requirement gathering phase. This is where ReqIF finds a key use, as multiple entities could be involved. ReqIF facilitates seamless sharing of requirements between agencies, even if each uses a different tool. It is far more efficient than formats like Word, Excel or PDF as it “allows for a loss-free exchange”.

Usage: Few of the advantages of using this format are: Improved collaboration between entities; Obviates the need to use the same authoring tools, Agencies interacting with multiple entities (eg: Suppliers) do not need stack up authoring tools that their respective Customers use.

OASIS CACAO for Cybersecurity

Overview: It is apparent that in order to defend against cybersecurity threats, a structured set of rules need to be defined. A cybersecurity playbook is generally considered to be a comprehensive manual that spells out actions to be taken when there is theft or loss of data. To that end, enterprises need to “identify, create, and document the prevention, mitigation, and remediation steps”, currently in most cases done manually. These steps considered together, constitute a course of action playbook. Like in other areas of the cybersecurity domain, here too lack of a standard mechanism to “document and share these playbooks across organisational boundaries” compounded with inadequate automation, proves to be a challenge.

Purpose: OASIS Collaborative Automated Course of Action Operations (or CACAO) for Cyber Security Technical Committee (TC), tackles this challenge by “defining a sequence of cyber defense actions that can be executed for each type of playbook”.

Usage: This will help entities to: (a) “create course of action playbooks in a structured machine-readable format” (b) “digitally sign course of action playbooks” (c) “securely share course of action playbooks across organisational boundaries and technological solutions” and (d) “document processing instructions for course of action playbooks in a machine-readable format”.

People related Frameworks

This section summarises content from QCI and other frameworks that are related to individual and organisational competencies. Readers must consult the authoritative sources for the actual guidelines.

Terms and Definitions

The terms and definitions are for all stakeholders to use for communicating their perspectives to achieve a common understanding. The terms and definitions are derived from various authoritative sources, accepted standards (ISO/IEC/IEEE, NIST etc), applicable laws (e.g. The IT Act 2000), regulations and broadly accepted public terminologies.

The source(s) of definitions of the terms are also provided, where available. Notes are added under the terms to provide additional information for readers, to help them apply the terms correctly to the context of discussions.

The glossary is divided into the following sub-sections, to align with the ecosystem levels:

• Conceptual terms. Provide basic definitions and interpretations for all readers of this documentation.
• Governance terms. Provide the business leadership, top and senior management with a common vocabulary while engaging with other stakeholders at this level.
• Business terms. Provide the business management and workforce with a common vocabulary while engaging with other stakeholders at this level.
• Technology terms. Provide the technology stakeholders with a common vocabulary while engaging with others at this level. This will be very useful during technical interactions between the CSEs, OEMs, service providers and the national nodal agencies.
• Other terms. Provide some standard definitions for use by all readers.

Conceptual Terms

System (ISO 15288:2015)

• combination of interacting elements organized to achieve one or more stated purposes.

Note 1: A system is sometimes considered as a product or as the services it provides.

Note 2: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun, e.g. information system.

Note 3: A complete system includes all of the associated equipment, facilities, material, computer programs, firmware, technical documentation, services and personnel required for operations and support to the degree necessary for self-sufficient use in its intended environment.

Note 4: Stakeholders, while using the term, are encouraged to clarify the context of the term ‘System’. For example, governance and business level stakeholders use the term ‘System’ to imply a business system. For technology level stakeholders, ‘System’ implies a digital system. For physical security and safety stakeholders, ‘System’ implies a security or safety system.

System-of-interest (ISO 15288:2015)

• system whose life cycle is under consideration.

System-of-systems (SoS) (ISO 15288:2015)

• set of systems that integrate or interoperate to provide a unique capability that none of the constituent systems can accomplish on its own.

Note 1: Each constituent system is a useful system by itself, having its own management, goals, and resources, but coordinates within the SoS to provide the unique capability of the SoS.

Note 2: In this document, a system-of-systems is also termed as an ‘Ecosystem’. See Business ecosystem and Digital ecosystem.

Business system

• a structured and integrated collection of processes, people, technology and governance that combine together to help organisations achieve specific goals and objectives. It provides the organisations an operating structure to deliver their mission/ business functions.

Note 1: the key components of a business system are i) processes, procedures and workflows that outline how activities and tasks are coordinated, managed and executed to achieve specific outcomes, ii) individuals and teams, who perform the tasks and contribute to the overall functionality of the system, iii) technology, tools, equipment, software and other resources that support and automate the processes, iv) governing principles, policies, rules and protocols that ensure consistency and control over data and procedures, and v) methods to measure the results and outcomes the system is designed to achieve.

Note 2: Business systems provide the framework within which business processes are executed. The business processes are the moving parts that make the business system work.

Note 3: The term often alludes to the primary digital system that enables the business system. For example, ERP, CRM, HCM system.

Note 4: Business systems must be reliable and trustworthy. They must incorporate clear matrices for accountability and responsibility, have robust documentation, and be monitored regularly to ensure reliability and trustworthiness.

Digital transformation

• a business strategy initiative that incorporates digital technology across all areas of an organisation. It evaluates and modernises an organisation’s processes, products, operations and technology stack to enable continual, rapid, customer-driven innovation¹.

Note 1: Every organisation’s digital transformation implementation is different. It can begin with a single focused technology project, or as a comprehensive enterprise-wide initiative. It can range from integrating digital technology and digital solutions into existing processes and products, to reinventing processes and products or creating entirely new revenue streams by using still-emerging technologies.

Note 2: An associated term ‘business transformation’ defines the wholesale rethinking and restructuring of an organisation’s business planning, operations, technology, development and customer experience to achieve business goals.

Information system NIST SP 800-37r2

• a discrete set of information resources organised for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information. The term information system includes, for example, general-purpose computing systems; industrial/ process control systems; cyber-physical systems; command, control, and communications systems; devices such as smart phones and tablets; environmental control systems; embedded devices/ sensors; and paper-based systems.

Industrial Control System NIST SP 800-82r3

• general term that encompasses several types of control systems, including supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), and other control system configurations that are often found in the industrial sectors and critical infrastructures, such as programmable logic controllers (PLC). An ICS consists of combinations of control components (e.g., electrical, mechanical, hydraulic, pneumatic) that act together to achieve an industrial objective (e.g., manufacturing, transportation of matter or energy).

Digital system

• an information system.

• an outcome of digital transformation.

• a system comprising of ICT, OT, IoT and IIoT elements. It typically comprises of computing, processing and storage systems, networks, applications, data repositories and user devices that enable and support the automation of business processes and business systems.

Note 1: A digital system is also referred to as digital infrastructure or information infrastructure.

Business ecosystem

• a composition of distributed business systems of individual organisations that work together in partnership to achieve the larger goals and objectives of the community, sector, region and the nation.

Digital ecosystem

• a geographically dispersed, interconnected and federated conglomeration of digital systems that together function as a large system-of-systems.

• a federation of the digital systems of the suppliers, customers, partners, service providers and national bodies.

Note 1: The digital ecosystem is also referred to as the underlying digital infrastructure of the business ecosystem.

Cyberspace

• a conceptual term that mimics the physical space but in a virtual domain. It manifests itself in the form of a digital ecosystem across the world.

Note 1: The national cyberspace is a subset of the global cyberspace, used by the nation’s organisations and people for their business and personal functions. The national cyberspace is not defined by who owns it but by who uses it.

Note 2: An Indian organisation’s cyberspacfe is a subset within the national cyberspace, used by the organisation for its business functions. The organisation acquires the digital infrastructure and uses it to deploy and run applications that enable and support the organisation’s business/ operations. The organisation federates its digital infrastructure with other organisations within the national and global cyberspace.

Note 3: An organisation’s own cyberspace and the national cyberspace can be demarcated within the global cyberspace by means of domains, zones and segments.

Critical Information Infrastructure (ITAA-2008)

• the computer resource, the incapacitation or destruction of which, shall have debilitating impact on national security, economy, public health or safety.

Critical sectors (G.S.R. 19(E), 16 Jan 2014)

• sectors, which are critical to the nation and whose incapacitation or destruction will have a debilitating impact on national security, economy, public health, or safety.

Information Technology (IT) (NIST)

• any services, equipment, or interconnected system(s) or subsystem(s) of equipment, that are used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information.

Information and Communications Technology (ICT) (NIST)

• all categories of ubiquitous technology used for the gathering, storing, transmitting, retrieving, or processing of information (e.g., microelectronics, printed circuit boards, computing systems, software, signal processors, mobile telephony, satellite communications, and networks).

Operations Technology (OT) (NIST)

• a broad range of programmable systems and devices that interact with the physical environment or manage devices that interact with the physical environment. These systems and devices detect or cause a direct change through the monitoring and/or control of devices, processes, and events.

Note 1: Examples include industrial control systems, building automation systems, transportation systems, physical access control systems, physical environment monitoring systems, and physical environment measurement systems.

Note 2: Alternative terms for OT are Industrial Control Systems (ICS) (used by NIST) and Industrial Automation and Control Systems (IACS) (used by IEC).

Internet of Things (IoT) (NIST)

• user or industrial devices that are connected to the internet. IoT devices include sensors, controllers, and household appliances.

Industrial Internet of Things (IIoT) (NIST)

• sensors, instruments, machines, and other devices that are networked together and use Internet connectivity to enhance industrial and manufacturing business processes and applications.

Note 1: An IoT device has at least one transducer (sensor or actuator) for interacting directly with the physical world and at least one wired or wireless network interface (e.g., ethernet, wi-fi, bluetooth, Long-Term Evolution (LTE), Zigbee, Ultra-Wideband (UWB)) for interfacing with the digital world (NIST IR 8259).

Note 2: An IoT product contains at least one IoT device and three specific kinds of IoT product components (NIST IR 8425):

• Specialty networking/ gateway hardware.

• Companion application software.

• Backends to which data is transferred for backup, storage and analysis.

Note 3: An IoT system is composed of networked IoT components and interacts with a physical entity of interest through one or more sensors and/or actuators that are within the IoT components. IoT systems differ from conventional IT systems in their ability to directly interact with the physical world (NIST IR 8316).

Information security (IS) (NIST)

• the protection of information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide confidentiality, integrity, and availability.

Information security (IS) (ISO 27000:2018)

• preservation of confidentiality, integrity and availability of information.

Note: In addition, other properties such as authenticity, accountability, non-repudiation and reliability can also be involved.

Cyber security (CS) (ITAA-2008)

• protecting information, equipment, devices, computer, computer resource, communication device and information stored therein from unauthorised access, use, disclosure, disruption, modification, or destruction.

Note 1: The definition is explicitly used for information technology (IT) elements and also for elements of operations technology (OT) and Industrial Internet of Things (IIoT).

Note 2: The terms Information Security (IS) and Cyber Security (CS) are often used interchangeably, since there are only some minor distinctions between the two terms. Notes 3 to 6 below provide guidance for specific situations in which one term is more appropriate than the other.

Note 3: In general, the information security is used in the context of securing information that is held and managed in both digital and non-digital (paper-based) forms. Cybersecurity is used in the context of securing the cyber-ecosystem (IT, OT, and IIoT) from cyber-attacks.

Note 4: Data and information content encompasses i) content created, used and managed using office productivity tools, ii) content stored in databases and other electronic repositories, which may be located on-premises or on cloud, iii) content searched, accessed and shared using web, email and other technologies, iv) machine to machine exchange of content through information exchange standards and protocols (EDI, API, STIX/TAXII), and OT-specific communication protocols (Modbus, DNP3/ IEEE 1815-2012, IEC-60870, IEC 61850, IEC 61131, IEC 62351) and, v) archival content stored in online and offline backups.

Note 5: Data and information related activities encompass i) content creation, updation and deletion (CRUD activities), ii) data processing, iii) view, copy, scan, search and print, iv) content integrity and confidentiality protection using digital signatures and encryption, v) masking or redaction of sensitive content and reclassification of the masked/ redacted content, vi) content exchange and distribution through electronic media and communication channels, vii) short-term and long-term storage of content and, viii) secure disposal of content from all the electronic stores, as per the organisation policies.

Note 6: Most OT systems are process control systems. Typically, the input and output OT data of such systems have a short period of utility. The most important concerns of such systems are the availability of the systems themselves, safety of the physical environment around the systems or influenced by them. The confidentiality of data exchanged through OT protocols, as well as intermittent data loss are minor concerns. As regards data integrity, the concern is more about the integrity of the process control systems that generate, consume and process the data using OT protocols. In summary, focus of OT security is more about protecting critical processes (Safety, Availability, Integrity) and less about data loss (Confidentiality).

Cyber defence

• a set of defensive activities carried out across the organisation’s digital infrastructure by different teams of the organisation, by means of well-established practices and processes, with or without automation.

Note 1: The objective of cyber defence is to protect the organisation’s digital infrastructure from harm and to ensure its availability for use by all authorised users.

Note 2: Cyber defence is similar to physical defence but in the cyberspace. Just as in physical defence, securing the digital infrastructure of the nation and/ or organisations requires both proactive actions like anticipating, continually observing and plugging breaches, and reactive measures like responding to and mitigating cyberattacks when they occur.

Resilience (NIST)

• the ability to prepare for and adapt to changing conditions and withstand and recover rapidly from disruption. Resilience includes the ability to withstand and recover from deliberate attacks, accidents, or naturally occurring threats or incidents.

Cyber resilience (NIST)

• the ability of an information system to operate under adverse conditions or stress, even if in a degraded or debilitated state, while maintaining essential operational capabilities, and to recover to an effective operational posture in a time frame consistent with mission needs.

• the ability to anticipate, withstand, recover from, and adapt to adverse conditions, stresses, attacks, or compromises on systems that use or are enabled by cyber resources. Cyber resiliency is intended to enable mission or business objectives that depend on cyber resources to be achieved in a contested cyber environment.

Note: Cybersecurity is the practice of protecting the digital infrastructure from unauthorised access, data breaches, and cyber-attacks. Cyber resilience is an organisation’s capability to prepare for, respond to, and recover from cyber threats and disruptions. Both functions require a combination of technologies, practices and processes, policies and controls, peope and governance for delivering the required outcomes.

Domain (ISO/IEC/IEEE)

• distinct scope, within which common characteristics are exhibited, common rules observed, and over which a distribution transparency is preserved.

• area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area.

Domain (NIST)

• a set of elements, data, resources, and functions that share a commonality in combinations of (1) roles supported, (2) rules governing their use, and (3) protection needs.

Note 1: Domain Coverage/ Scope - A domain’s coverage/ scope lists the elements, data, resources, processes and practices grouped under the domain, to reflect one or any combination of the following: i) capability, functional, or service distinctions; ii) data flow and control flow associated with capability, functional, or service distinctions; iii) data and information sensitivity; iv) data and information security; or v) administrative, management, operational, or jurisdictional authority.

Note 2: Domain Principle/ Objective - A domain’s principle/ objective describes at a high level what an organisation is required to do/ achieve with regard to the requirements for the domain, using the triad of processes, people and technology.

Note 3: “Domain” is a widely used term by different practitioners to describe their working environments. For example, management teams use the term to describe distinct functional areas and job responsibilities. Systems and software engineering teams classify their work into different technical domains. HR and training teams define knowledge and skill domains to refer to different sets of concepts, topics and modules about which the professionals are expected to possess or develop the required competency. Security teams define security domains to categorise the security characteristics, policies and authorities. Cybersecurity capability maturity modelling research teams use distinct domains to classify, gather evidence and measure the capability and maturity of organisations.

Policy (ISO 38500:2015)

• intentions and direction of an organisation as formally expressed by its governing body or executive managers acting with appropriate authority.

Note 1: A “policy” is a high-level statement of intent or direction that provides guidance to individuals and organisations on how they should act in specific circumstances. A policy is a formal declaration of an organisation’s objectives, values, and principles, and it provides the basis for decision-making and the development of related processes, procedures, and controls.

Note 2: Policies are an important component of a management system, as they provide the overall direction and guidance for the management system and help to ensure that the management system is aligned with the organisation’s objectives and values. Policies should be clear, concise, and aligned with the overall strategic objectives of the organisation, to enable the management system to deliver its intended outcomes.

Note 3: A policy typically defines a scope (business processes, departments and locations that will be covered by the policy), the external and internal environment of the organisation (to identify the interfaces and dependencies), and the business, IT, and information security objectives of the policy (what it seeks to achieve).

Practice

• a set of activities that are continuously carried out over time, in pursuit of an organisation’s strategic interests and goals.

Note 1: A “practice” typically comprises of persons/ teams owning the practice, along with activities, governance, tools, and technology platforms to implement and operate the practice. The intelligence of the practice—how it gets something accomplished—is embedded in the complex, analytical and decision-making expertise of the practice owners (individuals/ teams). The key outcomes of a practice are continuous refinement, optimisation of effort and leveraging of the organisation’s expertise. The adoption of best practices can help organisations to improve their performance, meet regulatory requirements, and achieve their goals more effectively.

Process

• set of interrelated or interacting activities that use inputs to deliver an intended result. (ISO 9000:2015)

• a set of repeatable activities and tasks, usually designed as a set of well-defined steps with well-defined beginnings and ends, to get something done.

Note 1: A “process” typically comprises of people, activities and tasks, governance, tools, and technology platforms to implement and execute the process. The execution steps of a process may be carried out sequentially or in parallel, either by a person, team or through automation. The intelligence of the process—how it gets something accomplished—is embedded in the process design and does not require complex decision-making by the persons or automation agents executing the steps. In other words, the process designer converts the knowledge of an activity or task into well-defined sequence of steps and records the same in the process documentation. People or automation agents are only supposed to know how to execute the steps laid down in the process documentation, without having to understand why they are to be done. The key outcomes of a process are standardisation, speed, efficiency and automation.

Note 2: There is no rigid hierarchy between practices and processes. A practice can have multiple sub-practices and/ or processes. Usually, over time, many practice owners convert parts of their practice into processes with well-defined execution steps and enable them using automation.

Note 3: Everything need not be a practice or a process. For example, activities and tasks that are performed infrequently, or those that do not have clear sequence of steps, can just be accomplished without defining a practice or process for the same. It is also important that practices and processes should not become the end goal by themselves but should only help reach the end goal.

Note 4: Parameters and metrics to quantify and measure a practice or process are designed so as to help improve and maintain their performance and effectiveness.

Procedure

• specified way to carry out an activity or a process, which may or may not be documented. (ISO 9000:2015)

• a specific and documented way of performing a task or activity, to ensure that it is carried out consistently in its defined manner.

Note 1: A procedure typically outlines the detailed steps to be followed by an individual, a team or automation to perform a task or activity to achieve the required outcomes of the task or activity. Procedures are more prescriptive and granular than processes.

Guidelines

• a type of document that provides recommendations or suggestions on how to achieve a particular outcome or meet certain objectives.

Note 1: Guidelines are intended to help users interpret and apply the requirements and principles set out in the applicable policies and standards, and to provide guidance and best practices for specific applications or contexts.

Control

• a mechanism to ensure that an activity or process is performed as intended. It comprises of a set of actions that should be taken to manage risk, prevent or mitigate negative outcomes, and ensure that the system is functioning as required.

Note 1: In the context of cybersecurity, a control is a measure implemented to reduce risk and protect information assets. The specific risk or issue being addressed defines the type of control(s) to be used, which may be administrative controls, such as policies and procedures, technical controls, such as role-based access permissions or physical controls, such as locks and alarms.

Control objective/ purpose

• a statement that defines what a control is intended to achieve.

Note 1: A control objective is a specific and measurable outcome that is desired from a control. It provides the basis for evaluating the effectiveness of the control in relation to the risks or issues that the management system is designed to address.

Note 2: Control objectives/ purposes are an important component of a management system, as they provide the basis for defining and designing controls. Effective control objectives help organisations ensure that their management system is functioning effectively and achieving their objectives.

Governance Terms

Accountable (ISO 38500:2015)

• answerable for actions, decisions and performance.

Accountability

• state of being accountable. Accountability relates to an allocated responsibility. The responsibility can be based on regulation or agreement or through assignment as part of delegation. (ISO 38500:2015)

• the obligation to exercise authority that is based on established standards and to take ownership of the outcomes or results.

Note 1: Authority can be delegated, Responsibility can be shared but cannot be delegated, Accountability can neither be shared nor delegated.

Aim or Goal

• the desired result of an effort. 

Note: In an entity/ organisational context, the term ‘mission’ is also used.

Audit

• a structured, independent, and recorded method for gathering audit evidence and impartially assessing it to ascertain the degree of compliance with the audit standards.

Note 1: Audits can be internal (first party), external (second-party or third-party), or combined audits (integrating multiple disciplines).

Note 2: An internal audit is carried out by the organization or by an external entity acting for the organization.

Note 3: The fundamental elements of an audit include the determination of the conformity of an object according to a procedure carried out by personnel not being responsible for the object audited.

Note 4: An internal audit may serve management review and other in-house functions and may underpin an organization’s self-declaration of compliance. Independence in this context is demonstrated by the auditor’s lack of involvement in the activities under review. External audits encompass both second and third-party evaluations. Second-party audits are performed by parties with a vested interest in the organization, like clients or their representatives. Third-party audits are carried out by independent external bodies, such as certification authorities or regulatory agencies.

Note 5: This constitutes one of the common terms and core definitions of the high-level structure for ISO management system standards. The original definition has been modified by adding Notes 3 and 4 to entry.

Authority

• the right or power assigned to an individual or a government entity in order to achieve defined goals and objectives. An ‘authority’ gives official and legal right to take decisions, command action by others and enforce compliance.

Board of Directors

• usually maps to the governing body. Designations are usually in the form of CMD, MD, Executive and Non-executive Directors. In the Government, the word ‘Authority’ is also used.

Context of the organisation (ISO 9000:2015)

• Combination of internal and external issues that can have an effect on an organisation’s approach to developing and achieving its objectives.

Consequence (NIST, ISO 15026-1:2019)

• effect (change or non-change), usually associated with an event or condition or with the system and usually allowed, facilitated, caused, prevented, changed, or contributed to by the event, condition, or system.

Continuity

• the strategic and tactical ability, sanctioned by management, for an organization to prepare for and react to various conditions, situations, and events to maintain operations at an approved, predetermined level.

Note 1: Continuity is a broader concept that encompasses both operational and business continuity, ensuring an organization’s capacity to continue functioning under non-standard conditions. This concept is applicable to all types of organizations, including for-profit, non-profit, public interest, and governmental entities.

Coordination

• way in which different organisations (public or private) or parts of the same organisation work or act together in order to achieve a common objective.

Note 1: Coordination combines the individual response efforts of all involved entities to create a cohesive incident response with a shared goal and coordinates actions through open sharing of information about their respective incident response efforts.

Note 2: All organizations participate in the process to agree on a shared incident response goal and commit to implementing strategies through a consensus-based decision-making process.

Corrective action

• to prevent recurrence, remove the cause of a nonconformity and prevent it from occurring.

Crisis

• volatile situation marked by an imminent drastic or substantial change that demands immediate attention and action to safeguard lives, assets, property, or the environment.

Crisis management

• comprehensive management approach that identifies potential threats to an organization and establishes a structure for resilience, with the capacity for an effective response that protects the interests of the organization’s key stakeholders, reputation, brand, and value-generating activities, as well as efficiently reinstating operational capabilities.

Note 1: Crisis management also involves managing readiness, mitigation, response, and recovery or continuity in the event of an incident, as well as overseeing the overall programme through training, rehearsals, and reviews to ensure that preparedness, response, and continuity plans remain current and relevant.

Crisis management team

• a collective of individuals tasked with guiding the creation and implementation of plans for response and operational continuity, declaring states of operational disruption or crisis, and directing the recovery efforts both before and after an incident.

Note 1: This team may include members from within the organization as well as first responders and other relevant parties.

Criticality analysis

• a systematic procedure to identify and assess the significance of an organization’s assets based on their role in the organization’s mission, the potential impact on people, or the consequences of disruptions on meeting organizational goals.

Customer (ISO 20000-10:2018)

• organisation or part of an organisation that receives a service or services.

EXAMPLE: Consumer, client, beneficiary, sponsor, purchaser.

Note 1: A customer can be internal or external to the organisation delivering the service or services.

Note 2: A customer can also be a user. A customer can also act as a supplier.

Direct (ISO 38500:2015)

• communicate desired purposes and outcomes to. In the context of governance of IT, ‘direct’ involves setting objectives, strategies, and policies to be adopted by the members of the organisation to ensure that use of IT meets business objectives. Objectives, strategies, and policies can be set by managers if they have authority delegated by the governing body.

Disruption

• an event, expected or unexpected, that causes an undesired deviation from the anticipated delivery of products and services, impacting an organization’s objectives.

Documented information

• records that an organization must manage and maintain, which can be in various formats and media, originating from any source.

EXAMPLE: Policies, plans, process descriptions, procedures, service level agreements or contracts.

Note 1: Documented information can encompass the management system, its processes, operational documentation, and evidence of outcomes achieved.

Effectiveness (ISO 9000:2015, ISO 20000-10:2018)

• extent to which planned activities are realized and planned results are achieved.

Efficiency (ISO 9000:2015)

• relationship between the result achieved and the resources used.

Enterprise (TOGAF)

• any collection of Organizations that has a common set of goals.

Example: an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant Organizations linked together by common ownership. An extended enterprise nowadays frequently includes partners, suppliers, and customers.

Enterprise or corporate governance

• The functions carried out by the governing body of an entity and the top management of the Organisations of an entity.

Entity (ISO 27014:2020)

• a corporate or enterprise group of companies or a single company in the public or private sector, a government body or a body owned or controlled by the government. An entity can have multiple Organizations within itself or be identical to the organisation, as in smaller companies. The entity has governance authority over the organisation.

Evaluate (ISO 38500:2015)

• consider and make informed judgements. In the context of governance of IT, evaluate involves judgements about the internal and external, current and future circumstances and opportunities relating to the organisation’s current and future use of IT.

Executive manager (ISO 38500:2015)

• person who has authority delegated from the governing body for implementation of strategies and policies to fulfil the purpose of the organisation. Executive managers can include roles which report to the governing body or the head of the organisation or have overall accountability for major reporting function, for example Chief Executive Officers (CEOs), Heads of Government Organizations, Chief Financial Officers (CFOs), Chief Operating Officers (COOs), Chief Information Officers (CIs), and similar roles. In management standards, executive managers can be referred to as top management.

Executive management

• usually maps to the top management of the entity and its Organisations. Designations are usually in the form of CXOs.

External supplier (ISO 20000-10:2018)

• another party that is external to the organisation that enters into a contract to contribute to the planning, design, transition, delivery or improvement of a service, service component or process.

Function, Operation

• what an entity does in order to fulfil its goal, mission and objectives. Typically comprises of activities, processes, practices.

Governance (ISO 38500:2015)

• system of directing and controlling

Governance of information security

• system by which an organisation’s information security activities are directed and controlled. (ISO 27000:2018)

• the means by which an organisation’s governing body provides overall direction and control of activities that affect the security of an organisation’s information. This direction and control focuses on circumstances where inadequate information security can adversely affect the organisation’s ability to achieve its overall objectives. (ISO/IEC 27014:2020, Reccomendation ITU-T X.1054 (04/2021))

It is common for a governing body to realise its governance objectives by:

• providing direction by setting strategies and policies;
• monitoring the performance of the organization; and
• evaluating proposals and plans developed by managers.

Management of information security is associated with ensuring the achievement of the objectives of the organisation described within the strategies and policies established by the governing body. This can include interacting with the governing body by:

• providing proposals and plans for consideration by the governing body; and
• providing information to the governing body concerning the performance of the organization.

Effective governance of information security requires both members of the governing body and managers to fulfil their respective roles in a consistent way.

Governance of IT (ISO 38500:2015)

• system by which the current and future use of IT is directed and controlled.

Governance of IT is a component or a subset of organisational governance. The term governance of IT is equivalent to corporate governance of IT, enterprise governance of IT, and organisational governance of IT.

Note: Typically, Enterprise IT Governance deals with resources required to acquire, process, store and disseminate information. Enterprise Information Security Governance deals with assurance of information confidentiality, integrity and availability and effective communication of the same with various external stakeholders.

Governing body (ISO 27014:2020)

• person or group of people who are accountable for the performance and conformance of the entity.

Impact

• outcome of a disruption affecting objectives.

Impact analysis

• process of analysing all operational functions and the effect that an operational interruption can have upon them.

Note 1: Impact analysis, a component of risk assessment, includes business impact analysis and identifies the nature of potential losses, the potential for escalating damage over time, the essential minimum services and resources required for business continuity, and the recovery timeline and scope for organizational activities, functions, and services.

Incident

• an unexpected interruption or degradation of service, or an event that has not yet affected service delivery to customers or users.

Interested party, Stakeholder (ISO 9000:2015)

• person or organisation that can affect, be affected by, or perceive itself to be affected by a decision or activity.

Internal supplier (ISO 20000-10:2018)

• part of a larger organisation that is outside the scope of the SMS, that enters into a documented agreement to contribute to the planning, design, transition, delivery or improvement of a service, service component or process.

EXAMPLE - procurement, infrastructure, finance, human resources, facilities.

Key Performance Indicators (KPI)

• a mechanism for measurement.

• a measurable value that organisations use to evaluate their performance against strategic and operational goals.

Note 1: Terms such as objectives, metrics, goals, targets, KPIs, and outcomes are often used interchangeably, which can lead to confusion, especially during external audits. Organisations should clarify the context in which these terms are used.

Likelihood

• chance of something happening.

Note 1: In risk management, “likelihood” refers to the probability of an event, defined in various ways, including objectively, subjectively, qualitatively, quantitatively, or mathematically (e.g., probability or frequency over time).

Note 2: While “likelihood” and “probability” may be used differently in English, in risk management, “likelihood” is intended to be as broadly interpreted as “probability” is in many non-English languages.

Levels of management hierarchy.

Entities usually have the following levels of management hierarchy with regard to business/ IT / Information Security goals, plans, activities and functions:

• Strategic Level: long term (multi-year) planning, goal setting, management oversight activities and accountability lies with the governing body and top management. IS/ISO/IEC 9001:2015 defines the term ‘strategic direction’.

• Tactical Level: short term (quarterly/ half-yearly/ yearly) planning, target setting, management oversight activities and responsibility lies with the top management and senior management.

• Operational Level: ultra-short term (daily/ weekly/ fortnightly/ monthly) planning, target setting, management activities and responsibility lies with the senior, middle level and lower-level management.

Note 1: The term Business as Usual (BAU) is also used for operational level functions and activities.

Note 2: Audit and compliance verification/ validation is usually done across the three time-frames – long term, short term and ultra-short term.

Note 3: One mechanism to distinguish the levels of hierarchy within an entity is by the financial powers and decision authority that is delegated to each level. Another mechanism is the type of decision making that is allowed (strategic, tactical or operational) and the chain of command/ reporting.

Lower management

• usually maps to supervisory or operative management, the first line managers of systems, processes, and teams.

Management (ISO 38500:2015)

• exercise of control and supervision within the authority and accountability established by governance.

Note: The term management describes the coordinated activities to direct and control an organisation (ISO 9000:2015). It can include establishing policies and objectives, and processes to achieve the objectives. It is also used as a collective term for those with responsibility for controlling an organisation or parts of an organisation. The term managers is used to avoid confusion with management systems.

Managers (ISO 38500:2015)

• group of people responsible for control and supervision of an organisation or parts of an organisation. Executive managers are a category of managers.

Middle management

• usually maps to department or branch management, the second line managers of systems, processes, and teams.

Mission (ISO 9000:2015)

• organisation’s purpose for existing as expressed by top management.

Monitor (ISO 38500:2015)

• review as a basis for appropriate decisions and adjustments. Monitoring involves routinely obtaining information about progress against plans as well as the periodic examination of overall achievements against agreed strategies and outcomes to provide a basis for decision making and adjustments to plans. Monitoring includes reviewing compliance with relevant legislation, regulations, and organisational policies.

Objective (ISO 9000:2015)

• result to be achieved. An objective can relate to different disciplines, be strategic, tactical, or operational, and can apply at different levels (such as strategic, organisation-wide, project, product and process. An objective can be expressed in other ways, e.g. as an intended outcome, a purpose, an operational criterion, or by other words with similar meaning (e.g. aim, goal, or target).

Note: Objectives are usually defined using SMART - Specific, Measurable, Achievable, Relevant and Time bound - statements of purpose.

Organisation (ISO 27014:2020)

• The whole entity or part of an entity, which works under the governance authority of the entity.

Note: ISO/IEC 27014:2020 provides the distinction between entity and organisation in the context of ISMS. By definition, the ISMS covers the whole of an organisation, which by itself may cover the whole of the entity or part of the entity. Typically the two terms defined in ISO 27014:2020 are applied to both the governance of IT and Information Security.

Organisational governance (ISO 38500:2015)

• system by which Organisations are directed and controlled.

Organisational resilience

• the capacity of an organization to endure and adapt to changes in the environment.

Outcome

• the result or effect of an action. Typically expressed using quantifiable/ measurable/ comparative units.

Note: Objectives are rooted in intention and planning. Outcomes are the results of execution. Achievement of objectives can be measured through the outcomes. 

Outsource

• the practice of delegating a portion of an organization’s functions or processes to an external entity.

Preventive action

• proactive measures taken to remove the root causes of potential nonconformities or other undesirable situations to prevent their occurrence.

Problem

• the origin of one or more actual or potential incidents.

Protection

• strategies and safeguards implemented by an organization to lessen the impact of potential disruptions.

Recovery

• the process of restoring and, where appropriate, enhancing the operations, infrastructure, livelihoods, or living conditions of organizations affected by disruptions, including actions to reduce risk factors.

Resource

• the collective term for all assets, including equipment and facilities, personnel, expertise, technology, premises, supplies, and information, that an organization requires for its operations and to achieve its goals.

Response plan

• a detailed set of procedures and information compiled and maintained in readiness for deployment during an incident.

Response programme

• a structured approach, including plans, processes, and resources, to conduct activities and provide services essential for the preservation and protection of life, property, operations, and critical assets.

Note 1: Typical response actions include recognizing the incident, notifying the appropriate parties, assessing the situation, declaring the incident, executing the response plan, communicating with stakeholders, and managing resources.

Response team

• a dedicated group responsible for formulating, implementing, practicing, and updating the response plan and its associated processes and procedures.

Responsibility

• obligation to act and take decisions to achieve required outcomes. (ISO 38500:2015)

• an obligation to perform an assigned task or duty and take ownership of the outcomes or results.

Risk

• the potential effect of uncertainty on objectives.

Note 1: An effect can deviate from what was expected, positively, negatively, or both, and can lead to opportunities as well as threats.

Note 2: Objectives can vary in nature and category and can be applied at different organizational levels.

Note 3: Risk is often characterized by the sources of risk, potential events, their outcomes, and the probability of occurrence.

Risk analysis

• the examination of risk nature and the assessment of risk levels.

Note 1: Risk analysis informs risk evaluation and decisions regarding risk management.

Note 2: It encompasses risk estimation.

Risk assessment

• the comprehensive process of risk identification, risk analysis, and risk evaluation.

Note 1: This involves pinpointing internal and external threats and vulnerabilities, assessing the likelihood and impact of potential events, defining essential operations, establishing controls to minimize exposure, and evaluating control costs.

Risk communication

• the sharing and exchange of risk-related information among decision-makers and other stakeholders.

Note 1: This information may concern the existence, characteristics, probability, severity, acceptability, management, or other aspects of risk.

Risk criteria

• benchmarks used to gauge the significance of a risk.

Note 1: These criteria are derived from organizational goals and both external and internal contexts.

Note 2: They may be based on standards, laws, policies, and other regulations.

Risk evaluation

• the process of comparing risk analysis outcomes with predefined risk criteria to decide if the risk and its magnitude are acceptable.

Note 1: Risk evaluation aids in making decisions about risk management.

Risk identification

• the act of detecting, recognizing, and describing risks.

Note 1: This includes pinpointing risk sources, events, their causes, and potential outcomes.

Note 2: Risk identification may use historical data, theoretical analysis, expert input, and stakeholder needs.

Risk management

• the orchestrated efforts to guide and control an organization with respect to risk.

Risk mitigation

• the process of reducing the negative effects of a hazardous event.

Risk owner

• the party responsible and accountable for managing a particular risk.

Risk reduction

• actions aimed at decreasing the likelihood or adverse consequences associated with a risk.

Risk register

• a documented record of identified risks.

Note 1: It compiles all risks identified, analysed, and evaluated in the risk assessment process, including details on probability, outcomes, mitigation measures, and risk owners.

Risk sharing

• a risk management strategy that involves distributing risk among various parties through agreement.

Note 1: Legal or regulatory stipulations may restrict, forbid, or mandate risk sharing.

Note 2: It can be executed via insurance or contractual agreements.

Note 3: The degree of risk distribution depends on the reliability and clarity of the sharing arrangements.

Note 4: Risk transfer is a type of risk sharing.

Risk source

• a factor or combination of factors that can potentially lead to risk.

Risk tolerance

• the willingness of an organization or stakeholder to accept risk following risk management measures.

Note 1: Risk tolerance may be influenced by clients, stakeholders, legal, or regulatory requirements.

Risk treatment

• the process of modifying risk.

Note 1: This can include avoiding, accepting, reducing, or sharing risk, as well as pursuing opportunities presented by the risk.

Note 2: Measures addressing negative outcomes are often termed as risk mitigation, elimination, prevention, or reduction.

Note 3: Risk treatment can introduce new risks or alter existing ones.

Robustness

• the strength of a system to withstand internal or external attacks, whether virtual or physical.

Note 1: This includes the system’s ability to resist imitation, intrusion, or circumvention.

Security management

• the coordinated actions to steer and oversee an organization in terms of security and resilience.

Security policy

• a formal set of guidelines and procedures designed to safeguard information and computing resources.

Senior management

• usually maps to the management that is one rung lower than the top management. In practice, general managers (GM) business unit, line and staff management heads are part of the senior management.

Service

• a means of providing value to customers by enabling desired outcomes.

Note 1: Services are usually intangible in nature.

Note 2: Within the context of the SMS, ‘service’ specifically refers to the services covered by the system. Any other use of the term is clearly differentiated.

Service Level Agreement (SLA)

• a formalized agreement that outlines the services provided and their expected level of performance.

Note 1: SLAs can also be established with external or internal suppliers, or with customers who act as suppliers.

Note 2: An SLA may be part of a contract or another formal agreement.

Service integrator (ISO 20000-10:2018)

• entity that manages the integration of services and service components delivered by multiple suppliers

Note: The role of the service integrator supports the promotion of end-to-end service management, particularly in complex supply chains by ensuring all parties are aware of, enabled to perform, and are held accountable for their role in the supply chain.

Service management

• the capabilities and processes used to direct and manage an organization’s activities and resources for the design, transition, delivery, and enhancement of services.

Note 1: Organizations can tailor these requirements into their processes, using sub-clauses to define their SMS processes.

Note 2: An SMS encompasses policies, objectives, plans, processes, documented information, and resources needed for service planning, design, transition, delivery, and improvement.

Service provider (ISO 20000-10:2018)

• organisation that manages and delivers a service or services to customers.

Strategy (ISO 9000:2015)

• plan to achieve a long-term or overall objective.

Threat

• a potential source of harm or adverse event that could negatively impact individuals, assets, systems, organizations, the environment, or communities.

Top management (ISO 27014:2020)

• person or group of people who direct and control the organisation (as defined above) at the highest level. The top management of the organisation is accountable to the governing body of the entity and has the power to delegate authority and provide resources within the organisation. In smaller entities, where the entity and organisation are identical, top management is the same as governing body.

Use of IT (ISO 38500:2015)

• planning, design, development, deployment, operation, management, and application of IT to fulfil business objectives and create value for the organisation. The use of IT includes the demand for, and the supply of, IT, the current and future use of IT.

User (ISO 20000-10:2018)

• individual or group that interacts with or benefits from a service or services.

Note: Examples of users include a person or community of people. A customer can also be a user.

Validation

• the act of confirming that certain criteria or requirements have been met for a specific purpose or use, supported by objective evidence.

Value

• the significance, advantage, or utility of something.

Example: This could be monetary worth, service delivery success, meeting service management goals, retaining customers, or eliminating obstacles.

Note 1: Value creation from services involves achieving benefits while managing resources efficiently and handling risks. Both assets and services can be assigned value.

Verification

• the process of confirming that specific requirements have been satisfied, based on objective evidence.

Vision (ISO 9000:2015)

• aspiration of what an organisation would like to become as expressed by top management.

Vulnerability

• a detectable flaw or weakness in a computer system’s hardware or software that could be exploited, leading to malfunction or unintended operation.

Weakness

• Defect or characteristic that may lead to undesirable behavior.

• A condition in a software, firmware, hardware, or service component that, under certain circumstances, could contribute to the introduction of vulnerabilities.

Workforce

• all individuals contributing to the achievement of an organization’s goals, including employees, temporary staff, contractors, and volunteers.

Note 1: This documentation uses the term composite workforce to refer to all the entities and individuals, who “work” for the organisation. The composite workforce comprises of the organisation’s own employees, contracted manpower and third-party product and services providers.

Note 2: Automation agents and bots provide an hugely scalable non-human workforce that supplements the limited human workforce.

Business Terms

Asset

• a resource, object, or entity that holds potential or actual significance to an organisation.

Note 1: Value may be material or immaterial, encompassing both monetary and non-monetary aspects, and takes into account potential risks and obligations. Throughout various stages of an asset’s lifecycle, its value can fluctuate, presenting either positive or negative worth.

Note 2: Physical assets typically denote the tangible items such as machinery, stock, and real estate that are in the possession of the organization. Physical assets are the opposite of intangible assets, which are non-physical assets such as leases, brands, digital assets, use rights, licences, intellectual property rights, reputation, or agreements.

Note 3: A grouping of assets referred to as an asset system could also be considered as an asset.

Note 4: An asset can also be a configuration item. Some configuration items are not assets.

Business Process

• a collection of related, structured activities or tasks performed by people or equipment in which a specific sequence produces a service or product (that serves a particular business goal) for a particular customer or customers. Source

Note 1: Processes are the structure by which an organisation does what is necessary to produce value for its customers, partners and employees. A business process begins with a mission or business objective and ends with achievement of the business objective.

Note 2: Business processes can be categorised into:

• Strategic processes, which are managerial, directive or steering processes.

• Operational processes, which generate products or services to be delivered to customers. 

• Support processes, which support the operational and strategic processes.

Note 3: Each business process has a process owner (i.e., the person responsible for the continuous improvement of the process). The process owner may be the same or different from the one, who performs the process.

Industrial Process

• operational process that is carried out using operations technology (OT), Industrial Internet of Things (IIoT), Industrial Control Systems (ICS) and/ or Industrial Automation and Control Systems (IACS).

Business impact analysis (ISO/IEC 27031:2011)

• process of analysing operational functions and the effect that a disruption might have upon them.

Acquirer

• critical sector entities, central agencies and others, who acquire a System for their use.

Note 1: Some acquirers may carry out all the System lifecycle related activities in-house, using their own teams or contracted personnel. Often, the acquirers get the System delivered, installed, commissioned and supported by third-parties, and have a project management team to oversees all the project related activities.

Original Equipment Manufacturer (OEM)

• an organisation that “owns” or “holds in custody” the design and code of the hardware, appliances and software products. They are responsible for the product maintenance, updates and upgrades.

OEM provided Advanced Services

• different types of professional services provided by the OEMs directly for their products.

Note 1: Most OEMs provide professional services of an advanced nature directly using OEM’s own teams for the type of work that may be beyond the competence or credibility levels of Partners and Resellers.

Authorized Professional Services

• different types of professional services provided by the OEM Partners or Reselers for the OEM products.

Note 1: Typically, repetitive services such as installation & commissioning, Level 1 and Level 2 support are delivered by the OEM’s Partners or Resellers, based on training and competency certification given by the OEM.

Authorized Partners

• organisations, who have been authorised by the OEM to supply the OEM products and/ or provide various services related to the OEM SKUs, such as, installation & commissioning, operations & maintenance support services.

Note 1: OEM(s) develop and manage their partner ecosystem.

Authorized Resellers/ Distributors

• organisations, who have been authorised by the OEM to sell and deliver the OEM SKUs to the Acquirers.

Note 1: Usually these organisations do not provide any installation & commissioning, operations & maintenance support services. OEM(s) develop and manage their own reseller/ distributor ecosystem.

Cloud Service Provider (CSP)

• provides the infrastructure and platforms (IaaS, PaaS) for hosting a System on a public, private, government community cloud.

Internet Service Provider (ISP)

• provides basic network (IP) connectivity between different locations, such as CSEs, Central Agencies, CSP datacentres etc. In addition, they may also provide services, such as DDoS mitigation, site-to-site VPNs, etc.

Subscription Service Provider (SSP)

• provides various subscription services, such as domain registration and management, DNS, CASB, Cloud-based identity and Zero Trust, SSL/ SSH certificate management, etc.

System Integrators (SI)

• organisations, who usually front-end the bidding, contracting, delivery and support of turnkey projects of the Acquirers. They may themselves be Authorized Partners or may engage and work with the OEMs, OEM Partners, Authorized Resellers/ Distributors, CSPs, ISPs, SSPs etc, for delivery of the System.

Managed Services Provider (MSP), Managed Security Services Provider (MSSP)

• organisations, who provide services for operating, managing and securing the Acquirers’ IT and OT during the operating phase.

Technology Terms

Asset

• see here

Communication Device (ITAA-2008)

• Cell Phones, Personal Digital Assistance (Sic), or combination of both or any other device used to communicate, send or transmit any text, video, audio, or image.

Computer (ITAA-2008)

• any electronic, magnetic, optical or other high-speed data processing device or system which performs logical, arithmetic, and memory functions by manipulations of electronic, magnetic or optical impulses, and includes all input, output, processing, storage, computer software, or communication facilities which are connected or related to the computer in a computer system or computer network.

Note: The definition is also applied to OT and IIoT devices having programmable or upgradable software or firmware, such as i) PLCs, RTUs etc, and ii) CCTV cameras, smartcard and biometric readers etc.

Computer Network (ITAA-2008)

• the interconnection of one or more Computers or Computer systems or Communication device through i) the use of satellite, microwave, terrestrial line, wire, wireless or other communication media; and ii) terminals or a complex consisting of two or more interconnected computers or communication device whether or not the interconnection is continuously maintained.

Computer Resource (ITAA-2008)

• computer, communication device, computer system, computer network, data, computer database or software.

Note1: The term ‘Resource’ is also used, when there is no ambiguity that it refers to computer resource.

Note 2: The term is explicitly used for information technology (IT) elements and implicitly for describing elements of operations technology (OT) and Internet of Things (IoT). Alternative terms for OT OT elements the ICS elements. Further the word ICS also includes operations technology (OT) and IACS elements. At places where required, the terms OT and IACS are explicitly defined.

Computer System (ITAA-2008)

• a device or collection of devices, including input and output support devices and excluding calculators which are not programmable and capable of being used in conjunction with external files, which contain computer programmes, electronic instructions, input data, and output data, that performs logic, arithmetic, data storage and retrieval, communication control and other functions.

Note: The definition is also applied to OT and IIoT systems having programmable or upgradable OT and IIoT devices, such as i) SCADA, DCS etc, and ii) smart grid technologies, such as automatic meter infrastructure etc.

Configuration Item CI

• element that requires to be controlled in order to deliver a service(s).

Note 1: Every IT, OT, IIoT or cybersecurity asset that is in-use within the information infrastructure has to be configured, managed, and protected while it is in-use. The in-use asset is termed as a Configuration Item.

Cyber incident (G.S.R 20(E), 16 Jan 2014)

• any real or suspected adverse event that is likely to cause or causes an offence or contravention, harm to critical functions and services across the public and private sectors by impairing the confidentiality, integrity, or availability of electronic information, systems, services or networks resulting in unauthorised access, denial of service or disruption, unauthorised use of a computer resource, changes to data or information without authorisation; or threatens public safety, undermines public confidence, have a negative effect on the national economy, or diminishes the security posture of the nation.

Cyber security incident (G.S.R 20(E), 16 Jan 2014)

• any real or suspected adverse event in relation to cyber security that violates an explicitly or implicitly applicable security policy resulting in unauthorized access, denial of service or disruption, unauthorised use of a computer resource for processing or storage of information or changes to data, information without authorisation.

Cybersecurity breach (G.S.R 20(E), 16 Jan 2014)

• unauthorised acquisition or unauthorised use by a person as well as an entity of data or information that compromises the confidentiality, integrity or availability of information maintained in a computer resource.

Data (ITAA-2008)

• a representation of information, knowledge, facts, concepts, or instructions which are being prepared or have been prepared in a formalized manner, and is intended to be processed, is being processed or has been processed in a computer system or computer network. ,.and may be in any form (including computer printouts magnetic or optical storage media, punched cards, punched tapes) or stored internally in the memory of the computer.

Defence in depth

• the provision of multiple security protections, particularly in layers, with the intention to delay if not prevent an attack.

Note 1: This approach involves multiple security measures, including detection systems, to challenge attackers at every layer, mitigate weaknesses in any single layer, and integrate system security into the broader network security architecture.

Information (ITAA-2008)

• includes data, message, text, images, sound, voice, codes, computer programmes, software and databases or microfilm or computer-generated micro fiche.

Information infrastructure

• conglomeration of all computer resources of an entity or a group of entities, viz, include systems, networks, applications, databases, information along with associated user and machine identities.

Note 1: This term is derived from the ITAA-2008 definitions of ‘computer resources’ and ‘critical information infrastructure’ and the term ‘federated digital ecosystem’ in this documentation.

Note 2: The term can also be used in a larger context that includes

• the technical practices and processes to configure, administer, manage, secure and maintain the conglomeration of computer resources.
• the composite workforce that carries out the technical practices and processes.

Information security incident

• an isolated or series of unwanted information security events with a significant likelihood of jeopardizing business operations and information security.

Root of Trust (NIST)

• highly reliable hardware, firmware, and software components that perform specific, critical security functions.

• a starting point that is implicitly trusted.

Security operation

• activities and functions aimed at protecting individuals and safeguarding tangible and intangible assets.

Security operations management

• the organized activities that guide and oversee an organization’s security operations.

Note 1: This typically involves formulating policies, setting objectives, planning operational processes, and fostering continuous improvement.

Security operations programme

• a continuous management and governance initiative, backed by senior leadership and adequately resourced, to ensure coordinated action towards meeting the goals of the security operations management system.

Security threat scenario

• a potential sequence of events that could lead to a security incident.

Threat action

• an attack on system security.

Threat agent

• the entity responsible for initiating a threat action.

Threat analysis

• the process of identifying and assessing the potential sources of harm and their possible impact.

Vulnerability analysis

• the process of identifying and measuring weaknesses that could be exploited by threats.

Vulnerability assessment

• the systematic evaluation and quantification of vulnerabilities.

Other Terms

Indian Regulations

Regulated entities (Reserve Bank of India (RBI))

• financial institutions such as commercial banks, non-banking financial companies (NBFCs), and credit information companies that are subject to RBI’s guidelines to ensure stability, transparency, and customer protection in the financial sector.

Regulated entities (Securities and Exchange Board of India (SEBI))

• financial institutions and organizations that operate under the supervision of SEBI. These entities must comply with specific regulations set forth by SEBI to ensure market integrity and protect investors.

Responsible entities (Central Electricity Authority (CEA))

• power sector entities deploying Operational Technologies with or without IT systems, including Generating companies including the captive plants, Renewable Energy Sources, Energy Storage System, Transmission Licensees including deemed transmission licensee, Distribution Licensees, National Load Dispatch Centre, Regional Load Dispatch Centers, State Load Dispatch Centers, Control Centers of distribution licensee, Central Transmission Utility, State Transmission Utilities, and Renewable Energy Management Centers, forecasting service provider, Traders, Power Exchanges, Qualified Coordinating Agencies.

Note: Responsible entities serve various roles in the power sector and are sector participants with significant exposure to cyber threats.

Authorised entities (Department of Telecom (DoT))

• a person holding an authorisation for
  • providing telecommunication services;
  • establishing, operating, maintaining or expanding telecommunication networks; or
  • possessing radio equipment.

NCIIPC-QCI Conformity Assessment Framework

The following terms are defined in the NCIIPC-QCI Conformity Assessment Framework and are to be read in line with the definitions notified in IS/ISO/IEC 27000 and its family of standards.

Accreditation

• third-party attestation related to a conformity assessment body conveying formal demonstration of its competence to carry out specific conformity assessment tasks.

Accreditation Body

• authoritative body that performs accreditation. The authority of an accreditation body can be derived from government, public authorities, contracts, market acceptance or Scheme owners.

Assessment

• process that evaluates a person’s fulfilment of the requirements of the Scheme.

Attest

• process that confirms the conformance of the entity and individual certified, inspected, accredited, or approved.

Attestation

• issue of a statement, based on a decision following review, that fulfilment of specified requirements has been demonstrated. The resulting statement, referred to in this Standard as a “statement of conformity”, conveys the assurance that the specified requirements have been fulfilled. Such an assurance does not, of itself, afford contractual or other legal guarantees. First-party and third-party attestation activities are distinguished by the terms. For second-party attestation, no special term is available.

Certificate

• document issued by a certification body under the provisions of this Standard, indicating that the named person has fulfilled the certification requirements.

Certification

• third-party attestation related to products, processes, systems or persons. Certification of a management system is some- times also called registration. Certification is applicable to all objects of conformity assessment except for conformity assessment bodies themselves, to which accreditation is applicable.

Conformity assessment

• demonstration that specified requirements are fulfilled. Conformity Assessment includes activities, such as but not limited to testing, inspection, validation, verification, certification, and accreditation.

Conformity Assessment Body

• body that performs conformity assessment activities, excluding accreditation. The CAF includes following conformity assessment bodies:
  • Certification Body (CB)
  • Inspection Body (IB)
  • Certification Body for Persons (PrCB)

Conformity Assessment Framework

• structure of processes and specifications, related to conformity assessment system, designed to support the accomplishment of a specific task. There are various conformity assessment Schemes that can be used to determine whether specified requirements are fulfilled, they include but are not limited to inspection, evaluation, audit of management system etc. In a framework, these conformity assessment Schemes / system share common vocabulary, principles and family of standards which ensure interoperability of various Schemes.

Conformity Assessment System

• set of rules and procedures for the management of similar or related conformity assessment schemes. A conformity assessment system can be operated at an international, regional, national, sub-national, or industry sector level.

Conformity Assessment Scheme

• set of rules and procedures that describes the objects of conformity assessment identifies the specified requirements and provides the methodology for performing conformity assessment. A Scheme can be managed within a conformity assessment system. A scheme can be operated at an international, regional, national, sub-national, or industry sector level. A Scheme can cover all or part of the conformity assessment functions.

Inspection

• examining a product’s design, the product itself, or an installation to determine its conformity with specific requirements. This determination is made either through adherence to explicit criteria or, when professional judgment is applied, in accordance with general conditions.

Object of conformity assessment

• entity to which specified requirements apply.

Example: product, process, service, system, installation, project, data, design, material, claim, person, body or organisation, or any combination thereof. The term “body” is used in this framework to refer to conformity assessment bodies and accreditation bodies. The term “organisation” is used in its general meaning and may include bodies according to the context.

Scope of attestation

• range or characteristics of objects of conformity assessment covered by attestation.

Surveillance

• systematic iteration of conformity assessment activities as a basis for maintaining the validity of the statement of conformity.

Suspension

• temporary invalidation of the statement of conformity for all or part of the specified scope of attestation.

Withdrawal

• revocation, cancellation of the statement of conformity appeal request by the provider of the object of conformity assessment to the conformity assessment body or accreditation body for reconsideration by that body of a decision it has made relating to that object.