Questions? Feedback? powered by Olark live chat software
+1 650 627 7667 Contact Us

Agari Security Program

1. Agari SaaS Environments

The infrastructure for Agari Customer Protect (my.agari.com) is redundantly hosted on multiple Availability Zones (AZ) within Amazon Web Service’s (AWS) US-West2 (OR) Public Cloud Region. All software maintenance and configuration activities are conducted by Agari employees, primarily from our corporate office in San Mateo, California.

We employ a multi-tenant architecture using logical access controls both within the application and at the database layer to ensure the necessary separation between customers. We leverage AWS for the security and scalability of the cloud and Agari personnel handle the security and scalability of our systems hosted within the cloud. Agari customers are provided with the roles and privileges needed to manage their own data and users at the application level.

Agari follows industry standard best practices for security and scalability as well as the knowledge and experience gained developing and maintaining security applications both at Agari and previously at companies like Cisco, IronPort and LiveOps.

1.1 SaaS Management and Access Control

Access to the Agari SaaS production systems is restricted to appropriate engineering and operations personnel on a least-privilege basis. AWS console access requires a multi-factor login and root access requires a physical 2 factor token which is kept under lock and key. Application level administrator access also requires 2factor access and all application passwords must meet password complexity requirements. Additionally, repeated failed login attempts force a password reset to prevent brute-force style attacks. Logins to our host operating systems is further restricted by source IP, requires SSH PKI passwordless authentication as well as a 2factor token. Generic administrative accounts are disabled. Agari periodically reviews employee access to internal systems. Reviews ensure that employees’ access rights and access patterns are commensurate with their current positions.

1.2 Data Access by Customers

Customer end users are authorized only to see data from their account and may have additional privilege restrictions placed on their access to the account by their account administrator. Customer end users are identified with a username and password and customer administrators can set their own password complexity rules. Agari also support SAML and OAUTH based Single Sign-On so clients may leverage their own Identity Provider. All access to the Agari Web Application requires an SSL connection.

1.3 Auditing

Detailed audit logs are maintained at all levels of the system: application, AWS Cloudtrail, operating system and network and are monitored on a 24/7 basis for anomalous behavior as well as stored indefinitely in a write only manner for possible forensic investigation.

2. Risk Management

Agari has completed a company wide Risk Assessment in Q1 of 2016, led by Hooman Mohajeri of Strata Consulting. Risks areas assessed include Financial, HR, Internal IT, Facilities and Product Engineering. All CRITICAL findings were remediated immediately and several several security and compliance projects are ongoing in 2016 .

Prior efforts have included a Business Continuity audit of our corporate systems in 2013 and ongoing assessments of our engineering systems based on the possible risks to our customers and Agari itself. Agari maintains coverage to insure against major risks. Policies include errors and omissions liability, commercial general liability, commercial umbrella liability, workers’ compensation and employer’s liability, fiduciary liability and directors’ and officers’ liability. Insurance companies, which management believes to be financially sound, provide coverage. Coverage is maintained at levels which Agari considers reasonable given the size and scope of its operations.

3. Security Policies

3.1 Policies

Agari maintains, and annually updates, a collection of written Security & Privacy Policies, which include employee’s responsibilities toward all types of assets, training, confidentiality of client data and acceptable use of resources. All staff must review and sign these policies during on-boarding and at least once per year. Additionally, Agari engineering and operations personnel must review and acknowledge specialized policies and procedures governing practices such as incident response process, change management, encryption and backups. Such policies and procedures are defined as standalone documents, and communicated separately to the appropriate audience. Individual employee review is tracked in our HR system.

3.2 Information and Communication

Agari employs various methods of communication, including email, Slack channels, JIRA Confluence and Google Sites to update employees on current events and policies, and share information relevant to employees, such as corporate data, industry news, training and development materials, employee resources, and other corporate policies. Update of key documents such as policies require email notification to the affected staff.

3.3 Access control to program source code

Write access to Agari source code is limited to the engineering staff, some additional personnel may be granted read-only access to specific repositories as required by their job function.

3.4 Acceptable Use

3.4.1 Electronic Communications and Internet Use

The following guidelines have been established for using the company’s Internet systems (“Internet”), company-provided cell phones and email in an appropriate, ethical and professional manner: Internet, company-provided equipment (e.g., cell phone, laptops, computers) and services may not be used for transmitting, retrieving or storing any communications of a defamatory, discriminatory, harassing or pornographic nature. The following actions are forbidden: using disparaging, abusive, profane or offensive language; creating, viewing or displaying materials that might adversely or negatively reflect upon Agari or be contrary to Agari’s best interests; and engaging in any illegal activities, including piracy, extortion, blackmail, copyright infringement, and unauthorized access of any computers and company-provided equipment such as cell phones and laptops. Employees may not copy, retrieve, modify or forward copyrighted materials, except with permission or as a single copy to reference only. Employees must not use the system in a way that disrupts its use by others. Employees should not open suspicious emails, pop-ups or downloads. Contact IT with any questions or concerns to reduce the release of viruses or to contain viruses immediately. Internal and external emails are considered business records and may be subject to discovery in the event of litigation. Be aware of this possibility when sending email within and outside the company.

3.4.2 Right to Monitor

All company-supplied technology, including but not limited to, databases, internet, email and voice mail systems, and company-related work records belong to the company and not to the employee, and employees should have no expectation of privacy in its contents, or the contents of information sent or received using the company’s systems. Such company-supplied technology is subject to unannounced monitoring, inspections, searches, filtering, data analysis, retrieval, and disclosure, on a periodic and/or ongoing basis, wichin the sole discretion of the company. Inappropriate or illegal use or communications may be subject to disciplinary action up to and including termination of employment. Employees consent to the terms of this policy by their use of the company’s technology.

3.4.3 Social Media – Acceptable Use

Employees may not post confidential or proprietary information about the company, clients, employees or applicants. Employees may not post about aspects of the company that is part of a non-disclosure agreement; doing so is grounds for immediate termination and legal action. Employees must be respectful to fellow employees, customers, partners and competitors. If an employee does decide to post complaints or criticism, employees may not post any material that is defamatory, libelous, threatening, abusive or embarrassing to another person or entity related to Agari. When posting on social media sites, including blogs, discussion forums, newsgroups, and email distribution lists, if Agari is a subject of the content an employee is creating, the employee must be clear and open about the fact that he or she is an employee and make it clear that his or her views do not represent those of

4. Organization of Information Security

4.1 Information Security Coordination

The Agari Director of Engineering and Security coordinates all security and privacy efforts. This function reports directly to the CTO. Responsibilities of this role include:

  • Driving Security and Privacy initiatives
  • Communication and education of these initiatives both within engineering and with the rest of the company
  • Risk Management and Disaster Recovery planning and testing
  • Coordination with corporate Business Continuity Planning and testing
  • Security Incident Response planning and testing
  • Perform annual security and privacy assessment and reviews
5. Human Resources Security

5.1 Employee Screening

All Agari employees are required to submit to a background check and provide specific documents verifying identity at the time of employment. Failure to cooperate fully with the background check process or any dishonestly or omissions in the information provided may preclude employment with Agari. Background checks differ by geography to account for local laws. In all cases, they include criminal checks, education and employment reports. All background checks for US employees comply with the Fair Credit Reporting Act. Background checks are performed by a reputable third party vendor.

5.2 Terms of Employment

General information security responsibilities are documented in the Agari Security & Privacy Policies, which all employees must review and sign as part of their onboarding and at least once per annum. All Agari employees must sign the Agari confidentiality agreement (NDA) at the time they join the organization. Periodic verbal and email reminders are provided. Upon termination, employees are provided another copy of their agreement.

6. Asset Management

All data collected by Agari on behalf of its clients is classified as highly confidential under the Agari Customer Information Security Policy policy, which provides employees with the necessary guidance for the handling of all information according to its classification. Access to customer data is restricted to legitimate business use only and only to appropriate personnel. All data collected on behalf of customers is processed and stored in the United States. The Agari Master Service Agreement and product specific addendums detail the nature of the data collected and acceptable use.  Data are encrypted when in transit between systems and the client browser and all backups are encrypted.

6.1 Client Data Location

All client data is processed and stored in the United States though data may transit through host countries en route to our US based data centers.

6.2 Media Handling

The Agari Customer Information Security Policy explicitly prohibits copying customer data onto removable media device, including flash drives, hard drives, tapes or other media, other than for legitimate business purposes and with the express authorization from the customer. This authorization can be contingent on encryption being used. All confidential printed information, including client data, is disposed of in secure containers, and shredded weekly. Agari deletes all client data, other than copies held for disaster recovery and archival back-up purposes, on a scheduled basis following termination of contract.

7. Physical and Environmental Security

7.1 Agari Product Security

The Agari Customer Protect and Enterprise Protect production and staging environments are entirely hosted with Amazon Web Services. We leverage their excellent and thoroughly audited physical security infrastructure. More details can be found on the AWS Security page. Agari clients who want to review the AWS’ compliance documentation must sign an NDA directly with Amazon.

7.2 Agari Corporate Security

Agari headquarters is located in San Mateo. All external doors both the building and to the floors where Agari employees are located are video monitored. Entrance to the Agari offices requires a badge to unlock the door and all entrances and exits are logged.  The Agari wifi uses industry standard best practices for authentication, authorization and encryption. The LAN is continually monitored for unknown or suspicious connections.

8. Operational Security and Reliability

8.1 Networking

We implement the full suite of AWS’ network layer protections including Virtual Private Clouds, security groups, network ACLs, routing tables, and external gateways. All Network/System management machines are managed in a separate network and VPC Flow logs are stored indefinitely in a secure S3 bucket. The Production, Staging and Development environments are separated into their own VPCs and firewalls are configured DENY ALL by default and are completely separate from corporate and internal IT networks. Only required ports and protocols are allowed inbound. We employ a primary-secondary approach to our primary DNS domains leveraging both Neustar’s UltraDNS and Dynect’s solutions to mitigate the impact of DNS DDOS attacks.

8.2 Intrusion, Anomaly Detection and Monitoring & Alerting

Primary security monitoring and reporting tools employed by Agari Engineering:

AlertLogic is a network level IDS deployed to all production and staging Amazon instances. They provide comprehensive protection with an extensive IDS signature database, continual updates, and unlimited vulnerability scanning. This service is enhanced by employing their Alert Logic Security Operations Center (SOC) which provides 24×7 security monitoring by certified security analysts using state-of-the-art technology.

DataDog‘s Cloudtrail integration stores all AWS API calls for 13 months. These are stored in an easily searchable manner making it possible to identify and audit every action taken, system accessed or file downloaded for every set of credentials that has accessed our systems.

All relevant system and application logs are sent to LogEntries. All logs are eventually shipped to a secure AWS S3 bucket and stored indefinitely.

8.3 Change Management

  1. Customer contacts Agari Solutions Engineering (Support) with change request (feature or defect)
  2. Solutions Engineering logs the request through the Agari Issue Tracker (Jira)
  3. Feature requests are reviewed by Agari Product Management and prioritized and documented as a story in the product backlog.
  4. Non-severity 1 defects are reviewed by Agari Engineering and Product Management and prioritized and documented as a story in the engineering backlog.
  5. A story is scheduled for a sprint during planning.
  6. The story is scoped by the engineering team and assigned.  New features go through a vulnerability assessment, including encryption and top vulnerability checklist.
  7. Development is completed, code is reviewed by a second engineer and manual and automated tests are written for the feature.
  8. A build is generated and automated tests are run against the new feature.
    1. Automated tests include Brakeman security static code analysis
  9. The build is reviewed and approved by engineering management and placed on the Stage environment for evaluation.
    1. Tinfoil Security Web Application scanner runs weekly against Staging and Production.
    2. An additional set of regression tests are launched daily by Jenkins against staging to test for issues such as data consistency that cannot be checked during integration testing.
  10. The feature/defect is validated by quality assurance and product management (features).
  11. A production deployment request is created in email including:
    1. Business justification for the change
    2. Nature of defect (if applicable)/enhancement
    3. Details of the build and Testing performed
    4. Systems affected
    5. Risk level
    6. Rollback instructions
    7. (All requests are archived and accessible to review for auditing purposes.)
  12. The deployment request is reviewed and approved by engineering management and operations for production deployment.
  13. Operations deploys the change.
  14. The request is updated in Jira by the assigned engineer as Resolved.
  15. The author of the change request is notified, verifies that the feature is in place or the defect is fixed and then notifies the customer as agreed.

8.4 Capacity Management

All aspects of the SaaS system are tracked and evaluated for capacity inflection points. Agari engineering regularly reviews these data and schedules upgrades and performance enhancement changes as required.

8.5 Malware Protection

All laptops are centrally managed by internal IT and are required to have disk level encryption, automatic updates and antivirus software installed and running.

8.6 Data Backup

To ensure our customers are not impacted by data loss or equipment failures all data critical to the operation and management of our systems must be stored redundantly and backed up regularly. Further details are covered in the policy “System Backup Policy and Procedures” which all engineering and operations personnel must review at least once per year and when hired.

8.7 Technical Vulnerability Management

Agari subscribes to all vendor and independent security notification services to monitor potential external threats. Manual and automated vulnerability testing is performed during the development process. Nessus vulnerability scans run weekly on all exposed services and we perform Tinfoil Application security scans on both production and staging web applications at least once per week. No less than once a year, Agari engages with reputable third party security firms to conduct weekly network vulnerability and application vulnerability scans as well as annual authenticated penetration tests. Vulnerabilities are logged as defects, resolved or mitigated, and verified fixed.

8.8 Hardening Controls and Build Management

Agari SaaS uses automated tools and documented procedures to build, configure and ensure consistency between all operating systems, frameworks, tools and applications. Further, these systems are architected to minimize security risks. Specifically:

  • Agari follows vendor and open source maintainer’s hardening recommendations and documented standard operating procedures
  • Unnecessary ports, protocols, services and features are disabled
  • Only necessary components, scripts, drivers, web services are included and enabled

8.9 Patch Management

Agari leverages AWS’ impressively audited systems to ensure all AWS managed components are patched. At the operating system level Agari tests and rolls out all critical Ubuntu Security updates within 1 business day.

9. Development
Agari follows an agile development methodology in which products are deployed on an iterative, rapid release cycle. Security and security testing are implemented throughout the software development lifecycle. Quality Assurance is involved at each phase of the lifecycle and security best practices are a mandated aspect of all development activities. Agari employs both internal and third party security vulnerability scanners. Peer code review is mandated. The development process includes a review of all embedded third party components to ensure that security updates are incorporated. Use of open source software is subject to technical and legal review and approval. All software developers are located within the United States and are required to attend annual security training based on OWASP and SANs best practices. Additionally, Agari employs ethical, 3rd party penetration testers at least annually across all product lines as well as annual, company wide risk assessments.
10. Supplier Relationships

Agari may use contractors for development and testing tasks. These individuals work under the direct supervision of Agari employees and may have access to client data in accordance with contract terms. All contractors must be vetted and approved by management prior to their engagement. Agari retains exclusively world renown third party suppliers with stellar backgrounds such as Amazon (for cloud infrastructure). All third party supplies must be vetted according to the policies and standards outlined in our Application Service Provider Policy and Standards document.

11. Incident Response

Agari has established a Computer Security Incident Response Capability (CSIRC) to address computer security incidents, including theft, misuse of data, intrusions, hostile probes, and malicious software. When an incident occurs, the on call engineer must notify Agari executive management and engineering resources within 30 minutes of detection. A written preliminary report must be submitted within two working days. Within five working days of the resolution of an incident, a written final report must be submitted. In cases where incident resolution is expected to take more than thirty days, a weekly status report must be sent to the previously mentioned parties. A security incident is defined to be any adverse event that threatens the security of information resources. Adverse events include compromises of integrity, denial of service, data lost, sold or used in an unauthorized fashion, loss of accountability, or damage to any part of the system. Complete details of this process are documented in “Agari Security Incident Response Plan.pdf” part of our overall Security and Privacy document repository.

12. Business Continuity and Disaster Recovery

12.1 Business Continuity

We have launched our first, comprehensive BCP project in Q3 2017 and expect to be finished early in 2018.

12.2 Disaster Recovery

The Agari Customer Protect web application is hosted on multiple Availability Zones within (AZ) Amazon’s US-West2 (OR) Cloud Region. We can survive the loss of an entire AZ without service interruption. In the unlikely event of a disaster impacting all of Amazon’s Oregon based data centers, we can rebuild our infrastructure from our offsite data backups and build repositories within 72 hours.

12.3 Scalability and Redundancy

We use AWS Elastic Load Balancers (ELB) to distribute traffic across Availability Zones and to make it possible to quickly add capacity to our Web Application Server groups and to ensure availability through system health checks and smart traffic routing. At the data store layer we utilize both ElasticSearch and CitusDB DB clusters enabling horizontal scaling, multi-node data redundancy and high performance queries. Within our data pipelines we leverage AWS autoscale groups, SQS/SNS, EMR driven Spark Clusters and Elastically Load Balanced Postfix servers to handle our ever growing and bursty data ingest needs.