Security in obscurity is a wrong thing to follow: Harish Pillay
As the global community and technology architect, Harish Pillay is a part of the community architecture group, which comprises a core group of Red Hatters who interface between Red Hat and the Open Source community. Harish joined Red Hat from Maringo Tree Technologies, an open source consultancy, training and services company, he co-founded in 2002. He was also the Founder/CTO of Inquisitive Mind – an e-learning services company – founded in 1999. Excerpts from an interview:
Can you give an overview on how SE Linux project initiated?
Essentially, a project was initiated around 1999-2000 timeframe by the National Security Agency, USA. In the 90s, they had worked with different operating system (OS) vendors to have secure operating systems, but they were all proprietary software vendors, which never really went far. With the rise of Linux and open source technologies in the late 90s, they saw this became an interesting opportunity to see whether one can secure a fully open source operating system.
Therefore, they approached the Linux community to see what they can do about it and whether Red Hat could power-off from the kernel itself. That initiated a project called SE Linux (Security Enhanced Linux). This is within the Linux kernel itself down every single port, every single process, every file, every access and every single thing that can be locked down. If we fast forward the last 10 years, SE Linux is a now a standard in everything Linux provides. It is always switched on, enabled by default.
Now what has SE Linux evolved into?
Now, if you look at anything over the last six years that Red Hat has provided, from a Red Hat enterprise in the OS perspective, there has not been a single issue as far as security is concerned – the credit largely has to go to SE Linux as it confines to a user and there is no duplicity with parallel user. Suppose, if two users are accessing from the web on a shared platform and if there was any breach, it would immediately terminate user sessions from the kernel level itself. Moreover, that is the best place to make it as secure as possible. So, once that is already locked down, then JVM (Java machine) comes in. JVM already has the security components embedded into it — a sort of sandboxing, meaning when a person does something in his own box, it cannot affect the next person).
From a design standpoint, Java was already inside it and then you have JBoss on top of it. Therefore, you have multi-layer security in-depth inside it and with that many security threats can be thwarted. Therefore, the credit has to go to whatever has been done at the lower levels because that is where the first instance of break-ins happen.
Can you elaborate on how does it work from an application standpoint?
From an applications front, if an application breaks down or is compromised, then Java environment confines the situation within the sandbox. If one were to attempt getting into the sandbox, then he would have to break into the JVM layer, and for that he would have get into the SE Linux layer. So, in a sense, many multiple layers to crack, which is not a trivial thing. While there have been reports of issues but they have already been addressed and fixed. On that basis, security is front-ended and never an add-on or an after-thought. It is designed with security in mind from the very first instance.
What about threats from BOYD and social networking tools?
As far as threats from BOYD and social networking tools are concerned, the same thing applies and the sandboxing principle comes into play. The sandboxing capability isolates the issue and deals with it accordingly.
At the end of the day, if you see, most of the breaches are socially engineered breaches. The technical breaches are few and far between. Thus, we need to educate users to not click on something — such as an attachment — that looks normal from a friend or a source you can trust. Do not click immediately, check first and verify the source.
At the same time, security should not be cumbersome or make the user feel burdened, as then the entire exercise is wasted. Training and following best practices play an equally important role in ensuring security. At the same time, we need to be proactive about it because different people come up with different ideas regarding security. We need to disseminate information far and wide. Security in obscurity is wrong to have — that is the mantra we go through all the time. Do not try to hide what you are trying to secure.
Security in obscurity is a wrong thing to follow: Harish Pillay
Harish Pillay, Global Head, Community Architect & Leadership, Red Hat, was in Bangalore for the recently held JUDCon 2012: India conference. InformationWeek caught up with him to gauge his insights into the security culture embedded in the Linux community
Verghese Joseph
IFSEC Insider | Security and Fire News and Resources Related Topics