SC-18 Mobile code

Wazuh's Security Configuration Assessment module scans monitored endpoints against policies written in YAML. Each policy checks files, directories, registry keys and running processes, reports which checks pass or fail, and recommends remediation. For SC-18, the acceptable and unacceptable mobile code lists your organization defines can be translated into checks, such as whether a prohibited script runtime is installed or whether a disallowed process is running.

• Policy content: Shipped policies are based mostly on CIS benchmarks. You can add custom YAML policies that reflect your own mobile code list, which is where most SC-18 checks will live.
• Coverage: Checks reach files, directories, registry keys and processes. Confirm whether browser extensions and office macro settings are covered by a shipped policy or need a custom check.
• Evidence output: Scan results per agent, with pass or fail status and remediation text, can be exported and retained as dated records of the configuration state.
• Ongoing operation: Scans run on a schedule, so the evidence shows the configuration over time rather than at one moment.
• License: Wazuh is GPL-2.0-only. Ask counsel how those terms apply to your deployment and to any changes you make to policies or code.

Before relying on this tool for SC-18, confirm on a test endpoint that it detects your browser and macro cases, and document the result in the test record.

Fleet policies ask each device a yes or no question, written as an osquery query. The policies page then shows which devices in each fleet are passing and which are failing. osquery exposes running processes, loaded kernel modules, open network connections, browser plugins and file hashes as SQL tables, so a single policy can test whether an unapproved browser plugin is installed or whether a prohibited file hash appears on a host.

• Query design: Write one policy per mobile code rule, for example one for browser plugins that are not on the acceptable list and one for script engines outside the approved set.
• Hash checks: File hash tables let you test for specific unacceptable files by content, which is stronger than matching names alone. Confirm that your hash list is maintained as the unacceptable list changes.
• Scheduling: The osqueryd daemon runs queries across the fleet on a schedule, so pass and fail results are recorded continuously.
• Evidence output: Per-fleet pass and fail views and exported results show which devices met each policy and when they were last checked.
• Licenses: Fleet is MIT. osquery is licensed under Apache-2.0 OR GPL-2.0-only, so your organization can select the license that suits its use. Confirm the selection with counsel and record it in your software inventory.

Before relying on these policies, confirm that the queries cover browser and office macro cases on each operating system you run, because table availability differs by platform.

Velociraptor collects forensic artifacts from endpoints, defined in VQL. A hunt runs one or more artifacts across a group of systems, and it schedules collection on machines that are offline until they reconnect. Each hunt can have its own notebook for analyzing the combined results. For SC-18, hunts suit one-time or investigative checks, such as confirming that no endpoint holds a file from a newly prohibited mobile code category, or establishing the scope of a suspected macro-based incident.

• Artifact design: VQL artifacts can search for files in defined directories, read registry values and list running processes, so your mobile code lists can be turned into targeted collection.
• Reach across groups: Hunts cover a selected group of systems, which helps assessors see the population tested, not just a sample chosen after the fact.
• Offline endpoints: Machines that are offline when a hunt starts collect when they reconnect, so the results can be incomplete until the hunt has run long enough. Record the completion status in the evidence.
• Notebooks: Each hunt's notebook keeps the query, the parameters and the combined results together, which supports the assessment record.
• License: Velociraptor is AGPL-3.0-only. AGPL terms can require source availability for modified versions offered to users over a network, so confirm with counsel before modifying or hosting it for others.

Before relying on hunts for SC-18, confirm that your artifacts cover browser and macro cases and that the hunt results reach the assessment file.

Your organization owns SC-18. The control asks you to define which mobile code and mobile code technologies are acceptable and which are not, and to authorize, monitor and control their use in the system. Those decisions depend on business needs, risk appetite and which applications your users depend on, so they cannot be delegated to a vendor or consultant without losing accountability.

• Approved and prohibited lists: Decide which script types, macro formats, browser-executed code and similar technologies are permitted, and record the reasons for each entry. The assessment procedure looks for a list of acceptable and a list of unacceptable mobile code and technologies.
• Authorization decisions: Approve exceptions, such as a finance team needing a specific macro, and keep the signed authorization records that an assessor will examine.
• Policy owner and review cycle: Name the person who maintains the lists and sets how often they are reviewed, aligned with your SC-1 policy.
• Monitoring oversight: Review the monitoring results and decide what happens when a prohibited code type appears on an endpoint.
• Quote scope: When you ask a partner for help, the written scope should state that list ownership and approvals stay with your staff.

Before engaging anyone, confirm that you have a named owner, a current approved list and a documented exception process.

An implementation partner prepares the systems that enforce and monitor your decisions and assembles the evidence. DeployOpen works this way: it configures open-source tooling inside your own infrastructure and packages the output for your assessment. It prepares evidence but does not issue assessment reports, attestations or certifications. Your organization remains responsible for the control, and the independent assessor decides whether the control is met.

• Monitoring setup: Deploy and tune endpoint monitoring so it checks for the code types on your approved and prohibited lists, for example with Wazuh Security Configuration Assessment policies or osquery queries scheduled through Fleet.
• Policy translation: Convert your lists into queries or policies that devices can run, and test them on a sample of hosts before rollout.
• Hunting and collection: Configure Velociraptor artifacts and hunts where you need to search for prohibited code across a group of systems.
• Evidence packaging: Export monitoring results, authorization records and configuration baselines in a form the assessor can examine, and document how each item maps to the assessment objects.
• Ongoing support: Where you need continued tuning, a retainer can cover updates to the tooling and to your lists.

Ask any partner to state in writing which items it configures, which it only documents and which it will not touch.

The independent auditor or assessor tests SC-18 and reports on it. The assessment procedure in SP 800-53A Rev. 5 describes examine, interview and test methods for seven determination statements. The assessor examines your lists and authorization records, interviews the people who approve and monitor mobile code, and tests whether the monitoring actually detects what the policy prohibits. Independence means the assessor cannot design the controls it later judges, so it should not configure your tooling or write the lists it tests.

• Examine: Review the approved and unacceptable lists, authorization records and system monitoring records for the period in scope.
• Interview: Ask owners and administrators how exceptions are approved and how alerts are handled.
• Test: Select endpoints or samples and check whether monitoring detects a prohibited item and whether the response follows your procedure.
• Reporting: Record findings and the basis for each determination in the assessment report that you then use in your authorization or certification decision.
• Independence boundary: A firm that built the monitoring it is assessing has a conflict and should disclose it or step back.

Before the assessment, confirm the auditor's independence arrangements and agree in writing which evidence will be provided and in what format.