We take great pride in protecting you! This is an overview of the daily steps we take to ensure your data is secure with T3 Softwares and that our hosted version, the T3 Softwares Cloud, follows best security practices.
- Every T3 Softwares database is fully backed upto 24 hours, which we save for a minimum of three months: once in a day.
- Backups are duplicated across a minimum of two continents and two distinct data centers.
- Using the management panel, you can manually download backup modules of your live data at any time.
- To restore any of those backups onto your live database, get in touch with our Helpdesk (or on the side).
- Hardware failover: We perform local standby replication with monitoring and a manual failover mechanism for services hosted on bare metal, where hardware failure is likely.
- Disaster recovery: our goals are to avoid the failover to our local hot standby in the worst-case scenario of a full disaster, where a data center is completely offline for an extended period of time. This is the worst-case scenario, which has never happened before.
- Recovery Point Objective (RPO) = 24 hours. This implies that if the data cannot be restored and we have to restore your most recent daily backup, you could lose up to 24 hours of work.
- This is achieved through the active monitoring of our daily backups, which are mirrored across numerous continents. In order to launch our services in a new hosting location, we have automated provisioning. Then, for the largest clusters, restoring the data based on our daily backups can be completed in a few hours, giving priority to those with paid subscriptions.
Both the daily backups and the provisioning scripts are regularly used for day-to-day operations, meaning that both components of the disaster recovery strategy are always being tested.
- There is no data exchange between clients; all customer information is kept in a separate database and separate application instance.
- Complete isolation across customer databases running on the same cluster is implemented by data access control rules, meaning that no data can be accessed from one database to another.
- Industry-standard encryption is used to secure customer passwords.
- Twin level authentication is available for all core level applications.
- The only thing you can do if you lose your password is to reset it; T3 Softwares staff does not have access to it and cannot retrieve it for you.
- Credentials for logins are always sent securely via HTTPS.
- The rate limitation and cooldown period for multiple login attempts can also be customized by customer database administrators.
- Password policies: Database administrators can enforce a minimum password length for users by using an integrated setting. Certain password rules, such as the need for certain character types, are not supported by default since they have been shown to be ineffective.
- As per requirement password should be reset by the user after every 3months.
- To ensure privacy and security, any user that fails to authenticate with incorrect credentials three times will be temporarily blocked by the firewall. This measure is implemented to protect against unauthorized access attempts and safeguard sensitive information.
- To access settings pertaining to your support issue, T3 Softwares helpdesk workers may get into your account. Rather than using your password—which they have no way of knowing—they utilize their own unique staff/admin credentials for this.
- With this unique staff access, efficiency, and security are increased because we can audit and regulate staff actions independently, they can quickly replicate the issue you are experiencing, and you never have to reveal your password!
- Our Helpdesk team works hard to protect your privacy, accessing files and settings only as necessary to identify and fix problems.
- Current security fixes are installed on all T3 Softwares Cloud servers, which are running hardened Linux variants.
- Installations are limited and done on the fly to reduce the amount of services that can be vulnerable (no PHP/MySQL stack, for example).
- Access to the servers can only be gained by a select group of reliable T3 Softwares engineers through the use of a personal SSH keypair that is encrypted and obtained from a machine that has complete disk encryption.
T3 Softwares Cloud servers are housed in reliable data centers across the Equinox, Corporate Co Location, Google Cloud EMEA Ltd, Endurance International Group, Inc and each one of them needs to meet our strict physical security requirements:
- Restricted perimeter that only authorized data center workers can physically enter.
- Physical access control via biometric security or security badges.
- Cameras on security guard the data center locations around the clock.
- Security guards are on duty around the clock.
Encryption is used for both in-transit and at-rest customer data transfers and storage.
- The most recent 256-bit SSL encryption (HTTPS) protects all data connections to client instances.
- Our servers’ internal data communications are likewise safeguarded by cutting-edge encryption (SSH).
- With constant security monitoring and patching against the most recent SSL vulnerabilities, our servers consistently maintain Grade A SSL ratings.
- We employ full SHA-2 certificate chains and a strong 2048-bit modulus for all of our SSL certificates.
- Every piece of client data, including database content and saved files, is secured.
- Every data center provider that T3 Softwares Cloud works with has extremely vast networks and has built their architecture to be resistant to even the most powerful Distributed Denial of Service (DDoS) assaults. At the perimeter of their transcontinental networks, their automated and manual mitigation systems are able to identify and reroute attack traffic before it has an opportunity to compromise service availability.
- On T3 Softwares Cloud servers, intrusion prevention systems and firewalls assist in identifying and thwarting security risks like brute-force password attacks.
- The rate limitation and cooldown period for multiple login attempts can also be customized by customer database administrators.
- Code review procedures for newly created and contributed pieces of code in the T3 Softwares R&D processes cover security-related topics.
T3 Softwares is made to avoid introducing the majority of common security flaws:
- By using a higher-level API that does not require manual SQL queries, SQL injections can be avoided.
- A sophisticated templating technique that automatically escapes injected data is used to thwart XSS assaults.
- Because the framework blocks RPC access to secret methods, exploitable vulnerabilities are more difficult to establish.
To learn how T3 Softwares is built from the bottom up to stop such vulnerabilities from arising, see also the OWASP Top Vulnerabilities section.
Independent businesses that our clients and prospects contract to do audits and penetration test their application(Cost to be paid by client). When necessary, the T3 Softwares Security Team reviews the results and implements the necessary corrective actions.
However, as those results are private and belong to the commissioners, we are unable to share any of them. Don’t ask, please.
In addition, T3 Softwares boasts a vibrant community of independent security researchers that collaborate with us to enhance and fortify T3 Softwares’s security by regularly monitoring the source code.
According to the Open Web Application Security Project (OWASP), the following is T3 Softwares’s position on the most critical security vulnerability for web applications:
- Injection Flaws: In web applications, injection problems are frequently seen, especially those related to SQL injection. When user-supplied data is passed to an interpreter as a command or query, this is known as injection. The interpreter is tricked into executing unwanted commands or altering data by the attacker’s hostile data.The object-relational mapping (ORM) architecture used by T3 Softwares abstracts away the process of creating queries and by default guards against SQL injections. SQL queries are typically created by the ORM, not explicitly crafted by developers, and arguments are always appropriately escaped.
- Cross-Site Scripting (XSS): XSS vulnerabilities arise when an application receives data from the user and delivers it to a web browser without properly encoding or verifying the content. Through the use of XSS, attackers can run scripts in the victim’s browser that have the ability to inject worms, deface websites, hijack user sessions, and more.To avoid XSS, the T3 Softwares framework by default escapes all expressions rendered into views and pages. Expressions must be specifically marked as “safe” by developers before they can be included raw into produced pages.
- Cross Site Request Forgery (CSRF): In a CSRF attack, a susceptible web application receives a faked HTTP request from a logged-in victim’s browser that includes the victim’s session cookie and any other automatically supplied authentication information. This gives the attacker the ability to have the victim’s browser send requests that the vulnerable application interprets as coming from the victim.The CSRF prevention technique is integrated into the T3 Softwares website engine. It stops a POST request from being sent to any HTTP controller if the associated security token is missing. The suggested method for preventing CSRF is this one. An attacker cannot counterfeit a request without this security token, which is only known and present when the user has authentically accessed the necessary website form.
- Malicious File Execution: When code is susceptible to remote file inclusion (RFI), attackers can insert malicious code and data, which can lead to disastrous attacks including complete server compromise.The ability to do remote file inclusion is not exposed by T3 Softwares. Nonetheless, it enables privileged users to add unique expressions to features that the system will assess. Only authorized functions are allowed access to this cleaned and sandboxed environment, which evaluates these expressions.
- Insecure Direct Object Reference: A direct object reference is when a developer exposes a file, directory, key, database record, or other internal implementation object as a URL or form parameter. Attackers have the ability to change those references in order to get unauthorized access to other objects.There is no danger associated with exposing references to internal objects in URLs because T3 Softwares access control is not implemented at the user interface level. By changing such references, an attacker cannot get beyond the access control layer because all requests still need to pass through the data access validation layer.
- Insecure Cryptographic Storage: Cryptographic functions are rarely used correctly by web apps to safeguard credentials and data. Weakly protected data is exploited by attackers to commit crimes like credit card fraud and identity theft.To protect stored passwords, T3 Softwares employs industry-standard secure hashing for user passwords (PKFDB2 + SHA-512, with key stretching by default). If local user password storage is not desired, external authentication methods like LDAP or OAuth 2.0 can be used.
- Insecure conversations: When it comes to protecting sensitive conversations, applications often forget to encrypt network traffic.By default, T3 Softwares Cloud operates over HTTPS. It is advised to operate T3 Softwares behind a web server—such as Apache, Lighttpd, or nginx—that implements encryption and requests a proxy on behalf of T3 Softwares for installs that are done on-premise. A security checklist for more secure public deployments is part of the T3 Softwares deployment guide.
- Failure to Limit URL Access: Often, a program merely shields confidential features by not allowing links or URLs to be displayed to unapproved users. By directly accessing certain URLs, attackers can take advantage of this vulnerability to get access and carry out unwanted operations.T3 Softwares access control is neither based on hiding unique URLs, nor is it implemented at the user interface level. Attackers are unable to get around the access control layer by modifying or reusing any URL since the data access validation layer still needs to process each request. Rarely, URLs that provide unauthenticated access to private information—like unique URLs clients use to verify an order—are digitally signed with distinct tokens and are only delivered by email to the intended recipient.
To report a security vulnerability please contact T3 Support. These reports are given top attention; the T3 Softwares security team promptly investigates and resolves the issue in conjunction with the reporter, and the information is subsequently responsibly shared with T3 Softwares users and customers.