Purpose
You want to know more about how security works within PDQ Deploy & Inventory software.
Intended Audience
CEO, IT Leadership, IT Security Officers, and System Administrators
Overview
We believe that the best approach to security is a layered approach. PDQ Deploy & Inventory can play an integral part in the security strategy of any organization by providing a vehicle to inventory older, out-of-date software packages and update them to the latest versions. Additionally, our framework is flexible enough to allow for the rapid development of custom packages, scripts, and inventory reports to provide System Administrators with tools to solve business problems and ultimately enhance the security posture of an environment.
Requirements
PDQ Deploy & Inventory require and run on Windows-based operating systems. We support all Microsoft 8x, 10, and Server 2012+ operating systems. Good PDQ security requires good Windows security. It's important to keep your server patched and configured to your organization's security standards. System Requirements
PDQ runs on the .NET 4.6.1 (and newer) framework and uses the SMB (Server Message Block) protocol to transfer files: It is important to note PDQ utilizes the highest version of SMB available in your network. In most cases, this will be the latest version, SMBv3, and will exclude SMBv1, which is vulnerable to ransomware.
PDQ File and Folder Locations
PDQ Software Installation Directory:
C:\Program Files (x86)\Admin Arsenal\PDQ Deploy
C:\Program Files (x86)\Admin Arsenal\PDQ Inventory
PDQ Deploy and PDQ Inventory use SQlite Databases located on the PDQ server:
C:\ProgramData\Admin Arsenal\PDQ Deploy\Database.db
C:\ProgramData\Admin Arsenal\PDQ Inventory\Database.db
PDQ Server Default Package Repository Location:
C:\Users\Public\Documents\Admin Arsenal\PDQ Deploy\Repository
PDQ Client Working Directory and Logs:
C:\Windows\AdminArsenal
Credentials
PDQ uses 3 sets of Credentials:
- Background Service Account for running the PDQ Server
- Deploy and Scanning Account for connecting with endpoints to deploy software and perform inventory scans
- Console Credentials to only allow authorized windows administrators to launch the PDQ software
PDQ encrypts all sensitive information (passwords) when they are stored in the PDQ databases. We use industry-standard AES encryption with three separate keys to keep your data safe. One key is built into the application, one key is stored in the database, and the third is stored in the registry. These last two keys are generated when the application is installed and is unique to your system.
PDQ recommends following the principle of least privilege (definition) when determining which credentials to use, utilizing credentials which have the required permissions for the commands you wish to run, and no additional permissions beyond that.
For additional security, we also support Windows LAPS (Local Administrator Password Solution). You can find more about this integration here: LAPS Integration with PDQ Inventory and PDQ Deploy
Client/Server Connection
The PDQ Deploy & Inventory server uses an agentless, client/server model to interact with endpoints. Standard Windows authentication is used to create a temporary service on the client in order to deploy software or perform an inventory scan. Once completed, the temporary files and service are deleted.
Network Connections
Internal Traffic:
PDQ requires default windows ports along with the following:
ICMP enabled
TCP 445
TCP 6336 (ONLY if using PDQ Deploy Central Server)
TCP 7337 (ONLY if using PDQ Inventory Central Server)
External Traffic:
PDQ Deploy & Inventory regularly access the internet to update the Package Library, Collection Library, Tools Library, and System Variables (used in collections). Additionally, PDQ products check for program updates, license expiration information, and general information notifications from PDQ.com (Webcast notices, Beta notices, etc.) In order for these connections to function properly, PDQ products require access to the external sites found here: PDQ External Exceptions
Package Library Integrity
We have an in-house automation system that will periodically check for new software updates and download them into our repository. When applicable, we submit their hashes to a third-party site for reputation analysis, leveraging multiple antivirus engines.
We then use dedicated virtual machines that only have the windows operating system installed and are only used for building PDQ Deploy packages. Once we've built the package, we then deploy this to a group of virtual machines, each having a different version of windows along with their respective 32Bit/64Bit architecture. We then run a report in PDQ Inventory that all test machines installed the package successfully and are reflecting the correct updated version. We then verify on each test machine that the program was installed and will launch normally as a non-admin user. Additionally, we have another virtual machine in the group that uses a third-party security product that combines both traditional antivirus signatures with behavior-based scanning to add another layer of monitoring for malware-based activity during the build process.
After the first engineer has signed off on the build, we require that a second engineer perform a quality assurance step and deploy the package to a separate group of virtual machines, verify deployment success, program version, and software functionality.
The third and final step requires yet another engineer to publish the package:
- The package is compressed into a CAB file
- The CAB file is signed with a PDQ public certificate
- The signed CAB file is then uploaded to our Azure storage
- The package variables are updated in the PDQ Inventory Collection Library
- The package is then made publicly available in the PDQ Deploy Package Library
- On the customer side, PDQ Deploy will then only download and extract the Library package if it has a valid PDQ signature. This helps prevent file tampering from build to customer download.
Interacting with PDQ support
What files are sent to support? Our support staff may ask you to submit your databases so we can get more information to help fix your problem. When you submit your databases, these include PDQ databases, PDQ log files, PDQ errors in the Windows event log, and PDQ Server configuration information.
Database in transit protection? Sensitive data is not sent to PDQ. All data is transmitted over a secure SSL connection to a protected internal storage share where the data is only accessible to support engineers and developers.
What can PDQ see in the databases? We don't have any access to customer databases, unless you manually submit them as part of a support ticket. When we receive these databases, we do not have access to the customer's stored passwords. We do have access to hardware and software inventory information that can include computer names, IP and MAC addresses, and logged-on username.
Customer database retention policy? We don't have a formal retention policy, because sometimes we close a ticket and the customer needs additional support and re-opens the case. It's more based on clearing space for new ticket uploads, which typically ends up being around 3-6 months. If a customer specifically requests that their data be deleted, the support engineer immediately honors that request.
