In the second edition of CyberInsights LongReads, we delve into the controversial CERT-In guidelines. We try to remove the hullabaloo around it and focus on what you need to do as a cybersecurity leader in your firm.
Know someone who might find this useful? Share it with them:
Imagine this:
You are a private limited company going about your business in peace. One day, you find that one of your ex employees, who somehow still had access to your company’s LinkedIn administrator page, posts from the page that a competitor is much better than your company. You are understandably peeved. You set about removing the post and then removing the misbehaving gentleman from the company admin page. Your PR team writes a post that makes a joke of this and manages to salvage the situation.
Smack in the middle of this, you realise that as per the directions issued by the government of India, you have to report this to CERT-In (Indian Computer Emergency Response Team) within 6 hours of the incident. You do not know if this qualifies as an incident that nation states would be interested in, but you want to be squeaky clean. So, you read up the directive to see if this qualifies as an incident. As you scroll through it, you come across guideline iii.) Unauthorised access of IT systems / data. You consider it for a bit and think - this is not unauthorised access. This person had legitimate access. His access was not removed in time, making it unauthorised. Not worth reporting. But then you casually scroll to point number xvii.) Unauthorised access to social media accounts. This is a thin line, you think. You decide to report the incident to CERT-In. You fill up the form and then send it across to CERT.
By the time you send it, you realise it was the next day. More than the stipulated 6 hours.
Oh no!
The CERT-In Direction
On the 28th of April, 2022, the Government of India, released the “Directions under sub-section (6) of section 70B of the Information Technology Act, 2000 relating to information security practices, procedure, prevention, response and reporting of cyber incidents for Safe & Trusted Internet.” These are directions to report incidents to CERT-In.
To be able to report incidents accurately, the directions have certain pre-requisites:
The systems used by entities should synchronise time by connecting to the NTP (Network Time Protocol) servers of NIC (National Informatics Limited) or NPL (National Physical Laboratories). If you connect to another NTP server, the time should not deviate from the NIC / NPL servers. You can learn how to sync your systems with NPL here. The timeserver by NPL is at time.nplindia.org.
Mandatorily report cyber incidents within 6 hours of noticing the incident.
CERT-In can ask you for information in ‘near real time’. You would have to send it to them in the time frame that they request it in.
You will enable logs for all systems and maintain them securely for a rolling period of 180 days. You should provide these logs along with the incident report to CERT-In or when asked for.
If you are any of the following, a data centre, a provider of virtual private servers, a cloud service provider or a VPN service provider, then you maintain a records for 5 years, including KYC of the user. (The VPN bit is a hotly debated topic in the cybersecurity community right now. The debate is again around privacy vs. national security)
For those who provide virtual assets, provide virtual asset exchanges, custodian wallets (psst… you crypto guys), you have to maintain the KYC of people who use your services.
If you do not follow the directions, you can face punitive action under sub-section 7 of section 70B of the IT act, 2000
These directions will be effective from June 27th, 2022.
What about NCIIPC, then?
If you are an organisation that is a part of the National Critical Information Infrastructure, then you have to also report incidents to the National Critical Information Infrastructure Protection Centre (NCIIPC). They have fairly simple guidelines that you can access here. NCIIPC too asks for your logs. Too many entities out to get your logs?
The incidents
Well, what is an incident, really? It could be anything. You could define an incident the way you like it. Not in this case! CERT-In gives you 20 incidents that you must report. These 20 incidents are comprehensive, but are also open to interpretation. Read this section carefully and form your own internal guideline for incident reporting to CERT-In. I have put in my explanation in the description. Please note that the explanations are not from CERT-In, but my interpretations.
1. Targeted scanning / probing of critical networks/systems
The word ‘targeted’ makes this confusing. How can we distinguish between targeted scanning vs. general scanning? SOC teams know that scanning attempts detected with alarming regularity for internet facing systems. Should all of them be reported? The prudent thing is to follow the spirit of the requirement rather than the letter. If you recognise repeated scanning or scanning of key systems and after investigation find that it restricted only to your systems, then report it as an incident.
2. Compromise of critical systems/information
You only have to worry about defining ‘compromise’. Use your judgement to decide if a system has been compromised. If an external perpetrator gains access to critical systems or information, it is compromised. In all other cases, internal exposure of data, policy violations not leading to public compromise, etc. can be defined as not compromised.
3. Unauthorised access of IT systems/data
The term ‘unauthorised’ is very broad. While deciding if any unauthorised access is worth reporting to CERT-In, you should consider the following:
Did the unauthorised access lead to data compromise?
Did the unauthorised access happen on critical system?
Is the individual responsible for the unauthorised access unknown?
Are the consequences of this unauthorised access unknown?
If you have answered ‘yes’ to any of these questions, then report the incident.
If you have a doubt, then report the incident.
4. Defacement of website or intrusion into a website and unauthorised changes such as inserting malicious code, links to external websites etc.
This is straight forward. The guidelines are very clear on what to report.
To split hair, what would you do if the iframe you are using from a payment vendor has been compromised. Should you report it? Or is it the responsibility of the payment vendor?
5. Malicious code attacks such as spreading of Virus/ Worm/ Trojan/ Bots/ Spyware/ Ransomware/ Cryptominers
Here, you should use judgement again. If your AV has detected and blocked one malware, then it would not be an incident to report.
If the virus infected just one system and your team managed to contain it, should it be reported? In most cases, no.
The guideline is, however, unclear in such cases. Keeping in the spirit of the requirement, you should report incidents where there is impact to business (business operations are halted, data unavailable, etc.) and demand for ransom - even if you decide to restore from backup and never pay the ransom.
6. Attack on servers such as Database, Mail and DNS and network devices such as Routers
If you host your own databases, DNS servers or mail servers, then use 1, 2 and 3 above to decide if an incident on this infrastructure should be reported. In case you do not host your own systems (your ISP does your DNS, you use cloud based systems, etc.) and you detect an incident, drop a line to the service provider to report the incident.
In case of your own edge devices such as routers, firewalls, load balancers, etc., you can ignore regular scans (those hundreds of port scans that you see regularly). Report case there are attempts to use exploits. What might be of interest to CERT-In would be cases DoS and DDoS attacks (see 8 below). Even if DoS and DDoS incidents have been thwarted, report them.
7. Identity Theft, spoofing and phishing attacks
Interpret identity theft as stolen identities for your organisation as well as stolen identities for key leadership teams in your organisation. It would be wise to issue guidelines internally to your infosec team to keep track of key identities.
Spoofing and phishing attacks on your organisation should be reported directly.
8. Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks
Any DoS or DDoS attack should be reported as an incident to CERT-In
9. Attacks on Critical infrastructure, SCADA and operational technology systems and Wireless networks
For critical infrastructure, refer to point 2. If you have critical operational technology infrastructure, then you can also refer to the NCIIPC guidelines for securing OT.
NCIIPC has information security guidelines as well as incident response guidelines.
Update your existing incident response procedures to ensure compliance to both the CERT-In directions and the NCIIPC guidelines.
10. Attacks on Application such as E-Governance, E-Commerce etc.
Use, 1, 2, 3 and 5 above to decide on reporting attacks on key e-governance and e-commerce platforms.
11. Data Breach
Data breach appears to be a special case of 2 - ‘compromise of critical systems / information’. So, no special discussions here.
12. Data Leak
Data leaks are tricky. You can detect an incident, but it is not easy to detect a data leak. A data leak is mostly revealed to you by a third party - someone reports your organisation’s data is available for sale on the dark web, or you realise that your competition is able to predict your moves and respond easily.
CERT-In expects you to report a data leak once it come to your notice.
It might be difficult to gauge if there is a genuine data leak (unless it is through the logs of your own systems). Again use your discretion.
13. Attacks on Internet of Things (IoT) devices and associated systems, networks, software, servers
This is similar to 9, but extends the definition of OT to include IoT devices as well. All the ‘smart’ manufacturers should report attacks their ecosystem.
There is a grey area here. If you manufacture, say, smart light bulbs. A vulnerability is discovered and is exploited at a user’s end. The user does not complain to you, but the information reaches you via news reports. Do you report it?
Keeping in the spirit of the directive, you would have to report it.
14. Attacks or incident affecting Digital Payment systems
This talks about 1, 2, 3, 5, 8 and 10 above applied to digital payment systems. Redundant, because these systems would be critical anyway.
15. Attacks through Malicious mobile Apps
This is just a description of an attack vector. The incident will come from the earlier points.
16. Fake mobile apps
Again, a repeat of the above point 15.
17. Unauthorised access to social media accounts
Expand this to include not just the company social media accounts, but also social media accounts of key personnel in the organisation. Use similar judgement as ‘identity theft’ above.
18. Attacks or malicious/ suspicious activities affecting Cloud computing systems/ servers/ software/ applications
This is for those using cloud based assets. The challenge here is, how do you know if a cloud service provider has faced a breach? Unless they decide to report it to you.
You could, of course, have agreements that mandate disclosure, but those will be subject to the same subjectivities that are a part of this CERT-In guideline.
Ensure that your cloud agreement caters to this point.
19. Attacks or malicious/suspicious activities affecting systems/ servers/ networks/ software/ applications related to Big Data, Block chain, virtual assets, virtual asset exchanges, custodian wallets, Robotics, 3D and 4D Printing, additive manufacturing, Drones
Yet another list of assets…
20. Attacks or malicious/ suspicious activities affecting systems/ servers/software/ applications related to Artificial Intelligence and Machine Learning
Yet another list of assets…
What you should be doing…
The guidelines will be effective from June 27, 2022.
Before the date, you would have to do at least the following:
Identify key systems in your organisation. If you have done a formal risk assessment, the critical assets from there should suffice to take forward.
Ensure all of them have logging enabled.
Ensure that your NTP is in sync with the CERT-In requirements. If you have servers across geographies, this might be a tough ask. Your server infra team would be in a better position to figure out a way.
Check the storage for logs. Are they being overwritten before the 180 day period? If so, increase log storage.
Review your incident response process. Update to include the following:
SPOC to communicate with CERT-In
Trigger for informing CERT-In
Decision pointers for informing CERT-In
Decision makers involved in making the decision for informing
List of submissions to be made to CERT-In
Acknowledgement receipt and record keeping process
Consider NCIIPC and other regulatory reporting guidelines as well
Draft a set of guidelines on types of incidents to report based in the 20 points of CERT-In. Try to clarify things as much as possible so that on ground teams can triage incidents quickly and cleanly.
Stay away from the privacy debate around VPN services 😈
CyberInsights LongReads is a part of CyberInsights and delves into one topic in detail each month. If you like what you are reading, you can subscribe to get LongReads in your email. Just remember to check your spam in case you do not receive these mails.