Security

Continuity Plan

Security Statement

Privacy Statement


Security Statement

CAN’s Security Statement outlines security policies that every employee must comply with. These policies apply to employee security, data security and physical security. They also include more specialized policies that cover internal applications and systems that specific employees are required to follow.


We have designed our security policies to be easy to understand and practice without getting in the way of work. We know that if security policies get in the way of work, over time people will override them or ignore them in order to get their work done.

Data Security

We separate all data that comes into CAN into three levels. This allows us to focus our security efforts to protect our most valuable data and operate efficiently. Our goal is to maximize security while making our security policies easy to follow.

Level 1 security is the baseline that we use to protect all data. This includes controlled access to facilities, password protection, network monitoring, and drive encryption.

Level 2 security is our next layer used to protect our clients. Access to Level 2 data is restricted to facilities, equipment, data scientists, and salespeople required to complete an individual client’s project. This includes file level permissions and encryption.

Level 3 security is the most secure layer used to protect our clients’ customers and employees’ privacy. Level 3 data handling is compliant with HIPPA, PCI, and SSAE16. This includes storage in a secure data center.

Application Security

CAN’s Portal is hosted in a HIPAA/HITECH, PCI, and SSAE16 compliant data center. This includes hardened and compliant facilities, network, servers, databases, hypervisors, and operating system. Our entire environment receives monthly patches, 24 hours 7 days a week monitoring by our security operations center, internal and external network vulnerability assessments, penetration testing, reporting, documentation, and compliant backup and disaster recovery.

In addition to a compliant hosting environment, our applications force the use of a Hypertext Transfer Protocol Secure (HTTPS) connection between our clients and servers. This creates a secure browser connection, and encrypts information between our servers, employees, clients, and users.

When debugging and maintaining the CAN Portal, CAN’s development team access our production environment using secure shell (SSH) connections. These connections are authenticated using short-lived public key certificates that are issued to individual developers. These certificates are issued using two-factor authentication. Connections to the production environment are forced by network-level controls to pass through security proxies. This provides centralized auditing of connections into the production environment and control over access. Individuals are granted access on an as-need basis.

Media Disposal

When retired disks (hard drive, solid state drives, USB drives) containing client information and/or our clients’ customer information, are first logically wiped. Once they are logically wiped, someone on CAN’s IT team performs a second inspection to confirm that the disk has been successfully wiped.  All drives are tracked by their serial number. Successfully erased drives are released to inventory for future use. If a drive has failed, it must be securely stored until it can be physically destroyed.

Access Control

CAN uses authentication and authorization controls to protect against unauthorized access. Our goal is to make sure that the right people have access to the right information at the right time. Access control is managed by CAN’s IT team.

During new hire orientation, each CAN employee is assigned a unique User ID. At the end of a person’s employment, their account access to CAN’s network is disabled. CAN’s IT team also enforces CAN’s password policies. These policies include password expiration, restrictions on password use, and sufficient password strength. We also provide training on how to create random and strong passwords that are easy to remember.

Access rights and levels are based on an employee’s job description and client responsibilities. All employees are granted default permission to access company resources, such as email, calendars, and CAN’s internal backend. Additional access is based on an employee’s roles and client responsibilities. The goal is to layer security to minimize risks.

Employee Security

CAN’s employees are required to conduct themselves in a manner consistent with the company’s guidelines regarding confidentiality, business ethics, appropriate usage, and professional standards.

As part of the interview process, CAN verifies prospective employee education, employment, and references. If possible, CAN may also conduct criminal, credit, immigration, and security checks. The extent of verifications and background checks are dependent on the prospect’s desired position.

All employees must acknowledge receipt of and compliance with the policies in CAN’s employee manual and employment agreement, including a confidentiality agreement. In addition, all Employees receive training on CAN’s security policies, privacy policies, code of conduct, and employee manual. Training is a part of initial orientation and on going quarterly employee training. Additional training is available as needed.

Networking Monitoring and Security

CAN’s corporate network is protected and monitored using a Firewall. Using automatic threat detection, CAN’s Firewall prevents CAN’s employees from accessing websites or servers that are inappropriate for a work environment, host malware, attack code, or has been involved in sending spam. CAN’s IT team reviews reports monthly on network activity, including network traffic, employee activities, and outside network vulnerabilities.

Vulnerability Test

As necessary, CAN’s team scans for security threats using automated and manual penetrations efforts, quality assurance processes, software security reviews, and external audits.

Reporting Security Issues

Security is essential to CAN’s operations. If you have a security issue to report or have discovered a vulnerability, please contact us by email at support@can2013.wpengine.com or by phone at 866-963-6941. We will respond quickly and do our best to verify issues and fix potential problems as quickly as possible.

Disclosure

We ask that security researchers follow “Responsible Disclosure” as opposed to “Full Disclosure”. Full Disclosure is when a security researcher simultaneously notifies a vendor and the public of a security vulnerability. Responsible Disclosure is when a security researcher notifies a vendor and allows them time to fix the security vulnerability before announcing the vulnerability. Since we have a relatively small user base we ask that a security researcher allows us time to address vulnerabilities. We want to minimize the opportunity that attackers have to exploit a vulnerability.

We believe that Responsible Disclosure is a two way street and follows the guidelines outlined by Google in the article, “Rebooting Responsible Disclosure” http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html.

We support security researchers that hold vendors accountable while simultaneously practicing Responsible Disclosure by:

  • Assigning a deadline for disclosure for serious vulnerabilities consistent with the complexity of the fix.
  • Publishing an analysis of a vulnerability and suggested workarounds if the deadline for disclosure is missed.
  • Setting aggressive deadlines for disclosure if there is evidence that attackers already have knowledge of a given bug.

Incident Management

Once an issue has been reported CAN’s team will work to verify the issue, and if it is credible it will be sent to triage. CAN uses the following standards to triage threats. CAN uses the same standards to prioritize response to emergencies, privacy breaches, security vulnerability, and business interruptions. Standards ensure consistent and predictable responses, and help coordinate responses to multiple types and combinations of issues.

  • Critical: Impact or possible impact to many clients
  • High: Impact or possible impact to a small number of clients
  • Moderate: No impact to clients, but possible impact if combined with another breach, vulnerability, loss, or disaster.
  • Low: Possible hindrance to CAN’s operations, but no immediate impact to CAN’s clients or their data.
  • Other: These are issues that CAN’s is having difficulty verifying or reproducing. Once CAN has been able to verify the issue it will be prioritized or dismissed.

Disaster Recovery and Business Continuity

CAN’s work environment is designed to minimize interruptions in the event of an interruption due to disaster or the loss of people, facilities, technology, machinery, transportation, critical records, and vendors/partners. We have defined how to quickly call on secondary resources if we lose a primary resource. For more information please reference CAN’s Business Continuity Plan.

CAN conducts random tests of our Business Continuity Plan by requiring employees to spend a day a quarter working from home and requiring that all key executives take a complete week each year of vacation without access to the rest of the team. Our goal is to make sure that CAN is able to operate with the loss of our most critical primary resource, our people.

Summary

We work hard to make sure that your data is secure. Please contact us at support@can2013.wpengine.com if you have any questions or concerns.


Want More? Check out our latest blog posts.

 

Featured

March Machine Learning Mayhem

on March 13

Machine Learning and the NCAA Men’s Basketball Tournament Methodology  <<This article is meant to be the technical document following the above article. Please read the following article before continuing.>> “The…

More in

Curious? Read one of our success stories.

Case Study

Preparing for a Pandemic

How predictive analytics helped prepare for the H1N1 Pandemic.

CAN helped a regional healthcare system prepare for the 2009 H1N1 Swine Flu Pandemic. From April 2009 to April 2010…

View more Case Studies