Q: What is HSS?
A: HSS or High Security Server is the first Unix OS based on a completely new developed Linux kernel (started with Debian) with integrity protection, like a standard iPhone. It runs as well on Red Hat and Suse Linux. It has been developed by our German company called Iπsec Ltd., operating in Frankfurt, Hamburg and the UK. Iπsec has also developed the fastest file transfer protocol called RHIPP – Robust High Performance Protocol. RHIPP is seven times faster than anything else IP-based on the planet and works especially well in Cloud Computing environments, where a lot of data has to be transferred very fast from an IPC to the customer desktop, including integrity protection. Iπsec’s Vision is innovation and real security, specialized on Integrity protection.
Q: What is so special about the HSS? Is it something like SELinux from the NSA?
A: True, there are tons of other systems like the HSS. Here come the major ones. Apparmor e.g., has a good security, but is a bit outdated and difficult in handling. GRSecurity has a low level security and remains in the middle in terms of ease of handling. RSBAC offers the same security and handling features like GRSecurity. Systrace offers bad security and bad handling. Lids as well.
The only two competitors of the HSS are Apparmor and SELinux. The HSS follows the same principles in terms of the LSM concept in development like its two competitors, and remains on the official ethical path on how security should be implemented into Linux kernels.
Q: And what is the major difference to SELinux and Apparmor?
A: The security protection of SELinux and Apparmor only work if the system is configured appropriately. A breach or short cut of the administrator violates the whole security of these OS systems, meaning confidentiality, integrity and availability of the system. HSS offers a hardening of its kernel from the operating system start and remains compatible to its applications. SELinux and Apparmor do not offer a basic protection against vulnerabilities of the Linux kernel. Everything has to be set up manually and by tons of scripts.
One of the major tricks is that the HSS re-assigns the Unix Capabilities. They are assigned in a different way to root, other users and to a new account called the Security Officer, or SecOff, depending on the security levels chosen before booting. Root has only read (allow) on the SecOff account and its rights. A sudo or su does not work just because an admin owns root rights. Security is mandatory and a four eyes principle has been implemented.
Q: But that means in terms of operations that if a system stands due to a problem, it stands?
A: Yes, it will stop processing, but security goes on, and that is the major point. Some business processes have to be adopted when playing with the thought to implement HSS. We did not care about environments where people need to have SOX-related security compliance for executive reports and compliance reports, when we had the idea. We were focusing on high security areas, where people really have to rely on security, where reliability for security is 100%. We have implemented three security levels in the HSS.
These 3 levels can be seen as different profiles, while the HSS continues its principles in all three security levels, but will allow for some flexibility which can be customized in all three security levels. Well of course in level three, which is the highest security protection, we do not offer a lot of customization. Customers which need level three will not start to argue about it. We can e.g. configure, that in level one, where root cannot submit a “su”, it would be allowed. In level three the graphical user interface e.g. X11 will not work. Only the command line is to be used. Level three is the most restrictive security protection.
Q: Can’t SELinux can do the same job?
A: Yes nearly, though not everything what we have implemented in the HSS can be fulfilled as well by SELinux. But let us say for the ease of understanding, they are close in relation to security to each other when both system are customized to their highest security protection.
There is still a major difference between SELinux and the HSS. HSS is up and running and configured in 20 minutes. For customizations in levels one and two please add 40 minutes, for customizations in level three please add 15 min. For training on how to use its ControlPanel (license ware) and its special error messages please add one hour. Now you can see that it takes only 2 hours to have it up and running. And the funny thing in addition is, that it does not matter, for which type of server system you would like to use it? Fileserver, Webserver, Apps-Server? Security works for all of them out of the box. We also have a proof of concept for an Apache Webserver Integrity module.
The major difference to SELinux is time. And time is money…I have seen EDS (now HP) Gurus which required 12 man days to configure SELinux, when I was in Plano, TX while working for the security department of EDS in Germany on different projects overseas.
Q: So you’re saying that HSS has a major advantage over SELinux in setup time.
A: Yes, that is our advantage.. But we have also a lot of other facts which may convince you to choose HSS.
Q: And they are…?
A: HSS offers a Buffer Overflow Protection, including for insecure applications. Drivers cannot be loaded if the system is operated in sealed mode. Time changes are impossible. Access to process information can be restricted. Direct writing on block devices can be forbidden. Executing file without a hash can be forbidden. Loading of libraries with LD_PRELOAD can be forbidden. Setting of SUID/SGID Flags can be forbidden. PTRACE can be forbidden. It can be switched on, that only the Security Officer can modify hashes of programs and files. The kernel-internal integrity protection checks programs and libraries and directly executed scripts before execution against a whitelist (a reserved hash in the Meta directory). HSS offers a library, which can check the integrity of all kind of data before opening for processing occurs. Last but not least, this library can check the Keyed-Hash Message Authentication Codes (HMAC). During calculation of the hash a private key will be added. A program or file will only be successfully checked, if the hash is valid and the signee knows the private key. HSS avoids a persistent contamination with viruses and Trojans. Security is mandatory.
If you need speed and security, you need HSS.
Q: So you have a hybrid licensing model, with proprietary software on top of the open source base.
A: We started selling a single license for the ControlPanel, which can only control the kernel built-in security features for $6000 US. We thought that is still much cheaper and safer, than using SELinux. And we have a license model, which makes HSS very attractive up from more than 50 licenses. Support is a yearly fee of 8% of the license price.
Q: When did you launch your product?
A: End of 2007 it worked with some smaller errors and a one major error with the hashes. Since end of 2008 it is in production and in sales.
Q: Has any outside entity confirmed your security claims?
A: The star under the German security penetration companies called n.runs AG in Oberursel tested it.
Q: So why hasn’t there been more publicity about your product?
A: We wrote in 2008 in IDG Computerwoche (Computerweek) about it and three days later somebody broke into our Hamburg offices and tried to steal the source code. Fact is, we never had the source in our offices. Funny was, that there were two brand new load balancers for 40.000 Euro and 4 laptops on the tables, but the burglars left them there. That was strange. So we think, that one of the existing three-letter-code agencies on earth tried their luck. Since that time, we’ve been keeping a low profile. We have sold more than 1000 licenses, however.
Q: What comes next?
A: Scheduled is an EAL-4 certification. The problem is, that economic espionage is everywhere. If you find the wrong certification authority, it could be that somebody raises patents in countries, and you cannot even sell your little modified own products on these markets. That is why we proceed very carefully, we screen our certification company and its people very well with modern technology, before we select one. If you choose “too” German certification companies like TÜV-it or T-Systems, it could be that the source goes at least to the German Ministry of Internal Affairs -- and from there in deals, maybe also to Bad Aibling (Military Intelligence). We do not want either or both. We would like to offer Integrity. We want that people choosing and paying for high security will not be disappointed. And just because not being EAL-certified, does not necessarily mean, that it is not secure. But we are heading for this. Modern fuzzing technologies can also be used to certify a system soon without the need of having the source code. And we have that time. Also in the pipe is an army model. But before both, we are working at the moment on a new version which supports newer server hardware better. This is already running and will end in total of 70 man days.
HSS Whitepaper (German Language).