-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
aap-14811 Added modules for section 4.5 #812
Conversation
|
||
[role="_abstract"] | ||
|
||
Software patching is a fundamental activity of security and IT operations teams everywhere. Keeping patches up to date is critical to remediating software vulnerabilities and meeting compliance requirements, but patching systems manually at scale can be a time-consuming and error-prone process. Organizations should put thought into patch management strategies that meet their security, compliance, and business objectives, in order to prioritize the types of patches to apply (known exploits, critical or important vulnerabilities, optimizations, routine updates, new features, and so on) against the IT assets available across the enterprise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Software patching is a fundamental activity of security and IT operations teams everywhere. Keeping patches up to date is critical to remediating software vulnerabilities and meeting compliance requirements, but patching systems manually at scale can be a time-consuming and error-prone process. Organizations should put thought into patch management strategies that meet their security, compliance, and business objectives, in order to prioritize the types of patches to apply (known exploits, critical or important vulnerabilities, optimizations, routine updates, new features, and so on) against the IT assets available across the enterprise. | |
Software patching is a fundamental activity of security and IT operations teams everywhere. | |
Keeping patches up to date is critical to remediating software vulnerabilities and meeting compliance requirements, but patching systems manually at scale can be a time-consuming and error-prone process. | |
Organizations should put thought into patch management strategies that meet their security, compliance, and business objectives, in order to prioritize the types of patches to apply (known exploits, critical or important vulnerabilities, optimizations, routine updates, new features, and so on) against the IT assets available across the enterprise. |
|
||
Software patching is a fundamental activity of security and IT operations teams everywhere. Keeping patches up to date is critical to remediating software vulnerabilities and meeting compliance requirements, but patching systems manually at scale can be a time-consuming and error-prone process. Organizations should put thought into patch management strategies that meet their security, compliance, and business objectives, in order to prioritize the types of patches to apply (known exploits, critical or important vulnerabilities, optimizations, routine updates, new features, and so on) against the IT assets available across the enterprise. | ||
|
||
Once policies and priorities have been defined and a patching plan is established, the manual tasks involved in patch management can be automated using the {PlatformNameShort} to improve patch deployment speed and accuracy, reduce human error, and limit downtime. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once policies and priorities have been defined and a patching plan is established, the manual tasks involved in patch management can be automated using the {PlatformNameShort} to improve patch deployment speed and accuracy, reduce human error, and limit downtime. | |
Once you have defined policies and priorities and established a patching plan, you can automate the manual patch management tasks using the {PlatformNameShort}. | |
Automating the tasks improves patch deployment speed and accuracy, reduces human error, and limits downtime. |
|
||
[role="_abstract"] | ||
|
||
For organizations with a policy requiring that all RPMs including security errata be kept up to date, the following playbook might be used in a regularly scheduled job template. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For organizations with a policy requiring that all RPMs including security errata be kept up to date, the following playbook might be used in a regularly scheduled job template. | |
If your organization has a policy requiring that all RPMs including security errata be kept up to date, you can use the following playbook in a regularly scheduled job template. |
Best to avoid "might" in technical docs
|
||
[role="_abstract"] | ||
|
||
For some RHEL servers, such as a lab or other non-production systems, there may be a desire to install all available patches on a regular cadence. The following example playbook might be used in a job template that is scheduled to run weekly, and will update the system with all of the latest RPMs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some RHEL servers, such as a lab or other non-production systems, there may be a desire to install all available patches on a regular cadence. The following example playbook might be used in a job template that is scheduled to run weekly, and will update the system with all of the latest RPMs. | |
For some RHEL servers, such as a lab or other non-production systems, administrators might want to install all available patches on a regular cadence. | |
The following example playbook can be used in a job template that is scheduled to run weekly. It updates the system with all of the latest RPMs. |
{PlatformName} can connect your security teams, tools, and processes for more successful automation adoption and use. | ||
Learn how automation can help you safeguard your business and respond to growing security threats faster. | ||
|
||
link:https://www.redhat.com/en/resources/security-automation-ebook[Simplify your security operations center] provides an overview of the benefits to automating SOC operations, including use cases such as: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be useful to tell the reader that this is a Red Hat e-book?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds good to me! What do you think of something like: "For more information on the benefits of automating SOC operations, including use cases, see the Red Hat E-book link:https://www.redhat.com/en/resources/security-automation-ebook[_Simplify your security operations center_]. @ariordan-redhat
|
||
Automating the patching process provides a number of benefits: | ||
|
||
* Reduce error-prone manual effort. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Reduce error-prone manual effort. | |
* Reduces error-prone manual effort. |
Automating the patching process provides a number of benefits: | ||
|
||
* Reduce error-prone manual effort. | ||
* Decrease time to deploy patches at scale. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Decrease time to deploy patches at scale. | |
* Decreases time to deploy patches at scale. |
|
||
[role="_abstract"] | ||
|
||
For production systems, it is a well-established configuration management practice to deploy only known, tested combinations of software in order to ensure that systems are configured correctly and perform as expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For production systems, it is a well-established configuration management practice to deploy only known, tested combinations of software in order to ensure that systems are configured correctly and perform as expected. | |
For production systems, it is a well-established configuration management practice to deploy only known, tested combinations of software to ensure that systems are configured correctly and perform as expected. |
|
||
For production systems, it is a well-established configuration management practice to deploy only known, tested combinations of software in order to ensure that systems are configured correctly and perform as expected. | ||
This includes deploying only known versions of operating system software and patches to ensure that system updates do not introduce problems with production applications. | ||
The following example playbook will install a specific version of the httpd RPM and its dependencies when the target host uses the RHEL 9 operating system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following example playbook will install a specific version of the httpd RPM and its dependencies when the target host uses the RHEL 9 operating system. | |
The following example playbook installs a specific version of the `httpd` RPM and its dependencies when the target host uses the RHEL 9 operating system. |
|
||
In {PlatformNameShort}, multiple automation jobs can be chained together into workflows, which can be used to coordinate multiple steps in a complex patching scenario. | ||
|
||
In the following example complex patching scenario demonstrates taking virtual machine snapshots, patching the virtual machines, and creating tickets when an error is encountered in the workflow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the following example complex patching scenario demonstrates taking virtual machine snapshots, patching the virtual machines, and creating tickets when an error is encountered in the workflow. | |
The following example complex patching scenario demonstrates taking virtual machine snapshots, patching the virtual machines, and creating tickets when an error is encountered in the workflow. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
[role="_abstract"] | ||
|
||
The following set of defensive security controls are recommended to reduce operational risk of {PlatformNameShort} deployed on physical or virtual machines. | ||
These controls apply to all of the {PlatformNameShort} infrastructure nodes: the dedicated installation host, and any servers listed in the installation inventory such as controllers, hubs, EDA controllers, and the database server. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for "controllers, hubs, and EDA controllers" I would recommend checking with branding to get the name/shortname of each of these and probably parameterize them similar to PlatformName/PlatformNameShort. Maybe something to do in another PR?
.. In {ControllerName}, create the file `/etc/audit/rules.d/75-automation-controller.rules` with the following content, then run `augenrules --load` to load the new rules: | ||
|
||
----- | ||
-w /etc/tower/ -p warx -k aap-aac-mon-confdir | ||
-w /etc/supervisord.conf -p warx -k aap-aac-mon-supervisord | ||
-w /etc/supervisord.d/ -p warx -k aap-aac-mon-supervisord | ||
-w /etc/nginx/ -p warx -k aap-aac-mon-nginx | ||
-w /etc/receptor/ -p war -k aap-aac-mon-receptor | ||
-w /etc/redis/ -p war -k aap-aac-mon-redis | ||
----- | ||
|
||
. In {HubName}, create the file `/etc/audit/rules.d/75-automation-hub.rules` with the following content, then run `augenrules --load` to load the new rules: | ||
|
||
----- | ||
-w /etc/pulp/ -p warx -k aap-hub-mon-confdir | ||
-w /etc/redis/ -p war -k aap-hub-mon-redis | ||
-w /etc/nginx/ -p warx -k aap-hub-mon-nginx | ||
----- | ||
|
||
[NOTE] | ||
If the audit rules are set to be immutable (that is, `-e 2` is set in `/etc/audit/audit.rules`), a reboot will be required for the new audit rules to take effect. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did this procedure go through technical QA? it worked on a test system i built, but formal QA would be better.
AAP-14811
Added the following modules for Chapter 3 of Red Hat Ansible Automation Platform Hardening Guide v2.5:
Updated:
Deleted: