That is what one tries to avoid. The best is to have multiple blocking mechanisms. First is by IP address, so if someone is hacking user Alice's account, the site trying to hack in as Alice gets blocked on the IP level.
The hashing appliance is a work in progress. Either a delay between handing out replies for the same user or an outright lockout serve the same purpose. The trick is to slow down a dictionary attack, as well as make it difficult for an attacker to grab the list of user password hashes.
It is an easy way to go, but what I saw people do is log in just to make sure a legit user would be locked out.
Some old IBM systems would lock a user account indefinitely after 3-5 wrong guesses. So, what people would do for petty revenge is just type in the user name of someone they don't like, type in some wrong guesses, and that person's account is locked out until the next weekday when the IT staff comes in.
Instead, there needs to be multiple levels of lockout to prevent brute force guessing. The lowest level would be at the hash database server, where it would allow 10-20 wrong guesses before it would block access for 1-2 minutes (good enough to slow down brute force dictionary attacks, but not so long that it means a legit user is locked out forever.) From there, the app server would lock out access via IP ranges, say 15 minutes if there were 3+ guesses wrong. This way, if someone was coming from one IP range to guess passwords, it would not completely lock a legit user out who was coming from somewhere else.
I've been playing with a dedicated hash database that is on its own server, so hosts bounce a request off this appliance and get a "yes", "no", or "timeout". Too many "no"s in too short a time make the hash validation appliance refuse to give any answers for a period of time.
If done correctly, for someone to get the hash database, they would have to find a way to physically get access to the appliance, then dump the box. It isn't perfect (which is why a better algorithm like bcrypt should be used to store hashes), but having a layer of security whose sole purpose is to keep the list of hashes out of the hands of the blackhats means that after a breach is rectified, users are not forced to change all their passwords (unless their accounts were directly involved).
The key is to have the first store the user encounters, be it Google's, Amazon's, or an Android version of Cydia handle app security on a rigorous level. Of course, users should get the ability to swap to another store (and know the consequences of moving from an actively maintained store to a marketplace where malware enforcement is reactive, not proactive.) It is about expectations. People expect on iOS to be able to download everything and that it is safe for human consumption. Pretty much this has held true. People expect the same thing on Google Play, but don't realize that they are not dealing with the equivalent of a sterile big box store, but more of a flea market.
For Google's sake, the first store that comes up for a new user should be one that is tightly vetted. Then they should have the option of going to another store (knowing the consequences of doing so.)
Since most Android phones ship with Google's Play Store as the main store, Google's name is on the line when someone doesn't know any better and downloads a malware-ridden app, even though it isn't technically Google's fault in any way.
This is why for the previously suggested "top tier", Google should finance the time and money it takes to run a tight ship with a higher developer fee.
This doesn't mean to stop offering $25.00 for access to the Play Store, but it means that having a segment of the market where things are thoroughly vetted and found suitable consumption. Most people reading/. have enough sense to check permissions and check for bogus reviews before downloading and running, but unfortunately, people assume if they download an app from a store, it is safe. Google needs to meet this expectation, with the option of letting users to the wild west if they so choose.
If Google doesn't do this, users will leave the platform in droves once the horror stories start coming in about bank balances, bogus charges, and other stuff. This WILL happen when malware gets more sophisticated than just spamming SMS messages to contacts.
Android isn't like Windows where people tolerate the perception of no security in order to run their apps. There are other operating systems for devices that users can jump to, and when the users leave Android, so do the developers. This feedback cycle is killing RIM/Blackberry, and can easily kill Android if it isn't put in check.
This is one area where Android is above iOS. If an app's perms don't allow it to read contacts, unless it comes with a built in exploiter like rageinthecage or zergrush, the app is not going to be able to touch the contact list.
However, as stated above, people see the app on the Play Store, tap "Download", see some writing, then tap the button again to get the app. Then, for most users, the "fun" begins. Of course, with a rooted phone and DroidWall and/or LBE Privacy guard, the malicious app isn't going to go far, but for most phone users, it will have a field day.
Of course, the users that get nailed by the malware won't blame the source, they will blame the OS in general. This is where Apple gets it right. Unless someone uses some tightly controlled methods of loading software through iTunes or jailbreaks, all software comes through a very well guarded store that has zero hesitation of pulling apps that violate their guidelines. Heavy-handed, yes, but it does give Apple positive PR in the security department.
While browsing the Google Play store, I have started to notice a number of apps that have 1000+ good reviews, all rather pithy like "Amazing", or "!!!".
You then tap "Download" to look at the permissions, and the app asks for everything under the sun, even though the app might be a game or a utility that does one thing, and has zero need to be able to read and write contacts.
Of course, for users who know what they are doing, stuff like this is as close to a Trojan as one can get, or at best some basic game coupled with a malware payload. However, for novice users who just want to use a phone and who think permissions are something to obtain from their teacher so they can go use the bathroom, the phrase, "babe in the woods" comes to mind.
I hate lobbing brickbats at Google since I like the Android ecosystem and Android phones. Android even has a stronger security model than iOS. However, Apple does one thing which precludes the need for that much security in iOS, and that is to be an active and stern gatekeeper. iOS devs don't get their app stomped, then one hour later turn up again with the same app under a different name.
Google needs to get on the ball and make two tiers of their Play Store. The first (default) tier would be like Amazon, where all apps are not just sent past a rudimentary scanner, but are actively vetted. This includes not just the original version of the app, but any updates, so malware can't be slipped in.
To boot, a higher fee is charged to play in this game, partially to offset the cost of the enhanced filtering, and partially to discourage people from making accounts and trying to palm off the same malware-ridden app under different names.
In the top tier, Google would need have some very stringent policies. For example, if an app gets rejected by account "A", submitting the exact same app under account "B" with slight changes mean that account "B" gets suspended for the first offense, and closed down for good after the second.
Of course, Google can keep their second tier (which would be the same as Google Play now), but maybe put up some sort of warning for a user that once they exit the vetted tier, they are essentially on their own, so do what is needed at their own risk. This tier is one step up from just downloading an app via a website and sideloading it, but it is better than no security.
Google needs to do something here, because the malicious apps are causing issues, not just in China, but here in the US. Already, Android's reputation is being tarnished by something that is not the OS's or hardware maker's fault, and Google needs to step up to the plate and do the role of active gatekeeper unless they want to see customers abandon the platform for ones with a better gate guardian, even though it means people buying far locked down devices.
Right now, ARM isn't that big, but there is a lot of talk about the jump to using ARM for servers and such because of the better MIPS per watt ratio it has over x86.
For things that are relatively lightweight in CPU, such as NTP servers, DNS, DHCP, and other basic services, ARM would excel. And MS demanding that only their key would ensure that every time ARM advanced in the enterprise, Windows would come with it.
I find the biggest impediment to secure systems is cost. In previous companies I have worked for, there was a mantra by the management, "security has no ROI."
The fact that on the accounting ledger, proper security practices, doesn't mean black numbers are added, but that red numbers are not added escaped them. The typical response when I asked what the contingency plan about a break-in was usually "We call Geek Squad. They are open 24/7."
Yes, good security costs. Good routers, firewalling, hiring clued network guys, and running penetration scenarios are not cheap. However compared to other business operating costs, it isn't expensive on the relative scale.
Because there is little to no penalty if a business does get compromised, there is not much interest in locking things down. Until this is addressed, crappy security policies will be the norm.
I personally am from the IT school of "all operating systems suck, so pick what sucks less", and in some cases, the Mac recommendation may be the best way to go.
First, Apple has actual customer service compared to the PC companies (well, unless you buy from the "business" tier and get the better support plan.) So, they will have someone to call to get problems fixed and questions answered that isn't you.
Second, building them a desktop is in some ways the best solution, but it means you are on 24/7/365 call if anything breaks.
Third, Macs are not unhackable, but as of now, the biggest attack is through Trojan horses, while Windows is easily compromised through browser and browser add-on holes. So, for now, Macs have a less of a chance of being compromised by browser exploits.
Fourth, Time Machine isn't perfect, but compared to other consumer level backup programs, it is good enough. Especially if paired up with Mozy or Carbonite for documents. That way, the parent's documents are stashed safely even if the computer and its backup drive are destroyed or stolen.
Fifth, the App Store and a stern instruction to not run anything unless it came from there will help mitigate the possibility of Trojans. It isn't perfect, but it is a good method.
Of course, Linux is a workable solution as well, but a Mac's advantage is that it still has a mainstream software selection available for it, so Aunt Tillie can get a copy of Photoshop if she so chooses.
If given the choice between an ever shrinking SIM card versus the alternative of getting on my hands and knees and begging the CDMA provider to allow my handset on their network, I'll take the SIM card.
Say I find a cool phone from overseas. GSM, I can use it here in the US, although I likely will get stuck with EDGE speeds. Overseas, CDMA providers use R/UIM cards (functionally identical to SIM cards). A CDMA provider here in the US would laugh and tell me where to stuff the phone, since they likely wouldn't allow any device near their network they didn't sell.
It also works the other way around. An unlocked iPhone that has dual radios can go for a world tour and generally find GSM access. A CDMA device that doesn't have a GSM secondary radio would be pretty much a neutered PDA outside CONUS.
Of course not, but Google and RIM could have a very uphill battle, especially if MS has some patents they can use on the ActiveSync replacement.
MS isn't dealing with a hostile DoJ these days. In fact, if MS actively blocked devices from using the AS replacement, there is nothing Google or RIM could do. Antitrust? MS's lawyers would happily show that POP and IMAP are open protocols and can still be used, so there is no "monopoly", just people wanting to use their protocol.
Of course, I'm doing pure devil's advocate speculation here. However, MS does own that protocol and even Apple has acknowledged that, and MS can at any time only allow what devices they so choose to use it, and this can be enforced in court under a EULA.
Virtualization is one of those things that is a great tool, but people assume it is an all or nothing item, mainly because there are so many vendors making cash on VM solutions, as well as vendors making cash on discrete hardware solutions.
Because it is a grey area, usually a "real" solution doesn't happen with all the extremely loud voices beating the drumbeats for their technologies.
There are things that I just wouldn't bother virtualizing. Anything that has to work near RT for example like NTP servers. I also like keeping very sensitive items on physically separate frames. I do trust hypervisor security (it is good enough for production databases), but there are some items where I like it not in the mix, such as Netbackup master/media servers, LDAP servers, SecurID boxes, SDMC boxes, and the syslog dump boxes. Having LDAP on its own discrete frame also means that even if something takes down the VMWare cluster, people are still able to authenticate and do something. Same with SecurID. Someone knocks that out, there goes access from outside the perimeter, and that can cause some screaming, and may even cause a chicken-and-egg scenario if someone configures SecurID on vCenter.
The trick is to use virtualization and the cloud as tools. However, so many people have their interests lie in one blind direction or the other that finding a solution that uses the best tool for the job is difficult.
Call me insane, but I'd leave the master server on discrete hardware as well as the media servers. Opscenter, OTOH, can be virtualized because it won't absolutely hammer the bus as the media servers will.
I also like keeping the master server on separate hardware due to security -- if someone gets in via vCenter and is able to pull up NBU as root, they pretty much have access to everything unless client encryption is turned on (which means no compression or deduplication for that client.)
Netbackup is one of those few things that is just a big fat juicy target. Hack the master server, and essentially that's every single bit of data in an organization available to the attacker unless encryption is used.
Once Microsoft gets its Windows CE successor through a few iterations, BB is doomed. In fact, Microsoft has a trump card which few people realize: They control the horizontal and vertical when it comes to the Exchange/Activesync universe. Even Apple knows this because they licensed it from MS.
First will come the Windows phone that has full Office support for viewing and editing files. Both iOS and Android have gone through a lot of versions, but MS is catching up.
The next shoe that will drop is Microsoft coming with a new ActiveSync protocol that only supports their devices and possibly iOS. It would be touted as a "secure" protocol with some additional features such as NAC, ability to demand more on a device than current Exchange policies. Of course, this becomes standard, and the old AS protocols get dropped.
Result: The only thing that can connect to Exchange would be iOS and Windows based devices. With Microsoft's stranglehold on the enterprise when it comes to messaging, this would ensure them a permanent spot for their devices, and pushing RIM completely out of a market that is their last gasp.
This exactly is my concern. Why? ARM brings a lot to the table, so if MS can lock ARM devices to being Windows only, they will have gained immensely:
1: ARM based servers are being worked on. For tasks like DNS, DHCP, and other fairly static items, they are hard to beat. In general, ARM CPUs use significantly less power than x86, so the amount of MIPS per watt can be a game changer, especially when businesses are under constant attack about having eco-friendly data centers.
2: ARM based desktops for businesses will be a useful market. Because of the non-x86 architecture, games and "unauthorized" software won't work. However, Office and Outlook will. This will be a major boon for low level IT desktop support. I can see this selling like hotcakes in the enterprise because it keeps support costs down, guarantees a Windows foothold, and helps ensure that only authorized stuff will run. A new architecture means that virus and malware writers are sent to the drawing board as well.
For "cloud" access, a "thin client" has to be pretty beefy, because for access to "cloud" applications, the client will have to have not just a keyboard/mouse/TCP/IP stack (like an X-station), but a full OS that has to handle security, a Web browser with support for add-ons, and some form of persistent storage (so each machine can be uniquely identified via remote via a cookie, "super-cookie", LSO, or whatnot.)
With persistant storage comes HDDs or SDDs.
Desktop IT support is not going to vanish anytime soon:
1: Someone has to deal with broken machines/terminals in users' cubicles of offices. In theory, switching out a thin client would be the best thing, but in reality, thin clients tend to usually be more expensive than a generic x86 desktop, and with a desktop, parts can be swapped which means another client doesn't have to be purchased if one breaks. Of course, if it is a new thin client, it will have a different MAC address, so it won't be allowed on a locked down corporate network, which brings us to the next point.
2: There are going to be network admins. Packets don't magically route themselves, so someone is going to be there making sure the routers are working and secure, and local company policies are enforced. That way, a worm originating in one corporate department stays in that subnet and doesn't wind up in receiving or sales. Even if things work perfectly, someone is going to have to be there every six months to upgrade the router OS every time Cisco makes a major security update package.
Personally, cloud computing has its place, but it is not a cure-all, just like Javastations were not a cure-all when that was the rage, nor were X-stations the cure-all when that was important.
If a cloud computing provider goes bankrupt, the buyer of the liquidated servers has all the data stored on there free and clear. Trade secrets can be uploaded as a torrent. PII including bank info and credit cards? Public domain.
Consider this: If a cloud provider goes bankrupt, all the data on their servers is free for the taking by anyone.
If a drive has capacity enough to back up completely at least one of my machines, that would be considered adequate by me. Having the 1TB SSD is nice, but so is having a pair of drives that data is copied to on a nightly basis so if the SSD gets lost or erased, it is still present (without having to waste the time and bandwidth costs to recover from a cloud provider.)
Maybe we will see disks with more options for interfaces. For example, it would be nice if an external drive could be configured to show up as a virtual tape library for example. This would allow backup software to back data up, without the fear of just one goof from the OS (or perhaps malware) completely trashing the backup drive's filesystem. Other options might be a UDF drive presented so files can be copied in a write once, read-many fashion, and so on. Of course, we have drives that work as NAS servers, but with how software is able to be improved, why not have a standalone external USB or Thunderbolt drive start sporting some SAN-like features? For example:
1: Use USB for the "control" connection, then use either iSCSI, or Thunderbolt for the presenting of LUNs to the machine. This would allow for separation of data and filesystems, so a trashed filesystem in one user's home directory wouldn't mean a complete restore.
2: Have the ability to take snapshots and have an antivirus utility running on another machine with the LUNs presented read-only look for them. If this is done with a Windows box running off the drive, this can catch rootkits that might be able to hide from the main machine's OS.
3: Snapshots in general would be useful, either as a way of doing quick and dirty backups, or other items.
4: Combine snapshot backups with a cloud backup service, and this would result in no CPU needed on the host machines for backups. Encryption can be done on the drive as well.
5: Obtain two similar drives and give them Internet ability, then one can enable replication (with end to end encryption) on the block level, so someone can just ask a friend to allow their HDD to just passively sit on the network, and it does everything else.
6: No real need for a file server at home. Just present a LUN as a CIFS share.
7: Some redirector service similar to dyndns, so someone can access their drive from anywhere securely.
There is a ton of stuff that can be done with disk controllers. A VTL might have been an expensive, ardious task years ago, but that is "just" programming to make a disk drive or a drive array appear as a library of tapes. It would be useful at home because it would provide a means of storing data that is resistant to malware (no "list all drives, format all drives" logic bombs at least.)
One thing we have had issues with is that even now, the issue with drives is how fast we can get data in and out of it.
Even the high end SAN makers know this and tell people to always use RAID 6 on the backend, just because the window of time that it takes to rebuild a drive is so long these days that it can easily allow for a second drive failure to happen with no protection.
What I really will dread seeing is an external 60TB drive that is stuck with a USB 3 interface as its only I/O. USB 3 (for lowest denominator compatibility), a SATA descendant, and Thunderbolt, would be ideal, but with how cheap some drives end up, it might just be a sole USB port for in/out.
I used to swear by HTC phones, because I had a T-Mobile MDA/Wizard (WM 5.x initially, flashed to 6.x, and overclocked) and that phone lasted over four years without an issue. Battery life? Could go for a week on standby, few phones made these days could brag about doing.
The one thing I wish Google would do with Motorola is what they have done on all Nexus phones --
fastboot oem unlock
accept the "you can't just walk into Mordor" dialog, have it erase the filesystems, and then go about what you want to do.
Novice users who are prone to the dancing bunny attack won't be downloading and using the Android SDK, especially when they see that every piece of data they have will get wiped.
Motorola has some very good security and some very cool features in their newer devices. Webtop just is something that has a ton of promises, especially with the technology of a render server streaming video to devices (so they can show the detailed 3D graphics without having to have the video card power for them.)
The biggest thing I've been hoping for with the Google/Motorola merger is that Google could offer a method to unlock bootloaders on newer Motorola phones, such as the Atrix 2, Photon, or others.
I'm just hoping this comes to pass now that all the big names have signed onto this.
On a personal level, TrueCrypt is excellent. In fact, I consider it a must have on machines.
However, in a company, BitLocker provides me with audit trails. This way, if a laptop is stolen, I can print out something from a console showing that the machine has been encrypted with policy settings showing AES-256 encryption, and use of TPM/PIN/USB key. This can mean the difference between writing a laptop theft off as "just" hardware (especially if the laptop uses a PIN so the thief wouldn't be able to boot it to a login screen) versus having to report to the press about a breach in security with data lost.
With regards to backdoors, I'm not really worried. Since BitLocker is mainly used by US companies, if it were true that MS put a backdoor in by the demand of the US government, someone would find it and the blowback would be enormous.
As for machines without TPMs, the reason for this is that even though most business line machines (Optiplex is the usual) have this in place, usually the top brass of a company, as well as sales droids want Macs, and they have no TPMs whatsoever since the original x86 Mac Pro came out.
To me, where BitLocker or another disk encryption tool means the difference between a hardware write-off and insurance claim versus having to report to every manager up a chain, as well as the press, I consider the basic Windows 8 security upgrades to BitLocker important.
It would be nice if they would allow non-TPM encryption without a USB flash drive, because not many machines have TPM/TCG compatible motherboards these days.
However, I can deploy images that are already BitLocker encrypted, or just tell the machine to encrypt used space in Windows 8. With the new hardware encrypted HDDs, I can have BitLocker deal with those as well.
Yes, this is boring, but anything that ensures that an attacker isn't going to get data should a laptop be stolen is important for day to day IT.
Slashdot Mirror
That is what one tries to avoid. The best is to have multiple blocking mechanisms. First is by IP address, so if someone is hacking user Alice's account, the site trying to hack in as Alice gets blocked on the IP level.
The hashing appliance is a work in progress. Either a delay between handing out replies for the same user or an outright lockout serve the same purpose. The trick is to slow down a dictionary attack, as well as make it difficult for an attacker to grab the list of user password hashes.
It is an easy way to go, but what I saw people do is log in just to make sure a legit user would be locked out.
Some old IBM systems would lock a user account indefinitely after 3-5 wrong guesses. So, what people would do for petty revenge is just type in the user name of someone they don't like, type in some wrong guesses, and that person's account is locked out until the next weekday when the IT staff comes in.
Instead, there needs to be multiple levels of lockout to prevent brute force guessing. The lowest level would be at the hash database server, where it would allow 10-20 wrong guesses before it would block access for 1-2 minutes (good enough to slow down brute force dictionary attacks, but not so long that it means a legit user is locked out forever.) From there, the app server would lock out access via IP ranges, say 15 minutes if there were 3+ guesses wrong. This way, if someone was coming from one IP range to guess passwords, it would not completely lock a legit user out who was coming from somewhere else.
I've been playing with a dedicated hash database that is on its own server, so hosts bounce a request off this appliance and get a "yes", "no", or "timeout". Too many "no"s in too short a time make the hash validation appliance refuse to give any answers for a period of time.
If done correctly, for someone to get the hash database, they would have to find a way to physically get access to the appliance, then dump the box. It isn't perfect (which is why a better algorithm like bcrypt should be used to store hashes), but having a layer of security whose sole purpose is to keep the list of hashes out of the hands of the blackhats means that after a breach is rectified, users are not forced to change all their passwords (unless their accounts were directly involved).
Very true.
The key is to have the first store the user encounters, be it Google's, Amazon's, or an Android version of Cydia handle app security on a rigorous level. Of course, users should get the ability to swap to another store (and know the consequences of moving from an actively maintained store to a marketplace where malware enforcement is reactive, not proactive.) It is about expectations. People expect on iOS to be able to download everything and that it is safe for human consumption. Pretty much this has held true. People expect the same thing on Google Play, but don't realize that they are not dealing with the equivalent of a sterile big box store, but more of a flea market.
For Google's sake, the first store that comes up for a new user should be one that is tightly vetted. Then they should have the option of going to another store (knowing the consequences of doing so.)
Since most Android phones ship with Google's Play Store as the main store, Google's name is on the line when someone doesn't know any better and downloads a malware-ridden app, even though it isn't technically Google's fault in any way.
This is why for the previously suggested "top tier", Google should finance the time and money it takes to run a tight ship with a higher developer fee.
This doesn't mean to stop offering $25.00 for access to the Play Store, but it means that having a segment of the market where things are thoroughly vetted and found suitable consumption. Most people reading /. have enough sense to check permissions and check for bogus reviews before downloading and running, but unfortunately, people assume if they download an app from a store, it is safe. Google needs to meet this expectation, with the option of letting users to the wild west if they so choose.
If Google doesn't do this, users will leave the platform in droves once the horror stories start coming in about bank balances, bogus charges, and other stuff. This WILL happen when malware gets more sophisticated than just spamming SMS messages to contacts.
Android isn't like Windows where people tolerate the perception of no security in order to run their apps. There are other operating systems for devices that users can jump to, and when the users leave Android, so do the developers. This feedback cycle is killing RIM/Blackberry, and can easily kill Android if it isn't put in check.
This is one area where Android is above iOS. If an app's perms don't allow it to read contacts, unless it comes with a built in exploiter like rageinthecage or zergrush, the app is not going to be able to touch the contact list.
However, as stated above, people see the app on the Play Store, tap "Download", see some writing, then tap the button again to get the app. Then, for most users, the "fun" begins. Of course, with a rooted phone and DroidWall and/or LBE Privacy guard, the malicious app isn't going to go far, but for most phone users, it will have a field day.
Of course, the users that get nailed by the malware won't blame the source, they will blame the OS in general. This is where Apple gets it right. Unless someone uses some tightly controlled methods of loading software through iTunes or jailbreaks, all software comes through a very well guarded store that has zero hesitation of pulling apps that violate their guidelines. Heavy-handed, yes, but it does give Apple positive PR in the security department.
While browsing the Google Play store, I have started to notice a number of apps that have 1000+ good reviews, all rather pithy like "Amazing", or "!!!".
You then tap "Download" to look at the permissions, and the app asks for everything under the sun, even though the app might be a game or a utility that does one thing, and has zero need to be able to read and write contacts.
Of course, for users who know what they are doing, stuff like this is as close to a Trojan as one can get, or at best some basic game coupled with a malware payload. However, for novice users who just want to use a phone and who think permissions are something to obtain from their teacher so they can go use the bathroom, the phrase, "babe in the woods" comes to mind.
I hate lobbing brickbats at Google since I like the Android ecosystem and Android phones. Android even has a stronger security model than iOS. However, Apple does one thing which precludes the need for that much security in iOS, and that is to be an active and stern gatekeeper. iOS devs don't get their app stomped, then one hour later turn up again with the same app under a different name.
Google needs to get on the ball and make two tiers of their Play Store. The first (default) tier would be like Amazon, where all apps are not just sent past a rudimentary scanner, but are actively vetted. This includes not just the original version of the app, but any updates, so malware can't be slipped in.
To boot, a higher fee is charged to play in this game, partially to offset the cost of the enhanced filtering, and partially to discourage people from making accounts and trying to palm off the same malware-ridden app under different names.
In the top tier, Google would need have some very stringent policies. For example, if an app gets rejected by account "A", submitting the exact same app under account "B" with slight changes mean that account "B" gets suspended for the first offense, and closed down for good after the second.
Of course, Google can keep their second tier (which would be the same as Google Play now), but maybe put up some sort of warning for a user that once they exit the vetted tier, they are essentially on their own, so do what is needed at their own risk. This tier is one step up from just downloading an app via a website and sideloading it, but it is better than no security.
Google needs to do something here, because the malicious apps are causing issues, not just in China, but here in the US. Already, Android's reputation is being tarnished by something that is not the OS's or hardware maker's fault, and Google needs to step up to the plate and do the role of active gatekeeper unless they want to see customers abandon the platform for ones with a better gate guardian, even though it means people buying far locked down devices.
Bouncer just isn't going to cut it.
Right now, ARM isn't that big, but there is a lot of talk about the jump to using ARM for servers and such because of the better MIPS per watt ratio it has over x86.
For things that are relatively lightweight in CPU, such as NTP servers, DNS, DHCP, and other basic services, ARM would excel. And MS demanding that only their key would ensure that every time ARM advanced in the enterprise, Windows would come with it.
I find the biggest impediment to secure systems is cost. In previous companies I have worked for, there was a mantra by the management, "security has no ROI."
The fact that on the accounting ledger, proper security practices, doesn't mean black numbers are added, but that red numbers are not added escaped them. The typical response when I asked what the contingency plan about a break-in was usually "We call Geek Squad. They are open 24/7."
Yes, good security costs. Good routers, firewalling, hiring clued network guys, and running penetration scenarios are not cheap. However compared to other business operating costs, it isn't expensive on the relative scale.
Because there is little to no penalty if a business does get compromised, there is not much interest in locking things down. Until this is addressed, crappy security policies will be the norm.
I personally am from the IT school of "all operating systems suck, so pick what sucks less", and in some cases, the Mac recommendation may be the best way to go.
First, Apple has actual customer service compared to the PC companies (well, unless you buy from the "business" tier and get the better support plan.) So, they will have someone to call to get problems fixed and questions answered that isn't you.
Second, building them a desktop is in some ways the best solution, but it means you are on 24/7/365 call if anything breaks.
Third, Macs are not unhackable, but as of now, the biggest attack is through Trojan horses, while Windows is easily compromised through browser and browser add-on holes. So, for now, Macs have a less of a chance of being compromised by browser exploits.
Fourth, Time Machine isn't perfect, but compared to other consumer level backup programs, it is good enough. Especially if paired up with Mozy or Carbonite for documents. That way, the parent's documents are stashed safely even if the computer and its backup drive are destroyed or stolen.
Fifth, the App Store and a stern instruction to not run anything unless it came from there will help mitigate the possibility of Trojans. It isn't perfect, but it is a good method.
Of course, Linux is a workable solution as well, but a Mac's advantage is that it still has a mainstream software selection available for it, so Aunt Tillie can get a copy of Photoshop if she so chooses.
If given the choice between an ever shrinking SIM card versus the alternative of getting on my hands and knees and begging the CDMA provider to allow my handset on their network, I'll take the SIM card.
Say I find a cool phone from overseas. GSM, I can use it here in the US, although I likely will get stuck with EDGE speeds. Overseas, CDMA providers use R/UIM cards (functionally identical to SIM cards). A CDMA provider here in the US would laugh and tell me where to stuff the phone, since they likely wouldn't allow any device near their network they didn't sell.
It also works the other way around. An unlocked iPhone that has dual radios can go for a world tour and generally find GSM access. A CDMA device that doesn't have a GSM secondary radio would be pretty much a neutered PDA outside CONUS.
Of course not, but Google and RIM could have a very uphill battle, especially if MS has some patents they can use on the ActiveSync replacement.
MS isn't dealing with a hostile DoJ these days. In fact, if MS actively blocked devices from using the AS replacement, there is nothing Google or RIM could do. Antitrust? MS's lawyers would happily show that POP and IMAP are open protocols and can still be used, so there is no "monopoly", just people wanting to use their protocol.
Of course, I'm doing pure devil's advocate speculation here. However, MS does own that protocol and even Apple has acknowledged that, and MS can at any time only allow what devices they so choose to use it, and this can be enforced in court under a EULA.
Virtualization is one of those things that is a great tool, but people assume it is an all or nothing item, mainly because there are so many vendors making cash on VM solutions, as well as vendors making cash on discrete hardware solutions.
Because it is a grey area, usually a "real" solution doesn't happen with all the extremely loud voices beating the drumbeats for their technologies.
There are things that I just wouldn't bother virtualizing. Anything that has to work near RT for example like NTP servers. I also like keeping very sensitive items on physically separate frames. I do trust hypervisor security (it is good enough for production databases), but there are some items where I like it not in the mix, such as Netbackup master/media servers, LDAP servers, SecurID boxes, SDMC boxes, and the syslog dump boxes. Having LDAP on its own discrete frame also means that even if something takes down the VMWare cluster, people are still able to authenticate and do something. Same with SecurID. Someone knocks that out, there goes access from outside the perimeter, and that can cause some screaming, and may even cause a chicken-and-egg scenario if someone configures SecurID on vCenter.
The trick is to use virtualization and the cloud as tools. However, so many people have their interests lie in one blind direction or the other that finding a solution that uses the best tool for the job is difficult.
Call me insane, but I'd leave the master server on discrete hardware as well as the media servers. Opscenter, OTOH, can be virtualized because it won't absolutely hammer the bus as the media servers will.
I also like keeping the master server on separate hardware due to security -- if someone gets in via vCenter and is able to pull up NBU as root, they pretty much have access to everything unless client encryption is turned on (which means no compression or deduplication for that client.)
Netbackup is one of those few things that is just a big fat juicy target. Hack the master server, and essentially that's every single bit of data in an organization available to the attacker unless encryption is used.
Add to that IBM, where on POWER7 hardware, the AIX-based OS used for the VIO servers is called IOS as well.
oem_setup_env is your friend, although IBM does not support this way of adminning a VIO server.
Once Microsoft gets its Windows CE successor through a few iterations, BB is doomed. In fact, Microsoft has a trump card which few people realize: They control the horizontal and vertical when it comes to the Exchange/Activesync universe. Even Apple knows this because they licensed it from MS.
First will come the Windows phone that has full Office support for viewing and editing files. Both iOS and Android have gone through a lot of versions, but MS is catching up.
The next shoe that will drop is Microsoft coming with a new ActiveSync protocol that only supports their devices and possibly iOS. It would be touted as a "secure" protocol with some additional features such as NAC, ability to demand more on a device than current Exchange policies. Of course, this becomes standard, and the old AS protocols get dropped.
Result: The only thing that can connect to Exchange would be iOS and Windows based devices. With Microsoft's stranglehold on the enterprise when it comes to messaging, this would ensure them a permanent spot for their devices, and pushing RIM completely out of a market that is their last gasp.
This exactly is my concern. Why? ARM brings a lot to the table, so if MS can lock ARM devices to being Windows only, they will have gained immensely:
1: ARM based servers are being worked on. For tasks like DNS, DHCP, and other fairly static items, they are hard to beat. In general, ARM CPUs use significantly less power than x86, so the amount of MIPS per watt can be a game changer, especially when businesses are under constant attack about having eco-friendly data centers.
2: ARM based desktops for businesses will be a useful market. Because of the non-x86 architecture, games and "unauthorized" software won't work. However, Office and Outlook will. This will be a major boon for low level IT desktop support. I can see this selling like hotcakes in the enterprise because it keeps support costs down, guarantees a Windows foothold, and helps ensure that only authorized stuff will run. A new architecture means that virus and malware writers are sent to the drawing board as well.
For "cloud" access, a "thin client" has to be pretty beefy, because for access to "cloud" applications, the client will have to have not just a keyboard/mouse/TCP/IP stack (like an X-station), but a full OS that has to handle security, a Web browser with support for add-ons, and some form of persistent storage (so each machine can be uniquely identified via remote via a cookie, "super-cookie", LSO, or whatnot.)
With persistant storage comes HDDs or SDDs.
Desktop IT support is not going to vanish anytime soon:
1: Someone has to deal with broken machines/terminals in users' cubicles of offices. In theory, switching out a thin client would be the best thing, but in reality, thin clients tend to usually be more expensive than a generic x86 desktop, and with a desktop, parts can be swapped which means another client doesn't have to be purchased if one breaks. Of course, if it is a new thin client, it will have a different MAC address, so it won't be allowed on a locked down corporate network, which brings us to the next point.
2: There are going to be network admins. Packets don't magically route themselves, so someone is going to be there making sure the routers are working and secure, and local company policies are enforced. That way, a worm originating in one corporate department stays in that subnet and doesn't wind up in receiving or sales. Even if things work perfectly, someone is going to have to be there every six months to upgrade the router OS every time Cisco makes a major security update package.
Personally, cloud computing has its place, but it is not a cure-all, just like Javastations were not a cure-all when that was the rage, nor were X-stations the cure-all when that was important.
I'd also add one more thing in the mix:
If a cloud computing provider goes bankrupt, the buyer of the liquidated servers has all the data stored on there free and clear. Trade secrets can be uploaded as a torrent. PII including bank info and credit cards? Public domain.
Consider this: If a cloud provider goes bankrupt, all the data on their servers is free for the taking by anyone.
If a drive has capacity enough to back up completely at least one of my machines, that would be considered adequate by me. Having the 1TB SSD is nice, but so is having a pair of drives that data is copied to on a nightly basis so if the SSD gets lost or erased, it is still present (without having to waste the time and bandwidth costs to recover from a cloud provider.)
Maybe we will see disks with more options for interfaces. For example, it would be nice if an external drive could be configured to show up as a virtual tape library for example. This would allow backup software to back data up, without the fear of just one goof from the OS (or perhaps malware) completely trashing the backup drive's filesystem. Other options might be a UDF drive presented so files can be copied in a write once, read-many fashion, and so on. Of course, we have drives that work as NAS servers, but with how software is able to be improved, why not have a standalone external USB or Thunderbolt drive start sporting some SAN-like features? For example:
1: Use USB for the "control" connection, then use either iSCSI, or Thunderbolt for the presenting of LUNs to the machine. This would allow for separation of data and filesystems, so a trashed filesystem in one user's home directory wouldn't mean a complete restore.
2: Have the ability to take snapshots and have an antivirus utility running on another machine with the LUNs presented read-only look for them. If this is done with a Windows box running off the drive, this can catch rootkits that might be able to hide from the main machine's OS.
3: Snapshots in general would be useful, either as a way of doing quick and dirty backups, or other items.
4: Combine snapshot backups with a cloud backup service, and this would result in no CPU needed on the host machines for backups. Encryption can be done on the drive as well.
5: Obtain two similar drives and give them Internet ability, then one can enable replication (with end to end encryption) on the block level, so someone can just ask a friend to allow their HDD to just passively sit on the network, and it does everything else.
6: No real need for a file server at home. Just present a LUN as a CIFS share.
7: Some redirector service similar to dyndns, so someone can access their drive from anywhere securely.
There is a ton of stuff that can be done with disk controllers. A VTL might have been an expensive, ardious task years ago, but that is "just" programming to make a disk drive or a drive array appear as a library of tapes. It would be useful at home because it would provide a means of storing data that is resistant to malware (no "list all drives, format all drives" logic bombs at least.)
One thing we have had issues with is that even now, the issue with drives is how fast we can get data in and out of it.
Even the high end SAN makers know this and tell people to always use RAID 6 on the backend, just because the window of time that it takes to rebuild a drive is so long these days that it can easily allow for a second drive failure to happen with no protection.
What I really will dread seeing is an external 60TB drive that is stuck with a USB 3 interface as its only I/O. USB 3 (for lowest denominator compatibility), a SATA descendant, and Thunderbolt, would be ideal, but with how cheap some drives end up, it might just be a sole USB port for in/out.
I used to swear by HTC phones, because I had a T-Mobile MDA/Wizard (WM 5.x initially, flashed to 6.x, and overclocked) and that phone lasted over four years without an issue. Battery life? Could go for a week on standby, few phones made these days could brag about doing.
The one thing I wish Google would do with Motorola is what they have done on all Nexus phones --
fastboot oem unlock
accept the "you can't just walk into Mordor" dialog, have it erase the filesystems, and then go about what you want to do.
Novice users who are prone to the dancing bunny attack won't be downloading and using the Android SDK, especially when they see that every piece of data they have will get wiped.
Motorola has some very good security and some very cool features in their newer devices. Webtop just is something that has a ton of promises, especially with the technology of a render server streaming video to devices (so they can show the detailed 3D graphics without having to have the video card power for them.)
The biggest thing I've been hoping for with the Google/Motorola merger is that Google could offer a method to unlock bootloaders on newer Motorola phones, such as the Atrix 2, Photon, or others.
I'm just hoping this comes to pass now that all the big names have signed onto this.
On a personal level, TrueCrypt is excellent. In fact, I consider it a must have on machines.
However, in a company, BitLocker provides me with audit trails. This way, if a laptop is stolen, I can print out something from a console showing that the machine has been encrypted with policy settings showing AES-256 encryption, and use of TPM/PIN/USB key. This can mean the difference between writing a laptop theft off as "just" hardware (especially if the laptop uses a PIN so the thief wouldn't be able to boot it to a login screen) versus having to report to the press about a breach in security with data lost.
With regards to backdoors, I'm not really worried. Since BitLocker is mainly used by US companies, if it were true that MS put a backdoor in by the demand of the US government, someone would find it and the blowback would be enormous.
As for machines without TPMs, the reason for this is that even though most business line machines (Optiplex is the usual) have this in place, usually the top brass of a company, as well as sales droids want Macs, and they have no TPMs whatsoever since the original x86 Mac Pro came out.
To me, where BitLocker or another disk encryption tool means the difference between a hardware write-off and insurance claim versus having to report to every manager up a chain, as well as the press, I consider the basic Windows 8 security upgrades to BitLocker important.
It would be nice if they would allow non-TPM encryption without a USB flash drive, because not many machines have TPM/TCG compatible motherboards these days.
However, I can deploy images that are already BitLocker encrypted, or just tell the machine to encrypt used space in Windows 8. With the new hardware encrypted HDDs, I can have BitLocker deal with those as well.
Yes, this is boring, but anything that ensures that an attacker isn't going to get data should a laptop be stolen is important for day to day IT.