Timeline for Why does DISA STIG recommend "Deny access to this computer from the network" for Domain Admins?
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 14, 2016 at 3:07 | review | Low quality posts | |||
| Aug 14, 2016 at 3:46 | |||||
| Aug 14, 2016 at 1:12 | comment | added | atdre | The STIG should be updated. I don't even know if CIS Benchmarks are current with what Microsoft provides in a 2012, 2012 R2, and definitely not a 2016 functional-domain level. Don't expect everyone in the world to be able to go this deep with ever-changing Microsoftisms. It's highly-specialized Red Team and/or DFIR Tradecraft | |
| Aug 14, 2016 at 1:07 | comment | added | Bill_Stewart | Your comment on my answer is good in that it delineates between process and technical policy. This setting enforces good process policy, but my question is about what this setting does technically--does it actually do what the STIG says it does? The answer to this question is no; it actually does not. In other words, the STIG recommendation should be updated to explain that its purpose is process policy rather than technical policy. | |
| Aug 14, 2016 at 1:05 | comment | added | atdre | No worries -- it's a highly-technical scenario. Usually that results in a language barrier, but one I believe we've overcome! | |
| Aug 14, 2016 at 0:56 | comment | added | Bill_Stewart | Thanks for the references. However, I confess I must not be explaining myself properly. I'm not asking for opinions about whether this setting is best practice--I agree that it has its place, but that's not what I am asking. I am pointing out that it does not prevent credential stealing on a potentially compromised host--it prevents the connection, yes, but it doesn't mean that it prevents credential exposure. (I guess I must be doing a poor job explaining the actual question, or perhaps there is a language barrier...) | |
| Aug 14, 2016 at 0:49 | history | answered | atdre | CC BY-SA 3.0 |