You want to know more about how security works within PDQ software.
CEO, IT Leadership, IT Security Officers, and System Administrators
We believe that the best approach to security is a layered approach. PDQ software in itself is not a security product but 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.
PDQ Deploy and PDQ 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:
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.
For additional security, we also support Microsoft LAPS (Local Administrator Password Solution)
The PDQ 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.
PDQ requires default windows ports along with the following:
TCP 6336 (ONLY if using PDQ Deploy Central Server)
TCP 7337 (ONLY if using PDQ Inventory Central Server)
PDQ Deploy and PDQ 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.com 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.