Archive | Open Source RSS feed for this section

System security and fascination with homegrown solutions

Not long ago, there was the news flash that the India government is in the process of kick-starting a project to build “our own operating system”. According to V.K. Saraswat, Scientific Adviser to the Defence Minister and DRDO Director-General,

We do not have our own operating system. Today, various bodies, including banks and defence establishments, need security. Having our own operating system will help us prevent hacking of our systems.

(…)

With a home-grown system, the source code will be with us and it helps in securing our systems.

Dr. Saraswat seems to have expanded on the plan by going beyond the operating system. At Aero India expo he is reported to have added the network to the plan:

“Cyber security is a major challenge for us as all our operations are going to be on the network centric system, which is dependent on information and communication technologies,” scientific adviser to defence minister V.K. Saraswat told reporters.

Admitting that securing the network centric system would be a major problem, Saraswat said the country would have to build robust systems and platforms with proprietary software to make sure the networks were safe and almost invincible.

The mention of proprietary software is confusing since it is not clear whether Dr. Saraswat is referring to the non-open source software ecosystem that includes the likes of Microsoft and others or whether he means a “made in India” indigenous software. Give the earlier emphasis on home grown operating system, I would venture a guess that it is the latter.

The goal of coming up with a home grown operating system and network defense framework is noble and even commendable, but not for the reason expounded by the scientific adviser. Given the ease with which trojans and traps can be inserted into a software (and hardware), it would seem logical that an internally developed piece of code would be more trustworthy. In a world where few understand the intricate details of the implementation of cryptographic primitives in code, it is not just about whether the code is open source or not, not when allegations like that against the OpenBSD IPSec stack cannot be dismissed easily. Software building involves a lot of reuse and in the case of open source code, it also involves donated code. Granted that these codes are there for everyone to see and audit, there is a dearth of expertise to actually such a meticulous analysis, especially when we are taking in the realm of cleverly hidden side channel attacks.

Given all this, software developed in a relative clean room, like what Dr. Saraswat aims to have, should be more trust worthy. Except that, clean rooms can only be “clean” up to a point. At what point can one safely say that re-using an idea, component or, for that matter, a standard would not destroy the pristine nature of the development? The less one can reuse, the more one has to re-invent and re-develop, the costlier and error prone the whole process is going to be.

This may seem like a lost cause but that is only because one assumes that there is a single silver bullet. In system security, there is never a silver bullet. Instead what we see succeeding in a practical world is a risk assessment based analysis of the systems and the implementation of the simple but powerful concept of defense in depth.

Comments { 3 }

Govt to develop own operating system

The Times of India reported yesterday of an initiative launched by the India government to develop its own operating system.

The government formed a high-level taskforce in February to devise a plan for building indigenous software, said a senior intelligence official who is a member. The panel will also suggest ways to conduct third-party audits on existing software in government offices to prevent online sabotage attempts until the software’s launch, he said.

While the details are sketchy and confusing, starting from the fact that there is more reference to “software” than operating system, it looks like the plan is to build an indigenous OS that can be used by government officials, starting from an open source OS out there. No further details are available on whether it will be BSD or Linux based.

This is a very encouraging step in the right direction though not without potential pitfalls.

For an OS to be secure and useful it has to get to a maturity level that is hard to reach. It remains to be seen how many of the government offices would find their way around a Linux distribution, even if it is as intuitive as Ubuntu or others out there.

Starting from an existing OS, while a practical thing to do, is risky in that either the current state of the OS has to be assumed to be secure or a careful meticulous audit has to be carried out to ascertain the security of the code. Given that so many vulnerabilities are being found in Open Source kernels and software, it would be prudent not to assume that they are secure just because they are open source. Of course being open source means that one has at least the option of  performing the necessary code analysis.

Another downside of using an open source distribution is that of maintenance and support. Unless a government agency takes it upon itself to maintain the distribution and provide end user support, the move is going to hit a brick wall soon.  This point should not be underestimated. A secure OS or a distribution that is not well maintained is just as insecure as any other out there. In addition, given that this OS is meant to be used by a wider non-technical user base that is the government offices, support service will turn out to be very important in the long run. Try explaining SELinux or how to configure it to a layman!

Operating system, though critical, is still only one of the pieces that makes the distribution. The software used within the OS is also critical. Is it not clear if this initiative is aimed at securing general purpose software too.

As the article mentions, regular audits have to be conducted in order to ascertain the security of the infrastructure. Though the content of the article casts a shadow at the anti-virus vendors, it is more likely that the users did not keep the virus signatures up to date than that the vendors had any malicious intent. Of course regular audits will only highlight the problem. The actual task of solving the problem (patching the OS, updating the signatures etc.) still needs to be carried out without delay.

At the end of the day the weakest link is almost always between the keyboard and the chair. Any initiative to secure the software infrastructure has to be accompanied with educating the users of best security practices and do-nots of computer security.

Comments { 7 }