Requirement
SC.L2-3.13.13 – Control and monitor the use of mobile code. This control comes from NIST SP 800-171 REV.2 / CMMC 2.0 Level 2.
Understanding the Requirement
This control requires you to establish rules that limit when and how mobile code—such as Java, JavaScript, ActiveX, PostScript/PDF scripting, Flash animations, and VBScript—can execute, and to monitor its use for risky or unauthorized activity. Because malware is frequently delivered through mobile code embedded in web pages, documents, and emails, your program must both control execution (default-deny or restricted use) and maintain visibility and alerts when mobile code runs.
Policies and Procedures Needed
Create a Mobile Code Policy that defines permitted and prohibited technologies, trusted sources (e.g., enterprise allowlists), and a default-deny stance for unknown sites. Document an exception process with business justification, risk review, time limits, and approvals. Include procedures for endpoint configuration management (who applies and verifies settings), change control for browser and document-viewer policies, monitoring and log review routines, and user guidance for handling prompts/pop-ups. Align roles and responsibilities across security leads and system/network administrators for deployment, monitoring, and exception handling.
Technical Implementation
- Harden browsers with managed policies. Deploy DISA STIG-aligned settings (or vendor security baselines) for Edge/Chrome/Firefox via Group Policy or MDM. Disable or tightly restrict ActiveX, Flash (remove if present), Java applets, VBScript, and PDF JavaScript; limit JavaScript features where feasible; enforce enterprise mode/zone mapping so only trusted sites can run advanced features.
- Implement allowlists and default-deny rules. Define trusted domains where specific mobile code is permitted; block execution from all other sites. Use site-to-zone assignment lists, content filters, or secure web gateways to enforce, and make exceptions time-bound with tickets and auto-expiry.
- Harden document and email clients. Set Office to “block macros by default,” allow only signed macros from trusted publishers, block OLE/ActiveX embeddings, and disable scripting in PDFs unless required for a specific business case. Apply PowerShell Constrained Language Mode for standard users.
- Monitor execution and blocks. Send browser, document-viewer, and script-engine telemetry (PowerShell, wscript/cscript, mshta, rundll32) from EDR and endpoints to your SIEM. Create alerts for events like blocked ActiveX, PDF JavaScript execution, HTA launches, or unusual script use by office apps.
- Verify and test regularly. Use configuration scanners (e.g., STIG/CIS checklists) to validate enforcement, run spot checks on endpoints, and perform periodic simulations (malicious doc/web payloads in a safe test) to confirm blocks and alerting work. Track metrics: percent endpoints compliant, number of blocks by category, age/count of active exceptions.
- Educate users. Provide a brief guide on what mobile code prompts mean, when to click “Block,” and how to request an exception through the service desk. Include this in onboarding and annual refresher training.
Example in a Small or Medium Business
Acme Services manages 120 Windows laptops and standardizes on Microsoft Edge and Adobe Acrobat Reader. The IT administrator deploys the DISA STIG settings for Edge via Group Policy, which disables ActiveX, removes Flash components, restricts JavaScript to default settings, and enforces a trusted sites list. Acrobat is configured to disable JavaScript and block embedded multimedia by default. All web traffic flows through a secure DNS filter, and endpoint EDR is tuned to alert on PowerShell, mshta, and script host executions triggered by office applications. A payroll vendor’s legacy portal requires an ActiveX-like control, so a help desk ticket initiates the exception process: the security lead reviews the business need, adds the vendor domain to a limited allowlist for 30 days, and documents the approval and compensating monitoring in the ticket. The SIEM captures each allowed execution and notifies the team if activity occurs outside business hours or from non-payroll users. When the vendor upgrades to a modern portal, the exception auto-expires, returning the environment to default-deny.
Summary
By defining a clear mobile code policy, enforcing hardened browser and document settings, limiting execution to trusted sources, and continuously monitoring script and content execution, SMBs can effectively control and observe the use of mobile code. A disciplined exception process and regular verification close gaps while keeping the business running. Together, these policy and technical measures reduce malware risk from web pages and documents and demonstrate that SC.L2-3.13.13 is met in a practical, auditable way.
