πŸ” Security Principles

We follow best practices

At SalesTim we follow a number of best practices that improve our security posture. Here are a few examples:

  • All data received from and sent to SalesTim is encrypted in transit. Our API and application endpoints are TLS/SSL only.
  • We use two-factor authentication whenever possible. We ask vendors to enforce two factor authentication in all our accounts. We discourage use of shared accounts on any system.
  • We don't trust our corporate network - it has no backdoors into our production systems.
  • We do not store payment details. SalesTim is not in the business of storing or processing payments. All payments made to SalesTim goes through our partner, Stripe.

Secure Development Principles

We at SalesTim know you care about how your personal information is used and shared, and we take your privacy seriously by implementing the most rigorous practices for our developments.

These best practices are gounded by the OWASP Security Design Principles:

  • Minimize attack surface area : The aim for secure development is to reduce the overall risk by reducing the attack surface area.
  • Establish secure defaults: By default, the experience should be secure, and it should be up to the user to reduce their security – if they are allowed.
  • Principle of Least privilege: The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. See SalesTim App Permissions as an example.
  • Principle of Defense in depth: The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better.
  • Fail securely: Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not.
  • Don’t trust services: Many organizations utilize the processing capabilities of third party partners, who more than likely have differing security policies and posture than you. Therefore, implicit trust of externally run systems is not warranted. All external systems should be treated in a similar fashion.
  • Separation of duties: Certain roles have different levels of trust than normal users. In particular, administrators are different to normal users. In general, administrators should not be users of the application.
  • Avoid security by obscurity: Security through obscurity is a weak security control, and nearly always fails when it is the only control.
  • Keep security simple: Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.
  • Fix security issues correctly: Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential.
Last Updated: 6/1/2019, 7:08:08 PM