4

In the context of a small scale operation, we are considering use of single special purpose PCs allocated to single security-sensitive tasks - for example, certain financial operations.

The intended security benefit is that by simplifying the processes that take place on these machines, the opportunities for mistakes leading to data leaks are reduced. The sorts of mistakes we are concerned about here are principally those that would increase the risk of successful, mostly automated, use of exploits by third parties, involving local malware and web-based attacks. The types of attack we are concerned with are not highly targetted ones. I also don't anticipate any protection here from social engineering and insider attacks, which I consider a separate but important issues.

The philosophy behind this idea is that though user education is important, there are practical limits even for users who are doing work that is relatively security sensitive. By limiting the scope of work at a PC we hope to make it easier for individuals to consistently stick to security policy where it is most important.

To further limit the scope of this question, the the software / processes that would be used are:

  • gmail for transfer of documents and communication with a small set of websites and people.
  • A web browser, for use only with a small number of websites

The (low-cost) hardware would would not share a monitor with another PC, and use of USB devices would not be permitted. The hardware would be attached via wifi to the same local network as all other machines. Printing would likely be done over that local network.

The machines are likely to run Linux and limited use of libreoffice, in a environment where other machines are Mac / Windows / MS Office. We do anticipate some training / compatibility issues with the office suite.

Does this plan confer actual security advantages of the type I've described? If not, what flaws might it have, and can changes be made to provide a useful security benefit?

2
  • Using a VM as sandbox eg with VirtualBox may be also good to prevent that malware from one machine in the same network breaks out and infects all other machines. Is it really necessary, that they are in one network without any virtualization or containerization?
    – user6090
    Commented Dec 5, 2015 at 15:56
  • Definitely do create a virtual machine (to install the web browser into). Install a USB wireless adapter and give the virtual machine control over it. Use that adapter to give your virtual machine Internet access. Do not give your main machine Internet access. Unity mode will allow you to use the web browser as a regular application while still technically running in the context of the VM's sandbox. This way you have pretty much the same security of an offline system but with the benefits of an online system. The best of both worlds. Commented Dec 5, 2015 at 16:14

2 Answers 2

5

The basic idea of restricting what can be done with the system does improve the security, because it decreases the attack surface and it also reduces the risk that the user will cause harm accidentally.

Unfortunately you have added one software which has a very great attack surface - the web browser. To limit this risk you should explicitly limit what sites can be reached from the browser. This could be done with a restrictive proxy or by configuring the browser to use a proxy.pac file which denies access to all but a few sites.

5
  • I think its more secure to filter on the IP level with a firewall, instead of using a proxy. Inserting a proxy does add potential compromise points. By simply allowing certain website IPs in firewall, and after this, blocking "all", you can gain a much more robust system. Also, another good idea is to use the hosts file to locally define the sites in question, then you can set DNS IP to 127.0.0.1 & block all traffic, including DNS traffic, except for HTTP/HTTPS to the permitted sites, and thus prevent any malicious DNS tunneling. Commented Dec 6, 2015 at 8:40
  • 1
    @sebastiannielsen: White-listing using DNS is a good idea. But I doubt that this can be done with the hosts file since this is too static in order to deal with changes to the association between IP address and hostname. Blocking/white-listing at the level of IP addresses in firewalls has the same problem, so you should better white-list at the level of hostnames (i.e. DNS, proxy or proxy.pac). Commented Dec 6, 2015 at 8:54
  • The advantage of the IP filtering in firewall is, that I said, more robust since it does not rely on layer 7 data, instead filtering takes place on layer 3. Filtering should be done on the lowest layer number as possible. Any IP-changes will error on the safe side, eg the whitelisted site in question becomes unreachable. Its very rare that a unsafe site takes over the IP number. If you in addition to this, use the hosts file linking, most sites will fail to load with a incorrect host: header. When you filter on the DNS side or proxy, you open up issues like possibility to "tunnel" data via DNS Commented Dec 6, 2015 at 11:32
  • @sebastiannielsen: I propagated white-listing not black-listing in which case I don't see why it should be possible to tunnel data through DNS. And while I agree that filtering should be done at the lowest level possible it might be an administration problem if you deal with sites where the IP address changes. But I think we speculate too much here anyway - the requirements in this question are not detailed enough to see if filtering at IP level is enough or not. Commented Dec 6, 2015 at 11:52
  • @sebastiannielsen: You analysis of the DNS tunnel side channel seems mistaken. Pure IP filtering is vulnerable to it (because the DNS request has to be answered in order to know whether an allowed or blocked IP address is to be contacted). The DNS service (whether proxy or recursive server) needs to perform filtering in order to block the problematic queries.
    – Ben Voigt
    Commented Nov 8 at 19:50
3

Its actually a great measure. This allows you to enforce stricter policies, you can put this "secure terminal" behind a locked door requiring a access card, and you can lock down this terminal very well.

But you need to improve it a little bit. I would not suggest using GMAIL because that would allow a rogue user to compromise material. A user could easily insert illicit software by sending a mail from himself to the "secure terminal GMAIL adress", and the user can easily leak confidental material by using GMAIL to mail himself. If the GMAIL adress leaks out, rogue users on the outside could send virus to the adress and compromise the terminal.

I would instead set up some own secure system for importing and exporting material from the computer. This system can then be restricted in ways to prevent leaking of information, for example mandatory encryption or restricted to a set of import or export email adresses. This solution should preferable be hosted locally, so the access to the service can be tightly controlled and be limited to the secure terminal only.

I would also suggest using a secure browser based system, like WebConverger, to prevent compromise. WebConverger is OpenSource and can easily be modified in the boot API to allow booting into secure local websites, without having to use the config service. WebConverger is actually made with public terminals in mind, so the system is protected against local compromise aswell, so even if a rogue user infront of terminal tries to compromise it, it will stand against it.

Instead of using Libreoffice, I would suggest using a web-based office system, preferable hosted locally, that is loaded inside the WebConverger.

And needless to say, block all traffic to all sites except for permitted ones. I would suggest not using a proxy for this, instead, use a firewall, and filter by IP-adress instead, by permitting all good sites and then finishing with a "BLOCK ALL".

Preferable, its a good idea to use the hosts file to code all the good sites, and then set the DNS IP to 127.0.0.1 Then you can block all DNS traffic, so no "tunneling" of traffic can be done.

But one thing I would suggest: Use a secure USB memory that do have a write-protect switch, like Kanguru FlashTrust: https://www.kanguru.com/storage-accessories/kanguru-flashtrust-secure-firmware.shtml

On this memory, you store the operating system, in the form of a "live operating system", that permit no modifications to be stored between boots. After initial configuration is done, the memory is simply locked with the write-protect switch.

The whole computer, must then be put into a lockable enclosure or secure location, such as the actual computer is not physically accessible by the end users. This prevents all usage of end user USB memories and such. This can be accomplished either by simply using a anti-theft-cage that does not permit access to the computer's IO ports once the enclosure is locked, or you can tuck away the computer in a server room and use a KVM-over-Ethernet solution to place a secure display, keyboard and mouse in the secure room.

Another security measure I would suggest, is that you wire up the access system (many access control systems today have additional IO relays that can be used to control equipment), so the following rules are used:

1: The door have a door sensor, like a magnetic contact or lock sensor, that can detect if the door is open or closed.

2: When someone swipes their card at the ENTRY terminal, the door will open. When the door closes successfully (with the user inside), the power to the terminal will be given by the relay. This can be accomplished by simply using a low-voltage computer system like INTEL NUC, and then using the relay to switch on and off the low voltage side of the transformer.

3: The power LED of the computer, is wired to the access control's "BUSY" input, which will disallow entry to the room while the computer is on.

4: After a set period of inactivity, like 10 minutes, the computer will shut off itself (halt) and this will clear the "BUSY" signal, allowing access to the room again, for example if a user accidentially closes the door without entering.

5: When a user swipes the card at the EXIT terminal, the system will power off the system automatically by just cutting power, and then unlock door.

The good thing with this, is that the terminal will be guranteed clean when a user enters the room, no matter what the previous or a rogue user installed or compromised or did whatever to the terminal, any such tampering will be gone.

No logon system or authentication system is needed on the computer. All authentication is physically handled by the access control system, which can also be hooked up to a alarm panel to prevent any attempt of "hacking" the secure computer. If you want some sort of access control to different sets of information depending on which user is on computer, then most access control panels do have a API where you can check whoever is inside the room (user which swiped at ENTRY latest but not yet at EXIT), and thus use that for access control.

By doing this, you will prevent most forms of compromise. Its better to use technical solutions to prevent the user from violating the policies instead of having policies.

And a last thing: Drop the wifi. Even if a wifi can be made secure with encryption and VPN's, you gain much more control if you use physical cables, like you gain much more control with physical locks.

1
  • This is interesting but I think I wasn't clear enough on the intent of these measures: I'm not concerned here with defending against deliberate leaks by insiders, though of course that's a real problem, and a tough one to defend against. Also, I didn't mean to restrict the threats addressed to pure information leaks, but to multiple forms of abuse that could follow after exploits either via local execution of malware or web-based holes (at the least I was quite unclear in my question on that point, apologies). Commented Dec 21, 2015 at 0:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .