Documentation forPapertrail

Why should I trust you?

Papertrail's Terms of Use does a good job of covering our intent:

  • keep data secure
  • remove data immediately and completely at any time
  • don't ever release data

…but that's intent, and we're more concerned with practice. Here's our thought process:

The status quo is really poor.

A lot of security stems from transparency, visibility, and awareness; think about documented procedures, open source software, and published algorithms. Visibility is very low when logs are scattered among 15 files in 5 directories, and spread across a dozen (or a hundred) systems, each of which has different user accounts and retention/rotation policies. There's nobody looking at the data.

Even the few folks who have internal log aggregation often only consolidate the problem, rather than watching and relying on the data kept there. In that case, it's just an unmaintained dumping ground — hard-to-access data just sitting on the filesystem. Papertrail lets you actually make use of it.

Expose different levels of security and convenience

…and make the tradeoffs obvious and easy. For example, Papertrail supports identifying log sources based on different sets of information (including a statically-configured source IP, statically-configured source IP and hostname, message destination, and message destination and source hostname).

Papertrail supports optional TLS encryption and certificate-based verification of the destination host, and using TLS is a single argument to our remote_syslog2 sender. The goal is to be able to pick the right fit(s) for your network topology and security needs.

It's your information, not ours.

Many Web services have admin interfaces that make it easy to login as a specific customer. Papertrail's admin interface doesn't have that, nor any easy way to view, search, or download your logs. For Papertrail staff, viewing any customer logs is an annoying, manual process, just as it should be. This is occasionally inconvenient, which we consider ideal.

We'll always ask before intentionally viewing any of your logs for troubleshooting purposes. At least two engineers will be aware of that action (your approval is typically logged in our ticketing system).

Simplicity is worth its weight in gold.

That's true logically (as in emptying one's head of cruft) and practically (as in spending one’s time on high-value tasks).

Actually searching, interpreting, and acting on logs is high value; operating and maintaining a log aggregation server is not. We try to think about fewer non-core applications, and Papertrail makes it easier to cleanly split the core and non-core effort.

Expertise depends on focus.

Papertrail presents the same services to all customers, without one-offs, and our success depends on making your text logs more useful. In this case, security centralizes well: what would be neglected "repeat learning" (or never happen) for each Papertrail customer become items Papertrail can put real effort towards. Doing one thing really well lets us do it much better[1]) than the status quo.

We're clued.

Technically, we're savvier than the average infrastructure operator, and it shows in the importance we place on security. Staff have:

  • operated an Internet peering point used and trusted by dozens of public companies
  • been excerpted in Bruce Schneier's Crypto-Gram newsletter
  • consulted with the FBI in prosecuting high-profile healthcare and e-commerce intrusions
  • started a non-profit service to prevent denial-of-service attacks
  • discovered and reported vulnerabilities in applications used by thousands of organizations (including Google's)
  • lectured about information assurance at a large university

Maybe more importantly, we're always paranoid and always learning new things.

Most text data is not as risky as it may seem.

While a few specific logs have higher-risk data (most notably, personally-identifiable user attributes, authentication tokens, and failed login attempts which include rejected password strings [2]), most system and application events are utilitarian. We strongly recommend following NIST SP 800-122 regardless of what or where you log.

Finally, while we're absolutely devoted to security, it's worth noting that an attacker generally can't act on most log data without other knowledge. Also, Papertrail's communication is entirely one-way (you to us). The service can’t issue requests/queries or make changes.

Third-party archiving "comes free."

In many environments, a neutral third-party message archive with its own separate credentials is useful or even required. You'll have reliable log data kept elsewhere that won't go away should one of your servers be hacked. We're pleased to provide a neutral, verified, timestamped log history for tracking and prosecuting intrusions.

It's a smart risk.

Merely skimming logs on a regular basis – let alone receiving regular summaries you want and can act on — lets you avoid (or catch and fix) other problems, security and otherwise. That's what Papertrail enables, and it's as or more secure than existing methods.

Everything in security is a trade-off between risk and reward and by this measure, we believe that Papertrail has an overwhelmingly positive return.

Got specific questions?

We've got specific answers.

[1]: "Cloud Security Fears are Overblown, Some Say", Network World, 2009. "'My IT department came to me with a list of 100 security requirements and I thought, Wait a minute, we don’t even have most of that in our own data center.'"

[2]: Papertrail provides the visibility to identify and destroy data that shouldn’t have ever been logged in the first place (locally or to Papertrail), such as a plaintext password typed by a user in a failed login attempt.