Mobile device management, application security, sandboxing and deception

Objective 4.1 asks you to apply controls that secure an environment. The previous lesson shaped the systems themselves. This one deals with the places you only partly control: the phone in an employee's pocket, the code your developers write and the repositories it lives in, the file you do not yet trust, and the attacker who is already inside. The last of those is met with deception, which tells you someone is there but never stops them on its own.

Why this matters

These areas have one thing in common: the thing you are protecting is partly outside your hands. A phone leaves the building every evening. Code is written quickly by people under deadline pressure, and sometimes it carries a password it should never have held. An attachment arrives from outside, and nobody yet knows what it does.

The exam's questions match a control to a failure: a leaked key, a lost phone, a suspect attachment, a quiet intruder. The wrong answers are usually real controls aimed at a different problem.

The lesson

Mobile device management, and the control it actually gives you

Mobile device management (MDM) is the tooling that enforces policy on phones and tablets. Its broader forms are mobile application management, which manages only the corporate apps, and unified endpoint management, which brings mobile devices and laptops under one console.

What it can do:

• require a passcode and device encryption, and check that both are in place;
• enforce a minimum operating system version and push updates;
• install, configure and remove applications, and block installs from unofficial sources;
• deliver Wi-Fi, VPN and certificate settings so users never handle them;
• detect a rooted or jailbroken device;
• locate a lost device and wipe it.

Wiping depends on who owns the device. On a corporate-owned device you can perform a full wipe. On a personally owned one you generally cannot, either legally or practically. Instead, MDM keeps corporate data in a managed container, separate from personal apps, and a selective wipe removes only that container. Whether personal devices are allowed at all is a policy decision, covered in lesson 42.

What MDM cannot do is the part worth knowing. Its guarantees rest on the platform's own integrity. On a rooted or jailbroken device the management agent can be defeated or made to lie, so the console may report compliance that does not exist. That is why the standard policy is to block such devices, not to manage them.

MDM does most of its work when paired with conditional access. The identity provider refuses a sign-in unless the device is enrolled and compliant, which turns device health into part of every access decision. That is the most common real-world form of the zero trust thinking in lesson 4.

Input validation, secure cookies, static analysis and code signing

These are the controls that keep application code from becoming the way in.

• Input validation is the root control against the whole injection family. Validate on the server. Client-side checks help usability, but the client is under the user's control and can be bypassed. Prefer an allow list of what is acceptable, such as an expected type, length, format and range, over trying to block what is known to be bad. For database access, parameterised queries keep data from ever being read as code.
• Secure cookies are about three attributes. Secure sends the cookie only over HTTPS. HttpOnly stops page scripts from reading it, which limits what a cross-site scripting flaw can steal. SameSite restricts when the browser sends the cookie on cross-site requests, which helps against request forgery. A session cookie missing these is a common finding.
• Static code analysis (SAST) reads source code without running it, looking for insecure patterns. It runs early and cheaply, often on every commit, and produces false positives because it cannot see how the code behaves at runtime. The contrast to remember is dynamic analysis, which tests a running application and needs no source code. Use both.
• Code signing attaches a digital signature to software, so the platform can check that it came from the named publisher and has not changed since signing. It proves origin and integrity. It does not prove the code is safe, and it protects nothing once the signing key itself is stolen. That is why signing keys belong in hardware security modules or tightly controlled signing services.

Secrets scanning, and the credential somebody committed to a repository

A secret is anything that grants access by itself: an API key, a cloud access key, a database password, a private key, a token. Developers embed them in code and configuration files because it is the quickest way to make something work. Then the file is committed, and the secret goes wherever the repository goes: every clone, every fork, every build log, and, if the repository is ever made public, the internet.

Secrets scanning looks through repositories for these values. Scanners recognise the distinctive formats many providers use for their keys, and they also flag long random-looking strings that resemble secrets. Scanning works at three points:

• before the commit, through a check on the developer's machine;
• at the push, where the repository platform refuses changes containing a recognised secret;
• across the history, because deleting a secret in a later commit does not remove it from earlier ones. Anyone with a copy of the history still has it.

When a secret is found, the order of response matters. Revoke and rotate it first. Once it has been committed, assume it has been copied. Removing it from the code without rotating it leaves a working credential in every clone. Then check the provider's logs for any use of that credential, and only then clean up the history.

The lasting fix is to keep secrets out of code entirely. Store them in a secrets manager or vault, let the application fetch them at runtime, and use short-lived credentials where the platform supports them. Pipelines, container images and infrastructure-as-code templates need the same scanning as application code, because they leak secrets just as easily.

Sandboxing: running what you do not trust where it cannot reach anything

Sandboxing runs code in a constrained environment where it cannot affect the host or the network beyond what the sandbox allows. The exam uses it in three ways:

• Detonation. Email gateways and web filters open attachments and downloads in an isolated virtual machine, watch what they do, and deliver only what behaved. Malware with no known signature can still be caught by its behaviour.
• Application isolation. Browsers run each site in its own restricted process, and mobile platforms confine each app to its own space. A compromised tab or app is boxed in.
• Analysis. Incident responders examine suspicious files in a sandbox rather than on a production machine.

The limitation is worth knowing. Capable malware attempts sandbox evasion. It looks for signs of a virtual machine, a tiny disk, no user activity or a fresh boot, and if it suspects it is being watched it stays dormant or waits out the observation period. So a clean sandbox verdict is evidence, not proof. That is why sandboxing sits beside behavioural detection on the endpoint instead of replacing it.

Honeypots, honeyfiles, honeytokens and canary accounts as tripwires, never a defence on their own

Deception technology places something attractive and fake where only an intruder would find it, so touching it is itself the alert.

• A honeypot is a decoy system that looks real, runs plausible services and holds nothing of value. No legitimate user has any reason to connect to it.
• A honeynet is a network of decoys, where you can watch an intruder move between systems and learn their techniques.
• A honeyfile is a decoy document with a tempting name, placed on a real share and set to alert on any access.
• A honeytoken is a decoy data item or credential, such as a fake API key or a fake customer record. If it is used anywhere, or turns up in someone else's leaked data, you learn that it was taken and roughly from where.
• A canary account is a decoy identity in the directory. It looks worth stealing, for example an old-looking admin or service account, but it has no real privileges and no legitimate user. Any sign-in attempt, any authentication request and any use of its credentials is an alert. It is especially good at catching intruders who harvest credentials or enumerate the directory and then try what they found.

Disruption is the active counterpart: slowing an intruder down and making them waste effort, for example with fake records, decoy DNS answers or connections deliberately held open. The aim is to raise their cost and buy time, not to block them.

Classify all of this correctly. Deception is a detective control. Its strength is a false-positive rate close to zero, because no legitimate activity ever touches a decoy, so an alert from one needs no tuning to be believed. It stops nothing. A decoy that is not properly isolated can also become a real foothold. Treat deception as an early warning that sits on top of the preventive controls. An exam option offering it as the primary defence is wrong.

What to take into the exam

• MDM enforces passcode, encryption, OS version, apps and wipe. Use selective wipe and containers on personal devices. Rooted or jailbroken devices are blocked, not managed.
• Validate input on the server with an allow list. Session cookies get Secure, HttpOnly and SameSite.
• Static analysis reads code without running it. Code signing proves origin and integrity, not safety.
• A committed secret is compromised: revoke and rotate first, then clean up the history, and move secrets into a vault.
• A clean sandbox verdict is evidence, not proof, because malware evades sandboxes.
• Honeypots, honeyfiles, honeytokens and canary accounts are detective tripwires with almost no false positives. They never replace prevention.