adding changelog and updating readme

nsx/4.x/ansible/vmware-nsx-4.x-stig-ansible-hardening/CHANGELOG.md

@@ -0,0 +1,6 @@
+# Change Log
+
+## [4.x Version 1 Release 1] (2023-03-07)
+
+#### Release Notes
+- Initial release

nsx/4.x/ansible/vmware-nsx-4.x-stig-ansible-hardening/README.md

@@ -11,12 +11,15 @@ This is a hardening playbook that utilizes Ansible to perform automated remediat
 - Please read through the README carefully and familiarize yourself with the playbook and ansible before running this playbook
 - As always please ensure you have a backout plan if needed you can roll back the changes
 - This playbook has not been tested for forward or backward compability beyond the version of NSX listed under requirements.
+- Some NSX-T STIG controls can be very impactful to your environment if care is not taken during implementation especially in a brownfield scenario. For example, changing the default DFW rule to deny traffic without first creating rules to allow authorized traffic. 
 
 ## Requirements
-- [Ansible](https://docs.ansible.com/ansible/latest/installation_guide/index.html) installed on a machine that can SSH to the target node(s).  Tested with Ansible 2.12.10.
+- [Ansible](https://docs.ansible.com/ansible/latest/installation_guide/index.html) installed on a machine that can SSH to the target node(s).  Tested with Ansible 2.14.4.
+- Install [JMESPath](https://pypi.org/project/jmespath/) for community.general.json_query collection.
 - an API token is needed and must be provided at the CLI or vars file
 - The manager IP or FQDN must be provided at the CLI or vars file
 - This playbook does not include remediation for the SDN Controller controls
+- An account with sufficient privileges to configure NSX  
 
 ## Playbook Structure
 
@@ -29,20 +32,29 @@ This is a hardening playbook that utilizes Ansible to perform automated remediat
 - /roles/<role name>/templates - Any template files used in the role
 - /roles/<role name>/vars/main.yml - variables referenced by tasks.  Update these variables as needed for your environment.
 
-## How to run
+## Generate API Session Token
+This playbook uses Session-Based authentication to authenticate with NSX for remediation. A session token and cookie must be generated and provided an input for the profile. This can be generated in various ways via curl, tools like Postman, etc. For more information see the [NSX API Documentation](https://developer.vmware.com/apis/1583/nsx-t).
+
+**Note:** If the user is a remote user, append "@domain" to the username, for example, "[email protected]". The domain must match a domain for a configured VIDM identity source or a configured LDAP identity source.  
+
+## Update vars file
+In order to run the playbook, environment specific values need to be provided. An example vars file `vars-nsx-4x-example.yml` is provided and values need to be updated for the `var_nsx_manager`, `var_jsession_id`, `var_session_token`, `var_ntp_server1`, `var_ntp_server2` variables at a minimum.  
 
-Run all controls on a target manager. Displays verbose output, and specifies a vars files to pass variables to the playbook  
+## How to run
+Run all controls for NSX-T and specify a vars file.
 ```
 ansible-playbook playbook.yml -v --extra-vars @vars-nsx-4x-example.yml
 ```
-Run controls for one role by specifying a tag.  
+Run controls for one role (manager in this example) by specifying a tag.  
 ```
 ansible-playbook playbook.yml -v --extra-vars @vars-nsx-4x-example.yml --tags manager
 ```
 Run a specific control by specifying a tag.  
 ```
-ansible-playbook playbook.yml -v --extra-vars @vars-nsx-4x-example.yml --tags NMGR-4X-000097
+ansible-playbook playbook.yml -v --extra-vars @vars-nsx-4x-example.yml --tags NDFW-4X-000004
 ```
 
+**Note:** All commands above are ran from the playbooks root directory. If running from a different location adjust the paths accordingly.  le-playbook playbook.yml -v --extra-vars @vars-nsx-4x-example.yml --tags NMGR-4X-000097
+
 ## Misc
 - If vars need to be updated we recommend either creating a vars file to specify at the command line or adding them to the main playbook.yml or your own playbook.yml so that it is easy to track what is being altered from the original state.