Symantec Encryption Desktop does exactly this. Sits in the systray, click on it, and it can encrypt/decrypt the clipboard contents, files, and other stuff.
There used to be a few other products in Windows that can do this, but almost all projects except for GPG4Win have died off.
S/MIME is better than nothing, but if a CA gets compromised, it is worthless. OpenPGP is a superset of S/MIME, because it can support a real web of trust, not just assuming one key is 100% trustworthy.
I prefer to pack my own parachute, and if one does keysigning parties properly, it ensures that knowing other people's key IDs is as iron-clad as one can get.
It is commercial, but I've been using PGP Desktop (now Symantec Encryption Desktop) going on decades, and it is available for Windows and Macs. Main reason is that it is easy to copy some stuff, hit a key, instantly sign/encrypt/decrypt/validate it, then read or paste it. PGP Desktop also supports smart cards, which are the way to go when it comes to protecting one's private key (malware can only force the smart card to sign/decrypt, and not slurp the key up.)
It offers plugins for Outlook. For Thunderbird, Enigmail is useful as well.
Everyone worries about different things. For what I am concerned about, PGP Desktop works fine, but other people may not trust a commercial application intended for the enterprise.
I'm confused here, so going to try to untangle a few things:
1: From the TFA, FB will take a copy of your public key, and use it to optionally send its messages PGP/gpg signed or signed and encrypted.
2: It will allow others to fetch a copy of your PGP/gpg key.
I don't see where it does any encryption/decryption with one's private key. That is still handled by a plugin in the user's MUA or manual copy/paste into a PGP/gpg application.
The only thing FB can do is replace Alice's key with Charlie's and try to actively MITM... but if Alice and Bob previously set up a WoT through another channel or a keysigning party, this would be detected immediately when Bob pulls Alice's key from FB, and it isn't the one he signed. I seriously doubt FB would do this because people using PGP/gpg are already vigilant and dustrustful in nature, so would detect this at once.
All and all, I give kudos to FB for offering this. It is a security gain for everyone.
For most people, there are not many easy to use tools to use PGP/gpg encryption. The easiest I've found is Symantec's Encryption Desktop (formerly PGP Desktop), and enigmail is decent, but in general, getting people to not just make a key, but have a usable web of trust that they can use with friends.
Even with the technical issue solved, similar to how encryption via S/MIME is just a matter of clicking a button in Outlook, it is a tough thing to get people to bother with encryption.
Maybe it is just me, but with people willing to spill their guts out to the world each day onto social networks, down to the photos of how many coils they pinched off in the morning, there isn't an interest in security as there was with people back in the 1990s. A lot of people I know (and this spans a number of age ranges) just have zero concern about privacy, and assume the "hackers" will get their info anyway.
The goal is to have something that isn't limited to a device. This lessens the amount of code that is locked to one make, or even worse, one model. It also reduces the chance of security issues, since one company's EncFS implementation may be brain dead, while another's is quite up to par with security.
Same with device encryption. If each maker did its own thing with regards to encrypting/data, it would be difficult to make a ROM for that platform that would be up to par with security. At best, a factory ROM would have to have everything disassembled and the pieces used (with a lot of testing and even more luck) for the feature to work.
The more security in base Android, the better. This at least provides a baseline that we know is good. For example, we know any Android 4.x and 5.x device offers encryption of/data, and 5.x devices -should- encrypt that filesystem automatically (although there are exceptions.)
Limiting code to one make/model isn't good. For example, there are features of my old Atrix 2 which no new phones have, and likely would never have.
I wouldn't mind something along the lines of XPrivacy (or on iOS, Protect My Privacy) being integrated into Android where if a legacy app wants data, instead of getting an error, it gets bogus information. That way, some generic fleshlight app that asks for everything under the sun including root will be able to fetch data... but it will be all bogus. The ad ID, IMEI, location, username, accounts, list of stashed music, and pictures? Sure, it is valid data, but useless.
Lots of evolutionary fixes. The privacy stuff is better than nothing... but still all of nothing with legacy apps. The fingerprint standardization is good, because it allows an app that keeps keys to have an easy way to validate that the user is authorized.
Mobile payment - works with credit cards, as opposed to ACH debits, so thumbs up there. This means there is some way of rolling back fraudulent charges should something happen. With ACH based mechanisms, once the crook sucks the money out, there is little or nothing one can do.
Of course, there is one thing missing -- a standardized way to encrypt data on SD cards. Yes,/data is protected, but each device maker has their own way of securing SD card data. What is needed is protection similar to Blackberries in the past:
1: Offer compatibility with vfat and exFAT filesystems, by using loopback encryption (EncFS), as well as adding UNIX permissions via UMSDOSFS to keep apps separated. UMSDOSFS hasn't been used in ages... but is ideal for enforcing basic UNIX permissions while allowing for MS-DOS based filesystems to be used underneath.
2: Encrypt the entire SD card's partitions entirely similar to how/data is encrypted. This is the ideal choice, but it keeps the card from being able to be popped out and used with other devices.
RVs tend to have two rails. A 12 volt set of circuits, and 120 VAC. However, because it is only 3-4 meters at most, one can get away with using low-amp appliances on that rail.
A house, with its far longer runs should be on 120 for everything, and if 12 volts is needed... put a rectifier in the room. No need to use big fat meth-head attracting cables.
If one wants the advantage of clean power without needing a power supply for every box... this is a long since solved problem. Telcos have been using 48VDC and NEBS compliant machines for decades.
Even with a few meters, it will require fat, all copper cables (A/C, one can use CCA due to the skin effect.) These are not cheap, and even the big fat ones are not run for more than a few feet.
As an RV-er, I'm familar with both 12 volt and 120 volt systems. For a LED TV or other low wattage appliance, 12 volt is better, just because it directly comes from the batteries. However, for a load like a microwave, A/C, heater, or anything above 300 watts, trying to run that on 12 volts would require very fat, expensive cable. High amperage DC stuff is expensive too. For example, since there are no zero crossings of the electricity, a switch needs to be made quite beefy to handle the arcing when being turned on and off.
USB-C can provide 100 watts is because it steps up the voltage, up to 48 volts. If the connector was trying to provide 25 amps at 5 volts via the thin little wires, they would arc into gas almost immediately.
To boot, with physical security, intruders can get shot. However, if an attacker is going after your stuff via the Internet, there isn't much one can do back to hurt them, especially if they are in a country that doesn't like your home nation. It is a purely defensive war, where a victory can't be obtained, but only mitigating or avoiding a defeat.
However, we do have one thing on our side when it comes to computer security... the air gap. Not 100% secure (as Stuxnet showed), but it forces an attacker to put boots on the ground and deal with physical defenses. Next to the airgap are separated networks (NIPRNet/SIPRNet) that run on distinct leased lines as opposed to just going over Internet VPNs.
For a while after 2001, there were auditors and "security consultants" (described best by another/. poster as "suit wearing chatter monkeys") which would do their job by chucking existing solutions and installing Windows, saying that Linux isn't "Sarbanes Oxley compliant." Thankfully this has gone to a dull roar... but in general, it still remains that an OS with FIPS, Common Criteria, EAL 3, and other certifications is going to be a lot more auditor friendly than one that doesn't.
I probably would say that an insurance company denying claims is likely the -only- way we (as proles) will ever see most companies start taking proper precautions [1] in keeping their barn doors closed. Regulations won't happen, lawsuits won't do much other than make lawyers rich, and even with bad PR, people will forget about it. Already, all but/. readers have pretty much forgotten about the Sony breaches, because the news media is covering the sins of the Duggar family.
[1]: Nothing is 100% secure, but proper security precautions are not hard to implement. Disk encryption for laptops is trivially easy. If proper routers are too expensive, a PC with a bunch of NICs and PfSense can do the job for a smaller installation.
One has to be more specific than "firewalls" and "encryption" as well. I can put up a Linux box, use LUKS for all partitions except the kernel, stuff a rule in nftables, and I can claim I have both "firewalls" and "encryption".
However, does that mean an intruder from the outside is locked out. Hardly. The disk encryption means nothing when the volume is mounted and the data is being copied from remote.
What is really needed is going beyond generalities, but having a specific set of guidelines. FISMA comes to mind on this because part of the spec by NIST are security checklists and guidelines by OS and device. With a standard like this [1], it is easier to gauge if a company or organization is in compliance, has issues, or just completely fails.
Some guidelines also have varying levels of security, because not every machine needs to be at a "high" security level. As stated above, guidelines are not just about what settings are in an OS, but training with people, and basic physical security. Things like waving your badge at the door even though the door is open make significant security differences.
[1]: Most of it is obvious, like putting your VMWare management NICs on an isolated network, similar with the SAN management ports... but some of it might be useful. AppLocker in Windows comes to mind.
The blessed fob idea could be used for a lot more than that, assuming BT or NFC connections (for short range items.) Not just for the network connections, but for things like recovering a lost password on a machine.
As you said, the concept of a physical key is a lot more common, and intuitive to a lot of people, so that might be a way of doing security on a home user basis.
No, this isn't perfect... but it would help immensely with security and close a lot of remote attack holes.
I wish more routers came either with a local method of configuration (an onboard touchscreen display like a lot of LTE Wi-Fi routers, USBSerial, or perhaps just a good old fashioned serial port, with a USB dongle and cable.) From there, one could configure some form of 2FA, which does mitigate the aspect of a compromised PC or network.
What needs to be implemented on a POS terminal, if it has to run Windows, is AppLocker and other policy restrictions. I'd say even add DeepFreeze, so that if the terminal gets in some screwy state, a power cycle gets it back to normal. Updates can be handled by various mechanisms, be it a WSUS server if there are a lot of terminals, a USB flash drive with an installer on it, to get a machine to a known good patch level, or even a fresh image of the OS that gets copied over, which reads the terminals config files stashed on a separate volume.
AppLocker or something that blocks executables would have stopped this attack cold.
I do see a lot of XPe (XP Embedded) point of sale installations around my neck of the woods.
Cash registers have two odd quantities. On one hand, they need good security. On the other hand, they may need to keep up with the latest things. At the minimum, EMV credit cards, but things like various payment items from a cellphone are can be needed as well.
Maybe POS machines should be split up into two VMs:
One part does the item totaling, inventory, calculations, purchase/returns, and other parts which stay pretty much static. Even EMV credit card processing can be added here.
The second VM would be just for handling the latest and greatest e-pay stuff, be it ISIS, SoftCard, PayPal, Google Wallet, Apple Wallet, CurrenC, Bitcoin, AltCoin, Namecoin, DogeCoin, pyreals, gil, ounces of precious metals, platinum pieces, and so on. This VM pretty much gets the total transaction amount from the other VM, and does a purchase, audit, or return.
Add a decent hypervisor coupled with a decent snapshot/backup mechanism, and this would provide adequate security and separation of functions.
Done right, it can be done relatively seamlessly, and would limit what happens if one side gets compromised.
My HTC One M8 has an Extreme Power Saving mode which replaces the Launcher, drops all network connections, and only allows a few basic functions to work. Not sure how long it will last, but easily over a week.
Or use a VM with snapshots or change logs, and when done, roll back all changes, so no matter how much the browser tries to stash, all gets eradicated.
It also works well to deal with compromised browsers, especially if the VM is run in its own NAT segment, so the compromised instance can't gain knowledge of network topology.
I actually paid for Netscape because it was a good browser at the time.
If the Mozilla Foundation needs cash, maybe a commercial browser may not be a bad idea, especially if it had enterprise level items like being able to be shipped as a.MSI, updated from an internal server like WSUS (not all internal machines have access to the Net in a lot of companies), offered GPO-like functionality to allow for insertion of internal keys, allowed for a recovery mechanism to the security key store, and so on.
This may not mean much to the average consumer, but a supported browser version that can be managed by IT quite well might be a good revenue source, especially with it being platform independent.
Similar with Thunderbird and SeaMonkey. Other than Outlook and mail.app, there are not many good MUAs out there these days. Eudora is dead, and the Bat and Lotus Notes are niche products. Having an alternative to Outlook might be a good thing for businesses, especially if enterprise level management/update functionality could be added in.
If it is sitting empty on Windows 8.1, it is being used for read/write cache by the OS. Same with Linux.
With RAM as relatively inexpensive as it is today, one shouldn't have less than 16-32 GB of RAM on a desktop, especially if one is using virtualization, sandboxing, or other type of container usage to keep their Web browser separate from their sensitive stuff [1].
[1]: In fact, it doesn't hurt to keep different things in separate VMs, and with SSD and a decent amount of RAM, the performance loss is negligable, while one gains a lot in security. Plus, it is easy to move to new hardware... just copy the VM's images to the new machine.
I like Android's customizability and the ability to replace things. For example, I toss the launcher and go with Nova's. The keyboard app gets replaced, and I use a custom texting app that supports encryption.
Plus, I have more privacy on Android with XPrivacy. For example, a lot of apps pull your ad info, IMEI, hardware serial number, and anything they can find for behavioral tracking. With XPrivacy, the app will happily get a number... but it will be a random one. I can also ad block on the IP level.
Newer phones respond to fstrim/blkdiscard, so one can use those tools to fire off TRIM commands, zeroing all data. For example, if one wants to ensure/data isn't available, one could do a blkdiscard of/data's device, or run fstrim on the mounted/data partition to have the SSD zero out all free pages. Similar with/system. Delete all extraneous data, mount it read-write, fstrim it.
The good news is that there are apps (which require root) which will modify SELinux so that the SD card is usable. Since most SD cards are using FAT32, there isn't any real way to enforce permissions, so for security reasons, the card wound up being locked from most apps completely.
Of course, it would be nice if the SD card could be formatted with ext4, so permissions could be enforced.
Another option, which was part of Linux, but pulled out a long time ago, was the UMSDOS filesystem. What this did was put Linux permissions and ACLs atop of FAT/FAT32. Yes, this was a kludge... but it worked without having any changes to the filesystem (other than the marker files) in place. This might be a way to go, since it would allow the phone to enforce app permissions on a filesystem that normally doesn't support it.
The Windows format command does this. If one uses it on a BitLocker encrypted volume, it will go and zero the parts on the volume that hold the BitLocker master key, so even if someone later has a recovery password, the data is still completely gone. Same with secure erase on a number of SSDs.
Since Android is sitting on a SSD, it might be wise to move to a smarter wiping system. One that would wipe the dm-crypt data, core places of the filesystem, and after that, TRIM the entire data partition before formatting and rebuilding it. The TRIM command helps ensure that the data present isn't recoverable at the drive level, and likely will get utterly destroyed when the drive erases the TRIMmed pages.
I read about some newer phones using a chip to store the encryption key for/data, similar to how iOS does it, but when hardware starts getting involved, it becomes harder to deal with a potential backdoor.
Maybe the ideal is a small bit of storage that is used, and if it is erased, the erasure is guarenteed (where there is no way to recover previously stored data.) Then, the master key is stored there. On initial bootup, the phone prompts the user for the PIN, decrypts the key stored on that small bit of storage for the master key to/data, and proceeds from there. On an erase,/data gets force unmounted, the small storage is erased, and a blkdiscard is issued for the/data's device. Not 100%, but it will pretty much ensure anything stashed in/data is gone.
Then there is the external SD card. Unlike/data, there isn't a real standard to encrypt that storage partition. Usually it winds up being encrypted on a file by file basis with some EncFS offshot. The key for this is stored in/data, so if the phone is wiped, there isn't any way to retrieve the SD card's data. What might be an idea would be to offer the file based mechanism, but also offer the ability to format the SD card and encrypt the entire card on a device level, not just on a file by file basis.
Of course, something like phonebookfs could be used so that someone looking at the encrypted file stash on the SD card can't tell between real data and randomly generated chaff, but that may not be something for mainstream phones.
Slashdot Mirror
Symantec Encryption Desktop does exactly this. Sits in the systray, click on it, and it can encrypt/decrypt the clipboard contents, files, and other stuff.
There used to be a few other products in Windows that can do this, but almost all projects except for GPG4Win have died off.
S/MIME is better than nothing, but if a CA gets compromised, it is worthless. OpenPGP is a superset of S/MIME, because it can support a real web of trust, not just assuming one key is 100% trustworthy.
I prefer to pack my own parachute, and if one does keysigning parties properly, it ensures that knowing other people's key IDs is as iron-clad as one can get.
It is commercial, but I've been using PGP Desktop (now Symantec Encryption Desktop) going on decades, and it is available for Windows and Macs. Main reason is that it is easy to copy some stuff, hit a key, instantly sign/encrypt/decrypt/validate it, then read or paste it. PGP Desktop also supports smart cards, which are the way to go when it comes to protecting one's private key (malware can only force the smart card to sign/decrypt, and not slurp the key up.)
It offers plugins for Outlook. For Thunderbird, Enigmail is useful as well.
Everyone worries about different things. For what I am concerned about, PGP Desktop works fine, but other people may not trust a commercial application intended for the enterprise.
I'm confused here, so going to try to untangle a few things:
1: From the TFA, FB will take a copy of your public key, and use it to optionally send its messages PGP/gpg signed or signed and encrypted.
2: It will allow others to fetch a copy of your PGP/gpg key.
I don't see where it does any encryption/decryption with one's private key. That is still handled by a plugin in the user's MUA or manual copy/paste into a PGP/gpg application.
The only thing FB can do is replace Alice's key with Charlie's and try to actively MITM... but if Alice and Bob previously set up a WoT through another channel or a keysigning party, this would be detected immediately when Bob pulls Alice's key from FB, and it isn't the one he signed. I seriously doubt FB would do this because people using PGP/gpg are already vigilant and dustrustful in nature, so would detect this at once.
All and all, I give kudos to FB for offering this. It is a security gain for everyone.
For most people, there are not many easy to use tools to use PGP/gpg encryption. The easiest I've found is Symantec's Encryption Desktop (formerly PGP Desktop), and enigmail is decent, but in general, getting people to not just make a key, but have a usable web of trust that they can use with friends.
Even with the technical issue solved, similar to how encryption via S/MIME is just a matter of clicking a button in Outlook, it is a tough thing to get people to bother with encryption.
Maybe it is just me, but with people willing to spill their guts out to the world each day onto social networks, down to the photos of how many coils they pinched off in the morning, there isn't an interest in security as there was with people back in the 1990s. A lot of people I know (and this spans a number of age ranges) just have zero concern about privacy, and assume the "hackers" will get their info anyway.
The goal is to have something that isn't limited to a device. This lessens the amount of code that is locked to one make, or even worse, one model. It also reduces the chance of security issues, since one company's EncFS implementation may be brain dead, while another's is quite up to par with security.
Same with device encryption. If each maker did its own thing with regards to encrypting /data, it would be difficult to make a ROM for that platform that would be up to par with security. At best, a factory ROM would have to have everything disassembled and the pieces used (with a lot of testing and even more luck) for the feature to work.
The more security in base Android, the better. This at least provides a baseline that we know is good. For example, we know any Android 4.x and 5.x device offers encryption of /data, and 5.x devices -should- encrypt that filesystem automatically (although there are exceptions.)
Limiting code to one make/model isn't good. For example, there are features of my old Atrix 2 which no new phones have, and likely would never have.
I wouldn't mind something along the lines of XPrivacy (or on iOS, Protect My Privacy) being integrated into Android where if a legacy app wants data, instead of getting an error, it gets bogus information. That way, some generic fleshlight app that asks for everything under the sun including root will be able to fetch data... but it will be all bogus. The ad ID, IMEI, location, username, accounts, list of stashed music, and pictures? Sure, it is valid data, but useless.
Lots of evolutionary fixes. The privacy stuff is better than nothing... but still all of nothing with legacy apps. The fingerprint standardization is good, because it allows an app that keeps keys to have an easy way to validate that the user is authorized.
Mobile payment - works with credit cards, as opposed to ACH debits, so thumbs up there. This means there is some way of rolling back fraudulent charges should something happen. With ACH based mechanisms, once the crook sucks the money out, there is little or nothing one can do.
Of course, there is one thing missing -- a standardized way to encrypt data on SD cards. Yes, /data is protected, but each device maker has their own way of securing SD card data. What is needed is protection similar to Blackberries in the past:
1: Offer compatibility with vfat and exFAT filesystems, by using loopback encryption (EncFS), as well as adding UNIX permissions via UMSDOSFS to keep apps separated. UMSDOSFS hasn't been used in ages... but is ideal for enforcing basic UNIX permissions while allowing for MS-DOS based filesystems to be used underneath.
2: Encrypt the entire SD card's partitions entirely similar to how /data is encrypted. This is the ideal choice, but it keeps the card from being able to be popped out and used with other devices.
RVs tend to have two rails. A 12 volt set of circuits, and 120 VAC. However, because it is only 3-4 meters at most, one can get away with using low-amp appliances on that rail.
A house, with its far longer runs should be on 120 for everything, and if 12 volts is needed... put a rectifier in the room. No need to use big fat meth-head attracting cables.
If one wants the advantage of clean power without needing a power supply for every box... this is a long since solved problem. Telcos have been using 48VDC and NEBS compliant machines for decades.
Even with a few meters, it will require fat, all copper cables (A/C, one can use CCA due to the skin effect.) These are not cheap, and even the big fat ones are not run for more than a few feet.
As an RV-er, I'm familar with both 12 volt and 120 volt systems. For a LED TV or other low wattage appliance, 12 volt is better, just because it directly comes from the batteries. However, for a load like a microwave, A/C, heater, or anything above 300 watts, trying to run that on 12 volts would require very fat, expensive cable. High amperage DC stuff is expensive too. For example, since there are no zero crossings of the electricity, a switch needs to be made quite beefy to handle the arcing when being turned on and off.
USB-C can provide 100 watts is because it steps up the voltage, up to 48 volts. If the connector was trying to provide 25 amps at 5 volts via the thin little wires, they would arc into gas almost immediately.
To boot, with physical security, intruders can get shot. However, if an attacker is going after your stuff via the Internet, there isn't much one can do back to hurt them, especially if they are in a country that doesn't like your home nation. It is a purely defensive war, where a victory can't be obtained, but only mitigating or avoiding a defeat.
However, we do have one thing on our side when it comes to computer security... the air gap. Not 100% secure (as Stuxnet showed), but it forces an attacker to put boots on the ground and deal with physical defenses. Next to the airgap are separated networks (NIPRNet/SIPRNet) that run on distinct leased lines as opposed to just going over Internet VPNs.
For a while after 2001, there were auditors and "security consultants" (described best by another /. poster as "suit wearing chatter monkeys") which would do their job by chucking existing solutions and installing Windows, saying that Linux isn't "Sarbanes Oxley compliant." Thankfully this has gone to a dull roar... but in general, it still remains that an OS with FIPS, Common Criteria, EAL 3, and other certifications is going to be a lot more auditor friendly than one that doesn't.
I probably would say that an insurance company denying claims is likely the -only- way we (as proles) will ever see most companies start taking proper precautions [1] in keeping their barn doors closed. Regulations won't happen, lawsuits won't do much other than make lawyers rich, and even with bad PR, people will forget about it. Already, all but /. readers have pretty much forgotten about the Sony breaches, because the news media is covering the sins of the Duggar family.
[1]: Nothing is 100% secure, but proper security precautions are not hard to implement. Disk encryption for laptops is trivially easy. If proper routers are too expensive, a PC with a bunch of NICs and PfSense can do the job for a smaller installation.
One has to be more specific than "firewalls" and "encryption" as well. I can put up a Linux box, use LUKS for all partitions except the kernel, stuff a rule in nftables, and I can claim I have both "firewalls" and "encryption".
However, does that mean an intruder from the outside is locked out. Hardly. The disk encryption means nothing when the volume is mounted and the data is being copied from remote.
What is really needed is going beyond generalities, but having a specific set of guidelines. FISMA comes to mind on this because part of the spec by NIST are security checklists and guidelines by OS and device. With a standard like this [1], it is easier to gauge if a company or organization is in compliance, has issues, or just completely fails.
Some guidelines also have varying levels of security, because not every machine needs to be at a "high" security level. As stated above, guidelines are not just about what settings are in an OS, but training with people, and basic physical security. Things like waving your badge at the door even though the door is open make significant security differences.
[1]: Most of it is obvious, like putting your VMWare management NICs on an isolated network, similar with the SAN management ports... but some of it might be useful. AppLocker in Windows comes to mind.
The blessed fob idea could be used for a lot more than that, assuming BT or NFC connections (for short range items.) Not just for the network connections, but for things like recovering a lost password on a machine.
As you said, the concept of a physical key is a lot more common, and intuitive to a lot of people, so that might be a way of doing security on a home user basis.
No, this isn't perfect... but it would help immensely with security and close a lot of remote attack holes.
Excellent idea.
I wish more routers came either with a local method of configuration (an onboard touchscreen display like a lot of LTE Wi-Fi routers, USBSerial, or perhaps just a good old fashioned serial port, with a USB dongle and cable.) From there, one could configure some form of 2FA, which does mitigate the aspect of a compromised PC or network.
What needs to be implemented on a POS terminal, if it has to run Windows, is AppLocker and other policy restrictions. I'd say even add DeepFreeze, so that if the terminal gets in some screwy state, a power cycle gets it back to normal. Updates can be handled by various mechanisms, be it a WSUS server if there are a lot of terminals, a USB flash drive with an installer on it, to get a machine to a known good patch level, or even a fresh image of the OS that gets copied over, which reads the terminals config files stashed on a separate volume.
AppLocker or something that blocks executables would have stopped this attack cold.
I do see a lot of XPe (XP Embedded) point of sale installations around my neck of the woods.
Cash registers have two odd quantities. On one hand, they need good security. On the other hand, they may need to keep up with the latest things. At the minimum, EMV credit cards, but things like various payment items from a cellphone are can be needed as well.
Maybe POS machines should be split up into two VMs:
One part does the item totaling, inventory, calculations, purchase/returns, and other parts which stay pretty much static. Even EMV credit card processing can be added here.
The second VM would be just for handling the latest and greatest e-pay stuff, be it ISIS, SoftCard, PayPal, Google Wallet, Apple Wallet, CurrenC, Bitcoin, AltCoin, Namecoin, DogeCoin, pyreals, gil, ounces of precious metals, platinum pieces, and so on. This VM pretty much gets the total transaction amount from the other VM, and does a purchase, audit, or return.
Add a decent hypervisor coupled with a decent snapshot/backup mechanism, and this would provide adequate security and separation of functions.
Done right, it can be done relatively seamlessly, and would limit what happens if one side gets compromised.
My HTC One M8 has an Extreme Power Saving mode which replaces the Launcher, drops all network connections, and only allows a few basic functions to work. Not sure how long it will last, but easily over a week.
Or use a VM with snapshots or change logs, and when done, roll back all changes, so no matter how much the browser tries to stash, all gets eradicated.
It also works well to deal with compromised browsers, especially if the VM is run in its own NAT segment, so the compromised instance can't gain knowledge of network topology.
I actually paid for Netscape because it was a good browser at the time.
If the Mozilla Foundation needs cash, maybe a commercial browser may not be a bad idea, especially if it had enterprise level items like being able to be shipped as a .MSI, updated from an internal server like WSUS (not all internal machines have access to the Net in a lot of companies), offered GPO-like functionality to allow for insertion of internal keys, allowed for a recovery mechanism to the security key store, and so on.
This may not mean much to the average consumer, but a supported browser version that can be managed by IT quite well might be a good revenue source, especially with it being platform independent.
Similar with Thunderbird and SeaMonkey. Other than Outlook and mail.app, there are not many good MUAs out there these days. Eudora is dead, and the Bat and Lotus Notes are niche products. Having an alternative to Outlook might be a good thing for businesses, especially if enterprise level management/update functionality could be added in.
If it is sitting empty on Windows 8.1, it is being used for read/write cache by the OS. Same with Linux.
With RAM as relatively inexpensive as it is today, one shouldn't have less than 16-32 GB of RAM on a desktop, especially if one is using virtualization, sandboxing, or other type of container usage to keep their Web browser separate from their sensitive stuff [1].
[1]: In fact, it doesn't hurt to keep different things in separate VMs, and with SSD and a decent amount of RAM, the performance loss is negligable, while one gains a lot in security. Plus, it is easy to move to new hardware... just copy the VM's images to the new machine.
I like Android's customizability and the ability to replace things. For example, I toss the launcher and go with Nova's. The keyboard app gets replaced, and I use a custom texting app that supports encryption.
Plus, I have more privacy on Android with XPrivacy. For example, a lot of apps pull your ad info, IMEI, hardware serial number, and anything they can find for behavioral tracking. With XPrivacy, the app will happily get a number... but it will be a random one. I can also ad block on the IP level.
Newer phones respond to fstrim/blkdiscard, so one can use those tools to fire off TRIM commands, zeroing all data. For example, if one wants to ensure /data isn't available, one could do a blkdiscard of /data's device, or run fstrim on the mounted /data partition to have the SSD zero out all free pages. Similar with /system. Delete all extraneous data, mount it read-write, fstrim it.
The good news is that there are apps (which require root) which will modify SELinux so that the SD card is usable. Since most SD cards are using FAT32, there isn't any real way to enforce permissions, so for security reasons, the card wound up being locked from most apps completely.
Of course, it would be nice if the SD card could be formatted with ext4, so permissions could be enforced.
Another option, which was part of Linux, but pulled out a long time ago, was the UMSDOS filesystem. What this did was put Linux permissions and ACLs atop of FAT/FAT32. Yes, this was a kludge... but it worked without having any changes to the filesystem (other than the marker files) in place. This might be a way to go, since it would allow the phone to enforce app permissions on a filesystem that normally doesn't support it.
The Windows format command does this. If one uses it on a BitLocker encrypted volume, it will go and zero the parts on the volume that hold the BitLocker master key, so even if someone later has a recovery password, the data is still completely gone. Same with secure erase on a number of SSDs.
Since Android is sitting on a SSD, it might be wise to move to a smarter wiping system. One that would wipe the dm-crypt data, core places of the filesystem, and after that, TRIM the entire data partition before formatting and rebuilding it. The TRIM command helps ensure that the data present isn't recoverable at the drive level, and likely will get utterly destroyed when the drive erases the TRIMmed pages.
I read about some newer phones using a chip to store the encryption key for /data, similar to how iOS does it, but when hardware starts getting involved, it becomes harder to deal with a potential backdoor.
Maybe the ideal is a small bit of storage that is used, and if it is erased, the erasure is guarenteed (where there is no way to recover previously stored data.) Then, the master key is stored there. On initial bootup, the phone prompts the user for the PIN, decrypts the key stored on that small bit of storage for the master key to /data, and proceeds from there. On an erase, /data gets force unmounted, the small storage is erased, and a blkdiscard is issued for the /data's device. Not 100%, but it will pretty much ensure anything stashed in /data is gone.
Then there is the external SD card. Unlike /data, there isn't a real standard to encrypt that storage partition. Usually it winds up being encrypted on a file by file basis with some EncFS offshot. The key for this is stored in /data, so if the phone is wiped, there isn't any way to retrieve the SD card's data. What might be an idea would be to offer the file based mechanism, but also offer the ability to format the SD card and encrypt the entire card on a device level, not just on a file by file basis.
Of course, something like phonebookfs could be used so that someone looking at the encrypted file stash on the SD card can't tell between real data and randomly generated chaff, but that may not be something for mainstream phones.