updates for 4.6

content/modules/ROOT/nav.adoc

@@ -14,8 +14,8 @@
 
 //Extra modules
 
-* xref:11-tssc.adoc[11. Trusted Software Supply Chain]
-* xref:misc-hacking-linux.adoc[CTF - hack a web application]
+* xref:11-tssc.adoc[MISC: Trusted Software Supply Chain]
+* xref:misc-hacking-linux.adoc[MISC: CTF - hack a web application]
 * xref:misc-log-4-shell-lab.adoc[MISC: log4shell example]
 // * xref:partner-paladin.adoc[Partner - Paladin Cloud & RHACS Integration]
 

content/modules/ROOT/pages/00-setup-install-navigation.adoc

@@ -623,9 +623,16 @@ Showing that the latest version of Ubuntu from Docker.io has 0 critical vulnerab
 
 *Your turn*
 
+IMPORTANT: Make sure to set the image in the MYIMAGE variable, or put the image into the command.
+
+
 [source,sh,subs="attributes",role=execute]
 ----
 MYIMAGE=<Add the registry URL here>
+----
+
+[source,sh,subs="attributes",role=execute]
+----
 roxctl --insecure-skip-tls-verify -e "$ROX_CENTRAL_ADDRESS:443" image scan --image $MYIMAGE --force -o table --severity=CRITICAL
 ----
 

content/modules/ROOT/pages/01-visibility-and-navigation.adoc

@@ -217,6 +217,10 @@ The network user interface contains two drop-downs: the *Network Graph* tab and
 
 > *Click on the Network Graph tab*
 
+image::00-network-0.png[link=self, window=blank, width=100%]
+
+> *To see results, sort by Cluster -> Namespace -> Deployment. Try Production + Backend*
+
 image::00-network-1.png[link=self, window=blank, width=100%, Dashboard Filter]
 
 The network graph tab allows you to visualize all the network connections in your cluster look at Baseline flows simulate Network policies manage CIDR blocks and more

content/modules/ROOT/pages/02-vulnerability-management-lab.adoc

@@ -165,13 +165,14 @@ Notice which images are more exposed. Not only can we see the number of CVEs aff
 
 [start=4]
 
-. Next, find and click on the image *ctf-web-to-system:latest-v2*. You will review the images' components and violations.
+. Next, find and click on the image *ctf-web-to-system:1.0*. You will review the images' components and violations.
 
 image::acs-risk-05.png[link=self, window=blank, width=100%, Visa Processor Image]
 
-NOTE: If you cannot find the ctf-web-to-system:latest-v2 image, use the search bar to filter for the specific image you want. Try searching by *deployment* and then entering *ctf-web-to-system*
+NOTE: If you cannot find the ctf-web-to-system:1.0 image, use the search bar to filter for the specific image you want. Try searching by *deployment* and then entering *ctf-web-to-system*
 
 image::acs-risk-06.png[link=self, window=blank, width=100%, Search Bar]
+image::acs-risk-061.png[link=self, window=blank, width=100%]
 
 You can move on to the next section only when the dashboard displays the image below.
 
@@ -338,7 +339,7 @@ You can identify vulnerabilities in your nodes by using RHACS. The same logic th
 
 *Procedure*
 
-. In the RHACS portal, go to Platform Configuration → Integrations.
+. In the RHACS portal, go to Vulnerability Management -> Node CVEs.
 . Find and review RHSA-2024:1780
 
 What is the CVE associated with this RHSA? What would you do to fix it?

content/modules/ROOT/pages/03-risk-profiling.adoc

@@ -288,20 +288,20 @@ image::05-policy-1.png[link=self, window=blank, width=100%]
 [start=4]
 . Give the policy all of the necessary information and complete the required fields then hit next.
 
-* *Name*: `No bash allowed`
+* *Name*: `No apt-get allowed`
 * *Severity*: `High`
 * *Categories*: `Anomalous Activity`
-* *Description*: `No bash allowed`
-* *Rationale*: `Too many known vulns`
-* *Guidance*: `Use ZSH`
-* *MITRE ATT&CK*: `The policy can be mapped to a MITRE ATT&CK technique.`
+* *Description*: `No package managers allowed`
+* *Rationale*: `Privilege escalation technique`
+* *Guidance*: `Uninstall during container build`
+* *MITRE ATT&CK*: `(Optional) The policy can be mapped to a MITRE ATT&CK technique.`
 * *Lifecycle stages*: `Runtime`
 * *Event sources*; `Deployment`
+* *Rules*: Process activity -> Process Name -> apt-get
+* *Activation state*: Enable 
 * *Response method*: `Inform`
 * *Inform and enforce*: `Enform on Runtime`
 
-* *Policy Crieria*: `On the right there is a *drag out policy fields* bar.Find *Process Activity* and select *Unexpected process executed*. Drag into into the policy section.`
-
 Make sure to preview the policy before accepting it. 
 
 === Advanced Filtering

content/modules/ROOT/pages/04-policy-management.adoc

@@ -58,7 +58,7 @@ image::acs-runtime-01.png[link=self, window=blank, width=100%]
 
 [start=5]
 
-. Select the *Policy Behavior* tab by hitting next or clicking the tab.
+. Select *Policy Behavior -> Actions*
 
 image::acs-runtime-02.png[link=self, window=blank, width=100%]
 
@@ -71,7 +71,7 @@ image::acs-runtime-03.png[link=self, window=blank, width=100%, Enforce Runtime P
 
 [start=8]
 
-. Go to the *Review Policy* tab
+. Go to the *Review* tab
 . Review the changes
 . Click save
 
@@ -199,26 +199,35 @@ image::acs-deploy-01.png[link=self, window=blank, width=100%]
 
 [start=5]
 
-. Next, update the policy to *inform and enforce* while clicking on the deploy stage only.
-
-IMPORTANT: Make sure to unselect the *Build* lifecycle before moving forward.
+. Next, update the policy by clicking on the *Build* stage so that only the Deploy stage is selected.
 
 image::acs-deploy-02.png[link=self, window=blank, width=100%]
 
+IMPORTANT: Make sure to unselect the *Build* lifecycle before moving forward. This will trigger an alert!
+
+image::acs-deploy-021.png[link=self, window=blank, width=100%]
+
+We will have to add the policy criteria back. This is because certain actions can only be done in the build, deploy, or runtime stages.
+
 Now, we want to target our specific deployment with an image label.
 
 [start=6]
-. Click on the *Policy criteria* tab.
-. Click on the *Deployment metadata* dropdown on the right side of the browser.
-. Find the *Namespace* label and drag it to the default policy criteria.
-. Type *default* under the namespace criteria
+. Click on the *Rules* tab.
+. Click on the *Image contents* dropdown on the right side of the browser.
+. Find the *Image component* label and drag it to the default policy criteria.
+. Type *apt-get* under the criteria
 
 Your policy should look like this,
 
 image::acs-deploy-04.png[link=self, window=blank, width=100%]
 
 [start=10]
 
+. In Policy behavior -> Actions, click *Inform and enforce*.
+
+image::acs-deploy-044.png[link=self, window=blank, width=100%]
+
+[start=11]
 . Lastly, go to the *Review Policy* tab
 . Review the changes
 
@@ -419,8 +428,8 @@ NOTE: Use the quay admin credentials, Username: *{quay_admin_username}* & passwo
 
 [source,sh,subs="attributes",role=execute]
 ----
-podman pull ubuntu:latest
-podman tag docker.io/library/ubuntu:latest $QUAY_URL/$QUAY_USER/ctf-web-to-system:1.0
+podman pull $QUAY_URL/$QUAY_USER/ctf-web-to-system:1.0
+podman tag docker.io/library/ubuntu:latest $QUAY_URL/$QUAY_USER/ctf-web-to-system:1.1
 ----
 
 |====
@@ -433,7 +442,7 @@ The following command is designed to mimic and build a pipeline where a containe
 [source,sh,subs="attributes",role=execute]
 ----
 roxctl --insecure-skip-tls-verify -e "$ROX_CENTRAL_ADDRESS:443" image check --image=$QUAY_URL/$QUAY_USER/ctf-web-to-system:1.0 
-podman push $QUAY_URL/$QUAY_USER/ubuntu:latest --remove-signatures
+podman push $QUAY_URL/$QUAY_USER/ctf-web-to-system:1.1 --remove-signatures
 ----
 
 IMPORTANT: We are using the *image check* CLI option, NOT the image scan. 
@@ -482,9 +491,6 @@ image::05-build-1.png[link=self, window=blank, width=100%]
 
 . Next, update the policy to *inform and enforce* while ensuring the Build stage checkbox is selected And select Enforce on Build at the bottom of the page.
 
-IMPORTANT: Make sure to unselect the *DEPLOY* lifecycle before moving forward.
-
-image::05-build-2.png[link=self, window=blank, width=100%]
 image::05-build-3.png[link=self, window=blank, width=100%]
 
 [start=6]
@@ -499,8 +505,10 @@ Now let's test it out!
 
 [source,sh,subs="attributes",role=execute]
 ----
-roxctl --insecure-skip-tls-verify -e "$ROX_CENTRAL_ADDRESS:443" image check --image=docker.io/library/ubuntu 
-podman push $QUAY_URL/$QUAY_USER/ubuntu:latest --remove-signatures
+podman pull $QUAY_URL/$QUAY_USER/ctf-web-to-system:1.1
+podman tag docker.io/library/ubuntu:latest $QUAY_URL/$QUAY_USER/ctf-web-to-system:1.2
+roxctl image check --insecure-skip-tls-verify -e "$ROX_CENTRAL_ADDRESS:443"  --image=$QUAY_URL/$QUAY_USER/ctf-web-to-system:1.2 
+podman push  $QUAY_URL/$QUAY_USER/ctf-web-to-system:1.2 --remove-signatures
 ----
 
 [.console-output]
@@ -521,144 +529,6 @@ ERROR:  checking image failed after 3 retries: failed policies found: 1 policies
 
 IMPORTANT: You should see the same violations from the previous command EXCEPT now you have a failed policy check. This woruld send an exit 0 command if this was run in any pipeline. 
 
----
-
-## Hands-On Walk-Through: Managing Policies as Code in RHACS
-
-This guide provides a step-by-step walk-through to help you explore and demo managing policies as code in Red Hat Advanced Cluster Security (RHACS). This hands-on approach will give you a practical understanding of configuring and managing policies using Kubernetes-native tools like Argo CD.
-
-### What is Policy as Code?
-
-Policy as code enables you to define and manage security policies as Kubernetes custom resources (CRs). These policies can be applied to clusters using continuous delivery (CD) tools such as Argo CD. This approach allows Kubernetes security architects to define policies in YAML or JSON, providing an alternative to using the RHACS portal.
-
-### Key Features
-- **Create custom policies locally**: Author policies in YAML or JSON files and use GitOps workflows to manage them.
-- **Use continuous delivery tools**: Leverage Argo CD or other GitOps tools to deploy and manage policies across clusters.
-- **Monitor policy drift**: Understand and resolve discrepancies between policies stored in Kubernetes and RHACS.
-
-#### Configure Argo CD for Policy as Code
-1. **Install the RHACS Configuration Controller**: This is automatically installed in the `stackrox` namespace when RHACS is deployed.
-2. **Set Up Argo CD Communication**:
-   - Configure Argo CD to interact with the RHACS controller via the Kubernetes API.
-   - Ensure Argo CD monitors the namespace where RHACS Central is installed.
-
-#### **3. Enable GitOps Integration (Optional)**
-For workflows that do not use Argo CD:
-- Use the RHACS API to connect your GitOps repository (e.g., GitHub) directly to Central.
-- Manage policies as CRs stored in your repository.
-
----
-
-### **Creating Policies as Code**
-
-#### **Option 1: Using the RHACS Portal**
-
-1. **Create or Clone a Policy**:
-   - Navigate to the Policy Management page.
-   - Create a new policy or clone an existing default policy.
-2. **Save as a Custom Resource (CR)**:
-   - Click the kebab (overflow menu) next to the policy.
-   - Select **Save as Custom Resource**.
-   - For bulk saving, use **Bulk Actions** > **Save as Custom Resources**.
-3. **Apply the Policy CR**:
-   - Use `kubectl apply` or `oc apply` to deploy the CR to the namespace where Central is installed:
-
-     ```bash
-     $ kubectl apply -f your-policy.yaml
-     ```
-   - Alternatively, push the CR to the namespace using Argo CD or another GitOps tool.
-
-#### **Option 2: Manually Authoring a Policy CR**
-
-1. **Construct the CR**:
-   - Use a text editor to define the policy as a Kubernetes CR with the following attributes:
-
-     ```yaml
-     kind: SecurityPolicy
-     apiVersion: config.stackrox.io/v1alpha1
-     metadata:
-       name: short-name
-     spec:
-       policyName: A longer form name
-       # ...
-     ```
-   - Use `kubectl explain securitypolicy.spec` for field definitions.
-2. **Apply the Policy CR**:
-   - Use `kubectl apply` or `oc apply`:
-
-     ```bash
-     $ kubectl apply -f your-policy.yaml
-     ```
-   - Or push the CR to the namespace via Argo CD or GitOps.
-
----
-
-### **Understanding Policy Drift**
-
-Policy drift occurs when the version of a policy in RHACS Central does not match the version in Kubernetes. Drift can happen when changes are made directly in the RHACS portal or API rather than updating the CR.
-
-> **Note:** Drift is resolved automatically within 10 hours. To avoid drift, always modify policies through their corresponding CRs.
-
----
-
-### **Disabling the Policy as Code Feature**
-The policy as code feature is enabled by default but can be disabled if needed.
-
-#### **Procedure**
-- **Operator Method**: Set the `spec.configAsCode.configAsCodeComponent` field to `Enabled`.
-- **Helm Method**: Set `configAsCode.enabled` in the `values.yaml` file to `true`.
-- **Manifest Method**:
-
-  Delete the configuration controller deployment:
-
-  ```bash
-  $ kubectl -n stackrox delete deployment config-controller
-  ```
-
-  Replace `kubectl` with `oc` if using OpenShift.
-
----
-
-### **Wrap-Up and Next Steps**
-
-This hands-on demo provides an overview of managing policies as code in RHACS. Practice creating, managing, and resolving policy configurations using both the RHACS portal and manual methods. For additional details, consult the [official RHACS documentation](https://docs.openshift.com/acs/4.6/operating/manage_security_policies/custom-security-policies.html#policy-as-code-about_custom-security-policies).
-
-== Understand Violations in RHACS
-
-Violations taken together determine _risk_, which you covered in previous labs. In this lab, you explore how to determine the details of those violations to plan and implement their remediation.
-
-The *Violations* view allows you to see these details.
-
-Using RHACS, you can view policy violations, drill down to the actual cause of the violation, and take corrective actions.
-
-The built-in policies identify a variety of security findings, including vulnerabilities (CVEs), violations of DevOps best practices, high-risk build and deployment practices, and suspicious runtime behaviors.
-You can use the default out-of-the-box security policies or your own custom policies.
-
-== Report and Resolve Violations
-
-In this last section. We will resolve a few of the issues that we have created.
-
-*Procedure*
-
-. Navigate to the *Violations* page.
-. Filter by the policy violation *Ubuntu Package Manager Execution* OR by the most recent policy violations. You will see a build, deploy and runtime policy violation that has been enforced one time.
-
-image::05-violation-1.png[link=self, window=blank, width=100%, Violations Menu]
-
-[start=3]
-. Click the most recent violation and explore the list of the violation events:
-
-If configured, each violation record is pushed to a Security Information and Event Management (SIEM) integration and is available to be retrieved via the API. The forensic data shown in the UI is recorded, including the timestamp, process user IDs, process arguments, process ancestors, and enforcement action.
-
-After this issue is addressed, in this case by the RHACS product using the runtime enforcement action, you can remove it from the list by marking it as *Resolved*.
-
-[start=4]
-
-. Lastly, hover over the violation in the list to see the resolution options and resolve this issue.
-
-image::acs-violations-01.png[link=self, window=blank, width=100%, Resolve Violations]
-
-For more information about integration with SIEM tools, see the RHACS help documentation on external tools.
 
 == Summary