Product Security Guide
At PDQ we realize how important the security of our products is. That is why every decision we've made with SmartDeploy revolves around ensuring the product is safe to use for managing your devices. From encrypting data in transit and at rest to Platform Pack integrity and more — SmartDeploy is built to securely manage your devices pretty damn quick.
Architecture overview
Introduction to SmartDeploy
SmartDeploy is a hybrid endpoint management tool for computer imaging. IT professionals and sysadmins use SmartDeploy to manage both the local and remote devices in their organization. IT professionals perform actions like deploying Windows operating systems to devices, managing drivers, installing and updating software, or running scripts — locally or remotely through the internet.
Product architecture
SmartDeploy works in a hybrid fashion utilizing a cloud-based broker for communication. All devices connected to the same network as the installed SmartDeploy Service will communicate directly to that instance via HTTPS. Any internet-connected device will communicate through the SmartDeploy Cloud Services.
When the SmartDeploy Console is used to deploy images, applications, drivers, or user state to an internet-connected device, SmartDeploy’s servers will securely save those requested messages in the SmartDeploy database system. When a device running the SmartDeploy Client is connected to the internet, it will make an outbound HTTPS request to SmartDeploy servers to get any pending messages.
SmartDeploy Client
To manage a Windows device using SmartDeploy, an administrator must first install the SmartDeploy Client on the device.
The Client runs in the background on your Windows devices and is responsible for reporting device hardware information and checking for messages to run tasks. It runs as a system user so that it can perform admin-required package installations and other maintenance activities.
The Client can communicate with the SmartDeploy Console in two ways, via the SmartDeploy Local Service or the SmartDeploy Cloud Service. Local connections are secured using HTTPS with a unique certificate to the local API service. Cloud is also secured using HTTPS. Both will also use a client registration process to confirm authentication by utilizing a unique key to get a token.
The Client can also make connections to third-party cloud storage providers, such as OneDrive or Google Drive, by using refresh tokens obtained as part of a cloud deployment message. These refresh tokens are scoped to provide the minimal permissions to download any package(s) required to complete the message task.
Learn more about the SmartDeploy Client.
SmartDeploy Console
Administrators use the SmartDeploy Console to manage computers and deploy images, drivers, applications, and updates. The Console is installed alongside a local API service, which hosts a local database.
The Console can interact with both a local and cloud API service. In both instances, communication is secured using HTTPS and certificates.
The Console can also make a connection to a third-party cloud storage provider. It will require a full scope to be able to read, write, and delete from the provider, but all interactions are limited to a specific SmartDeploy folder created on the provider.
Data security
Encryption
At rest:
All information sent to the SmartDeploy Cloud Services is stored in a database that is encrypted at rest. This includes all messages, computer details, and any other information collected by the Client or Console.
In transit:
All information traveling between your SmartDeploy Local Service and the SmartDeploy Cloud Service is encrypted in transit using HTTPS TLSv1.2. We also use HTTPS TLSv1.2 encryption for secure communication between the SmartDeploy Client software and the local and cloud SmartDeploy Service.
Please note that while the contents of any Application or Platform Pack are encrypted in transit to a device, if user-created scripts or installers initiate other web requests or downloads, it is the user’s responsibility to ensure that those are done securely.
Data isolation
All data within the SmartDeploy databases and services are logically separated and isolated using unique company identities. When data is requested from a service or database, it is isolated to only data that the unique AccountId is allowed to access. This means that customers see only their own data and never data from other SmartDeploy customers.
Data retention
Unless otherwise required by law, SmartDeploy retains Sensitive and Confidential Data only for as long as necessary to fulfill the purposes for which it is collected and processed, or to meet legal and client contractual obligations. To support compliance with these obligations, SmartDeploy, on an annual basis, reviews its existing retention practices regarding Sensitive and Confidential Data.
Data backups
All critical data is backed up at least daily. Annual tests are performed to ensure data backups can be restored successfully.
Identity and authentication
Identity and authentication overview
SmartDeploy utilizes Azure B2C, an industry-leading authentication and identity provider, for authentication and password management. SmartDeploy does not collect, process, or use passwords directly.
Password requirements
Passwords must be 8–24 characters and contain 3 out of 4 of the following:
Lowercase characters
Uppercase characters
Digits (0–9)
One or more of the following symbols: . @ # $ % ^ & * - _ + = [ ] { } | : ' , ? / ` ~ "( ) ; .
Passwords do not expire but can be reset as needed.
Multi-factor authentication (MFA)
MFA is currently not supported; however, it is a feature on the current roadmap.
User sessions
Inactive SmartDeploy session tokens expire after 1 hour, requiring users to re-authenticate.
Managing product access
Organizations control and manage who has access to the SmartDeploy account. Administrators can create users, edit user permissions, or remove users from their organization at app.smartdeploy.com. PDQ does not manage users or access on behalf of customers.
Password reset
Users can reset their password using a password reset link. When the password reset link is used, an email is sent to the user’s inbox with instructions. To reset a password, the user must have access to the email inbox associated with their user account. PDQ does not reset passwords on behalf of customers.
Account restoration
For security reasons, PDQ cannot restore access to an account where an administrator left an organization or forgot their username. In these instances, PDQ recommends that organizations restore the inbox of administrators and use the password reset option.
Operational security
System access
PDQ enforces a role-based access control (RBAC) policy over defined subjects and objects. PDQ controls access based upon defined roles and users authorized to assume such roles. By doing so, PDQ ensures that user access to in-scope system components is based on job role and function.
PDQ ensures that, at minimum, the RBAC policy establishes and enforces RBAC on the following elements:
Core business suite
Software development system
Cloud service providers (CSP)
Other business critical systems
Vulnerability prevention
PDQ has established a Vulnerability Monitoring and Scanning Program designed to monitor and scan for internal and external vulnerabilities in systems and hosted applications at least weekly (or more randomly) to identify, quantify, and prioritize vulnerabilities. PDQ also identifies and implements code analysis in the organization’s development pipeline to regularly scan both static and dynamic codebases to check for vulnerabilities. Processes ensure that the scope of any vulnerability is defined and documented prior to the initiation of a vulnerability assessment.
PDQ also ensures that all findings from vulnerability scans are analyzed and documented on a weekly basis and are remediated in accordance with the organization's risk tolerance. PDQ shares information obtained from the vulnerability monitoring process and control assessments with key stakeholders to help eliminate similar vulnerabilities in other systems.
Other security topics
Third-party vendors
SmartDeploy utilizes a handful of services that are required to provide product functionality. These third-party vendors process data for PDQ and include:
Provider | Service | Notes |
|---|---|---|
Azure B2C | Authentication | Used for managing user authentication and passwords. |
Chargebee | Payments | Used for customer invoicing. |
Dynamics 365 | CRM | Used for account licensing and management. |
Security audits
PDQ performs annual human-based and weekly automated penetration tests to identify vulnerabilities that could be exploited to gain access to its production environment. PDQ Corporation will ensure that in-scope assets are documented prior to the initiation of any penetration test. PDQ’s internal SmartDeploy team has committed to an internal SLA to remediate issues found by these tests.
Additionally, PDQ has engaged a third-party bug bounty program that pays out for non-publicly disclosed vulnerabilities.
Certifications
PDQ takes security seriously and realizes the value of independently audited security certifications. We are SOC 2 compliant and will continue to undergo routine audits for updated reports.
Platform Pack and Application Pack Libraries
SmartDeploy offers a library of Platform Packs (hardware driver packages) and Application Packs used in the deployment functions of the software, allowing users to pull packages for commonly used business hardware platforms and several applications from PDQ without having to self-manage these packages.
This is an optional feature included with SmartDeploy. Organizations can choose to not use this feature and instead manually create packages.
Package creation process
SmartDeploy creates and updates packages in the library both proactively and based on customer requests. Platform Packs are created by directly sourcing hardware drivers from the OEMs, and then they are built into a package suitable for use with SmartDeploy. Application Packs are similarly created by sourcing installation files from the ISV, and then they are repackaged for use with SmartDeploy. In all instances, antivirus scans are run against packages before redistribution.
The package creation and update process is manually verified by a secondary engineer for quality assurance. At no point can a single engineer build and publish into the library. Once the package passes secondary validation, the package is uploaded and made available in SmartDeploy.
Custom packages
Customers can optionally create their own Application and Platform Packs. PDQ does not share, or make available, custom packages created by one customer with other SmartDeploy customers. It is the responsibility of customers to ensure the packages they create are safe.