Naavi.org had suggested a model Bug Bounty Policy for Private Sector Companies as part of its Cyber Law Compliance Center (CLCC) Activity. Copy of this policy is available through the menu link CLCC. This was drawn in March 2016 specifically for private sector companies. This could act as a guide to a possible Bug Bounty policy that UIDAI could use.
Now after the Abhinav Srivastava incident, questions arise on what “Due Diligence” step should UIDAI take in the light of what has happened. On the one hand UIDAI may maintain rightly that this is not a case of hacking of the CIDR and therefore there is no vulnerability in the access system. They would be correct in claiming that whatever is considered as an “Unauthorized Access” could have taken place at the level of the e-hospital platform used by one of the e-hospital users. NIC may be the organization responsible for the maintenance of the e-Hospital platform.
At present, the complaint against Mr Abhinav Srivstava has been made by UIDAI and if the security breach has occurred not at the level of CIDR, it appears that the complaint should not have been entertained in the first place by the Police. On the other hand, UIDAI could have raised the complaint against NIC or the e-hospital user stating that they had caused defamation of UIDAI and its security by not following adequate security at their end.
Police cannot however launch any proceedings based on Section 43A of ITA 2000/8 since it is a matter that should be taken up by individual persons who may claim damages on account of the breach or by the Adjudicator who has suo moto powers to take up the case on behalf of the public. It is unthinkable that the Adjudicator anywhere in India would take up a complaint against NIC or the Government hospitals using e-hospital application since the Government itself is a party to the management or mis-management of the information security practice in these agencies.
Under Section 79 however, if there has been any criminal offence attributable to the intermediary, the crime can be extended to the organization for lack of “Due Diligence”. If therefore it is felt that in the use of Abhinav App, there was some crime committed either under ITA 2000/8 then it would be feasible for Police to have taken action against such intermediaries. However so far Police have not initiated any action in this direction.
Let’s for the time being forget what the Police may do here after and focus on how should UIDAI respond now with all the experience they have gained in the incident.
Failure of the Incident Management System
The first observation I would like to record is that UIDAI did not wake up the presence of an App in Google PlayStore claiming eKYC through Aadhar until around 80000 downloads took place. In fact there were many more such applications in PlayStore some of which might have been taken off now. The inability to observe presence of such Apps can be considered as the “Failure of the Incident Management System” of UIDAI.
Tomorrow if some body opens a website www.uidai-kyc.in or uidai-kyc.com (Both of which are available for registration) does UIDAI have the measures in place to recognize this and take remedial action?… Probably not.
Hence there is an urgent need for UIDAI to set up policies and procedures to identify such “Attempt to Impersonate” as a “Techno Legal Cyber Security Incident” as part of its “Due Diligence” practice. It should raise an internal ticket and resolve it at the earliest documenting the entire resolution and lessons drawn.
Since such measures donot exist, it is just an indication that UIDAI itself is not ITA 2008 compliant and has not taken “Reasonable” measures to prevent occurrence of Cyber Crimes under different sections of ITA 2000/8.
On September 5, 2009, Naavi.org had published an article titled “Reasonable Security Practices For UID Project A Draft for Debate Prepared by Naavi”. In the last 8 years, UIDAI and Aadhar has changed its perspective and hence this draft needs revision. But the fact that UIDAI needs to be itself ITA 2000/8 compliant still exists and such an exercise includes development of such policies and procedures that would identify and mitigate all risks identified below.
Need for Crowd sourcing Risk identification
UIDAI is a service that would be used by more than a billion people and multiple times during the year. It is a service which will be a prime target of hackers around the world including Cyber terrorists and enemy nations such as China and Pakistan interested in Cyber warfare.
UIDAI may be capable of taking care of internal server security preventing unauthorized access. We can therefore accept their contention that the UIDAI systems are safe.
However, risks arising from the negligence of Users and Sub Contractors which may indirectly cause reputation loss to UIDAI and raise National security issues may not be adequately addressed by UIDAI and this is well demonstrated in the past.
The fact that despite Naavi.org raising several issues not only by the Nov 4 2016 article on e-Hospital but also regarding the domain name registration in individual officer’s names and use of digital certificates of US companies etc, UIDAI has not responded promptly to address the potential risks.
We may therefore consider that the internal Information Security team of UIDAI cannot be expected to mitigate such risks nor even identify them in time.
It is therefore essential that UIDAI responds to the present crisis by inviting well intentioned security professionals who are not in the roles of UIDAI to be part of the security risk identification infrastructure by starting a “UIDAI-Bug Bounty Program”.
UIDAI as a Protected System
The Need for UIDAI Bug Bounty Program also arises from the fact that UIDAI has been declared as a “Protected System” under Section 70 of ITA 2000/8 though the notification
Government of India has notified through Gazette Notification GSR 993 (E) dated 11th December 2015 that
UIDAI’s Central Identities Data Repository (CIDR) facilities, Information Assets, Logistics
Infrastructure and Dependencies Installed at UIDAI (Unique Identification Authority of India)
locations to be Protected System for the Purpose of Information Technology Act 2000.
Authorised personnel as per Sub-section (2) of Section 70 of IT Act 2000 (amended 2008)
having role based access to UIDAI-CIDR facility are:
1. Designated UIDAI officers & Support Staff.
2. UIDAI authorised team members of contracted Managed Service Provider (MSP).
3. Other authorised third party Vendors and its partners.
4. UIDAI authorised business partners.
Section 70 of the ITA 2000/8 states as under:
Sec 70: Protected system (Amended Vide ITAA-2008)
(1) The appropriate Government may, by notification in the Official Gazette, declare any computer resource which directly or indirectly affects the facility of Critical Information Infrastructure, to be a protected system.
Explanation: For the purposes of this section, “Critical Information Infrastructure” means the computer resource, the incapacitation or destruction of which , shall have debilitating impact on national security, economy, public health or safety. (Substituted vide ITAA-2008)
(2)The appropriate Government may, by order in writing, authorize the persons who are authorized to access protected systems notified under sub-section (1)
(3)Any person who secures access or attempts to secure access to a protected system in contravention of the provisions of this section shall be punished with imprisonment of either description for a term which may extend to ten years and shall also be liable to fine.
(4) The Central Government shall prescribe the information security practices and procedures for such protected system. (Inserted vide ITAA 2008)
It is obvious that the Gazette Notification of 11th December 2015 does not fulfill the requirements of Section 70 in full since it does not provide the details of how this protected system needs to be operated. Merely stating that “Role Based Access” would be provided is grossly inadequate to meet the requirements of Sec 70. It is necessary that detailed information security practices and procedures need to be developed.
Normally we say that the detailed Information Security Policy may not be “Disclosed to Public” for security reasons.
However, in the case of Section 70 systems, since “An Attempt to Access” the system is as much an offence as actual access and could result in imprisonment of upto 10 years, public have the right to know what would constitute an “Attempt” to access the CIDR systems and who will be considered as “Not Authorized”.
It is our interpretation that persons who are authorized to access these systems should be identified by name and cannot be described as “UIDAI Business Partners” or “Other authorized third party vendors” and its partners or “Designated UIDAI Officers & Support Staff” or “UIDAI authorized team members of contracted Managed Service Providers” or such other general terms.
If and when Abhinav’s case goes to a Court, there will be a discussion on whether UIDAI has clarified on what is “Authorized Access” to UIDAI systems and in the absence of clarity, whether Mr Abhinav can be said to have “Unauthorizedly accessed” the systems.
In view of the need to clarify what constitutes a crime under Section 70 of ITA 2000/8 when some body accesses the CIDR system, UIDAI needs to define and publish “Permitted Access System” and also take reasonable precautions at their end to ensure that any attempt to access their systems outside these permitted parameters are blocked by their Firewall and also generate appropriate alerts/Notices to the person who is attempting to access the system outside the permitted procedure.
The website of www.uidai.gov.in declares certain website policies which are only related to visit to UIDAI website and even in that respect it is not fully adequate. It does not say anything about the access to CIDR systems. This needs to be corrected.
In view of the above, a properly structured Bug Bounty Policy can be a good tool not only to crowd source the skills of security professionals to harden the security around UIDAI but also to provide clarity to the access rules under Section 70 of ITA 2000/8.
Essential Features of UIDAI Bug Bounty Program
The Model Bug Bounty Policy for Private Sector published by the CLCC provides a general template under which the UIDAI-Bug Bounty Policy needs to be developed.
It would be inappropriate for me to try and draft a final policy for UIDAI on this website since UIDAI is supposed to have more intelligent and more informed persons at their disposal and can do a better job. I therefore would not try to attempt such an exercise.
However some points that needs be made are
- In the “Objective Clause” the fact that UIDAI system is a Section 70 declared “Protected System” must be included.
- The policy should be prominently shown on the UIDAI website.
- Alerts are to be shown when a visitor tries to get any information from the website including getting his own Aadhar data.
- The names of authorized persons who have the access rights are to be displayed on the website.
- Restricted procedure on how the authorized persons can access the systems should also be displayed. (This does not need disclosure of the detailed information security policy that would reveal the network details etc).
- The definition of “Bug” for the “Bug Bounty” purpose should be defined to include all possible means by which the system could be compromised and data accessed except as provided under Section 70 notification.
- Being a Bug Bounty program for a “Protected System” where “An attempt to access” can be a crime, it is necessary that any person who would like to check for a “Bug” needs to be first “Registered” as a “Prospective Bug Bounty Hunter”. The registration has to be with UIDAI and obviously with an “Aadhar KYC”. The permission may be restricted to Indian nationals and could be denied on the basis of a background check which the UIDAI can undertake before granting the permission.
- Any activity of the Bug Bounty Hunter before he obtains the permission could be treated as an unauthorized attempt to access and UIDAI may reserve it’s right to take action though they can use their discretion in this regard.
- The critical aspect of the program would be how the Bug Bounty Committee would be constituted. Given the fact that the receiver of the Bug report can turn around and charge the reporter of a Crime, the reporting has to be treated like “Whistle Blowing”. The Committee therefore cannot be a committee of the CEO/CTO of UIDAI. It has to be committee of “Respected Members of the community” who anonymize the registrant and also scrutinize the bug without any pre-conceived notions and egos. Only after the bug is accepted by UIDAI management, the committee may reveal the identity of the bug reporter at his option. The committee members should provide the confidence to the public that an honest good faith report even if it is incorrect would not be considered as malicious and would not be proceeded against for punishment.
- The Bug itself may be never publicized in detail so that UIDAI may retain its reputation and not be open to the charge that several bugs were found to be present. All professionals know that just as there can be no 100% information security, there may not be 100% bug free software service. Hence, mere identification of bugs is not to be considered as a loss of reputation of the IS/IT team of UIDAI. Some politicians particularly in the opposition may not understand this and pass criticisms but such criticisms should be ignored.
“The Greatness of a person is not that he has never fallen down, but it is how gracefully he gets up”.
This applies to UIDAI after the recent spate of media exposures about the so called Aadhar Data Breach”. It is now in the hands of UIDAI to show if it is a great institution and gets up gracefully or acts mean and crucifies Bug finders.