Will the coder too be held culpable one day ??

In the world of increasing dimensions to crime, being careless or just not being alert to possibilities can invite criminal liability. Many acts of contravention/crime are punished by laws that criminalize an organization or institution for not following guidelines as prescribed in notifications. It is as if the entity has abetted the crime by being careless about guidelines – however tough they may be to follow or adhere to. Further,  the awareness and activism surrounding Data Privacy has resulted in increased sensitivity around matters of personal data. With tough regulations such as the EU’s GDPR ( European Union’s General Data Protection Regulation ) coming into force with its steep penalties on infringements of its provisions, the consequences of data breach due to carelessness or otherwise, has become very severe.

The IT Act 2008 ( Information Technology Act ) has defined several laws that concern contraventions and crimes in the cyber space. Under section 79 of the Act, the Service Provider, who provides internet data or voice connectivity, can become liable if it cannot prove that it took sufficient care in avoidance of the crime, and in taking quick action to control the damage caused by the crime.  The service provider is bracketed under the larger legal term “intermediary” which includes the Internet Service provider, Network service provider, telecom service provider , hosting providers, online markets, cyber centers etc..  

So, if a service provider can be liable for just being careless, what about the coder/programmer who could deliberately or through sheer carelessness, leave scope for lot of loopholes in the source code of the various applications – perhaps to be exploited later by criminals ?? … but before we jump directly there, there is a need to step back a bit and look at the background of the liability.

Hacking is popularly believed to be a highly technical hit job. But it is not exactly so as the technical complexity is being increasingly abstracted by the introduction of new tools.  Either way the perpetrator/hacker/criminal exploits some vulnerability in the system in order to gain access. He could break a weak password to gain entry, or he could use hacker tools to scan and identify an open port and use it to execute some unintended code, or use specially designed tools to install and run a Trojan server in the compromised system to do a variety of mischievous/dangerous activities. The access available through tools ( such as ProRat for instance ) could be used to download  files, take pictures, alter credentials and many other havoc causing actions. The victim upon noticing the violation on the system, complains to the authorities and the Cyber Police in the jurisdiction. The forensic process follows and evidence is collected leading to investigation. Here the suspect  is clearly the hacker who committed the criminal intrusion, and in this particular case is liable to be slapped with a FIR with offence defined under section 43(c) read with Section 66 of ITA 2000. While the investigating agencies may be able to nail down the offender through the forensic evidence collected, the story doesn’t end there. Suppose say the compromised system were to be in the data center managed by a service provider, the provider becomes questionable and it would be upon him to prove that he –

1. Did not conspire, abet, or come under any threat to aid the crime
2. Took immediate action to disable access to system and removed the intruding element.
3. Did not tamper the evidence in any manner.
4.  Followed as a matter of practice, the due diligence and guidelines as prescribed by the provisions of the IT Act 2000.

While the intermediary does comes under the scanner, the reason for the hacker being able to break into the system may also be attributed to faulty implementation of applications running in the systems. These appear at a deeper layer of vulnerability in the cyber crime ecosystem, that the cyber  law does not really touch upon. It stops at the intermediary. The point to be understood here is that the application provider is not yet part of the “intermediary layer”. The liability of the application provider    ( and hence perhaps its designing and coding team ) will arise only if there are specific contractual bindings that the service provider may have with the application provider, which falls outside the purview of the IT Act 2000. Even if they exist in the contract, it could usually be “civil” in nature , whereas the service provider becomes liable for “criminal” charges under provisions of Section 79 of the IT ACT 2000. While the cyber crime investigating team may be equipped to question the hosting service provider as the intermediary, it will most definitely fall short in competence to investigate vulnerabilities in source code of the application software. Some aspects are beyond imagination and comprehension and are likely to be left out of the scheme of things, whether right or wrong. This is especially true, when you realize that there are even chip level vulnerabilities that are uncovered from time to time !! These vulnerabilities allow the intruder to access restricted areas of memory totally bypassing the entire gamut of operating system and the applications.

Here again, it is to be reiterated that being careless and not following the guidelines in coding could make the coder as culpable as the service provider is today as per section 79 of ITA 2000 ( of course, only if and when there will be an amendment to the Act to reach deeper further beyond the intermediary ). The point to reinforce is that, poor adherence to guidelines in application implementation, can eventually impact the end customer quite severely. This is not a case of mindless exaggeration or neither is it making a mountain out of a mole hill.  Who can tell in what different ways the potential hacker would exploit the vulnerabilities left unchecked??  The ramifications of open vulnerabilities when exploited by hackers,  can be very severe.  It is when seen in that sense, that the impact of introducing a vulnerability, intentionally or carelessly, starts to bug the coder.  The impact is further compounded by the emergence of stringent global laws ( like GDPR ) that impose huge penalties on the erring organization. The hacker may get away with a much lesser sentence locally since only local cyber laws are applicable, but the intermediary gets caught up in global glare as it is a visible fixed entity unlike a runaway hacker.

But, what exactly are the source code induced vulnerabilities? Here are a few –

1. Introducing malicious code exploiting buffer overflows ( for instance – by introducing malicious function pointers or overwriting existing function pointers )
2. A socket waiting on an open port, can be deliberately programmed to give access to the restricted files which the client can access, or an accidentally left open port can be exploited by the remote client by connecting to some other vulnerable application running on the system.
3. Careless implementation of error handling code that does not get reviewed seriously. The error handling function could be written with malicious intent to transfer important files or alter content of files.
4. Loading malicious code into build by tweaking the operating system configurations
5. Accessing forbidden files by using Unicode encoded directory path traversal

As of now the source code induced vulnerabilities does not come under the gambit of the cyber laws. For the other substantive laws to be applicable, the contracts that the corporate has with its employee may not always cover such deep set aspects related to coding. The corporate may have avoided such clauses in the employment contracts in order to not appear too intimidating or unreasonable from the perspective of the prospective recruit.

The laws are bound to evolve covering new advances in cyber crime. Just as the IT Act 2000 was amended in 2008, there will in all probability be future amendments which might make the application provider also a party to the crime as an intermediary. The investigating agencies in future may also be equipped to pin point the culprit instead of just vaguely stopping at the intermediary. Cyber crime ecosystem is a world of tools – tools for the hacker as well as the forensics investigator. The cyber forensic tools, though very expensive, could evolve to actually pin point the source of the vulnerability leaving it to the investigating authority to conclude whether to dig further reaching down to the actual programmer. It is entirely possible for the programmer and the hacker to be at 2 different ends of the crime scenario, working for a common purpose with mens rea (criminal intent).

( Note : Many software vendor companies do have internal process and checks to ensure the compliance of the deliverable against cyber security related requirements.  The rigorous vulnerability tests do ensure that the bugs are uncovered and fixed. But the dimension of criminal liability as a result of a legal provision could usher in much more serious thought to be applied across organizations, just as has happened with the intermediaries in relation to section 79 of the ITA 2008. )