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.