Claroty CTD 5.x oval:ssg-installed_app_is_ctd4:def:1 draft Guide to the Secure Configuration of Claroty CTD 5.x This DRAFT United States Government Configuration Baseline for Claroty CTD 5.x represents a whole of government baseline to support cybersecurity hardening of Claroty CTD 5.x. Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. This baseline is under active development and should be considered a DRAFT for non-production usage. Content authored by Mission IT (https://www.missionit.com) in partnership with Claroty Government (https://www.claroty.com) This baseline is developed by Mission IT (https://missionit.com) in collaboration with Claroty Government (https://www.claroty.com). Baseline questions can be directed to checklists@missionit.com. anssi app-srg app-srg-ctr bsi cis cis-csc cjis cobit5 cui dcid disa hipaa isa-62443-2009 isa-62443-2013 ism iso27001-2013 nerc-cip nist nist-csf os-srg ospp pcidss pcidss4 stigid stigref 0.1.81 SCAP Security Guide Project SCAP Security Guide Project Frank J Cameron (CAM1244) <cameron@ctc.com> 0x66656c6978 <0x66656c6978@users.noreply.github.com> Håvard F. Aasen <havard.f.aasen@pfft.no> Armando Acosta <armando.acosta@oracle.com> Jack Adolph <jack.adolph@gmail.com> Edgar Aguilar <edgar.aguilar@oracle.com> akuster <akuster808@gmail.com> Gabe Alford <redhatrises@gmail.com> Firas AlShafei <firas.alshafei@us.abb.com> Rodrigo Alvares <ralvares@redhat.com> am-tux <andrew.miller11@gmail.com> Christopher Anderson <cba@fedoraproject.org> Craig Andrews <candrews@integralblue.com> angystardust <angystardust@users.noreply.github.com> anivan-suse <anastasija.ivanovic@suse.com> anixon-rh <55244503+anixon-rh@users.noreply.github.com> Anna-Koudelkova <akoudelk@redhat.com> Arden97 <arden2545@gmail.com> Steve Arnold <sarnold@vctlabs.com> Ikko Ashimine <eltociear@gmail.com> Chuck Atkins <chuck.atkins@kitware.com> axuan <axuan@redhat.com> Bharath B <bhb@redhat.com> Ryan Ballanger <root@rballang-admin-2.fastenal.com> Alex Baranowski <alex@euro-linux.com> Eduardo Barretto <eduardo.barretto@canonical.com> Paul Bastide <pbastide@us.ibm.com> Molly Jo Bault <Molly.Jo.Bault@ballardtech.com> Andrew Becker <A-Beck@users.noreply.github.com> Gabriel Becker <ggasparb@redhat.com> BenGui <benoit.guillon1@etu.unilim.fr> Alexander Bergmann <abergmann@suse.com> Eric Berry <eric@approvedworkman.com> Dale Bewley <dale@bewley.net> Jose Luis BG <bgjoseluis@gmail.com> binyanling <binyanling@uniontech.com> Joseph Bisch <joseph.bisch@gmail.com> Jeff Blank <blank@eclipse.ncsc.mil> Olivier Bonhomme <ptitoliv@ptitoliv.net> bontreger <bontreger@users.noreply.github.com> Lance Bragstad <lbragstad@gmail.com> Ted Brunell <tbrunell@redhat.com> Marcus Burghardt <maburgha@redhat.com> Matthew Burket <mburket@redhat.com> Blake Burkhart <blake.burkhart@us.af.mil> Patrick Callahan <pmc@patrickcallahan.com> George Campbell <gcampbell@palantir.com> Nick Carboni <ncarboni@redhat.com> Carlos <64919342+carlosmmatos@users.noreply.github.com> James Cassell <james.cassell@ll.mit.edu> Frank Caviggia <fcaviggia@users.noreply.github.com> Sinong Chen <costinchen@tencent.com> Eric Christensen <echriste@redhat.com> Dan Clark <danclark@redhat.com> Jayson Cofell <1051437+70k10@users.noreply.github.com> David du Colombier <djc@datadoghq.com> Commandcracker <lukas.fricke.dev@gmail.com> Caleb Cooper <coopercd@ornl.gov> CoreyCook8 <129206271+CoreyCook8@users.noreply.github.com> cortesana <acortes@redhat.com> Richard Maciel Costa <richard.maciel.costa@canonical.com> Xavier Coulon <xavier.coulon@suse.com> Deric Crago <deric.crago@gmail.com> crleekwc <crleekwc@gmail.com> cueball23 <christoph.alms@westnetz.de> cyarbrough76 <42849651+cyarbrough76@users.noreply.github.com> Maura Dailey <maura@eclipse.ncsc.mil> Benjamin Deering <ben_deering@jeepingben.net> Shane Dell <shanedell100@gmail.com> Klaas Demter <demter@atix.de> denknorr <dennis.knorr@suse.com> dhanushkar-wso2 <dhanushkar@wso2.com> Andrew DiPrinzio <andrew.diprinzio@jhuapl.edu> dom <dominique.blaze@devinci.fr> Jean-Baptiste Donnette <jean-baptiste.donnette@epita.fr> Marco De Donno <mdedonno1337@gmail.com> dperrone <dperrone@redhat.com> drax <applezip@gmail.com> Qingmin Duanmu <qduanmu@redhat.com> Sebastian Dunne <sdunne@redhat.com> François Duthilleul <francoisduthilleul@gmail.com> Greg Elin <gregelin@gitmachines.com> eradot4027 <jrtonmac@gmail.com> ericeberry <ericeberry@gmail.com> ermeratos <manuel.ermer@eviden.net> Evelyn <evansvevelyn@gmail.com> Alexis Facques <alexis.facques@mythalesgroup.io> Jan Fader <jan.fader@web.de> felixmarch <felixmarch@users.noreply.github.com> Asser Schrøder Femø <asser@asser.org> Henry Finucane <hfinucane@zscaler.com> Leah Fisher <lfisher047@gmail.com> Marco Fortina <marco_fortina@hotmail.it> Yavor Georgiev <strandjata@gmail.com> Alijohn Ghassemlouei <alijohn@secureagc.com> Swarup Ghosh <swghosh@redhat.com> ghylock <ghylock@gmail.com> Andrew Gilmore <agilmore2@gmail.com> Joshua Glemza <jglemza@nasa.gov> Nick Gompper <forestgomp@yahoo.com> David Fernandez Gonzalez <david.fernandezgonzalez@canonical.com> Loren Gordon <lorengordon@users.noreply.github.com> Gene Gotimer <otherdevopsgene@portinfo.com> Patrik Greco <sikevux@sikevux.se> Steve Grubb <sgrubb@redhat.com> guangyee <gyee@suse.com> Bhargavi Gudi <bgudi@bgudi-thinkpadt14sgen2i.remote.csb> Christian Hagenest <christian.hagenest@suse.com> Marek Haicman <mhaicman@redhat.com> Sun, Haoxiang <haoxiang.sun@intel.com> Vern Hart <vern.hart@canonical.com> Alex Haydock <alex@alexhaydock.co.uk> Rebekah Hayes <rhayes@corp.rivierautilities.com> hazerre <kotadouglas2@gmail.com> Trey Henefield <thenefield@gmail.com> Henning Henkel <henning.henkel@helvetia.ch> hex2a <hex2a@users.noreply.github.com> hipponix <mirco.santori@gmail.com> John Hooks <jhooks@starscream.pa.jhbcomputers.com> Jakub Hrozek <jhrozek@redhat.com> Donald Hunter <donald.hunter@gmail.com> De Huo <De.Huo@windriver.com> Robin Price II <robin@redhat.com> Yasir Imam <yimam@redhat.com> Jiri Jaburek <jjaburek@redhat.com> Keith Jackson <keithkjackson@gmail.com> Marc Jadoul <mgjadoul@laptomatic.auth-o-matic.corp> Jeremiah Jahn <jeremiah@goodinassociates.com> Jakub Jelen <jjelen@redhat.com> Jessicahfy <Jessicahfy@users.noreply.github.com> Stephan Joerrens <Stephan.Joerrens@fiduciagad.de> Simon John <sjohn@tuxcare.com> Hunter Jones <hjones2199@gmail.com> Jono <jono@ubuntu-18.localdomain> julius.ish <julius.ish@zetier.com> justchris1 <justchris1@justchris1.email> Kacper <kacper@kacper.se> Kai Kang <kai.kang@windriver.com> Charles Kernstock <charles.kernstock@ultra-ats.com> Yuli Khodorkovskiy <ykhodorkovskiy@tresys.com> Sherine Khoury <skhoury@redhat.com> Nathan Kinder <nkinder@redhat.com> Lee Kinser <lee.kinser@gmail.com> Evgeny Kolesnikov <ekolesni@redhat.com> Peter 'Pessoft' Kolínek <github@pessoft.com> Luke Kordell <luke.t.kordell@lmco.com> Malte Kraus <malte.kraus@suse.com> Seth Kress <seth.kress@dsainc.com> Felix Krohn <felix.krohn@helvetia.ch> kspargur <kspargur@kspargur.csb> Amit Kumar <amitkuma@redhat.com> Fen Labalme <fen@civicactions.com> Dexter Le <dexter.le@sap.com> Dimitri John Ledkov <dimitri.ledkov@surgut.co.uk> Ade Lee <alee@redhat.com> Christopher Lee <Crleekwc@gmail.com> Ian Lee <lee1001@llnl.gov> Jarrett Lee <jarrettl@umd.edu> Joseph Lenox <joseph.lenox@collins.com> Stefano Libero <stefano.libero@nozominetworks.com> lichtblaugue <guenther.lichtblau@eviden.com> Jan Lieskovsky <jlieskov@redhat.com> Markus Linnala <Markus.Linnala@knowit.fi> Flos Lonicerae <lonicerae@gmail.com> Simon Lukasik <slukasik@redhat.com> Andrew Lukoshko <andrew.lukoshko@gmail.com> Milan Lysonek <mlysonek@redhat.com> Fredrik Lysén <fredrik@pipemore.se> Mackemania <8738793+Mackemania@users.noreply.github.com> Caitlin Macleod <caitelatte@gmail.com> Dmitry Makovey <dmakovey@yahoo.com> Nick Maludy <nmaludy@gmail.com> Lokesh Mandvekar <lsm5@fedoraproject.org> Matus Marhefka <mmarhefk@redhat.com> Jamie Lorwey Martin <jlmartin@redhat.com> Carlos Matos <cmatos@redhat.com> Robert McAllister <rmcallis@redhat.com> Karen McCarron <kmccarro@redhat.com> Michael McConachie <michael@redhat.com> Marcus Meissner <meissner@suse.de> Khary Mendez <kmendez@redhat.com> Rodney Mercer <rmercer@harris.com> Matt Micene <nzwulfin@gmail.com> Brian Millett <bmillett@gmail.com> Takuya Mishina <tmishina@jp.ibm.com> Mixer9 <35545791+Mixer9@users.noreply.github.com> mmosel <mmosel@kde.example.com> Thomas Montague <montague.thomas@gmail.com> Alan Moore <alan.moore@canonical.com> Zbynek Moravec <zmoravec@redhat.com> Kazuo Moriwaka <moriwaka@users.noreply.github.com> Michael Moseley <michael@eclipse.ncsc.mil> Nathan Moyer <nmoyer@spectric.com> Ross Murphy <RossMurphy@ibm.com> Renaud Métrich <rmetrich@redhat.com> Joe Nall <joe@nall.com> namoyer10 <48189779+namoyer10@users.noreply.github.com> Neiloy <neiloy@redhat.com> Axel Nennker <axel@nennker.de> Michele Newman <mnewman@redhat.com> nnerdmann <128606223+nnerdmann@users.noreply.github.com> Sean O'Keeffe <seanokeeffe797@gmail.com> Jiri Odehnal <jodehnal@redhat.com> Ilya Okomin <ilya.okomin@oracle.com> Kaustubh Padegaonkar <theTuxRacer@gmail.com> Michael Palmiotto <mpalmiotto@tresys.com> Eryx Paredes <eryxp@lyft.com> Max R.D. Parmer <maxp@trystero.is> Arnaud Patard <apatard@hupstream.com> Jan Pazdziora <jpazdziora@redhat.com> pcactr <paul.c.arnold4.ctr@mail.mil> Kenneth Peeples <kennethwpeeples@gmail.com> Nathan Peters <Nathaniel.Peters@ca.com> Frank Lin PIAT <fpiat@klabs.be> Stefan Pietsch <mail.ipv4v6+gh@gmail.com> piggyvenus <piggyvenus@gmail.com> Vojtech Polasek <vpolasek@redhat.com> Orion Poplawski <orion@nwra.com> Jennifer Power <barnabei.jennifer@gmail.com> Nick Poyant <npoyant@redhat.com> Martin Preisler <mpreisle@redhat.com> Wesley Ceraso Prudencio <wcerasop@redhat.com> Raphael Sanchez Prudencio <rsprudencio@redhat.com> Miha Purg <miha.purg@canonical.com> T.O. Radzy Radzykewycz <radzy@windriver.com> rain-Qing <yangyuqing6@qq.com> Kenyon Ralph <kenyon@kenyonralph.com> Mike Ralph <mralph@redhat.com> Federico Ramirez <federico.r.ramirez@oracle.com> rchikov <rumen.chikov@suse.com> Rick Renshaw <Richard_Renshaw@xtoenergy.com> Paul Rensing <prensing@cimetrics.com> Chris Reynolds <c.reynolds82@gmail.com> rhayes <rhayes@rivierautilities.com> Pat Riehecky <riehecky@fnal.gov> rlucente-se-jboss <rlucente@redhat.com> Juan Antonio Osorio Robles <juan.osoriorobles@eu.equinix.com> Paul Roche <paul.roche@menlosecurity.com> Jan Rodak <hony.com@seznam.cz> Matt Rogers <mrogers@redhat.com> Jesse Roland <jesse.roland@onyxpoint.com> Joshua Roys <roysjosh@gmail.com> rrenshaw <bofh69@yahoo.com> Daniel Ruf <daniel@daniel-ruf.de> Chris Ruffalo <chris.ruffalo@gmail.com> Benjamin Ruland <benjamin.ruland@gmail.com> rumch-se <77793453+rumch-se@users.noreply.github.com> Rutvik <rutksh@gmail.com> Ray Shaw (Cont ARL/CISD) rvshaw <rvshaw@esme.arl.army.mil> Nicolas SAID <nicolas.said@atos.net> Earl Sampson <ESampson@suse.com> sampsone <esampson@suse.com> Mirco Santori <mirco.santori@roche.com> Willy Santos <wsantos@redhat.com> Nagarjuna Sarvepalli <snagarju@redhat.com> Anderson Sasaki <33833274+ansasaki@users.noreply.github.com> Gautam Satish <gautams@hpe.com> Watson Sato <wsato@redhat.com> Satoru SATOH <satoru.satoh@gmail.com> Alexander Scheel <alexander.m.scheel@gmail.com> Bryan Schneiders <pschneiders@trisept.com> Robert Schweikert <rjschwei@suse.com> shaneboulden <shane.boulden@gmail.com> Vincent Shen <wenshen@redhat.com> Dhriti Shikhar <dhriti.shikhar.rokz@gmail.com> Spencer Shimko <sshimko@tresys.com> Mark Shoger <mshoger@redhat.com> Shane Siebken <shane.siebken@capellaspace.com> THOBY Simon <Simon.THOBY@viveris.fr> Thomas Sjögren <konstruktoid@users.noreply.github.com> Jindrich Skacel <102800748+jskacel@users.noreply.github.com> Alexandre Skrzyniarz <alexandre.skrzyniarz@laposte.net> Francisco Slavin <fslavin@tresys.com> sluetze <13255307+sluetze@users.noreply.github.com> Dave Smith <dsmith@eclipse.ncsc.mil> David Smith <dsmith@fornax.eclipse.ncsc.mil> Kevin Spargur <kspargur@redhat.com> Kenneth Stailey <kstailey.lists@gmail.com> Leland Steinke <leland.j.steinke.ctr@mail.mil> Justin Stephenson <jstephen@redhat.com> steven.y.gui <steven_ygui@163.com> Brian Stinson <brian@bstinson.com> Jake Stookey <jakestookey@gmail.com> Nathan Strahs <135379779+nathanstrahs@users.noreply.github.com> Jonathan Sturges <jsturges@redhat.com> svet-se <svetlin.boychev@suse.com> Kaushik Talathi <kaushik.talathi1@ibm.com> teacup-on-rockingchair <315160+teacup-on-rockingchair@users.noreply.github.com> Ian Tewksbury <itewk@redhat.com> Philippe Thierry <phil@reseau-libre.net> Simon THOBY <git@nightmared.fr> Derek Thurston <thegrit@gmail.com> tianzhenjia <jiatianzhen@cmss.chinamobile.com> Greg Tinsley <gtinsley@redhat.com> Paul Tittle <ptittle@cmf.nrl.navy.mil> tom <tom@localhost.localdomain> tomas.hudik <tomas.hudik@embedit.cz> Jeb Trayer <jeb.d.trayer@uscg.mil> TrilokGeer <tgeer@redhat.com> Viktors Trubovics <viktors.trubovics@suse.com> Nico Truzzolino <nico.truzzolino@gmx.de> Brian Turek <brian.turek@gmail.com> Matěj Týč <matyc@redhat.com> Jörgen Uhr <jorgen.uhr@sitevision.se> VadimDor <29509093+VadimDor@users.noreply.github.com> Trevor Vaughan <tvaughan@onyxpoint.com> vtrubovics <82443408+vtrubovics@users.noreply.github.com> Sophia Wang <huiwang@redhat.com> Samuel Warren <swarren@redhat.com> wcushen <54533890+wcushen@users.noreply.github.com> Shawn Wells <shawn@redhat.com> Whidix <31294015+Whidix@users.noreply.github.com> Daniel E. White <linuxdan@users.noreply.github.com> Bernhard M. Wiedemann <bwiedemann@suse.de> Roy Williams <roywilli@roywilli.redhat.com> Willumpie <willumpie@xs4all.nl> Rob Wilmoth <rwilmoth@redhat.com> win97pro <win97pro@protonmail.com> xcfxr <xucee@qq.com> Lucas Yamanishi <lucas.yamanishi@onyxpoint.com> Xirui Yang <xirui.yang@oracle.com> Yuqing Yang <yyq01323329@alibaba-inc.com> yarunachalam <yarunachalam@suse.com> Guang Yee <guang.yee@suse.com> Achilleas John Yfantis <ayfantis@redhat.com> YiLin.Li <YiLin.Li@linux.alibaba.com> yu410621 <lihuanyu410621@gmail.com> Xiaojie Yuan <xiyuan@redhat.com> yungcero <133906218+yungcero@users.noreply.github.com> yunimoo <yunimoo@nekocake.cafe> YuQing <yyq0391@163.com> zhaoyun <zhaoyun@kylinos.cn> Kevin Zimmerman <kevin.zimmerman@kitware.com> Luigi Mario Zuccarelli <luzuccar@redhat.com> Jan Černý <jcerny@redhat.com> Michal Šrubař <msrubar@redhat.com> https://github.com/ComplianceAsCode/content/releases/latest United States Government Configuration Baseline for Claroty CTD 5.x This DRAFT United States Government Configuration Baseline for Claroty CTD 5.x represents a whole of government baseline to support cybersecurity hardening of Claroty CTD 5.x. System Settings Contains rules that check correct system settings. Installing and Maintaining Software The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates. System and Software Integrity System and software integrity can be gained by installing antivirus, increasing system encryption strength with FIPS, verifying installed software, enabling SELinux, installing an Intrusion Prevention System, etc. However, installing or enabling integrity checking tools cannot prevent intrusions, but they can detect that an intrusion may have occurred. Requirements for integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates. Software Integrity Checking Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes. The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system. Verify Integrity with AIDE AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database is created immediately after initial system configuration, and then again after any software update. AIDE is highly configurable, with further configuration information located in /usr/share/doc/aide-VERSION . Install AIDE The aide package can be installed with the following command: $ apt-get install aide 1 11 12 13 14 15 16 2 3 5 7 8 9 5.10.1.3 APO01.06 BAI01.06 BAI02.01 BAI03.05 BAI06.01 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS01.03 DSS03.05 DSS04.07 DSS05.02 DSS05.03 DSS05.05 DSS05.07 DSS06.02 DSS06.06 4.3.4.3.2 4.3.4.3.3 4.3.4.4.4 SR 3.1 SR 3.3 SR 3.4 SR 3.8 SR 4.1 SR 6.2 SR 7.6 A.11.2.4 A.12.1.2 A.12.2.1 A.12.4.1 A.12.5.1 A.12.6.2 A.14.1.2 A.14.1.3 A.14.2.2 A.14.2.3 A.14.2.4 A.14.2.7 A.15.2.1 A.8.2.3 CM-6(a) DE.CM-1 DE.CM-7 PR.DS-1 PR.DS-6 PR.DS-8 PR.IP-1 PR.IP-3 Req-11.5 SRG-OS-000445-GPOS-00199 R76 R79 1034 1288 1341 1417 11.5.2 The AIDE package must be installed if it is to be available for integrity checking. Build and Test AIDE Database Run the following command to generate a new database: $ sudo /usr/bin/aide --init By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/bin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows: $ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz To initiate a manual check, run the following command: $ sudo /usr/bin/aide --check If this check produces any unexpected output, investigate. In RHEL Image Mode (bootc) systems, the AIDE database must be regenerated after each system update. Image Mode systems receive updates through new container images that may include modified files. After applying system updates, run the following commands to regenerate the AIDE database: $ sudo /usr/bin/aide --init Then replace the existing database: $ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz Failure to regenerate the AIDE database after updates will result in false positive alerts for legitimate system changes introduced by the update process. 1 11 12 13 14 15 16 2 3 5 7 8 9 5.10.1.3 APO01.06 BAI01.06 BAI02.01 BAI03.05 BAI06.01 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS01.03 DSS03.05 DSS04.07 DSS05.02 DSS05.03 DSS05.05 DSS05.07 DSS06.02 DSS06.06 4.3.4.3.2 4.3.4.3.3 4.3.4.4.4 SR 3.1 SR 3.3 SR 3.4 SR 3.8 SR 4.1 SR 6.2 SR 7.6 A.11.2.4 A.12.1.2 A.12.2.1 A.12.4.1 A.12.5.1 A.12.6.2 A.14.1.2 A.14.1.3 A.14.2.2 A.14.2.3 A.14.2.4 A.14.2.7 A.15.2.1 A.8.2.3 CM-6(a) DE.CM-1 DE.CM-7 PR.DS-1 PR.DS-6 PR.DS-8 PR.IP-1 PR.IP-3 Req-11.5 SRG-OS-000445-GPOS-00199 R76 R79 11.5.2 For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files. Configure AIDE to Verify the Audit Tools The operating system file integrity tool must be configured to protect the integrity of the audit tools. AU-9(3) AU-9(3).1 SRG-OS-000278-GPOS-00108 Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include but are not limited to vendor-provided and open-source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools to provide the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files. Configure AIDE To Notify Personnel if Baseline Configurations Are Altered The operating system file integrity tool must be configured to notify designated personnel of any changes to configurations. SRG-OS-000447-GPOS-00201 SRG-OS-000363-GPOS-00150 Detecting changes in the system can help avoid unintended, and negative consequences that could affect the security state of the operating system Configure Periodic Execution of AIDE At a minimum, AIDE should be configured to run a weekly scan. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 05 4 * * * root /usr/bin/aide --check To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 05 4 * * 0 root /usr/bin/aide --check AIDE can be executed periodically through other means; this is merely one example. The usage of cron's special time codes, such as @daily and @weekly is acceptable. 1 11 12 13 14 15 16 2 3 5 7 8 9 5.10.1.3 APO01.06 BAI01.06 BAI02.01 BAI03.05 BAI06.01 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS01.03 DSS03.05 DSS04.07 DSS05.02 DSS05.03 DSS05.05 DSS05.07 DSS06.02 DSS06.06 4.3.4.3.2 4.3.4.3.3 4.3.4.4.4 SR 3.1 SR 3.3 SR 3.4 SR 3.8 SR 4.1 SR 6.2 SR 7.6 A.11.2.4 A.12.1.2 A.12.2.1 A.12.4.1 A.12.5.1 A.12.6.2 A.14.1.2 A.14.1.3 A.14.2.2 A.14.2.3 A.14.2.4 A.14.2.7 A.15.2.1 A.8.2.3 SI-7 SI-7(1) CM-6(a) DE.CM-1 DE.CM-7 PR.DS-1 PR.DS-6 PR.DS-8 PR.IP-1 PR.IP-3 Req-11.5 SRG-OS-000363-GPOS-00150 SRG-OS-000446-GPOS-00200 SRG-OS-000447-GPOS-00201 R76 11.5.2 By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files. Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security. Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system's Information Management Officer (IMO)/Information System Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item. Federal Information Processing Standard (FIPS) The Federal Information Processing Standard (FIPS) is a computer security standard which is developed by the U.S. Government and industry working groups to validate the quality of cryptographic modules. The FIPS standard provides four security levels to ensure adequate coverage of different industries, implementation of cryptographic modules, and organizational sizes and requirements. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets industry and government requirements. For government systems, this allows Security Levels 1, 2, 3, or 4 for use on Claroty CTD 5.x. See http://csrc.nist.gov/publications/PubsFIPS.html for more information. Verify '/proc/sys/crypto/fips_enabled' exists On a system where FIPS 140-2 mode is enabled, /proc/sys/crypto/fips_enabled must exist. To verify FIPS mode, run the following command: cat /proc/sys/crypto/fips_enabled To configure the OS to run in FIPS 140-2 mode, the kernel parameter "fips=1" needs to be added during its installation. Enabling FIPS mode on a preexisting system involves a number of modifications to it. Refer to the vendor installation guidances. System Crypto Modules must be provided by a vendor that undergoes FIPS-140 certifications. FIPS-140 is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf To meet this, the system has to have cryptographic software provided by a vendor that has undergone this certification. This means providing documentation, test results, design information, and independent third party review by an accredited lab. While open source software is capable of meeting this, it does not meet FIPS-140 unless the vendor submits to this process. SC-12(2) SC-12(3) SC-13 SRG-OS-000396-GPOS-00176 SRG-OS-000478-GPOS-00223 Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. Operating System Vendor Support and Certification The assurance of a vendor to provide operating system support and maintenance for their product is an important criterion to ensure product stability and security over the life of the product. A certified product that follows the necessary standards and government certification requirements guarantees that known software vulnerabilities will be remediated, and proper guidance for protecting and securing the operating system will be given. The Installed Operating System Is Vendor Supported The installed operating system must be maintained by a vendor. Red Hat Enterprise Linux is supported by Red Hat, Inc. As the Red Hat Enterprise Linux vendor, Red Hat, Inc. is responsible for providing security patches. There is no remediation besides switching to a different operating system. 18 20 4 APO12.01 APO12.02 APO12.03 APO12.04 BAI03.10 DSS05.01 DSS05.02 4.2.3 4.2.3.12 4.2.3.7 4.2.3.9 A.12.6.1 A.14.2.3 A.16.1.3 A.18.2.2 A.18.2.3 CM-6(a) MA-6 SA-13(a) ID.RA-1 PR.IP-12 SRG-OS-000480-GPOS-00227 An operating system is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve any security issue discovered in the system software. Disk Partitioning To ensure separation and protection of data, there are top-level system directories which should be placed on their own physical partition or logical volume. The installer's default partitioning scheme creates separate logical volumes for /, /boot, and swap. If starting with any of the default layouts, check the box to \"Review and modify partitioning.\" This allows for the easy creation of additional logical volumes inside the volume group already created, though it may require making /'s logical volume smaller to create space. In general, using logical volumes is preferable to using partitions because they can be more easily adjusted later.If creating a custom layout, create the partitions mentioned in the previous paragraph (which the installer will require anyway), as well as separate ones described in the following sections. If a system has already been installed, and the default partitioning scheme was used, it is possible but nontrivial to modify it to create separate logical volumes for the directories listed above. The Logical Volume Manager (LVM) makes this possible. Encrypt Partitions Claroty CTD 5.x natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time. For manual installations, select the Encrypt checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots. For automated/unattended installations, it is possible to use Kickstart by adding the --encrypted and --passphrase= options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition: part / --fstype=ext4 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the --passphrase= option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation. By default, the Anaconda installer uses aes-xts-plain64 cipher with a minimum 512 bit key size which should be compatible with FIPS enabled. Detailed information on encrypting partitions using LUKS or LUKS ciphers can be found on the Claroty CTD 5.x Documentation web site: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening . 13 14 APO01.06 BAI02.01 BAI06.01 DSS04.07 DSS05.03 DSS05.04 DSS05.07 DSS06.02 DSS06.06 3.13.16 164.308(a)(1)(ii)(D) 164.308(b)(1) 164.310(d) 164.312(a)(1) 164.312(a)(2)(iii) 164.312(a)(2)(iv) 164.312(b) 164.312(c) 164.314(b)(2)(i) 164.312(d) SR 3.4 SR 4.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CIP-003-8 R4.2 CIP-007-3 R5.1 CM-6(a) SC-28 SC-28(1) SC-13 AU-9(3) PR.DS-1 PR.DS-5 SRG-OS-000405-GPOS-00184 SRG-OS-000185-GPOS-00079 SRG-OS-000404-GPOS-00183 The risk of a system's physical compromise, particularly mobile systems such as laptops, places its data at risk of compromise. Encrypting this data mitigates the risk of its loss if the system is lost. GNOME Desktop Environment GNOME is a graphical desktop environment bundled with many Linux distributions that allow users to easily interact with the operating system graphically rather than textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user switching contexts as well as display server management. GNOME is developed by the GNOME Project and is considered the default Red Hat Graphical environment. For more information on GNOME and the GNOME Project, see https://www.gnome.org. Configure GNOME Screen Locking In the default GNOME3 desktop, the screen can be locked by selecting the user name in the far right corner of the main panel and selecting Lock. The following sections detail commands to enforce idle activation of the screensaver, screen locking, a blank-screen screensaver, and an idle activation time. Because users should be trained to lock the screen when they step away from the computer, the automatic locking feature is only meant as a backup. The root account can be screen-locked; however, the root account should never be used to log into an X Windows environment and should only be used to for direct login via console in emergency circumstances. For more information about enforcing preferences in the GNOME3 environment using the DConf configuration system, see http://wiki.gnome.org/dconf and the man page dconf(1). Screensaver Inactivity timeout Choose allowed duration (in seconds) of inactive graphical sessions 600 900 1800 300 900 Screensaver Lock Delay Choose allowed duration (in seconds) after a screensaver becomes active before displaying an authentication prompt 10 5 0 0 Set GNOME3 Screensaver Inactivity Timeout The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/gdm.d directory and locked in /etc/dconf/db/gdm.d/locks directory to prevent user modification. For example, to configure the system for a 15 minute delay, add the following to /etc/dconf/db/gdm.d/00-security-settings: [org/gnome/desktop/session] idle-delay=uint32 900 1 12 15 16 5.5.5 DSS05.04 DSS05.10 DSS06.10 3.1.10 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 AC-11(a) CM-6(a) PR.AC-7 Req-8.1.8 SRG-OS-000029-GPOS-00010 SRG-OS-000031-GPOS-00012 8.2.8 8.2 A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME3 can be configured to identify when a user's session has idled and take action to initiate a session lock. Set GNOME3 Screensaver Lock Delay After Activation Period To activate the locking delay of the screensaver in the GNOME3 desktop when the screensaver is activated, add or set lock-delay to uint32 in /etc/dconf/db/gdm.d/00-security-settings. For example: [org/gnome/desktop/screensaver] lock-delay=uint32 After the settings have been set, run dconf update. 1 12 15 16 DSS05.04 DSS05.10 DSS06.10 3.1.10 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 AC-11(a) CM-6(a) PR.AC-7 Req-8.1.8 SRG-OS-000029-GPOS-00010 SRG-OS-000031-GPOS-00012 8.2.8 8.2 A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absence. Enable GNOME3 Screensaver Lock After Idle Period To activate locking of the screensaver in the GNOME3 desktop when it is activated, add or set lock-enabled to true in /etc/dconf/db/gdm.d/00-security-settings. For example: [org/gnome/desktop/screensaver] lock-enabled=true Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: /org/gnome/desktop/screensaver/lock-enabled After the settings have been set, run dconf update. 1 12 15 16 5.5.5 DSS05.04 DSS05.10 DSS06.10 3.1.10 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 CM-6(a) PR.AC-7 Req-8.1.8 SRG-OS-000028-GPOS-00009 SRG-OS-000030-GPOS-00011 8.2.8 8.2 A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absence. GNOME System Settings GNOME provides configuration and functionality to a graphical desktop environment that changes graphical configurations or allow a user to perform actions that users normally would not be able to do in non-graphical mode such as remote access configuration, power policies, Geo-location, etc. Configuring such settings in GNOME will prevent accidental graphical configuration changes by users from taking place. Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3 By default, GNOME will reboot the system if the Ctrl-Alt-Del key sequence is pressed. To configure the system to ignore the Ctrl-Alt-Del key sequence from the Graphical User Interface (GUI) instead of rebooting the system, add or set logout to [''] in /etc/dconf/db/local.d/00-security-settings. For example: [org/gnome/settings-daemon/plugins/media-keys] logout=[''] Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: /org/gnome/settings-daemon/plugins/media-keys/logout After the settings have been set, run dconf update. 12 13 14 15 16 18 3 5 APO01.06 DSS05.04 DSS05.07 DSS06.02 3.1.2 4.3.3.7.3 SR 2.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CM-6(a) AC-6(1) CM-7(b) PR.AC-4 PR.DS-5 SRG-OS-000480-GPOS-00227 A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. Sudo Sudo, which stands for "su 'do'", provides the ability to delegate authority to certain users, groups of users, or system administrators. When configured for system users and/or groups, Sudo can allow a user or group to execute privileged commands that normally only root is allowed to execute. For more information on Sudo and addition Sudo configuration options, see https://www.sudo.ws. Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. 1 12 15 16 5 DSS05.04 DSS05.10 DSS06.03 DSS06.10 4.3.3.5.1 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-11 CM-6(a) PR.AC-1 PR.AC-7 SRG-OS-000373-GPOS-00156 SRG-OS-000373-GPOS-00157 SRG-OS-000373-GPOS-00158 1546 Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical that the user re-authenticate. Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. 1 12 15 16 5 DSS05.04 DSS05.10 DSS06.03 DSS06.10 4.3.3.5.1 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-11 CM-6(a) PR.AC-1 PR.AC-7 SRG-OS-000373-GPOS-00156 SRG-OS-000373-GPOS-00157 SRG-OS-000373-GPOS-00158 1546 Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical that the user re-authenticate. The operating system must restrict privilege elevation to authorized personnel The sudo command allows a user to execute programs with elevated (administrator) privileges. It prompts the user for their password and confirms your request to execute a command by checking a file, called sudoers. Restrict privileged actions by removing the following entries from the sudoers file: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL This rule doesn't come with a remediation, as the exact requirement allows exceptions, and removing lines from the sudoers file can make the system non-administrable. CM-6(b) CM-6(iv) SRG-OS-000480-GPOS-00227 If the "sudoers" file is not configured correctly, any user defined on the system can initiate privileged actions on the target system. Updating Software The apt_get command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update. Claroty CTD 5.x systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Consistently using apt_get or the graphical Software Update for all software installation allows for insight into the current inventory of installed software on the system. Ensure apt_get Removes Previous Package Versions apt_get should be configured to remove previous software components after new versions have been installed. To configure apt_get to remove the previous software components after updating, set the clean_requirements_on_remove to 1 in /etc/apt/apt.conf. 18 20 4 APO12.01 APO12.02 APO12.03 APO12.04 BAI03.10 DSS05.01 DSS05.02 3.4.8 4.2.3 4.2.3.12 4.2.3.7 4.2.3.9 A.12.6.1 A.14.2.3 A.16.1.3 A.18.2.2 A.18.2.3 SI-2(6) CM-11(a) CM-11(b) CM-6(a) ID.RA-1 PR.IP-12 SRG-OS-000437-GPOS-00194 Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by some adversaries. Account and Access Control In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Claroty CTD 5.x. Warning Banners for System Accesses Each system should expose as little information about itself as possible. System banners, which are typically displayed just before a login prompt, give out information about the service or the host's operating system. This might include the distribution name and the system kernel version, and the particular version of a network service. This information can assist intruders in gaining access to the system as it can reveal whether the system is running vulnerable software. Most network services can be configured to limit what information is displayed. Many organizations implement security policies that require a system banner provide notice of the system's ownership, provide warning to unauthorized users, and remind authorized users of their consent to monitoring. Login Banner Verbiage Enter an appropriate login banner text for your organization. This variable is used only in remediations. In OVAL checks a regular expression specified in the login_banner_text variable is used instead. Using a regular expression is needed because some profiles (eg. STIG) allow multiple different banners. Authorized users only. All activity may be monitored and reported. Authorized uses only. All activity may be monitored and reported. You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:\n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.\n-At any time, the USG may inspect and seize data stored on this IS.\n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. I've read & consent to terms in IS user agreem't. Use of this or any other DoD interest computer system constitutes consent to monitoring at all times. This is a DoD interest computer system. All DoD interest computer systems and related equipment are intended for the communication, transmission, processing, and storage of official U.S. Government or other authorized information only. All DoD interest computer systems are subject to monitoring at all times to ensure proper functioning of equipment and systems including security devices and systems, to prevent unauthorized use and violations of statutes and security regulations, to deter criminal activity, and for other similar purposes. Any user of a DoD interest computer system should be aware that any information placed in the system is subject to monitoring and is not subject to any expectation of privacy. If monitoring of this or any other DoD interest computer system reveals possible evidence of violation of criminal statutes, this evidence and any other related information, including identification information about the user, may be provided to law enforcement officials. If monitoring of this or any other DoD interest computer systems reveals violations of security regulations or unauthorized use, employees who violate security regulations or make unauthorized use of DoD interest computer systems are subject to appropriate disciplinary action. Use of this or any other DoD interest computer system constitutes consent to monitoring at all times. -- WARNING -- This system is for the use of authorized users only. Individuals using this computer system without authority or in excess of their authority are subject to having all their activities on this system monitored and recorded by system personnel. Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible evidence of criminal activity system personal may provide the evidence of such monitoring to law enforcement officials. Dconf GDM Login Banner Verbiage Regular Expression Enter an appropriate login banner regular expression for your organization. Using a regular expression is needed because some profiles (eg. STIG) allow multiple different banners. This regular expression is used only in OVAL checks. In remediations the login_banner_contents variable is used instead. For information about how to generate banner regular expression for your tailoring files, see: https://complianceascode.readthedocs.io/en/latest/manual/developer/05_tools_and_utilities.html#generating-login-banner-regular-expressions ^(Authorized[\s\n]+uses[\s\n]+only\.[\s\n]+All[\s\n]+activity[\s\n]+may[\s\n]+be[\s\n]+monitored[\s\n]+and[\s\n]+reported\.|^(?!.*(\\|fedora|rhel|sle|ubuntu)).*)$ ^Authorized[\s\n]+uses[\s\n]+only\.[\s\n]+All[\s\n]+activity[\s\n]+may[\s\n]+be[\s\n]+monitored[\s\n]+and[\s\n]+reported\.$ ^(You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U\.S\.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG\-authorized[\s\n]+use[\s\n]+only\.[\s\n]+By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:(?:[\n]+|(?:\\n)+)\-The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations\.(?:[\n]+|(?:\\n)+)\-At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS\.(?:[\n]+|(?:\\n)+)\-Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG\-authorized[\s\n]+purpose\.(?:[\n]+|(?:\\n)+)\-This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e\.g\.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests\-\-not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy\.(?:[\n]+|(?:\\n)+)\-Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants\.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential\.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details\.|I've[\s\n]+read[\s\n]+\&[\s\n]+consent[\s\n]+to[\s\n]+terms[\s\n]+in[\s\n]+IS[\s\n]+user[\s\n]+agreem't\.)$ ^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U\.S\.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG\-authorized[\s\n]+use[\s\n]+only\.[\s\n]+By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:(?:[\n]+|(?:\\n)+)\-The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations\.(?:[\n]+|(?:\\n)+)\-At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS\.(?:[\n]+|(?:\\n)+)\-Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG\-authorized[\s\n]+purpose\.(?:[\n]+|(?:\\n)+)\-This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e\.g\.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests\-\-not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy\.(?:[\n]+|(?:\\n)+)\-Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants\.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential\.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details\.$ ^I've[\s\n]+read[\s\n]+\&[\s\n]+consent[\s\n]+to[\s\n]+terms[\s\n]+in[\s\n]+IS[\s\n]+user[\s\n]+agreem't\.$ ^Use[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+constitutes[\s\n]+consent[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times\.[\s\n]+This[\s\n]+is[\s\n]+a[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system\.[\s\n]+All[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+and[\s\n]+related[\s\n]+equipment[\s\n]+are[\s\n]+intended[\s\n]+for[\s\n]+the[\s\n]+communication,[\s\n]+transmission,[\s\n]+processing,[\s\n]+and[\s\n]+storage[\s\n]+of[\s\n]+official[\s\n]+U\.S\.[\s\n]+Government[\s\n]+or[\s\n]+other[\s\n]+authorized[\s\n]+information[\s\n]+only\.[\s\n]+All[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times[\s\n]+to[\s\n]+ensure[\s\n]+proper[\s\n]+functioning[\s\n]+of[\s\n]+equipment[\s\n]+and[\s\n]+systems[\s\n]+including[\s\n]+security[\s\n]+devices[\s\n]+and[\s\n]+systems,[\s\n]+to[\s\n]+prevent[\s\n]+unauthorized[\s\n]+use[\s\n]+and[\s\n]+violations[\s\n]+of[\s\n]+statutes[\s\n]+and[\s\n]+security[\s\n]+regulations,[\s\n]+to[\s\n]+deter[\s\n]+criminal[\s\n]+activity,[\s\n]+and[\s\n]+for[\s\n]+other[\s\n]+similar[\s\n]+purposes\.[\s\n]+Any[\s\n]+user[\s\n]+of[\s\n]+a[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+should[\s\n]+be[\s\n]+aware[\s\n]+that[\s\n]+any[\s\n]+information[\s\n]+placed[\s\n]+in[\s\n]+the[\s\n]+system[\s\n]+is[\s\n]+subject[\s\n]+to[\s\n]+monitoring[\s\n]+and[\s\n]+is[\s\n]+not[\s\n]+subject[\s\n]+to[\s\n]+any[\s\n]+expectation[\s\n]+of[\s\n]+privacy\.[\s\n]+If[\s\n]+monitoring[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+reveals[\s\n]+possible[\s\n]+evidence[\s\n]+of[\s\n]+violation[\s\n]+of[\s\n]+criminal[\s\n]+statutes,[\s\n]+this[\s\n]+evidence[\s\n]+and[\s\n]+any[\s\n]+other[\s\n]+related[\s\n]+information,[\s\n]+including[\s\n]+identification[\s\n]+information[\s\n]+about[\s\n]+the[\s\n]+user,[\s\n]+may[\s\n]+be[\s\n]+provided[\s\n]+to[\s\n]+law[\s\n]+enforcement[\s\n]+officials\.[\s\n]+If[\s\n]+monitoring[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+reveals[\s\n]+violations[\s\n]+of[\s\n]+security[\s\n]+regulations[\s\n]+or[\s\n]+unauthorized[\s\n]+use,[\s\n]+employees[\s\n]+who[\s\n]+violate[\s\n]+security[\s\n]+regulations[\s\n]+or[\s\n]+make[\s\n]+unauthorized[\s\n]+use[\s\n]+of[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+appropriate[\s\n]+disciplinary[\s\n]+action\.[\s\n]+Use[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+constitutes[\s\n]+consent[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times\.$ ^\-\-[\s\n]+WARNING[\s\n]+\-\-[\s\n]+This[\s\n]+system[\s\n]+is[\s\n]+for[\s\n]+the[\s\n]+use[\s\n]+of[\s\n]+authorized[\s\n]+users[\s\n]+only\.[\s\n]+Individuals[\s\n]+using[\s\n]+this[\s\n]+computer[\s\n]+system[\s\n]+without[\s\n]+authority[\s\n]+or[\s\n]+in[\s\n]+excess[\s\n]+of[\s\n]+their[\s\n]+authority[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+having[\s\n]+all[\s\n]+their[\s\n]+activities[\s\n]+on[\s\n]+this[\s\n]+system[\s\n]+monitored[\s\n]+and[\s\n]+recorded[\s\n]+by[\s\n]+system[\s\n]+personnel\.[\s\n]+Anyone[\s\n]+using[\s\n]+this[\s\n]+system[\s\n]+expressly[\s\n]+consents[\s\n]+to[\s\n]+such[\s\n]+monitoring[\s\n]+and[\s\n]+is[\s\n]+advised[\s\n]+that[\s\n]+if[\s\n]+such[\s\n]+monitoring[\s\n]+reveals[\s\n]+possible[\s\n]+evidence[\s\n]+of[\s\n]+criminal[\s\n]+activity[\s\n]+system[\s\n]+personal[\s\n]+may[\s\n]+provide[\s\n]+the[\s\n]+evidence[\s\n]+of[\s\n]+such[\s\n]+monitoring[\s\n]+to[\s\n]+law[\s\n]+enforcement[\s\n]+officials\.$ ^Authorized[\s\n]+users[\s\n]+only\.[\s\n]+All[\s\n]+activity[\s\n]+may[\s\n]+be[\s\n]+monitored[\s\n]+and[\s\n]+reported\.$ Remote Login Banner Verbiage Enter an appropriate login banner text for your organization. This variable is used only in remediations. In OVAL checks a regular expression specified in the remote_login_banner_text variable is used instead. Using a regular expression is needed because some profiles (eg. STIG) allow multiple different banners. Authorized users only. All activity may be monitored and reported. Authorized users only. All activity may be monitored and reported. You are accessing a U.S. Government (USG) Information System (IS) that is\nprovided for USG-authorized use only. By using this IS (which includes any\ndevice attached to this IS), you consent to the following conditions:\n\n-The USG routinely intercepts and monitors communications on this IS for\npurposes including, but not limited to, penetration testing, COMSEC monitoring,\nnetwork operations and defense, personnel misconduct (PM), law enforcement\n(LE), and counterintelligence (CI) investigations.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-Communications using, or data stored on, this IS are not private, are subject\nto routine monitoring, interception, and search, and may be disclosed or used\nfor any USG-authorized purpose.\n\n-This IS includes security measures (e.g., authentication and access controls)\nto protect USG interests--not for your personal benefit or privacy.\n\n-Notwithstanding the above, using this IS does not constitute consent to PM, LE\nor CI investigative searching or monitoring of the content of privileged\ncommunications, or work product, related to personal representation or services\nby attorneys, psychotherapists, or clergy, and their assistants. Such\ncommunications and work product are private and confidential. See User\nAgreement for details. I've read & consent to terms in IS user agreem't. Use of this or any other DoD interest computer system constitutes consent to\nmonitoring at all times. This is a DoD interest computer system. All DoD\ninterest computer systems and related equipment are intended for the\ncommunication, transmission, processing, and storage of official U.S.\nGovernment or other authorized information only. All DoD interest computer\nsystems are subject to monitoring at all times to ensure proper functioning of\nequipment and systems including security devices and systems, to prevent\nunauthorized use and violations of statutes and security regulations, to deter\ncriminal activity, and for other similar purposes. Any user of a DoD interest\ncomputer system should be aware that any information placed in the system is\nsubject to monitoring and is not subject to any expectation of privacy. If\nmonitoring of this or any other DoD interest computer system reveals possible\nevidence of violation of criminal statutes, this evidence and any other related\ninformation, including identification information about the user, may be\nprovided to law enforcement officials. If monitoring of this or any other DoD\ninterest computer systems reveals violations of security regulations or\nunauthorized use, employees who violate security regulations or make\nunauthorized use of DoD interest computer systems are subject to appropriate\ndisciplinary action. Use of this or any other DoD interest computer system\nconstitutes consent to monitoring at all times. -- WARNING -- This system is for the use of authorized users only. Individuals\nusing this computer system without authority or in excess of their authority\nare subject to having all their activities on this system monitored and\nrecorded by system personnel. Anyone using this system expressly consents to\nsuch monitoring and is advised that if such monitoring reveals possible\nevidence of criminal activity system personal may provide the evidence of such\nmonitoring to law enforcement officials. Remote Login Banner Verbiage Regular Expression Enter an appropriate login banner regular expression for your organization. Using a regular expression is needed because some profiles (eg. STIG) allow multiple different banners. This regular expression is used only in OVAL checks. In remediations the remote_login_banner_contents variable is used instead. For information about how to generate banner regular expression for your tailoring files, see: https://complianceascode.readthedocs.io/en/latest/manual/developer/05_tools_and_utilities.html#generating-login-banner-regular-expressions ^(Authorized[\s\n]+users[\s\n]+only\.[\s\n]+All[\s\n]+activity[\s\n]+may[\s\n]+be[\s\n]+monitored[\s\n]+and[\s\n]+reported\.|^(?!.*(\\|fedora|rhel|sle|ubuntu)).*)$ ^Authorized[\s\n]+users[\s\n]+only\.[\s\n]+All[\s\n]+activity[\s\n]+may[\s\n]+be[\s\n]+monitored[\s\n]+and[\s\n]+reported\.$ ^(You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U\.S\.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG\-authorized[\s\n]+use[\s\n]+only\.[\s\n]+By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:(?:[\n]+|(?:\\n)+)\-The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations\.(?:[\n]+|(?:\\n)+)\-At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS\.(?:[\n]+|(?:\\n)+)\-Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG\-authorized[\s\n]+purpose\.(?:[\n]+|(?:\\n)+)\-This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e\.g\.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests\-\-not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy\.(?:[\n]+|(?:\\n)+)\-Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants\.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential\.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details\.|I've[\s\n]+read[\s\n]+\&[\s\n]+consent[\s\n]+to[\s\n]+terms[\s\n]+in[\s\n]+IS[\s\n]+user[\s\n]+agreem't\.)$ ^You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U\.S\.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG\-authorized[\s\n]+use[\s\n]+only\.[\s\n]+By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:(?:[\n]+|(?:\\n)+)\-The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations\.(?:[\n]+|(?:\\n)+)\-At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS\.(?:[\n]+|(?:\\n)+)\-Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG\-authorized[\s\n]+purpose\.(?:[\n]+|(?:\\n)+)\-This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e\.g\.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests\-\-not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy\.(?:[\n]+|(?:\\n)+)\-Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants\.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential\.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details\.$ ^I've[\s\n]+read[\s\n]+\&[\s\n]+consent[\s\n]+to[\s\n]+terms[\s\n]+in[\s\n]+IS[\s\n]+user[\s\n]+agreem't\.$ ^Use[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+constitutes[\s\n]+consent[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times\.[\s\n]+This[\s\n]+is[\s\n]+a[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system\.[\s\n]+All[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+and[\s\n]+related[\s\n]+equipment[\s\n]+are[\s\n]+intended[\s\n]+for[\s\n]+the[\s\n]+communication,[\s\n]+transmission,[\s\n]+processing,[\s\n]+and[\s\n]+storage[\s\n]+of[\s\n]+official[\s\n]+U\.S\.[\s\n]+Government[\s\n]+or[\s\n]+other[\s\n]+authorized[\s\n]+information[\s\n]+only\.[\s\n]+All[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times[\s\n]+to[\s\n]+ensure[\s\n]+proper[\s\n]+functioning[\s\n]+of[\s\n]+equipment[\s\n]+and[\s\n]+systems[\s\n]+including[\s\n]+security[\s\n]+devices[\s\n]+and[\s\n]+systems,[\s\n]+to[\s\n]+prevent[\s\n]+unauthorized[\s\n]+use[\s\n]+and[\s\n]+violations[\s\n]+of[\s\n]+statutes[\s\n]+and[\s\n]+security[\s\n]+regulations,[\s\n]+to[\s\n]+deter[\s\n]+criminal[\s\n]+activity,[\s\n]+and[\s\n]+for[\s\n]+other[\s\n]+similar[\s\n]+purposes\.[\s\n]+Any[\s\n]+user[\s\n]+of[\s\n]+a[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+should[\s\n]+be[\s\n]+aware[\s\n]+that[\s\n]+any[\s\n]+information[\s\n]+placed[\s\n]+in[\s\n]+the[\s\n]+system[\s\n]+is[\s\n]+subject[\s\n]+to[\s\n]+monitoring[\s\n]+and[\s\n]+is[\s\n]+not[\s\n]+subject[\s\n]+to[\s\n]+any[\s\n]+expectation[\s\n]+of[\s\n]+privacy\.[\s\n]+If[\s\n]+monitoring[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+reveals[\s\n]+possible[\s\n]+evidence[\s\n]+of[\s\n]+violation[\s\n]+of[\s\n]+criminal[\s\n]+statutes,[\s\n]+this[\s\n]+evidence[\s\n]+and[\s\n]+any[\s\n]+other[\s\n]+related[\s\n]+information,[\s\n]+including[\s\n]+identification[\s\n]+information[\s\n]+about[\s\n]+the[\s\n]+user,[\s\n]+may[\s\n]+be[\s\n]+provided[\s\n]+to[\s\n]+law[\s\n]+enforcement[\s\n]+officials\.[\s\n]+If[\s\n]+monitoring[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+reveals[\s\n]+violations[\s\n]+of[\s\n]+security[\s\n]+regulations[\s\n]+or[\s\n]+unauthorized[\s\n]+use,[\s\n]+employees[\s\n]+who[\s\n]+violate[\s\n]+security[\s\n]+regulations[\s\n]+or[\s\n]+make[\s\n]+unauthorized[\s\n]+use[\s\n]+of[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+systems[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+appropriate[\s\n]+disciplinary[\s\n]+action\.[\s\n]+Use[\s\n]+of[\s\n]+this[\s\n]+or[\s\n]+any[\s\n]+other[\s\n]+DoD[\s\n]+interest[\s\n]+computer[\s\n]+system[\s\n]+constitutes[\s\n]+consent[\s\n]+to[\s\n]+monitoring[\s\n]+at[\s\n]+all[\s\n]+times\.$ ^\-\-[\s\n]+WARNING[\s\n]+\-\-[\s\n]+This[\s\n]+system[\s\n]+is[\s\n]+for[\s\n]+the[\s\n]+use[\s\n]+of[\s\n]+authorized[\s\n]+users[\s\n]+only\.[\s\n]+Individuals[\s\n]+using[\s\n]+this[\s\n]+computer[\s\n]+system[\s\n]+without[\s\n]+authority[\s\n]+or[\s\n]+in[\s\n]+excess[\s\n]+of[\s\n]+their[\s\n]+authority[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+having[\s\n]+all[\s\n]+their[\s\n]+activities[\s\n]+on[\s\n]+this[\s\n]+system[\s\n]+monitored[\s\n]+and[\s\n]+recorded[\s\n]+by[\s\n]+system[\s\n]+personnel\.[\s\n]+Anyone[\s\n]+using[\s\n]+this[\s\n]+system[\s\n]+expressly[\s\n]+consents[\s\n]+to[\s\n]+such[\s\n]+monitoring[\s\n]+and[\s\n]+is[\s\n]+advised[\s\n]+that[\s\n]+if[\s\n]+such[\s\n]+monitoring[\s\n]+reveals[\s\n]+possible[\s\n]+evidence[\s\n]+of[\s\n]+criminal[\s\n]+activity[\s\n]+system[\s\n]+personal[\s\n]+may[\s\n]+provide[\s\n]+the[\s\n]+evidence[\s\n]+of[\s\n]+such[\s\n]+monitoring[\s\n]+to[\s\n]+law[\s\n]+enforcement[\s\n]+officials\.$ ^Authorized[\s\n]+users[\s\n]+only\.[\s\n]+All[\s\n]+activity[\s\n]+may[\s\n]+be[\s\n]+monitored[\s\n]+and[\s\n]+reported\.$ Modify the System Login Banner for Remote Connections To configure the system login banner edit /etc/issue.net. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR: I've read & consent to terms in IS user agreem't. SRG-OS-000023-GPOS-00006 SRG-OS-000228-GPOS-00088 Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. Implement a GUI Warning Banner In the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner. Enable GNOME3 Login Warning Banner In the default graphical environment, displaying a login warning banner in the GNOME Display Manager's login screen can be enabled on the login screen by setting banner-message-enable to true. To enable, add or edit banner-message-enable to /etc/dconf/db/gdm.d/00-security-settings. For example: [org/gnome/login-screen] banner-message-enable=true Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: /org/gnome/login-screen/banner-message-enable After the settings have been set, run dconf update. The banner text must also be set. 1 12 15 16 DSS05.04 DSS05.10 DSS06.10 3.1.9 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 AC-8(a) AC-8(b) AC-8(c) PR.AC-7 SRG-OS-000023-GPOS-00006 SRG-OS-000228-GPOS-00088 Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. For U.S. Government systems, system use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. Set the GNOME3 Login Warning Banner Text In the default graphical environment, configuring the login warning banner text in the GNOME Display Manager's login screen can be configured on the login screen by setting banner-message-text to 'APPROVED_BANNER' where APPROVED_BANNER is the approved banner for your environment. To enable, add or edit banner-message-text to /etc/dconf/db/gdm.d/00-security-settings. For example: [org/gnome/login-screen] banner-message-text='APPROVED_BANNER' Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example: /org/gnome/login-screen/banner-message-text After the settings have been set, run dconf update. When entering a warning banner that spans several lines, remember to begin and end the string with ' and use \n for new lines. 1 12 15 16 DSS05.04 DSS05.10 DSS06.10 3.1.9 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 AC-8(a) AC-8(c) PR.AC-7 SRG-OS-000023-GPOS-00006 SRG-OS-000228-GPOS-00088 An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Protect Accounts by Configuring PAM PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that. PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM. PAM looks in the directory /etc/pam.d for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file /etc/pam.d/login to determine what actions should be taken. One very important file in /etc/pam.d is /etc/pam.d/system-auth. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service. Be careful when making changes to PAM's configuration files. The syntax for these files is complex, and modifications can have unexpected consequences. The default configurations shipped with applications should be sufficient for most users. Running authconfig or system-config-authentication will re-write the PAM configuration files, destroying any manually made changes and replacing them with a series of system defaults. One reference to the configuration file syntax can be found at https://fossies.org/linux/Linux-PAM-docs/doc/sag/Linux-PAM_SAG.pdf. Password Hashing algorithm Specify the system default encryption algorithm for encrypting passwords. Defines the value set as ENCRYPT_METHOD in /etc/login.defs. SHA512 SHA512 SHA256 YESCRYPT SHA512|YESCRYPT SHA512|YESCRYPT YESCRYPT|SHA512 YESCRYPT|SHA512 YESCRYPT|SHA512 Install nss-sss Package The libnss-sss package can be installed with the following command: $ apt-get install libnss-sss libnss-sss contains library that is needed by SSSD (System Security Services Daemon).. Install pam_pwquality Package The libpwquality package can be installed with the following command: $ apt-get install libpwquality SRG-OS-000480-GPOS-00225 Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. "pwquality" enforces complex password construction configuration and has the ability to limit brute-force attacks on the system. Install pam-sss Package The libpam-sss package can be installed with the following command: $ apt-get install libpam-sss libpam-sss has pam module for the SSSD (System Security Services Daemon). Set Lockouts for Failed Password Attempts The pam_faillock PAM module provides the capability to lock out user accounts after a number of failed login attempts. Its documentation is available in /usr/share/doc/pam-VERSION/txts/README.pam_faillock. Locking out user accounts presents the risk of a denial-of-service attack. The lockout policy must weigh whether the risk of such a denial-of-service attack outweighs the benefits of thwarting password guessing attacks. fail_deny Number of failed login attempts before account lockout 10 3 4 5 6 8 3 fail_interval Interval for counting failed login attempts before account lockout 100000000 1800 3600 86400 900 900 fail_unlock_time Seconds before automatic unlocking or permanently locking after excessive failed logins 1800 3600 600 604800 86400 900 300 0 0 faildelay_delay Delay next login attempt after a failed login 0 4000000 4000000 Enforce Delay After Failed Logon Attempts To configure the system to introduce a delay after failed logon attempts, add or correct the pam_faildelay settings in /etc/pam.d/common-auth to make sure its delay parameter is at least or greater. For example: auth required pam_faildelay.so delay= SRG-OS-000480-GPOS-00226 Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account. Account Lockouts Must Be Logged PAM faillock locks an account due to excessive password failures, this event must be logged. AC-7 (a) SRG-OS-000021-GPOS-00005 Without auditing of these events it may be harder or impossible to identify what an attacker did after an attack. Lock Accounts After Failed Password Attempts This rule configures the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. Ensure that the file /etc/security/faillock.conf contains the following entry: deny = <count> Where count should be less than or equal to and greater than 0. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. If the system relies on authselect tool to manage PAM settings, the remediation will also use authselect tool. However, if any manual modification was made in PAM files, the authselect integrity check will fail and the remediation will be aborted in order to preserve intentional changes. In this case, an informative message will be shown in the remediation report. If the system supports the /etc/security/faillock.conf file, the pam_faillock parameters should be defined in faillock.conf file. 1 12 15 16 5.5.3 DSS05.04 DSS05.10 DSS06.10 3.1.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 CM-6(a) AC-7(a) PR.AC-7 FIA_AFL.1 Req-8.1.6 SRG-OS-000329-GPOS-00128 SRG-OS-000021-GPOS-00005 R31 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 8.3.4 8.3 By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking the account. Set Interval For Counting Failed Password Attempts Utilizing pam_faillock.so, the fail_interval directive configures the system to lock out an account after a number of incorrect login attempts within a specified time period. Ensure that the file /etc/security/faillock.conf contains the following entry: fail_interval = <interval-in-seconds> where interval-in-seconds is or greater. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. If the system relies on authselect tool to manage PAM settings, the remediation will also use authselect tool. However, if any manual modification was made in PAM files, the authselect integrity check will fail and the remediation will be aborted in order to preserve intentional changes. In this case, an informative message will be shown in the remediation report. If the system supports the /etc/security/faillock.conf file, the pam_faillock parameters should be defined in faillock.conf file. 1 12 15 16 DSS05.04 DSS05.10 DSS06.10 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 CM-6(a) AC-7(a) PR.AC-7 FIA_AFL.1 SRG-OS-000329-GPOS-00128 SRG-OS-000021-GPOS-00005 R31 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 By limiting the number of failed logon attempts the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account. Do Not Show System Messages When Unsuccessful Logon Attempts Occur This rule ensures the system prevents informative messages from being presented to the user pertaining to logon information after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. If the system relies on authselect tool to manage PAM settings, the remediation will also use authselect tool. However, if any manual modification was made in PAM files, the authselect integrity check will fail and the remediation will be aborted in order to preserve intentional changes. In this case, an informative message will be shown in the remediation report. If the system supports the /etc/security/faillock.conf file, the pam_faillock parameters should be defined in faillock.conf file. SRG-OS-000329-GPOS-00128 SRG-OS-000021-GPOS-00005 The pam_faillock module without the silent option will leak information about the existence or non-existence of a user account in the system because the failures are not recorded for unknown users. The message about the user account being locked is never displayed for non-existing user accounts allowing the adversary to infer that a particular account exists or not on the system. Set Lockout Time for Failed Password Attempts This rule configures the system to lock out accounts during a specified time period after a number of incorrect login attempts using pam_faillock.so. Ensure that the file /etc/security/faillock.conf contains the following entry: unlock_time=<interval-in-seconds> where interval-in-seconds is or greater. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid any errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user. This should be done using the faillock tool. If the system supports the new /etc/security/faillock.conf file but the pam_faillock.so parameters are defined directly in /etc/pam.d/system-auth and /etc/pam.d/password-auth, the remediation will migrate the unlock_time parameter to /etc/security/faillock.conf to ensure compatibility with authselect tool. The parameters deny and fail_interval, if used, also have to be migrated by their respective remediation. If the system relies on authselect tool to manage PAM settings, the remediation will also use authselect tool. However, if any manual modification was made in PAM files, the authselect integrity check will fail and the remediation will be aborted in order to preserve intentional changes. In this case, an informative message will be shown in the remediation report. If the system supports the /etc/security/faillock.conf file, the pam_faillock parameters should be defined in faillock.conf file. 1 12 15 16 5.5.3 DSS05.04 DSS05.10 DSS06.10 3.1.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 CM-6(a) AC-7(b) PR.AC-7 FIA_AFL.1 Req-8.1.7 SRG-OS-000329-GPOS-00128 SRG-OS-000021-GPOS-00005 R31 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 8.3.4 8.3 By limiting the number of failed logon attempts the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account. Set Password Quality Requirements The default pam_pwquality PAM module provides strength checking for passwords. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes. The pam_pwquality module is the preferred way of configuring password requirements. The man pages pam_pwquality(8) provide information on the capabilities and configuration of each. Set Password Quality Requirements with pam_pwquality The pam_pwquality PAM module can be configured to meet requirements for a variety of policies. For example, to configure pam_pwquality to require at least one uppercase character, lowercase character, digit, and other (special) character, make sure that pam_pwquality exists in /etc/pam.d/system-auth: password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth. Next, modify the settings in /etc/security/pwquality.conf to match the following: difok = 4 minlen = 14 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1 maxrepeat = 3 The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows. dcredit Minimum number of digits in password 0 -1 -2 -1 dictcheck Prevent the use of dictionary words for passwords. 1 1 difok Minimum number of characters not present in old password 15 1 2 3 4 5 6 7 8 8 lcredit Minimum number of lower case in password 0 -1 -2 -1 minlen Minimum number of characters in password 10 12 14 15 17 18 20 6 7 8 15 ocredit Minimum number of other (special characters) in password 0 -1 -2 -1 retry Number of retry attempts before erroring out 1 2 3 4 5 3 ucredit Minimum number of upper case in password 0 -1 -2 -1 Ensure PAM Enforces Password Requirements - Minimum Digit Characters The pam_pwquality module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional length credit for each digit. Modify the dcredit setting in /etc/security/pwquality.conf to require the use of a digit in passwords. 1 12 15 16 5 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(c) IA-5(1)(a) CM-6(a) IA-5(4) PR.AC-1 PR.AC-6 PR.AC-7 FMT_SMF_EXT.1 Req-8.2.3 SRG-OS-000071-GPOS-00039 R31 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 8.3.6 8.3 Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Requiring digits makes password guessing attacks more difficult by ensuring a larger search space. Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words The pam_pwquality module's dictcheck check if passwords contains dictionary words. When dictcheck is set to 1 passwords will be checked for dictionary words. IA-5(c) IA-5(1)(a) CM-6(a) IA-5(4) SRG-OS-000480-GPOS-00225 SRG-OS-000072-GPOS-00040 Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Passwords with dictionary words may be more vulnerable to password-guessing attacks. Ensure PAM Enforces Password Requirements - Minimum Different Characters The pam_pwquality module's difok parameter sets the number of characters in a password that must not be present in and old password during a password change. Modify the difok setting in /etc/security/pwquality.conf to equal to require differing characters when changing passwords. 1 12 15 16 5 5.6.2.1.1 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(c) IA-5(1)(b) CM-6(a) IA-5(4) PR.AC-1 PR.AC-6 PR.AC-7 SRG-OS-000072-GPOS-00040 Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute–force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however. Ensure PAM Enforces Password Requirements - Enforcing Verify that the operating system uses "pwquality" to enforce the password complexity rules. Verify the pwquality module is being enforced by operating system by running the following command: $ grep -i enforcing /etc/security/pwquality.conf enforcing = 1 If the value of "enforcing" is not "1" or the line is commented out, this is a finding. SRG-OS-000480-GPOS-00225 Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Using enforcing=1 ensures "pwquality" enforces complex password construction configuration and has the ability to limit brute-force attacks on the system. Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters The pam_pwquality module's lcredit parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each lowercase character. Modify the lcredit setting in /etc/security/pwquality.conf to require the use of a lowercase character in passwords. 1 12 15 16 5 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(c) IA-5(1)(a) CM-6(a) IA-5(4) PR.AC-1 PR.AC-6 PR.AC-7 FMT_SMF_EXT.1 Req-8.2.3 SRG-OS-000070-GPOS-00038 R31 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 8.3.6 8.3 Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space. Ensure PAM Enforces Password Requirements - Minimum Length The pam_pwquality module's minlen parameter controls requirements for minimum characters required in a password. Add minlen= after pam_pwquality to set minimum password length requirements. 1 12 15 16 5 5.6.2.1.1 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(c) IA-5(1)(a) CM-6(a) IA-5(4) PR.AC-1 PR.AC-6 PR.AC-7 FMT_SMF_EXT.1 Req-8.2.3 SRG-OS-000078-GPOS-00046 R31 R68 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 8.3.6 8.3 The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. Ensure PAM Enforces Password Requirements - Minimum Special Characters The pam_pwquality module's ocredit= parameter controls requirements for usage of special (or "other") characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each special character. Modify the ocredit setting in /etc/security/pwquality.conf to equal to require use of a special character in passwords. 1 12 15 16 5 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(c) IA-5(1)(a) CM-6(a) IA-5(4) PR.AC-1 PR.AC-6 PR.AC-7 FMT_SMF_EXT.1 SRG-OS-000266-GPOS-00101 R31 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space. Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry= , or a lower value if site policy is more restrictive. The profile requirement is a maximum of retry= prompts per session. 1 11 12 15 16 3 5 9 5.5.3 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 4.3.4.3.2 4.3.4.3.3 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 7.6 A.12.1.2 A.12.5.1 A.12.6.2 A.14.2.2 A.14.2.3 A.14.2.4 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 CM-6(a) AC-7(a) IA-5(4) PR.AC-1 PR.AC-6 PR.AC-7 PR.IP-1 SRG-OS-000069-GPOS-00037 SRG-OS-000480-GPOS-00227 R68 Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Note that this is different from account lockout, which is provided by the pam_faillock module. Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters The pam_pwquality module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each uppercase character. Modify the ucredit setting in /etc/security/pwquality.conf to require the use of an uppercase character in passwords. 1 12 15 16 5 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(c) IA-5(1)(a) CM-6(a) IA-5(4) PR.AC-1 PR.AC-6 PR.AC-7 FMT_SMF_EXT.1 Req-8.2.3 SRG-OS-000069-GPOS-00037 SRG-OS-000070-GPOS-00038 R31 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Set Password Hashing Algorithm The system's default algorithm for storing password hashes in /etc/shadow is SHA-512. This can be configured in several locations. Set Password Hashing Algorithm for PAM The PAM system service can be configured to only store encrypted representations of passwords. In "/etc/pam.d/common-password", the password section of the file controls which PAM modules to execute during a password change. Set the pam_unix.so module in the password section to include the option sha512 and no other hashing algorithms as shown below: password [success=1 default=ignore] pam_unix.so sha512 other arguments... This will help ensure that new passwords for local users will be stored using the sha512 algorithm. Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Set Password Hashing Algorithm in /etc/login.defs In /etc/login.defs, add or update the following line to ensure the system will use as the hashing algorithm: ENCRYPT_METHOD 1 12 15 16 5 5.6.2.2 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 3.13.11 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(c) IA-5(1)(c) CM-6(a) PR.AC-1 PR.AC-6 PR.AC-7 Req-8.2.1 SRG-OS-000073-GPOS-00041 0418 1055 1402 8.3.2 8.3 Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. Using a stronger hashing algorithm makes password cracking attacks more difficult. Protect Physical Console Access It is impossible to fully protect a system from an attacker with physical access, so securing the space in which the system is located should be considered a necessary step. However, there are some steps which, if taken, make it more difficult for an attacker to quickly or undetectably modify a system from its console. Disable Ctrl-Alt-Del Reboot Activation By default, SystemD will reboot the system if the Ctrl-Alt-Del key sequence is pressed. To configure the system to ignore the Ctrl-Alt-Del key sequence from the command line instead of rebooting the system, do either of the following: ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target or systemctl mask ctrl-alt-del.target Do not simply delete the /usr/lib/systemd/system/ctrl-alt-del.service file, as this file may be restored during future system updates. 12 13 14 15 16 18 3 5 APO01.06 DSS05.04 DSS05.07 DSS06.02 3.4.5 164.308(a)(1)(ii)(B) 164.308(a)(7)(i) 164.308(a)(7)(ii)(A) 164.310(a)(1) 164.310(a)(2)(i) 164.310(a)(2)(ii) 164.310(a)(2)(iii) 164.310(b) 164.310(c) 164.310(d)(1) 164.310(d)(2)(iii) 4.3.3.7.3 SR 2.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 R2.3 CIP-007-3 R2.1 CIP-007-3 R2.2 CIP-007-3 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.1 CIP-007-3 R5.1.2 CM-6(a) AC-6(1) PR.AC-4 PR.DS-5 FAU_GEN.1.2 SRG-OS-000324-GPOS-00125 SRG-OS-000480-GPOS-00227 A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. Configure Screen Locking When a user must temporarily leave an account logged-in, screen locking should be employed to prevent passersby from abusing the account. User education and training is particularly important for screen locking to be effective, and policies can be implemented to reinforce this. Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen. Configure Console Screen Locking A console screen locking mechanism is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operation system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. Check that vlock is installed to allow session locking The Claroty CTD 5.x operating system must have vlock installed to allow for session locking. The kbd package can be installed with the following command: $ apt-get install kbd SRG-OS-000028-GPOS-00009 SRG-OS-000030-GPOS-00011 A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. Regardless of where the session lock is determined and implemented, once invoked, the session lock must remain in place until the user reauthenticates. No other activity aside from reauthentication must unlock the system. Hardware Tokens for Authentication The use of hardware tokens such as smart cards for system login provides stronger, two-factor authentication than using a username and password. In Red Hat Enterprise Linux servers and workstations, hardware token login is not enabled by default and must be enabled in the system settings. Install the opensc Package For Multifactor Authentication The opensc package can be installed with the following command: $ apt-get install opensc CM-6(a) SRG-OS-000375-GPOS-00160 SRG-OS-000376-GPOS-00161 1386 Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider. Install Smart Card Packages For Multifactor Authentication Configure the operating system to implement multifactor authentication by installing the required package with the following command: The openssl-pkcs11 package can be installed with the following command: $ apt-get install openssl-pkcs11 CM-6(a) Req-8.3 SRG-OS-000105-GPOS-00052 SRG-OS-000375-GPOS-00160 SRG-OS-000375-GPOS-00161 SRG-OS-000377-GPOS-00162 Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider. Configure Smart Card Certificate Authority Validation Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ca like so: cert_policy = ca, ocsp_on, signature; SRG-OS-000066-GPOS-00034 SRG-OS-000384-GPOS-00167 Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider. Configure Smart Card Certificate Status Checking Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so: cert_policy = ca, ocsp_on, signature; SRG-OS-000375-GPOS-00160 SRG-OS-000376-GPOS-00161 SRG-OS-000377-GPOS-00162 SRG-OS-000384-GPOS-00167 Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider. Configure Smart Card Local Cache of Revocation Data Configure the operating system for PKI-based authentication to use local revocation data when unable to access the network to obtain it remotely. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include crl_auto or crl_offline like so: cert_policy = ca,signature,ocsp_on,crl_auto; SRG-OS-000384-GPOS-00167 Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates). Enable Smart Card Logins in PAM This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management). Check that the pam_pkcs11.so option is configured in the etc/pam.d/common-auth file with the following command: # grep pam_pkcs11.so /etc/pam.d/common-auth auth sufficient pam_pkcs11.so For general information about enabling smart card authentication, consult the documentation at: https://www.suse.com/c/configuring-smart-card-authentication-suse-linux-enterprise/ SRG-OS-000068-GPOS-00036 SRG-OS-000105-GPOS-00052 SRG-OS-000106-GPOS-00053 SRG-OS-000107-GPOS-00054 SRG-OS-000108-GPOS-00055 SRG-OS-000375-GPOS-00160 SRG-OS-000375-GPOS-00161 SRG-OS-000375-GPOS-00162 Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials. Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider. Verify that 'use_mappers' is set to 'pwent' in PAM The operating system must map the authenticated identity to the user or group account for PKI-based authentication. Verify that use_mappers is set to pwent in /etc/pam_pkcs11/pam_pkcs11.conf file with the following command: $ grep ^use_mappers /etc/pam_pkcs11/pam_pkcs11.conf use_mappers = pwent SRG-OS-000068-GPOS-00036 Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. Protect Accounts by Restricting Password-Based Login Conventionally, Unix shell accounts are accessed by providing a username and password to a login program, which tests these values for correctness using the /etc/passwd and /etc/shadow files. Password-based login is vulnerable to guessing of weak passwords, and to sniffing and man-in-the-middle attacks against passwords entered over a network or at an insecure console. Therefore, mechanisms for accessing accounts by entering usernames and passwords should be restricted to those which are operationally necessary. Set Account Expiration Parameters Accounts can be configured to be automatically disabled after a certain time period, meaning that they will require administrator interaction to become usable again. Expiration of accounts after inactivity can be set for all accounts by default and also on a per-account basis, such as for accounts that are known to be temporary. To configure automatic expiration of an account following the expiration of its password (that is, after the password has expired and not been changed), run the following command, substituting NUM_DAYS and USER appropriately: $ sudo chage -I NUM_DAYS USER Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the -E option. The file /etc/default/useradd controls default settings for all newly-created accounts created with the system's normal command line utilities. This will only apply to newly created accounts number of days after a password expires until the account is permanently disabled The number of days to wait after a password expires, until the account will be permanently disabled. 0 180 30 35 40 45 60 90 35 Set Account Expiration Following Inactivity To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following line in /etc/default/useradd: INACTIVE= If a password is currently on the verge of expiration, then day(s) remain(s) until the account is automatically disabled. However, if the password will not expire for another 60 days, then 60 days plus day(s) could elapse until the account would be automatically disabled. See the useradd man page for more information. 1 12 13 14 15 16 18 3 5 7 8 5.6.2.1.1 DSS01.03 DSS03.05 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 3.5.6 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 6.2 A.12.4.1 A.12.4.3 A.18.1.4 A.6.1.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 IA-4(e) AC-2(3) CM-6(a) DE.CM-1 DE.CM-3 PR.AC-1 PR.AC-4 PR.AC-6 PR.AC-7 Req-8.1.4 SRG-OS-000118-GPOS-00060 8.2.6 8.2 Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Assign Expiration Date to Temporary Accounts Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts. In the event temporary accounts are required, configure the system to terminate them after a documented time period. For every temporary account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately: $ sudo chage -E YYYY-MM-DD USER YYYY-MM-DD indicates the documented expiration date for the account. For U.S. Government systems, the operating system must be configured to automatically terminate these types of accounts after a period of 72 hours. 1 12 13 14 15 16 18 3 5 7 8 DSS01.03 DSS03.05 DSS05.04 DSS05.05 DSS05.07 DSS06.03 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 SR 1.1 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 6.2 A.12.4.1 A.12.4.3 A.6.1.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 AC-2(2) AC-2(3) CM-6(a) DE.CM-1 DE.CM-3 PR.AC-1 PR.AC-4 PR.AC-6 SRG-OS-000123-GPOS-00064 SRG-OS-000002-GPOS-00002 If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation. Set Password Expiration Parameters The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information. Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag. The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire. For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command: $ sudo chage -M 180 -m 7 -W 7 USER maximum password age Maximum age of password in days 365 120 180 90 60 45 60 minimum password age Minimum age of password in days 0 1 2 3 4 5 6 7 7 Set Password Maximum Age To specify password maximum age for new accounts, edit the file /etc/login.defs and add or correct the following line: PASS_MAX_DAYS The profile requirement is . 1 12 15 16 5 5.6.2.1 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 3.5.6 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(f) IA-5(1)(d) CM-6(a) PR.AC-1 PR.AC-6 PR.AC-7 Req-8.2.4 SRG-OS-000076-GPOS-00044 0418 1055 1402 8.3.9 8.3 Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised. Setting the password maximum age ensures users are required to periodically change their passwords. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise. Set Password Minimum Age To specify password minimum age for new accounts, edit the file /etc/login.defs and add or correct the following line: PASS_MIN_DAYS A value of 1 day is considered sufficient for many environments. The profile requirement is . 1 12 15 16 5 5.6.2.1.1 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 3.5.8 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-5(f) IA-5(1)(d) CM-6(a) PR.AC-1 PR.AC-6 PR.AC-7 SRG-OS-000075-GPOS-00043 0418 1055 1402 Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse. Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement. Verify Proper Storage and Existence of Password Hashes By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration. Password Hashing algorithm Specify the number of rounds for the system password encryption algorithm. Defines the value set in /etc/pam.d/system-auth and /etc/pam.d/password-auth 5000 5000 65536 100000 11 5 Set number of Password Hashing Rounds - password-auth Configure the number or rounds for the password hashing algorithm. This can be accomplished by using the rounds option for the pam_unix PAM module. In file /etc/pam.d/password-auth append rounds= to the pam_unix.so entry, as shown below: password sufficient pam_unix.so ...existing_options... rounds= The system's default number of rounds is 5000. Setting a high number of hashing rounds makes it more difficult to brute force the password, but requires more CPU resources to authenticate users. SRG-OS-000073-GPOS-00041 R68 Using a higher number of rounds makes password cracking attacks more difficult. Ensure sudo group has only necessary members Developers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles. Implementation may include isolation of memory space and libraries. The Ubuntu operating system restricts access to security functions through the use of access control mechanisms and by implementing least privilege capabilities. Due to the risk of removing user rights, automated remediation is not available for this configuration check. SRG-OS-000134-GPOS-00068 Any users assigned to the sudo group would be granted administrator access to the system. Ensure no duplicate UIDs exist Although the useradd program will not let you create a duplicate User ID (UID), it is possible for an administrator to manually edit the /etc/passwd file and change the UID field. Users must be assigned unique UIDs for accountability and to ensure appropriate access protections. Due to the risk of removing user accounts or changing user's UIDS, automated remediation is not available for this configuration check. SRG-OS-000104-GPOS-00051 SRG-OS-000121-GPOS-00062 Users must be assigned unique UIDs for accountability and to ensure appropriate access protections. Prevent Login to Accounts With Empty Password If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok in /etc/pam.d/system-auth and /etc/pam.d/password-auth to prevent logins with empty passwords. If the system relies on authselect tool to manage PAM settings, the remediation will also use authselect tool. However, if any manual modification was made in PAM files, the authselect integrity check will fail and the remediation will be aborted in order to preserve intentional changes. In this case, an informative message will be shown in the remediation report. Note that this rule is not applicable for systems running within a container. Having user with empty password within a container is not considered a risk, because it should not be possible to directly login into a container anyway. 1 12 13 14 15 16 18 3 5 5.5.2 APO01.06 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.02 DSS06.03 DSS06.10 3.1.1 3.1.5 164.308(a)(1)(ii)(B) 164.308(a)(7)(i) 164.308(a)(7)(ii)(A) 164.310(a)(1) 164.310(a)(2)(i) 164.310(a)(2)(ii) 164.310(a)(2)(iii) 164.310(b) 164.310(c) 164.310(d)(1) 164.310(d)(2)(iii) 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.18.1.4 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 IA-5(1)(a) IA-5(c) CM-6(a) PR.AC-1 PR.AC-4 PR.AC-6 PR.AC-7 PR.DS-5 FIA_UAU.1 Req-8.2.3 SRG-OS-000480-GPOS-00227 1546 8.3.1 8.3 If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. Ensure There Are No Accounts With Blank or Null Passwords Check the "/etc/shadow" file for blank passwords with the following command: $ sudo awk -F: '!$2 {print $1}' /etc/shadow If the command returns any results, this is a finding. Configure all accounts on the system to have a password or lock the account with the following commands: Perform a password reset: $ sudo passwd [username] Lock an account: $ sudo passwd -l [username] Note that this rule is not applicable for systems running within a container. Having user with empty password within a container is not considered a risk, because it should not be possible to directly login into a container anyway. CM-6(b) CM-6.1(iv) SRG-OS-000480-GPOS-00227 2.2.2 2.2 If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. Restrict Root Logins Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH. Direct root Logins Are Not Allowed Configure the operating system to prevent direct logins to the root account by performing the following operations: $ sudo passwd -l root SRG-OS-000109-GPOS-00056 Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Secure Session Configuration Files for Login Accounts When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators. Maximum concurrent login sessions Maximum number of concurrent sessions by a user 1 10 15 20 3 5 1 Account Inactivity Timeout (seconds) In an interactive shell, the value is interpreted as the number of seconds to wait for input after issuing the primary prompt. Bash terminates after waiting for that number of seconds if input does not arrive. 1800 600 900 300 600 Limit the Number of Concurrent Login Sessions Allowed Per User Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf or a file under /etc/security/limits.d/: * hard maxlogins 14 15 18 9 5.5.2.2 DSS01.05 DSS05.02 4.3.3.4 SR 3.1 SR 3.8 A.13.1.1 A.13.1.3 A.13.2.1 A.14.1.2 A.14.1.3 CIP-007-3 R5.1 CIP-007-3 R5.1.2 AC-10 CM-6(a) PR.AC-5 SRG-OS-000027-GPOS-00008 Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions. Set Interactive Session Timeout Setting the TMOUT option in /etc/profile ensures that all user sessions will terminate based on inactivity. A value of 0 (zero) disables the automatic logout feature and is therefore not a compliant setting. The value of TMOUT should be a positive integer, exported, and read only. The TMOUT setting in a file loaded by /etc/profile, e.g. /etc/profile.d/tmout.sh should read as follows: typeset -xr TMOUT= or declare -xr TMOUT= Using the typeset keyword is preferred for wider compatibility with ksh and other shells. 1 12 15 16 DSS05.04 DSS05.10 DSS06.10 3.1.11 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 CIP-004-6 R2.2.3 CIP-007-3 R5.1 CIP-007-3 R5.2 CIP-007-3 R5.3.1 CIP-007-3 R5.3.2 CIP-007-3 R5.3.3 AC-12 SC-10 AC-2(5) CM-6(a) PR.AC-7 SRG-OS-000163-GPOS-00072 SRG-OS-000029-GPOS-00010 R32 8.6.1 8.6 Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. Ensure that Users Have Sensible Umask Values The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member. Sensible umask Enter default user umask 007 022 027 077 027 Ensure the Default Umask is Set Correctly in login.defs To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows: UMASK 11 18 3 9 APO13.01 BAI03.01 BAI03.02 BAI03.03 BAI10.01 BAI10.02 BAI10.03 BAI10.05 4.3.4.3.2 4.3.4.3.3 SR 7.6 A.12.1.2 A.12.5.1 A.12.6.2 A.14.1.1 A.14.2.1 A.14.2.2 A.14.2.3 A.14.2.4 A.14.2.5 A.6.1.5 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 R2.3 CIP-007-3 R2.1 CIP-007-3 R2.2 CIP-007-3 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.1 CIP-007-3 R5.1.2 AC-6(1) CM-6(a) PR.IP-1 PR.IP-2 SRG-OS-000480-GPOS-00228 R36 The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read and written to by unauthorized users. AppArmor Many security vulnerabilities result from bugs in trusted programs. A trusted program runs with privileges that attackers want to possess. The program fails to keep that trust if there is a bug in the program that allows the attacker to acquire said privilege. AppArmor® is an application security solution designed specifically to apply privilege confinement to suspect programs. AppArmor allows the administrator to specify the domain of activities the program can perform by developing a security profile. A security profile is a listing of files that the program may access and the operations the program may perform. AppArmor secures applications by enforcing good application behavior without relying on attack signatures, so it can prevent attacks even if previously unknown vulnerabilities are being exploited. Ensure AppArmor is installed AppArmor provide Mandatory Access Controls. SRG-OS-000368-GPOS-00154 SRG-OS-000312-GPOS-00122 SRG-OS-000312-GPOS-00123 SRG-OS-000312-GPOS-00124 SRG-OS-000324-GPOS-00125 SRG-OS-000370-GPOS-00155 R45 Without a Mandatory Access Control system installed only the default Discretionary Access Control system will be available. Ensure AppArmor is Active and Configured Verify that the Apparmor tool is configured to control whitelisted applications and user home directory access control. The apparmor service can be enabled with the following command: $ sudo systemctl enable apparmor.service AC-3(4) AC-6(8) AC-6(10) CM-7(5)(b) CM-7(2) SC-7(21) CM-6(a) SRG-OS-000312-GPOS-00122 SRG-OS-000312-GPOS-00123 SRG-OS-000312-GPOS-00124 SRG-OS-000324-GPOS-00125 SRG-OS-000326-GPOS-00126 SRG-OS-000370-GPOS-00155 SRG-OS-000480-GPOS-00230 SRG-OS-000480-GPOS-00227 SRG-OS-000480-GPOS-00231 SRG-OS-000480-GPOS-00232 R45 Using a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. The organization must identify authorized software programs and permit execution of authorized software by adding each authorized program to the "pam_apparmor" exception policy. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. Verification of whitelisted software occurs prior to execution or at system startup. Users' home directories/folders may contain information of a sensitive nature. Nonprivileged users should coordinate any sharing of information with a System Administrator (SA) through shared resources. Apparmor can confine users to their home directory, not allowing them to make any changes outside of their own home directories. Confining users to their home directory will minimize the risk of sharing information. GRUB2 bootloader configuration During the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Claroty CTD 5.x boot loader for x86 systems is called GRUB2. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly. Non-UEFI GRUB2 bootloader configuration Non-UEFI GRUB2 bootloader configuration Set Boot Loader Password in grub2 The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings. Since plaintext passwords are a security risk, generate a hash for the password by running the following command: # grub2-setpassword When prompted, enter the password that was selected. To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation must be automated as a component of machine provisioning, or followed manually as outlined above. Also, do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file. 1 11 12 14 15 16 18 3 5 DSS05.02 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.06 DSS06.10 3.4.5 164.308(a)(1)(ii)(B) 164.308(a)(7)(i) 164.308(a)(7)(ii)(A) 164.310(a)(1) 164.310(a)(2)(i) 164.310(a)(2)(ii) 164.310(a)(2)(iii) 164.310(b) 164.310(c) 164.310(d)(1) 164.310(d)(2)(iii) 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.5.3 4.3.3.5.4 4.3.3.5.5 4.3.3.5.6 4.3.3.5.7 4.3.3.5.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.1 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.11 SR 1.12 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.6 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.2 SR 2.3 SR 2.4 SR 2.5 SR 2.6 SR 2.7 A.18.1.4 A.6.1.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CM-6(a) PR.AC-1 PR.AC-4 PR.AC-6 PR.AC-7 PR.PT-3 FIA_UAU.1 SRG-OS-000080-GPOS-00048 R5 Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. UEFI GRUB2 bootloader configuration UEFI GRUB2 bootloader configuration UEFI generally uses vfat file systems, which does not support Unix-style permissions managed by chmod command. In this case, in order to change file permissions for files within /boot/efi it is necessary to update the mount options in /etc/fstab file and reboot the system. Set the UEFI Boot Loader Password The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings. Since plaintext passwords are a security risk, generate a hash for the password by running the following command: # grub2-setpassword When prompted, enter the password that was selected. To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation must be automated as a component of machine provisioning, or followed manually as outlined above. Also, do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file. 11 12 14 15 16 18 3 5 DSS05.02 DSS05.04 DSS05.05 DSS05.07 DSS06.03 DSS06.06 3.4.5 164.308(a)(1)(ii)(B) 164.308(a)(7)(i) 164.308(a)(7)(ii)(A) 164.310(a)(1) 164.310(a)(2)(i) 164.310(a)(2)(ii) 164.310(a)(2)(iii) 164.310(b) 164.310(c) 164.310(d)(1) 164.310(d)(2)(iii) 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.5.3 4.3.3.5.4 4.3.3.5.5 4.3.3.5.6 4.3.3.5.7 4.3.3.5.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.1 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.11 SR 1.12 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.6 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.2 SR 2.3 SR 2.4 SR 2.5 SR 2.6 SR 2.7 A.6.1.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CM-6(a) PR.AC-4 PR.AC-6 PR.PT-3 FIA_UAU.1 SRG-OS-000080-GPOS-00048 R5 Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. Configure Syslog The syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications. In Claroty CTD 5.x, rsyslog has replaced ksyslogd as the syslog daemon of choice, and it includes some additional security features such as reliable, connection-oriented (i.e. TCP) transmission of logs, the option to log to database formats, and the encryption of log data en route to a central logging server. This section discusses how to configure rsyslog for best effect, and how to use tools provided with the system to maintain and monitor logs. Enable rsyslog Service The rsyslog service provides syslog-style logging by default on Claroty CTD 5.x. The rsyslog service can be enabled with the following command: $ sudo systemctl enable rsyslog.service 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO13.01 BAI03.05 BAI04.04 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 164.312(a)(2)(ii) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 SR 7.1 SR 7.2 A.12.1.3 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 A.17.2.1 CM-6(a) AU-4(1) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.DS-4 PR.PT-1 SRG-OS-000480-GPOS-00227 1409 The rsyslog service must be running in order to provide logging services, which are essential to system administration. Ensure real-time clock is set to UTC Ensure that the system real-time clock (RTC) is set to Coordinated Universal Time (UTC). SRG-OS-000359-GPOS-00146 If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the operating system include date and time. Time is commonly expressed in UTC, a modern continuation of GMT, or local time with an offset from UTC. Ensure Proper Configuration of Log Files The file /etc/rsyslog.conf controls where log message are written. These are controlled by lines called rules, which consist of a selector and an action. These rules are often customized depending on the role of the system, the requirements of the environment, and whatever may enable the administrator to most effectively make use of log data. The default rules in Claroty CTD 5.x are: *.info;mail.none;authpriv.none;cron.none /var/log/messages authpriv.* /var/log/secure mail.* -/var/log/maillog cron.* /var/log/cron *.emerg * uucp,news.crit /var/log/spooler local7.* /var/log/boot.log See the man page rsyslog.conf(5) for more information. Note that the rsyslog daemon can be configured to use a timestamp format that some log processing programs may not understand. If this occurs, edit the file /etc/rsyslog.conf and add or edit the following line: $ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat Ensure remote access methods are monitored in Rsyslog Logging of remote access methods must be implemented to help identify cyber attacks and ensure ongoing compliance with remote access policies are being audited and upheld. An examples of a remote access method is the use of the Remote Desktop Protocol (RDP) from an external, non-organization controlled network. The /etc/rsyslog.conf or /etc/rsyslog.d/*.conf file should contain a match for the following selectors: auth.*, authpriv.*, and daemon.*. If not, use the following as an example configuration: auth.*;authpriv.* /var/log/secure daemon.* /var/log/messages AC-17(1) SRG-OS-000032-GPOS-00013 Logging remote access methods can be used to trace the decrease the risks associated with remote user access management. It can also be used to spot cyber attacks and ensure ongoing compliance with organizational policies surrounding the use of remote access methods. systemd-journald systemd-journald is a system service that collects and stores logging data. It creates and maintains structured, indexed journals based on logging information that is received from a variety of sources. For more information on systemd-journald and additional systemd-journald configuration options, see https://systemd.io/. Verify group-owner of system journal directories Verify the /run/log/journal and /var/log/journal directories are group-owned by "systemd-journal" by using the following command: $ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %G" {} \; If any output returned is not owned by "systemd-journal", this is a finding. Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. Verify owner of system journal directories Verify the /run/log/journal and /var/log/journal directories are owned by "root" by using the following command: $ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %U" {} \; If any output returned is not owned by "root", this is a finding. Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. Verify Permissions on the system journal directories Verify the /run/log/journal and /var/log/journal directories have permissions set to "2750" or less permissive by using the following command: $ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %a" {} \; If any output returned has a permission set greater than "2750", this is a finding. Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization. Verify Groupowner on the journalctl command Verify that the "journalctl" command is group-owned by "root" by using the following command: $ sudo find /usr/bin/journalctl -exec stat -c "%n %G" {} \; If any output returned is not owned by "root", this is a finding. Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. Verify Group Who Owns the system journal ' To properly set the group owner of /var/log/journal/.*/system.journal, run the command: $ sudo chgrp systemd-journal /var/log/journal/.*/system.journal ' SRG-APP-000118-CTR-000240 RHCOS must protect system journal file from any type of unauthorized access by setting file group ownership. Verify Owner on the journalctl Command Verify that the "journalctl" command is owned by "root" by using the following command: $ sudo find /usr/bin/journalctl -exec stat -c "%n %U" {} \; If any output returned is not owned by "root", this is a finding. Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. Verify Owner on the system journal ' To properly set the owner of /var/log/journal/.*/system.journal, run the command: $ sudo chown root /var/log/journal/.*/system.journal ' SRG-APP-000118-CTR-000240 RHCOS must protect system journal file from any type of unauthorized access by setting file ownership Verify Permissions on the journal command Verify that the "journalctl" command has a permission set of "740" by using the following command: $ sudo find /usr/bin/journalctl -exec stat -c "%n %a" {} \; If "journalctl" is not set to "740", this is a finding. Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization. Verify Permissions on the system journal To properly set the permissions of /var/log/journal/.*/system.journal, run the command: $ sudo chmod 0640 /var/log/journal/.*/system.journal SRG-APP-000118-CTR-000240 RHCOS must protect system journal file from any type of unauthorized access by setting file permissions. Network Configuration and Firewalls Most systems must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system. This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks. Kernel Parameters Which Affect Networking The sysctl utility is used to set parameters which affect the operation of the Linux kernel. Kernel parameters which affect networking and have security implications are described here. Network Related Kernel Runtime Parameters for Hosts and Routers Certain kernel parameters should be set for systems which are acting as either hosts or routers to improve the system's ability defend against certain types of IPv4 protocol attacks. net.ipv4.tcp_syncookies Enable to turn on TCP SYN Cookie Protection 1 0 1 Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1 To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.tcp_syncookies = 1 1 12 13 14 15 16 18 2 4 6 7 8 9 5.10.1.1 APO01.06 APO13.01 BAI04.04 DSS01.03 DSS01.05 DSS03.01 DSS03.05 DSS05.02 DSS05.04 DSS05.07 DSS06.02 3.1.20 4.2.3.4 4.3.3.4 4.4.3.3 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.2 SR 7.1 SR 7.2 SR 7.6 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.12.1.1 A.12.1.2 A.12.1.3 A.13.1.1 A.13.1.2 A.13.1.3 A.13.2.1 A.13.2.2 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.17.2.1 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CM-7(a) CM-7(b) SC-5(1) SC-5(2) SC-5(3)(a) CM-6(a) DE.AE-1 DE.CM-1 ID.AM-3 PR.AC-5 PR.DS-4 PR.DS-5 PR.PT-4 Req-1.4.1 SRG-OS-000480-GPOS-00227 SRG-OS-000420-GPOS-00186 SRG-OS-000142-GPOS-00071 R12 1.4.3 1.4 A TCP SYN flood attack can cause a denial of service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests. Uncomplicated Firewall (ufw) The Linux kernel in Ubuntu provides a packet filtering system called netfilter, and the traditional interface for manipulating netfilter are the iptables suite of commands. iptables provide a complete firewall solution that is both highly configurable and highly flexible. Becoming proficient in iptables takes time, and getting started with netfilter firewalling using only iptables can be a daunting task. As a result, many frontends for iptables have been created over the years, each trying to achieve a different result and targeting a different audience. The Uncomplicated Firewall (ufw) is a frontend for iptables and is particularly well-suited for host-based firewalls. ufw provides a framework for managing netfilter, as well as a command-line interface for manipulating the firewall. ufw aims to provide an easy to use interface for people unfamiliar with firewall concepts, while at the same time simplifies complicated iptables commands to help an administrator who knows what he or she is doing. ufw is an upstream for other distributions and graphical frontends. Install ufw Package The ufw package can be installed with the following command: $ apt-get install ufw SRG-OS-000297-GPOS-00115 ufw controls the Linux kernel network packet filtering code. ufw allows system operators to set up firewalls and IP masquerading, etc. Verify ufw Enabled The ufw service can be enabled with the following command: $ sudo systemctl enable ufw.service SRG-OS-000297-GPOS-00115 The ufw service must be enabled and running in order for ufw to protect the system Verify ufw Active Verify the ufw is enabled on the system with the following command: # sudo ufw status If the above command returns the status as "inactive" or any type of error, this is a finding. Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Ubuntu 22.04 LTS functionality (e.g., RDP) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components. Only Allow Authorized Network Services in ufw Check the firewall configuration for any unnecessary or prohibited functions, ports, protocols, and/or services by running the following command: $ sudo ufw show raw Chain OUTPUT (policy ACCEPT) target prot opt sources destination Chain INPUT (policy ACCEPT 1 packets, 40 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Ask the System Administrator for the site or program PPSM CLSA. Verify the services allowed by the firewall match the PPSM CLSA. SRG-OS-000096-GPOS-00050 To prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues. ufw Must rate-limit network interfaces The operating system must configure the uncomplicated firewall to rate-limit impacted network interfaces. Check all the services listening to the ports with the following command: $ sudo ss -l46ut Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 128 [::]:ssh [::]:* For each entry, verify that the ufw is configured to rate limit the service ports with the following command: $ sudo ufw status If any port with a state of "LISTEN" is not marked with the "LIMIT" action, run the following command, replacing "service" with the service that needs to be rate limited: $ sudo ufw limit "service" Rate-limiting can also be done on an interface. An example of adding a rate-limit on the eth0 interface follows: $ sudo ufw limit in on eth0 SRG-OS-000420-GPOS-00186 This requirement addresses the configuration of the operating system to mitigate the impact of DoS attacks that have occurred or are ongoing on system availability. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks. Wireless Networking Wireless networking, such as 802.11 (WiFi) and Bluetooth, can present a security risk to sensitive or classified systems and networks. Wireless networking hardware is much more likely to be included in laptop or portable systems than in desktops or servers. Removal of hardware provides the greatest assurance that the wireless capability remains disabled. Acquisition policies often include provisions to prevent the purchase of equipment that will be used in sensitive spaces and includes wireless capabilities. If it is impractical to remove the wireless hardware, and policy permits the device to enter sensitive spaces as long as wireless is disabled, efforts should instead focus on disabling wireless capability via software. Disable Wireless Through Software Configuration If it is impossible to remove the wireless hardware from the device in question, disable as much of it as possible through software. The following methods can disable software support for wireless networking, but note that these methods do not prevent malicious software or careless users from re-activating the devices. Deactivate Wireless Network Interfaces Deactivating wireless network interfaces should prevent normal usage of the wireless capability. Configure the system to disable all wireless network interfaces with the following command: $ sudo nmcli radio all off 11 12 14 15 3 8 9 APO13.01 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS01.04 DSS05.02 DSS05.03 DSS05.05 DSS06.06 3.1.16 4.3.3.5.1 4.3.3.5.2 4.3.3.5.3 4.3.3.5.4 4.3.3.5.5 4.3.3.5.6 4.3.3.5.7 4.3.3.5.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.1 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.3.2 4.3.4.3.3 SR 1.1 SR 1.10 SR 1.11 SR 1.12 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.6 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.2 SR 2.3 SR 2.4 SR 2.5 SR 2.6 SR 2.7 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 7.1 SR 7.6 A.11.2.6 A.12.1.2 A.12.5.1 A.12.6.2 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.2 A.14.2.3 A.14.2.4 A.6.2.1 A.6.2.2 A.9.1.2 AC-18(a) AC-18(3) CM-7(a) CM-7(b) CM-6(a) MP-7 PR.AC-3 PR.IP-1 PR.PT-3 PR.PT-4 Req-1.3.3 SRG-OS-000299-GPOS-00117 SRG-OS-000300-GPOS-00118 SRG-OS-000424-GPOS-00188 SRG-OS-000481-GPOS-00481 1315 1319 1.3.3 1.3 The use of wireless networking can introduce many different attack vectors into the organization's network. Common attack vectors such as malicious association and ad hoc networks will allow an attacker to spoof a wireless access point (AP), allowing validated systems to connect to the malicious AP and enabling the attacker to monitor and record network traffic. These malicious APs can also serve to create a man-in-the-middle attack or be used to create a denial of service to valid network resources. Transport Layer Security Support Support for Transport Layer Security (TLS), and its predecessor, the Secure Sockets Layer (SSL), is included in Red Hat Enterprise Linux in the OpenSSL software (RPM package openssl). TLS provides encrypted and authenticated network communications, and many network services include support for it. TLS or SSL can be leveraged to avoid any plaintext transmission of sensitive data. For information on how to use OpenSSL, see http://www.openssl.org/docs/. Information on FIPS validation of OpenSSL is available at http://www.openssl.org/docs/fips.html and http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm. Only Allow DoD PKI-established CAs The operating system must only allow the use of DoD PKI-established certificate authorities for verification of the establishment of protected sessions. SRG-OS-000403-GPOS-00182 Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI-certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates. File Permissions and Masks Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access. Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given system. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn. The following command prints a list of all xfs partitions on the local system, which is the default filesystem for Claroty CTD 5.x installations: $ mount -t xfs | awk '{print $3}' For any systems that use a different local filesystem type, modify this command as appropriate. Verify Permissions on Important Files and Directories Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen. Verify that All World-Writable Directories Have Sticky Bits Set When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes. To set the sticky bit on a world-writable directory DIR, run the following command: $ sudo chmod +t DIR This rule can take a long time to perform the check and might consume a considerable amount of resources depending on the number of directories present on the system. It is not a problem in most cases, but especially systems with a large number of directories can be affected. See https://access.redhat.com/articles/6999111. Please note that there might be cases where the rule remediation cannot fix directory permissions. This can happen for example when running on a system with some immutable parts. These immutable parts cannot be remediated because they are read-only. Example of such directories can be OStree deployments located at /sysroot/ostree/deploy. In such case, it is needed to make modifications to the underlying ostree snapshot and this is out of scope of regular rule remediation. 12 13 14 15 16 18 3 5 APO01.06 DSS05.04 DSS05.07 DSS06.02 4.3.3.7.3 SR 2.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 R2.3 CIP-007-3 R2.1 CIP-007-3 R2.2 CIP-007-3 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.1 CIP-007-3 R5.1.2 CM-6(a) AC-6(1) PR.AC-4 PR.DS-5 SRG-OS-000138-GPOS-00069 R54 1409 2.2.6 2.2 Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure. The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, by users for temporary file storage (such as /tmp), and for directories requiring global read/write access. Verify permissions of log files Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization. Organizations carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers. SI-11(a) SI-11(b) SI-11.1(iii) PR.AC-4 PR.DS-5 SRG-OS-000205-GPOS-00083 10.3.1 10.3 The Claroty CTD 5.x must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. Verify Permissions on Files within /var/log Directory The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel. Verify Group Who Owns /var/log Directory To properly set the group owner of /var/log, run the command: $ sudo chgrp root /var/log SRG-OS-000206-GPOS-00084 SRG-APP-000118-CTR-000240 The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel. Verify Group Who Owns /var/log/syslog File To properly set the group owner of /var/log/syslog, run the command: $ sudo chgrp adm /var/log/syslog SRG-OS-000206-GPOS-00084 The /var/log/syslog file contains logs of error messages in the system and should only be accessed by authorized personnel. Verify User Who Owns /var/log Directory To properly set the owner of /var/log, run the command: $ sudo chown root /var/log SRG-OS-000206-GPOS-00084 SRG-APP-000118-CTR-000240 The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel. Verify User Who Owns /var/log/syslog File To properly set the owner of /var/log/syslog, run the command: $ sudo chown syslog /var/log/syslog SRG-OS-000206-GPOS-00084 The /var/log/syslog file contains logs of error messages in the system and should only be accessed by authorized personnel. Verify Permissions on /var/log Directory To properly set the permissions of /var/log, run the command: $ sudo chmod 0755 /var/log SRG-OS-000206-GPOS-00084 SRG-APP-000118-CTR-000240 The /var/log directory contains files with logs of error messages in the system and should only be accessed by authorized personnel. Verify Permissions on /var/log/syslog File To properly set the permissions of /var/log/syslog, run the command: $ sudo chmod 0640 /var/log/syslog SRG-OS-000206-GPOS-00084 The /var/log/syslog file contains logs of error messages in the system and should only be accessed by authorized personnel. Verify File Permissions Within Some Important Directories Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively. Verify that Shared Library Directories Have Root Group Ownership System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be group-owned by the root user. If the directories, is found to be owned by a user other than root correct its ownership with the following command: $ sudo chgrp root DIR CM-5(6) CM-5(6).1 SRG-OS-000259-GPOS-00100 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership of library directories is necessary to protect the integrity of the system. Verify that system commands directories are group owned by root System commands files are stored in the following directories by default: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin All these directories should be owned by the root group. If the directory is found to be owned by a group other than root correct its ownership with the following command: $ sudo chgrp root DIR SRG-OS-000258-GPOS-00099 If the operating system allows any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Verify that System Executable Have Root Ownership /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin All these directories should be owned by the root user. If any directory DIR in these directories is found to be owned by a user other than root, correct its ownership with the following command: $ sudo chown root DIR SRG-OS-000258-GPOS-00099 System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. Verify that Shared Library Directories Have Root Ownership System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directories, is found to be owned by a user other than root correct its ownership with the following command: $ sudo chown root DIR CM-5(6) CM-5(6).1 SRG-OS-000259-GPOS-00100 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership of library directories is necessary to protect the integrity of the system. Verify that System Executable Directories Have Restrictive Permissions System executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin These directories should not be group-writable or world-writable. If any directory DIR in these directories is found to be group-writable or world-writable, correct its permission with the following command: $ sudo chmod go-w DIR SRG-OS-000258-GPOS-00099 System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted. Verify that system commands files are group owned by root or a system account System commands files are stored in the following directories by default: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin All files in these directories should be owned by the root group, or a system account. If the directory, or any file in these directories, is found to be owned by a group other than root or a a system account correct its ownership with the following command: $ sudo chgrp root FILE CM-5(6) CM-5(6).1 SRG-OS-000259-GPOS-00100 R50 If the operating system allows any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Verify that System Executables Have Root Ownership System executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbin All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command: $ sudo chown root FILE 12 13 14 15 16 18 3 5 APO01.06 DSS05.04 DSS05.07 DSS06.02 4.3.3.7.3 SR 2.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 R2.3 CIP-007-3 R2.1 CIP-007-3 R2.2 CIP-007-3 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.1 CIP-007-3 R5.1.2 CM-5(6) CM-5(6).1 CM-6(a) AC-6(1) PR.AC-4 PR.DS-5 SRG-OS-000259-GPOS-00100 R50 1409 System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. Verify that Shared Library Files Have Root Ownership System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command: $ sudo chown root FILE 12 13 14 15 16 18 3 5 APO01.06 DSS05.04 DSS05.07 DSS06.02 4.3.3.7.3 SR 2.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 R2.3 CIP-007-3 R2.1 CIP-007-3 R2.2 CIP-007-3 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.1 CIP-007-3 R5.1.2 CM-5(6) CM-5(6).1 CM-6(a) AC-6(1) PR.AC-4 PR.DS-5 SRG-OS-000259-GPOS-00100 1409 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system. Verify that System Executables Have Restrictive Permissions System executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/libexec /usr/local/bin /usr/local/sbin /usr/sbin All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: $ sudo chmod go-w FILE 12 13 14 15 16 18 3 5 APO01.06 DSS05.04 DSS05.07 DSS06.02 4.3.3.7.3 SR 2.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 R2.3 CIP-007-3 R2.1 CIP-007-3 R2.2 CIP-007-3 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.1 CIP-007-3 R5.1.2 CM-5(6) CM-5(6).1 CM-6(a) AC-6(1) PR.AC-4 PR.DS-5 SRG-OS-000259-GPOS-00100 R50 1409 System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted. Verify that Shared Library Files Have Restrictive Permissions System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command: $ sudo chmod go-w FILE 12 13 14 15 16 18 3 5 APO01.06 DSS05.04 DSS05.07 DSS06.02 4.3.3.7.3 SR 2.1 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 R2.3 CIP-007-3 R2.1 CIP-007-3 R2.2 CIP-007-3 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.1 CIP-007-3 R5.1.2 CM-6(a) CM-5(6) CM-5(6).1 AC-6(1) PR.AC-4 PR.DS-5 SRG-OS-000259-GPOS-00100 1409 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system. Verify the system-wide library files in directories "/lib", "/lib64", "/usr/lib/" and "/usr/lib64" are group-owned by root. System-wide library files are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 All system-wide shared library files should be protected from unauthorised access. If any of these files is not group-owned by root, correct its group-owner with the following command: $ sudo chgrp root FILE CM-5(6) CM-5(6).1 SRG-OS-000259-GPOS-00100 If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications. Restrict Dynamic Mounting and Unmounting of Filesystems Linux includes a number of facilities for the automated addition and removal of filesystems on a running system. These facilities may be necessary in many environments, but this capability also carries some risk -- whether direct risk from allowing users to introduce arbitrary filesystems, or risk that software flaws in the automated mount facility itself could allow an attacker to compromise the system. This command can be used to list the types of filesystems that are available to the currently executing kernel: $ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko' If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d. Disable Modprobe Loading of USB Storage Driver To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. To configure the system to prevent the usb-storage kernel module from being loaded, add the following line to the file /etc/modprobe.d/usb-storage.conf: install usb-storage /bin/false This entry will cause a non-zero return value during a usb-storage module installation and additionally convey the meaning of the entry to the user in form of an error message. If you would like to omit a non-zero return value and an error message, you may want to add a different line instead (both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan): install usb-storage /bin/true This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually. 1 12 15 16 5 APO13.01 DSS01.04 DSS05.03 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 3.1.21 164.308(a)(3)(i) 164.308(a)(3)(ii)(A) 164.310(d)(1) 164.310(d)(2) 164.312(a)(1) 164.312(a)(2)(iv) 164.312(b) 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.6 A.11.2.6 A.13.1.1 A.13.2.1 A.18.1.4 A.6.2.1 A.6.2.2 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 CM-7(a) CM-7(b) CM-6(a) MP-7 PR.AC-1 PR.AC-3 PR.AC-6 PR.AC-7 SRG-OS-000114-GPOS-00059 SRG-OS-000378-GPOS-00163 SRG-OS-000480-GPOS-00227 SRG-APP-000141-CTR-000315 3.4.2 3.4 USB storage devices such as thumb drives can be used to introduce malicious software. Restrict Programs from Dangerous Execution Patterns The recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs. Restrict Access to Kernel Message Buffer To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command: $ sudo sysctl -w kernel.dmesg_restrict=1 To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.dmesg_restrict = 1 3.1.5 164.308(a)(1)(ii)(D) 164.308(a)(3) 164.308(a)(4) 164.310(b) 164.310(c) 164.312(a) 164.312(e) SI-11(a) SI-11(b) FMT_SMF_EXT.1 SRG-OS-000132-GPOS-00067 SRG-OS-000138-GPOS-00069 SRG-APP-000243-CTR-000600 R9 1546 Unprivileged access to the kernel syslog can expose sensitive kernel address information. Enable ExecShield ExecShield describes kernel features that provide protection against exploitation of memory corruption errors such as buffer overflows. These features include random placement of the stack and other memory regions, prevention of execution in memory that should only hold data, and special handling of text buffers. These protections are enabled by default on 32-bit systems and controlled through sysctl variables kernel.exec-shield and kernel.randomize_va_space. On the latest 64-bit systems, kernel.exec-shield cannot be enabled or disabled with sysctl. Enable Randomized Layout of Virtual Address Space To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command: $ sudo sysctl -w kernel.randomize_va_space=2 To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.randomize_va_space = 2 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3) 164.308(a)(4) 164.310(b) 164.310(c) 164.312(a) 164.312(e) CIP-002-5 R1.1 CIP-002-5 R1.2 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 4.1 CIP-004-6 4.2 CIP-004-6 R2.2.3 CIP-004-6 R2.2.4 CIP-004-6 R2.3 CIP-004-6 R4 CIP-005-6 R1 CIP-005-6 R1.1 CIP-005-6 R1.2 CIP-007-3 R3 CIP-007-3 R3.1 CIP-007-3 R5.1 CIP-007-3 R5.1.2 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 CIP-007-3 R8.4 CIP-009-6 R.1.1 CIP-009-6 R4 SC-30 SC-30(2) CM-6(a) Req-2.2.1 SRG-OS-000433-GPOS-00193 SRG-OS-000480-GPOS-00227 SRG-APP-000450-CTR-001105 R9 1409 3.3.1.1 3.3.1 3.3 Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques. Enable Execute Disable (XD) or No Execute (NX) Support on x86 Systems Recent processors in the x86 family support the ability to prevent code execution on a per memory page basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER, have included such support since inception and the standard kernel for those platforms supports the feature. This is enabled by default on the latest Oracle Linux, Red Hat and Fedora systems if supported by the hardware. Enable NX or XD Support in the BIOS Reboot the system and enter the BIOS or Setup configuration menu. Navigate the BIOS configuration menu and make sure that the option is enabled. The setting may be located under a Security section. Look for Execute Disable (XD) on Intel-based systems and No Execute (NX) on AMD-based systems. 11 3 9 BAI10.01 BAI10.02 BAI10.03 BAI10.05 3.1.7 4.3.4.3.2 4.3.4.3.3 SR 7.6 A.12.1.2 A.12.5.1 A.12.6.2 A.14.2.2 A.14.2.3 A.14.2.4 SC-39 CM-6(a) PR.IP-1 SRG-OS-000433-GPOS-00192 SRG-APP-000450-CTR-001105 2.2.1 2.2 Computers with the ability to prevent this type of code execution frequently put an option in the BIOS that will allow users to turn the feature on or off at will. Services The best protection against vulnerable software is running less software. This section describes how to review the software which Claroty CTD 5.x installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Claroty CTD 5.x system and provides guidance about which ones can be safely disabled. Claroty CTD 5.x provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Claroty CTD 5.x systems, it is highly recommended to select the minimal packages and then build up the system from there. APT service configuration The apt service manage the package management and update of the whole system. Its configuration need to be properly defined to ensure efficient security updates, packages and repository authentication and proper lifecycle management. Disable unauthenticated repositories in APT configuration Unauthenticated repositories should not be used for updates. SRG-OS-000366-GPOS-00153 Repositories hosts all packages that will be installed on the system during update. If a repository is not authenticated, the associated packages can't be trusted, and then should not be installed locally. Base Services This section addresses the base services that are installed on a Claroty CTD 5.x default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required. Disable KDump Kernel Crash Analyzer (kdump) The kdump service provides a kernel crash dump analyzer. It uses the kexec system call to boot a secondary kernel ("capture" kernel) following a system crash, which can load information from the crashed kernel for analysis. The kdump service can be disabled with the following command: $ sudo systemctl mask --now kdump.service 11 12 14 15 3 8 9 APO13.01 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS01.04 DSS05.02 DSS05.03 DSS05.05 DSS06.06 164.308(a)(1)(ii)(D) 164.308(a)(3) 164.308(a)(4) 164.310(b) 164.310(c) 164.312(a) 164.312(e) 4.3.3.5.1 4.3.3.5.2 4.3.3.5.3 4.3.3.5.4 4.3.3.5.5 4.3.3.5.6 4.3.3.5.7 4.3.3.5.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.1 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.3.2 4.3.4.3.3 SR 1.1 SR 1.10 SR 1.11 SR 1.12 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.6 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.2 SR 2.3 SR 2.4 SR 2.5 SR 2.6 SR 2.7 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 7.1 SR 7.6 A.11.2.6 A.12.1.2 A.12.5.1 A.12.6.2 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.2 A.14.2.3 A.14.2.4 A.6.2.1 A.6.2.2 A.9.1.2 CM-7(a) CM-7(b) CM-6(a) PR.AC-3 PR.IP-1 PR.PT-3 PR.PT-4 FMT_SMF_EXT.1.1 SRG-OS-000269-GPOS-00103 SRG-OS-000480-GPOS-00227 1409 Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition. Unless the system is used for kernel development or testing, there is little need to run the kdump service. Deprecated services Some deprecated software services impact the overall system security due to their behavior (leak of confidentiality in network exchange, usage as uncontrolled communication channel, risk associated with the service due to its old age, etc. Uninstall the telnet server The telnet daemon should be uninstalled. 11 12 14 15 3 8 9 APO13.01 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS01.04 DSS05.02 DSS05.03 DSS05.05 DSS06.06 4.3.3.5.1 4.3.3.5.2 4.3.3.5.3 4.3.3.5.4 4.3.3.5.5 4.3.3.5.6 4.3.3.5.7 4.3.3.5.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.1 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.3.2 4.3.4.3.3 SR 1.1 SR 1.10 SR 1.11 SR 1.12 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.6 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.2 SR 2.3 SR 2.4 SR 2.5 SR 2.6 SR 2.7 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 7.1 SR 7.6 A.11.2.6 A.12.1.2 A.12.5.1 A.12.6.2 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.2 A.14.2.3 A.14.2.4 A.6.2.1 A.6.2.2 A.9.1.2 CM-7(a) CM-7(b) CM-6(a) PR.AC-3 PR.IP-1 PR.PT-3 PR.PT-4 telnet allows clear text communications, and does not protect any data transmission between client and server. Any confidential data can be listened and no integrity checking is made.' NFS and RPC The Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to systems operating as NFS clients, as well as to those operating as NFS servers. Uninstall nfs-common Package The nfs-common package can be removed with the following command: $ apt-get remove nfs-common If the system does not export NFS shares or act as an NFS client, it is recommended that these services be removed to reduce the remote attack surface. Uninstall nfs-kernel-server Package The nfs-kernel-server package can be removed with the following command: $ apt-get remove nfs-kernel-server If the system does not export NFS shares or act as an NFS client, it is recommended that these services be removed to reduce the remote attack surface. Network Time Protocol The Network Time Protocol is used to manage the system clock over a network. Computer clocks are not very accurate, so time will drift unpredictably on unmanaged systems. Central time protocols can be used both to ensure that time is consistent among a network of systems, and that their time is consistent with the outside world. If every system on a network reliably reports the same time, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable. Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, using a public timeserver (or one provided by your enterprise) provides globally accurate timestamps which may be essential in investigating or responding to an attack which originated outside of your network. A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers. There is a choice between the daemons ntpd and chronyd, which are available from the repositories in the ntp and chrony packages respectively. The default chronyd daemon can work well when external time references are only intermittently accessible, can perform well even when the network is congested for longer periods of time, can usually synchronize the clock faster and with better time accuracy, and quickly adapts to sudden changes in the rate of the clock, for example, due to changes in the temperature of the crystal oscillator. Chronyd should be considered for all systems which are frequently suspended or otherwise intermittently disconnected and reconnected to a network. Mobile and virtual systems for example. The ntpd NTP daemon fully supports NTP protocol version 4 (RFC 5905), including broadcast, multicast, manycast clients and servers, and the orphan mode. It also supports extra authentication schemes based on public-key cryptography (RFC 5906). The NTP daemon (ntpd) should be considered for systems which are normally kept permanently on. Systems which are required to use broadcast or multicast IP, or to perform authentication of packets with the Autokey protocol, should consider using ntpd. Refer to https://en.wikipedia.org/wiki/Network_Time_Protocol for more detailed comparison of features of chronyd and ntpd daemon features respectively, and for further guidance how to choose between the two NTP daemons. The upstream manual pages at https://chrony-project.org/documentation.html for chronyd and http://www.ntp.org for ntpd provide additional information on the capabilities and configuration of each of the NTP daemons. Maximum NTP or Chrony Poll The maximum NTP or Chrony poll interval number in seconds specified as a power of two. 17 16 10 10 The Chrony package is installed System time should be synchronized between all systems in an environment. This is typically done by establishing an authoritative time server or set of servers and having all systems synchronize their clocks to them. The chrony package can be installed with the following command: $ apt-get install chrony FMT_SMF_EXT.1 Req-10.4 SRG-OS-000355-GPOS-00143 R71 0988 1405 10.6.1 10.6 Time synchronization is important to support time sensitive security mechanisms like Kerberos and also ensures log files have consistent time records across the enterprise, which aids in forensic investigations. Remove the ntp service The ntpd service should not be installed. Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Remove the systemd_timesyncd Service The systemd_timesyncd service should not be installed. Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Configure Time Service Maxpoll Interval The maxpoll should be configured to in /etc/ntp.conf or /etc/chrony/chrony.conf (or /etc/chrony/conf.d/) to continuously poll time servers. To configure maxpoll in /etc/ntp.conf or /etc/chrony/chrony.conf (or /etc/chrony/conf.d/) add the following after each server, pool or peer entry: maxpoll to server directives. If using chrony, any pool directives should be configured too. 1 14 15 16 3 5 6 APO11.04 BAI03.05 DSS05.04 DSS05.07 MEA02.01 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 CM-6(a) AU-8(1)(b) AU-12(1) PR.PT-1 SRG-OS-000355-GPOS-00143 SRG-OS-000356-GPOS-00144 SRG-OS-000359-GPOS-00146 Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). Synchronize internal information system clocks Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. SRG-OS-000356-GPOS-00144 Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Obsolete Services This section discusses a number of network-visible services which have historically caused problems for system security, and for which disabling or severely limiting the service has been the best available guidance for some time. As a result of this, many of these services are not installed as part of Claroty CTD 5.x by default. Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as iptables to restrict access to the vulnerable service to only those remote hosts which have a known need to use it. Rlogin, Rsh, and Rexec The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model. Uninstall rsh-server Package The rsh-server package can be removed with the following command: $ apt-get remove rsh-server 11 12 14 15 3 8 9 APO13.01 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS01.04 DSS05.02 DSS05.03 DSS05.05 DSS06.06 164.308(a)(4)(i) 164.308(b)(1) 164.308(b)(3) 164.310(b) 164.312(e)(1) 164.312(e)(2)(ii) 4.3.3.5.1 4.3.3.5.2 4.3.3.5.3 4.3.3.5.4 4.3.3.5.5 4.3.3.5.6 4.3.3.5.7 4.3.3.5.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.1 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.3.2 4.3.4.3.3 SR 1.1 SR 1.10 SR 1.11 SR 1.12 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.6 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.2 SR 2.3 SR 2.4 SR 2.5 SR 2.6 SR 2.7 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 7.1 SR 7.6 A.11.2.6 A.12.1.2 A.12.5.1 A.12.6.2 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.2 A.14.2.3 A.14.2.4 A.6.2.1 A.6.2.2 A.9.1.2 CM-7(a) CM-7(b) CM-6(a) IA-5(1)(c) PR.AC-3 PR.IP-1 PR.PT-3 PR.PT-4 SRG-OS-000095-GPOS-00049 R62 2.2.4 2.2 The rsh-server service provides unencrypted remote access service which does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication. If a privileged user were to login using this service, the privileged user password could be compromised. The rsh-server package provides several obsolete and insecure network services. Removing it decreases the risk of those services' accidental (or intentional) activation. SSH Server The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, https://www.openssh.com. Its server program is called sshd and provided by the RPM package openssh-server. SSH session Idle time Specify duration of allowed idle time. 600 7200 840 900 1800 300 3600 300 SSH Max Keep Alive Count Specify the maximum number of idle message counts before session is terminated. 10 3 5 0 1 0 Install the OpenSSH Server Package The openssh-server package should be installed. The openssh-server package can be installed with the following command: $ apt-get install openssh-server 13 14 APO01.06 DSS05.02 DSS05.04 DSS05.07 DSS06.02 DSS06.06 SR 3.1 SR 3.8 SR 4.1 SR 4.2 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CM-6(a) PR.DS-2 PR.DS-5 FIA_UAU.5 FTP_ITC_EXT.1 FCS_SSH_EXT.1 FCS_SSHS_EXT.1 SRG-OS-000423-GPOS-00187 SRG-OS-000424-GPOS-00188 SRG-OS-000425-GPOS-00189 SRG-OS-000426-GPOS-00190 Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered. Enable the OpenSSH Service The SSH server service, sshd, is commonly needed. The sshd service can be enabled with the following command: $ sudo systemctl enable sshd.service 13 14 APO01.06 DSS05.02 DSS05.04 DSS05.07 DSS06.02 DSS06.06 3.1.13 3.5.4 3.13.8 SR 3.1 SR 3.8 SR 4.1 SR 4.2 SR 5.2 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CM-6(a) SC-8 SC-8(1) SC-8(2) SC-8(3) SC-8(4) PR.DS-2 PR.DS-5 SRG-OS-000423-GPOS-00187 SRG-OS-000424-GPOS-00188 SRG-OS-000425-GPOS-00189 SRG-OS-000426-GPOS-00190 Without protection of the transmitted information, confidentiality, and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This checklist item applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, etc). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Configure OpenSSH Server if Necessary If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information. Set SSH Client Alive Count Max The SSH server sends at most ClientAliveCountMax messages during a SSH session and waits for a response from the SSH client. The option ClientAliveInterval configures timeout after each ClientAliveCountMax message. If the SSH server does not receive a response from the client, then the connection is considered unresponsive and terminated. For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when the ClientAliveInterval is set. Starting with v8.2, a value of 0 disables the timeout functionality completely. If the option is set to a number greater than 0, then the session will be disconnected after ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message. 1 12 13 14 15 16 18 3 5 7 8 5.5.6 APO13.01 BAI03.01 BAI03.02 BAI03.03 DSS01.03 DSS03.05 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 3.1.11 164.308(a)(4)(i) 164.308(b)(1) 164.308(b)(3) 164.310(b) 164.312(e)(1) 164.312(e)(2)(ii) 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.3.3 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 6.2 A.12.4.1 A.12.4.3 A.14.1.1 A.14.2.1 A.14.2.5 A.18.1.4 A.6.1.2 A.6.1.5 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CIP-004-6 R2.2.3 CIP-007-3 R5.1 CIP-007-3 R5.2 CIP-007-3 R5.3.1 CIP-007-3 R5.3.2 CIP-007-3 R5.3.3 AC-2(5) AC-12 AC-17(a) SC-10 CM-6(a) DE.CM-1 DE.CM-3 PR.AC-1 PR.AC-4 PR.AC-6 PR.AC-7 PR.IP-2 Req-8.1.8 SRG-OS-000163-GPOS-00072 SRG-OS-000279-GPOS-00109 8.2.8 8.2 This ensures a user login will be terminated as soon as the ClientAliveInterval is reached. Set SSH Client Alive Interval SSH allows administrators to set a network responsiveness timeout interval. After this interval has passed, the unresponsive client will be automatically logged out. To set this timeout interval, edit the following line in /etc/ssh/sshd_config as follows: ClientAliveInterval The timeout interval is given in seconds. For example, have a timeout of 10 minutes, set interval to 600. If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made in /etc/ssh/sshd_config. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle. SSH disconnecting unresponsive clients will not have desired effect without also configuring ClientAliveCountMax in the SSH service configuration. Following conditions may prevent the SSH session to time out: Remote processes on the remote machine generates output. As the output has to be transferred over the network to the client, the timeout is reset every time such transfer happens.Any scp or sftp activity by the same user to the host resets the timeout. 1 12 13 14 15 16 18 3 5 7 8 5.5.6 APO13.01 BAI03.01 BAI03.02 BAI03.03 DSS01.03 DSS03.05 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 3.1.11 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.3.3 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 6.2 A.12.4.1 A.12.4.3 A.14.1.1 A.14.2.1 A.14.2.5 A.18.1.4 A.6.1.2 A.6.1.5 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CIP-004-6 R2.2.3 CIP-007-3 R5.1 CIP-007-3 R5.2 CIP-007-3 R5.3.1 CIP-007-3 R5.3.2 CIP-007-3 R5.3.3 CM-6(a) AC-17(a) AC-2(5) AC-12 AC-17(a) SC-10 CM-6(a) DE.CM-1 DE.CM-3 PR.AC-1 PR.AC-4 PR.AC-6 PR.AC-7 PR.IP-2 Req-8.1.8 SRG-OS-000126-GPOS-00066 SRG-OS-000163-GPOS-00072 SRG-OS-000279-GPOS-00109 SRG-OS-000395-GPOS-00175 8.2.8 8.2 Terminating an idle ssh session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been let unattended. Disable SSH Access via Empty Passwords Disallow SSH login with empty passwords. The default SSH configuration disables logins with empty passwords. The appropriate configuration is used if no value is set for PermitEmptyPasswords. To explicitly disallow SSH login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: PermitEmptyPasswords no Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords. 11 12 13 14 15 16 18 3 5 9 5.5.6 APO01.06 BAI10.01 BAI10.02 BAI10.03 BAI10.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 DSS06.02 DSS06.03 DSS06.06 3.1.1 3.1.5 164.308(a)(4)(i) 164.308(b)(1) 164.308(b)(3) 164.310(b) 164.312(e)(1) 164.312(e)(2)(ii) 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.5.3 4.3.3.5.4 4.3.3.5.5 4.3.3.5.6 4.3.3.5.7 4.3.3.5.8 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.1 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.3.2 4.3.4.3.3 SR 1.1 SR 1.10 SR 1.11 SR 1.12 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.6 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.2 SR 2.3 SR 2.4 SR 2.5 SR 2.6 SR 2.7 SR 5.2 SR 7.6 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.12.1.2 A.12.5.1 A.12.6.2 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.14.2.2 A.14.2.3 A.14.2.4 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.1 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 AC-17(a) CM-7(a) CM-7(b) CM-6(a) PR.AC-4 PR.AC-6 PR.DS-5 PR.IP-1 PR.PT-3 FIA_UAU.1 Req-2.2.4 SRG-OS-000106-GPOS-00053 SRG-OS-000480-GPOS-00229 SRG-OS-000480-GPOS-00227 1546 2.2.6 2.2 Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. Disable X11 Forwarding The X11Forwarding parameter provides the ability to tunnel X11 traffic through the connection to enable remote graphic connections. SSH has the capability to encrypt remote X11 connections when SSH's X11Forwarding option is enabled. The default SSH configuration disables X11Forwarding. The appropriate configuration is used if no value is set for X11Forwarding. To explicitly disable X11 Forwarding, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: X11Forwarding no CM-6(b) SRG-OS-000480-GPOS-00227 0484 2.2.6 2.2 Disable X11 forwarding unless there is an operational requirement to use X11 applications directly. There is a small risk that the remote X11 servers of users who are logged in via SSH with X11 forwarding could be compromised by other users on the X11 server. Note that even if X11 forwarding is disabled, users can always install their own forwarders. Do Not Allow SSH Environment Options Ensure that users are not able to override environment variables of the SSH daemon. The default SSH configuration disables environment processing. The appropriate configuration is used if no value is set for PermitUserEnvironment. To explicitly disable Environment options, add or correct the following /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: PermitUserEnvironment no 11 3 9 5.5.6 BAI10.01 BAI10.02 BAI10.03 BAI10.05 3.1.12 164.308(a)(4)(i) 164.308(b)(1) 164.308(b)(3) 164.310(b) 164.312(e)(1) 164.312(e)(2)(ii) 4.3.4.3.2 4.3.4.3.3 SR 7.6 A.12.1.2 A.12.5.1 A.12.6.2 A.14.2.2 A.14.2.3 A.14.2.4 AC-17(a) CM-7(a) CM-7(b) CM-6(a) PR.IP-1 Req-2.2.4 SRG-OS-000480-GPOS-00229 1546 2.2.6 2.2 SSH environment options potentially allow users to bypass access restriction in some configurations. Enable PAM UsePAM Enables the Pluggable Authentication Module interface. If set to “yes” this will enable PAM authentication using ChallengeResponseAuthentication and PasswordAuthentication in addition to PAM account and session module processing for all authentication types. To enable PAM authentication, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: UsePAM yes SRG-OS-000125-GPOS-00065 2.2.6 2.2 When UsePAM is set to yes, PAM runs through account and session types properly. This is important if you want to restrict access to services based off of IP, time or other factors of the account. Additionally, you can make sure users inherit certain environment variables on login or disallow access to the server. Enable Public Key Authentication Enable SSH login with public keys. The default SSH configuration enables authentication based on public keys. The appropriate configuration is used if no value is set for PubkeyAuthentication. To explicitly enable Public Key Authentication, add or correct the following /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: PubkeyAuthentication yes SRG-OS-000105-GPOS-00052 SRG-OS-000106-GPOS-00053 SRG-OS-000107-GPOS-00054 SRG-OS-000108-GPOS-00055 Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. Smart cards or hardware tokens paired with digital certificates are common examples of multifactor implementations. Enable SSH Warning Banner To enable the warning banner and ensure it is consistent across the system, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: Banner /etc/issue.net Another section contains information on how to create an appropriate system-wide warning banner. 5.5.6 DSS05.04 DSS05.10 DSS06.10 3.1.9 164.308(a)(4)(i) 164.308(b)(1) 164.308(b)(3) 164.310(b) 164.312(e)(1) 164.312(e)(2)(ii) 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 SR 1.1 SR 1.10 SR 1.2 SR 1.5 SR 1.7 SR 1.8 SR 1.9 A.18.1.4 A.9.2.1 A.9.2.4 A.9.3.1 A.9.4.2 A.9.4.3 AC-8(a) AC-8(c) AC-17(a) CM-6(a) PR.AC-7 SRG-OS-000023-GPOS-00006 SRG-OS-000228-GPOS-00088 The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution. Use Only FIPS 140-2 Validated Ciphers Limit the ciphers to those algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers: Ciphers aes256-ctr,aes192-ctr,aes128-ctr This rule ensures that there are configured ciphers mentioned above (or their subset), keeping the given order of algorithms. The system needs to be rebooted for these changes to take effect. System Crypto Modules must be provided by a vendor that undergoes FIPS-140 certifications. FIPS-140 is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf To meet this, the system has to have cryptographic software provided by a vendor that has undergone this certification. This means providing documentation, test results, design information, and independent third party review by an accredited lab. While open source software is capable of meeting this, it does not meet FIPS-140 unless the vendor submits to this process. SRG-OS-000033-GPOS-00014 SRG-OS-000120-GPOS-00061 SRG-OS-000125-GPOS-00065 SRG-OS-000250-GPOS-00093 SRG-OS-000393-GPOS-00173 SRG-OS-000394-GPOS-00174 Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and system data may be compromised. Operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets industry and government requirements. For government systems, this allows Security Levels 1, 2, 3, or 4 for use on Claroty CTD 5.x. Use Only FIPS 140-2 Validated Key Exchange Algorithms Limit the key exchange algorithms to those which are FIPS-approved. Add or modify the following line in This rule ensures that only the key exchange algorithms mentioned above (or their subset) are configured for use, keeping the given order of algorithms. The system needs to be rebooted for these changes to take effect. System crypto modules must be provided by a vendor that undergoes FIPS-140 certifications. FIPS-140 is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf To meet this requirements, the system has to have cryptographic software provided by a vendor that has undergone this certification. This means providing documentation, test results, design information, and independent third party review by an accredited lab. While open source software is capable of meeting this, it does not meet FIPS-140 unless the vendor submits to this process. AC-17(2) SRG-OS-000250-GPOS-00093 FIPS-approved key exchange algorithms are required to be used. The system will attempt to use the first algorithm presented by the client that matches the server list. Listing the values "strongest to weakest" is a method to ensure the use of the strongest algorithm available to secure the SSH connection. Use Only FIPS 140-2 Validated MACs Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs: MACs hmac-sha2-512,hmac-sha2-256 This rule ensures that there are configured MACs mentioned above (or their subset), keeping the given order of algorithms. The system needs to be rebooted for these changes to take effect. System Crypto Modules must be provided by a vendor that undergoes FIPS-140 certifications. FIPS-140 is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf To meet this, the system has to have cryptographic software provided by a vendor that has undergone this certification. This means providing documentation, test results, design information, and independent third party review by an accredited lab. While open source software is capable of meeting this, it does not meet FIPS-140 unless the vendor submits to this process. SRG-OS-000125-GPOS-00065 SRG-OS-000250-GPOS-00093 SRG-OS-000394-GPOS-00174 FIPS-approved cryptographic hash functions are required to be used. The only SSHv2 hash algorithms meeting this requirement is SHA2. Prevent remote hosts from connecting to the proxy display The SSH daemon should prevent remote hosts from connecting to the proxy display. The default SSH configuration for X11UseLocalhost is yes, which prevents remote hosts from connecting to the proxy display. To explicitly prevent remote connections to the proxy display, add or correct the following line in /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf: X11UseLocalhost yes CM-6(b) SRG-OS-000480-GPOS-00227 When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display. System Security Services Daemon The System Security Services Daemon (SSSD) is a system daemon that provides access to different identity and authentication providers such as Red Hat's IdM, Microsoft's AD, openLDAP, MIT Kerberos, etc. It uses a common framework that can provide caching and offline support to systems utilizing SSSD. SSSD using caching to reduce load on authentication servers permit offline authentication as well as store extended user data. For more information, see Install the SSSD Package The sssd package should be installed. The sssd package can be installed with the following command: $ apt-get install sssd 1 12 15 16 5 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 CM-6(a) PR.AC-1 PR.AC-6 PR.AC-7 SRG-OS-000375-GPOS-00160 R67 Enable the SSSD Service The SSSD service should be enabled. The sssd service can be enabled with the following command: $ sudo systemctl enable sssd.service The service requires a valid sssd configuration. If the configuration is not present, the service will fail to start and consequently this rule will be reported as failing. The configuration shipped in your distribution package might not be sufficient. Manual modification of configuration files might be required. 1 12 15 16 5 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 CM-6(a) IA-5(10) PR.AC-1 PR.AC-6 PR.AC-7 SRG-OS-000375-GPOS-00160 R67 Certificate trust path in SSSD Enable certification trust path for SSSD to an accepted trust anchor. Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. Configure PAM in SSSD Services SSSD should be configured to run SSSD pam services. To configure SSSD to known SSH hosts, add pam to services under the [sssd] section in /etc/sssd/sssd.conf. For example: [sssd] services = sudo, autofs, pam 1 12 15 16 5 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 IA-2(1) CM-6(a) PR.AC-1 PR.AC-6 PR.AC-7 SRG-OS-000375-GPOS-00160 SRG-OS-000376-GPOS-00161 SRG-OS-000377-GPOS-00162 R67 Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Enable Smartcards in SSSD SSSD should be configured to authenticate access to the system using smart cards. To enable smart cards in SSSD, set pam_cert_auth to True under the [pam] section in /etc/sssd/sssd.conf. For example: [pam] pam_cert_auth = True Req-8.3 SRG-OS-000375-GPOS-00160 SRG-OS-000105-GPOS-00052 SRG-OS-000106-GPOS-00053 SRG-OS-000107-GPOS-00054 SRG-OS-000108-GPOS-00055 0421 0422 0974 1173 1401 1504 1505 1546 1557 1558 1559 1560 1561 Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multi-Factor Authentication (MFA) solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards or similar secure authentication devices issued by an organization or identity provider. Enable Certificates Mapping in SSSD SSSD needs to be set up to link the authenticated identity to the user or group account for PKI-based authentication. To implement this, confirm that the /etc/sssd/sssd.conf file contains the following line ldap_user_certificate=userCertificate;binary Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. Configure SSSD to Expire Offline Credentials SSSD should be configured to expire offline credentials after 1 day. To configure SSSD to expire offline credentials, set offline_credentials_expiration to 1 under the [pam] section in /etc/sssd/sssd.conf. For example: [pam] offline_credentials_expiration = 1 1 12 15 16 5 DSS05.04 DSS05.05 DSS05.07 DSS05.10 DSS06.03 DSS06.10 4.3.3.2.2 4.3.3.5.1 4.3.3.5.2 4.3.3.6.1 4.3.3.6.2 4.3.3.6.3 4.3.3.6.4 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.3.6.9 4.3.3.7.2 4.3.3.7.4 SR 1.1 SR 1.10 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 A.18.1.4 A.7.1.1 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.2 A.9.4.3 CM-6(a) IA-5(13) PR.AC-1 PR.AC-6 PR.AC-7 SRG-OS-000383-GPOS-00166 If cached authentication information is out-of-date, the validity of the authentication information may be questionable. System Accounting with auditd The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, auditd has modest disk space requirements, and should not noticeably impact system performance. NOTE: The Linux Audit daemon auditd can be configured to use the augenrules program to read audit rules files (*.rules) located in /etc/audit/rules.d location and compile them to create the resulting form of the /etc/audit/audit.rules configuration file during the daemon startup (default configuration). Alternatively, the auditd daemon can use the auditctl utility to read audit rules from the /etc/audit/audit.rules configuration file during daemon startup, and load them into the kernel. The expected behavior is configured via the appropriate ExecStartPost directive setting in the /usr/lib/systemd/system/auditd.service configuration file. To instruct the auditd daemon to use the augenrules program to read audit rules (default configuration), use the following setting: ExecStartPost=-/sbin/augenrules --load in the /usr/lib/systemd/system/auditd.service configuration file. In order to instruct the auditd daemon to use the auditctl utility to read audit rules, use the following setting: ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules in the /usr/lib/systemd/system/auditd.service configuration file. Refer to [Service] section of the /usr/lib/systemd/system/auditd.service configuration file for further details. Government networks often have substantial auditing requirements and auditd can be configured to meet these requirements. Examining some example audit records demonstrates how the Linux audit system satisfies common requirements. The following example from Red Hat Enterprise Linux 7 Documentation available at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/selinux_users_and_administrators_guide/index#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages shows the substantial amount of information captured in a two typical "raw" audit messages, followed by a breakdown of the most important fields. In this example the message is SELinux-related and reports an AVC denial (and the associated system call) that occurred when the Apache HTTP Server attempted to access the /var/www/html/file1 file (labeled with the samba_share_t type): type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null) msg=audit(1226874073.147:96)The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command. { getattr }The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.comm="httpd"The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd". path="/var/www/html/file1"The path to the object (target) the process attempted to access. scontext="unconfined_u:system_r:httpd_t:s0"The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain. tcontext="unconfined_u:object_r:samba_share_t:s0"The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain. From the system call (SYSCALL) message, two items are of interest: success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t. exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd". Ensure the default plugins for the audit dispatcher are Installed The audit-audispd-plugins package should be installed. 164.308(a)(1)(ii)(D) 164.308(a)(5)(ii)(C) 164.310(a)(2)(iv) 164.310(d)(2)(iii) 164.312(b) Req-10.5.3 SRG-OS-000342-GPOS-00133 10.3.3 10.3 Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. Ensure the audit Subsystem is Installed The audit package should be installed. 164.308(a)(1)(ii)(D) 164.308(a)(5)(ii)(C) 164.310(a)(2)(iv) 164.310(d)(2)(iii) 164.312(b) CIP-004-6 R3.3 CIP-007-3 R6.5 AC-7(a) AU-7(1) AU-7(2) AU-14 AU-12(2) AU-2(a) CM-6(a) FAU_GEN.1 Req-10.1 SRG-OS-000062-GPOS-00031 SRG-OS-000037-GPOS-00015 SRG-OS-000038-GPOS-00016 SRG-OS-000039-GPOS-00017 SRG-OS-000040-GPOS-00018 SRG-OS-000041-GPOS-00019 SRG-OS-000042-GPOS-00021 SRG-OS-000051-GPOS-00024 SRG-OS-000054-GPOS-00025 SRG-OS-000122-GPOS-00063 SRG-OS-000254-GPOS-00095 SRG-OS-000255-GPOS-00096 SRG-OS-000337-GPOS-00129 SRG-OS-000348-GPOS-00136 SRG-OS-000349-GPOS-00137 SRG-OS-000350-GPOS-00138 SRG-OS-000351-GPOS-00139 SRG-OS-000352-GPOS-00140 SRG-OS-000353-GPOS-00141 SRG-OS-000354-GPOS-00142 SRG-OS-000358-GPOS-00145 SRG-OS-000365-GPOS-00152 SRG-OS-000392-GPOS-00172 SRG-OS-000475-GPOS-00220 R33 R73 0582 0846 10.2.1 10.2 The auditd service is an access monitoring and accounting daemon, watching system calls to audit any access, in comparison with potential local access control policy such as SELinux policy. Enable auditd Service The auditd service is an essential userspace component of the Linux Auditing System, as it is responsible for writing audit records to disk. The auditd service can be enabled with the following command: $ sudo systemctl enable auditd.service 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.3.1 3.3.2 3.3.6 164.308(a)(1)(ii)(D) 164.308(a)(5)(ii)(C) 164.310(a)(2)(iv) 164.310(d)(2)(iii) 164.312(b) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 CIP-004-6 R3.3 CIP-007-3 R6.5 AC-2(g) AU-3 AU-10 AU-2(d) AU-12(c) AU-14(1) AC-6(9) CM-6(a) SI-4(23) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 FAU_GEN.1 Req-10.1 SRG-OS-000062-GPOS-00031 SRG-OS-000037-GPOS-00015 SRG-OS-000038-GPOS-00016 SRG-OS-000039-GPOS-00017 SRG-OS-000040-GPOS-00018 SRG-OS-000041-GPOS-00019 SRG-OS-000042-GPOS-00021 SRG-OS-000051-GPOS-00024 SRG-OS-000054-GPOS-00025 SRG-OS-000122-GPOS-00063 SRG-OS-000254-GPOS-00095 SRG-OS-000255-GPOS-00096 SRG-OS-000337-GPOS-00129 SRG-OS-000348-GPOS-00136 SRG-OS-000349-GPOS-00137 SRG-OS-000350-GPOS-00138 SRG-OS-000351-GPOS-00139 SRG-OS-000352-GPOS-00140 SRG-OS-000353-GPOS-00141 SRG-OS-000354-GPOS-00142 SRG-OS-000358-GPOS-00145 SRG-OS-000365-GPOS-00152 SRG-OS-000392-GPOS-00172 SRG-OS-000475-GPOS-00220 SRG-APP-000095-CTR-000170 SRG-APP-000409-CTR-000990 SRG-APP-000508-CTR-001300 SRG-APP-000510-CTR-001310 R33 R73 1409 10.2.1 10.2 Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Ensuring the auditd service is active ensures audit records generated by the kernel are appropriately recorded. Additionally, a properly configured audit subsystem ensures that actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. Enable Auditing for Processes Which Start Prior to the Audit Daemon To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the default GRUB 2 command line for the Linux operating system. Configure the default Grub2 kernel command line to contain audit=1 as follows: # grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) audit=1" 1 11 12 13 14 15 16 19 3 4 5 6 7 8 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS05.02 DSS05.03 DSS05.04 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.3.1 164.308(a)(1)(ii)(D) 164.308(a)(5)(ii)(C) 164.310(a)(2)(iv) 164.310(d)(2)(iii) 164.312(b) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AC-17(1) AU-14(1) AU-10 CM-6(a) IR-5(1) DE.AE-3 DE.AE-5 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 FAU_GEN.1 Req-10.3 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000473-GPOS-00218 SRG-OS-000254-GPOS-00095 10.7.2 10.7 Each process on the system carries an "auditable" flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot. Configure auditd Rules for Comprehensive Auditing The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system's capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system. The audit subsystem supports extensive collection of events, including: Tracing of arbitrary system calls (identified by name or number) on entry or exit.Filtering by PID, UID, call success, system call argument (with some limitations), etc.Monitoring of specific files for modifications to the file's contents or metadata. Auditing rules at startup are controlled by the file /etc/audit/audit.rules. Add rules to it to meet the auditing requirements for your organization. Each line in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested during runtime. See documentation in /usr/share/doc/audit-VERSION and in the related man pages for more details. If copying any example audit rulesets from /usr/share/doc/audit-VERSION, be sure to comment out the lines containing arch= which are not appropriate for your system's architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture. After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows: $ sudo service auditd restart Ensure auditd Collects Changes to Cron Jobs - /etc/cron.d/ At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/cron.d/ -p wa -k cronjobs If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /etc/cron.d/ -p wa -k cronjobs SRG-OS-000471-GPOS-00215 The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. Record Attempts to Alter Process and Session Initiation Information btmp The audit system already collects process information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /var/log/btmp -p wa -k session If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /var/log/btmp -p wa -k session 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) AU-12(c) AU-12.1(iv) SRG-OS-000472-GPOS-00217 R73 0582 0846 10.2.1.3 10.2.1 10.2 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Record Attempts to Alter Process and Session Initiation Information utmp The audit system already collects process information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /var/run/utmp -p wa -k session If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /var/run/utmp -p wa -k session 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) AU-12(c) AU-12.1(iv) SRG-OS-000472-GPOS-00217 R73 0582 0846 10.2.1.3 10.2.1 10.2 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Record Attempts to Alter Process and Session Initiation Information wtmp The audit system already collects process information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /var/log/wtmp -p wa -k session If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /var/log/wtmp -p wa -k session 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) AU-12(c) AU-12.1(iv) SRG-OS-000472-GPOS-00217 R73 0582 0846 10.2.1.3 10.2.1 10.2 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Ensure auditd Collects System Administrator Actions - /etc/sudoers At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/sudoers -p wa -k actions If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /etc/sudoers -p wa -k actions SRG-OS-000004-GPOS-00004 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000304-GPOS-00121 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000470-GPOS-00214 SRG-OS-000471-GPOS-00215 SRG-OS-000239-GPOS-00089 SRG-OS-000240-GPOS-00090 SRG-OS-000241-GPOS-00091 SRG-OS-000303-GPOS-00120 SRG-OS-000466-GPOS-00210 SRG-OS-000476-GPOS-00221 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000503-CTR-001275 The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/ At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/sudoers.d/ -p wa -k actions If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /etc/sudoers.d/ -p wa -k actions SRG-OS-000004-GPOS-00004 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000304-GPOS-00121 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000470-GPOS-00214 SRG-OS-000471-GPOS-00215 SRG-OS-000239-GPOS-00089 SRG-OS-000240-GPOS-00090 SRG-OS-000241-GPOS-00091 SRG-OS-000303-GPOS-00120 SRG-OS-000466-GPOS-00210 SRG-OS-000476-GPOS-00221 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000503-CTR-001275 The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. Editing the sudoers file may be sign of an attacker trying to establish persistent methods to a system, auditing the editing of the sudoers files mitigates this risk. Record Events When Privileged Executables Are Run Verify the system generates an audit record when privileged functions are executed. If audit is using the "auditctl" tool to load the rules, run the following command: $ sudo grep execve /etc/audit/audit.rules If audit is using the "augenrules" tool to load the rules, run the following command: $ sudo grep -r execve /etc/audit/rules.d -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid If both the "b32" and "b64" audit rules for "SUID" files are not defined, this is a finding. If both the "b32" and "b64" audit rules for "SGID" files are not defined, this is a finding. Note that these rules can be configured in a number of ways while still achieving the desired effect. CM-5(1) AU-7(a) AU-7(b) AU-8(b) AU-12(3) AC-6(9) SRG-OS-000326-GPOS-00126 SRG-OS-000327-GPOS-00127 SRG-APP-000343-CTR-000780 SRG-APP-000381-CTR-000905 SRG-OS-000755-GPOS-00220 10.2.1.2 10.2.1 10.2 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. Record Events that Modify User/Group Information - /etc/group If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/group -p wa -k audit_rules_usergroup_modification If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /etc/group -p wa -k audit_rules_usergroup_modification 1 11 12 13 14 15 16 18 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 DSS06.03 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.2.2 4.3.3.3.9 4.3.3.5.1 4.3.3.5.2 4.3.3.5.8 4.3.3.6.6 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.1 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.1.2 A.6.2.1 A.6.2.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-1 PR.AC-3 PR.AC-4 PR.AC-6 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.5 SRG-OS-000004-GPOS-00004 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000304-GPOS-00121 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000470-GPOS-00214 SRG-OS-000471-GPOS-00215 SRG-OS-000239-GPOS-00089 SRG-OS-000240-GPOS-00090 SRG-OS-000241-GPOS-00091 SRG-OS-000303-GPOS-00120 SRG-OS-000466-GPOS-00210 SRG-OS-000476-GPOS-00221 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000503-CTR-001275 R73 0582 10.2.1.5 10.2.1 10.2 In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Record Events that Modify User/Group Information - /etc/gshadow If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/gshadow -p wa -k audit_rules_usergroup_modification If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /etc/gshadow -p wa -k audit_rules_usergroup_modification 1 11 12 13 14 15 16 18 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 DSS06.03 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.2.2 4.3.3.3.9 4.3.3.5.1 4.3.3.5.2 4.3.3.5.8 4.3.3.6.6 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.1 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.1.2 A.6.2.1 A.6.2.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-1 PR.AC-3 PR.AC-4 PR.AC-6 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.5 SRG-OS-000004-GPOS-00004 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000304-GPOS-00121 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000470-GPOS-00214 SRG-OS-000471-GPOS-00215 SRG-OS-000239-GPOS-00089 SRG-OS-000240-GPOS-00090 SRG-OS-000241-GPOS-00091 SRG-OS-000303-GPOS-00120 SRG-OS-000466-GPOS-00210 SRG-OS-000476-GPOS-00221 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000503-CTR-001275 R73 0582 10.2.1.5 10.2.1 10.2 In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Record Events that Modify User/Group Information - /etc/security/opasswd If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification 1 11 12 13 14 15 16 18 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 DSS06.03 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.2.2 4.3.3.3.9 4.3.3.5.1 4.3.3.5.2 4.3.3.5.8 4.3.3.6.6 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.1 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.1.2 A.6.2.1 A.6.2.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-1 PR.AC-3 PR.AC-4 PR.AC-6 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.5 SRG-OS-000004-GPOS-00004 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000304-GPOS-00121 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000470-GPOS-00214 SRG-OS-000471-GPOS-00215 SRG-OS-000239-GPOS-00089 SRG-OS-000240-GPOS-00090 SRG-OS-000241-GPOS-00091 SRG-OS-000303-GPOS-00120 SRG-OS-000466-GPOS-00210 SRG-OS-000476-GPOS-00221 SRG-APP-000495-CTR-001235 SRG-APP-000496-CTR-001240 SRG-APP-000497-CTR-001245 SRG-APP-000498-CTR-001250 SRG-APP-000503-CTR-001275 R73 0582 10.2.1.5 10.2.1 10.2 In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Record Events that Modify User/Group Information - /etc/passwd If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/passwd -p wa -k audit_rules_usergroup_modification If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /etc/passwd -p wa -k audit_rules_usergroup_modification 1 11 12 13 14 15 16 18 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 DSS06.03 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.2.2 4.3.3.3.9 4.3.3.5.1 4.3.3.5.2 4.3.3.5.8 4.3.3.6.6 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.1 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.1.2 A.6.2.1 A.6.2.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-1 PR.AC-3 PR.AC-4 PR.AC-6 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.5 SRG-OS-000004-GPOS-00004 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000304-GPOS-00121 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000470-GPOS-00214 SRG-OS-000471-GPOS-00215 SRG-OS-000239-GPOS-00089 SRG-OS-000240-GPOS-00090 SRG-OS-000241-GPOS-00091 SRG-OS-000303-GPOS-00120 SRG-OS-000304-GPOS-00121 SRG-OS-000466-GPOS-00210 SRG-OS-000476-GPOS-00221 SRG-OS-000274-GPOS-00104 SRG-OS-000275-GPOS-00105 SRG-OS-000276-GPOS-00106 SRG-OS-000277-GPOS-00107 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000503-CTR-001275 R73 0582 10.2.1.5 10.2.1 10.2 In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Record Events that Modify User/Group Information - /etc/shadow If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/shadow -p wa -k audit_rules_usergroup_modification If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /etc/shadow -p wa -k audit_rules_usergroup_modification 1 11 12 13 14 15 16 18 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 DSS06.03 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.2.2 4.3.3.3.9 4.3.3.5.1 4.3.3.5.2 4.3.3.5.8 4.3.3.6.6 4.3.3.7.2 4.3.3.7.3 4.3.3.7.4 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.1 SR 1.13 SR 1.2 SR 1.3 SR 1.4 SR 1.5 SR 1.7 SR 1.8 SR 1.9 SR 2.1 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.1.2 A.6.2.1 A.6.2.2 A.7.1.1 A.9.1.2 A.9.2.1 A.9.2.2 A.9.2.3 A.9.2.4 A.9.2.6 A.9.3.1 A.9.4.1 A.9.4.2 A.9.4.3 A.9.4.4 A.9.4.5 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-1 PR.AC-3 PR.AC-4 PR.AC-6 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.5 SRG-OS-000004-GPOS-00004 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000304-GPOS-00121 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000470-GPOS-00214 SRG-OS-000471-GPOS-00215 SRG-OS-000239-GPOS-00089 SRG-OS-000240-GPOS-00090 SRG-OS-000241-GPOS-00091 SRG-OS-000303-GPOS-00120 SRG-OS-000466-GPOS-00210 SRG-OS-000476-GPOS-00221 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000503-CTR-001275 R73 0582 10.2.1.5 10.2.1 10.2 In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Ensure auditd Collects records for events that affect "/var/log/journal" Auditing the systemd journal files provides logging that can be used for forensic purposes. Verify the system generates audit records for all events that affect "/var/log/journal" by using the following command: $ sudo auditctl -l | grep journal -w /var/log/journal/ -p wa -k systemd_journal If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" value is arbitrary and can be different from the example output above. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /var/log/journal -p wa -k systemd_journal If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /var/log/journal -p wa -k systemd_journal Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to modify system level binaries and their operation. Auditing the systemd journal files provides logging that can be used for forensic purposes. Ensure auditd Collects Changes to Cron Jobs - /var/spool/cron If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /var/spool/cron -p wa -k cronjobs If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /var/spool/cron -p wa -k cronjobs SRG-OS-000363-GPOS-00150 SRG-OS-000363-GPOS-00150 SRG-OS-000446-GPOS-00200 SRG-OS-000447-GPOS-00201 In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. Record Attempts to perform maintenance activities The Claroty CTD 5.x operating system must generate audit records for privileged activities, nonlocal maintenance, diagnostic sessions and other system-level access. Verify the operating system audits activities performed during nonlocal maintenance and diagnostic sessions. Run the following command: $ sudo auditctl -l | grep sudo.log -w /var/log/sudo.log -p wa -k maintenance If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /var/log/sudo.log -p wa -k maintenance If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /var/log/sudo.log -p wa -k maintenance Req-10.2.2 Req-10.2.5.b SRG-OS-000392-GPOS-00172 SRG-OS-000471-GPOS-00215 R73 10.2.1.3 10.2.1 10.2 If events associated with nonlocal administrative access or diagnostic sessions are not logged, a major tool for assessing and investigating attacks would not be available. This requirement addresses auditing-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system, for example, the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch. System Audit Logs Must Have Mode 0750 or Less Permissive Verify the audit log directories have a mode of "0750" or less permissive by first determining where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log By default, the audit log directory is /var/log/audit. Configure the audit log directory to be protected from unauthorized read access by setting the correct permissive mode. The appropriate directory permissions depend on the log_group setting in /etc/audit/auditd.conf: If log_group is set to root or is not set, the directory should have mode 0700. This restricts access to root only, which is the most secure configuration.If log_group is set to a group other than root, the directory should have mode 0750. This is necessary because when log_group is set to a non-root group, the audit log files are typically configured with mode 0640 (allowing group read access). For group members to access these files, they need execute permission on the directory to traverse it. The 0750 mode allows root full access and the specified group read and execute access, while preventing others from accessing the directory. If log_group is set to a group other than root, change the mode of the audit log directory with the following command: $ sudo chmod 0750 audit_log_directory Otherwise, change the mode of the audit log directory with the following command: $ sudo chmod 0700 audit_log_directory Replace audit_log_directory with the correct audit log directory path. 1 11 12 13 14 15 16 18 19 3 4 5 6 7 8 APO01.06 APO11.04 APO12.06 BAI03.05 BAI08.02 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS05.04 DSS05.07 DSS06.02 MEA02.01 4.2.3.10 4.3.3.3.9 4.3.3.5.8 4.3.3.7.3 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.1 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 5.2 SR 6.1 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.16.1.4 A.16.1.5 A.16.1.7 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CIP-003-8 R5.1.1 CIP-003-8 R5.2 CIP-003-8 R5.3 CIP-004-6 R2.3 CIP-004-6 R3.3 CIP-007-3 R2.1 CIP-007-3 R2.2 CIP-007-3 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.1 CIP-007-3 R5.1.2 CIP-007-3 R6.5 CM-6(a) AC-6(1) AU-9 DE.AE-3 DE.AE-5 PR.AC-4 PR.DS-5 PR.PT-1 RS.AN-1 RS.AN-4 SRG-OS-000057-GPOS-00027 SRG-OS-000058-GPOS-00028 SRG-OS-000059-GPOS-00029 If users can write to audit logs, audit trails can be modified or destroyed. System Audit Logs Must Be Group Owned By Root All audit logs must be group owned by root user. Determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, determine if the audit log files are owned by the "root" group by using the following command: $ sudo stat -c "%n %G" /var/log/audit/* /var/log/audit/audit.log root If the audit log files are owned by a group other than "root", this is a finding. To remediate, configure the audit log directory and its underlying files to be owned by "root" group. Set the "log_group" parameter of the audit configuration file to the "root" value so when a new log file is created, its group owner is properly set: $ sudo sed -i '/^log_group/D' /etc/audit/auditd.conf $ sudo sed -i /^log_file/a'log_group = root' /etc/audit/auditd.conf Last, signal the audit daemon to reload the configuration file to update the group owners of existing files: $ sudo systemctl kill auditd -s SIGHUP SRG-OS-000057-GPOS-00027 SRG-OS-000058-GPOS-00028 SRG-OS-000059-GPOS-00029 SRG-OS-000206-GPOS-00084 Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit Configuration Files Must Be Owned By Group root All audit configuration files must be owned by group root. chown :root /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/* SRG-OS-000063-GPOS-00032 Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit Configuration Files Must Be Owned By Root All audit configuration files must be owned by root user. To properly set the owner of /etc/audit/, run the command: $ sudo chown root /etc/audit/ To properly set the owner of /etc/audit/rules.d/, run the command: $ sudo chown root /etc/audit/rules.d/ SRG-OS-000063-GPOS-00032 Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. System Audit Logs Must Be Owned By Root All audit logs must be owned by root user. The path for audit log can be configured via log_file parameter in /etc/audit/auditd.conf or by default, the path for audit log is /var/log/audit/. To properly set the owner of /var/log/audit/*, run the command: $ sudo chown root /var/log/audit/* 1 11 12 13 14 15 16 18 19 3 4 5 6 7 8 5.4.1.1 APO01.06 APO11.04 APO12.06 BAI03.05 BAI08.02 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS05.04 DSS05.07 DSS06.02 MEA02.01 3.3.1 4.2.3.10 4.3.3.3.9 4.3.3.5.8 4.3.3.7.3 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.1 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 5.2 SR 6.1 A.10.1.1 A.11.1.4 A.11.1.5 A.11.2.1 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.1.3 A.13.2.1 A.13.2.3 A.13.2.4 A.14.1.2 A.14.1.3 A.16.1.4 A.16.1.5 A.16.1.7 A.6.1.2 A.7.1.1 A.7.1.2 A.7.3.1 A.8.2.2 A.8.2.3 A.9.1.1 A.9.1.2 A.9.2.3 A.9.4.1 A.9.4.4 A.9.4.5 CM-6(a) AC-6(1) AU-9(4) DE.AE-3 DE.AE-5 PR.AC-4 PR.DS-5 PR.PT-1 RS.AN-1 RS.AN-4 Req-10.5.1 SRG-OS-000057-GPOS-00027 SRG-OS-000058-GPOS-00028 SRG-OS-000059-GPOS-00029 SRG-OS-000206-GPOS-00084 Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. System Audit Logs Must Have Mode 0600 or Less Permissive Determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, determine if the audit log files have a mode of "600" or less by using the following command: $ sudo stat -c "%n %a" /var/log/audit/* SRG-OS-000057-GPOS-00027 SRG-OS-000058-GPOS-00028 If users can write to audit logs, audit trails can be modified or destroyed. Record Events that Modify the System's Discretionary Access Controls At a minimum, the audit system should collect file permission changes for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -F key=perm_mod -a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -F key=perm_mod -a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod Record Events that Modify the System's Discretionary Access Controls - chmod At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000466-GPOS-00210 SRG-OS-000458-GPOS-00203 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 R73 0582 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - chown At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000466-GPOS-00210 SRG-OS-000458-GPOS-00203 SRG-OS-000474-GPOS-00219 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 R73 0582 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - fchmod At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000466-GPOS-00210 SRG-OS-000458-GPOS-00203 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - fchmodat At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000466-GPOS-00210 SRG-OS-000458-GPOS-00203 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - fchown At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000466-GPOS-00210 SRG-OS-000458-GPOS-00203 SRG-OS-000474-GPOS-00219 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - fchownat At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000466-GPOS-00210 SRG-OS-000458-GPOS-00203 SRG-OS-000474-GPOS-00219 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - fremovexattr At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000458-GPOS-00203 SRG-OS-000462-GPOS-00206 SRG-OS-000463-GPOS-00207 SRG-OS-000471-GPOS-00215 SRG-OS-000474-GPOS-00219 SRG-OS-000466-GPOS-00210 SRG-OS-000468-GPOS-00212 SRG-OS-000064-GPOS-00033 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000496-CTR-001240 SRG-APP-000497-CTR-001245 SRG-APP-000498-CTR-001250 SRG-APP-000499-CTR-001255 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - fsetxattr At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000458-GPOS-00203 SRG-OS-000462-GPOS-00206 SRG-OS-000463-GPOS-00207 SRG-OS-000466-GPOS-00210 SRG-OS-000468-GPOS-00212 SRG-OS-000471-GPOS-00215 SRG-OS-000474-GPOS-00219 SRG-OS-000064-GPOS-00033 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000496-CTR-001240 SRG-APP-000497-CTR-001245 SRG-APP-000498-CTR-001250 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - lchown At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000466-GPOS-00210 SRG-OS-000458-GPOS-00203 SRG-OS-000474-GPOS-00219 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - lremovexattr At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000458-GPOS-00203 SRG-OS-000462-GPOS-00206 SRG-OS-000463-GPOS-00207 SRG-OS-000468-GPOS-00212 SRG-OS-000471-GPOS-00215 SRG-OS-000474-GPOS-00219 SRG-OS-000466-GPOS-00210 SRG-OS-000064-GPOS-00033 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000496-CTR-001240 SRG-APP-000497-CTR-001245 SRG-APP-000498-CTR-001250 SRG-APP-000499-CTR-001255 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - lsetxattr At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000458-GPOS-00203 SRG-OS-000462-GPOS-00206 SRG-OS-000463-GPOS-00207 SRG-OS-000466-GPOS-00210 SRG-OS-000468-GPOS-00212 SRG-OS-000471-GPOS-00215 SRG-OS-000474-GPOS-00219 SRG-OS-000064-GPOS-00033 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000496-CTR-001240 SRG-APP-000497-CTR-001245 SRG-APP-000498-CTR-001250 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - removexattr At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000458-GPOS-00203 SRG-OS-000462-GPOS-00206 SRG-OS-000463-GPOS-00207 SRG-OS-000468-GPOS-00212 SRG-OS-000471-GPOS-00215 SRG-OS-000474-GPOS-00219 SRG-OS-000466-GPOS-00210 SRG-OS-000064-GPOS-00033 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 SRG-APP-000496-CTR-001240 SRG-APP-000497-CTR-001245 SRG-APP-000498-CTR-001250 SRG-APP-000499-CTR-001255 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Events that Modify the System's Discretionary Access Controls - setxattr At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod If the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 5.4.1.1 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.5.5 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000466-GPOS-00210 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000458-GPOS-00203 SRG-APP-000091-CTR-000160 SRG-APP-000492-CTR-001220 SRG-APP-000493-CTR-001225 SRG-APP-000494-CTR-001230 SRG-APP-000500-CTR-001260 SRG-APP-000507-CTR-001295 SRG-APP-000495-CTR-001235 R73 10.3.4 10.3 The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. Record Execution Attempts to Run ACL Privileged Commands At a minimum, the audit system should collect the execution of ACL privileged commands for all users and root. Record Any Attempts to Run chacl At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/chacl -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/chacl -F auid>=1000 -F auid!=unset -F key=privileged SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Record Any Attempts to Run setfacl At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/setfacl -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/setfacl -F auid>=1000 -F auid!=unset -F key=privileged SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000495-CTR-001235 Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Record Execution Attempts to Run SELinux Privileged Commands At a minimum, the audit system should collect the execution of SELinux privileged commands for all users and root. Record Any Attempts to Run chcon At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/chcon -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/chcon -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000468-GPOS-00212 SRG-OS-000471-GPOS-00215 SRG-OS-000463-GPOS-00207 SRG-OS-000465-GPOS-00209 SRG-APP-000495-CTR-001235 SRG-APP-000496-CTR-001240 SRG-APP-000497-CTR-001245 SRG-APP-000498-CTR-001250 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 0582 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Record File Deletion Events by User At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat,renameat2 -F auid>=1000 -F auid!=unset -F key=delete If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat,renameat2 -F auid>=1000 -F auid!=unset -F key=delete Ensure auditd Collects File Deletion Events by User - rename At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.4 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.1.1 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.MA-2 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.7 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-OS-000467-GPOS-00211 SRG-OS-000468-GPOS-00212 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.2.1.7 10.2.1 10.2 Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. Ensure auditd Collects File Deletion Events by User - renameat At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.4 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.1.1 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.MA-2 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.7 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-OS-000467-GPOS-00211 SRG-OS-000468-GPOS-00212 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.2.1.7 10.2.1 10.2 Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. Ensure auditd Collects File Deletion Events by User - rmdir At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.4 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.1.1 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.MA-2 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.7 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-OS-000467-GPOS-00211 SRG-OS-000468-GPOS-00212 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.2.1.7 10.2.1 10.2 Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. Ensure auditd Collects File Deletion Events by User - unlink At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.4 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.1.1 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.MA-2 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.7 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-OS-000467-GPOS-00211 SRG-OS-000468-GPOS-00212 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.2.1.7 10.2.1 10.2 Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. Ensure auditd Collects File Deletion Events by User - unlinkat At a minimum, the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.5 4.3.3.6.6 4.3.3.6.7 4.3.3.6.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.4 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.1.1 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.MA-2 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.7 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-OS-000467-GPOS-00211 SRG-OS-000468-GPOS-00212 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 R73 10.2.1.7 10.2.1 10.2 Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. Record Unauthorized Access Attempts Events to Files (unsuccessful) At a minimum, the audit system should collect unauthorized file accesses for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Record Unsuccessful Access Attempts to Files - creat At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.4 Req-10.2.1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000458-GPOS-00203 SRG-OS-000461-GPOS-00205 SRG-APP-000495-CTR-001235 R73 0582 0846 Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Record Unsuccessful Access Attempts to Files - ftruncate At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.4 Req-10.2.1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000458-GPOS-00203 SRG-OS-000461-GPOS-00205 SRG-APP-000495-CTR-001235 R73 0582 0846 Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Record Unsuccessful Access Attempts to Files - open At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.4 Req-10.2.1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000458-GPOS-00203 SRG-OS-000461-GPOS-00205 SRG-APP-000495-CTR-001235 R73 0582 0846 Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Record Unsuccessful Access Attempts to Files - open_by_handle_at At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.4 Req-10.2.1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000458-GPOS-00203 SRG-OS-000461-GPOS-00205 SRG-APP-000495-CTR-001235 0582 0846 Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Record Unsuccessful Access Attempts to Files - openat At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.4 Req-10.2.1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000458-GPOS-00203 SRG-OS-000461-GPOS-00205 SRG-APP-000495-CTR-001235 R73 0582 0846 Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Record Unsuccessful Access Attempts to Files - truncate At a minimum, the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file: -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access If the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.4 Req-10.2.1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000064-GPOS-00033 SRG-OS-000458-GPOS-00203 SRG-OS-000461-GPOS-00205 SRG-APP-000495-CTR-001235 R73 0582 0846 Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. Record Information on Kernel Modules Loading and Unloading To capture kernel module loading and unloading events, use following lines, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S init_module,delete_module -F key=modules Place to add the lines depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the lines to a file with suffix .rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the lines to file /etc/audit/audit.rules. Ensure auditd Collects Information on Kernel Module Unloading - delete_module To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S delete_module -F key=modules Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix .rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.7 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000471-GPOS-00216 SRG-OS-000477-GPOS-00222 SRG-APP-000495-CTR-001235 SRG-APP-000504-CTR-001280 R73 The removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S finit_module -F key=modules Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix .rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.7 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000471-GPOS-00216 SRG-OS-000477-GPOS-00222 SRG-APP-000495-CTR-001235 SRG-APP-000504-CTR-001280 R73 The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. Ensure auditd Collects Information on Kernel Module Loading - init_module To capture kernel module loading and unloading events, use the following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -S init_module -F key=modules Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix .rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.7 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000471-GPOS-00216 SRG-OS-000477-GPOS-00222 SRG-APP-000495-CTR-001235 SRG-APP-000504-CTR-001280 R73 The addition of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. Record Attempts to Alter Logon and Logout Events The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing logon events: -w /var/log/tallylog -p wa -k logins -w -p wa -k logins -w /var/log/lastlog -p wa -k logins If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events: -w /var/log/tallylog -p wa -k logins -w -p wa -k logins -w /var/log/lastlog -p wa -k logins Record Attempts to Alter Logon and Logout Events - faillog The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /var/log/faillog -p wa -k logins If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /var/log/faillog -p wa -k logins SRG-OS-000037-GPOS-00015 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Record Attempts to Alter Logon and Logout Events - lastlog The audit system already collects login information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d: -w /var/log/lastlog -p wa -k logins If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules: -w /var/log/lastlog -p wa -k logins 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 APO12.06 APO13.01 BAI03.05 BAI08.02 DSS01.03 DSS01.04 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS03.05 DSS05.02 DSS05.03 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.2.3.10 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.3.6.6 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 1.13 SR 2.10 SR 2.11 SR 2.12 SR 2.6 SR 2.8 SR 2.9 SR 3.1 SR 3.5 SR 3.8 SR 4.1 SR 4.3 SR 5.1 SR 5.2 SR 5.3 SR 6.1 SR 6.2 SR 7.1 SR 7.6 A.11.2.6 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.13.1.1 A.13.2.1 A.14.1.3 A.14.2.7 A.15.2.1 A.15.2.2 A.16.1.4 A.16.1.5 A.16.1.7 A.6.2.1 A.6.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.AE-3 DE.AE-5 DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.AC-3 PR.PT-1 PR.PT-4 RS.AN-1 RS.AN-4 Req-10.2.3 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000473-GPOS-00218 SRG-OS-000470-GPOS-00214 SRG-APP-000495-CTR-001235 SRG-APP-000503-CTR-001275 SRG-APP-000506-CTR-001290 R73 0582 10.2.1.3 10.2.1 10.2 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Record Information on the Use of Privileged Commands At a minimum, the audit system should collect the execution of privileged commands for all users and root. Record Any Attempts to Run apparmor_parser At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/sbin/apparmor_parser -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/sbin/apparmor_parser -F auid>=1000 -F auid!=unset -F key=privileged SRG-OS-000064-GPOS-00033 Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Ensure auditd Collects Information on the Use of Privileged Commands - chage At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/chage -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/chage -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000468-GPOS-00212 SRG-OS-000471-GPOS-00215 SRG-APP-000029-CTR-000085 SRG-APP-000495-CTR-001235 SRG-APP-000501-CTR-001265 SRG-APP-000502-CTR-001270 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - chfn At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/chfn -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/chfn -F auid>=1000 -F auid!=unset -F key=privileged AU-3 AU-12(a) AU-12(c) MA-4(1)(a) Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Ensure auditd Collects Information on the Use of Privileged Commands - chsh At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/chsh -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/chsh -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000495-CTR-001235 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - crontab At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/crontab -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/crontab -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000495-CTR-001235 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - fdisk Configure the operating system to audit the execution of the partition management program "fdisk". SRG-OS-000477-GPOS-00222 Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/gpasswd -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/gpasswd -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000029-CTR-000085 SRG-APP-000495-CTR-001235 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - kmod At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/kmod -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/kmod -F auid>=1000 -F auid!=unset -F key=privileged AU-3 AU-3.1 AU-12(a) AU-12.1(ii) AU-12.1(iv)AU-12(c) MA-4(1)(a) SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000471-GPOS-00216 SRG-OS-000477-GPOS-00222 SRG-APP-000495-CTR-001235 SRG-APP-000504-CTR-001280 R73 Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Ensure auditd Collects Information on the Use of Privileged Commands - modprobe At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -w /sbin/modprobe -p x -k modules If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -w /sbin/modprobe -p x -k modules AU-12(a) AU-12.1(ii) AU-3 AU-3.1 AU-12(c) AU-12.1(iv) MA-4(1)(a) SRG-OS-000037-GPOS-00015 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 R73 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - mount At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/mount -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/mount -F auid>=1000 -F auid!=unset -F key=privileged AU-2(d) AU-12(c) AC-6(9) CM-6(a) SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000029-CTR-000085 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - newgrp At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/newgrp -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/newgrp -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000029-CTR-000085 SRG-APP-000495-CTR-001235 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/sbin/pam_timestamp_check -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/sbin/pam_timestamp_check -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000029-CTR-000085 SRG-APP-000495-CTR-001235 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - passwd At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/passwd -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/passwd -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 CIP-004-6 R2.2.2 CIP-004-6 R2.2.3 CIP-007-3 R.1.3 CIP-007-3 R5 CIP-007-3 R5.1.1 CIP-007-3 R5.1.3 CIP-007-3 R5.2.1 CIP-007-3 R5.2.3 AC-2(4) AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000029-CTR-000085 SRG-APP-000495-CTR-001235 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Record Any Attempts to Run ssh-agent At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/ssh-agent -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/ssh-agent -F auid>=1000 -F auid!=unset -F key=privileged SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000495-CTR-001235 Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000029-CTR-000085 SRG-APP-000495-CTR-001235 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - su At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/su -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/su -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000064-GPOS-00033 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-APP-000029-CTR-000085 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-OS-000755-GPOS-00220 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - sudo At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/sudo -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/sudo -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-APP-000029-CTR-000085 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 SRG-OS-000755-GPOS-00220 R33 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - sudoedit At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/sudoedit -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/sudoedit -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000495-CTR-001235 SRG-OS-000755-GPOS-00220 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - umount At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/bin/umount -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/bin/umount -F auid>=1000 -F auid!=unset -F key=privileged 1 12 13 14 15 16 2 3 5 6 7 8 9 APO10.01 APO10.03 APO10.04 APO10.05 APO11.04 BAI03.05 DSS01.03 DSS03.05 DSS05.02 DSS05.04 DSS05.05 DSS05.07 MEA01.01 MEA01.02 MEA01.03 MEA01.04 MEA01.05 MEA02.01 3.1.7 164.308(a)(1)(ii)(D) 164.308(a)(3)(ii)(A) 164.308(a)(5)(ii)(C) 164.312(a)(2)(i) 164.312(b) 164.312(d) 164.312(e) 4.3.2.6.7 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 6.2 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.14.2.7 A.15.2.1 A.15.2.2 AU-2(d) AU-12(c) AC-6(9) CM-6(a) DE.CM-1 DE.CM-3 DE.CM-7 ID.SC-4 PR.PT-1 SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000029-CTR-000085 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - unix_update At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/sbin/unix_update -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/sbin/unix_update -F auid>=1000 -F auid!=unset -F key=privileged SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000064-GPOS-00033 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-APP-000495-CTR-001235 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Ensure auditd Collects Information on the Use of Privileged Commands - usermod At a minimum, the audit system should collect the execution of privileged commands for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F path=/usr/sbin/usermod -F auid>=1000 -F auid!=unset -F key=privileged If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules: -a always,exit -F path=/usr/sbin/usermod -F auid>=1000 -F auid!=unset -F key=privileged SRG-OS-000037-GPOS-00015 SRG-OS-000042-GPOS-00020 SRG-OS-000062-GPOS-00031 SRG-OS-000392-GPOS-00172 SRG-OS-000462-GPOS-00206 SRG-OS-000471-GPOS-00215 SRG-OS-000466-GPOS-00210 SRG-APP-000495-CTR-001235 SRG-APP-000499-CTR-001255 Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threats. Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. Configure auditd Data Retention The audit system writes data to /var/log/audit/audit.log. By default, auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of data in total, and refuses to write entries when the disk is too full. This minimizes the risk of audit data filling its partition and impacting other services. This also minimizes the risk of the audit daemon temporarily disabling the system if it cannot write audit log (which it can be configured to do). For a busy system or a system which is thoroughly auditing system activity, the default settings for data retention may be insufficient. The log file size needed will depend heavily on what types of events are being audited. First configure auditing to log all the events of interest. Then monitor the log size manually for awhile to determine what file size will allow you to keep the required data for the correct time period. Using a dedicated partition for /var/log/audit prevents the auditd logs from disrupting system functionality if they fill, and, more importantly, prevents other activity in /var from filling the partition and stopping the audit trail. (The audit logs are size-limited and therefore unlikely to grow without bound unless configured to do so.) Some machines may have requirements that no actions occur which cannot be audited. If this is the case, then auditd can be configured to halt the machine if it runs out of space. Note: Since older logs are rotated, configuring auditd this way does not prevent older logs from being rotated away before they can be viewed. If your system is configured to halt when logging cannot be performed, make sure this can never happen under normal circumstances! Ensure that /var/log/audit is on its own partition, and that this partition is larger than the maximum amount of data auditd will retain normally. Remote server for audispd to send audit records The configuration file could be "/etc/audit/audisp-remote.conf" or "/etc/audisp/audisp-remote.conf" depending on the distro logcollector Account for auditd to send email when actions occurs The setting for action_mail_acct in /etc/audit/auditd.conf admin root root Action for auditd to take when disk is full 'The setting for disk_full_action in /etc/audit/auditd.conf, if multiple values are allowed write them separated by pipes as in "syslog|single|halt", for remediations the first value will be taken' single exec halt single suspend syslog ignore rotate syslog|single|halt syslog|single|halt single|halt halt|single halt|single halt|single halt|single halt|single halt|single Action for auditd to take when disk space just starts to run low The setting for space_left_action in /etc/audit/auditd.conf email email exec halt single suspend syslog rotate ignore email|exec|single|halt email|exec|single|halt email|exec|single|halt email|exec|single|halt The percentage remaining in disk space before prompting space_left_action The setting for space_left as a percentage in /etc/audit/auditd.conf 25 50 75 25 Configure audispd Plugin To Send Logs To Remote Server Configure the audispd plugin to off-load audit records onto a different system or media from the system being audited. Set the remote_server option in /etc/audit/audisp-remote.conf with an IP address or hostname of the system that the audispd plugin should send audit records to. For example remote_server = SRG-OS-000342-GPOS-00133 SRG-OS-000479-GPOS-00224 Information stored in one location is vulnerable to accidental or incidental deletion or alteration.Off-loading is a common process in information systems with limited audit storage capacity. Configure a Sufficiently Large Partition for Audit Logs The Claroty CTD 5.x operating system must allocate audit record storage capacity to store at least one weeks worth of audit records when audit records are not immediately sent to a central audit record storage facility. The partition size needed to capture a week's worth of audit records is based on the activity level of the system and the total storage capacity available. In normal circumstances, 10.0 GB of storage space for audit records will be sufficient. Determine which partition the audit records are being written to with the following command: $ sudo grep log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Check the size of the partition that audit records are written to with the following command: $ sudo df -h /var/log/audit/ /dev/sda2 24G 10.4G 13.6G 43% /var/log/audit SRG-OS-000341-GPOS-00132 SRG-OS-000342-GPOS-00133 Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. Configure auditd Disk Full Action when Disk Space Is Full The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: disk_full_action = ACTION Set this value to single to cause the system to switch to single-user mode for corrective action. Acceptable values also include syslog, exec, single, and halt For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 APO11.04 APO12.06 APO13.01 BAI03.05 BAI04.04 BAI08.02 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS05.04 DSS05.07 MEA02.01 4.2.3.10 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 7.1 SR 7.2 A.12.1.3 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.16.1.4 A.16.1.5 A.16.1.7 A.17.2.1 AU-5(b) AU-5(2) AU-5(1) AU-5(4) CM-6(a) DE.AE-3 DE.AE-5 PR.DS-4 PR.PT-1 RS.AN-1 RS.AN-4 SRG-OS-000047-GPOS-00023 Taking appropriate action in case of a filled audit storage volume will minimize the possibility of losing audit records. Configure auditd mail_acct Action on Low Disk Space The auditd service can be configured to send email to a designated account in certain situations. Add or correct the following line in /etc/audit/auditd.conf to ensure that administrators are notified via email for those situations: action_mail_acct = 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 5.4.1.1 APO11.04 APO12.06 APO13.01 BAI03.05 BAI04.04 BAI08.02 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS05.04 DSS05.07 MEA02.01 3.3.1 164.312(a)(2)(ii) 4.2.3.10 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 7.1 SR 7.2 A.12.1.3 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.16.1.4 A.16.1.5 A.16.1.7 A.17.2.1 CIP-003-8 R1.3 CIP-003-8 R3 CIP-003-8 R3.1 CIP-003-8 R3.2 CIP-003-8 R3.3 CIP-003-8 R5.1.1 CIP-003-8 R5.3 CIP-004-6 R2.2.3 CIP-004-6 R2.3 CIP-007-3 R5.1 CIP-007-3 R5.1.2 CIP-007-3 R5.2 CIP-007-3 R5.3.1 CIP-007-3 R5.3.2 CIP-007-3 R5.3.3 IA-5(1) AU-5(a) AU-5(2) CM-6(a) DE.AE-3 DE.AE-5 PR.DS-4 PR.PT-1 RS.AN-1 RS.AN-4 Req-10.7.a SRG-OS-000046-GPOS-00022 SRG-OS-000343-GPOS-00134 Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action. Configure auditd space_left Action on Low Disk Space The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately: space_left_action = ACTION Possible values for ACTION are described in the auditd.conf man page. These include: syslogemailexecsuspendsinglehalt Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention. Acceptable values also include suspend, single, and halt. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 5.4.1.1 APO11.04 APO12.06 APO13.01 BAI03.05 BAI04.04 BAI08.02 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS05.04 DSS05.07 MEA02.01 3.3.1 164.312(a)(2)(ii) 4.2.3.10 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 7.1 SR 7.2 A.12.1.3 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.16.1.4 A.16.1.5 A.16.1.7 A.17.2.1 AU-5(b) AU-5(2) AU-5(1) AU-5(4) CM-6(a) DE.AE-3 DE.AE-5 PR.DS-4 PR.PT-1 RS.AN-1 RS.AN-4 Req-10.7 SRG-OS-000343-GPOS-00134 10.5.1 10.5 Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. Configure auditd space_left on Low Disk Space The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting PERCENTAGE appropriately: space_left = PERCENTAGE% Set this value to at least 25 to cause the system to notify the user of an issue. 1 11 12 13 14 15 16 19 2 3 4 5 6 7 8 APO11.04 APO12.06 APO13.01 BAI03.05 BAI04.04 BAI08.02 DSS02.02 DSS02.04 DSS02.07 DSS03.01 DSS05.04 DSS05.07 MEA02.01 4.2.3.10 4.3.3.3.9 4.3.3.5.8 4.3.4.4.7 4.3.4.5.6 4.3.4.5.7 4.3.4.5.8 4.4.2.1 4.4.2.2 4.4.2.4 SR 2.10 SR 2.11 SR 2.12 SR 2.8 SR 2.9 SR 6.1 SR 7.1 SR 7.2 A.12.1.3 A.12.4.1 A.12.4.2 A.12.4.3 A.12.4.4 A.12.7.1 A.16.1.4 A.16.1.5 A.16.1.7 A.17.2.1 AU-5(b) AU-5(2) AU-5(1) AU-5(4) CM-6(a) DE.AE-3 DE.AE-5 PR.DS-4 PR.PT-1 RS.AN-1 RS.AN-4 Req-10.7 SRG-OS-000343-GPOS-00134 Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. Offload audit Logs to External Media The operating system must have a crontab script running weekly to offload audit events of standalone systems. Due to different needs and possibilities, automated remediation is not available for this configuration check. SRG-OS-000479-GPOS-00224 Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. System Accounting with auditd The audit service provides substantial capabilities for recording system activities. This section deals with permissions of auditd related files. Verify that audit tools are owned by root The Claroty CTD 5.x operating system audit tools must have the proper ownership configured to protected against unauthorized access. Verify it by running the following command: $ stat -c "%n %U" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules root Audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators SRG-OS-000256-GPOS-00097 SRG-OS-000257-GPOS-00098 Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the access to audit tools. Verify that audit tools Have Mode 0755 or less The Claroty CTD 5.x operating system audit tools must have the proper permissions configured to protected against unauthorized access. Verify it by running the following command: $ stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl 755 /sbin/aureport 755 /sbin/ausearch 755 /sbin/autrace 755 /sbin/auditd 755 /sbin/audispd 755 /sbin/augenrules 755 Audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators SRG-OS-000256-GPOS-00097 SRG-OS-000257-GPOS-00098 Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys to make access decisions regarding the access to audit tools. Verify Permissions on /etc/audit/auditd.conf To properly set the permissions of /etc/audit/auditd.conf, run the command: $ sudo chmod 0640 /etc/audit/auditd.conf AU-12(b) SRG-OS-000063-GPOS-00032 Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Verify Permissions on /etc/audit/audit.rules To properly set the permissions of /etc/audit/audit.rules, run the command: $ sudo chmod 0640 /etc/audit/audit.rules Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Verify Permissions on /etc/audit/rules.d/*.rules To properly set the permissions of /etc/audit/rules.d/*.rules, run the command: $ sudo chmod 0600 /etc/audit/rules.d/*.rules AU-12(b) SRG-OS-000063-GPOS-00032 Without the capability to restrict the roles and individuals that can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Claroty CTD 5.x Claroty CTD 5.x is an operational technology monitoring and detection platform. This section contains Claroty-specific hardening guidance for the CTD appliance and administrative web interface. Claroty CTD must accept the DOD CAC or other PKI credential for identity management and personal authentication. Claroty CTD must support DoD CAC or other approved PKI credentials for identity management and personal authentication where required. CLTY-OT-001750 CAC and PKI credentials strengthen identity assurance and support enterprise authentication requirements. Claroty CTD must alert the information system security officer (ISSO), information system security manager (ISSM), and other individuals designated by the local organization when events are detected that indicate a compromise or potential for compromise. Claroty CTD must alert the ISSO, ISSM, and other designated personnel when compromise-related events are detected. CLTY-OT-002120 Prompt security alerting helps organizations respond quickly to indicators of compromise or potential compromise. Claroty CTD must allocate audit record storage retention length. Claroty CTD must allocate sufficient storage retention for audit records in accordance with organizational requirements. CLTY-OT-001430 Adequate audit storage retention helps ensure records remain available for monitoring, investigation, and compliance review. Claroty CTD must only allow authorized local accounts as documented in the System Security Plan (SSP). Claroty CTD must permit only local accounts that are authorized and documented in the system security plan. CLTY-OT-000240 Restricting local accounts reduces unauthorized access paths and supports accountable administration. Before establishing a network connection with a Network Time Protocol (NTP) server, Claroty CTD must authenticate using a bidirectional, cryptographically based authentication method that uses a FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to authenticate with the NTP server. Claroty CTD must authenticate to the configured NTP server using a bidirectional cryptographic method based on FIPS-validated AES before establishing the network connection. CLTY-OT-002480 Authenticated NTP reduces the risk of time spoofing and improves the trustworthiness of system timestamps. Change Default Administrator Password The default administrative password for Claroty CTD 5.x must be changed from the vendor-supplied value to an organization-approved password. Default credentials are widely known and can provide attackers with immediate administrative access if they are not changed during deployment. Claroty CTD must configure local password policies. Claroty CTD must enforce local password policies that meet organizational requirements for complexity and strength. CLTY-OT-000650 Strong password policy requirements make it more difficult to compromise local credentials. Claroty CTD must have disk encryption enabled on virtual machines (VMs). Claroty CTD deployments on virtual machines must enable disk encryption for the virtual storage used by the appliance. CLTY-OT-000500 Disk encryption protects sensitive data at rest from unauthorized disclosure if the underlying storage is exposed. Claroty CTD must display the Standard Mandatory DOD Notice and Consent Banner before granting local or remote access to the system. Claroty CTD must display the Standard Mandatory DoD Notice and Consent Banner before granting system access. CLTY-OT-000200 Required notice and consent language establishes user awareness and supports authorized monitoring. The publicly accessible Claroty CTD application must display the Standard Mandatory DOD Notice and Consent Banner before granting access to Claroty CTD. The Claroty CTD web application must display the Standard Mandatory DoD Notice and Consent Banner before granting access. CLTY-OT-000220 A pre-access banner ensures users are informed of monitoring and consent requirements before using the web application. Claroty CTD must configure idle timeouts at 10 minutes. Claroty CTD must terminate or lock idle administrative sessions after 10 minutes of inactivity. CLTY-OT-000020 Short idle timeouts reduce the risk of unauthorized use of an unattended session. Claroty CTD must have notification and audit services operational. Claroty CTD must maintain operational notification and audit services to support monitoring and accountability. CLTY-OT-000370 Notification and audit services are necessary to detect, record, and respond to security-relevant events. Claroty CTD must notify system administrators and information system security officer (ISSO) of local account activity. Claroty CTD must notify designated administrators and the ISSO of local account activity. CLTY-OT-001190 Notification of local account activity helps identify unauthorized account creation and misuse. Claroty CTD must only allow the use of DOD PKI established certificate authorities for verification of the establishment of protected sessions. Claroty CTD must use only DoD PKI-established certificate authorities for protected session verification where required. CLTY-OT-001910 Restricting trust to approved certificate authorities reduces the risk of accepting untrusted identities for protected sessions. Claroty CTD must allow only the individuals appointed by the information system security manager (ISSM) to have full admin rights to the system. Claroty CTD must restrict full administrative rights to ISSM-authorized individuals only. CLTY-OT-000610 Limiting full administrative rights reduces the chance of unauthorized changes to auditing and system security settings. Claroty CTD must limit privileges and restrict administrative shell access. Claroty CTD must restrict administrative shell access and limit privileges to only those functions required by authorized users. CLTY-OT-000520 Restricting shell access and privilege escalation reduces the risk of unauthorized changes to the platform. Claroty CTD must be configured to send backup audit records. Claroty CTD must be configured to preserve or send backup copies of audit records. CLTY-OT-000490 Backup audit records support recovery, forensic review, and the continued availability of security evidence. The Claroty CTD Syslog client must use TCP connections. The Claroty CTD syslog client must use TCP for remote log transport. CLTY-OT-001630 TCP supports more reliable delivery for remote log forwarding than connectionless transports. Claroty CTD must use FIPS-validated encryption and hashing algorithms to protect the confidentiality and integrity of application configuration files and user-generated data stored or aggregated on the device. Claroty CTD must use FIPS-validated encryption and hashing algorithms to protect configuration files and user-generated data stored on the device. CLTY-OT-001010 FIPS-validated cryptography supports the confidentiality and integrity of sensitive data stored by the platform. Claroty CTD must use an Identity Provider (IDP) for authentication and authorization processes. Claroty CTD must integrate with an approved identity provider for authentication and authorization processes. CLTY-OT-000090 Centralized identity management improves account lifecycle control and reduces administrative error. OVALFileLinker from SCAP Security Guide ssg: [0, 1, 81], python: 3.14.3 5.11.2 2026-04-01T21:16:40 Configure audispd Plugin To Send Logs To Remote Server Claroty CTD 5.x remote_server setting in /etc/audit/audisp-remote.conf is set to a certain IP address or hostname Configure auditd Disk Full Action when Disk Space Is Full Claroty CTD 5.x disk_full_action setting in /etc/audit/auditd.conf is set to a certain action Configure auditd mail_acct Action on Low Disk Space Claroty CTD 5.x action_mail_acct setting in /etc/audit/auditd.conf is set to a certain account Configure auditd space_left Action on Low Disk Space Claroty CTD 5.x space_left_action setting in /etc/audit/auditd.conf is set to a certain action Configure auditd space_left on Low Disk Space Claroty CTD 5.x space_left setting in /etc/audit/auditd.conf is set to at least a certain value Offload audit Logs to External Media Claroty CTD 5.x Check if a script for audit offload exists in /etc/cron.weekly/ Disable unauthenticated repositories in APT configuration Claroty CTD 5.x Accessing a repository should be allowed only when the repository is authenticated. Configure Time Service Maxpoll Interval Claroty CTD 5.x Configure the maxpoll setting in /etc/ntp.conf or chrony.conf to continuously poll the time source servers. Certificate trust path in SSSD Claroty CTD 5.x SSSD should be configured with trust path to an accepted trust anchor. Configure PAM in SSSD Services Claroty CTD 5.x SSSD should be configured to run SSSD PAM services. Enable Smartcards in SSSD Claroty CTD 5.x SSSD should be configured to authenticate access to the system using smart cards. Enable Certificates Mapping in SSSD Claroty CTD 5.x SSSD should be configured to map the certificate to correct user or group Configure SSSD to Expire Offline Credentials Claroty CTD 5.x SSSD should be configured to expire offline credentials after 1 day. Enable authselect Claroty CTD 5.x Check that authselect is enabled Modify the System Login Banner for Remote Connections Claroty CTD 5.x The system login banner text should be set correctly. Account Lockouts Must Be Logged Claroty CTD 5.x Account Lockouts Must Be Logged Do Not Show System Messages When Unsuccessful Logon Attempts Occur Claroty CTD 5.x Prevent System Messages When Three Unsuccessful Logon Attempts Occur Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session Claroty CTD 5.x The password retry should meet minimum requirements Set Password Hashing Algorithm for PAM Claroty CTD 5.x The password hashing algorithm should be set correctly in {{{ pam_file }}}. Set Password Hashing Algorithm in /etc/login.defs Claroty CTD 5.x The password hashing algorithm should be set correctly in /usr/etc/login.defs. Disable Ctrl-Alt-Del Reboot Activation Claroty CTD 5.x By default, the system will reboot when the Ctrl-Alt-Del key sequence is pressed. Set Account Expiration Following Inactivity Claroty CTD 5.x The accounts should be configured to expire automatically following password expiration. Set Password Maximum Age Claroty CTD 5.x The maximum password age policy should meet minimum requirements. Set Password Minimum Age Claroty CTD 5.x The minimum password age policy should be set appropriately. Set number of Password Hashing Rounds - password-auth Claroty CTD 5.x The number of rounds for password hashing should be set correctly. Prevent Login to Accounts With Empty Password Claroty CTD 5.x The file /etc/pam.d/system-auth should not contain the nullok option Ensure There Are No Accounts With Blank or Null Passwords Claroty CTD 5.x The file /etc/shadow shows that there aren't empty passwords Direct root Logins Are Not Allowed Claroty CTD 5.x Direct root Logins Are Not Allowed Limit the Number of Concurrent Login Sessions Allowed Per User Claroty CTD 5.x The maximum number of concurrent login sessions per user should meet minimum requirements. Set Interactive Session Timeout Claroty CTD 5.x Checks interactive shell timeout Set Boot Loader Password in grub2 Claroty CTD 5.x The grub2 boot loader should have password protection enabled. Set the UEFI Boot Loader Password Claroty CTD 5.x The UEFI grub2 boot loader should have password protection enabled. Ensure real-time clock is set to UTC Claroty CTD 5.x Ensure RTC is using UTC as its time base Ensure remote access methods are monitored in Rsyslog Claroty CTD 5.x Rsyslog should be configured to monitor remote access methods. Deactivate Wireless Network Interfaces Claroty CTD 5.x All wireless interfaces should be disabled. Verify that All World-Writable Directories Have Sticky Bits Set Claroty CTD 5.x The sticky bit should be set for all world-writable directories. Verify that system commands files are group owned by root or a system account Claroty CTD 5.x Checks that system commands in /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin are owned by root group or a system account. Verify that System Executables Have Root Ownership Claroty CTD 5.x Checks that /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /usr/libexec, and objects therein, are owned by root. Verify that System Executables Have Restrictive Permissions Claroty CTD 5.x Checks that binary files under /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, and /usr/libexec are not group-writable or world-writable. Enable NX or XD Support in the BIOS Claroty CTD 5.x The NX (no-execution) bit flag should be set on the system. Verify '/proc/sys/crypto/fips_enabled' exists Claroty CTD 5.x Inspect the contents of /proc/sys/crypto/fips_enabled Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate Claroty CTD 5.x Checks sudo usage without authentication Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD Claroty CTD 5.x Checks sudo usage without password The operating system must restrict privilege elevation to authorized personnel Claroty CTD 5.x Check that sudoers doesn't allow all users to run commands via sudo Ensure apt_get Removes Previous Package Versions Claroty CTD 5.x The clean_requirements_on_remove option should be used to ensure that old versions of software components are removed after updating. Ensure PAM Enforces Password Requirements - Enforcing Claroty CTD 5.x Check presence of enforcing = 1 in /etc/security/pwquality.conf Enforce Delay After Failed Logon Attempts Claroty CTD 5.x Configure PAM module Lock Accounts After Failed Password Attempts Claroty CTD 5.x Lockout account after failed login attempts. Set Interval For Counting Failed Password Attempts Claroty CTD 5.x The number of allowed failed logins should be set correctly. Set Lockout Time for Failed Password Attempts Claroty CTD 5.x The unlock time after number of failed logins should be set correctly. Configure AIDE To Notify Personnel if Baseline Configurations Are Altered Claroty CTD 5.x Ensure 'SILENTREPORTS' is configured with value 'no' in /etc/default/aide Ensure AppArmor is Active and Configured Claroty CTD 5.x The apparmor service should be enabled if possible. Synchronize internal information system clocks Claroty CTD 5.x Ensure 'makestep' is configured with value '1 -1' in /etc/chrony/chrony.conf Verify that Shared Library Directories Have Root Group Ownership Claroty CTD 5.x This test makes sure that /lib/, /lib64/, /usr/lib/, /usr/lib64/ is group owned by 0. Verify group-owner of system journal directories Claroty CTD 5.x This test makes sure that /run/log/journal/, /var/log/journal/ is group owned by systemd-journal. Verify that system commands directories are group owned by root Claroty CTD 5.x This test makes sure that /bin/, /sbin/, /usr/bin/, /usr/sbin/, /usr/local/bin/, /usr/local/sbin/ is group owned by 0. Verify owner of system journal directories Claroty CTD 5.x This test makes sure that /run/log/journal/, /var/log/journal/ is owned by 0. Verify that System Executable Have Root Ownership Claroty CTD 5.x This test makes sure that /bin/, /sbin/, /usr/bin/, /usr/sbin/, /usr/local/bin/, /usr/local/sbin/ is owned by 0. Verify that Shared Library Directories Have Root Ownership Claroty CTD 5.x This test makes sure that /lib/, /lib64/, /usr/lib/, /usr/lib64/ is owned by 0. Verify that System Executable Directories Have Restrictive Permissions Claroty CTD 5.x This test makes sure that /bin/, /sbin/, /usr/bin/, /usr/sbin/, /usr/local/bin/, /usr/local/sbin/ has mode 0755. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Permissions on the system journal directories Claroty CTD 5.x This test makes sure that /run/log/journal/, /var/log/journal/ has mode 2750. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Groupowner on the journalctl command Claroty CTD 5.x This test makes sure that /usr/bin/journalctl is group owned by 0. Verify Group Who Owns the system journal Claroty CTD 5.x This test makes sure that ^/var/log/journal/.*/system.journal$ is group owned by systemd-journal. Verify Group Who Owns /var/log Directory Claroty CTD 5.x This test makes sure that /var/log/ is group owned by 0. Verify Group Who Owns /var/log/syslog File Claroty CTD 5.x This test makes sure that /var/log/syslog is group owned by 4. Audit Configuration Files Must Be Owned By Group root Claroty CTD 5.x This test makes sure that /etc/audit/, /etc/audit/rules.d/ is group owned by 0. Verify Owner on the journalctl Command Claroty CTD 5.x This test makes sure that /usr/bin/journalctl is owned by 0. Verify Owner on the system journal Claroty CTD 5.x This test makes sure that ^/var/log/journal/.*/system.journal$ is owned by 0. Verify User Who Owns /var/log Directory Claroty CTD 5.x This test makes sure that /var/log/ is owned by 0. Verify User Who Owns /var/log/syslog File Claroty CTD 5.x This test makes sure that /var/log/syslog is owned by syslog. Verify that audit tools are owned by root Claroty CTD 5.x This test makes sure that /sbin/auditctl, /sbin/aureport, /sbin/ausearch, /sbin/autrace, /sbin/auditd, /sbin/audispd, /sbin/augenrules is owned by 0. Audit Configuration Files Must Be Owned By Root Claroty CTD 5.x This test makes sure that /etc/audit/, /etc/audit/rules.d/ is owned by 0. Verify that Shared Library Files Have Root Ownership Claroty CTD 5.x This test makes sure that /lib/, /lib64/, /usr/lib/, /usr/lib64/ is owned by 0. Verify that audit tools Have Mode 0755 or less Claroty CTD 5.x This test makes sure that /sbin/auditctl, /sbin/aureport, /sbin/ausearch, /sbin/autrace, /sbin/auditd, /sbin/audispd, /sbin/augenrules has mode 0755. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Permissions on /etc/audit/auditd.conf Claroty CTD 5.x This test makes sure that /etc/audit/auditd.conf has mode 0640. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Permissions on /etc/audit/audit.rules Claroty CTD 5.x This test makes sure that /etc/audit/audit.rules has mode 0640. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Permissions on /etc/audit/rules.d/*.rules Claroty CTD 5.x This test makes sure that /etc/audit/rules.d/ has mode 0600. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Permissions on the journal command Claroty CTD 5.x This test makes sure that /usr/bin/journalctl has mode 0740. If the target file or directory has an extended ACL, then it will fail the mode check. Verify that Shared Library Files Have Restrictive Permissions Claroty CTD 5.x This test makes sure that /lib/, /lib64/, /usr/lib/, /usr/lib64/ has mode 7755. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Permissions on the system journal Claroty CTD 5.x This test makes sure that ^/var/log/journal/.*/system.journal$ has mode 0640. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Permissions on /var/log Directory Claroty CTD 5.x This test makes sure that /var/log/ has mode 0755. If the target file or directory has an extended ACL, then it will fail the mode check. Verify Permissions on /var/log/syslog File Claroty CTD 5.x This test makes sure that /var/log/syslog has mode 0640. If the target file or directory has an extended ACL, then it will fail the mode check. Disable Modprobe Loading of USB Storage Driver Claroty CTD 5.x The kernel module usb-storage should be disabled. Verify permissions of log files Claroty CTD 5.x This test makes sure that /var/log/ has mode 0640. If the target file or directory has an extended ACL, then it will fail the mode check. Verify the system-wide library files in directories "/lib", "/lib64", "/usr/lib/" and "/usr/lib64" are group-owned by root. Claroty CTD 5.x This test makes sure that /lib/, /lib64/, /usr/lib/, /usr/lib64/ is group owned by 0. Enable auditd Service Claroty CTD 5.x The auditd service should be enabled if possible. Enable rsyslog Service Claroty CTD 5.x The rsyslog service should be enabled if possible. Enable the OpenSSH Service Claroty CTD 5.x The sshd service should be enabled if possible. Enable the SSSD Service Claroty CTD 5.x The sssd service should be enabled if possible. Verify ufw Enabled Claroty CTD 5.x The ufw service should be enabled if possible. Restrict Access to Kernel Message Buffer Claroty CTD 5.x The 'kernel.dmesg_restrict' kernel parameter should be set to the appropriate value in system configuration and system runtime. Restrict Access to Kernel Message Buffer Claroty CTD 5.x The kernel 'kernel.dmesg_restrict' parameter should be set to 1 in the system runtime. Restrict Access to Kernel Message Buffer Claroty CTD 5.x The kernel 'kernel.dmesg_restrict' parameter should be set to 1 in the system configuration. Enable Randomized Layout of Virtual Address Space Claroty CTD 5.x The 'kernel.randomize_va_space' kernel parameter should be set to the appropriate value in system configuration and system runtime. Enable Randomized Layout of Virtual Address Space Claroty CTD 5.x The kernel 'kernel.randomize_va_space' parameter should be set to 2 in the system runtime. Enable Randomized Layout of Virtual Address Space Claroty CTD 5.x The kernel 'kernel.randomize_va_space' parameter should be set to 2 in the system configuration. Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces Claroty CTD 5.x The 'net.ipv4.tcp_syncookies' kernel parameter should be set to the appropriate value in system configuration and system runtime. Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces Claroty CTD 5.x The kernel 'net.ipv4.tcp_syncookies' parameter should be set to the appropriate value in the system runtime. Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces Claroty CTD 5.x The kernel 'net.ipv4.tcp_syncookies' parameter should be set to the appropriate value in the system configuration. Verify that 'use_mappers' is set to 'pwent' in PAM Claroty CTD 5.x Check presence of use_mappers = pwent in /etc/pam_pkcs11/pam_pkcs11.conf /etc/audit/audisp-remote.conf ^[ ]*(?i)remote_server(?-i)[ ]+=[ ]+(\S+)[ ]*$ 1 /etc/audit/auditd.conf ^[ ]*disk_full_action[ ]+=[ ]+(\S+)[ ]*$ 1 /etc/audit/auditd.conf ^[ ]*action_mail_acct[ ]+=[ ]+(\S+)[ ]*$ 1 /etc/audit/auditd.conf ^[ ]*space_left_action[ ]+=[ ]+(\S+)[ ]*$ 1 /etc/audit/auditd.conf ^[\s]*space_left[\s]+=[\s]+(\d+)%[\s]*$ 1 /etc/cron.weekly/audit-offload ^.*$ 1 /etc/apt/apt.conf(\.d/.*)?$ ^[^#]*(?i)AllowUnauthenticated(?-i)(.*)$ 1 /etc/ntp.conf ^server[\s]+[\S]+.*maxpoll[\s]+(\d+) 1 ^(/etc/chrony/chrony\.conf|/etc/chrony/conf\.d/.+\.conf)$ ^(?:server|pool|peer)[\s]+[\S]+.*maxpoll[\s]+(\d+) 1 /etc/ntp.conf ^server[\s]+[\S]+[\s]+(.*) 1 ^(/etc/chrony/chrony\.conf|/etc/chrony/conf\.d/.+\.conf)$ ^(?:server|pool|peer)[\s]+[\S]+[\s]+(.*) 1 ^/etc/sssd/sssd.conf$ ^[\s]*\[domain\/.*](?:[^\n\[]*\n+)+?[\s]*certificate_verification\s*=\s*([\w,]+)$ 1 ^/etc/sssd/(sssd|conf\.d/.*)\.conf$ ^\s*\[sssd\].*(?:\n\s*[^[\s].*)*\n\s*services[ \t]*=[ \t]*(.*)$ 1 /etc/sssd/(sssd\.conf|conf.d/[^/]+\.conf) ^[\s]*\[pam](?:[^\n\[]*\n+)+?[\s]*pam_cert_auth[\s]*=[\s]*(\w+)\s*$ 1 /etc/sssd/sssd.conf ^[\s]*\[[^\n\[\]]+\](?:[^\n\[]*\n+)+?[\s]*ldap_user_certificate\s*=\s*([\w;]+)$ 1 ^\/etc\/sssd\/(sssd.conf|conf\.d\/.+\.conf)$ ^[\s]*\[pam](?:[^\n\[]*\n+)+?[\s]*offline_credentials_expiration[\s]*=[\s]*(\d+)\s*(?:#.*)?$ 1 /etc/pam.d/fingerprint-auth /etc/pam.d/password-auth /etc/pam.d/postlogin /etc/pam.d/smartcard-auth /etc/pam.d/system-auth ^/etc/issue\.net$ ^(.*)$ 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/security/faillock.conf ^\s*audit 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/security/faillock.conf ^\s*silent 1 /etc/pam.d/system-auth ^\s*password\s+(?:(?:required)|(?:requisite))\s+pam_pwquality\.so.*retry=([0-9]*).*$ 1 /etc/security/pwquality.conf ^[\s]*retry[\s]*=[\s]*(\d+)(?:[\s]|$) 1 /etc/pam.d/common-password ^[\s]*password[\s]+(?:\[success=\d+\s+default=ignore\])[\s]+pam_unix\.so[\s]+(?!.*\b(sha512|yescrypt|gost_yescrypt|blowfish|sha256|md5|bigcrypt)\b[^#]*\b(sha512|yescrypt|gost_yescrypt|blowfish|sha256|md5|bigcrypt)\b)[^#]*\b(sha512|yescrypt|gost_yescrypt|blowfish|sha256|md5|bigcrypt)\b.*$ 1 /etc/login.defs .*\n[^#]*(ENCRYPT_METHOD\s+\w+)\s*\n 1 oval:ssg-variable_last_encrypt_method_instance_value:var:1 /etc/systemd/system/ctrl-alt-del.target /etc/default/useradd ^\s*INACTIVE\s*=\s*(\d+)\s*$ 1 /etc/login.defs ^(?:.*\n)*\s*[^#]*(PASS_MAX_DAYS\s+\d+)\s*\n 1 oval:ssg-variable_last_pass_max_days_instance_value:var:1 /etc/login.defs .*\n[^#]*(PASS_MIN_DAYS\s+\d+)\s*\n 1 oval:ssg-variable_last_pass_min_days_instance_value:var:1 ^/etc/pam.d/password-auth$ ^\s*password\s+(?:(?:sufficient)|(?:required))\s+pam_unix\.so[^#]*rounds=([0-9]*).*$ 1 ^/etc/pam.d/(system|password)-auth$ ^[^#]*\bnullok\b.*$ 1 /etc/shadow ^[^:]+::.*$ 1 /etc/shadow ^root:([^:]*):(?:[^:]*:){6}(?:[^:]*)$ 1 /etc/security/limits.conf ^[\s]*\*[\s]+(?:(?:hard)|(?:-))[\s]+maxlogins[\s]+(\d+)\s*$ 1 /etc/security/limits.d ^.*\.conf$ ^[\s]*\*[\s]+(?:(?:hard)|(?:-))[\s]+maxlogins[\s]+(\d+)\s*$ 1 /etc/security/limits.d ^.*\.conf$ ^[\s]*\*[\s]+(?:(?:hard)|(?:-))[\s]+maxlogins 1 /etc/profile ^[\s]*(?:typeset|declare)[\s]+-xr[\s]+TMOUT=([\w$]+).*$ 1 /etc/profile.d ^.*\.sh$ ^[\s]*(?:typeset|declare)[\s]+-xr[\s]+TMOUT=([\w$]+).*$ 1 oval:ssg-object_etc_profile_tmout:obj:1 oval:ssg-object_etc_profiled_tmout:obj:1 oval:ssg-variable_count_of_tmout_instances:var:1 /boot/grub/grub.cfg ^[\s]*set[\s]+superusers=("?)[a-zA-Z_]+\1$ 1 /boot/grub/user.cfg ^[\s]*GRUB2_PASSWORD=grub\.pbkdf2\.sha512.*$ 1 /boot/grub/grub.cfg ^[\s]*password_pbkdf2[\s]+.*[\s]+grub\.pbkdf2\.sha512.*$ 1 /boot/efi/EFI/ubuntu/user.cfg ^[\s]*GRUB2_PASSWORD=grub\.pbkdf2\.sha512.*$ 1 /etc/localtime ^/etc/rsyslog\.(conf|d/.+\.conf)$ ^[ \t]*(?:(?:\w+,)*auth(?:,\w+)*\.\*|\S+;auth\.\*|auth\.\*;\S+|\S+;auth\.\*;\S+)[ \t]+(?:(?!action\()\S+|action\([^)]*file\s*=\s*["'][^"']+["'][^)]*\))\s*$ 1 ^/etc/rsyslog\.(conf|d/.+\.conf)$ ^[ \t]*(?:(?:\w+,)*authpriv(?:,\w+)*\.\*|\S+;authpriv\.\*|authpriv\.\*;\S+|\S+;authpriv\.\*;\S+)[ \t]+(?:(?!action\()\S+|action\([^)]*file\s*=\s*["'][^"']+["'][^)]*\))\s*$ 1 ^/etc/rsyslog\.(conf|d/.+\.conf)$ ^[ \t]*(?:(?:\w+,)*daemon(?:,\w+)*\.\*|\S+;daemon\.\*|daemon\.\*;\S+|\S+;daemon\.\*;\S+)[ \t]+(?:(?!action\()\S+|action\([^)]*file\s*=\s*["'][^"']+["'][^)]*\))\s*$ 1 ^wl.*$ .* oval:ssg-state_dir_perms_world_writable_sticky_bits_dev_partitons:ste:1 oval:ssg-state_dir_perms_world_writable_sticky_bits:ste:1 ^\/s?bin|^\/usr\/s?bin|^\/usr\/local\/s?bin ^.*$ oval:ssg-state_groupowner_system_commands_dirs_not_root_or_system_account:ste:1 oval:ssg-state_groupowner_system_commands_dirs_symlink:ste:1 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin|^\/usr\/libexec oval:ssg-state_owner_binaries_not_root:ste:1 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin|^\/usr\/libexec ^.*$ oval:ssg-state_owner_binaries_not_root:ste:1 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin|^\/usr\/libexec ^.*$ oval:ssg-state_perms_binary_files_nogroupwrite_noworldwrite:ste:1 oval:ssg-state_perms_binary_files_symlink:ste:1 /proc/cpuinfo ^flags[\s]+:.*[\s]+nx[\s]+.*$ 1 /proc/cmdline .+noexec[0-9]*=off.+ 1 /proc/sys/crypto/fips_enabled ^.*$ 1 /etc/sudoers ^(?!#).*[\s]+\!authenticate.*$ 1 /etc/sudoers.d ^.*$ ^(?!#).*[\s]+\!authenticate.*$ 1 /etc/sudoers ^(?!#).*[\s]+NOPASSWD[\s]*\:.*$ 1 /etc/sudoers.d ^.*$ ^(?!#).*[\s]+NOPASSWD[\s]*\:.*$ 1 ^/etc/sudoers(\.d/.*)?$ ^\s*ALL\s+ALL\=\(ALL\)\s+ALL\s*$ 1 ^/etc/sudoers(\.d/.*)?$ ^\s*ALL\s+ALL\=\(ALL\:ALL\)\s+ALL\s* 1 /etc/apt/apt.conf ^\s*clean_requirements_on_remove\s*=\s*(1|True|yes)\s*$ 1 /etc/security/pwquality.conf ^[\s]*enforcing = 1[\s]*$ 1 /etc/pam.d/common-auth ^\s*auth\s+required\s+pam_faildelay.so.*\sdelay=(-?[a-zA-Z0-9]+)(?:\s+.*)? 1 /etc/pam.d/system-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/security/faillock.conf 1 /etc/pam.d/system-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/security/faillock.conf 1 /etc/pam.d/system-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/pam.d/system-auth 1 /etc/pam.d/password-auth 1 /etc/security/faillock.conf 1 /etc/default/aide ^\s*SILENTREPORTS=(.+?)[ \t]*(?:$|#) 1 ^/etc/default/aide multi-user.target multi-user.target ^apparmor\.(socket|service)$ ActiveState apparmor-parser /etc/chrony/chrony.conf ^\s*makestep (.+?)[ \t]*(?:$|#) 1 ^/etc/chrony/chrony.conf /lib oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_group_ownership_library_dirs_0_0:ste:1 /lib64 oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_group_ownership_library_dirs_0_0:ste:1 /usr/lib oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_group_ownership_library_dirs_0_0:ste:1 /usr/lib64 oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_group_ownership_library_dirs_0_0:ste:1 /etc/group ^systemd-journal:\w+:(\w+):.* 1 /usr/lib/group ^systemd-journal:\w+:(\w+):.* 1 oval:ssg-object_file_groupownerdir_groupowner_system_journal_systemd-journal_gid_etc:obj:1 oval:ssg-object_file_groupownerdir_groupowner_system_journal_systemd-journal_gid_usr:obj:1 /run/log/journal oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_groupowner_system_journal_0_systemd-journal:ste:1 /var/log/journal oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_groupowner_system_journal_0_systemd-journal:ste:1 /bin oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_groupownership_binary_dirs_0_0:ste:1 /sbin oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_groupownership_binary_dirs_0_0:ste:1 /usr/bin oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_groupownership_binary_dirs_0_0:ste:1 /usr/sbin oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_groupownership_binary_dirs_0_0:ste:1 /usr/local/bin oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_groupownership_binary_dirs_0_0:ste:1 /usr/local/sbin oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerdir_groupownership_binary_dirs_0_0:ste:1 /run/log/journal oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_owner_system_journal_0_0:ste:1 /var/log/journal oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_owner_system_journal_0_0:ste:1 /bin oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_binary_dirs_0_0:ste:1 /sbin oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_binary_dirs_0_0:ste:1 /usr/bin oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_binary_dirs_0_0:ste:1 /usr/sbin oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_binary_dirs_0_0:ste:1 /usr/local/bin oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_binary_dirs_0_0:ste:1 /usr/local/sbin oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_binary_dirs_0_0:ste:1 /lib oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_library_dirs_0_0:ste:1 /lib64 oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_library_dirs_0_0:ste:1 /usr/lib oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_library_dirs_0_0:ste:1 /usr/lib64 oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownerdir_ownership_library_dirs_0_0:ste:1 /bin oval:ssg-exclude_symlinks_dir_permissions_binary_dirs:ste:1 oval:ssg-state_file_permissionsdir_permissions_binary_dirs_0_mode_0755or_stricter_:ste:1 /sbin oval:ssg-exclude_symlinks_dir_permissions_binary_dirs:ste:1 oval:ssg-state_file_permissionsdir_permissions_binary_dirs_1_mode_0755or_stricter_:ste:1 /usr/bin oval:ssg-exclude_symlinks_dir_permissions_binary_dirs:ste:1 oval:ssg-state_file_permissionsdir_permissions_binary_dirs_2_mode_0755or_stricter_:ste:1 /usr/sbin oval:ssg-exclude_symlinks_dir_permissions_binary_dirs:ste:1 oval:ssg-state_file_permissionsdir_permissions_binary_dirs_3_mode_0755or_stricter_:ste:1 /usr/local/bin oval:ssg-exclude_symlinks_dir_permissions_binary_dirs:ste:1 oval:ssg-state_file_permissionsdir_permissions_binary_dirs_4_mode_0755or_stricter_:ste:1 /usr/local/sbin oval:ssg-exclude_symlinks_dir_permissions_binary_dirs:ste:1 oval:ssg-state_file_permissionsdir_permissions_binary_dirs_5_mode_0755or_stricter_:ste:1 /run/log/journal oval:ssg-exclude_symlinks_dir_permissions_system_journal:ste:1 oval:ssg-state_file_permissionsdir_permissions_system_journal_0_mode_2750or_stricter_:ste:1 /var/log/journal oval:ssg-exclude_symlinks_dir_permissions_system_journal:ste:1 oval:ssg-state_file_permissionsdir_permissions_system_journal_1_mode_2750or_stricter_:ste:1 /usr/bin/journalctl oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupowner_journalctl_0_0:ste:1 /etc/group ^systemd-journal:\w+:(\w+):.* 1 /usr/lib/group ^systemd-journal:\w+:(\w+):.* 1 oval:ssg-object_file_groupowner_system_journal_systemd-journal_gid_etc:obj:1 oval:ssg-object_file_groupowner_system_journal_systemd-journal_gid_usr:obj:1 ^/var/log/journal/.*/system.journal$ oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupowner_system_journal_0_systemd-journal:ste:1 /var/log oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupowner_var_log_0_0:ste:1 /var/log/syslog oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupowner_var_log_syslog_0_4:ste:1 /etc/audit ^.*audit(\.rules|d\.conf)$ oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownership_audit_configuration_0_0:ste:1 /etc/audit/rules.d ^.*\.rules$ oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownership_audit_configuration_0_0:ste:1 /usr/bin/journalctl oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_owner_journalctl_0_0:ste:1 ^/var/log/journal/.*/system.journal$ oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_owner_system_journal_0_0:ste:1 /var/log oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_owner_var_log_0_0:ste:1 syslog /var/log/syslog oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_owner_var_log_syslog_0_syslog:ste:1 /sbin/auditctl oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_binaries_0_0:ste:1 /sbin/aureport oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_binaries_0_0:ste:1 /sbin/ausearch oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_binaries_0_0:ste:1 /sbin/autrace oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_binaries_0_0:ste:1 /sbin/auditd oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_binaries_0_0:ste:1 /sbin/audispd oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_binaries_0_0:ste:1 /sbin/augenrules oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_binaries_0_0:ste:1 /etc/audit ^.*audit(\.rules|d\.conf)$ oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_configuration_0_0:ste:1 /etc/audit/rules.d ^.*\.rules$ oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_audit_configuration_0_0:ste:1 /lib ^.*$ oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_library_dirs_0_0:ste:1 /lib64 ^.*$ oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_library_dirs_0_0:ste:1 /usr/lib ^.*$ oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_library_dirs_0_0:ste:1 /usr/lib64 ^.*$ oval:ssg-symlink_file_owner:ste:1 oval:ssg-state_file_ownership_library_dirs_0_0:ste:1 /sbin/auditctl oval:ssg-exclude_symlinks__audit_binaries:ste:1 oval:ssg-state_file_permissions_audit_binaries_0_mode_0755or_stricter_:ste:1 /sbin/aureport oval:ssg-exclude_symlinks__audit_binaries:ste:1 oval:ssg-state_file_permissions_audit_binaries_1_mode_0755or_stricter_:ste:1 /sbin/ausearch oval:ssg-exclude_symlinks__audit_binaries:ste:1 oval:ssg-state_file_permissions_audit_binaries_2_mode_0755or_stricter_:ste:1 /sbin/autrace oval:ssg-exclude_symlinks__audit_binaries:ste:1 oval:ssg-state_file_permissions_audit_binaries_3_mode_0755or_stricter_:ste:1 /sbin/auditd oval:ssg-exclude_symlinks__audit_binaries:ste:1 oval:ssg-state_file_permissions_audit_binaries_4_mode_0755or_stricter_:ste:1 /sbin/audispd oval:ssg-exclude_symlinks__audit_binaries:ste:1 oval:ssg-state_file_permissions_audit_binaries_5_mode_0755or_stricter_:ste:1 /sbin/augenrules oval:ssg-exclude_symlinks__audit_binaries:ste:1 oval:ssg-state_file_permissions_audit_binaries_6_mode_0755or_stricter_:ste:1 /etc/audit/auditd.conf oval:ssg-exclude_symlinks__etc_audit_auditd:ste:1 oval:ssg-state_file_permissions_etc_audit_auditd_0_mode_0640or_stricter_:ste:1 /etc/audit/audit.rules oval:ssg-exclude_symlinks__etc_audit_rules:ste:1 oval:ssg-state_file_permissions_etc_audit_rules_0_mode_0640or_stricter_:ste:1 /etc/audit/rules.d ^.*rules$ oval:ssg-exclude_symlinks__etc_audit_rulesd:ste:1 oval:ssg-state_file_permissions_etc_audit_rulesd_0_mode_0600or_stricter_:ste:1 /usr/bin/journalctl oval:ssg-exclude_symlinks__journalctl:ste:1 oval:ssg-state_file_permissions_journalctl_0_mode_0740or_stricter_:ste:1 /lib ^.*$ oval:ssg-exclude_symlinks__library_dirs:ste:1 oval:ssg-state_file_permissions_library_dirs_0_mode_7755or_stricter_:ste:1 /lib64 ^.*$ oval:ssg-exclude_symlinks__library_dirs:ste:1 oval:ssg-state_file_permissions_library_dirs_1_mode_7755or_stricter_:ste:1 /usr/lib ^.*$ oval:ssg-exclude_symlinks__library_dirs:ste:1 oval:ssg-state_file_permissions_library_dirs_2_mode_7755or_stricter_:ste:1 /usr/lib64 ^.*$ oval:ssg-exclude_symlinks__library_dirs:ste:1 oval:ssg-state_file_permissions_library_dirs_3_mode_7755or_stricter_:ste:1 ^/var/log/journal/.*/system.journal$ oval:ssg-exclude_symlinks__system_journal:ste:1 oval:ssg-state_file_permissions_system_journal_0_mode_0640or_stricter_:ste:1 /var/log oval:ssg-exclude_symlinks__var_log:ste:1 oval:ssg-state_file_permissions_var_log_0_mode_0755or_stricter_:ste:1 /var/log/syslog oval:ssg-exclude_symlinks__var_log_syslog:ste:1 oval:ssg-state_file_permissions_var_log_syslog_0_mode_0640or_stricter_:ste:1 ^.*\.conf$ ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 /etc/modprobe.conf ^\s*install\s+usb-storage\s+(/bin/false|/bin/true)$ 1 /var/log .* oval:ssg-exclude_symlinks_permissions_local_var_log:ste:1 oval:ssg-state_file_permissionspermissions_local_var_log_0_mode_0640or_stricter_:ste:1 /lib ^.*$ oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerroot_permissions_syslibrary_files_0_0:ste:1 /lib64 ^.*$ oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerroot_permissions_syslibrary_files_0_0:ste:1 /usr/lib ^.*$ oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerroot_permissions_syslibrary_files_0_0:ste:1 /usr/lib64 ^.*$ oval:ssg-symlink_file_groupowner:ste:1 oval:ssg-state_file_groupownerroot_permissions_syslibrary_files_0_0:ste:1 multi-user.target multi-user.target ^auditd\.(socket|service)$ ActiveState audit multi-user.target multi-user.target ^rsyslog\.(socket|service)$ ActiveState rsyslog multi-user.target multi-user.target ^sshd\.(socket|service)$ ActiveState openssh-server multi-user.target multi-user.target ^sssd\.(socket|service)$ ActiveState sssd-common multi-user.target multi-user.target ^ufw\.(socket|service)$ ActiveState ufw kernel.dmesg_restrict oval:ssg-object_static_etc_lib_sysctls_sysctl_kernel_dmesg_restrict:obj:1 oval:ssg-object_static_run_usr_local_sysctls_sysctl_kernel_dmesg_restrict:obj:1 oval:ssg-object_static_etc_sysctls_sysctl_kernel_dmesg_restrict:obj:1 oval:ssg-object_static_lib_sysctld_sysctl_kernel_dmesg_restrict:obj:1 oval:ssg-object_static_sysctl_sysctl_kernel_dmesg_restrict:obj:1 oval:ssg-object_static_etc_sysctld_sysctl_kernel_dmesg_restrict:obj:1 oval:ssg-object_static_usr_local_lib_sysctld_sysctl_kernel_dmesg_restrict:obj:1 oval:ssg-object_static_run_sysctld_sysctl_kernel_dmesg_restrict:obj:1 /etc/sysctl.conf ^[\s]*kernel.dmesg_restrict[\s]*=[\s]*(.*\S)[\s]*$ 1 /etc/sysctl.d ^.*\.conf$ ^[\s]*kernel.dmesg_restrict[\s]*=[\s]*(.*\S)[\s]*$ 1 /run/sysctl.d ^.*\.conf$ ^[\s]*kernel.dmesg_restrict[\s]*=[\s]*(.*\S)[\s]*$ 1 /usr/local/lib/sysctl.d ^.*\.conf$ ^[\s]*kernel.dmesg_restrict[\s]*=[\s]*(.*\S)[\s]*$ 1 /usr/lib/sysctl.d ^.*\.conf$ ^[\s]*kernel.dmesg_restrict[\s]*=[\s]*(.*\S)[\s]*$ 1 /lib/sysctl.d ^.*\.conf$ ^[\s]*kernel.dmesg_restrict[\s]*=[\s]*(.*\S)[\s]*$ 1 kernel.randomize_va_space oval:ssg-object_static_etc_lib_sysctls_sysctl_kernel_randomize_va_space:obj:1 oval:ssg-object_static_run_usr_local_sysctls_sysctl_kernel_randomize_va_space:obj:1 oval:ssg-object_static_etc_sysctls_sysctl_kernel_randomize_va_space:obj:1 oval:ssg-object_static_lib_sysctld_sysctl_kernel_randomize_va_space:obj:1 oval:ssg-object_static_sysctl_sysctl_kernel_randomize_va_space:obj:1 oval:ssg-object_static_etc_sysctld_sysctl_kernel_randomize_va_space:obj:1 oval:ssg-object_static_usr_local_lib_sysctld_sysctl_kernel_randomize_va_space:obj:1 oval:ssg-object_static_run_sysctld_sysctl_kernel_randomize_va_space:obj:1 /etc/sysctl.conf ^[\s]*kernel.randomize_va_space[\s]*=[\s]*(.*\S)[\s]*$ 1 /etc/sysctl.d ^.*\.conf$ ^[\s]*kernel.randomize_va_space[\s]*=[\s]*(.*\S)[\s]*$ 1 /run/sysctl.d ^.*\.conf$ ^[\s]*kernel.randomize_va_space[\s]*=[\s]*(.*\S)[\s]*$ 1 /usr/local/lib/sysctl.d ^.*\.conf$ ^[\s]*kernel.randomize_va_space[\s]*=[\s]*(.*\S)[\s]*$ 1 /usr/lib/sysctl.d ^.*\.conf$ ^[\s]*kernel.randomize_va_space[\s]*=[\s]*(.*\S)[\s]*$ 1 /lib/sysctl.d ^.*\.conf$ ^[\s]*kernel.randomize_va_space[\s]*=[\s]*(.*\S)[\s]*$ 1 net.ipv4.tcp_syncookies oval:ssg-object_static_etc_lib_sysctls_sysctl_net_ipv4_tcp_syncookies:obj:1 oval:ssg-object_static_run_usr_local_sysctls_sysctl_net_ipv4_tcp_syncookies:obj:1 oval:ssg-object_static_etc_sysctls_sysctl_net_ipv4_tcp_syncookies:obj:1 oval:ssg-object_static_lib_sysctld_sysctl_net_ipv4_tcp_syncookies:obj:1 oval:ssg-object_static_sysctl_sysctl_net_ipv4_tcp_syncookies:obj:1 oval:ssg-object_static_etc_sysctld_sysctl_net_ipv4_tcp_syncookies:obj:1 oval:ssg-object_static_usr_local_lib_sysctld_sysctl_net_ipv4_tcp_syncookies:obj:1 oval:ssg-object_static_run_sysctld_sysctl_net_ipv4_tcp_syncookies:obj:1 /etc/sysctl.conf ^[\s]*net.ipv4.tcp_syncookies[\s]*=[\s]*(.*\S)[\s]*$ 1 /etc/sysctl.d ^.*\.conf$ ^[\s]*net.ipv4.tcp_syncookies[\s]*=[\s]*(.*\S)[\s]*$ 1 /run/sysctl.d ^.*\.conf$ ^[\s]*net.ipv4.tcp_syncookies[\s]*=[\s]*(.*\S)[\s]*$ 1 /usr/local/lib/sysctl.d ^.*\.conf$ ^[\s]*net.ipv4.tcp_syncookies[\s]*=[\s]*(.*\S)[\s]*$ 1 /usr/lib/sysctl.d ^.*\.conf$ ^[\s]*net.ipv4.tcp_syncookies[\s]*=[\s]*(.*\S)[\s]*$ 1 /lib/sysctl.d ^.*\.conf$ ^[\s]*net.ipv4.tcp_syncookies[\s]*=[\s]*(.*\S)[\s]*$ 1 /etc/pam_pkcs11/pam_pkcs11.conf ^[\s]*use_mappers = pwent[\s]*$ 1 ^[\s]+"false"[\s]*;[\s]*$ maxpoll \d+ ca_cert,ocsp ^.*pam.*$ (?i)true userCertificate;binary 1 /etc/pam.d/fingerprint-auth /etc/authselect/fingerprint-auth /etc/pam.d/password-auth /etc/authselect/password-auth /etc/pam.d/postlogin /etc/authselect/postlogin /etc/pam.d/smartcard-auth /etc/authselect/smartcard-auth /etc/pam.d/system-auth /etc/authselect/system-auth 0 sha512 /etc/systemd/system/ctrl-alt-del.target /dev/null -1 ^(\!|\*).*$ 1 1 /etc/localtime ^(/usr)?/share/zoneinfo(/Etc)?/(GMT|UTC)$ UP false true ^/dev/.*$ 1000 symbolic link 0 true true symbolic link 1 1 ^no$ apparmor.service apparmor.socket active ^1 -1$ symbolic link symbolic link false false false false false false false false false false false false false false false false false false false false false false false false false false false false false false symbolic link false false false false false false false false false false false false symbolic link false false false false false false false false false false false false false false false false false false false false false false false false false false false false false false false false false false false symbolic link false false false false false false false false false symbolic link false false false false false false false false false symbolic link false false false false false false false false false false symbolic link false false false false false false false false symbolic link false false false false false false false false symbolic link false false false false false false false false false symbolic link false false false false false symbolic link false false false false false false false false false symbolic link false false false false false false false false false symbolic link auditd.service auditd.socket active rsyslog.service rsyslog.socket active sshd.service sshd.socket active sssd.service sssd.socket active ufw.service ufw.socket active 1 1 2 2 (?i) (?i) ^[\s]*auth[\s]+(?:required|requisite)[\s]+pam_faillock.so[^\n#]preauth[^\n#]*audit ^[\s]*auth[\s]+(?:required|requisite)[\s]+pam_faillock.so[^\n#]+preauth[^\n#]+silent ^ $ ^\s*auth\N+pam_unix\.so ^[\s]*auth[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\w\d=]+preauth[\s\S]*^[\s]*auth[\s]+(sufficient|\[(?=.*\bsuccess=done\b)(?=.*?\bnew_authtok_reqd=done\b)(?=.*?\bdefault=ignore\b).*\])[\s]+pam_unix\.so[\s\S]*^[\s]*auth[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\w\d=]+authfail ^[\s]*account[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\S]*^[\s]*account[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_unix\.so ^[\s]*auth[\s]+.+[\s]+pam_faillock.so[\s]+[^\n]*deny=([0-9]+) ^[\s]*deny[\s]*=[\s]*([0-9]+) ^\s*auth\N+pam_unix\.so ^[\s]*auth[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\w\d=]+preauth[\s\S]*^[\s]*auth[\s]+(sufficient|\[(?=.*\bsuccess=done\b)(?=.*?\bnew_authtok_reqd=done\b)(?=.*?\bdefault=ignore\b).*\])[\s]+pam_unix\.so[\s\S]*^[\s]*auth[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\w\d=]+authfail ^[\s]*account[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\S]*^[\s]*account[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_unix\.so ^[\s]*auth[\s]+.+[\s]+pam_faillock.so[\s]+[^\n]*fail_interval=([0-9]+) ^[\s]*fail_interval[\s]*=[\s]*([0-9]+) ^\s*auth\N+pam_unix\.so ^[\s]*auth[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\w\d=]+preauth[\s\S]*^[\s]*auth[\s]+(sufficient|\[(?=.*\bsuccess=done\b)(?=.*?\bnew_authtok_reqd=done\b)(?=.*?\bdefault=ignore\b).*\])[\s]+pam_unix\.so[\s\S]*^[\s]*auth[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\w\d=]+authfail ^[\s]*account[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_faillock\.so[\s\S]*^[\s]*account[\s]+(required|\[(?=.*?\bsuccess=ok\b)(?=.*?\bnew_authtok_reqd=ok\b)(?=.*?\bignore=ignore\b)(?=.*?\bdefault=bad\b).*\])[\s]+pam_unix\.so ^[\s]*auth[\s]+.+[\s]+pam_faillock.so[\s]+[^\n]*unlock_time=([0-9]+) ^[\s]*unlock_time[\s]*=[\s]*([0-9]+) 0 0 0 0 0 0 0 4 0 0 0 0 0 0 0 /etc/modprobe.d /etc/modules-load.d /run/modprobe.d /run/modules-load.d /usr/lib/modprobe.d /usr/lib/modules-load.d 0 build_shorthand.py from SCAP Security Guide ssg: 0.1.81 2.0 2026-04-01T21:16:40 Set Account Expiration Following Inactivity ocil:ssg-account_disable_post_pw_expiration_action:testaction:1 Assign Expiration Date to Temporary Accounts ocil:ssg-account_temp_expire_date_action:testaction:1 Limit the Number of Concurrent Login Sessions Allowed Per User ocil:ssg-accounts_max_concurrent_login_sessions_action:testaction:1 Set Password Maximum Age ocil:ssg-accounts_maximum_age_login_defs_action:testaction:1 Set Password Minimum Age ocil:ssg-accounts_minimum_age_login_defs_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Digit Characters ocil:ssg-accounts_password_pam_dcredit_action:testaction:1 Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words ocil:ssg-accounts_password_pam_dictcheck_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Different Characters ocil:ssg-accounts_password_pam_difok_action:testaction:1 Ensure PAM Enforces Password Requirements - Enforcing ocil:ssg-accounts_password_pam_enforcing_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters ocil:ssg-accounts_password_pam_lcredit_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Length ocil:ssg-accounts_password_pam_minlen_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Special Characters ocil:ssg-accounts_password_pam_ocredit_action:testaction:1 Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session ocil:ssg-accounts_password_pam_retry_action:testaction:1 Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters ocil:ssg-accounts_password_pam_ucredit_action:testaction:1 Set number of Password Hashing Rounds - password-auth ocil:ssg-accounts_password_pam_unix_rounds_password_auth_action:testaction:1 Enforce Delay After Failed Logon Attempts ocil:ssg-accounts_passwords_pam_faildelay_delay_action:testaction:1 Account Lockouts Must Be Logged ocil:ssg-accounts_passwords_pam_faillock_audit_action:testaction:1 Lock Accounts After Failed Password Attempts ocil:ssg-accounts_passwords_pam_faillock_deny_action:testaction:1 Set Interval For Counting Failed Password Attempts ocil:ssg-accounts_passwords_pam_faillock_interval_action:testaction:1 Do Not Show System Messages When Unsuccessful Logon Attempts Occur ocil:ssg-accounts_passwords_pam_faillock_silent_action:testaction:1 Set Lockout Time for Failed Password Attempts ocil:ssg-accounts_passwords_pam_faillock_unlock_time_action:testaction:1 Set Interactive Session Timeout ocil:ssg-accounts_tmout_action:testaction:1 Ensure the Default Umask is Set Correctly in login.defs ocil:ssg-accounts_umask_etc_login_defs_action:testaction:1 Build and Test AIDE Database ocil:ssg-aide_build_database_action:testaction:1 Configure AIDE to Verify the Audit Tools ocil:ssg-aide_check_audit_tools_action:testaction:1 Configure AIDE To Notify Personnel if Baseline Configurations Are Altered ocil:ssg-aide_disable_silentreports_action:testaction:1 Configure Periodic Execution of AIDE ocil:ssg-aide_periodic_cron_checking_action:testaction:1 Ensure AppArmor is Active and Configured ocil:ssg-apparmor_configured_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - chmod ocil:ssg-audit_rules_dac_modification_chmod_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - chown ocil:ssg-audit_rules_dac_modification_chown_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fchmod ocil:ssg-audit_rules_dac_modification_fchmod_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fchmodat ocil:ssg-audit_rules_dac_modification_fchmodat_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fchown ocil:ssg-audit_rules_dac_modification_fchown_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fchownat ocil:ssg-audit_rules_dac_modification_fchownat_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fremovexattr ocil:ssg-audit_rules_dac_modification_fremovexattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - fsetxattr ocil:ssg-audit_rules_dac_modification_fsetxattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - lchown ocil:ssg-audit_rules_dac_modification_lchown_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - lremovexattr ocil:ssg-audit_rules_dac_modification_lremovexattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - lsetxattr ocil:ssg-audit_rules_dac_modification_lsetxattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - removexattr ocil:ssg-audit_rules_dac_modification_removexattr_action:testaction:1 Record Events that Modify the System's Discretionary Access Controls - setxattr ocil:ssg-audit_rules_dac_modification_setxattr_action:testaction:1 Ensure auditd Collects Changes to Cron Jobs - /etc/cron.d/ ocil:ssg-audit_rules_etc_cron_d_action:testaction:1 Record Any Attempts to Run chacl ocil:ssg-audit_rules_execution_chacl_action:testaction:1 Record Any Attempts to Run chcon ocil:ssg-audit_rules_execution_chcon_action:testaction:1 Record Any Attempts to Run setfacl ocil:ssg-audit_rules_execution_setfacl_action:testaction:1 Ensure auditd Collects File Deletion Events by User - rename ocil:ssg-audit_rules_file_deletion_events_rename_action:testaction:1 Ensure auditd Collects File Deletion Events by User - renameat ocil:ssg-audit_rules_file_deletion_events_renameat_action:testaction:1 Ensure auditd Collects File Deletion Events by User - rmdir ocil:ssg-audit_rules_file_deletion_events_rmdir_action:testaction:1 Ensure auditd Collects File Deletion Events by User - unlink ocil:ssg-audit_rules_file_deletion_events_unlink_action:testaction:1 Ensure auditd Collects File Deletion Events by User - unlinkat ocil:ssg-audit_rules_file_deletion_events_unlinkat_action:testaction:1 Ensure auditd Collects Information on Kernel Module Unloading - delete_module ocil:ssg-audit_rules_kernel_module_loading_delete_action:testaction:1 Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module ocil:ssg-audit_rules_kernel_module_loading_finit_action:testaction:1 Ensure auditd Collects Information on Kernel Module Loading - init_module ocil:ssg-audit_rules_kernel_module_loading_init_action:testaction:1 Record Attempts to Alter Logon and Logout Events - faillog ocil:ssg-audit_rules_login_events_faillog_action:testaction:1 Record Attempts to Alter Logon and Logout Events - lastlog ocil:ssg-audit_rules_login_events_lastlog_action:testaction:1 Record Any Attempts to Run apparmor_parser ocil:ssg-audit_rules_privileged_commands_apparmor_parser_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - chage ocil:ssg-audit_rules_privileged_commands_chage_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - chfn ocil:ssg-audit_rules_privileged_commands_chfn_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - chsh ocil:ssg-audit_rules_privileged_commands_chsh_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - crontab ocil:ssg-audit_rules_privileged_commands_crontab_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - fdisk ocil:ssg-audit_rules_privileged_commands_fdisk_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd ocil:ssg-audit_rules_privileged_commands_gpasswd_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - kmod ocil:ssg-audit_rules_privileged_commands_kmod_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - modprobe ocil:ssg-audit_rules_privileged_commands_modprobe_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - mount ocil:ssg-audit_rules_privileged_commands_mount_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - newgrp ocil:ssg-audit_rules_privileged_commands_newgrp_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check ocil:ssg-audit_rules_privileged_commands_pam_timestamp_check_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - passwd ocil:ssg-audit_rules_privileged_commands_passwd_action:testaction:1 Record Any Attempts to Run ssh-agent ocil:ssg-audit_rules_privileged_commands_ssh_agent_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign ocil:ssg-audit_rules_privileged_commands_ssh_keysign_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - su ocil:ssg-audit_rules_privileged_commands_su_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - sudo ocil:ssg-audit_rules_privileged_commands_sudo_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - sudoedit ocil:ssg-audit_rules_privileged_commands_sudoedit_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - umount ocil:ssg-audit_rules_privileged_commands_umount_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - unix_update ocil:ssg-audit_rules_privileged_commands_unix_update_action:testaction:1 Ensure auditd Collects Information on the Use of Privileged Commands - usermod ocil:ssg-audit_rules_privileged_commands_usermod_action:testaction:1 Record Attempts to Alter Process and Session Initiation Information btmp ocil:ssg-audit_rules_session_events_btmp_action:testaction:1 Record Attempts to Alter Process and Session Initiation Information utmp ocil:ssg-audit_rules_session_events_utmp_action:testaction:1 Record Attempts to Alter Process and Session Initiation Information wtmp ocil:ssg-audit_rules_session_events_wtmp_action:testaction:1 Ensure auditd Collects System Administrator Actions - /etc/sudoers ocil:ssg-audit_rules_sudoers_action:testaction:1 Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/ ocil:ssg-audit_rules_sudoers_d_action:testaction:1 Record Events When Privileged Executables Are Run ocil:ssg-audit_rules_suid_privilege_function_action:testaction:1 Record Unsuccessful Access Attempts to Files - creat ocil:ssg-audit_rules_unsuccessful_file_modification_creat_action:testaction:1 Record Unsuccessful Access Attempts to Files - ftruncate ocil:ssg-audit_rules_unsuccessful_file_modification_ftruncate_action:testaction:1 Record Unsuccessful Access Attempts to Files - open ocil:ssg-audit_rules_unsuccessful_file_modification_open_action:testaction:1 Record Unsuccessful Access Attempts to Files - open_by_handle_at ocil:ssg-audit_rules_unsuccessful_file_modification_open_by_handle_at_action:testaction:1 Record Unsuccessful Access Attempts to Files - openat ocil:ssg-audit_rules_unsuccessful_file_modification_openat_action:testaction:1 Record Unsuccessful Access Attempts to Files - truncate ocil:ssg-audit_rules_unsuccessful_file_modification_truncate_action:testaction:1 Record Events that Modify User/Group Information - /etc/group ocil:ssg-audit_rules_usergroup_modification_group_action:testaction:1 Record Events that Modify User/Group Information - /etc/gshadow ocil:ssg-audit_rules_usergroup_modification_gshadow_action:testaction:1 Record Events that Modify User/Group Information - /etc/security/opasswd ocil:ssg-audit_rules_usergroup_modification_opasswd_action:testaction:1 Record Events that Modify User/Group Information - /etc/passwd ocil:ssg-audit_rules_usergroup_modification_passwd_action:testaction:1 Record Events that Modify User/Group Information - /etc/shadow ocil:ssg-audit_rules_usergroup_modification_shadow_action:testaction:1 Ensure auditd Collects records for events that affect "/var/log/journal" ocil:ssg-audit_rules_var_log_journal_action:testaction:1 Ensure auditd Collects Changes to Cron Jobs - /var/spool/cron ocil:ssg-audit_rules_var_spool_cron_action:testaction:1 Record Attempts to perform maintenance activities ocil:ssg-audit_sudo_log_events_action:testaction:1 Configure audispd Plugin To Send Logs To Remote Server ocil:ssg-auditd_audispd_configure_remote_server_action:testaction:1 Configure a Sufficiently Large Partition for Audit Logs ocil:ssg-auditd_audispd_configure_sufficiently_large_partition_action:testaction:1 Configure auditd Disk Full Action when Disk Space Is Full ocil:ssg-auditd_data_disk_full_action_action:testaction:1 Configure auditd mail_acct Action on Low Disk Space ocil:ssg-auditd_data_retention_action_mail_acct_action:testaction:1 Configure auditd space_left Action on Low Disk Space ocil:ssg-auditd_data_retention_space_left_action_action:testaction:1 Configure auditd space_left on Low Disk Space ocil:ssg-auditd_data_retention_space_left_percentage_action:testaction:1 Offload audit Logs to External Media ocil:ssg-auditd_offload_logs_action:testaction:1 Modify the System Login Banner for Remote Connections ocil:ssg-banner_etc_issue_net_action:testaction:1 Enable NX or XD Support in the BIOS ocil:ssg-bios_enable_execution_restrictions_action:testaction:1 Configure Time Service Maxpoll Interval ocil:ssg-chronyd_or_ntpd_set_maxpoll_action:testaction:1 Synchronize internal information system clocks ocil:ssg-chronyd_sync_clock_action:testaction:1 Ensure apt_get Removes Previous Package Versions ocil:ssg-clean_components_post_updating_action:testaction:1 Claroty CTD must accept the DOD CAC or other PKI credential for identity management and personal authentication. ocil:ssg-ctd5_accept_dod_cac_or_pki_for_authentication_action:testaction:1 Claroty CTD must alert the information system security officer (ISSO), information system security manager (ISSM), and other individuals designated by the local organization when events are detected that indicate a compromise or potential for compromise. ocil:ssg-ctd5_alert_isso_issm_on_compromise_events_action:testaction:1 Claroty CTD must allocate audit record storage retention length. ocil:ssg-ctd5_allocate_audit_record_storage_retention_action:testaction:1 Claroty CTD must only allow authorized local accounts as documented in the System Security Plan (SSP). ocil:ssg-ctd5_allow_only_authorized_local_accounts_action:testaction:1 Before establishing a network connection with a Network Time Protocol (NTP) server, Claroty CTD must authenticate using a bidirectional, cryptographically based authentication method that uses a FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to authenticate with the NTP server. ocil:ssg-ctd5_authenticate_ntp_with_bidirectional_crypto_action:testaction:1 Change Default Administrator Password ocil:ssg-ctd5_change_default_admin_password_action:testaction:1 Claroty CTD must configure local password policies. ocil:ssg-ctd5_configure_local_password_policies_action:testaction:1 Claroty CTD must have disk encryption enabled on virtual machines (VMs). ocil:ssg-ctd5_disk_encryption_enabled_for_vms_action:testaction:1 Claroty CTD must display the Standard Mandatory DOD Notice and Consent Banner before granting local or remote access to the system. ocil:ssg-ctd5_display_dod_banner_before_system_access_action:testaction:1 The publicly accessible Claroty CTD application must display the Standard Mandatory DOD Notice and Consent Banner before granting access to Claroty CTD. ocil:ssg-ctd5_display_dod_banner_before_web_access_action:testaction:1 Claroty CTD must configure idle timeouts at 10 minutes. ocil:ssg-ctd5_idle_timeout_10_minutes_action:testaction:1 Claroty CTD must have notification and audit services operational. ocil:ssg-ctd5_notification_and_audit_services_operational_action:testaction:1 Claroty CTD must notify system administrators and information system security officer (ISSO) of local account activity. ocil:ssg-ctd5_notify_admins_and_isso_of_local_account_activity_action:testaction:1 Claroty CTD must only allow the use of DOD PKI established certificate authorities for verification of the establishment of protected sessions. ocil:ssg-ctd5_only_allow_dod_pki_certificate_authorities_action:testaction:1 Claroty CTD must allow only the individuals appointed by the information system security manager (ISSM) to have full admin rights to the system. ocil:ssg-ctd5_only_issm_appointed_admins_have_full_rights_action:testaction:1 Claroty CTD must limit privileges and restrict administrative shell access. ocil:ssg-ctd5_restrict_administrative_shell_access_action:testaction:1 Claroty CTD must be configured to send backup audit records. ocil:ssg-ctd5_send_backup_audit_records_action:testaction:1 The Claroty CTD Syslog client must use TCP connections. ocil:ssg-ctd5_syslog_client_uses_tcp_action:testaction:1 Claroty CTD must use FIPS-validated encryption and hashing algorithms to protect the confidentiality and integrity of application configuration files and user-generated data stored or aggregated on the device. ocil:ssg-ctd5_use_fips_validated_encryption_and_hashing_action:testaction:1 Claroty CTD must use an Identity Provider (IDP) for authentication and authorization processes. ocil:ssg-ctd5_use_identity_provider_for_authentication_action:testaction:1 Enable GNOME3 Login Warning Banner ocil:ssg-dconf_gnome_banner_enabled_action:testaction:1 Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3 ocil:ssg-dconf_gnome_disable_ctrlaltdel_reboot_action:testaction:1 Set the GNOME3 Login Warning Banner Text ocil:ssg-dconf_gnome_login_banner_text_action:testaction:1 Set GNOME3 Screensaver Inactivity Timeout ocil:ssg-dconf_gnome_screensaver_idle_delay_action:testaction:1 Set GNOME3 Screensaver Lock Delay After Activation Period ocil:ssg-dconf_gnome_screensaver_lock_delay_action:testaction:1 Enable GNOME3 Screensaver Lock After Idle Period ocil:ssg-dconf_gnome_screensaver_lock_enabled_action:testaction:1 Verify that Shared Library Directories Have Root Group Ownership ocil:ssg-dir_group_ownership_library_dirs_action:testaction:1 Verify that system commands directories are group owned by root ocil:ssg-dir_groupownership_binary_dirs_action:testaction:1 Verify that System Executable Have Root Ownership ocil:ssg-dir_ownership_binary_dirs_action:testaction:1 Verify that Shared Library Directories Have Root Ownership ocil:ssg-dir_ownership_library_dirs_action:testaction:1 Verify that System Executable Directories Have Restrictive Permissions ocil:ssg-dir_permissions_binary_dirs_action:testaction:1 Verify that All World-Writable Directories Have Sticky Bits Set ocil:ssg-dir_perms_world_writable_sticky_bits_action:testaction:1 System Audit Logs Must Have Mode 0750 or Less Permissive ocil:ssg-directory_permissions_var_log_audit_action:testaction:1 Disable Ctrl-Alt-Del Reboot Activation ocil:ssg-disable_ctrlaltdel_reboot_action:testaction:1 Encrypt Partitions ocil:ssg-encrypt_partitions_action:testaction:1 Ensure real-time clock is set to UTC ocil:ssg-ensure_rtc_utc_configuration_action:testaction:1 Ensure sudo group has only necessary members ocil:ssg-ensure_sudo_group_restricted_action:testaction:1 Verify Group Who Owns the system journal ocil:ssg-file_groupowner_system_journal_action:testaction:1 Verify Group Who Owns /var/log Directory ocil:ssg-file_groupowner_var_log_action:testaction:1 Verify Group Who Owns /var/log/syslog File ocil:ssg-file_groupowner_var_log_syslog_action:testaction:1 Audit Configuration Files Must Be Owned By Group root ocil:ssg-file_groupownership_audit_configuration_action:testaction:1 Verify that system commands files are group owned by root or a system account ocil:ssg-file_groupownership_system_commands_dirs_action:testaction:1 Verify Owner on the system journal ocil:ssg-file_owner_system_journal_action:testaction:1 Verify User Who Owns /var/log Directory ocil:ssg-file_owner_var_log_action:testaction:1 Verify User Who Owns /var/log/syslog File ocil:ssg-file_owner_var_log_syslog_action:testaction:1 Verify that audit tools are owned by root ocil:ssg-file_ownership_audit_binaries_action:testaction:1 Audit Configuration Files Must Be Owned By Root ocil:ssg-file_ownership_audit_configuration_action:testaction:1 Verify that System Executables Have Root Ownership ocil:ssg-file_ownership_binary_dirs_action:testaction:1 Verify that Shared Library Files Have Root Ownership ocil:ssg-file_ownership_library_dirs_action:testaction:1 System Audit Logs Must Be Owned By Root ocil:ssg-file_ownership_var_log_audit_stig_action:testaction:1 Verify that audit tools Have Mode 0755 or less ocil:ssg-file_permissions_audit_binaries_action:testaction:1 Verify that System Executables Have Restrictive Permissions ocil:ssg-file_permissions_binary_dirs_action:testaction:1 Verify Permissions on /etc/audit/auditd.conf ocil:ssg-file_permissions_etc_audit_auditd_action:testaction:1 Verify Permissions on /etc/audit/audit.rules ocil:ssg-file_permissions_etc_audit_rules_action:testaction:1 Verify Permissions on /etc/audit/rules.d/*.rules ocil:ssg-file_permissions_etc_audit_rulesd_action:testaction:1 Verify that Shared Library Files Have Restrictive Permissions ocil:ssg-file_permissions_library_dirs_action:testaction:1 Verify Permissions on the system journal ocil:ssg-file_permissions_system_journal_action:testaction:1 Verify Permissions on /var/log Directory ocil:ssg-file_permissions_var_log_action:testaction:1 Verify Permissions on /var/log/syslog File ocil:ssg-file_permissions_var_log_syslog_action:testaction:1 Enable Auditing for Processes Which Start Prior to the Audit Daemon ocil:ssg-grub2_audit_argument_action:testaction:1 Set Boot Loader Password in grub2 ocil:ssg-grub2_password_action:testaction:1 Set the UEFI Boot Loader Password ocil:ssg-grub2_uefi_password_action:testaction:1 Install Smart Card Packages For Multifactor Authentication ocil:ssg-install_smartcard_packages_action:testaction:1 The Installed Operating System Is Vendor Supported ocil:ssg-installed_OS_is_vendor_supported_action:testaction:1 Verify '/proc/sys/crypto/fips_enabled' exists ocil:ssg-is_fips_mode_enabled_action:testaction:1 Disable Modprobe Loading of USB Storage Driver ocil:ssg-kernel_module_usb-storage_disabled_action:testaction:1 Prevent Login to Accounts With Empty Password ocil:ssg-no_empty_passwords_action:testaction:1 Ensure There Are No Accounts With Blank or Null Passwords ocil:ssg-no_empty_passwords_etc_shadow_action:testaction:1 Install AIDE ocil:ssg-package_aide_installed_action:testaction:1 Ensure the default plugins for the audit dispatcher are Installed ocil:ssg-package_audit-audispd-plugins_installed_action:testaction:1 Ensure the audit Subsystem is Installed ocil:ssg-package_audit_installed_action:testaction:1 The Chrony package is installed ocil:ssg-package_chrony_installed_action:testaction:1 Uninstall nfs-common Package ocil:ssg-package_nfs-common_removed_action:testaction:1 Uninstall nfs-kernel-server Package ocil:ssg-package_nfs-kernel-server_removed_action:testaction:1 Install the opensc Package For Multifactor Authentication ocil:ssg-package_opensc_installed_action:testaction:1 Install the OpenSSH Server Package ocil:ssg-package_openssh-server_installed_action:testaction:1 Install pam_pwquality Package ocil:ssg-package_pam_pwquality_installed_action:testaction:1 Uninstall rsh-server Package ocil:ssg-package_rsh-server_removed_action:testaction:1 Install the SSSD Package ocil:ssg-package_sssd_installed_action:testaction:1 Install ufw Package ocil:ssg-package_ufw_installed_action:testaction:1 Verify permissions of log files ocil:ssg-permissions_local_var_log_action:testaction:1 Direct root Logins Are Not Allowed ocil:ssg-prevent_direct_root_logins_action:testaction:1 Verify the system-wide library files in directories "/lib", "/lib64", "/usr/lib/" and "/usr/lib64" are group-owned by root. ocil:ssg-root_permissions_syslibrary_files_action:testaction:1 Ensure remote access methods are monitored in Rsyslog ocil:ssg-rsyslog_remote_access_monitoring_action:testaction:1 Enable auditd Service ocil:ssg-service_auditd_enabled_action:testaction:1 Disable KDump Kernel Crash Analyzer (kdump) ocil:ssg-service_kdump_disabled_action:testaction:1 Enable rsyslog Service ocil:ssg-service_rsyslog_enabled_action:testaction:1 Enable the OpenSSH Service ocil:ssg-service_sshd_enabled_action:testaction:1 Enable the SSSD Service ocil:ssg-service_sssd_enabled_action:testaction:1 Verify ufw Enabled ocil:ssg-service_ufw_enabled_action:testaction:1 Set Password Hashing Algorithm in /etc/login.defs ocil:ssg-set_password_hashing_algorithm_logindefs_action:testaction:1 Configure Smart Card Certificate Authority Validation ocil:ssg-smartcard_configure_ca_action:testaction:1 Configure Smart Card Certificate Status Checking ocil:ssg-smartcard_configure_cert_checking_action:testaction:1 Configure Smart Card Local Cache of Revocation Data ocil:ssg-smartcard_configure_crl_action:testaction:1 Enable Smart Card Logins in PAM ocil:ssg-smartcard_pam_enabled_action:testaction:1 Disable SSH Access via Empty Passwords ocil:ssg-sshd_disable_empty_passwords_action:testaction:1 Disable X11 Forwarding ocil:ssg-sshd_disable_x11_forwarding_action:testaction:1 Do Not Allow SSH Environment Options ocil:ssg-sshd_do_not_permit_user_env_action:testaction:1 Enable PAM ocil:ssg-sshd_enable_pam_action:testaction:1 Enable Public Key Authentication ocil:ssg-sshd_enable_pubkey_auth_action:testaction:1 Enable SSH Warning Banner ocil:ssg-sshd_enable_warning_banner_net_action:testaction:1 Set SSH Client Alive Interval ocil:ssg-sshd_set_idle_timeout_action:testaction:1 Set SSH Client Alive Count Max ocil:ssg-sshd_set_keepalive_action:testaction:1 Use Only FIPS 140-2 Validated Ciphers ocil:ssg-sshd_use_approved_ciphers_ordered_stig_action:testaction:1 Use Only FIPS 140-2 Validated Key Exchange Algorithms ocil:ssg-sshd_use_approved_kex_ordered_stig_action:testaction:1 Use Only FIPS 140-2 Validated MACs ocil:ssg-sshd_use_approved_macs_ordered_stig_action:testaction:1 Prevent remote hosts from connecting to the proxy display ocil:ssg-sshd_x11_use_localhost_action:testaction:1 Certificate trust path in SSSD ocil:ssg-sssd_certification_path_trust_anchor_action:testaction:1 Configure PAM in SSSD Services ocil:ssg-sssd_enable_pam_services_action:testaction:1 Enable Smartcards in SSSD ocil:ssg-sssd_enable_smartcards_action:testaction:1 Configure SSSD to Expire Offline Credentials ocil:ssg-sssd_offline_cred_expiration_action:testaction:1 Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate ocil:ssg-sudo_remove_no_authenticate_action:testaction:1 Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD ocil:ssg-sudo_remove_nopasswd_action:testaction:1 The operating system must restrict privilege elevation to authorized personnel ocil:ssg-sudo_restrict_privilege_elevation_to_authorized_action:testaction:1 Restrict Access to Kernel Message Buffer ocil:ssg-sysctl_kernel_dmesg_restrict_action:testaction:1 Enable Randomized Layout of Virtual Address Space ocil:ssg-sysctl_kernel_randomize_va_space_action:testaction:1 Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces ocil:ssg-sysctl_net_ipv4_tcp_syncookies_action:testaction:1 Only Allow Authorized Network Services in ufw ocil:ssg-ufw_only_required_services_action:testaction:1 ufw Must rate-limit network interfaces ocil:ssg-ufw_rate_limit_action:testaction:1 Verify that 'use_mappers' is set to 'pwent' in PAM ocil:ssg-verify_use_mappers_action:testaction:1 Check that vlock is installed to allow session locking ocil:ssg-vlock_installed_action:testaction:1 Deactivate Wireless Network Interfaces ocil:ssg-wireless_disable_interfaces_action:testaction:1 PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL PASS FAIL To verify the INACTIVE setting, run the following command: $ grep "INACTIVE" /etc/default/useradd The output should indicate the INACTIVE configuration option is set to an appropriate integer as shown in the example below: $ grep "INACTIVE" /etc/default/useradd INACTIVE= Is it the case that the value of INACTIVE is greater than the expected value or is -1? Verify that temporary accounts have been provisioned with an expiration date of 72 hours. For every temporary account, run the following command to obtain its account aging and expiration information: $ sudo chage -l temporary_account_name Verify each of these accounts has an expiration date set within 72 hours or as documented. Is it the case that any temporary accounts have no expiration date set or do not expire within 72 hours? Verify Claroty CTD 5.x limits the number of concurrent sessions to "" for all accounts and/or account types with the following command: $ grep -r -s maxlogins /etc/security/limits.conf /etc/security/limits.d/*.conf /etc/security/limits.conf:* hard maxlogins 10 This can be set as a global domain (with the * wildcard) but may be set differently for multiple domains. Is it the case that the "maxlogins" item is missing, commented out, or the value is set greater than "<sub idref="var_accounts_max_concurrent_login_sessions" />" and is not documented with the Information System Security Officer (ISSO) as an operational requirement for all domains that have the "maxlogins" item assigned'? Verify that Claroty CTD 5.x enforces a -day maximum password lifetime for new user accounts by running the following command: $ grep -i pass_max_days /etc/login.defs PASS_MAX_DAYS Is it the case that the "PASS_MAX_DAYS" parameter value is greater than "<sub idref="var_accounts_maximum_age_login_defs" />", or commented out? Verify Claroty CTD 5.x enforces 24 hours/one day as the minimum password lifetime for new user accounts. Check for the value of "PASS_MIN_DAYS" in "/etc/login.defs" with the following command: $ grep -i pass_min_days /etc/login.defs PASS_MIN_DAYS Is it the case that the "PASS_MIN_DAYS" parameter value is not "<sub idref="var_accounts_minimum_age_login_defs" />" or greater, or is commented out? Verify that Claroty CTD 5.x enforces password complexity by requiring that at least one numeric character be used. Check the value for "dcredit" with the following command: $ sudo grep dcredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf /etc/security/pwquality.conf:dcredit = Is it the case that the value of "dcredit" is a positive number or is commented out? Verify Claroty CTD 5.x prevents the use of dictionary words for passwords with the following command: $ sudo grep dictcheck /etc/security/pwquality.conf /etc/pwquality.conf.d/*.conf /etc/security/pwquality.conf:dictcheck=1 Is it the case that "dictcheck" does not have a value other than "0", or is commented out? Verify the value of the "difok" option in "/etc/security/pwquality.conf" with the following command: $ sudo grep difok /etc/security/pwquality.conf difok = Is it the case that the value of "difok" is set to less than "<sub idref="var_password_pam_difok" />", or is commented out? To verify that enforcing is correctly applied, run the following command: $ grep -i enforcing /etc/security/pwquality.conf The output should return enforcing = 1 uncommented. Is it the case that enforcing is not uncommented or configured correctly? Verify that Claroty CTD 5.x enforces password complexity by requiring that at least one lower-case character. Check the value for "lcredit" with the following command: $ sudo grep lcredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf /etc/security/pwquality.conf:lcredit = -1 Is it the case that the value of "lcredit" is a positive number or is commented out? Verify that Claroty CTD 5.x enforces a minimum -character password length with the following command: $ grep minlen /etc/security/pwquality.conf minlen = Is it the case that the command does not return a "minlen" value of "<sub idref="var_password_pam_minlen" />" or greater, does not return a line, or the line is commented out? Verify that Claroty CTD 5.x enforces password complexity by requiring that at least one special character with the following command: $ sudo grep ocredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf ocredit = Is it the case that value of "ocredit" is a positive number or is commented out? Verify Claroty CTD 5.x is configured to limit the "pwquality" retry option to . Check for the use of the "pwquality" retry option in the PAM files with the following command: $ grep pam_pwquality /etc/pam.d/system-auth password requisite pam_pwquality.so retry= Is it the case that the value of "retry" is set to "0" or greater than "<sub idref="var_password_pam_retry" />", or is missing? Verify that Claroty CTD 5.x enforces password complexity by requiring that at least one upper-case character. Check the value for "ucredit" with the following command: $ sudo grep ucredit /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf ucredit = -1 Is it the case that the value of "ucredit" is a positive number or is commented out? To verify the number of rounds for the password hashing algorithm is configured, run the following command: $ sudo grep rounds /etc/pam.d/password-auth The output should show the following match: password sufficient pam_unix.so sha512 rounds= Is it the case that rounds is not set to <sub idref="var_password_pam_unix_rounds" /> or is commented out? Verify that the Claroty CTD 5.x operating system enforces a minimum delay between logon prompts following a failed logon attempt. # grep pam_faildelay /etc/pam.d/common-auth auth required pam_faildelay.so delay= If the value of delay is not set to or greater, "delay" is commented out, "delay" is missing, or the "pam_faildelay" line is missing completely, this is a finding. Is it the case that the value of delay is not set properly or the line is commented or missing? Verify the "/etc/security/faillock.conf" file is configured to log user name information when unsuccessful logon attempts occur: $ sudo grep audit /etc/security/faillock.conf audit Is it the case that the "audit" option is not set, is missing or commented out? Verify Claroty CTD 5.x is configured to lock an account after unsuccessful logon attempts with the command: $ grep 'deny =' /etc/security/faillock.conf deny = . Is it the case that the "deny" option is not set to "<sub idref="var_accounts_passwords_pam_faillock_deny" />" or less (but not "0"), is missing or commented out? To ensure the failed password attempt policy is configured correctly, run the following command: $ grep fail_interval /etc/security/faillock.conf The output should show fail_interval = <interval-in-seconds> where interval-in-seconds is or greater. Is it the case that the "fail_interval" option is not set to "<sub idref="var_accounts_passwords_pam_faillock_fail_interval" />" or less (but not "0"), the line is commented out, or the line is missing? To ensure that the system prevents messages from being shown when three unsuccessful logon attempts occur, run the following command: $ grep silent /etc/security/faillock.conf The output should show silent. Is it the case that the system shows messages when three unsuccessful logon attempts occur? Verify Claroty CTD 5.x is configured to lock an account until released by an administrator after unsuccessful logon attempts with the command: $ grep 'unlock_time =' /etc/security/faillock.conf unlock_time = Is it the case that the "unlock_time" option is not set to "<sub idref="var_accounts_passwords_pam_faillock_unlock_time" />", the line is missing, or commented out? Run the following command to ensure the TMOUT value is configured for all users on the system: $ sudo grep TMOUT /etc/profile /etc/profile.d/*.sh The output should return the following: TMOUT= Is it the case that the TMOUT value is not configured, is set to 0, or is not less than or equal to the expected setting? Verify Claroty CTD 5.x defines default permissions for all authenticated users in such a way that the user can only read and modify their own files with the following command: # grep -i umask /etc/login.defs UMASK Is it the case that the value for the "UMASK" parameter is not "<sub idref="var_accounts_user_umask" />", or the "UMASK" parameter is missing or is commented out? To find the location of the AIDE database file, run the following command: $ sudo ls -l DBDIR/database_file_name Is it the case that there is no database file? Check that AIDE is properly configured to protect the integrity of the audit tools by running the following command: # sudo cat /etc/aide/aide.conf | grep /usr/sbin/au /usr/sbin/auditctl p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/auditd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/ausearch p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/aureport p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/autrace p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/audispd p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 /usr/sbin/augenrules p+i+n+u+g+s+b+acl+selinux+xattrs+sha512 If AIDE is configured properly to protect the integrity of the audit tools, all lines listed above will be returned from the command. If one or more lines are missing, this is a finding. Is it the case that integrity checks of the audit tools are missing or incomplete? Verify that Advanced Intrusion Detection Environment (AIDE) notifies the System Administrator when anomalies in the operation of any security functions are discovered with the following command: # grep SILENTREPORTS /etc/default/aide SILENTREPORTS=no If SILENTREPORTS is commented out, this is a finding. If SILENTREPORTS is set to "yes", this is a finding. If SILENTREPORTS is not set to "no", this is a finding. Is it the case that silentreports is enabled in aide default configuration, or is missing? Verify the operating system routinely checks the baseline configuration for unauthorized changes. To determine that periodic AIDE execution has been scheduled, run the following command: $ grep aide /etc/crontab The output should return something similar to the following: 05 4 * * * root /usr/bin/aide --check NOTE: The usage of special cron times, such as @daily or @weekly, is acceptable. Is it the case that AIDE is not configured to scan periodically? Run the following command to determine the current status of the apparmor service: $ sudo systemctl is-active apparmor If the service is running, it should return the following: active Is it the case that it is not? To determine if the system is configured to audit calls to the chmod system call, run the following command: $ sudo grep "chmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the chown system call, run the following command: $ sudo grep "chown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fchmod system call, run the following command: $ sudo grep "fchmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fchmodat system call, run the following command: $ sudo grep "fchmodat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fchown system call, run the following command: $ sudo grep "fchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fchownat system call, run the following command: $ sudo grep "fchownat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fremovexattr system call, run the following command: $ sudo grep "fremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the fsetxattr system call, run the following command: $ sudo grep "fsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the lchown system call, run the following command: $ sudo grep "lchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the lremovexattr system call, run the following command: $ sudo grep "lremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the lsetxattr system call, run the following command: $ sudo grep "lsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the removexattr system call, run the following command: $ sudo grep "removexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the setxattr system call, run the following command: $ sudo grep "setxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/cron.d/" with the following command: $ sudo auditctl -l | grep /etc/cron.d/ -w /etc/cron.d/ -p wa -k cronjobs Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "chacl" command with the following command: $ sudo auditctl -l | grep chacl -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "chcon" command with the following command: $ sudo auditctl -l | grep chcon -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "setfacl" command with the following command: $ sudo auditctl -l | grep setfacl -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod Is it the case that the command does not return a line, or the line is commented out? To determine if the system is configured to audit calls to the rename system call, run the following command: $ sudo grep "rename" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the renameat system call, run the following command: $ sudo grep "renameat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the rmdir system call, run the following command: $ sudo grep "rmdir" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the unlink system call, run the following command: $ sudo grep "unlink" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the unlinkat system call, run the following command: $ sudo grep "unlinkat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the delete_module system call, run the following command: $ sudo grep "delete_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the finit_module system call, run the following command: $ sudo grep "finit_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? To determine if the system is configured to audit calls to the init_module system call, run the following command: $ sudo grep "init_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/faillog" with the following command: $ sudo auditctl -l | grep /var/log/faillog -w /var/log/faillog -p wa -k logins Is it the case that there is no output? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/lastlog" with the following command: $ sudo auditctl -l | grep /var/log/lastlog -w /var/log/lastlog -p wa -k logins Is it the case that the command does not return a line, or the line is commented out? To verify that execution of the command is being audited, run the following command: sudo auditctl -l | grep apparmor_parser The output should return something similar to: -a always,exit -F path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged Is it the case that ? Verify that Claroty CTD 5.x is configured to audit the execution of the "chage" command with the following command: $ sudo auditctl -l | grep chage -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chage Is it the case that the command does not return a line, or the line is commented out? To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chfn /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "chsh" command with the following command: $ sudo auditctl -l | grep chsh -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chsh Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "crontab" command with the following command: $ sudo auditctl -l | grep crontab -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -k privileged-crontab Is it the case that the command does not return a line, or the line is commented out? To verify that auditing of privileged command use is configured, run the following command: $ sudo auditctl -l | grep fdisk -w /sbin/fdisk -p x -k fdisk If the command does not return a line, or the line is commented out, this is a finding. Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "gpasswd" command with the following command: $ sudo auditctl -l | grep gpasswd -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-gpasswd Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "kmod" command with the following command: $ sudo auditctl -l | grep kmod -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -k privileged-kmod Is it the case that the command does not return a line, or the line is commented out? To verify that auditing of privileged command use is configured, run the following command: sudo auditctl -l | grep -w '/sbin/modprobe' -w /sbin/modprobe -p x -k modules It should return a relevant line in the audit rules. Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "mount" command with the following command: $ sudo auditctl -l | grep mount -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-mount Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "newgrp" command with the following command: $ sudo auditctl -l | grep newgrp -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -k privileged-newgrp Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "pam_timestamp_check" command with the following command: $ sudo auditctl -l | grep pam_timestamp_check -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pam_timestamp_check Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "passwd" command with the following command: $ sudo auditctl -l | grep passwd -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-passwd Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "ssh-agent" command with the following command: $ sudo auditctl -l | grep ssh-agent -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "ssh-keysign" command with the following command: $ sudo auditctl -l | grep ssh-keysign -a always,exit -F path=/usr/libexec/openssh/ssh-keysignssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-keysign Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "su" command with the following command: $ sudo auditctl -l | grep su -a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged-su Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "sudo" command with the following command: $ sudo auditctl -l | grep sudo -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k privileged-sudo Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "sudoedit" command with the following command: $ sudo auditctl -l | grep sudoedit -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -k privileged-sudoedit Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "umount" command with the following command: $ sudo auditctl -l | grep umount -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -k privileged-umount Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "unix_update" command with the following command: $ sudo auditctl -l | grep unix_update -a always,exit -F path=/usr/bin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix_update Is it the case that the command does not return a line, or the line is commented out? Verify that Claroty CTD 5.x is configured to audit the execution of the "usermod" command with the following command: $ sudo auditctl -l | grep usermod -a always,exit -F path=/usr/bin/usermod -F perm=x -F auid>=1000 -F auid!=unset -k privileged-usermod Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/btmp" with the following command: $ sudo auditctl -l | grep /var/log/btmp -w /var/log/btmp -p wa -k session Is it the case that Audit rule is not present? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/run/utmp" with the following command: $ sudo auditctl -l | grep /var/run/utmp -w /var/run/utmp -p wa -k session Is it the case that Audit rule is not present? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/wtmp" with the following command: $ sudo auditctl -l | grep /var/log/wtmp -w /var/log/wtmp -p wa -k session Is it the case that Audit rule is not present? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/sudoers" with the following command: $ sudo auditctl -l | grep /etc/sudoers -w /etc/sudoers -p wa -k actions Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/sudoers.d/" with the following command: $ sudo auditctl -l | grep /etc/sudoers.d/ -w /etc/sudoers.d/ -p wa -k actions Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x audits the execution of privileged functions. Check if Claroty CTD 5.x is configured to audit the execution of the "execve" system call using the following command: $ sudo grep execve /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid Is it the case that the command does not return all lines, or the lines are commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the creat system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r creat /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep creat /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the ftruncate system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r ftruncate /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep ftruncate /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the open system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r open /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep open /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the open_by_handle_at system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r open_by_handle_at /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep open_by_handle_at /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the openat system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r openat /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep openat /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates an audit record for unsuccessful attempts to use the truncate system call. If the auditd daemon is configured to use the "augenrules" program to to read audit rules during daemon startup (the default), run the following command: $ sudo grep -r truncate /etc/audit/rules.d If the auditd daemon is configured to use the "auditctl" utility to read audit rules during daemon startup, run the following command: $ sudo grep truncate /etc/audit/audit.rules The output should be the following: -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k access Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/group" with the following command: $ sudo auditctl -l | grep /etc/group -w /etc/group -p wa -k audit_rules_usergroup_modification Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/gshadow" with the following command: $ sudo auditctl -l | grep /etc/gshadow -w /etc/gshadow -p wa -k audit_rules_usergroup_modification Is it the case that the system is not configured to audit account changes? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/security/opasswd" with the following command: $ sudo auditctl -l | grep /etc/security/opasswd -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/passwd" with the following command: $ sudo auditctl -l | grep /etc/passwd -w /etc/passwd -p wa -k audit_rules_usergroup_modification Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/etc/shadow" with the following command: $ sudo auditctl -l | grep /etc/shadow -w /etc/shadow -p wa -k audit_rules_usergroup_modification Is it the case that command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/journal" with the following command: $ sudo auditctl -l | grep /var/log/journal -w /var/log/journal -p wa -k systemd_journal Is it the case that the command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/spool/cron" with the following command: $ sudo auditctl -l | grep /var/spool/cron -w /var/spool/cron -p wa -k cronjobs Is it the case that command does not return a line, or the line is commented out? Verify Claroty CTD 5.x generates audit records for all events that affect "/var/log/sudo.log" with the following command: $ sudo auditctl -l | grep /var/log/sudo.log -w /var/log/sudo.log -p wa -k maintenance Is it the case that Audit rule is not present? To verify the audispd plugin off-loads audit records onto a different system or media from the system being audited, run the following command: $ sudo grep -i remote_server /etc/audit/audisp-remote.conf The output should return something similar to remote_server = Is it the case that audispd is not sending logs to a remote system? To verify whether audispd plugin off-loads audit records onto a different system or media from the system being audited, run the following command: $ sudo grep -i remote_server /etc/audit/audisp-remote.conf The output should return something similar to where REMOTE_SYSTEM is an IP address or hostname: remote_server = REMOTE_SYSTEM Determine which partition the audit records are being written to with the following command: $ sudo grep log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Check the size of the partition that audit records are written to with the following command and verify whether it is sufficiently large: $ sudo df -h /var/log/audit/ /dev/sda2 24G 10.4G 13.6G 43% /var/log/audit Is it the case that audispd is not sending logs to a remote system and the local partition has inadequate space? Verify Claroty CTD 5.x takes the appropriate action when the audit storage volume is full. Check that Claroty CTD 5.x takes the appropriate action when the audit storage volume is full with the following command: $ sudo grep disk_full_action /etc/audit/auditd.conf disk_full_action = If the value of the "disk_full_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, ask the system administrator to indicate how the system takes appropriate action when an audit storage volume is full. Is it the case that there is no evidence of appropriate action? Verify that Claroty CTD 5.x is configured to notify the SA and/or ISSO (at a minimum) in the event of an audit processing failure with the following command: $ sudo grep action_mail_acct /etc/audit/auditd.conf action_mail_acct = Is it the case that the value of the "action_mail_acct" keyword is not set to "<sub idref="var_auditd_action_mail_acct" />" and/or other accounts for security personnel, the "action_mail_acct" keyword is missing, or the returned line is commented out, ask the system administrator to indicate how they and the ISSO are notified of an audit process failure. If there is no evidence of the proper personnel being notified of an audit processing failure? Verify Claroty CTD 5.x notifies the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity with the following command: $ sudo grep -w space_left_action /etc/audit/auditd.conf space_left_action = If the value of the "space_left_action" is not set to "", or if the line is commented out, ask the System Administrator to indicate how the system is providing real-time alerts to the SA and ISSO. Is it the case that there is no evidence that real-time alerts are configured on the system? Verify Claroty CTD 5.x takes action when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity with the following command: $ sudo grep -w space_left /etc/audit/auditd.conf space_left = % Is it the case that the value of the "space_left" keyword is not set to <sub idref="var_auditd_space_left_percentage" />% of the storage volume allocated to audit logs, or if the line is commented out, ask the System Administrator to indicate how the system is providing real-time alerts to the SA and ISSO. If the "space_left" value is not configured to the correct value? Verify there is a script that offloads audit data and that script runs weekly. Check if there is a script in the "/etc/cron.weekly" directory that offloads audit data: # sudo ls /etc/cron.weekly audit-offload Check if the script inside the file does offloading of audit logs to external media. If the script file does not exist or does not offload audit logs, this is a finding. Is it the case that Cron job has not been configured to offload audit logs to external media? To check if the system login banner is compliant, run the following command: $ cat /etc/issue.net Is it the case that it does not display the required banner? Verify the NX (no-execution) bit flag is set on the system. Check that the no-execution bit flag is set with the following commands: $ sudo dmesg | grep NX [ 0.000000] NX (Execute Disable) protection: active If "dmesg" does not show "NX (Execute Disable) protection" active, check the cpuinfo settings with the following command: $ sudo grep flags /proc/cpuinfo flags : fpu vme de pse tsc ms nx rdtscp lm constant_ts The output should contain the "nx" flag. Is it the case that NX is disabled? Verify Claroty CTD 5.x is securely comparing internal information system clocks at a regular interval with an NTP server with the following command: $ sudo grep maxpoll /etc/ntp.conf /etc/chrony/chrony.conf /etc/chrony/conf.d/ server [ntp.server.name] iburst maxpoll . Is it the case that "maxpoll" has not been set to the value of "<sub idref="var_time_service_set_maxpoll" />", is commented out, or is missing? Verify the operating system synchronizes internal system clocks to the authoritative time source when the time difference is greater than one second. Check the value of "makestep" by running the following command: $ sudo grep makestep /etc/chrony/chrony.conf makestep 1 -1 If it is not set to the above value, edit the /etc/chrony/chrony.conf file and add: makestep 1 -1 Restart the chrony service: $ sudo systemctl restart chrony.service Is it the case that ? Verify Claroty CTD 5.x removes all software components after updated versions have been installed. $ grep clean_requirements_on_remove /etc/apt/apt.conf clean_requirements_on_remove=1 Is it the case that '"clean_requirements_on_remove" is not set to "1"'? Review Claroty CTD authentication configuration. Verify the platform accepts the DoD CAC or another approved PKI credential for identity management and personal authentication where required by the deployment. If CAC or PKI authentication is required but not supported or not configured, this is a finding. Is it the case that Claroty CTD does not accept approved CAC or PKI credentials for authentication where required? Review Claroty CTD alerting and notification settings for compromise-related events. Verify the ISSO, ISSM, and other designated personnel are notified when events indicate a compromise or potential compromise. If required compromise-event alerts are not configured, this is a finding. Is it the case that Claroty CTD does not alert designated personnel when compromise-related events are detected? Review Claroty CTD audit storage and retention settings. Verify the platform allocates and retains audit records for the length of time required by the organization. If audit record storage retention is not configured appropriately, this is a finding. Is it the case that Claroty CTD audit record storage retention is not configured as required? Review the configured Claroty CTD local accounts and compare them to the accounts documented in the System Security Plan (SSP). Verify only authorized local accounts exist on the platform. If unauthorized or undocumented local accounts are present, this is a finding. Is it the case that Claroty CTD contains undocumented or unauthorized local accounts? Review Claroty CTD time synchronization settings and the configured NTP trust model. Verify the platform authenticates to the NTP server using a bidirectional, cryptographically based method that uses a FIPS-validated AES cipher block algorithm where required. If NTP authentication is not configured as required, this is a finding. Is it the case that Claroty CTD does not use bidirectional cryptographic authentication with its NTP server? Log in to the Claroty CTD 5.x administrative console. Open the administrator menu and review the Change Password function. Verify the default administrative password has been changed to an organization-approved value. If the default administrative password is still in use, this is a finding. Is it the case that the default Claroty CTD 5.x administrative password has not been changed? Review Claroty CTD local password policy settings. Verify the platform enforces the organization-approved password policy for local accounts, including complexity, length, and related controls where required. If local password policies are not configured appropriately, this is a finding. Is it the case that Claroty CTD local password policies are not configured as required? Determine whether Claroty CTD is deployed as a virtual machine. If so, review the virtualization and storage configuration and verify disk encryption is enabled for the CTD virtual disks. If Claroty CTD is deployed as a VM without disk encryption, this is a finding. Is it the case that disk encryption is not enabled for the Claroty CTD virtual machine? Access the Claroty CTD login interface and any local or remote system access entry points. Verify the Standard Mandatory DOD Notice and Consent Banner is displayed before access is granted. If the required banner is not displayed, this is a finding. Is it the case that Claroty CTD does not display the Standard Mandatory DOD Notice and Consent Banner before system access? Open the Claroty CTD web login page. Verify the Standard Mandatory DOD Notice and Consent Banner is displayed before the user is granted access to the application. If the required banner is not displayed, this is a finding. Is it the case that the Claroty CTD web application does not display the Standard Mandatory DOD Notice and Consent Banner before login? Review the Claroty CTD administrative session timeout configuration. Verify the platform is configured to terminate or lock idle sessions after no more than 10 minutes of inactivity. If the timeout exceeds 10 minutes or is not configured, this is a finding. Is it the case that Claroty CTD does not enforce a 10-minute idle session timeout? Review the Claroty CTD audit and notification service status. Verify audit collection, audit storage, and platform notification services are enabled and operational. If required notification or audit services are not operational, this is a finding. Is it the case that Claroty CTD notification or audit services are not operational? Review Claroty CTD alerting and notification settings for local account activity. Verify system administrators and the ISSO are notified of local account activity in accordance with site policy. If required notifications are not configured, this is a finding. Is it the case that Claroty CTD does not notify administrators and the ISSO of local account activity? Log in to the Claroty CTD administrative console. Review the Upload Certificate configuration under OS Configuration > Manage. Verify the certificate chain used for protected sessions is issued by DoD PKI-established certificate authorities where required by the deployment. If unapproved certificate authorities are trusted for protected sessions, this is a finding. Is it the case that Claroty CTD trusts certificate authorities that are not approved for protected sessions? Review the list of Claroty CTD accounts with full administrative privileges. Verify each individual with full administrative rights is appointed by the information system security manager (ISSM). If unapproved users have full administrative rights, this is a finding. Is it the case that individuals without ISSM appointment have full administrative rights in Claroty CTD? Review Claroty CTD administrative access methods and privilege assignments. Verify administrative shell access is restricted to authorized personnel and unavailable to users who do not require it. If unnecessary shell access or excessive privilege exists, this is a finding. Is it the case that Claroty CTD permits unnecessary administrative shell access or excessive privileges? Review Claroty CTD audit backup and export settings. Verify backup audit records are sent or otherwise preserved in accordance with organizational requirements. If backup audit records are not configured, this is a finding. Is it the case that Claroty CTD is not configured to send or preserve backup audit records? Review Claroty CTD syslog forwarding settings. Verify any configured syslog client uses TCP connections for remote log transmission. If syslog forwarding uses a noncompliant transport, this is a finding. Is it the case that the Claroty CTD syslog client is not configured to use TCP connections? Log in to the Claroty CTD administrative console. Open the administrator menu and review the displayed platform status. Verify the platform shows Fips Mode: Enabled and that deployed cryptographic protections rely on FIPS-validated algorithms. If FIPS mode is not enabled or approved cryptographic protections are not in use, this is a finding. Is it the case that Claroty CTD is not using FIPS-validated encryption and hashing mechanisms for stored data? Review Claroty CTD authentication and authorization settings. Verify an approved identity provider is configured and used for authentication and authorization processes. If the system relies only on unmanaged local authentication where an IDP is required, this is a finding. Is it the case that Claroty CTD is not configured to use an approved identity provider? To ensure a login warning banner is enabled, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/* If properly configured, the output should be true. To ensure a login warning banner is locked and cannot be changed by a user, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-enable. Is it the case that it is not? To ensure the system is configured to ignore the Ctrl-Alt-Del sequence, run the following command: $ gsettings get org.gnome.settings-daemon.plugins.media-keys logout $ grep logout /etc/dconf/db/local.d/locks/* If properly configured, the output should be /org/gnome/settings-daemon/plugins/media-keys/logout Is it the case that GNOME3 is configured to reboot when Ctrl-Alt-Del is pressed? To ensure the login warning banner text is properly set, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/* If properly configured, the proper banner text will appear. To ensure the login warning banner text is locked and cannot be changed by a user, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-text. Is it the case that it does not? To check the current idle time-out value, run the following command: $ gsettings get org.gnome.desktop.session idle-delay If properly configured, the output should be 'uint32 '. To ensure that users cannot change the screensaver inactivity timeout setting, run the following: $ grep idle-delay /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/desktop/session/idle-delay Is it the case that idle-delay is set to 0 or a value greater than <sub idref="inactivity_timeout_value" />? To check that the screen locks immediately when activated, run the following command: $ gsettings get org.gnome.desktop.screensaver lock-delay If properly configured, the output should be 'uint32 '. Is it the case that the screensaver lock delay is missing, or is set to a value greater than <sub idref="var_screensaver_lock_delay" />? To check the status of the idle screen lock activation, run the following command: $ gsettings get org.gnome.desktop.screensaver lock-enabled If properly configured, the output should be true. To ensure that users cannot change how long until the screensaver locks, run the following: $ grep lock-enabled /etc/dconf/db/gdm.d/locks/* If properly configured, the output for lock-enabled should be /org/gnome/desktop/screensaver/lock-enabled Is it the case that screensaver locking is not enabled and/or has not been set or configured correctly? Verify the system-wide shared library directories are group-owned by "root" with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 ! -group root -type d -exec stat -c "%n %G" '{}' \; If any system-wide shared library directory is returned and is not group-owned by a required system account, this is a finding. Is it the case that any system-wide shared library directory is returned and is not group-owned by a required system account? System commands are stored in the following directories: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin For each of these directories, run the following command to find files not owned by root group: $ sudo find -L $DIR ! -group root -type d \; Is it the case that any of these directories are not owned by root group? System executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/local/bin /usr/local/sbin /usr/sbin For each of these directories, run the following command to find files not owned by root: $ sudo find -L DIR/ ! -user root -type d -exec chown root {} \; Is it the case that any system executables directories are found to not be owned by root? Verify the system-wide shared library directories are owned by "root" with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 ! -user root -type d -exec stat -c "%n %U" '{}' \; Is it the case that any system-wide shared library directory is not owned by root? System executables are stored in the following directories by default: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin To find system executables directories that are group-writable or world-writable, run the following command for each directory DIR which contains system executables: $ sudo find -L DIR -perm /022 -type d Is it the case that any of these files are group-writable or world-writable? To find world-writable directories that lack the sticky bit, run the following command: $ sudo find / -type d \( -perm -0002 -a ! -perm -1000 \) -print 2>/dev/null fixtext: |- Configure all world-writable directories to have the sticky bit set to prevent unauthorized and unintended information transferred via shared system resources. Set the sticky bit on all world-writable directories using the command, replace "[World-Writable Directory]" with any directory path missing the sticky bit: $ chmod a+t [World-Writable Directory] srg_requirement: A sticky bit must be set on all Claroty CTD 5.x public directories to prevent unauthorized and unintended information transferred via shared system resources. Is it the case that any world-writable directories are missing the sticky bit? Verify the audit log directories have a correct mode or less permissive mode. Find the location of the audit logs: $ sudo grep "^log_file" /etc/audit/auditd.conf Find the group that owns audit logs: $ sudo grep "^log_group" /etc/audit/auditd.conf Run the following command to check the mode of the system audit logs: $ sudo stat -c "%a %n" [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit". If the log_group is "root" or is not set, the correct permissions are 0700, otherwise they are 0750. Is it the case that audit logs have a more permissive mode? To ensure the system is configured to mask the Ctrl-Alt-Del sequence, Check that the ctrl-alt-del.target is masked and not active with the following command: sudo systemctl status ctrl-alt-del.target The output should indicate that the target is masked and not active. It might resemble following output: ctrl-alt-del.target Loaded: masked (/dev/null; bad) Active: inactive (dead) Is it the case that the system is configured to reboot when Ctrl-Alt-Del is pressed? Check the system partitions to determine if they are encrypted with the following command: blkid Output will be similar to: /dev/sda1: UUID=" ab12c3de-4f56-789a-8f33-3850cc8ce3a2 " TYPE="crypto_LUKS" /dev/sda2: UUID=" bc98d7ef-6g54-321h-1d24-9870de2ge1a2 " TYPE="crypto_LUKS" The boot partition and pseudo-file systems, such as /proc, /sys, and tmpfs, are not required to use disk encryption and are not a finding. Is it the case that partitions do not have a type of crypto_LUKS? To verify that the system real-time clock is set to UTC or GMT, run the following command: # timedatectl status | grep -i timezone Timezone: UTC (UTC, +0000) If "Timezone" is not set to UTC, this is a finding. Fix Text: Configure the SUSE operating system is configured to use UTC. To configure the system time zone to use UTC or GMT, run the following command, replacing [ZONE] with "UTC" or "GMT". # sudo timedatectl set-timezone [ZONE] Is it the case that the system real-time clock is not configured to use UTC as its time base? Configure the sudo group with only members requiring access to security functions. To remove a user from the sudo group, run: $ sudo gpasswd -d username sudo Is it the case that sudo group contains users not needing access to security functions? To check the group ownership of /var/log/journal/.*/system.journal, run the command: $ ls -lL /var/log/journal/.*/system.journal If properly configured, the output should indicate the following group-owner: systemd-journal Is it the case that /var/log/journal/.*/system.journal does not have a group owner of systemd-journal ? To check the group ownership of /var/log, run the command: $ ls -lL /var/log If properly configured, the output should indicate the following group-owner: root Is it the case that /var/log does not have a group owner of root ? To check the group ownership of /var/log/syslog, run the command: $ ls -lL /var/log/syslog If properly configured, the output should indicate the following group-owner: adm Is it the case that /var/log/syslog does not have a group owner of adm ? To properly set the group owner of /etc/audit/, run the command: $ sudo chgrp root /etc/audit/ To properly set the group owner of /etc/audit/rules.d/, run the command: $ sudo chgrp root /etc/audit/rules.d/ Is it the case that ? Verify the system commands contained in the following directories are group-owned by "root", or a required system account, with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -exec ls -l {} \; Is it the case that any system commands are returned and is not group-owned by a required system account? To check the ownership of /var/log/journal/.*/system.journal, run the command: $ ls -lL /var/log/journal/.*/system.journal If properly configured, the output should indicate the following owner: root Is it the case that /var/log/journal/.*/system.journal does not have an owner of root? To check the ownership of /var/log, run the command: $ ls -lL /var/log If properly configured, the output should indicate the following owner: root Is it the case that /var/log does not have an owner of root? To check the ownership of /var/log/syslog, run the command: $ ls -lL /var/log/syslog If properly configured, the output should indicate the following owner: syslog Is it the case that /var/log/syslog does not have an owner of syslog? Verify it by running the following command: $ stat -c "%n %U" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules root If the command does not return all the above lines, the missing ones need to be added. Run the following command to correct the permissions of the missing entries: $ sudo chown root [audit_tool] Replace "[audit_tool]" with each audit tool not owned by root. Is it the case that ? To properly set the owner of /etc/audit/, run the command: $ sudo chown root /etc/audit/ To properly set the owner of /etc/audit/rules.d/, run the command: $ sudo chown root /etc/audit/rules.d/ Is it the case that ? Verify the system commands contained in the following directories are owned by "root" with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/libexec /usr/local/bin /usr/local/sbin ! -user root -exec ls -l {} \; Is it the case that any system commands are found to not be owned by root? Verify the system-wide shared library files are owned by "root" with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 ! -user root -exec ls -l {} \; Is it the case that any system wide shared library file is not owned by root? Verify the audit logs are owned by "root". First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the location of the audit log file, determine if the audit log is owned by "root" using the following command: $ sudo stat -c "%n %U" /var/log/audit/audit.log Audit logs must be owned by user root. If the log_file isn't defined in /etc/audit/auditd.conf, check all files in /var/log/audit/ directory instead. Is it the case that the audit log is not owned by root? Verify it by running the following command: $ stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl 755 /sbin/aureport 755 /sbin/ausearch 755 /sbin/autrace 755 /sbin/auditd 755 /sbin/audispd 755 /sbin/augenrules 755 If the command does not return all the above lines, the missing ones need to be added. Run the following command to correct the permissions of the missing entries: $ sudo chmod 0755 [audit_tool] Replace "[audit_tool]" with the audit tool that does not have the correct permissions. Is it the case that ? Verify the system commands contained in the following directories have mode "755" or less permissive with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/libexec /usr/local/bin /usr/local/sbin -perm /022 -exec ls -l {} \; Is it the case that any system commands are found to be group-writable or world-writable? To check the permissions of /etc/audit/auditd.conf, run the command: $ ls -l /etc/audit/auditd.conf If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /etc/audit/auditd.conf does not have unix mode -rw-r-----? To check the permissions of /etc/audit/audit.rules, run the command: $ ls -l /etc/audit/audit.rules If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /etc/audit/audit.rules does not have unix mode -rw-r-----? To check the permissions of /etc/audit/rules.d/*.rules, run the command: $ ls -l /etc/audit/rules.d/*.rules If properly configured, the output should indicate the following permissions: -rw------- Is it the case that /etc/audit/rules.d/*.rules does not have unix mode -rw-------? Verify the system-wide shared library files contained in the following directories have mode "755" or less permissive with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 -perm /022 -type f -exec ls -l {} \; Is it the case that any system-wide shared library file is found to be group-writable or world-writable? To check the permissions of /var/log/journal/.*/system.journal, run the command: $ ls -l /var/log/journal/.*/system.journal If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /var/log/journal/.*/system.journal does not have unix mode -rw-r-----? To check the permissions of /var/log, run the command: $ ls -l /var/log If properly configured, the output should indicate the following permissions: drwxr-xr-x Is it the case that /var/log does not have unix mode drwxr-xr-x? To check the permissions of /var/log/syslog, run the command: $ ls -l /var/log/syslog If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /var/log/syslog does not have unix mode -rw-r-----? Inspect the form of default GRUB 2 command line for the Linux operating system in grubenv that can be found either in /boot/grub in case of legacy BIOS systems, or in /boot/efi/EFI/ubuntu in case of UEFI systems. If they include audit=1, then the parameter is configured at boot time. $ sudo grep 'kernelopts.*audit=1.*' GRUBENV_FILE_LOCATION Fill in GRUBENV_FILE_LOCATION based on information above. Is it the case that auditing is not enabled at boot time? First, check whether the password is defined in either /boot/grub/user.cfg or /boot/grub/grub.cfg. Run the following commands: $ sudo grep '^[\s]*GRUB2_PASSWORD=grub\.pbkdf2\.sha512.*$' /boot/grub/user.cfg $ sudo grep '^[\s]*password_pbkdf2[\s]+.*[\s]+grub\.pbkdf2\.sha512.*$' /boot/grub/grub.cfg Second, check that a superuser is defined in /boot/grub/grub.cfg. $ sudo grep '^[\s]*set[\s]+superusers=("?)[a-zA-Z_]+\1$' /boot/grub/grub.cfg Is it the case that it does not produce any output? To verify the boot loader superuser password has been set, run the following command: $ sudo grep "^[\s]*GRUB2_PASSWORD=grub\.pbkdf2\.sha512.*$" /boot/efi/EFI/ubuntu/user.cfg The output should be similar to: GRUB2_PASSWORD=grub.pbkdf2.sha512.10000.C4E08AC72FBFF7E837FD267BFAD7AEB3D42DDC 2C99F2A94DD5E2E75C2DC331B719FE55D9411745F82D1B6CFD9E927D61925F9BBDD1CFAA0080E0 916F7AB46E0D.1302284FCCC52CD73BA3671C6C12C26FF50BA873293B24EE2A96EE3B57963E6D7 0C83964B473EC8F93B07FE749AA6710269E904A9B08A6BBACB00A2D242AD828 Is it the case that no password is set? Check that Claroty CTD 5.x has the packages for smart card support installed. Run the following command to determine if the openssl-pkcs11 package is installed: $ dpkg -l openssl-pkcs11 Is it the case that smartcard software is not installed? To verify that the installed operating system is supported, run the following command: Claroty CTD 5.x Is it the case that the installed operating system is not supported? To verify /proc/sys/crypto/fips_enabled exists, run the following command: cat /proc/sys/crypto/fips_enabled The output should be: 1 Is it the case that the command 'cat /proc/sys/crypto/fips_enabled' returns nothing or '0' or the file does not exist? If the system is configured to prevent the loading of the usb-storage kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated /etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d Is it the case that no line is returned? To verify that null passwords cannot be used, run the following command: $ grep nullok /etc/pam.d/system-auth /etc/pam.d/password-auth If this produces any output, it may be possible to log into accounts with empty passwords. Remove any instances of the nullok option to prevent logins with empty passwords. Is it the case that NULL passwords can be used? To verify that null passwords cannot be used, run the following command: $ sudo awk -F: '!$2 {print $1}' /etc/shadow If this produces any output, it may be possible to log into accounts with empty passwords. Is it the case that Blank or NULL passwords can be used? Run the following command to determine if the aide package is installed: $ dpkg -l aide Is it the case that the package is not installed? Is it the case that the package is not installed? Run the following command to determine if the audit package is installed: $ dpkg -l audit Is it the case that the audit package is not installed? Run the following command to determine if the chrony package is installed: $ dpkg -l chrony Is it the case that the package is not installed? Run the following command to determine if the nfs-common package is installed: $ dpkg -l nfs-common Is it the case that the package is installed? Run the following command to determine if the nfs-kernel-server package is installed: $ dpkg -l nfs-kernel-server Is it the case that the package is installed? Run the following command to determine if the opensc package is installed: $ dpkg -l opensc Is it the case that the package is not installed? Run the following command to determine if the openssh-server package is installed: $ dpkg -l openssh-server Is it the case that the package is not installed? Run the following command to determine if the libpwquality package is installed: $ dpkg -l libpwquality Is it the case that the package is not installed? Run the following command to determine if the rsh-server package is installed: $ dpkg -l rsh-server Is it the case that the package is installed? Run the following command to determine if the sssd package is installed: $ dpkg -l sssd Is it the case that the package is not installed? Run the following command to determine if the ufw package is installed: $ dpkg -l ufw Is it the case that the package is not installed? Verify the operating system has all system log files under the /var/log directory with a permission set to 640, by using the following command: sudo find /var/log -perm /137 -type f -exec stat -c "%n %a" {} \; Is it the case that not all log files have permission 640 or stricter? Verify the operating system prevents direct logins to the root account with the following command: $ sudo passwd -S root root L 04/23/2020 0 99999 7 -1 If the output does not contain "L" in the second field to indicate the account is locked, then run the following command: $ sudo passwd -l root Is it the case that the output does not contain "L" in the second field? Verify the system-wide shared library files are group-owned by root with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 ! -group root -exec ls -l {} \; Is it the case that any system wide shared library file is returned and is not group-owned by root? To verify that remote access methods are logging to rsyslog, run the following command: grep -rE '(auth.\*|authpriv.\*|daemon.\*)' /etc/rsyslog.* The output should contain auth.*, authpriv.*, and daemon.* pointing to a log file. Is it the case that remote access methods are not logging to rsyslog? Run the following command to determine the current status of the auditd service: $ sudo systemctl is-active auditd If the service is running, it should return the following: active Is it the case that the auditd service is not running? To check that the kdump service is disabled in system boot configuration, run the following command: $ sudo systemctl is-enabled kdump Output should indicate the kdump service has either not been installed, or has been disabled at all runlevels, as shown in the example below: $ sudo systemctl is-enabled kdump disabled Run the following command to verify kdump is not active (i.e. not running) through current runtime configuration: $ sudo systemctl is-active kdump If the service is not running the command will return the following output: inactive The service will also be masked, to check that the kdump is masked, run the following command: $ sudo systemctl show kdump | grep "LoadState\|UnitFileState" If the service is masked the command will return the following outputs: LoadState=masked UnitFileState=masked Is it the case that the "kdump" is loaded and not masked? Run the following command to determine the current status of the rsyslog service: $ sudo systemctl is-active rsyslog If the service is running, it should return the following: active Is it the case that the "rsyslog" service is disabled, masked, or not started.? Run the following command to determine the current status of the sshd service: $ sudo systemctl is-active sshd If the service is running, it should return the following: active Is it the case that sshd service is disabled? Run the following command to determine the current status of the sssd service: $ sudo systemctl is-active sssd If the service is running, it should return the following: active Is it the case that the service is not enabled? Run the following command to determine the current status of the ufw service: $ sudo systemctl is-active ufw If the service is running, it should return the following: active Is it the case that the service is not enabled? Verify that the shadow password suite configuration is set to encrypt password with a FIPS 140-2 approved cryptographic hashing algorithm. Check the hashing algorithm that is being used to hash passwords with the following command: $ sudo grep -i ENCRYPT_METHOD /etc/login.defs ENCRYPT_METHOD Is it the case that ENCRYPT_METHOD is not set to <sub idref="var_password_hashing_algorithm" />? To verify the operating system implements certificate status checking for PKI authentication, run the following command: $ sudo grep -i cert_policy /etc/pam_pkcs11/pam_pkcs11.conf The output should return multiple lines similar to the following: cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; Is it the case that ca is not configured? To verify the operating system implements certificate status checking for PKI authentication, run the following command: $ sudo grep -i cert_policy /etc/pam_pkcs11/pam_pkcs11.conf The output should return multiple lines similar to the following: cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; Is it the case that ocsp_on is not configured? To verify the operating system implements local cache of revocation data for PKI authentication, run the following command: sudo grep cert_policy /etc/pam_pkcs11/pam_pkcs11.conf | grep -E -- 'crl_auto|crl_offline' The output should return multiple lines similar to the following: cert_policy = ca,signature,ocsp_on,crl_auto; Is it the case that crl_auto or crl_offline is not configured? Remote access is access to nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management). Check that the pam_pkcs11.so option is configured in the etc/pam.d/common-auth file with the following command: # grep pam_pkcs11.so /etc/pam.d/common-auth auth sufficient pam_pkcs11.so If pam_pkcs11.so is not set in etc/pam.d/common-auth this is a finding. Is it the case that non-exempt accounts are not using CAC authentication? To determine how the SSH daemon's PermitEmptyPasswords option is set, run the following command: $ sudo grep -i PermitEmptyPasswords /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf $ sudo grep -i PermitEmptyPasswords /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf If a line indicating no is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's X11Forwarding option is set, run the following command: $ sudo grep -i X11Forwarding /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf $ sudo grep -i X11Forwarding /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf If a line indicating no is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's PermitUserEnvironment option is set, run the following command: $ sudo grep -i PermitUserEnvironment /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf $ sudo grep -i PermitUserEnvironment /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf If a line indicating no is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's UsePAM option is set, run the following command: $ sudo grep -i UsePAM /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf If a line indicating yes is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's PubkeyAuthentication option is set, run the following command: $ sudo grep -i PubkeyAuthentication /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf If a line indicating yes is returned, then the required value is set. Is it the case that the required value is not set? To determine how the SSH daemon's Banner option is set, run the following command: $ sudo grep -i Banner /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf If a line indicating /etc/issue.net is returned, then the required value is set. Is it the case that the required value is not set? Run the following command to see what the timeout interval is: $ sudo grep ClientAliveInterval /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveInterval Is it the case that it is commented out or not configured properly? To ensure ClientAliveInterval is set correctly, run the following command: $ sudo grep ClientAliveCountMax /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveCountMax For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when the ClientAliveInterval is set. Starting with v8.2, a value of 0 disables the timeout functionality completely. If the option is set to a number greater than 0, then the session will be disconnected after ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message. Is it the case that it is commented out or not configured properly? Only FIPS ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: $ sudo grep Ciphers /etc/ssh/sshd_config The output should contain only following ciphers (or a subset) in the exact order: aes256-ctr,aes192-ctr,aes128-ctr Is it the case that FIPS ciphers are not configured or the enabled ciphers are not FIPS-approved? Only FIPS-approved key exchange algorithms must be used. To verify that only FIPS-approved key exchange algorithms are in use, run the following command: $ sudo grep -i kexalgorithms The output should contain only following algorithms (or a subset) in the exact order: Is it the case that KexAlgorithms option is commented out, contains non-approved algorithms, or the FIPS-approved algorithms are not in the exact order? Only FIPS-approved MACs should be used. To verify that only FIPS-approved MACs are in use, run the following command: $ sudo grep -i macs /etc/ssh/sshd_config The output should contain only following MACs (or a subset) in the exact order: MACs Is it the case that MACs option is commented out or not using FIPS-approved hash algorithms? To determine how the SSH daemon's X11UseLocalhost option is set, run the following command: $ sudo grep -i X11UseLocalhost /etc/ssh/sshd_config.d/00-complianceascode-hardening.conf $ sudo grep -i X11UseLocalhost /etc/ssh/sshd_config.d/01-complianceascode-reinforce-os-defaults.conf If a line indicating yes is returned, then the required value is set. Is it the case that the display proxy is listening on wildcard address? Ensure "ca" is enabled in "certificate_verification" with the following command: $ sudo grep certificate_verification /etc/sssd/sssd.conf. If configured properly, output should look like certificate_verification = ca_cert,ocsp Is it the case that certificate_verification in sssd is not configured? To verify that SSSD is configured for PAM services, run the following command: $ sudo grep services /etc/sssd/sssd.conf If configured properly, output should be similar to services = pam Is it the case that it does not exist or 'pam' is not added to the 'services' option under the 'sssd' section? To verify that smart cards are enabled in SSSD, run the following command: $ sudo grep pam_cert_auth /etc/sssd/sssd.conf If configured properly, output should be pam_cert_auth = True Is it the case that smart cards are not enabled in SSSD? To verify that SSSD expires offline credentials, run the following command: $ sudo grep offline_credentials_expiration /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf If configured properly, output should be offline_credentials_expiration = 1 Is it the case that it does not exist or is not configured properly? To determine if !authenticate has not been configured for sudo, run the following command: $ sudo grep -r \!authenticate /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that !authenticate is specified in the sudo config files? To determine if NOPASSWD has been configured for sudo, run the following command: $ sudo grep -ri nopasswd /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that nopasswd is specified in the sudo config files? Determine if "sudoers" file restricts sudo access run the following commands: $ sudo grep -PR '^\s*ALL\s+ALL\=\(ALL\)\s+ALL\s*$' /etc/sudoers /etc/sudoers.d/* $ sudo grep -PR '^\s*ALL\s+ALL\=\(ALL\:ALL\)\s+ALL\s*$' /etc/sudoers /etc/sudoers.d/* Is it the case that either of the commands returned a line? The runtime status of the kernel.dmesg_restrict kernel parameter can be queried by running the following command: $ sysctl kernel.dmesg_restrict 1. Is it the case that the correct value is not returned? The runtime status of the kernel.randomize_va_space kernel parameter can be queried by running the following command: $ sysctl kernel.randomize_va_space 2. Is it the case that the correct value is not returned? The runtime status of the net.ipv4.tcp_syncookies kernel parameter can be queried by running the following command: $ sysctl net.ipv4.tcp_syncookies 1. Is it the case that the correct value is not returned? Check the firewall configuration for any unnecessary or prohibited functions, ports, protocols, and/or services by running the following command: $ sudo ufw show raw Ask the System Administrator for the site or program PPSM CLSA. Verify the services allowed by the firewall match the PPSM CLSA. Add all ports, protocols, or services allowed by the PPSM CLSA by using the following command: $ sudo ufw allow "direction" "port/protocol/service" where the direction is "in" or "out" and the port is the one corresponding to the protocol or service allowed. To deny access to ports, protocols, or services, use: $ sudo ufw deny "direction" "port/protocol/service" Is it the case that unauthorized network services can be accessed from the network? Check all the services listening to the ports with the following command: $ sudo ss -l46ut Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 128 [::]:ssh [::]:* For each entry, verify that the ufw is configured to rate limit the service ports with the following command: $ sudo ufw status If any port with a state of "LISTEN" is not marked with the "LIMIT" action, run the following command, replacing "service" with the service that needs to be rate limited: $ sudo ufw limit "service" Rate-limiting can also be done on an interface. An example of adding a rate-limit on the eth0 interface follows: $ sudo ufw limit in on eth0 Is it the case that network interface not rate-limit? Verify that use_mappers is set to pwent in /etc/pam_pkcs11/pam_pkcs11.conf file with the following command: $ grep ^use_mappers /etc/pam_pkcs11/pam_pkcs11.conf use_mappers = pwent Is it the case that use_mappers is not uncommented or configured correctly? Run the following command to determine if the kbd package is installed: $ dpkg -l kbd Is it the case that the package is not installed? Verify that there are no wireless interfaces configured on the system with the following command: Note: This requirement is Not Applicable for systems that do not have physical wireless network radios. $ nmcli device status DEVICE TYPE STATE CONNECTION virbr0 bridge connected virbr0 wlp7s0 wifi connected wifiSSID enp6s0 ethernet disconnected -- p2p-dev-wlp7s0 wifi-p2p disconnected -- lo loopback unmanaged -- virbr0-nic tun unmanaged -- Is it the case that a wireless interface is configured and has not been documented and approved by the Information System Security Officer (ISSO)? build_cpe.py from SCAP Security Guide ssg: [0, 1, 81], python: 3.14.3 5.11.2 2026-04-01T21:16:41 Claroty CTD 5.x Claroty CTD 5.x Claroty CTD 5.x The application installed on the system is Claroty CTD 5.x. ctd4