Introduction
Cyber security has always been a hot topic area and it’s gaining momentum by leaps and bounds these days (which is great for information security professionals like us 😀 ). In all seriousness, “Data is the new Oil” and there are criminal agencies operating worldwide with impunity that harvest user data and sell it or use it for malicious/financial gain.
CERT-In (under MeitY, Govt of India) has recently issued a much needed and welcome set of directives aimed at enhancing the security profile of organisations operating within the Indian jurisdiction. Interestingly, many of these directives are not new and have been referenced in other regulations and compliance standards such as Indian IT Act, PCI-DSS, ISO-27001, etc.
There is a lot of buzz within the media regarding the implementation time frame, data privacy, implementation cost, market impact and others, making it look impractical to implement, and unrealistic in expectation which may not be entirely true.
Let’s evaluate each clause within the CERT-In directives from a feasibility perspective and examine the pros and cons as well.
Disclaimer
The contents of this article are being dissected only from a technical deployment standpoint.
Not being part of the Indian legal fraternity, it would be inappropriate to comment on the CERT-In directives from a contractual, legal angle.
Understanding the Directives
Directive 1: Regarding NTP Syncing
Time syncing has been a crucial component (for many years) within SOC to triage an incident and determine root cause. This is termed as correlation and is performed by log analysis and is a critical component of incident investigation.
It should be noted that logs are acceptable evidence in any court of law. Thus, timestamped logs are absolutely necessary and the importance of having clock synchronisation cannot be overlooked. Maintain chain of custody for logs to ensure log integrity is preserved for forensic purposes.
Time syncing requirement maps to:
– CIS: Clause 8.4
– ISO-27001-2013: Clause A.12.4.4
– PCI v4: Clause 10.6
– NIST 800-53 Rev5: SC-45 under 3.18
Mandating everyone to sync with NPL/NIC clocks needs some clarifications around:
1. Entities operating across multiple geographies.
2. Handling entity parent-child relationships.
3. Alternatives to using NPL/NIC.
CERT-in has clarified in the subsequent FAQ’s that other NTP servers can be used provided time accuracy is maintained. This has created unnecessary confusion. It is recommended that CERT-In provide a list of globally trusted NTP servers and mandated a sync with any/few of them.
How easy is this to implement? Easy.
When using a cloud environment, don’t bother since cloud providers will do this natively. Most corporations can sync their internal NTP server with NPL/NIC and use that across their infrastructure. Setting up an internal NTP server is also not a very difficult project.
Directive 2: About reporting cyber security incident within 6 hour
It has generated a lot of media buzz regarding the notification timeframe. This is largely due to interpretation ambiguity arising from “report a security incident within 6 hours”.
First of all, we can all agree that it is not practically possible to identify & classify an incident, collect evidence, and report it in 6 hours even after extensive usage of automation, alerting, and reporting mechanisms.
But please note that the directive mentions incident reporting and not alert reporting. So for all practical reasons, the timer starts when an alert is classified as a security incident AND appropriate verification has been performed.
As per provisions in IT Rules, 2013, rule 12(1)(a) pertaining to Reporting of Incidents: The mandatory reporting of cyber security incidents is reportable as early as possible, so in this case CERT-In is putting a number to the word “as soon as possible”. Also noteworthy that RBI has already mandated banks to report within 2 to 6 hours.
Furthermore, the security incident identified should be categorised under one of the 20 types as identified in Annexure A of the CERT-In directive, we’ll look at those separately
Let’s step-through a basic incident management process:
1. SOC infrastructure alerts SOC operators based on detection/protection rules which can be derived from the machine learning model.
2. SOC team completes basic triage as defined in the SLA.
3. Triage classifies the incident as a security incident or a false positive
4. Triage applies a severity rating (e.g. Severe, High, Med, Low) to the security incident.
5. Appropriate activities described in the incident response plan are executed.
6. Relevant logs are collected and saved as investigative evidence.
7. Reports are generated.
8. Information about the security incident is distributed to appropriate stakeholders, users, customers, vendors, regulatory bodies, law enforcement as the case may be.
Here’s a different interpretation of the 6-hour time frame:
Step 1-6 can take time (maybe a few hours or even a few days). It’s possible during investigation an incident can be downgraded to lower severity. Publishing false positive information can cause panic, financial loss, and reputation damage if unverified incidents are reported. However, once the relevant data has been collected and it has been safely determined by internal processes that the incident was in fact a security incident resulting in breach, leak or any of the 20 parameters given in the CERT-In directive appendix, then reporting this within 6 hours is very easily do-able.
How easy is this to implement? Not trivial.
In case you have a SOC or some monitoring methodology, please make sure the correct use-cases are being monitored. Also fine tune your runbooks to make sure reporting to CERT-in is included in your process. In case you don’t have any monitoring infrastructure, this is going to be difficult and financially stressing to set up one but is highly recommended.
Directive 3: Regarding assistance with investigation
Providing assistance during investigation is nothing new again. This is a reiteration of IT Rules, 2013 Rule 14. It is expected for any citizen of India or business entity operating within the Indian jurisdiction to assist law enforcement, regulatory bodies and other related stakeholders during an investigation.
At this point, each organisation should develop processes to securely export the logs (in tamperproof way) and other data relevant for the investigation to the concerned authorities within stipulated time frames.
If the individual or business entity cannot provide necessary evidence, then it only increases the stress and resources needed to assist with the investigation or prove innocence.
Directive 4: 180 days Log Retention for all ICT logs
As per various studies conducted on intrusions, it has been observed that attackers infiltrate a network more than 100 days before the attack actually gets identified. Here, detection, investigation and root cause analysis needs a minimum 6 months of log data.
Log retention is a long standing requirement of most regulation and compliance checklists like
NIST 800-53 Rev 5: AU-2 and many more. Time frame of log retention should always follow the law of the land and applied regulations.
This is a key pillar in the risk management and incident management space. The directive by CERT-In and the subsequent FAQs clarifies that important logs such as Firewall logs, Intrusion Prevention Systems logs, SIEM logs, web/ database/ mail/ FTP/ Proxy server logs, event logs of critical systems, application logs, ATM switch logs, SSH logs, VPN logs etc should be maintained.
There is still an ambiguity regarding the following:
Are endpoint logs also needed? E.g. (laptop, desktop, mobile, tablets etc)
What logs are to be collected, will antivirus or similar control logs suffice?
Will endpoint security logs suffice?
Are transaction, activity, and application logs needed?
Including “all ICT logs” in the directive can strain log collection, processing, storage, archival processes. This could increase data storage service costs and infrastructure. Smaller businesses might not be able to afford a sudden infrastructure operational expense.
Most network devices and systems store logs between 7 to 30 days. Beyond this, businesses might have to leverage some form of SOC/ SIEM implementation. Incident root cause determination requires access to multiple log sources. This can cause operational expenses to shoot up considerably.
Additional expertise might be needed for automated log management, alerting, and reporting mechanisms.
What if a company does not have a log collection and monitoring setup?
It’s true that not all entities have the financial ability to set up and manage a SOC or SIEM environment. In this situation, they might have some security controls such as anti-virus, firewall etc, but will not have the ability to investigate a cyber security incident.
In worse case situations, they will not be able to prove their innocence if the cyber security incident includes serious offences such as child pornography, terrorism, cyber-bullying, malware propagation etc. that originates or pivots from their IT environment
For anyone saying that such situations cannot happen, it is only a matter of time before they are victims to it.
How easy is this to implement? Easy.
If security controls around log collection, management, monitoring, alerting, and reporting are not implemented, it is highly recommended that this process be initiated at the earliest.
To comply with this directive, we agree that there will be requirements for additional storage to retain logs for 180 days. It will most certainly add to an entity’s operational expense.
Directive 5: VPS/VPN providers to retain subscriber information
VPN/VPS providers with infrastructure here in India will be required to maintain subscriber information for 5 years. This has created a pain point for VPN/VPS services since their USP is user/ data privacy. With their USP gone, the providers can no longer guarantee users that their services will obfuscate user network traffic or user information.
Subsequently, some VPN providers have in fact decided to pull their services from India.
Stored logs are also data and when confidentiality and integrity of the logs are not maintained properly these exposed logs itself could provide information for an attacker.
CERT-IN needs to provide guidance on:
– Secure log storage
– Secure log export (when needed) to CERT-in agencies
Sending breach data (e.g. logs, reports etc.) via email should be discontinued as a practice since it contains sensitive information.
Let’s now take a step back and understand who the users are and how does it affect their privacy? Primarily from a privacy standpoint, a VPN tunnel is leveraged by someone who wants to protect their data and/or identity. These constitute privacy enthusiasts, journalists, whistleblowers, but may extend to fraudsters, and terrorists as well.
A lot of fraud/crime activities are generally performed via VPN services and investigation agencies cannot pinpoint the perpetrators. Under these circumstances, the Govt of India and other investigative agencies can request data from the VPN/VPS provider to determine such activities that go against national security interests. Although a matter of debate, it is important to place national security above privacy.
How easy is this to implement? May not be easy.
VPN/VPS providers will have to store their user data securely and apply processes and deploy technology for the same. A lot of other regulatory as well as non regulatory compliance overheads will be added. Goes without saying, user privacy related business decisions would be a difficult one at this stage.
Directive 6: Financial records / KYC information to be maintained.
Let’s try to understand why this is important. KYC data is needed when fraud happens and the perpetrator has to be identified. This has been a common ask since long by various regulators:
– RBI Directions 2016
– SEBI circular dated April 24, 2020
– Department of Telecom (DoT) notice September 21, 2021
– Even PCI-DSS says at least 1 year but the law of land always prevails
So again, nothing new here in CERT-In directives, it is purely expanding the constituent to other relevant organisations to help detect and stop cyber frauds causing financial losses within the Indian jurisdiction.
How easy is this to implement? May not be easy.
Longer retention period for such data will add to operational cost but is unavoidable.
Understanding Annexure I
1. Targeted scanning/probing of critical networks/systems
Reporting scanning of internet facing infrastructure could be an overkill as such scans are routinely conducted across large segments of the IPv4 address space. Enterprises leverage protection mechanisms to thwart such attempts.
Detecting targeted scans itself could be difficult since they will be stealthy. However, the very occurrence of targeted scanning should get reported as it is possible it could be a nation state actor and other organisations in the country could be saved by appropriate action taken by CERT-In at the right time.
Enable the right use cases within the log collection and monitoring environment.
2. Compromise of critical systems/information
When the entity has identified and confirmed that a critical resource has been breached it should be reported at the earliest. Why wait for even 6 hours?
3. Unauthorised access of IT systems/data
CERT-In could provide clarification to the definition of an “insider attack”. What if the matter is resolved internally in the organisation and doesn’t call for an external entity involvement?
4. Defacement of website or intrusion into a website and unauthorised changes such as inserting malicious code, links to external websites etc.
Appropriate monitoring should be enabled to detect this and report. Smaller organisations can leverage online monitoring services to get alerted whenever a defacement or malicious code injection happens to the external websites.
5. Malicious code attacks such as spreading of virus / worm / Trojan / Bots / Spyware / Ransomware / Cryptominers
If the infection is successful, it should be reported. Ambiguity in terms of attack detected and stopped by security solution, should that be reported? Thwarted attacks and successful infections should both be reported. On a larger scale, it’s possible that this could be a country wide issue. Analysis by CERT-In could help protect the nation against such large scale attacks.
6. Attack on servers such as Database, Mail and DNS and network devices such as Routers
Network devices such as routers, email servers are classified as critical systems since they serve as entry points to an attacker. Protecting them is critical and most monitoring products will provide controls for the same. Leverage these tools and platforms to adequately protect the network and alert in case of any potential incident.
7. Identity Theft, spoofing and phishing attacks
Review DMARC settings and SIEM alerts to reduce the spoofing, phishing attacks. Any such incident identification should be reported. If an organisation leverages 3rd party security controls (either provided by email provider or additionally deployed), monitoring of the same should be part of the incident management programs.
8. Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks
Detection for DoS and DDoS attacks can be enabled at various levels. If external DNS and Web Application Firewall services are leveraged, then their infrastructure is better equipped to handle large scale DoS/DDoS attacks.
9. Attacks on Critical infrastructure, SCADA and operational technology systems and Wireless networks
CI/SCADA/OT logs are critical for operational safety and should be maintained in a SIEM environment with appropriate alerting and reporting processes. Wireless segments in enterprise networks can co-exist on existing log collection processes. Many Wireless networks can be secured using Wireless Intrusion Detection System (WIDS) to improve security posture
10. Attacks on Application such as E-Governance, E-Commerce etc.
E-Gov and E-Com applications are technically web and/or mobile applications and they should be subjected to monitoring, log management similar to critical IT operations. Just in case e-commerce processes are hosted with a 3rd party, ensure contractual agreements include SLA’s for security monitoring, alerting, and reporting.
It is advised to perform a review of existing contracts for information security related SLA’s.
11. Data Breach
Attempts to breach or successful data breaches should be reported at the earliest. Investigations can be conducted in parallel. Very often organisations tend to hide data breaches as it affects share prices, customer confidence, and overall market reputation.
However, in today’s world not reporting data breaches can be more disastrous. It is highly recommended that organisations report at the earliest any sign of data breach to the relevant parties, stakeholders, regulatory bodies, law enforcement etc as the case applies.
12. Data Leak
Appropriately configured DLP systems can assist in identifying insider data leakage attempts and attacks. Configure rulesets to capture intentional and unintentional data leakage. Post alerting, IT / security teams must investigate until closure so that incidents can be tracked and reported as needed.
13. Attacks on Internet of Things (IoT) devices and associated systems, networks, software, servers
IoT environments can get very chatty and generate a lot of logs. Very often these segments get ignored and are leveraged by attackers. There are many examples where IoT thermostat in aquariums, HVAC systems, CCTV networks are infiltrated and subsequently the attacker has gained access to high value targets in that network.
Log collection, correlation and alerting will assist in detecting such stealthy attacks and protect high value assets.
14. Attacks or incident affecting Digital Payment systems
India made 7,422 crore digital payments in FY22. Attackers also watch such statistics and understand these are prime targets. If financial transactions are processed then the organization along with being PCI-DSS compliant should tighten their processes for fraud detection and assist law enforcement with detecting terrorism sponsored fund movement.
This will help the nation’s economy grow and prevent fraud.
15. Attacks through Malicious mobile Apps
Many malicious actors (sometimes nation state sponsored) develop and release malicious apps under the guise of games, photo management etc. In this regard, CERT-In should coordinate with the mobile operating system application marketplaces (e.g. Google PlayStore, Apple App Store) to remove/block such malicious apps at the earliest.
Appropriate security training can also help generate awareness within employees and the general public.
16. Fake mobile Apps
Fraudulent mobile applications can hurt business and overall brand value. Leverage threat intelligence services to identify and bring down any fake applications.
17. Unauthorised access to social media accounts
Include the primary social media accounts within the asset register. Designate certain individuals as owners to those accounts and tighten the access via security controls available through the social media platform such as multi-factor authentication (MFA).
Periodic access review will also help in curbing stale access and monitoring current access behaviour.
Passwords to these accounts should be managed via a password manager so that if the social media account owner’s employment is terminated, the password is unknown and the chances for account compromise are lowered.
Additional access control and appropriate monitoring can be enabled via internal security controls should be enabled to identify unauthorised access.
18. Attacks or malicious/suspicious activities affecting Cloud computing systems/servers/software/applications
Many organisations are taking advantage of the public cloud. These cloud providers have published checklists and basic best practices that should be adhered to. Review these best practices routinely and as they are subject to change as technology improves.
It is imperative to develop and enable use cases within the alerting and reporting tools provided by the cloud provider.
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
All the above mentioned areas are highly specialised and have their own risks and threats. There should be a prime focus if not already in adopting reasonable security practices and applying security monitoring.
20. Attacks or malicious/ suspicious activities affecting systems/ servers/software/ applications related to Artificial Intelligence and Machine Learning
As AI / ML forms the base for many operations globally, a lot of sophisticated attacks target the Machine Learning models with the intention to cause a malfunction within the artificial intelligence engine.
These attacks use various techniques such as deceptive data, environment manipulation etc. to corrupt the model and cause it to behave erroneously. Setup use cases within the alerting mechanism such that deceptive data being pushed by an attacker is identified and prevented from reaching and corrupting the machine learning model.
Authors
Views expressed in this article are of seasoned cyber security professionals who believe in enhancing an organisation’s security profile while easing usability and keeping management of security simple.
Rohit Srivastwa
20+ years of experience in information security. Microsoft Most Valuable Professional awardee in Enterprise Security. Serial entrepreneur with successful exits.
Twitter: @rohit11
Linkedin: https://linkedin.com/in/rohit11
Website: https://rohit11.com
Aalok Karnik
18+ years of experience in enterprise security. Managed various security projects in many of the fortune 100 companies like Google, McAfee, HP, Walmart, Twitter etc.
Twitter : @aalok_the_k
LinkedIn: https://linkedin.com/in/aalok