Privacy and Data Use
What kinds of information do we collect
Opsani never collects end user data like individual names, addresses, emails, credit cards, etc.
We collect data about the configurations of your systems. For instance, we collect metadata about the packages installed on your systems, including the package name (such as ‘glibc’), version, release, epoch, release date and vendor.
Can you control what information is sent to us
Yes, you have two ways in which you can control what information is sent. First, by using the collector advanced option you can disable (or enable) collection of certain information. Second, you can modify the code of the collector software (which we provide in source code under the BSD open source license)
Certain items, when disabled, reduce the value of the service you will receive (e.g., if you omit the hostnames, you will not be able to search by hostname or see the hostname of a system); others may disable whole functions (e.g., if you disable package collection, no quality or vulnerability data can be queried), or render your system as not identifiable (e.g., if you disable the system ID collection and don’t provide an alternate ID info).
How do we protect your information
- Subscription data like email addresses, company name, etc., is stored separately from all other data.
- We generate user credentials using high-quality API access passwords to prevent the most common security breaches of subscriber accounts.
- We use separate credentials for telemetry collection and API access. The possession of the telemetry API credentials does not provide access to reports or any other data.
- Your credentials are never stored in clear text in our service. We store only a one-way hash of your credentials sufficient to authenticate your request.
System identification data
- Your subscriber account is a number and does not contain your company name. We store the mapping between subscriber account numbers and subscriber information separately from all other service data.
- You can provide your own one-way system identifier that we will use for identifying each of your systems, which need not be sufficient for accessing the system (e.g., an EC2 instance ID cannot be used to mount an attack, since it cannot be mapped to an IP address).
- When you use the anonymization gateway (which will be available before the end of beta), we do not transmit or store system identifiers that can be used to address your system. For example, the host name, fully-qualified domain name and IP addresses of a system are replaced with tokens before the data is sent to our service. Thus, the data we store does not contain identifiers that would allow an attacker to find your system.
- All telemetry transmissions are done over an encrypted SSL connection
- All access to the our API is done over an encrypted SSL connection
- Data at rest will be encrypted before we exit beta.
How do we ensure data integrity
All telemetry transmissions are done over an encrypted SSL connection and are logged and timestamped in our service
The vulnerability master database (containing list of known vulnerabilities and identifying packages and versions that they affect) resides on a separate database instance
We collect information about known vulnerabilities only from reputable sources (such as the US NIST and the vendors for each respective product) and, where available, we communicate with these sources using only encrypted SSL connections. Changes to the vulnerability master database, whether automatic or manual, are timestamped and have an identifiable source agent
How do we use the information we collect
We aggregate configuration and event data across users to create metadata about trends and probabilities.
The metadata we create contains no remaining customer-specific information and is non-personal, de-identified and/or anonymous.
What information is shared between subscribers
Your raw data is never shared.
We share only aggregate data on configurations and the metadata we generate.
Do we ever sell your data
We never sell, share or allow third-party access to any customer-specific data.
We may allow third party partners or subscribers to access the configuration database (which has no customer specific information) to run their own models. An example might be a software publisher wanting to establish trends for how quickly the installed base migrates to new versions which would allow them to receive information such as total number of installs of each version over time, transitions, etc., without any customer-identifiable information.
Can you see what data we have about you
We store an ‘inspection’ copy of the data we collect from each system in a temporary file on the system, so you can review and see exactly what is being sent. We store only one such copy; it is overwritten every time new telemetry data is collected and sent.