Software Exploits Aren't Needed To Hack Most Organizations (darkreading.com) 57
The five most common ways of hacking an organization all involve stolen credentials, "based on data from 75 organizations, 100 penetration tests, and 450 real-world attacks," writes an anonymous Slashdot reader. In fact, 66% of the researchers' successful attacks involved cracking a weak domain user password. From an article on Dark Reading:
Playing whack-a-mole with software vulnerabilities should not be top of security pros' priority list because exploiting software doesn't even rank among the top five plays in the attacker's playbook, according to a new report from Praetorian. Organizations would be far better served by improving credential management and network segmentation...
"If we assume that 1 percent [of users] will click on the [malicious] link, what will we do next?" says Joshua Abraham, practice manager at Praetorian. The report suggests specific mitigation tactics organizations should take in response to each one of these attacks -- tactics that may not stop attackers from stealing credentials, but "building in the defenses so it's really not a big deal if they do"... [O]ne stolen password should not give an attacker (or pen tester) the leverage to access an organization's entire computing environment, exfiltrating all documents along the way.
Similar results were reported in Verizon's 2016 Data Breach Investigations Report.
"If we assume that 1 percent [of users] will click on the [malicious] link, what will we do next?" says Joshua Abraham, practice manager at Praetorian. The report suggests specific mitigation tactics organizations should take in response to each one of these attacks -- tactics that may not stop attackers from stealing credentials, but "building in the defenses so it's really not a big deal if they do"... [O]ne stolen password should not give an attacker (or pen tester) the leverage to access an organization's entire computing environment, exfiltrating all documents along the way.
Similar results were reported in Verizon's 2016 Data Breach Investigations Report.
Always one (Score:3)
[O]ne stolen password should not give an attacker (or pen tester) the leverage to access an organization's entire computing environment, exfiltrating all documents along the way.
What if it's the lead system administrator's password? Whitelisting IP addresses/ranges for out-of-the-building connections to allow telecommuting while still making it hard on an attacker?
Re:Always one (Score:4, Insightful)
What if it's the lead system administrator's password?
Why have you designed an enterprise wide administration process based on a hierarchy? Where an attack on (one of) the top nodes can gain entry into everything?
Re: (Score:2)
Compartmentalization is great, but you still need redundancy in privileges to cover employee departures, PTO, etc., leading to a lot of power in a few hands. Smaller organizations it is worse.
Having secure, unique, and temporal passwords ends up requiring them to be written down, but when you need to enter them 20 times a day, people get lazy... even with best intentions.
Re:Always one (Score:5, Insightful)
Re: (Score:1)
Hillary, welcome to Slashdot! ;-)
Re: (Score:3)
Re: (Score:2)
Do you use Directory Services of any kind
Not for anything security related. DNS as an example of a hierarchical database is useful. But if you have to be certain that you are talking to the correct remote host (due to possible corruption of the DNS system) it's better to use an authentication system based on something external to that. And there are better models than hierarchical for managing key and certificate exchange and peer to peer trust.
Re: (Score:2)
Re: (Score:1)
If you give full system access to one user (never mind username/password combo), then you'd hope that they wouldn't be so dumb as to open a dodgy attachment.
In a large org, nobody should have access to everything; it's terrible security practice.
Even in a small org, system administrators shouldn't be running net-facing software (browser, email, etc) as a privileged user. If they click on something dodgy, they should have to enter a password before it can install itself AT MINIMUM. Even then, they shouldn't
Re: (Score:1)
Who cares, the passwords are but a small part of the issue. Even if the SysAdmin account was restricted that compromised account can still send an email to -many-internal users requesting action on a link... More accounts get mooched...
The real problem is the apps themselves that may have direct kernel access on systems, or allow for a greater amount of code execution than say html which is nye on damn near impossible to produce remote hacks. Allow scripts to run on whitelisted domains ONLY. All other sites
Re:Always one (Score:4, Insightful)
Indeed, one password is not nearly enough. Each file should have its own password! Consisting of at least 38 characters that are randomly generated and consist of lowercase, uppercase, punctuation, digits, Chinese, whitespace, and dingbats! And changing every 24 hours!
In fact I don't think that's secure enough yet. Maybe we should just not allow any 'files'. That way the hackers can never take them.
Do security people even understand that one of the primary goals of security must always still be that it must still be possible for work to be done? That, despite everything, they are a _service_, not a goal? That without any work going on, they will also be out of a job?
Re: (Score:2)
Management is the biggest vulnerability (Score:1)
"What do you mean I have to create a password with 12 characters and at least one non-alphanumeric character? What do you mean I have to change my password once every 3 months? What do you mean my domain account can't be a global root account on every server in our global corporation even though my title is Assistant Project Manager? I'm going to talk to your boss, you puny IT serf."
Alternatively:
"What do you mean we need to approve a $2000 purchase request for IT infrastructure including a new domain se
Re:Management is the biggest vulnerability (Score:4, Informative)
All of those are perfectly good questions to ask your IT department.
- Requiring more complicated passwords does not improve security significantly as people start using simpler (to crack) passwords and writing them down (or worse putting them on a cloud-based notepad app)
- Requiring 3 month changes is likewise going to result in simpler passwords
- Allowing user domain accounts to have any credentials on any servers unnecessarily results in issues like having a single credential login to SSH on any server. You should only need your accounts authenticate against specific applications and do proper filtering (eg. only authenticate against cn=managers,ou=sales, not your entire LDAP tree).
- A 2007 IBM server should be able to handle plenty of directory services. LDAP is almost as old as the Internet, it's "light weight" and a single set of servers should be able to handle thousands if not millions of queries per minute. Off course, if you're tied into a single vendor *cough*Microsoft*cough*, you should've calculated the true cost in 2007.
Re: (Score:1)
If you're unfamiliar with the struggle between management and IT when it comes to management accounts having tons of unneeded access, you haven't worked in enterprise IT in a while.
Re: (Score:2)
Requiring people to regularly change their passwords is an utter fail. Competent security experts have known that for ages. Stupid "security" administrators are still ignorant of the fact.
Re: (Score:2, Insightful)
I support the concept of annual password changes. Much more than that and you quickly annoy your users, with very little gain in security.
Password complexity? Yes, but again, don't annoy your users. These arbitrary "must have one upper case and one lower case character, plus one number" BS rules, they aggravate the legitimate people you need on your side! Also, no words from the dictionary? Really? How do you think users remember their passwords?
If you are going to go full-on user hostile, then random
Re: (Score:2)
Security needs to be top priority.
Lets face it a proper secured environment is slightly inconvenient to the end user. That includes management, However if security had been a priority than management will need to think in terms of security. This means they will need to know what all their employees need to access and how they access them. Be disciplined enough to take a long passwords, and prepared to fully explain why an exception is needed and what additional safety precautions will be build around it.
New rule passwords must be changed each week (Score:2)
New rule passwords must be changed each week
Re: (Score:3)
"Okay, so my password this week is Password ..." *flips through calendar to check week number* "... Password31."
Re: (Score:2)
New rule passwords must be changed each week
Better yet, hourly. And no reusing any of the characters you used in the last 20 passwords.
Re:New rule passwords must be changed each week (Score:5, Funny)
New rule passwords must be changed each week
And it has to be written on a post-it on your monitor so we can check.
Re: (Score:2)
Re: (Score:2)
Next up..... (Score:2)
So... (Score:1)
Re: So... (Score:1)
http://world.std.com/~reinhold/diceware.html
Stop applying patches? Then you'll be in trouble. (Score:5, Insightful)
exploiting software doesn't even rank among the top five plays in the attacker's playbook
Only *because* you've been "Playing whack-a-mole with software vulnerabilities". If you stop applying patches, using exploits would be more productive.
Stronger passwords won't help (Score:5, Interesting)
Re: (Score:2)
Do you know if they're telling the truth?
If approached by a researcher I may thell them *a* password in exchange for chocolate - whether it's a valid one or not would be a matter for my conscience [is my deception greater than theirs? are the consequences of my lie better/worse than their planned action? ...]
Segementation of the Users themselves (Score:5, Interesting)
Any security tech worth their salt will tell you the same thing. The network needs to be protected from the users themselves. They are the primary way bad things enter the environment. To that end you need to do several things.
1. Segment off the entire gamut of user PCs and apply the same access restriction methodology you do to the Internet feed. Use a white list approach. Yes, they can reach more services internally. No, they cannot obtain administrative access. The user in front of the PC has no bearing on the PC's access.
2. Remove the ability to administer anything directly. Create a set of 'jump' or 'hop' boxes which employ some form of two-factor authentication, from which all administrative functions originate. And this includes everything from networking gear to application administration. No PC should be able to obtain any form of administrative access to anything, anywhere.
3. Use end node segmentation. Every server and network device must have a separate, non-routable management interface. The primary IP address, the one with the configured default gateway, is the one used to provide services. The management interface has a disjoint IP address, as in it can't be derived from the schema used to create the primary addresses. It has no routing capability, as in it can't communicate outside of its configured subnet. The Hop-box through which it is managed is housed on the same subnet. Hop-boxes provide the service of 'management' to the environment and employ the same addressing and routing scheme. In this way remote, or off-site administration is accomplished through normal routing to the hop-box, not to the device's management interface.
4. Management applications use a VDI methodology housed on the hop box. This includes even SSH clients to the networking devices. They only display on the PC, they don't run in its memory space. As a best practice, all of your applications similarly run as VDI services for the same reason. The end PC becomes much closer to a 'terminal' or portal to the applications, and its memory space and CPU are used only to draw on the screen and communicate with the VDI service. There is a financial advantage as well to loading software only onto VDI servers, instead of a set of desktops. This also aids in writing the firewall rules for user PC's as the only services they need are for Internet access, and the VDI protocol itself. This is a thin-client kind of design without using actual thin client hardware.
5. Eliminate the use of local storage. This includes thumb drives but is really focused on documents. For the most part laptop hard drives are not part of any backup process, and at some point some middle manager will complain about a key spreadsheet they lost because the only copy was on their laptop hard drive that just went belly up. Avoid that. Put everything onto a file server which has access controls and a backup schedule. If you need transfer capabilities, use any number of secured file transfer methodologies. Yes you will require a network connection to access your files. No this isn't really a problem anymore, and why would you be updating your business critical spreadsheet held on a thumb drive you can lose?
Among other things this alleviates the need for draconian Internet filtering policies. Let the users browse Facebook or even dark web sites. They are treated as the security cesspool they are and they cannot achieve a secure stance no matter what is running one them.
Another thing this eliminates is the need to control local admin rights to the PC's. Let anyone load whatever software they like. Heck, let the web link load malware. It won't accomplish anything. You can keylog all you want, it won't get you any access.
The final advantage this has is more operational in nature. Given that there is nothing critical contained on the PC, then any PC will do. If one goes belly up or is compromised by malware, then simply replace it with another from spares and the user continues on their way. Mean Time To Resolution becomes the time it takes to dispatch a replacement, and the failed/corrupted device can be examined offline and without impact to the user.
Re: Segementation of the Users themselves (Score:4, Insightful)
All the security you can come up with can be undone instantly if you offer the right person enough money.
Bribe the Tacacs server admin and you're golden. They'll set you up with access to anything and everything.
Pay them some more and they would probably disable logging for you.
Pro tip: Treat your IT folks well because they hold the keys to your entire Kingdom.
Pointless Debate (Score:2)
You can gain access to ANY corporations network on the entire planet, regardless of who they are using one simple time proven exploit.
Money.
Find an underpaid employee of your target company and offer them a crazy amount of money if they'll help you out.
Many will turn you down, but you'll always find one who won't.
For a State actor with an unlimited budget, this is trivial.
Re: (Score:1)
Better yet, hire somebody desperate but eager from the 3rd world for whom $500 means living well for a year...or even just living for a year.
Inside attacks (Score:1)
Huh? Most are software exploits (Score:2)