The need of a bank and voting are two different security models.
Between you and the bank, the bank is one "party" and all transactions going to them can be a black box. So, as far as the user is concerned, proper TLS/SSL is needed, as well as website security. Everything else is the bank's problem.
Voting is a different thing altogether. You have the party that made the machines, you have the county, you have the volunteers deploying the voting machines, and you have the voting public. Unlike a bank where physical data security is assured, voting machines have to factor that into account.
What really needs to be done is have the machine be similar to the old, mechanical voting machines that punch a ballot before sending it on its way. A ballot that is easily machine and human readable should be printed, the user look at over, then toss the ballot in the box (and physical ballot box security is a solved problem for almost all intents.)
For proof that a ballot was counted, the cryptographer David Chaum proposed a verifiable voting system that would ensure that one's vote did get counted, but the person would remain anonymous.
I have seen the term "vault" used quite loosely. To me, a true "vault" is something as described above -- has secure HVAC, fire, and electric routing, and has a door that is at least 15-30 minutes resistant to heavy duty power tools (TL-15/TL30.)
However, this word is used in computing. In Netbackup the term "vaulting" is used for copying data from one set of media to another, so if a restore comes in, and a disk doesn't have it, it will know to go fetch a tape out of a silo.
I've also seen the term "digital vaults" to point to devices like Isilons or Avamars... NAS models that have some faculty for tamper resistance, even if an attacker gets root. It isn't as secure as a silo using WORM media [1], but it passes muster for HIPAA and other regulations.
[1]: Of course, HDDs and SSDs have zero archival warranty, while tapes have 30+ years guaranteed archival life, but having data online is more important than having the ability to retrieve the data in most businesses, so deduplication appliances like Avamars wind up being used.
An airline pilot has a lot more time (in general) to move a plane, and they have had thousands of hours of training, and may more in the cockpit.
A driver, assuming he/she isn't drunk, stoned, texting, KO-ed on K2, or watching a movie, is not going to have the reaction times to realize the autonomous system just went TU, and they have to put down their tablet, set their beer down, and actually get through a dangerous situation
IMHO, Google's philosophy is the best here. Treat a self-driving car as a gestalt, from the ground up. Not just do it piecemeal, but have a vehicle that is designed to need zero operator intervention, even when things go pointy end up.
I have encountered a wide spectrum of administration styles, from "unless it has an IT sticker on it, has all the corpware and can be managed by domain GPOs, it doesn't get near a Wi-Fi AP or a switch" to "Here is your subnet/subdomain in DNS, if something happens, don't blame us."
Some autonomy is good. If a network is isolated from everything else [1], with an IDS/IPS watching the exit traffic just in case there is an infection, someone can be notified if it wasn't part of a test, then if the segment gets pwned, the damage is limited. Ideally, there should be some protection in place so it doesn't fall to the uni's IT department to send notes to the profs that their network segment and boxes on it belong to some organization out of Lower Elbonia, or ransomware doesn't destroy work being done for a grant. However, it is a tough balance. Turn the screws too tight, nothing gets done,
[1]: Really isolated, so there isn't a chance of island-hopping.
Those devices either wipe a value, or perhaps blow eFuses to disable circuits permanently.
It is a new level of paranoia, but having the ability to physically destroy a chip without resorting to electrical arcing, shorts, explosives, or other means which can cause big problems where intrinsic safety is needed, is a true innovation.
I can see this quite useful in a few consumer products:
1: An IronKey-like hardware encrypting USB flash drive, with a clear window showing the chip. If the chip is shattered, it will be obvious.
2: A physical tamper-resistant seal. The chip could use a fiber optic cable wrapped around an object, and if it detects a break, it shatters.
3: A replacement for a "Tip & Tell" sensor. The large crate, if tipped over will have the chip shatter, and if the chip is part of a RFID system, the damaged crate can be easily located.
4: Part of a TPM chip. If a machine is physically moved outside of a geofence, the chip shatters, making recovery of the main hard disk key impossible (well, until one types in the recovery code.)
5: Part of a SSD that is for securing sensitive data. If the SSD's driver doesn't send a watchdog pulse in "x" amount of time, shatter the chip.
In general, a "seal" is the ideal type of use for this chip.
Isn't Docker OS agnostic, where a container can be sitting on a Linux box, or a Windows Server 2016 machine (when the OS goes RTM) that either runs the container in the current VM, or spawns a VM using Hyper-V for it.
To me, I read/hear about how great it is for applications to be in the neat little vacuum beds that Docker provides... but the fact that UID root in the container is UID root in the underlying machine or VM is concerning. At least MS solves this by giving the option to put containers in their own VMs with a mini version of Windows.
RADIUS or LDAP are close, but the goal is something extremely simple and fast that can handle tons of authentications. Sent a HTTP GET request with the ID and password, get the result back.
Looks like a chunk of my message got eaten. There is no known way to reset the Knox value back to 0x0, which allows the phone to use Samsung's pay system.
At first, I doubted this, but was reminded of Samsung Knox, and the eFuses which permanently blow on a device (no way . Thankfully the latest rooting/bootloader mods don't cause Knox to trip, but it is there, and likely will only get worse in future revs of the phone.
I was wondering that myself, since I was thinking of the fracture patterns in Prince Rupert Drops, and how an attacker could mount a DoS, similar to the old mainframe systems that permanently locked accounts after three wrong guesses [1].
There is also the impact/shock resistant element. Would the vibrations of car eventually cause enough microfractures to get the chip to shatter?
Of course, I'm guessing the use for this chip will be in applications where security is far more important than recoverability. The old and tired example of a nuclear weapon PAL comes to mind where it is better for the device to fail secure than to be operational. Another place where this would come in handy would be a cryptographic token or a HSM, which helps guarantee that the key stored remains secure, and that any of the tamper mechanisms dispatches the stored key.
However, will it beat the blackhats? Right now, satellite piracy is at 0%, so each iteration may not be the thing that solves the problem, but it keeps raising the bar from hobbyists to tiger teams, to large companies and nations. A good example of this are how each generation of consoles have evolved [2]. This won't stop everyone, but it will raise the bar in various applications, if only just because it assures that a remote self destruct is a physical destruction of media.
[1]: Those were "fun", especially when you had a former cow-orker who got moved to another department who liked locking people's IDs just for grins, prompting constant calls to the central switchboard to have the account reset (which meant you got a temporary password which you had to have force changed to a permanent PW that the system gives you.)
[2]: Ironic that for many years we were promised lower prices on games if people would stop pirating. However, with a 0% piracy rate on modern consoles, one pays noticably more for a game than they did (even adjusted for inflation) in the past, especially factoring in DLC (which usually is add-on content which should have been included in the game anyway.)
SELinux is quite similar. Root might let them out of the cell, but they are not getting out of the cellblock. However, the ideal is definitely a docker container, just because it can run anywhere.
The This is what AD and LDAP are for. This at least reduces the amount of passwords to a manageable level, mainly to environments. Of course, there are exceptions [1], but in general, SSO tends to be useful.
It isn't NFC card access, but the closest thing that comes in mind for this was something Blackberry offered back in 2008/2009, where the Blackberry device could function as a CAC/PIV card via a Bluetooth adapter.
What I'd be happy with would be a card that took the place of both a SD card and a SIM, and dual-SIM phones. This way, I'd have the ability to store stuff on each card, and each card would have an OTP generator with its own seed. An ideal would be some method of communication similar to client certificates for authentication, but it would have to have a robust mechanism of not being able to be MITM-ed or attacked during transit.
[1]: You want production boxes on their own AD domain, for example, so they can be locked up tighter than internal AD is done.
Pretty much. We have enough good people out there that act as goalie, preventing a lot of disasters. However, this is only a matter of time before we get an attack that is a perfect storm where the good guys were not able to stop it.
In the past, we have had two groups: People who had the will do do harm, and would do anything to do it, and people who had the way and knowledge to do harm... but who were not into hurting people as their primary reason of existing. However, as things change, we are starting to see this change. The Middle East is starting to rise as a source for constant cyberattacks, and as time goes on, we will start seeing parties with not just the ability to do damage, but the will, either to gain their organization "street cred", or for a political statement.
It is actually astounding that we have not had a disaster happen yet. Every terrorist group down to the gangbanger who is looking to earn cred for full "soldier" status with his droogies is chomping at the bit to be able to pull something like this off.
It would be nice if the salt was obfuscated somehow, or perhaps the username/password tuples were not just stored via hashes, but actually stored in a separate database, as locked down as humanly possible.
Since this database just matches an ID (this can be an arbitrary value, so a 256-512 bit nonce comes to mind) and a hash, the DB could actually be on a standalone appliance and just do nothing but return "yes, that user's PW is correct", "wrong password", "no user by that name", or "account locked -- too many PW guesses for that user in too short a time."
This might just be the best way to secure usernames/PWs -- have a secure appliance, similar to a HSM for private keys, but dedicated to authenticating usernames/PWs. This way, an attacker might be able to see that user "foo" maps to ID "12345", then try guessing a few passwords until the appliance returns the middle finger... but the attacker couldn't just grab the entire DB and start cracking on it.
The problem is that nobody gives a rat's ass until people wind up dying on a massive scale, as in the hundreds to thousands. Even hacking a jetliner isn't going to do the trick because people are starting to get used to them being dropped out of the sky.
The biggest issue is the perception that "security has no ROI", combined with "the hackers can get us no matter what we do". Both are BS. If one looks at physical security, even the liquor store in the no-man's-land neighborhood has more than adequate physical security to keep the booze inside after business hours. Physical security is good enough to keep unauthorized people out of a ton of places. Not 100%, but adequate. If PHBs did the same about physical security as they do about network security, we would see a thin rope around the data center door handles instead of card readers, with the PHBs whining to Congress that anyone determined could get inside no matter how think a rope they used, and showing how a dopehead loaded on Valkyr off the street was able to tear server racks off the floor.
The ironic thing is when I went with a friend of mine who was looking at a Ford, the Ford rep confirmed that nothing on the lot would work (and other dealerships didn't have the configuration needed), and offered to have it built to order from a spreadsheet with the list of options. The price was well under MSRP as well.
I'd probably say the sales rep or the dealer was full of it, and just were wanting to move inventory as opposed to make sales.
One trick I learned (as a rule of thumb) is to find more rural dealers, because dealers in a city core tend to be able to tell people to go pound sand, since there is always that person next in line. It also helps to go on a weekday.
I'll be on Windows Server 2016 before Windows 10. For someone who knows what they are doing, W2016 is a lot better, just because it ships with all but basic functionality off/uninstalled. Wi-Fi, Cortana, and a UI? All available via features, but not there by default.
IMHO, cloud storage is just another storage medium, like disks, tapes, DVDs, or printouts. It has its good points, and it has its shortcomings.
The trick is to use the cloud, but also have backup/storage locally. Take NetBackup. It isn't tough to configure it to go use S3, making sure all data is encrypted. You can do this as a secondary means of migrating data, as a primary storage method, or an archival method. Ideally, you want to dump data to a local storage device that uses SSD, just so backup windows can be short, then propagate the critical data to the cloud as need be, keeping everything else on local arrays.
Is the cloud the magic bullet for backups? No. Security, costs for WAN access, and other gotchas are present. However, as a storage medium, it is something useful to have.
With a rake and a tension wrench, it would be almost impossible to detect picking, much less have evidence that would stand up in court.
This is why it is wise to use seals for TSA stuff, and for non-TSA items, to use high security locks. Nothing is unpickable, but something like a late model Medeco3, Abloy, or Mul-T-Lock is going to either force an intruder to use physical force (which insurance is a lot more likely to cover), or find an easier target.
I also use a variation. On eBay, one can buy 50 of the padlock style seals, each with an individual number. I toss one on, log the number somewhere, and call it done. Yes, the seal -could- be duplicated, but it wouldn't be a casual effort, and if someone has the cash to duplicate the seal and its serial number exactly, I'm hosed anyway.
Of course, I've found that I'm best off using FedEx and sending all but my carryon stuff that way. I use a padlockable cooler, toss my stuff inside that, make sure it is well packed, padlock the corners, and let FedEx handle that. That way, the only thing I have to get at the destination airport is out of there.
In theory, it is a good thing to have that ability, so if someone loses their phone in an outhouse or it gets grabbed, it can be erased.
With iOS, iCloud backups combined with one's cloud provider of choice to back up photos/movies in real time helps here.
With Android, it is a bit harder. Google's restore mechanism is laughable, so to restore data, the best thing is to have a cloud provider for photos/movies, and use a backup utility like Titanium Backup which not just can back up apps... but actually encrypt them [1] and send the encrypted backups to the cloud provider of choice. Using utilities like nandroid also help.
For most people, losing a phone sucks, but it is far easier to back up a phone than it is a computer.
As for malware, it does require root, but xPrivacy and some type of app that is an iptables wrapper are musts. This way, if an app doesn't need to phone home, it can't, and even if it got permission to use the camera from initial install, xPrivacy will prompt the user (or just fetch the app's entry from a DB and auto-deny access) and let the user decide if the app requires access to cameras, phone contacts or both.
In any case, this app is just the first salvo with ransomware. Future ransomware versions will exploit Androids all or nothing permission model [2] and start sending pictures at random to contacts, slurping up contacts, grabbing or overwriting the SD card, impersonating a user via E-mail accounts, and other nastiness.
[1]: Titanium Backup actually has a pretty well thought out encryption mechanism. Each file is encrypted via a public/private key keypair, but the private key is stored with the file, and decrypted with the passphrase. This way, backups can be done and encrypted with the public key, while a restore requires the passphrase.
[2]: The selective permission model in the next Android rev only applies to app developers who allow it in the manifest, which most likely won't.
iOS is similar. The latest version of Android offers this... but only if the app maker allows it in the manifest. Otherwise, if you want to protect your camera, you physically do something with the phone or you use xPrivacy so the app has full and free reign to access what it thinks is the camera... but in reality is just getting a black screen.
Android's all or nothing permission model is the ecosystem's biggest weakness. How many users even care what the fleshlight app they downloaded use for permissions? Not many. If Google went with an prompt on first use model like Blackberry, it would have caused them a lot fewer headaches.
To me, the app has no purpose. Another communications medium for tracking behavior, taking people's messages, storing them indefinitely, and allowing virtually anyone access as per the TOS? No thanks.
There are so many mail/messaging protocols out there. Enterprise? Skype for Business/Lync. Old school? IRC and USENET. Common chat? SMS, MMS, XMPP. Wanting to blab to the public about how many coils pinched off in the morning? Web page. Then, there is always Facebook.
Using another messenger just makes no sense. This is why I don't bother with stuff like whatsapp and kik. Apps like that don't have the vetting of the EFF, so why bother? If they are not secure like Silent Circle's stuff, extremely popular like FB's messenger or SMS, or built on an open protocol like IRC or XMPP, a messenger app just isn't worth the time to bother with.
Then, there is the definition of secure messaging. If I need enterprise security (think BitLocker), I use Skype or Lync. If I need personal security (think TrueCrypt or VeraCrypt), then I use Wickr, PGP, or a combination of the two.
I'm not that well versed with Nearline, but Amazon Glacier has relatively high retrieval fees, so it would be something to use as a last resort, and something you have a very good index of, just to minimize the sheer amount of data that you have to pull from it.
I'd use Glacier as the archive of last resort, after all tapes, hard drives, and other items are found to be not usable.
Slashdot Mirror
The need of a bank and voting are two different security models.
Between you and the bank, the bank is one "party" and all transactions going to them can be a black box. So, as far as the user is concerned, proper TLS/SSL is needed, as well as website security. Everything else is the bank's problem.
Voting is a different thing altogether. You have the party that made the machines, you have the county, you have the volunteers deploying the voting machines, and you have the voting public. Unlike a bank where physical data security is assured, voting machines have to factor that into account.
What really needs to be done is have the machine be similar to the old, mechanical voting machines that punch a ballot before sending it on its way. A ballot that is easily machine and human readable should be printed, the user look at over, then toss the ballot in the box (and physical ballot box security is a solved problem for almost all intents.)
For proof that a ballot was counted, the cryptographer David Chaum proposed a verifiable voting system that would ensure that one's vote did get counted, but the person would remain anonymous.
I have seen the term "vault" used quite loosely. To me, a true "vault" is something as described above -- has secure HVAC, fire, and electric routing, and has a door that is at least 15-30 minutes resistant to heavy duty power tools (TL-15/TL30.)
However, this word is used in computing. In Netbackup the term "vaulting" is used for copying data from one set of media to another, so if a restore comes in, and a disk doesn't have it, it will know to go fetch a tape out of a silo.
I've also seen the term "digital vaults" to point to devices like Isilons or Avamars... NAS models that have some faculty for tamper resistance, even if an attacker gets root. It isn't as secure as a silo using WORM media [1], but it passes muster for HIPAA and other regulations.
[1]: Of course, HDDs and SSDs have zero archival warranty, while tapes have 30+ years guaranteed archival life, but having data online is more important than having the ability to retrieve the data in most businesses, so deduplication appliances like Avamars wind up being used.
Airline pilots != Joe Sixpack.
An airline pilot has a lot more time (in general) to move a plane, and they have had thousands of hours of training, and may more in the cockpit.
A driver, assuming he/she isn't drunk, stoned, texting, KO-ed on K2, or watching a movie, is not going to have the reaction times to realize the autonomous system just went TU, and they have to put down their tablet, set their beer down, and actually get through a dangerous situation
IMHO, Google's philosophy is the best here. Treat a self-driving car as a gestalt, from the ground up. Not just do it piecemeal, but have a vehicle that is designed to need zero operator intervention, even when things go pointy end up.
I have encountered a wide spectrum of administration styles, from "unless it has an IT sticker on it, has all the corpware and can be managed by domain GPOs, it doesn't get near a Wi-Fi AP or a switch" to "Here is your subnet/subdomain in DNS, if something happens, don't blame us."
Some autonomy is good. If a network is isolated from everything else [1], with an IDS/IPS watching the exit traffic just in case there is an infection, someone can be notified if it wasn't part of a test, then if the segment gets pwned, the damage is limited. Ideally, there should be some protection in place so it doesn't fall to the uni's IT department to send notes to the profs that their network segment and boxes on it belong to some organization out of Lower Elbonia, or ransomware doesn't destroy work being done for a grant. However, it is a tough balance. Turn the screws too tight, nothing gets done,
[1]: Really isolated, so there isn't a chance of island-hopping.
Those devices either wipe a value, or perhaps blow eFuses to disable circuits permanently.
It is a new level of paranoia, but having the ability to physically destroy a chip without resorting to electrical arcing, shorts, explosives, or other means which can cause big problems where intrinsic safety is needed, is a true innovation.
I can see this quite useful in a few consumer products:
1: An IronKey-like hardware encrypting USB flash drive, with a clear window showing the chip. If the chip is shattered, it will be obvious.
2: A physical tamper-resistant seal. The chip could use a fiber optic cable wrapped around an object, and if it detects a break, it shatters.
3: A replacement for a "Tip & Tell" sensor. The large crate, if tipped over will have the chip shatter, and if the chip is part of a RFID system, the damaged crate can be easily located.
4: Part of a TPM chip. If a machine is physically moved outside of a geofence, the chip shatters, making recovery of the main hard disk key impossible (well, until one types in the recovery code.)
5: Part of a SSD that is for securing sensitive data. If the SSD's driver doesn't send a watchdog pulse in "x" amount of time, shatter the chip.
In general, a "seal" is the ideal type of use for this chip.
Isn't Docker OS agnostic, where a container can be sitting on a Linux box, or a Windows Server 2016 machine (when the OS goes RTM) that either runs the container in the current VM, or spawns a VM using Hyper-V for it.
To me, I read/hear about how great it is for applications to be in the neat little vacuum beds that Docker provides... but the fact that UID root in the container is UID root in the underlying machine or VM is concerning. At least MS solves this by giving the option to put containers in their own VMs with a mini version of Windows.
RADIUS or LDAP are close, but the goal is something extremely simple and fast that can handle tons of authentications. Sent a HTTP GET request with the ID and password, get the result back.
Looks like a chunk of my message got eaten. There is no known way to reset the Knox value back to 0x0, which allows the phone to use Samsung's pay system.
At first, I doubted this, but was reminded of Samsung Knox, and the eFuses which permanently blow on a device (no way . Thankfully the latest rooting/bootloader mods don't cause Knox to trip, but it is there, and likely will only get worse in future revs of the phone.
I was wondering that myself, since I was thinking of the fracture patterns in Prince Rupert Drops, and how an attacker could mount a DoS, similar to the old mainframe systems that permanently locked accounts after three wrong guesses [1].
There is also the impact/shock resistant element. Would the vibrations of car eventually cause enough microfractures to get the chip to shatter?
Of course, I'm guessing the use for this chip will be in applications where security is far more important than recoverability. The old and tired example of a nuclear weapon PAL comes to mind where it is better for the device to fail secure than to be operational. Another place where this would come in handy would be a cryptographic token or a HSM, which helps guarantee that the key stored remains secure, and that any of the tamper mechanisms dispatches the stored key.
However, will it beat the blackhats? Right now, satellite piracy is at 0%, so each iteration may not be the thing that solves the problem, but it keeps raising the bar from hobbyists to tiger teams, to large companies and nations. A good example of this are how each generation of consoles have evolved [2]. This won't stop everyone, but it will raise the bar in various applications, if only just because it assures that a remote self destruct is a physical destruction of media.
[1]: Those were "fun", especially when you had a former cow-orker who got moved to another department who liked locking people's IDs just for grins, prompting constant calls to the central switchboard to have the account reset (which meant you got a temporary password which you had to have force changed to a permanent PW that the system gives you.)
[2]: Ironic that for many years we were promised lower prices on games if people would stop pirating. However, with a 0% piracy rate on modern consoles, one pays noticably more for a game than they did (even adjusted for inflation) in the past, especially factoring in DLC (which usually is add-on content which should have been included in the game anyway.)
SELinux is quite similar. Root might let them out of the cell, but they are not getting out of the cellblock. However, the ideal is definitely a docker container, just because it can run anywhere.
The This is what AD and LDAP are for. This at least reduces the amount of passwords to a manageable level, mainly to environments. Of course, there are exceptions [1], but in general, SSO tends to be useful.
It isn't NFC card access, but the closest thing that comes in mind for this was something Blackberry offered back in 2008/2009, where the Blackberry device could function as a CAC/PIV card via a Bluetooth adapter.
What I'd be happy with would be a card that took the place of both a SD card and a SIM, and dual-SIM phones. This way, I'd have the ability to store stuff on each card, and each card would have an OTP generator with its own seed. An ideal would be some method of communication similar to client certificates for authentication, but it would have to have a robust mechanism of not being able to be MITM-ed or attacked during transit.
[1]: You want production boxes on their own AD domain, for example, so they can be locked up tighter than internal AD is done.
Pretty much. We have enough good people out there that act as goalie, preventing a lot of disasters. However, this is only a matter of time before we get an attack that is a perfect storm where the good guys were not able to stop it.
In the past, we have had two groups: People who had the will do do harm, and would do anything to do it, and people who had the way and knowledge to do harm... but who were not into hurting people as their primary reason of existing. However, as things change, we are starting to see this change. The Middle East is starting to rise as a source for constant cyberattacks, and as time goes on, we will start seeing parties with not just the ability to do damage, but the will, either to gain their organization "street cred", or for a political statement.
It is actually astounding that we have not had a disaster happen yet. Every terrorist group down to the gangbanger who is looking to earn cred for full "soldier" status with his droogies is chomping at the bit to be able to pull something like this off.
It would be nice if the salt was obfuscated somehow, or perhaps the username/password tuples were not just stored via hashes, but actually stored in a separate database, as locked down as humanly possible.
Since this database just matches an ID (this can be an arbitrary value, so a 256-512 bit nonce comes to mind) and a hash, the DB could actually be on a standalone appliance and just do nothing but return "yes, that user's PW is correct", "wrong password", "no user by that name", or "account locked -- too many PW guesses for that user in too short a time."
This might just be the best way to secure usernames/PWs -- have a secure appliance, similar to a HSM for private keys, but dedicated to authenticating usernames/PWs. This way, an attacker might be able to see that user "foo" maps to ID "12345", then try guessing a few passwords until the appliance returns the middle finger... but the attacker couldn't just grab the entire DB and start cracking on it.
The problem is that nobody gives a rat's ass until people wind up dying on a massive scale, as in the hundreds to thousands. Even hacking a jetliner isn't going to do the trick because people are starting to get used to them being dropped out of the sky.
The biggest issue is the perception that "security has no ROI", combined with "the hackers can get us no matter what we do". Both are BS. If one looks at physical security, even the liquor store in the no-man's-land neighborhood has more than adequate physical security to keep the booze inside after business hours. Physical security is good enough to keep unauthorized people out of a ton of places. Not 100%, but adequate. If PHBs did the same about physical security as they do about network security, we would see a thin rope around the data center door handles instead of card readers, with the PHBs whining to Congress that anyone determined could get inside no matter how think a rope they used, and showing how a dopehead loaded on Valkyr off the street was able to tear server racks off the floor.
The ironic thing is when I went with a friend of mine who was looking at a Ford, the Ford rep confirmed that nothing on the lot would work (and other dealerships didn't have the configuration needed), and offered to have it built to order from a spreadsheet with the list of options. The price was well under MSRP as well.
I'd probably say the sales rep or the dealer was full of it, and just were wanting to move inventory as opposed to make sales.
One trick I learned (as a rule of thumb) is to find more rural dealers, because dealers in a city core tend to be able to tell people to go pound sand, since there is always that person next in line. It also helps to go on a weekday.
I'll be on Windows Server 2016 before Windows 10. For someone who knows what they are doing, W2016 is a lot better, just because it ships with all but basic functionality off/uninstalled. Wi-Fi, Cortana, and a UI? All available via features, but not there by default.
IMHO, cloud storage is just another storage medium, like disks, tapes, DVDs, or printouts. It has its good points, and it has its shortcomings.
The trick is to use the cloud, but also have backup/storage locally. Take NetBackup. It isn't tough to configure it to go use S3, making sure all data is encrypted. You can do this as a secondary means of migrating data, as a primary storage method, or an archival method. Ideally, you want to dump data to a local storage device that uses SSD, just so backup windows can be short, then propagate the critical data to the cloud as need be, keeping everything else on local arrays.
Is the cloud the magic bullet for backups? No. Security, costs for WAN access, and other gotchas are present. However, as a storage medium, it is something useful to have.
With a rake and a tension wrench, it would be almost impossible to detect picking, much less have evidence that would stand up in court.
This is why it is wise to use seals for TSA stuff, and for non-TSA items, to use high security locks. Nothing is unpickable, but something like a late model Medeco3, Abloy, or Mul-T-Lock is going to either force an intruder to use physical force (which insurance is a lot more likely to cover), or find an easier target.
I also use a variation. On eBay, one can buy 50 of the padlock style seals, each with an individual number. I toss one on, log the number somewhere, and call it done. Yes, the seal -could- be duplicated, but it wouldn't be a casual effort, and if someone has the cash to duplicate the seal and its serial number exactly, I'm hosed anyway.
Of course, I've found that I'm best off using FedEx and sending all but my carryon stuff that way. I use a padlockable cooler, toss my stuff inside that, make sure it is well packed, padlock the corners, and let FedEx handle that. That way, the only thing I have to get at the destination airport is out of there.
In theory, it is a good thing to have that ability, so if someone loses their phone in an outhouse or it gets grabbed, it can be erased.
With iOS, iCloud backups combined with one's cloud provider of choice to back up photos/movies in real time helps here.
With Android, it is a bit harder. Google's restore mechanism is laughable, so to restore data, the best thing is to have a cloud provider for photos/movies, and use a backup utility like Titanium Backup which not just can back up apps... but actually encrypt them [1] and send the encrypted backups to the cloud provider of choice. Using utilities like nandroid also help.
For most people, losing a phone sucks, but it is far easier to back up a phone than it is a computer.
As for malware, it does require root, but xPrivacy and some type of app that is an iptables wrapper are musts. This way, if an app doesn't need to phone home, it can't, and even if it got permission to use the camera from initial install, xPrivacy will prompt the user (or just fetch the app's entry from a DB and auto-deny access) and let the user decide if the app requires access to cameras, phone contacts or both.
In any case, this app is just the first salvo with ransomware. Future ransomware versions will exploit Androids all or nothing permission model [2] and start sending pictures at random to contacts, slurping up contacts, grabbing or overwriting the SD card, impersonating a user via E-mail accounts, and other nastiness.
[1]: Titanium Backup actually has a pretty well thought out encryption mechanism. Each file is encrypted via a public/private key keypair, but the private key is stored with the file, and decrypted with the passphrase. This way, backups can be done and encrypted with the public key, while a restore requires the passphrase.
[2]: The selective permission model in the next Android rev only applies to app developers who allow it in the manifest, which most likely won't.
iOS is similar. The latest version of Android offers this... but only if the app maker allows it in the manifest. Otherwise, if you want to protect your camera, you physically do something with the phone or you use xPrivacy so the app has full and free reign to access what it thinks is the camera... but in reality is just getting a black screen.
Android's all or nothing permission model is the ecosystem's biggest weakness. How many users even care what the fleshlight app they downloaded use for permissions? Not many. If Google went with an prompt on first use model like Blackberry, it would have caused them a lot fewer headaches.
It does advance the concept of the paperless office, though.
To me, the app has no purpose. Another communications medium for tracking behavior, taking people's messages, storing them indefinitely, and allowing virtually anyone access as per the TOS? No thanks.
There are so many mail/messaging protocols out there. Enterprise? Skype for Business/Lync. Old school? IRC and USENET. Common chat? SMS, MMS, XMPP. Wanting to blab to the public about how many coils pinched off in the morning? Web page. Then, there is always Facebook.
Using another messenger just makes no sense. This is why I don't bother with stuff like whatsapp and kik. Apps like that don't have the vetting of the EFF, so why bother? If they are not secure like Silent Circle's stuff, extremely popular like FB's messenger or SMS, or built on an open protocol like IRC or XMPP, a messenger app just isn't worth the time to bother with.
Then, there is the definition of secure messaging. If I need enterprise security (think BitLocker), I use Skype or Lync. If I need personal security (think TrueCrypt or VeraCrypt), then I use Wickr, PGP, or a combination of the two.
I'm not that well versed with Nearline, but Amazon Glacier has relatively high retrieval fees, so it would be something to use as a last resort, and something you have a very good index of, just to minimize the sheer amount of data that you have to pull from it.
I'd use Glacier as the archive of last resort, after all tapes, hard drives, and other items are found to be not usable.