Docs / Security

Security Model and Operational Assurance

Lanview provides powerful administration features for managing Windows devices on a local area network. Those features include remote support, remote command execution, package deployment, file transfer, process and service control, device approval, security administration and audit review.

This document explains the security model used to control those capabilities. It is intended for security reviewers, IT managers, technical approvers and Lanview administrators who need to understand how Lanview limits access, records activity and supports accountable administration.

Lanview should be treated as a privileged administration platform. Its controls are designed to reduce risk, support least-privilege administration and provide an audit trail for sensitive activity. They do not remove the need for sound role design, Windows hardening, network controls, backup protection or administrator oversight.

Core security model

Lanview is built around a Server-controlled security model.

Lanview Server manages device state, policies, settings, permissions, package state, command dispatch and audit. Lanview Studio is the administrator application used to interact with Server. Lanview Client runs on managed Windows devices and connects outbound to Server. Lanview Agent supports logged-in user-session features, such as user-visible messages and Lanview-native remote support, but it does not replace the Client service.

Permissions are enforced by Lanview, not just by hiding buttons in Studio. Server authorises sensitive actions before they are accepted or dispatched.

Risks Lanview is designed to reduce

Lanview includes controls intended to reduce the risk of:

Unauthorised administrator access.
Over-privileged support users.
Unapproved devices joining management.
Misuse of remote support.
Misuse of remote commands, scripts or process controls.
Misuse of software package deployment.
Accidental broad targeting of devices or groups.
Lack of accountability for sensitive actions.
Manual tampering with Lanview-managed state.
Exposure of sensitive command output, logs or audit exports.

These risks are reduced through authentication, role-based access control, device approval, Client trust policy, feature-specific permissions, policy settings, audit records and optional reason prompts. They are not eliminated if administrators assign excessive permissions, share accounts, disable audit controls or bypass documented administration paths.

Authentication controls

Lanview operator accounts are managed by Lanview Server. Studio sign-in is authenticated against Server, and the first administrator account is created through a Server-controlled bootstrap process.

Lanview supports two-factor authentication with configurable modes. Two-factor authentication can be disabled, optional or required depending on Server policy.

Authorisation and role-based access control

Lanview uses role-based access control (RBAC) enforced by the Server. Users receive effective permissions from the roles assigned to them.

Permissions are granular across major administration areas, including:

Devices and groups.
Remote View, Remote Control and Remote Desktop.
Remote commands, scripts and Remote Console.
Packages and deployments.
File transfer.
Monitoring.
Security users and roles.
Settings and policy.
Audit viewing and export.
Console access.

The system.full_control permission grants unrestricted Lanview administration access and should be limited to a small number of trusted administrators.

Studio module visibility follows permissions, and Lanview Server checks permissions when actions are requested. Permission denials are audited where catalogued.

RBAC is only effective when roles are designed carefully. A role that grants remote control, package deployment, remote command execution, console access and security administration to the same broad user group removes much of the value of permission separation.

Device approval and Client trust

Lanview does not treat a device as trusted simply because a Client connects.

New Clients appear as pending devices and must be approved before normal management. Approval, rejection, blocking and deletion are separate device lifecycle actions. Reassociation is available for rebuild or replacement scenarios and requires a specific permission.

Lanview also includes Client identity and trust policy. This affects whether a Client can represent a managed device. Trust-related events are audited where catalogued.

Client trust is managed by Lanview. Administrators should use the supported reset, rebind or reassociation options rather than copying or editing trust data manually.

Remote support controls

Lanview separates Remote View, Remote Control and Microsoft Remote Desktop Protocol (RDP).

Remote View is Lanview-native and starts in view-only mode. Remote Control is an escalation from an active Remote View session and requires separate permission and policy allowance. Microsoft Remote Desktop Protocol is a separate remote access feature with its own permissions and configuration.

Remote View and Remote Control are controlled by Server policy modes. Depending on configuration, approval or consent may be required before a session or control escalation can continue. Agent policy can also affect user-session behaviour, such as notification or decline options where configured.

Remote support events are audited where catalogued, and reason prompts may apply to sensitive remote actions. Lanview Remote View and Remote Control audit records do not record typed text, screen frames, screenshots or video.

Remote support controls are documented at an administrator-facing level; session and protocol internals are not part of normal administration.

Remote command, script and process controls

Remote command and script execution are privileged administration features. They are permission-controlled and dispatched through Server.

Device and group execution permissions are separate. Managing saved scripts in the Script Repository is also separate from permission to execute scripts against devices. Remote Console permissions are distinct for Command Prompt, Windows PowerShell and PowerShell 7.

Process actions, including start, close and kill operations, are permission-controlled and audited where catalogued. Command text, process command lines and output can contain sensitive data. Avoid credentials, tokens, connection strings, recovery material and real command output in examples.

Package deployment controls

Lanview package deployment is controlled through separate permissions for authoring, publishing, deployment, uninstall, package version state and status overrides.

Package validation helps identify package issues before deployment, but it does not guarantee installation success on every endpoint. Deployment status and task results are tracked so administrators can review outcomes and failures.

Package actions are audited where catalogued. Package command lines, installer output and package metadata can contain sensitive information.

File transfer and Server cache controls

Lanview file transfer separates three concepts:

Uploading a payload from Studio to Server.
Storing eligible payloads in the Server-managed cache.
Sending files from Server to managed Clients.

Upload, transfer and cache limits are Server-level settings. File send, upload complete, cache clear and cleanup events are audited where catalogued.

The Server file cache is not a long-term document repository. Administrators should manage it through supported Lanview interfaces and commands, not by placing files directly into cache folders. Examples must avoid passwords, recovery material, private keys, licence material or confidential documents.

Audit and accountability

Lanview Server records audit events for security and administrative activity where catalogued. Audited areas include authentication, authorisation, device lifecycle, remote support, remote execution, package actions, process and service control, power/session actions, settings changes and other sensitive operations.

Audit records can include the operator, target, action, result, reason and relevant context. Reason prompts can be required for sensitive actions, and missing or invalid reasons can cause an action to be rejected.

Audit supports accountability and investigation. It does not prevent misuse by itself. Audit is only valuable if administrators protect audit data, review it appropriately and assign permissions carefully.

Audit retention and cleanup are configurable. Audit exports and logs should be treated as sensitive operational data because they may contain usernames, device names, reasons, command context, paths or operational details.

Audit storage should be managed only through supported Lanview features and documented retention controls.

Settings and policy control

Server settings are managed by Lanview Server. Studio changes Server settings through supported Server interfaces. Local Studio settings are separate from Server policy and apply only to the operator workstation.

Some features support Server, group and device-level inheritance. Examples include Remote Desktop Protocol port configuration and Agent policy. Inheritance is feature-specific; administrators should not assume every setting has group or device overrides.

Settings changes are audited where catalogued. A runtime change may not remain in effect after restart unless the corresponding startup configuration is also updated.

Sensitive data boundaries

Protected security material is not intended for routine viewing or manual handling. Use the supported administration, reset, recovery and reassociation options rather than copying or editing protected data manually.

Administrator responsibilities

Lanview provides security controls, but administrators remain responsible for configuring and operating them properly.

Recommended operational practices include:

Use named accounts for administrators and support users.
Avoid shared full-control accounts.
Assign least-privilege roles.
Limit system.full_control to a small number of trusted administrators.
Use two-factor authentication where appropriate.
Review audit reason policy before enabling broad administration.
Review Remote View and Remote Control policy before enabling remote support.
Restrict console access.
Restrict package deployment and remote execution permissions.
Review audit retention and cleanup settings.
Protect backups, logs and audit exports.
Test policies with a controlled device before broad rollout.

A poorly designed role model can make a technically sound security model ineffective. Permissions should reflect real responsibilities, not convenience.

Known security boundaries

Lanview has clear security boundaries:

Lanview does not replace Windows permissions.
Lanview does not replace Active Directory.
Lanview is not a full Security Information and Event Management (SIEM) system.
Lanview is not a secrets manager.
Lanview does not make unmanaged devices trustworthy.
Network and firewall configuration remain the administrator's responsibility.
Microsoft Remote Desktop Protocol availability and firewall configuration are external to Lanview.
Wake-on-LAN depends on network and device firmware support.

These boundaries are not weaknesses by themselves. They define where Lanview's responsibility ends and where Windows, network infrastructure and administrator policy begin.

Security and RBAC Overview
User Management
Roles and Permissions
Two-Factor Authentication
Device Approval
Remote View and Remote Control
Agent Policy
Remote Desktop
Remote Commands
Script Repository
Process Management
Packages and Deployments
Package Authoring
File Transfer
Server File Cache
Audit Log
What Lanview Is Not
Known Limitations
Logs and Diagnostics
Console Overview
AdminConsole