Effective Date: January 1, 2015
1. Introduction. We understand that security is critical to our users and we are serious about safeguarding our customers’ and partners’ personal information online. As a primary security measure, users may access personal information online from the RiskRT® website only after registering and creating a personal ID and password.
Although we cannot guarantee absolute confidentiality of data transmitted over the public Internet, we encrypt all data transmissions between your computer and our data center using the strongest-available, industry-standard SSL (Secure Socket Layer) protocols. Data transmissions to us, including personal IDs and passwords, are not decrypted until they are inside our secure perimeter. Once there, they are subjected to additional security procedures common to the best business practices of the leading e-commerce companies. Any information provided to our users is encrypted before it passes our secure perimeter and is decoded once it reaches the user’s browser.
2. Privacy. We will never give, rent or sell access to your data to anyone else (unless authorized), nor will we make use of it ourselves for any purpose other than to provide you with the recordkeeping service.
3. Website Encryption. Starting from the password entry screen, all communications between your computer and our data center uses the strongest-available, industry-standard SSL (Secure Socket Layer) protocols. This ensures that user data in transit is safe, secure, and available only to intended recipients.
To access the RiskRT® product you must use a browser that supports SSL encryption.
4. Personal IDs and Passwords. Personal IDs are used as a means of identifying users, and are not encrypted information. On the other hand, for security reasons, Passwords are encrypted and are known only to the individual user. No one working in association with the RiskRT® website will ever ask for your Password, and you should never furnish it to anyone who claims to represent the RiskRT® website. User passwords have minimum complexity requirements. Together, Personal IDs and Passwords are the user’s credentials to access personal information online and add to the security of the RiskRT® website.
5. Password Security. Passwords are encrypted when stored and are known only to the individual user. No one working in association with the RiskRT® website will ever ask for your Password, and you should never furnish it to anyone who claims to represent this website. If a user is unsuccessful when logging into the site, the user can select the “I forgot my password!” link on the password entry screen to facilitate resolving the issue through the e-mail address they have previously setup through the site. It is a good additional security measure to change your Password frequently. Simply log in, go to the "Login Settings" menu and click on “Change Password”.
6. Session Security. Each session is identified with a unique 40 alpha-numeric character string, active only during the duration of the session.
7. Role Based Access. Each account in the system can have multiple levels of client and menu access.
8. Automatic Log Out. As a safety precaution, after fifteen minutes without requesting additional resources from the server, the site will request the user to confirm that they would like to remain logged into the site. After five additional minutes, the system will automatically log the user out of the system.
When the Internet session is finished, we encourage users to log out by clicking on the "Log Out" button. It is also a good idea to close the browser after logging out, and to occasionally clear the browser history to ensure that any personal information is cleared from the browser's memory.
9. Cookies. We only use “cookies” for the anti-phishing image. If you do not/cannot enable cookies you will be asked to authenticate your PC by entering your security answer each time you log in.
10. Infrastructure Setup & Security. Our information systems infrastructure (servers, networking equipment, etc.) is hosted entirely within Amazon’s AWS offering, a third party highly controlled and audited data center. Application and database backups are held at Amazon’s S3 nightly and retained for 7 days. Scaling and load balancing are implemented with internal solutions leveraging Amazon’s ability to quickly start up a clone (AMI) of a previously imaged instance.
AWS accepts that the security of the solution is a shared responsibility. AWS secures the underlying, global infrastructure, while we secure the local network and physical environments with threat management, vulnerability management, identity/access management and what is placed on AWS.
Because Amazon recognizes this relationship as a shared responsibility, they have instituted methods to report possible security vulnerabilities, conform to a wide list of audits / standards (http://aws.amazon.com/compliance/), and provide methods for coordinated public announcements of vulnerabilities within AWS. For additional information specific to AWS security standards: http://aws.amazon.com/security/
11. Physical Location & Security. Our solution is hosted within Amazons US East (N. Virginia) region. The AWS cloud infrastructure is housed in AWS’s highly secure data centers, which utilize state-of-the-art electronic surveillance and multi-factor access control systems. Data centers are staffed 24x7 by trained security guards, and access is authorized strictly on a least privileged basis. All personnel are screened when leaving areas that contain customer data.
12. Network Controls. AWS gives control of their virtual network through the use of their VPC (Virtual Private Cloud) and Security Groups. These systems give control over the ports/data types that may be passed between each instance. Only required ports are accessible for each instance.
13. Uptime Monitoring. Amazon CloudWatch and an additional third party monitoring solution report any downtime to staff for escalation.
14. Patching. Latest security patches are applied to all operating system and application files to mitigate newly discovered vulnerabilities.
15. Access Control. Secure VPN, restricted IP lists, key pairs composed of 2048-bit SSH-2 RSA keys are used to connect directly to the systems and given to authorized personnel only.
16. Storage Security. Backups of application and databases occur daily and are transmitted to Amazon’s S3 solution. Data is retained for 7 days.
17. Non-HTTPS Data Transmission Security. Data transmissions that occur outside of the HTTPS protocol use either SFTP or FTPS methods.
18. Employee Screening. We perform background screening on all employees.
19. Access. Access controls to sensitive data in our databases, systems and environments are set on a need-to-know / least privileged basis.
20. Software Development Practices.
20.1 Core RiskRT® Product: We code primarily in C# and run on Microsoft SQL Server 2014, and Windows Server 2012 R2 Standard.
20.2 Support Center: Developed in PHP and runs MySQL and Fedora.
20.3 Coding Practices. Our engineers use best practices and industry-standard secure coding guidelines to ensure secure coding.
21. Additional Features and Issue Resolution. System functionality and design changes are verified in an isolated test “sandbox” environment and subject to functional testing prior to deployment to active production systems. Development items (features / reported issues) are tracked and prioritized within and issue tracking system (Redmine). Each planned patch is given a revision number and releases are planned to occur between 1 to 4 weeks. Support fixes are reported to the client through the use of the Support Center. Mercurial revision control is used to track specific code changes.
22. Handling of Security Breaches. Despite best efforts, no method of transmission over the Internet and no method of electronic storage is perfectly secure. We cannot guarantee absolute security. However, if RiskRT® learns of a security breach, we will notify affected users so that they can take appropriate protective steps. Our breach notification procedures are consistent with our obligations under various state and federal laws and regulation, as well as any industry rules or standards that we adhere to. Notification procedures include providing email notices or posting a notice on our website if a breach occurs.
23. Custom Requests. If you have specific security questions that were not addressed on this document, you may at this time make special requests at RiskRT.help@acasolutioncenter.com. We’ll respond to you within 2 business days with a reasonable estimate as to the time it will take to answer your questions.
24. Summary. Users (our partners and customers and their employees) play an important role in protecting security. Above all, it is crucial to maintain the secrecy of Internet Passwords. Passwords should never be told to anyone or written down in a place where it could be associated with any other Personal ID. If an employee has reason to believe that someone else may have access to their password, they should contact their employer immediately. It's a good idea to change passwords often (this can be done at any time by going to the "Settings" menu and clicking on “Login Settings”).
Effective Date: January 1, 2015
1. Introduction. We understand that security is critical to our users and we are serious about safeguarding our customers’ and partners’ personal information online. As a primary security measure, users may access personal information online from the RiskRT® website only after registering and creating a personal ID and password.
Although we cannot guarantee absolute confidentiality of data transmitted over the public Internet, we encrypt all data transmissions between your computer and our data center using the strongest-available, industry-standard SSL (Secure Socket Layer) protocols. Data transmissions to us, including personal IDs and passwords, are not decrypted until they are inside our secure perimeter. Once there, they are subjected to additional security procedures common to the best business practices of the leading e-commerce companies. Any information provided to our users is encrypted before it passes our secure perimeter and is decoded once it reaches the user’s browser.
2. Privacy. We will never give, rent or sell access to your data to anyone else (unless authorized), nor will we make use of it ourselves for any purpose other than to provide you with the recordkeeping service.
3. Website Encryption. Starting from the password entry screen, all communications between your computer and our data center uses the strongest-available, industry-standard SSL (Secure Socket Layer) protocols. This ensures that user data in transit is safe, secure, and available only to intended recipients.
To access the RiskRT® product you must use a browser that supports SSL encryption.
4. Personal IDs and Passwords. Personal IDs are used as a means of identifying users, and are not encrypted information. On the other hand, for security reasons, Passwords are encrypted and are known only to the individual user. No one working in association with the RiskRT® website will ever ask for your Password, and you should never furnish it to anyone who claims to represent the RiskRT® website. User passwords have minimum complexity requirements. Together, Personal IDs and Passwords are the user’s credentials to access personal information online and add to the security of the RiskRT® website.
5. Password Security. Passwords are encrypted when stored and are known only to the individual user. No one working in association with the RiskRT® website will ever ask for your Password, and you should never furnish it to anyone who claims to represent this website. If a user is unsuccessful when logging into the site, the user can select the “I forgot my password!” link on the password entry screen to facilitate resolving the issue through the e-mail address they have previously setup through the site. It is a good additional security measure to change your Password frequently. Simply log in, go to the "Login Settings" menu and click on “Change Password”.
6. Session Security. Each session is identified with a unique 40 alpha-numeric character string, active only during the duration of the session.
7. Role Based Access. Each account in the system can have multiple levels of client and menu access.
8. Automatic Log Out. As a safety precaution, after fifteen minutes without requesting additional resources from the server, the site will request the user to confirm that they would like to remain logged into the site. After five additional minutes, the system will automatically log the user out of the system.
When the Internet session is finished, we encourage users to log out by clicking on the "Log Out" button. It is also a good idea to close the browser after logging out, and to occasionally clear the browser history to ensure that any personal information is cleared from the browser's memory.
9. Cookies. We only use “cookies” for the anti-phishing image. If you do not/cannot enable cookies you will be asked to authenticate your PC by entering your security answer each time you log in.
10. Infrastructure Setup & Security. Our information systems infrastructure (servers, networking equipment, etc.) is hosted entirely within Amazon’s AWS offering, a third party highly controlled and audited data center. Application and database backups are held at Amazon’s S3 nightly and retained for 7 days. Scaling and load balancing are implemented with internal solutions leveraging Amazon’s ability to quickly start up a clone (AMI) of a previously imaged instance.
AWS accepts that the security of the solution is a shared responsibility. AWS secures the underlying, global infrastructure, while we secure the local network and physical environments with threat management, vulnerability management, identity/access management and what is placed on AWS.
Because Amazon recognizes this relationship as a shared responsibility, they have instituted methods to report possible security vulnerabilities, conform to a wide list of audits / standards (http://aws.amazon.com/compliance/), and provide methods for coordinated public announcements of vulnerabilities within AWS. For additional information specific to AWS security standards: http://aws.amazon.com/security/
11. Physical Location & Security. Our solution is hosted within Amazons US East (N. Virginia) region. The AWS cloud infrastructure is housed in AWS’s highly secure data centers, which utilize state-of-the-art electronic surveillance and multi-factor access control systems. Data centers are staffed 24x7 by trained security guards, and access is authorized strictly on a least privileged basis. All personnel are screened when leaving areas that contain customer data.
12. Network Controls. AWS gives control of their virtual network through the use of their VPC (Virtual Private Cloud) and Security Groups. These systems give control over the ports/data types that may be passed between each instance. Only required ports are accessible for each instance.
13. Uptime Monitoring. Amazon CloudWatch and an additional third party monitoring solution report any downtime to staff for escalation.
14. Patching. Latest security patches are applied to all operating system and application files to mitigate newly discovered vulnerabilities.
15. Access Control. Secure VPN, restricted IP lists, key pairs composed of 2048-bit SSH-2 RSA keys are used to connect directly to the systems and given to authorized personnel only.
16. Storage Security. Backups of application and databases occur daily and are transmitted to Amazon’s S3 solution. Data is retained for 7 days.
17. Non-HTTPS Data Transmission Security. Data transmissions that occur outside of the HTTPS protocol use either SFTP or FTPS methods.
18. Employee Screening. We perform background screening on all employees.
19. Access. Access controls to sensitive data in our databases, systems and environments are set on a need-to-know / least privileged basis.
20. Software Development Practices.
20.1 Core RiskRT® Product: We code primarily in C# and run on Microsoft SQL Server 2014, and Windows Server 2012 R2 Standard.
20.2 Support Center: Developed in PHP and runs MySQL and Fedora.
20.3 Coding Practices. Our engineers use best practices and industry-standard secure coding guidelines to ensure secure coding.
21. Additional Features and Issue Resolution. System functionality and design changes are verified in an isolated test “sandbox” environment and subject to functional testing prior to deployment to active production systems. Development items (features / reported issues) are tracked and prioritized within and issue tracking system (Redmine). Each planned patch is given a revision number and releases are planned to occur between 1 to 4 weeks. Support fixes are reported to the client through the use of the Support Center. Mercurial revision control is used to track specific code changes.
22. Handling of Security Breaches. Despite best efforts, no method of transmission over the Internet and no method of electronic storage is perfectly secure. We cannot guarantee absolute security. However, if RiskRT® learns of a security breach, we will notify affected users so that they can take appropriate protective steps. Our breach notification procedures are consistent with our obligations under various state and federal laws and regulation, as well as any industry rules or standards that we adhere to. Notification procedures include providing email notices or posting a notice on our website if a breach occurs.
23. Custom Requests. If you have specific security questions that were not addressed on this document, you may at this time make special requests at RiskRT.help@acasolutioncenter.com. We’ll respond to you within 2 business days with a reasonable estimate as to the time it will take to answer your questions.
24. Summary. Users (our partners and customers and their employees) play an important role in protecting security. Above all, it is crucial to maintain the secrecy of Internet Passwords. Passwords should never be told to anyone or written down in a place where it could be associated with any other Personal ID. If an employee has reason to believe that someone else may have access to their password, they should contact their employer immediately. It's a good idea to change passwords often (this can be done at any time by going to the "Settings" menu and clicking on “Login Settings”).
© 2020 RiskRT® All Rights Reserved
