The article “Security Gaps in RailTel Linked Systems Pose Risk” published on 19 April reported that internet-exposed systems associated with RailTel-linked infrastructure presented potential security risks, including remotely accessible services and endpoints.
RailTel Corporation of India Limited, in its rebuttal issued on 30 April, has contested both the process and the attribution of these findings, asserting that the identified systems fall entirely outside its responsibility.
The following is a point-wise response based on the rebuttal and official records.
On the issue of prior communication:
RailTel has stated that the email message ,apprising them of the vulnerabilities cited in the report, was sent to a non-functional address. It is acknowledged that the communication did not reach the correct channel, and this is regretted. However, this does not negate the existence of the identified exposures, which require independent examination on their technical merits.
On the claim that all identified IPs belong to customers:
RailTel has asserted that every IP address flagged in the report belongs to customers and not to its own systems. However, a Railway Board circular dated 12th May 2020 mandates RailTel to implement the e-Office system across Indian Railways, including divisions, hospitals, workshops and subordinate offices. These units, even if network-classified as customers, operate within a single administrative platform deployed by RailTel. In such a structure, the classification of endpoints as "customers" does not, by itself, establish that they are external to railway systems.
On the denial of linkage to core infrastructure:
RailTel has stated that none of the identified systems are part of its data centres, enterprise systems or the railway surveillance backbone. However, the Railway Board order establishes that railway systems are distributed across multiple units and locations. The operational system, as defined in the order, extends beyond centralised infrastructure to connected endpoints across the network.
On the argument of ISP-only responsibility under DoT norms:
RailTel has argued that as a licensed Class A ISP, hence responsible only for connectivity and has no legal authority over customer-side configurations.
However, the same rebuttal states that RailTel undertakes routine scanning and informs customers of vulnerabilities. This indicates ongoing visibility into endpoint exposure, which is not consistent with a purely passive connectivity role.
On responsibility for security configuration:
RailTel has placed full responsibility for security on customers.
The Railway Board directive, however, assigns RailTel responsibility for implementation and monitoring of a networked platform across railway units, including the creation of a centralised dashboard. In such a system, the integrity of the platform is dependent on the condition of its constituent nodes, and vulnerabilities at endpoint level cannot be entirely separated from system-level risk.
On the linkage to external cases:
RailTel has objected to references to external security incidents. The use of such references is a matter of editorial context, intended to illustrate how similar vulnerabilities have translated into operational risk.
On the request for takedown and publication of rebuttal:
RailTel has sought removal of the article and publication of its rebuttal with equal prominence. This response addresses the substantive issues raised, based on the documents available.
The Railway Board order establishes that RailTel's role extends beyond connectivity to the implementation and monitoring of a distributed administrative system across railway units.
By defining its role narrowly as a connectivity provider, the rebuttal does not address whether a compromise at such "subscriber" endpoints, if they are part of the networked system described in the 2020 order, would have implications for the integrity of that platform itself. That distinction remains central to assessing the risk.