Allow for remote scanning

[hearts1137]

Hi,

I like the script. Would it be possible to allow for the traditional services and security settings used for vulnerability settings?

Using a tool like Tenable Nessus the scans fail due to many security settings being disabled. It would also be nice to have an option to allow remote desktop. When the script runs it completely disabled RDP and it takes more than a few clicks to get it back to where it can be turned on.

Thanks

[github-actions]

Message that will be displayed on users' first issue

[simeononsecurity]

Hi,

I like the script. Would it be possible to allow for the traditional services and security settings used for vulnerability settings?

Using a tool like Tenable Nessus the scans fail due to many security settings being disabled. It would also be nice to have an option to allow remote desktop. When the script runs it completely disabled RDP and it takes more than a few clicks to get it back to where it can be turned on.

Thanks

So it depends on if you want to do credentialed scanning or unauthenticated scanning.
For credentialed, enable WMI over HTTPs / PSRemoting or use one of the Nessus Agents.
If you're going for unauthenticated, that's pretty much the point. It disables services to make the system more secure. Thus less will show up in scans.

Remote desktop isn't disabled either, it just enforces more secure standards for it. If you can't rdp into the box it's likely because of incompatibilities from the RDP clients configuration.

@hearts1137

[hearts1137]

I am doing credentialed scanning using Nessus Manager, not agent scans. WMI not available is the likely cause as far as I can tell. That and the admin shares seem to not exist IPC$ C$ and so on. It all gets too locked down.

The system I inherited is using the DISA SHB so it's kind of compliant but things like office and the browsers are not STIG'd.

Running the standalone script with no options is what I call "STIG'ing the system to death". No remote scans, no remote desktop, no remote anything really unless you join it to a domain and it inherits domain group policy.

I run the script with -cleargpos $false -installupdates $false -windows $false -firewall $false -mitigations $false -nessusPID $false -horizon $flase -sosoptional $false

*note: the -sosoptions option does not work. powershell complains it is not a valid cmdlet or something.

For a system that does not have RDP enabled, you can simply enable it by right clicking the start button - system - remote desktop - toggle the button to on. When the script is run with no option this setting is greyed out and to re-enable it takes some digging to find the right registry key, or local GPO, to un-grey it out so RDP can be enabled. That's all I meant.

Despite any of that the script is still amazing. It saves so much time. I run the Navy EvaluateSTIG against it and get to fixing what your script does not. Seems to be just office, Word and Excel specifically but it's quick work. Run another STIG scan and done. Thank you for providing this script. I also import the adml templates to make changing settings easier than searching the registry.

[simeononsecurity]

I am doing credentialed scanning using Nessus Manager, not agent scans. WMI not available is the likely cause as far as I can tell. That and the admin shares seem to not exist IPC$ C$ and so on. It all gets too locked down.

The system I inherited is using the DISA SHB so it's kind of compliant but things like office and the browsers are not STIG'd.

Running the standalone script with no options is what I call "STIG'ing the system to death". No remote scans, no remote desktop, no remote anything really unless you join it to a domain and it inherits domain group policy.

I run the script with -cleargpos $false -installupdates $false -windows $false -firewall $false -mitigations $false -nessusPID $false -horizon $flase -sosoptional $false

*note: the -sosoptions option does not work. powershell complains it is not a valid cmdlet or something.

For a system that does not have RDP enabled, you can simply enable it by right clicking the start button - system - remote desktop - toggle the button to on. When the script is run with no option this setting is greyed out and to re-enable it takes some digging to find the right registry key, or local GPO, to un-grey it out so RDP can be enabled. That's all I meant.

Despite any of that the script is still amazing. It saves so much time. I run the Navy EvaluateSTIG against it and get to fixing what your script does not. Seems to be just office, Word and Excel specifically but it's quick work. Run another STIG scan and done. Thank you for providing this script. I also import the adml templates to make changing settings easier than searching the registry.

To be fair this script is meant for standalone machines as stated in the intro to the readme https://github.com/simeononsecurity/Standalone-Windows-STIG-Script/tree/master#introduction . That usually means that they aren't going to have network connectivity. They "stand alone". With that in mind, it also disables wmi and various other kinds of networked services. It would be very rare to see a networked machine that isn't domain joined. Partially because many of the FISMA, NIST 800-53, and RMF controls pretty much require centralized authentication and access control of systems. The best way in modern networks to accomplish that is a windows domain. In the case that you have a domain you should be using this repo here: https://github.com/simeononsecurity/STIG-Compliant-Domain-Prep . Now if it is genuinely a standalone system, you can scan that with a standalone on system vuln scanner. If it is a networked system that isn't apart of the domain, your IA department likely isn't doing their job very well.

STIGs do break things. But they do it for a reason. The readme does state that you shouldn't run it if you don't understand it.
We've done our best to ensure it doesn't break anything critical in the process and have specifically left some checks not implemented because of it. But again, standalone means no network. Assumptions are made there.

Also, we added the configuration options to allow users to choose. However we only test all options on. To test every combination of things would be improbable, even with automated testing.

With RDP, it's a simple GPO. Any junior admin that has ever done the STIGs manually before would be aware of this configuration option. I suggest you review those.

Back to the stand alone issues. WMI isn't going to be disabled with gpo. The script should just remove the listeners. So it only takes one command to enable that again if that is desired.

With the sos options that is an actual mistake in the documentation. Those options where removed when the FireFox STIG and Microsoft Chromium Edge got actual GPOS and STIGs available. Thus making my workaround gpos with registry hacks redundant. I've fixed the documentation in this commit. 902802b

I've used the Eval tool from the navy. Make sure you have the latest version always when you use it. It often has bugs. Even still it is better than the other common tools.

Also, this tool specifically does support office and all versions from 2013 onward.
https://github.com/simeononsecurity/Standalone-Windows-STIG-Script/tree/master/Files/GPOs/DoD/Office
I can test again in a few hours to confirm. However it did pass our automated testing. It's possible there are other issues on your system preventing them from applying effectively.

The vast majority of the GPOs in this script come from the same sources that originally were used to build SHB and before that AGM. The only difference is that we implemented the deltas between them and what the STIGs say while minimizing or even changing what already existed to reduce bugs and breaking of features where possible.

Seriously, however, don't always rely on third party scripts. They are never perfect. You need to understand what you're running. In practically every company, you are required to get approval before running new scripts or software on a system. My scripts are included in that. They aren't endorsed by the DoD. It's up to your IA department and your system owner to determine what the acceptable levels of risk are and what is required to approve new software on your systems. If you had proper process for that, also including change control, issues with scripts like these would've been discussed at those meetings. And, almost certainly, you would've been required to test it on a virtual machine or test environment before running it anywhere near production.

I'm glad to save people time. But slow down a bit. understand what you're doing. Read the full readme. If you need to, ask questions. But don't run random scripts online without knowing what they do. No matter how trustworthy a source may seem, you should always verify first. If you can't do that, you shouldn't run the scripts at all.

[hearts1137]

I appreciate your comments, as snarky as they are. I've been in the IA world since eEye Retina and have used the Army Golden Master Image as well as their BAT so I don't really need your slow down comments. I'm already running on a VM vs a production system. And where I work standalone systems not on a domain are common, however unfortunate. Just the nature of what we do in a cloud hybrid model and different security enclaves.

Thanks for the script, it's cool.