A Practical Approach to CERT-In 70B Compliance

cert in 70b regulation

Jump to section

Share this post:

Share on twitter
Share on linkedin

CERT (Computer Emergency Response Team) India is a national nodal agency that’s been around since 2004 and responsible for responding to cyber security incidents as they occur.

India has faced an increasing level of cyber attacks over the last few years. 

In fact, according to an article by Business Standard, India is among the top 3 most affected nations with respect to cyber attacks.

On 28-Apr-2022 the CERT-In team has released a set of guidelines to further strengthen incident response measures implemented by public and private sector organisations. Organisations and government bodies would require to comply with these within 60 days.

With this post, we intend to break down these guidelines and provide a practical approach towards complying with them.

Who does it apply to?

The CERT-In 70B directive applies to any service provider, intermediary, data centre, body corporate and government organisation. 
We’ll refer to these as “entities” in the remaining post.

What is the CERT-In 70B directive?

First up, let’s look at what those guidelines call out.

Clock Synchronisation

Entities would be required to connect to the Network Time Protocol (NTP) Server of National Informatics Centre (NIC) or National Physical Laboratory (NPL) or with NTP servers traceable to these NTP servers, for synchronisation of all their ICT systems clocks. Entities having ICT infrastructure spanning multiple geographies may also use accurate and standard time source other than NPL and NIC, however it is to be ensured that their time source shall not deviate from NPL and NIC.

Incident Reporting Timeline

Entities shall mandatorily report cyber incidents to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents. The incidents can be reported to CERT-In via email, phone or fax. The format for reporting incidents is available at the CERT-In website here.

The type of incidents that need to be reported include targeted scanning / probing of critical systems or networks, compromise of critical systems or networks, defacement or intrusion into a website, data breach, data leak, attacks or suspicious attacks on cloud infrastructure, among others. The complete list can be found in the Annexure I of the directive here.

Log Retention

Entities would be required to securely retain logs of their information systems for a rolling period of 180 days within the Indian jurisdiction. These logs would need to be provided to CERT-In along with the incident being reported or when directed by CERT-In.

Maintain User Information for Infrastructure Providers

Data Centres, Virtual Private Server (VPS) providers, Virtual Private Network (VPN) providers and Cloud Service providers would require to maintain information on subscribers and customers for a period of 5 years or longer as mandated by law after cancellation or withdraw of service.

KYC Information for Virtual Assets, Exchanges and Wallets

Organisations falling in this category would need to maintain all KYC (know your customer) and records of financial transactions for a period of 5 years.

Further details of the directive can be found here.

Complying with the CERT-In 70B Directive

Now that we’ve discussed what the directive is all about, let’s look at how organisations can go about addressing its requirements in a practical manner.

The below project outline would help achieve this piece by piece. 

Step 1 – Identify & Prioritise Event Sources

Before dealing with cyber incidents, organisations need to comprehensively define what their adversaries are; how to detect and respond to them in the most efficient manner. Logs or system / application events are key to this detection process. Looking at Annexure I of the CERT-In directive, one can easily identify the systems or applications that need to be prioritised from a threat detection perspective. Some of these sources are listed as under:

  1. Active Directories
  2. End User Systems
  3. Servers
  4. Databases
  5. Anti-malware
  6. Public Cloud Activity

One of our articles on logging best practices provides further insights from a public cloud perspective. However, the same underlying thought process can be applied to other environments.

Compliance Tip: 

  1. Ensure application logs are not left out from the list
  2. Update source NTP settings in the identified sources point to NIC or NPL as directed by CERT-In
Step 2 – Integrate
Once we have a list of devices or sources that need to be integrated, the next step is to integrate these into an SIEM platform. In case an organisation already has an SIEM implemented, one would need to review the existing sources, carry out a gap analysis with the list in step 1 above, and plan on integrating the ones left out.
In case an SIEM is not yet deployed, organisations can choose from commercial or open source SIEM platforms depending on their need. 

Compliance Tip: Ensure log retention is set to 180 days as per the CERT-In directive.

Step 3 – Threat Detection

The most crucial next step is to actually detect threats that matter. Organisations should start with a threat landscape assessment to understand their adversaries, risk to information assets and current mitigation methods. 
Once this is done, the idea should be to convert the threat landscape assessment into use cases. Shown below, is an example of one such use case around account “port probing”.
Before we jump into the use case, let’s understand what port probing actually is. 
Port probing or network scanning is an essential step in initial reconnaissance, a tactic that attackers use to test find open services on a network or IP address. Once open services have been identified, further attack strategies can be applied. For instance, in case an HTTP port is found open, attackers can try the log4j vulnerability.
Awesome, now let’s get further into how we could map the “port probing” threat to its use case and subsequently, log sources. For this, let’s assume an organisation has its workload running in a local data centre and AWS.

Step 4 – The Process

We have some use cases running and alerts churning out of an SIEM platform, great! 
But that’s not it.
The final step is sustainable operations, by getting answers to these questions:
  1. How do we prioritise alerts?
  2. Who should action on them and how quickly?
  3. What is our incident management strategy?
  4. Do we need to contact regulatory authorities?
Establishing processes around incident management and response are key to fighting adversaries in a sustainable, repeatable manner. 
Organisations should invest in manpower, ticketing systems, smart alerting tools to increase productivity of SOC teams resulting in efficient operations. We’ll can probably write another post on this subject!

Compliance Tip: Ensure timelines for incident reporting is defined as 6 hours as per the CERT-In directive


The CERT-In 70B directive is a much needed step to elevate levels of enterprise and national security. It is in an organisation’s best interests to comply with these since it significantly helps create a robust incident detection and response program.  Cy5’s Cloud Native SIEM helps accelerate this journey by easing out deployment efforts and reducing the time to value by implementing pre-built use cases that are necessary to comply with the CERT-In 70B directive.
We hope the post was helpful in understanding the CERT-In 70B directive and ways to meet its compliance.