Posted on 08/24/2015 5:05:14 PM PDT by Swordmaker
Apple's Macs, iPhones and iPads are common in the modern workplace, but relatively few of these devices comply with standard security requirements, according to a new survey.
Nearly half of all U.S. employees use at least one Apple device at work, but most of those gadgets lack common security protocols required by many enterprises, according to a new survey commissioned by Centrify, a company that sells enterprise security and management software for Apple products.
Last month, Centrify asked 1,004 business professionals about how they use computers and smartphones in the workplace. Respondents used a total of 1,309 Apple devices at work, including 191 Macs, 387 iPads and 731 iPhones, according to Centrify. All of the respondents were employed full-time at companies with at least 20 employees, from various industries including healthcare and financial services, according to Centrify.
The survey, which was conducted by Dimensional Research, found that 45 percent of respondents use at least one Apple device for work, to access corporate email, documents and business applications. Of those gadgets, 63 percent were employee-owned. More than half, or 51 percent, of all the users' Apple devices were secured by single-word passwords or numerical PINs, and 58 percent of those devices had no software or policies to enforce the use of stronger passwords. The survey also found that 56 percent of Apple device users shared their passwords with others, and only 17 percent had company-supplied password managers.
In addition, only 28 percent of respondents' Apple devices had company-provided device management solutions, and 35 percent of the people work for companies that enforce data encryption on Apple devices. Almost 60 percent of the Macs represented in the survey were used to access confidential company information, and 65 percent of those systems were used to access sensitive or regulated customer information, according to the survey.
The results spotlight the high usage rates of unmanaged Apple devices in the workplace, according to Centrify, and they reinforce the risks organizations face when IT professionals don't have the necessary resources to make sure devices comply with security policies.
Changing passwords regularly is a tactic for mitigating potential damage if the credentials are discovered (there are multiple ways of doing this), or shared. Changing the passwords forces a potential intruder to have to be continually probing systems trying to discover the new passwords, and risk potentially being discovered themselves in the process.
Also, when the password changes attempts to log on using the old password will be recorded by the security systems, along with the source of the attempted logon. Those failed logon attempts are evidence of a possible intrusion, and security software will monitor the logs and analyze and alert on those events for investigation.
Having access to a set of credentials with a password that never expires allows an intruder to quietly access and monitor a system for months or even years without setting of those alerts or hitting the tripwires.
Such as?
Changing the passwords forces a potential intruder to have to be continually probing systems trying to discover the new passwords, and risk potentially being discovered themselves in the process.
Probing for passwords? How exactly? If an intruder wants data he will take the data. If he wants a salted hash file, he can have mine. I'll send it to him.
Also, when the password changes attempts to log on using the old password will be recorded by the security systems, along with the source of the attempted logon.
The source will be someone's compromised home computer or a server in Poland or China.
Having access to a set of credentials with a password that never expires allows an intruder to quietly access and monitor a system for months or even years without setting of those alerts or hitting the tripwires.
Makes sense, but that many intrusions were short.
Techniques like social engineering, packet captures, keystroke loggers and dumpster diving have yielded passwords.
Probing for passwords? How exactly? If an intruder wants data he will take the data. If he wants a salted hash file, he can have mine. I'll send it to him.
I do not know all the possible ways there are, and I don't think it's reasonable to expect me to give you a comprehensive course on hacking. Suffice it to say that not all passwords get you access to valuable data. Whenever a set of credentials is acquired you have to test them, possibly against many machines to determine what they do a do not grant access to. A low-level account might not grant you access to any valuable data, but might get you into a workstation where someone with an account that does might log on and let you capture theirs, and the testing starts all over again.
The source will be someone's compromised home computer or a server in Poland or China.
The source of the hack might be, but servers that hold sensitive data are typically firewalled so that they cannot talk directly to home computers in Poland or China. You have to get control of a computer that can talk to both. That is the source that will be recorded in the server's event logs you'll be looking for - the initial ingress point into the internal network.
Makes isense, but that many intrusions were short.
There's no "magic bullet" that will stop every type of intrusion. Things like requiring minimum password lengths and complexity, and periodic changes are basic good practice that will help protect against many known types of intrusion. Network security always starts with the assumption that the system can be breached and may already have been.
You seem to be punting on the probing for passwords. The thing to understand is that when a password system is implemented securely, as are more and more these days, there is no probing. There is simply a secure channel for entering the password (e.g. https) and a password hash comparison. There is no place or moment to probe for passwords since they are never cleartext or unhashed except momentarily in some server software which is easy to implement securely.
Things like requiring minimum password lengths and complexity, and periodic changes are basic good practice
Simply put, they are not. My 30 year old, relatively short and simole password is perfectly adequate for what I use it for. I run numerous servers using that password. The security of the ssh authentication is 100% indpendent of password size and complexity. An attacker can steal my salts and hashes and perform a brute force attack. But to do that he would already be in the server and can set up his own account or install a back door for access.
OTOH, I just looked at my logs and I have numerous probes hitting many potential weaknesses. Password complexity, length and changing interval protect against none of those. One injects "cat%20/var/www/secret.passwd" another looks for "...../../../../../var/tmp/voip.cfg%20%26...", etc. In contrast my server with the crown jewels has absolutely no probe attempts in any logs and the reason can be seen by typing "sudo iptables -L"
All probing attempts are obvious including the attempts to find the obfuscated ssh ports. The number of password tries is limited to three and then the attacker will have used up an IP address. Suffice to say my password is not going to be brute forced from outside.
There are two choices to getting my password: from outside by keystroke logging on my laptop, or inside by getting in via a vulnerability. Password complexity and length does not add any protection against either of those. Password changes are only going to stop the attacker within about a month or two. In the meantime the attacker will have the prior password. A month or two is certainly long enough to get what he wants.
The conclusion from that argument would be that not changing passwords will make an organization immune to social engineering. You can bet on that assumption if you want to. I won't.
Simply put, they are not.
Source?
I think the mistake is assuming that what works for you and your handful of servers will scale perfectly to dozens of physical installations, thousands of servers and tens of thousands of users and accounts.
The argument against length and complexity is simple. An attacker can increasing cracking by orders of magnitude with GPU's and custom hardware. Why keep lengthening and complexifying when there's a much simpler answer: secure the hash file. Any modern OS will have a root readable shadow file. The paranoid can go further and make it unreadable except when it is needed. An attacker with root privileges does not need your password, all he needs is the data he is after. If the password is useful to attack a different system then that is an argument for diversity which is never enforced across systems. Password changing hinders diversity or forces people to use a horrible password tool like lastpass.
There are a couple bloggers who argue convincingly against complexity and forced changing, but I don't have them handy. The people sticking to the old mentality that the hash file will always be stolen and cracked are stuck in the last century. Systems that allow distriuted external guesses are flawed. Flawed systems are not a good reason to apply password changing when that creates other vulnerabilities.
On the contrary, that's where it is most useful. The more users you have, the more chances an attacker will have with social engineering techniques. I noticed a couple years ago my bank stopped sending me the "ok it's time to change your password" crap. I asked them not to and I'm sure other people did as well. Consequently I have had the same password there for about 5 years (30 year old password plus trivial crap added for "complexity"). I assume the hashes are stored securely. I assume their attackers will go after accounts or money directly. I assume if the attacker wants to just log in as me, I'll accept that risk, the odds for a properly secured hash file and hash comparison SW are extremely low.
The way it works is very simple, my password is sent in a secure channel, the confidentiality is assured. A small amount of secure SW salts and hashes that password close to arrival on the server. Another secure piece of SW, preferably on another secure machine, checks the hash against the stored hashes. If no other SW (attacker) ever sees my single password or the hashes of all passwords, then the passwords are secure. There are a few more details of course, but not a lot of complexity which is the enemy of security.
Other access to the database (no password info there), transaction interfaces to steal money, etc are all more complex and vulnerable. That's where the attacker will go, and so far that has not happened at my bank.
And you expect to make a convincing argument against virtually every industry standard "best practices" policy with that?
If every thing you say is true, you should be very much in demand as a network security expert.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.