--- title: "z/OS Library Integrity: What to Monitor and How to Respond" description: RACF controls who can change a z/OS library, not what changed. The four library types to baseline with FIM, and how to triage and respond to alerts. image: https://blog.virtelweb.com/hubfs/Gemini_Generated_Image_a6jfrpa6jfrpa6jf.jpg --- [![Virtel-logo202](https://blog.virtelweb.com/hs-fs/hubfs/Virtel-logo202.png?width=200&height=62&name=Virtel-logo202.png "Virtel-logo202")](https://blog.virtelweb.com/) - [Articles](https://blog.virtelweb.com/) - [Resources](https://www.virtelweb.com/support-resources/resources.html?utm_source=blog&utm_medium=blog_cta) - [Try Virtel](https://www.virtelweb.com/support-resources/virtel-demos-and-free-trial.html?utm_source=blog&utm_medium=blog_cta) - [Contact Us](https://www.virtelweb.com/contact.html?utm_source=blog&utm_medium=blog_cta) - [Virtel Web Suite](https://www.virtelweb.com?utm_source=blog&utm_medium=blog_cta) ###### Posted by [Sebastian DEWAR](https://blog.virtelweb.com/author/sebastian-dewar), [Maxime Quartier](https://blog.virtelweb.com/author/maxime-quartier) ###### October 28, 2026 # The Mainframe Blind Spot: File Integrity Monitoring on z/OS 8 min read  ## *What's changed in your load libraries, PARMLIB and APF datasets since last Tuesday, and how file integrity monitoring would tell you* ![Two mainframe experts are looking at reporting on screens](https://blog.virtelweb.com/hs-fs/hubfs/Gemini_Generated_Image_pcj0xypcj0xypcj0.jpg?width=642&height=350&name=Gemini_Generated_Image_pcj0xypcj0xypcj0.jpg)   Every mainframe operator knows the question. Few can answer it in seconds: which executables, libraries, and configuration members have changed since the last verified baseline, and where did each of those changes come from? In the distributed estate, this question has had an answer for two decades. Configuration management tools and file integrity monitoring platforms provide continuous visibility into the state of deployed software and detect change as it happens. The major intrusions of the last decade brought the need into focus. Carbanak showed how long patient attackers could operate inside a bank's network; SolarWinds showed that a digitally signed, legitimately distributed software update could itself be the vehicle of compromise. In both cases, a large part of the response came down to establishing exactly what had changed, where, and since when. On the mainframe, the tooling to ask that question exists but is not universally deployed. Many environments still operate on the assumption that what was installed remains installed, and that change comes through formal release management because that is how mainframe shops have always worked. The assumption was reasonable for thirty years. In 2026 it has aged badly. This article is the third in a series on visibility into what runs on z/OS. [What You Actually Run: z/OS Asset Inventory and Compliance](https://blog.virtelweb.com/what-you-actually-run-z-os-asset-inventory-compliance) asked what is deployed on each LPAR. [What's Running on Your LPARs, and Has It Changed?](https://blog.virtelweb.com/whats-running-on-your-lpars-and-has-it-changed) asked whether any of it has been modified. Here we go one level down: which libraries deserve continuous monitoring, and what to do when an alert fires. #### KEY TAKEAWAYS - **RACF decides who may update a z/OS library**. File integrity monitoring (FIM) shows what has actually changed, including changes made with valid or stolen access rights. - **Four categories of datasets deserve continuous monitoring**: APF-authorized libraries, LINKLIST, SYS1 and PARMLIB, and the application load libraries behind critical business processes. - PCI DSS v4.0.1 Requirement 11.5.2 expects change detection on critical files, with **comparisons at least weekly**. DORA and ISO/IEC 27001:2022 expect evidence of controlled change without naming FIM. - **Detection is only half of the control**. Baseline curation, triage and a written response procedure turn alerts into evidence. ## What integrity monitoring means on z/OS File integrity monitoring (FIM) is the practice of recording a cryptographic hash — a digital fingerprint — of every file in a controlled scope, then continuously checking whether any of those fingerprints has changed. FIM does not decide who is allowed to modify a file: on z/OS, that is RACF's job, and without the required access rights a library simply cannot be updated. FIM answers a different, complementary question: what has actually changed, including changes made with perfectly valid — or stolen — access rights. It has been standard practice on Unix and Windows servers for decades, and [PCI DSS Requirement 11.5.2](https://www.pcisecuritystandards.org/document_library/) codifies it as a baseline expectation. On z/OS, the same practice exists but takes a different shape. The files of interest are load libraries, configuration members in PARMLIB, datasets in SYS1, REXX procedures, JCL members, the contents of LINKLIST, APF-authorized libraries — and any other datasets you consider critical. The cryptographic operation is the same. The deployment context is not. Load libraries are accessed by multiple subsystems concurrently. PARMLIB members are read at IPL and during dynamic reconfiguration. APF-authorised libraries, in particular, are the closest equivalent on z/OS to a privilege-escalation surface, and their integrity is, in compliance terms, non-negotiable. FIM tooling for z/OS exists, but it has been adopted unevenly. The cultural assumption that the mainframe is "secure by default" because of RACF, SMP/E and a disciplined change management process has slowed adoption. ## Why the assumption has aged badly The assumption that mainframe binaries are stable rests on three premises. Production change goes through formal release management. RACF prevents unauthorized access to sensitive libraries. SMP/E maintains a controlled chain from vendor PTF to deployed code. All three premises remain broadly true. None of them is, individually, sufficient to detect a modification that an attacker with sufficient access has made deliberately. The Carbanak campaign, documented by [Kaspersky in 2015](https://www.kaspersky.com/about/press-releases/the-great-bank-robbery-carbanak-cybergang-steals-1bn-from-100-financial-institutions-worldwide), established that financially motivated attackers were willing to invest months of preparation inside banking environments to position themselves for high-value fraud. The group targeted up to 100 banks, e-payment systems and other financial institutions in around 30 countries, with losses estimated at up to one billion dollars. Entry came through spear-phishing. The attackers then moved laterally, typically spent two to four months inside each network, and used the malware's video capabilities to watch how administrators worked. Only then did they cash out: ATMs instructed remotely to dispense money, SWIFT transfers, and account balances inflated directly in the banks' accounting systems. Carbanak was not a mainframe attack, and it did not rely on modifying system binaries. The lesson generalizes nonetheless: the attackers succeeded by learning to operate the banks' own systems with legitimate-looking access. Disciplined change management, RACF controls and SMP/E governance protect against casual or accidental modification. On their own, they do not reveal what an attacker holding valid credentials has changed — whether data, configuration or code. The 2026 threat landscape adds pressure.  The [International AI Safety Report 2026](https://arxiv.org/pdf/2602.21012) notes that general-purpose AI systems can now assist at several steps of a cyberattack, including identifying software vulnerabilities. None of this is specific to z/OS. But the direction is clear: specialized knowledge is becoming cheaper to acquire, and the assumption that adversaries lack the expertise to target mainframe systems is weaker than it was. We looked at what this means for exposed TN3270 access in [When Obscurity Stops Protecting](https://blog.virtelweb.com/when-obscurity-stops-protecting).  | ~$1B | *Estimated losses, up to $1 billion, across up to 100 financial institutions in around 30 countries targeted by the Carbanak group. The attackers typically spent two to four months inside each network, observing how administrators worked, before using the banks' own systems — ATMs, SWIFT transfers, account balances — to cash out.*  Source: Kaspersky Lab, Carbanak APT report, February 2015 | | --- | --- | ## The integrity surface on z/OS The libraries and members that a serious adversary would consider modifying, on a z/OS production environment, fall into four categories. The first is APF-authorized libraries. Any program loaded from an APF-authorized library can perform privileged operations. A modification to such a library that introduces or alters even a small piece of code  is comparable, in operational power, to root access on a Linux server . APF list management is a well-understood security discipline, but the integrity of the contents of each APF library is a separate question, and one that fewer environments monitor continuously. The second is the LINKLIST concatenation. Programs invoked by name from a JCL step are resolved against the LINKLIST. A modification to a high-traffic LINKLIST library, particularly to a program invoked by routine batch processing, creates an opportunity to execute injected code regularly and unobtrusively. The third is SYS1 and PARMLIB datasets. These contain the configuration that defines the security and operational behavior of the system itself. These are less common targets because they require specific knowledge of z/OS internals. Their impact, when they occur, is structural rather than tactical. The fourth is application load libraries for critical business processes. Banking core transactions, payment authorization logic, account balance updates, and similar workloads run from libraries that are stable in normal operations and rarely re-verified after the original deployment. An adversary who can place modified code in these libraries can manipulate the business logic itself. ## What the regulations say The regulatory expectation around binary integrity has hardened. [PCI DSS v4.0.1 Requirement 11.5.2](https://www.pcisecuritystandards.org/document_library/) requires a change-detection mechanism — file integrity monitoring tools are the example the standard gives — that alerts personnel to unauthorized modification of critical files, including changes, additions and deletions, and that performs critical file comparisons at least once weekly. Requirement 12.10.5 adds that the incident response plan must cover the alerts these mechanisms produce. In practice, the tool flags every change; separating expected changes from unauthorized ones is the organisation's responsibility. The requirement applies to in-scope system components: any mainframe that stores, processes or transmits cardholder data, or is connected to the environment that does.  [DORA Article 9(2)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj)requires financial entities to implement ICT security policies, procedures, protocols and tools that aim to ensure the resilience of their ICT systems and to maintain high standards of availability, authenticity, integrity and confidentiality of data, whether at rest, in use or in transit. Article 9(4)(e) is more specific: changes to software, firmware components, systems or security parameters must be recorded, tested, assessed, approved, implemented and verified in a controlled manner. [Article 17 of Commission Delegated Regulation (EU) 2024/1774](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj) sets out what those change management procedures must contain. DORA does not name file integrity monitoring. But a change that is expected to be "verified" is difficult to evidence without an independent record of what actually changed on the system. We covered the access-layer side of DORA in [DORA and Mainframe Access: The Security Gap Nobody Is Watching](https://blog.virtelweb.com/dora-and-mainframe-access-the-security-gap-nobody-is-watching).  [ISO/IEC 27001:2022](https://www.iso.org/standard/27001)does not prescribe FIM either, but FIM directly supports several Annex A controls: A.8.32 (change management), A.8.9 (configuration management), A.8.16 (monitoring activities) and A.8.7 (protection against malware). A.5.36 (compliance with policies, rules and standards for information security) requires that compliance be regularly reviewed — which, for the integrity of system libraries, presupposes a reliable way of observing their state. That applies to the mainframe as much as to any other platform in scope. | *Twenty years ago, the question on z/OS was “is your RACF configuration clean?” Today, the configuration  can be clean and the libraries can still have been modified. Those are two different questions, and the discipline to answer the second one is what has been missing.*  - Sebastian Dewar, CTO, Virtel | | --- | ## Beyond detection, responding to integrity events Detecting change is necessary but not sufficient. Three operational practices follow from any serious FIM deployment. The first is baseline curation. The list of files and members under integrity monitoring needs to be reviewed regularly to ensure it covers the high-value surfaces (APF libraries, LINKLIST, PARMLIB, critical application libraries) and excludes the genuinely volatile (work datasets, spool datasets, dynamically generated content). A baseline that includes too much produces noise. A baseline that includes too little misses the surface that matters. The second is triage. Every detected change is, at first, just a change. A mature FIM tool helps by grading each one by severity, from expected behavior, to behavior worth investigating, to potentially malicious behavior, based on its own analysis of the change. That grading tells an analyst where to look first; it does not replace the analyst’s judgment. It may not know about the change calendar either: correlating a detected change with an approved change request remains a human step, performed after the fact, and a reviewed change can then be marked as accepted. Organizations that skip this review end up with the worst of both worlds: alerts nobody reads, and unexpected changes left unnoticed among expected ones. [Vanguard SAMM](https://www.go2vanguard.com/solutions/samm/), for instance, categorizes changes as red (potentially malicious), yellow (to investigate) or green (expected), and provides an ACCEPT process for activity that has been reviewed. The third is response procedure. The action to take when an alert fires needs to be defined in advance. Quarantine the modified library. Compare against the SMP/E target. Confirm with the application owner. Roll back if no authorized change matches. These steps are not novel, but they have to exist in writing before the alert that requires them fires, not after. ## An assumption that no longer holds The integrity question on z/OS has been answerable for a long time. It has been asked less often than it should have been. The combination of evolving threats, hardening regulation, and matured tooling has made it untenable to continue treating binary integrity as an implicit assumption rather than a verified property. The mainframe was protected for decades by a security model that has aged well in most respects. Binary integrity verification is the one area where the security model needs to be supplemented by tooling that exists, can be deployed, and answers the question that the regulators are now asking explicitly. ## Frequently asked questions ### Which z/OS libraries should be monitored for integrity? At a minimum: APF-authorized libraries, the LINKLIST concatenation, SYS1 and PARMLIB datasets, and the application load libraries behind critical business processes. Volatile datasets such as work and spool datasets should be excluded so that alerts stay meaningful. ### Why isn't RACF enough to protect system libraries? RACF decides who may update a library. It does not record whether the content has changed, and a change made with valid or stolen credentials is a permitted change as far as RACF is concerned. FIM compares the current content with a baseline, so it shows that the change happened. ### How often must file integrity comparisons run? PCI DSS v4.0.1 Requirement 11.5.2 requires critical file comparisons at least once weekly. Continuous monitoring shortens the window between a change and its detection. ### What should happen when a FIM alert fires on z/OS? Follow a procedure defined in advance: quarantine the modified library, compare it against the SMP/E target, confirm with the application owner, and roll back if no authorized change matches. Then record the outcome so that reviewed changes are marked as accepted.   #### Vanguard SAMM, solution distributed by Virtel #### Make binary integrity an answered question, not an assumed one. Vanguard SAMM provides continuous file integrity monitoring across z/OS LPARs and libraries. Vanguard positions SAMM against PCI DSS 4.0, DORA, SOX and GLBA requirements. [Discover Vanguard SAMM →](https://www.virtelweb.fr/vanguard/vanguard-samm-securite-mainframe-zos.html) SOURCES and REFERENCES 1. [Vanguard — Software Application Monitoring and Malware Detection (SAMM) for z/OS, whitepaper](https://www.go2vanguard.com/wp-content/uploads/SAMM-for-zOS-whitepaper.pdf) Vanguard Integrity Professionals — Software Application Monitoring and Malware Detection 2. [Vanguard Integrity Professionals — SAMM product page](https://www.go2vanguard.com/solutions/samm/) go2vanguard.com 3. [Virtel — Vanguard SAMM, sécurité mainframe z/OS](https://www.virtelweb.fr/vanguard/vanguard-samm-securite-mainframe-zos.html) virtelweb.fr — distribution and integration 4. [Kaspersky — The Great Bank Robbery: Carbanak cybergang steals $1bn from 100 financial institutions worldwide](https://www.kaspersky.com/about/press-releases/the-great-bank-robbery-carbanak-cybergang-steals-1bn-from-100-financial-institutions-worldwide) kaspersky.com, press release, 17 February 2015 5. [PCI DSS v4.0.1 — Requirements 11.5.2 (change-detection / FIM) and 12.10.5](https://www.pcisecuritystandards.org/document_library/) PCI Security Standards Council 6. [Regulation (EU) 2022/2554 — DORA, Article 9(2) and 9(4)(e)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) EUR-Lex 7. [Commission Delegated Regulation (EU) 2024/1774 — RTS on ICT risk management framework, Article 17 (ICT change management)](https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj) EUR-Lex 8. [ISO/IEC 27001:2022 — Annex A controls A.5.36, A.8.7, A.8.9 and A.8.32](https://www.iso.org/standard/27001) iso.org 9. [International AI Safety Report 2026](https://arxiv.org/pdf/2602.21012) arXiv : 2602.21012, February 2026 10. [CISA — SolarWinds Supply Chain Compromise advisory](https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a) cisa.gov — AA20-352A Topics: [z/OS](https://blog.virtelweb.com/topic/z-os), [DORA](https://blog.virtelweb.com/topic/dora), [PCI DSS](https://blog.virtelweb.com/topic/pci-dss), [Compliance](https://blog.virtelweb.com/topic/compliance), [File integrity monitoring](https://blog.virtelweb.com/topic/file-integrity-monitoring), [APF](https://blog.virtelweb.com/topic/apf), [Malware](https://blog.virtelweb.com/topic/malware), [ISO27001](https://blog.virtelweb.com/topic/iso27001) Back to Top - Share - - [*X*](https://twitter.com/intent/tweet?url=https://blog.virtelweb.com/mainframe-blind-spot-file-integrity-monitoring-zos) - - [mailto:?body=https://blog.virtelweb.com/mainframe-blind-spot-file-integrity-monitoring-zos](mailto:?body=https://blog.virtelweb.com/mainframe-blind-spot-file-integrity-monitoring-zos) #### Related Articles [What's Running on Your LPARs, and Has It Changed?](https://blog.virtelweb.com/whats-running-on-your-lpars-and-has-it-changed) [Knowing the Components Is Not the Same as Understanding the System](https://blog.virtelweb.com/knowing-the-components-is-not-the-same-as-understanding-the-system) #### Topics - [Mainframe (23)](https://blog.virtelweb.com/tag/mainframe) - [3270 Emulation (16)](https://blog.virtelweb.com/tag/3270-emulation) - [Mainframe Modernization (12)](https://blog.virtelweb.com/tag/mainframe-modernization) - [z/OS (11)](https://blog.virtelweb.com/tag/z-os) - [TN3270 (10)](https://blog.virtelweb.com/tag/tn3270) - [3270 modernization (9)](https://blog.virtelweb.com/tag/3270-modernization) - [Virtel (9)](https://blog.virtelweb.com/tag/virtel) - [WebEnablement (9)](https://blog.virtelweb.com/tag/webenablement) - [LegacyTransformation (8)](https://blog.virtelweb.com/tag/legacytransformation) - [APIs (7)](https://blog.virtelweb.com/tag/apis) - [security (7)](https://blog.virtelweb.com/tag/security) - [terminal emulator (7)](https://blog.virtelweb.com/tag/terminal-emulator) - [DORA (5)](https://blog.virtelweb.com/tag/dora) - [Mainframe Applications (3)](https://blog.virtelweb.com/tag/mainframe-applications) - [Mainframe security (3)](https://blog.virtelweb.com/tag/mainframe-security) - [Compliance (2)](https://blog.virtelweb.com/tag/compliance) - [Inventory (2)](https://blog.virtelweb.com/tag/inventory) - [LPAR (2)](https://blog.virtelweb.com/tag/lpar) - [PCI DSS (2)](https://blog.virtelweb.com/tag/pci-dss) - [RACF (2)](https://blog.virtelweb.com/tag/racf) - [green screen modernization (2)](https://blog.virtelweb.com/tag/green-screen-modernization) - [AI (1)](https://blog.virtelweb.com/tag/ai) - [AI agents (1)](https://blog.virtelweb.com/tag/ai-agents) - [AT-TLS (1)](https://blog.virtelweb.com/tag/at-tls) - [Asset management (1)](https://blog.virtelweb.com/tag/asset-management) - [Audit (1)](https://blog.virtelweb.com/tag/audit) - [File integrity monitoring (1)](https://blog.virtelweb.com/tag/file-integrity-monitoring) - [Identity (1)](https://blog.virtelweb.com/tag/identity) - [Knowledge Transfer (1)](https://blog.virtelweb.com/tag/knowledge-transfer) - [Mainframe News (1)](https://blog.virtelweb.com/tag/mainframe-news) - [Mainframe Skills (1)](https://blog.virtelweb.com/tag/mainframe-skills) - [NIS2 (1)](https://blog.virtelweb.com/tag/nis2) - [Network (1)](https://blog.virtelweb.com/tag/network) - [Patch management (1)](https://blog.virtelweb.com/tag/patch-management) - [Pentest (1)](https://blog.virtelweb.com/tag/pentest) - [SOX (1)](https://blog.virtelweb.com/tag/sox) - [Training (1)](https://blog.virtelweb.com/tag/training) - [Virtel News (1)](https://blog.virtelweb.com/tag/virtel-news) - [case study (1)](https://blog.virtelweb.com/tag/case-study) - [cics (1)](https://blog.virtelweb.com/tag/cics) - [testimonial (1)](https://blog.virtelweb.com/tag/testimonial) See All Topics [Contact](https://www.virtelweb.com/contact.html) [Privacy](https://www.virtelweb.com/privacy.html) [About](https://www.virtelweb.com/about/syspertec-group.html) [Legal](https://www.virtelweb.com/legal.html) Copyright © 2026 Virtel. All Rights Reserved ![Virtel-logo2025-fondSombre](https://blog.virtelweb.com/hs-fs/hubfs/Virtel-logo2025-fondSombre.png?width=1500&height=465&name=Virtel-logo2025-fondSombre.png "Virtel-logo2025-fondSombre") ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Sebastian DEWAR", "url" : "https://blog.virtelweb.com/author/sebastian-dewar" }, "dateModified" : "2026-10-28T12:00:01.061Z", "datePublished" : "2026-10-28T12:00:01.000Z", "headline" : "z/OS Library Integrity: What to Monitor and How to Respond", "image" : [ "https://blog.virtelweb.com/hubfs/Gemini_Generated_Image_a6jfrpa6jfrpa6jf.jpg" ], "mainEntityOfPage" : { "@id" : "https://blog.virtelweb.com/mainframe-blind-spot-file-integrity-monitoring-zos", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.virtelweb.com/hubfs/LOGO%20VIRTEL%20RVB.jpg" }, "name" : "Syspertec Group" } } ``` ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "about" : [ { "@type" : "Thing", "name" : "File integrity monitoring" }, { "@type" : "Thing", "name" : "APF-authorized libraries" }, { "@type" : "Thing", "name" : "Digital Operational Resilience Act (DORA)" } ], "articleSection" : "Mainframe Security", "author" : [ { "@type" : "Person", "jobTitle" : "CTO", "name" : "Sebastian Dewar", "url" : "https://blog.virtelweb.com/author/sebastian-dewar", "worksFor" : { "@type" : "Organization", "name" : "Virtel" } }, { "@type" : "Person", "name" : "Maxime Quartier", "url" : "https://blog.virtelweb.com/author/maxime-quartier", "worksFor" : { "@type" : "Organization", "name" : "Virtel" } } ], "citation" : [ "https://www.kaspersky.com/about/press-releases/the-great-bank-robbery-carbanak-cybergang-steals-1bn-from-100-financial-institutions-worldwide", "https://www.pcisecuritystandards.org/document_library/", "https://eur-lex.europa.eu/eli/reg/2022/2554/oj", "https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj", "https://www.iso.org/standard/27001", "https://arxiv.org/abs/2602.21012", "https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-352a", "https://www.go2vanguard.com/solutions/samm/" ], "dateModified" : "2026-10-28", "datePublished" : "2026-10-28", "description" : "RACF controls who can change a z/OS library, not what changed. The four library types to baseline with FIM, and how to triage and respond to alerts.", "headline" : "The Mainframe Blind Spot: File Integrity Monitoring on z/OS", "inLanguage" : "en", "isBasedOn" : "https://blog.virtelweb.com/whats-running-on-your-lpars-and-has-it-changed", "keywords" : [ "z/OS library integrity", "file integrity monitoring z/OS", "APF-authorized libraries", "LINKLIST", "PARMLIB", "PCI DSS 11.5.2", "DORA Article 9", "ISO/IEC 27001:2022", "FIM alert triage", "Vanguard SAMM", "z/OS" ], "mainEntityOfPage" : { "@id" : "https://blog.virtelweb.com/mainframe-blind-spot-file-integrity-monitoring-zos", "@type" : "WebPage" }, "mentions" : [ { "@type" : "SoftwareApplication", "name" : "Vanguard SAMM (Software Application Monitoring and Malware Detection)" } ], "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://www.virtelweb.com/images/logos/logo2020SyspertecIBMprovider.JPG" }, "name" : "Virtel" } } ``` ```json { "@context" : "https://schema.org", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "At a minimum: APF-authorized libraries, the LINKLIST concatenation, SYS1 and PARMLIB datasets, and the application load libraries behind critical business processes. Volatile datasets such as work and spool datasets should be excluded so that alerts stay meaningful." }, "name" : "Which z/OS libraries should be monitored for integrity?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "RACF decides who may update a library. It does not record whether the content has changed, and a change made with valid or stolen credentials is a permitted change as far as RACF is concerned. FIM compares the current content with a baseline, so it shows that the change happened." }, "name" : "Why isn't RACF enough to protect system libraries?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "PCI DSS v4.0.1 Requirement 11.5.2 requires critical file comparisons at least once weekly. Continuous monitoring shortens the window between a change and its detection." }, "name" : "How often must file integrity comparisons run?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Follow a procedure defined in advance: quarantine the modified library, compare it against the SMP/E target, confirm with the application owner, and roll back if no authorized change matches. Then record the outcome so that reviewed changes are marked as accepted." }, "name" : "What should happen when a FIM alert fires on z/OS?" } ] } ```