Introduction

This document is for existing and prospective Ninja Metrics clients who are interested in learning more about our security practices and data retention policies. Your data, and its safety, are of paramount importance to Ninja Metrics.

Physical and Internal Network Security

Ninja Metrics’ Katana, and all it’s components, is hosted and runs on Amazon Web Services (AWS). As such and by extension, Ninja Metrics benefits from world-class physical security as well as network security. Should an attack vector be detected, in addition to also benefiting from Amazon’s security infrastructure, we have deployed and configured our servers to provide additional security measures.

In addition to Amazon’s systems and those configurations, we use the following policies and tools:

  • Connectivity/Accessibility
    • No direct access to servers is permitted.
    • When access is required, access is via a designated secured gateway.
    • Only authorized Ninja Metrics personnel have access to the gateway.
    • No direct access to a database is permitted to run queries. The only access allowed is for authorized Ninja Metrics personnel conducting system maintenance.
    • All servers are part of a security group with well-defined connection and access controls.
    • All access keys are changed quarterly.
  • Tools
    • Ninja Metrics makes extensive use of Snort and Tripwire.
    • All system log access and system events into Syslog.
  • Audits
    • All logs are inspected on a periodic basis.
    • Ninja Metrics has also developed Nagios plug-ins for Snort and Tripwire that enable at-a-glance auditing and immediate detection of any “perimeter breach”.

Application Security

  • OWASP
    • Katana has been built with security in mind. As such, Katana is OWASP compliant:
      • When required, all inputs are validated and rejected if known attack vectors are detected.
      • XSS prevention
      • Authentication ensuring direct object reference is secure.
      • CSRF prevention via security token on all form data
      • Software and frameworks are kept up to date with the latest in their version tree.
  • Tools
    • Automated Vulnerability Assessments (Webshag, Skipfish, ProxyStrike)
    • Client side attack assessments (SET, Nessus, hashcat)
    • Authentication attack assessments (Wireshark, Hamster and Ferret, sqlmap)
  • Automated Penetration Testing (schedule)
    • We conduct automated penetration testing as part of every major release during our regular QA.
    • Additionally, we perform automated testing once a month at the application level (Katana UI) and once a quarter end-to-end (Katana UI and back-end, DBs and infrastructure).

SDK/APIs/Logs

All of our SDKs and Web Services are configured and developed to use SSL. In other words, while in transit, between clients’ applications and Ninja Metrics’ Katana, data are encrypted. Data transferred via log files can be encrypted with a private/public key pair.

Data Retention Practices and Policies

The following are our data retention practices and policies:

  • All RAW events, as received via API or SDKs or Logs, are stored in near-term storage and readily available for re-processing if needed for 6 months.
  • All data at rest is encrypted
  • After 6 months RAW events are moved to long-term storage.
  • Since we operate on AWS, there is no off line storage.
  • Results, as displayed in Katana, are kept online and available for 4 years.
  • After 4 years, they are moved to long-terms storage and only available upon request.

Security Violations or Breaches

If a security violation or breach is detected, clients whose data has been compromised will be advised within 24 hours of the occurrence.

Appendix

Charles Log

The following is the output produced by Charles Proxy during a typical periodic automated security audit: