Hardening systems: from a benchmark guide to meaningful compliance

🎥 Coming soon
🧑 Nicolas Charles
📅 Configuration Management Camp 2024

New standards are constantly appearing and must be applied to a larger number of systems. Sometimes with very little time available from the law to the actual enforcement.
Applying standards on a clean state is in itself a difficult task. But when it’s on existing infrastructures, it gets very complex with potentially a lot of divergences to identify and exceptions to be made.
There are plenty of existing solutions. But they are often either one-size-fits-all, or they can audit but not remediate, or they cannot be consolidated over all the IT.
In this talk, I will present how we implemented a CIS Server benchmarks on an existing infrastructure using Rudder. It starts from the reference Excel Benchmarks from CIS to finish by the implementation of every control point, with default values and mixed audit and remediation mode. It concludes by showing how having a graphical interface makes the reporting to relevant stakeholders helpful.
This implementation involves a lot of YAML, some KCL to generate even more YAML, and unfortunately some bash scripts…

Transcript

1. Hardening systems From a benchmark guide to meaningful compliance
2. All rights reserved Outline This talk is a feedback from what we do. It presents how we implemented CIS benchmarks, with incremental improvements • As a full audit, one size fit them all approach • With exceptions • With non defaults values • And remediations • And exposing compliance in a meaningful way
3. All rights reserved Hardening systems Cyber-security threats are more and more pervasive. • Bots, state actors, disgruntled people • Attacks are getting very sophisticated • Even security tools can be a risk • Human error happens
4. All rights reserved Hardening systems IT systems need to be protected to mitigate and prevent risks It’s is even mandatory for a lot of enterprises and organisations (NIS2, PCI DSS, …), with punitive sanctions
5. All rights reserved Center for Internet Security The Center for Internet Security (CIS) is a US 501(c)(3) nonprofit organization, formed in October 2000. Its mission statement professes that the function of CIS is to "help people, businesses, and governments protect themselves against pervasive cyber threats." From wikipedia https://en.wikipedia.org/wiki/Center_for_Internet_Security
6. All rights reserved CIS Benchmarks CIS Benchmarks [..] allow IT workers to create reports that compare their system security to universal consensus standard. This fosters a new structure for internet security that everyone is accountable for and that is shared by top executives, technology professionals and other internet users throughout the globe From wikipedia https://en.wikipedia.org/wiki/Center_for_Internet_Security
7. Show me the code benchmark!
8. All rights reserved CIS Benchmarks What it is really?
9. All rights reserved CIS Benchmarks What it is really? It’s recommendations, distributed via very large XLS/PDF files (XLS are easier to process)
10. All rights reserved CIS Benchmarks The recommendations: • Identified by their id (3.4.1.1), • With manual or automated assessment • A human description and the rationale of the recommendation • The impact the change might have • The audit procedure • The remediation procedure
11. All rights reserved CIS Benchmarks These recommendations are sorted in profiles (Server or Workstation, and Level 1, 2 or 3 typically, with increasing security)
12. All rights reserved What is a typical CIS benchmark?
13. All rights reserved What is a typical CIS benchmark?
14. All rights reserved What is a typical CIS benchmark?
15. All rights reserved How actionnable is a typical CIS benchmark? Some sections are optional, but at least one of them is necessary In Ubuntu 20 CIS 3.4.1 Configure UncomplicatedFirewall 3.4.2 Configure nftables 3.4.3 Configure iptables
16. All rights reserved How actionnable is a typical CIS benchmark? Often, the audit procedure is clear
17. All rights reserved How actionnable is a typical CIS benchmark? Most of the time, the audit procedure is actionable 3.2.4 Ensure sctp kernel module is not available (Automated)
18. All rights reserved How actionnable is a typical CIS benchmark? Sometimes, you feel on your own 2.2.22 Ensure only approved services are listening on a network interface
19. All rights reserved How actionnable is a typical CIS benchmark? The remediation is sometimes straightforward 2.3.5 Ensure tftp client is not installed
20. All rights reserved How actionnable is a typical CIS benchmark? The remediation might be tricky, with a magical script 4.2.3 Ensure permissions on SSH public host key files are configured
21. All rights reserved How actionnable is a typical CIS benchmark? 4.4.2.5 Ensure pam_unix module is enabled How is it remediating anything ???
22. All rights reserved Standardisation These benchmarks are standards So we have a common language and the identifiers to reconcile information
23. All rights reserved Standardisation These benchmarks are standards So we have a common language and the identifiers to reconcile information BUT the identifiers are not always consistent across different CIS benchmarks
24. All rights reserved Standardisation These benchmarks are standards So we have a common language and the identifiers to reconcile information BUT the identifiers are not consistent across benchmarks
25. All rights reserved Standardisation Id RHEL 8 Ubuntu 20 Debian 10 1.1.2.3 Configure /home Ensure noexec option set on /tmp partition Ensure noexec option set on /tmp partition 1.5.1 Configure SELinux Ensure prelink is not installed Ensure address space layout randomization (ASLR) is enabled 4.2.10 Ensure sshd IgnoreRhosts is enabled Ensure SSH PermitUserEnvironm ent is disabled Ensure SSH PermitUserEnvironm ent is disabled
26. Show me the code CIS!
27. All rights reserved Existing Implementations Many CIS benchmarks implementation • Ad-hoc from PDF/Excel from CIS • Elastic https://www.elastic.co/guide/en/security/current/benchmark-rules.html • Ansible https://github.com/ansible-lockdown/RHEL8-CIS • OpenSCAP https://www.open-scap.org/security-policies/choosing-policy/ • Puppet https://www.puppet.com/docs/comply/2.x/supported-benchmarks.html
28. All rights reserved Existing Implementations Many CIS benchmarks implementation They are really useful Some are only in audit mode, other only remediate, some are customizable Why should we create a new implementation?
29. All rights reserved CIS in Rudder Why should we create a new implementation? Why not using existing implementation and making them available through Rudder?
30. All rights reserved CIS in Rudder Why should we create a new implementation? Why not using existing implementation and making them available through Rudder? There is an OpenSCAP plugin in Rudder, that automates execution and centralization of information. Data is there, but not easily usable/parsable
31. All rights reserved CIS in Rudder Compliance needs to be explorable, parsable, over nodes or groups. Having global overviews in the Web UI, sorting and filtering let user focus on what is good and what needs remediation Exporting via API, grouped by systems, rules permits interconnection with other tools and teams
32. All rights reserved How did we implement CIS? Goal: • Have a relevant implementation • Based on real-world usage • Bring value to users -> First implementation was with a Customer A direct translation of their custom CIS benchmark bash script within Rudder
33. All rights reserved How did we implement CIS? Direct translation of the script within a Configuration
34. All rights reserved How did we implement CIS? Benefits for the Customer • Visibility on its compliance to CIS • Expose information to the stakeholders • Fixed some bugs • Improved global security
35. All rights reserved How did we implement CIS?
36. All rights reserved First implementation - validated Our first implementation was a success. But…
37. All rights reserved First implementation - validated Our first implementation was a success. But… It was not reusable, didn’t have parameters, and was fitted to the Customer’s infrastructure
38. Show me the code CIS! Please, the code Directives!
39. All rights reserved How did we implement CIS (bis)? Goal: • Have a relevant implementation • Based on real-world usage • Factorized • Bring value to users • Customizable
40. All rights reserved How did we implement CIS (bis)? We needed to make it parameterizable. Rudder offers a separation between code (Technique) and parameterized code (Directive) So we implemented the technical part in Techniques, and the know how in Directives We tried to factorize a much code as possible
41. All rights reserved How did we implement CIS (bis)? Techniques
42. All rights reserved How did we implement CIS (bis)? Directives
43. All rights reserved How did we implement CIS (bis)? Directives
44. All rights reserved How did we implement CIS (bis)? It kinda worked It’s been used by users
45. All rights reserved How did we implement CIS (bis)? BUT it’s messy: one directive per control point is about 300 directives to manage And a lot of custom groups to define on which systems control points would apply in audit or enforce mode
46. All rights reserved How did we implement CIS (bis)? Control points are grouped by type and not per section As a result, compliance is hard to comprehend Benchmarks correct application is hard to trace We needed to do better
47. Show me the code YAML!
48. All rights reserved Maintenance issue Clicking one’s way through a graphical editor to create 300 control points is not really feasible Maintaining 300 control points through a web interface is even worse Techniques can be exported/imported in JSON, but that’s hardly better
49. All rights reserved Solution YAML ! In Rudder 8.0, we introduced a YAML DSL for our Techniques • Technique Editor uses this DSL • Can be easily edited by human or tools
50. All rights reserved Solution YAML structure, with; • metadata to describe the technique, • parameters for the technique, • hierarchical structure with items, being either ◦ Blocks to structure data ◦ Generic method to actually do something
51. All rights reserved YAML! id: cis___4_4___configure_pam___audit name: CIS - 4.4 - Configure PAM - Audit version: '1.0' description: Configure PAM following CIS Server 1 benchmark documentation: |- ### CIS Benchmark section 4.4 This Technique is to audit CIS benchmark section 4.4 * Check that password creation requirements are configured (min length for password) * Check that lockout for failed password category: ncf_techniques
52. All rights reserved YAML! items: - name: 4.4 - Configure PAM reporting: mode: weighted items: - name: 4.4.1 - Ensure password creation requirements are configured condition: cis_audit_4_4_1 items: - name: Ensure libpam-pwquality or libpwquality is present items: - name: Ensure libpwquality is installed condition: redhat method: package_present params: name: libpwquality - name: Ensure libpam-pwquality is installed condition: (debian|ubuntu) method: package_present params: name: libpam-pwquality - name: Ensure password minimal length is set to 14 method: file_key_value_present params: path: /etc/security/pwquality.conf key: minlen value: '14' separator: ‘ ‘ - name: 4.4.2 - Ensure lockout for failed password attempts is configured reporting: mode: weighted condition: cis_audit_4_4_2 items: - name: Ensure maximum failed login attempts before lock method: audit_from_command params: command: grep -P '^\h*auth\h+required\h+pam_tally2\.so.*\h+deny=[1|2|3|4|5](\h+|$).*' /etc/pam.d/common-auth compliant_codes: '0'
53. All rights reserved YAML!
54. All rights reserved YAML The new benchmarks were written along with the YAML DSL inception A whole CIS benchmark was written with YAML technique to ensure the DSL powerful enough
55. All rights reserved YAML One limit: we didn’t have a way in Rudder to have mixed audit/enforce mode in Technique, so there are 2 techniques, one for audit and one for enforce This limit is lifted within upcoming Rudder 8.1
56. All rights reserved Benefits of YAML for CIS We can grep/sed/edit it easily, so maintenance is easier for newer benchmarks versions The YAML backbone is created from an XLS export, with section name and all details We “simply” need to fill the blanks
57. All rights reserved How it works Methods are enabled by conditions for each section, using the format cis_distribution_[audit|enforce]_section cis_ubuntu20_enforce_1_1_3_2 Defines if a control is audited, enforced, or ignored
58. All rights reserved How it works Conditions are generated automatically based on hierarchical JSON properties • Global properties: for the whole infrastructure • Group properties: for a group of systems • Node properties: for a specific node
59. All rights reserved How it works Technique parameters to define values: • Based on CIS benchmarks parameters • With defaults
60. All rights reserved How it works Filtering on reports to show/hide only some report types
61. All rights reserved How it works Strategy: • Enable audit components • Detect non-compliance • Remediate (either automatically or manually) • Enable enforce components
62. Demo! At last
63. All rights reserved YAML - Tooling We built rudderc with this language: • Compiler, to check validity of code • Unit testing, with initial state condition • Import/export through git and API
64. All rights reserved YAML is not enough While writing benchmarks in YAML, we realize it was too cumbersome: • A lot of content is repetitive • Separate code for audit and enforce is the best recipe for failure • There are 5 profiles, maintaining them separately is too much effort • It is verbose
65. All rights reserved kcl-lang https://github.com/kcl-lang
66. All rights reserved kcl-lang _4_4_1 = cis.BlockCall { _item_nb = "4.4.1" _title = "Ensure password creation requirements are configured" _wk_lvl = 1 _srv_lvl = 1 _items = [ rudder.Method { name = "Ensure libpam-pwquality is installed" method = "package_present" params = {name = "libpam-pwquality"} } rudder.Method { name = "Ensure password minimal length is set to 14" method = "file_key_value_present" params = { path = "/etc/security/pwquality.conf" key = "minlen" value = "14" separator = r" " } } rudder.Method { name = "Ensure password minimal complexity is set to 4" method = "file_key_value_present" params = { path = "/etc/security/pwquality.conf" key = "minclass" value = "4" separator = r" " } } rudder.Method { name = "Ensure password quality is enabled" method = "audit_from_command" params = { command = r"grep -P '^\h*password\h+[^#\n\r]+\h+pam_pwquality\.so\b' /etc/pam.d/common-password" compliant_codes = "0" } tags = {enforce_supported = False} } ]
67. All rights reserved kcl-lang Benchmarks in kcl: • Written by sections • Compile into full YAML techniques • 1 per profile, 1 per audit/enforce • Auto-generation of errors reports for non-supported parts (no existing automated remediation) One point of knowledge compile to 10 techniques
68. All rights reserved Feedbacks The good: • Maintenance is fairly easy • One source of knowledge for all profiles in one benchmark • (Non) Compliance is really understandable • Benchmarks are customizable by users • Exceptions can be set
69. All rights reserved Feedbacks The bad: • A lot of properties to define to describe the state • Some remediations can’t be automated • We can’t document the reason of exceptions within Rudder yet
70. All rights reserved Feedbacks The ugly: • The definitions are sometimes not translatable correctly in automated control points • Benchmarks aren’t consistent between OSes, so we need one benchmark per OS
71. Questions?
72. All rights reserved What’s next? Multi-tenant approach in Rudder • Users can see only their own system • The security team deploy the benchmark in audit everywhere • Each user responsible can see the non compliance for their own system and remediate it themselves
73. All rights reserved What’s next? Extra informations in the benchmarks • Expose the rationale and description of each points • Document the reason for exceptions