👍🎉 First off, thanks for taking the time to contribute! 🎉👍
The following is a set of guidelines for contributing to the CyberArk Hardening Check tool. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
This repository is maintained by good people that take the time to make this tool better with hardening best practices and not by official CyberArk R&D.
For general contribution and community guidelines, please see the community repo.
This tool is built using Powershell. You should be familiar with PowerShell before contibuting to this project.
In the Bin folder, there are two main powershell modules: CommonUtil, GeneralHardeningSteps
Note: a powershell module is constructed by two main files:
- The Metadata file of the module (using a *.psd1 extension)
- The module file (using a *.psm1 extension)
The CommonUtil holds all the shared functions that perform the check on the machine, it holds the "bear-metal" functions to keep this tool going The GeneralHardeningSteps holds all hardening steps that are common to all components, any hardening step that is component specific should be in the relevant Component Hardening folder.
Doing major changes in one of those module files (*.psm1) should be accompanied with an increase in the module version in the metadata file (*.psd1)
The script architecture is structured in a way that each component has its own folder In the folder there are all relvant files for the component hardening. Two main files are the Hardening steps script (saved as *.psm1) and the hardening configuration (saved as *.xml)
- Write-LogMessage
- Join-ExceptionMessage
- Get-WMIItem
- Test-InDomain
- Test-LocalUser
- Test-InstalledWindowsRole
- Test-ServiceRunWithLocalUser
- Get-DnsHost
- Get-LocalAdministrators
- Get-LocalSystem
- Get-ServiceInstallPath
- Get-SeceditAnalysisResults
- Get-ParsedFileNameByOS
- Get-DetectedComponents
- Compare-ServiceStatus
- Compare-AuditRulesFromPath
- Compare-RegistryValue
- Compare-UserRight
- Compare-PolicyEntry
- Compare-UserPermissions
- Compare-UserFlags
- Compare-AmountOfUserPermissions
- Compare-AdvancedAuditPolicySubCategory
- Compare-EventLogSizeAndRetentionSettings
- Convert-NameToSID
- Convert-SIDToName
- ConvertTo-Bool
- Start-HardeningSteps
- Test-CredFileVerificationType
- ImportingINFConfiguration
- ValidateServerRoles
- EnableScreenSaver
- AdvancedAuditPolicyConfiguration
- RemoteDesktopServices
- EventLogSizeAndRetention
- RegistryAudits
- RegistryPermissions
- FileSystemPermissions
- FileSystemAudit
- DisableServices
- Vault_NICHardening
- Vault_StaticIP
- Vault_WindowsFirewall
- Vault_DomainJoined
- Vault_LogicContainerServiceLocalUser
- Vault_FirewallNonStandardRules
- Vault_ServerCertificate
- CPM_Password_Manager_Services_LocalUser
- CPM_EnableFIPSCryptography
- CPM_DisableDEPForExecutables
- CPM_CredFileHardening
- PVWA_IIS_Registry_Shares
- PVWA_IIS_WebDAV
- PVWA_Cryptography_Settings
- PVWA_IIS_MimeTypes
- PVWA_AnonymousAuthentication
- PVWA_DirectoryBrowsing
- PVWA_IIS_SSL_TLS_Settings
- PVWA_IIS_Cypher_Suites
- PVWA_Scheduled_Task_Service_LocalUser
- PVWA_NonSystemDrive
- PVWA_IIS_Hardening
- PVWA_AdditionalAppPool
- PVWA_CredFileHardening
- ConfigureUsersForPSMSessions
- PSMForWebApplications
- EnableUsersToPrintPSMSessions
- SupportWebApplications
- ClearRemoteDesktopUsers
- RunApplocker
- ConfigureOutOfDomainPSMServer
- DisableTheScreenSaverForThePSMLocalUsers
- HidePSMDrives
- BlockIETools
- HardenRDS
- HardenPSMUsersAccess
- HardenSMBServices
- PSM_CredFileHardening
- SecureTunnel_Permissions
Before adding a new hardening check, think if it is a component specific hardening or a general best practive hardening check. If it is a specific one, create it in the relevant component hardening file with the naming convention of _ If it is a general one, create it in the GeneralHardeningSteps file with the naming convention of <Hardening check name in Camel Case - no spaces>
You will be responsible testing your own code, please make sure to adhere to the functions naming convention and add the relevant documentation link if available.
- Fork the project
- Clone your fork
- Make local changes to your fork by editing or creating new files
- Commit your changes
- Push your local changes to the remote server
- Create new Pull Request
From here your pull request will be reviewed and once you've responded to all feedback it will be merged into the project.
Congratulations, you're a contributor! 🎉🎉🎉
This section guides you through submitting a bug report or an issue with one of the script published in this repository. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.
When you are creating a bug report, please include as many details as possible and make sure you run the script with Debug and Verbose logging (In all PowerShell scripts just add '-Debug -Verbose' at the end of the script command).
Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.
Before Submitting A Bug Report Run the script with Verbose logging. Perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.