Common use of Security Vulnerabilities Clause in Contracts

Security Vulnerabilities. We have made architectural choices that make vulnerabilities more difficult to introduce. For example, the identity and privilege level of the remote user is threaded throughout the application, all the way to the datastore, which enforces access rules in a testable, auditable place. The peer-code review process serves as a backstop against intentional or accidental vulnerabilities. We use automated static analysis tools that alert us to potential security problems in the code, and those checks must pass in order for code to get deployed. We have automated tools that monitor for security vulnerabilities in the third-party code dependencies and automatically propose patch updates. We rely on AWS’s mature vulnerability management practice for patching known vulnerabilities at the operating system, virtualization, and hardware layers. We divide our systems into separate environments for development, staging and production. Each environment is an independent domain with respect to network access control, service account credentials, and secrets. No access to the production, staging or development environments is allowed except on known protocols and ports via our front-end load balancers. All access to our services from user devices, or between our client software and our service is protected by TLS version 1.2 or higher. Our public endpoints, (for example, xxxxxxx.xx) receive an A+ rating from Qualys SSL Labs. To minimize the risk of data exposure, Nametag adheres to the principle of least privilege. Employees are only authorized to access data that they reasonably must handle in order to do their job: all engineers have access to their development environments, fewer engineers have access to the staging environment (only those who need access to perform their jobs), and far fewer have access to the production environment. All internal systems require our employees to authenticate with unique user accounts. Personal Information received from Customers or End Users in Asia, North America or South America will be stored and processed in the United States. Personal Information received from Customers or End Users in Europe or Africa will be stored and processed in Ireland or Germany. All employees complete mandatory security awareness training once per year. In addition to general resistance to online threats, we teach our staff to resist social engineering attacks through our support channels. All employees are trained in protecting the identities and confidential information of our clients. Although we do not generally handle protected health information (PHI), all employees are trained to identify and report any incidental contact with it.

Appears in 2 contracts

Samples: Cloud Services Agreement, Cloud Services Agreement

AutoNDA by SimpleDocs

Security Vulnerabilities. We have made architectural choices that make vulnerabilities more difficult to introduce. For example, the identity and privilege level of the remote user is threaded throughout the application, all the way to the datastore, which enforces access rules in a testable, auditable place. The peer-code review process serves as a backstop against intentional or accidental vulnerabilities. We use automated static analysis tools that alert us to potential security problems in the code, and those checks must pass in order for code to get deployed. We have automated tools that monitor for security vulnerabilities in the third-party code dependencies and automatically propose patch updates. We rely on AWS’s mature vulnerability management practice for patching known vulnerabilities at the operating system, virtualization, and hardware layers. We divide our systems into separate environments for development, staging and production. Each environment is an independent domain with respect to network access control, service account credentials, and secrets. No access to the production, staging or development environments is allowed except on known protocols and ports via our front-end load balancers. All access to our services from user devices, or between our client software and our service is protected by TLS version 1.2 or higher. Our public endpoints, (for example, xxxxxxx.xx) receive an A+ rating from Qualys SSL Labs. To minimize the risk of data exposure, Nametag adheres to the principle of least privilege. Employees are only authorized to access data that they reasonably must handle in order to do their job: all engineers have access to their development environments, fewer engineers have access to the staging environment (only those who need access to perform their jobs), and far fewer have access to the production environment. All internal systems require our employees to authenticate with unique user accounts. Personal Information received from Customers or End Users All Customer Data is maintained in Asiathe State of Ohio, United States (for North America or and South America will be stored and processed in the United States. Personal Information received from Customers Customer Data) or End Users in Europe or Africa will be stored and processed in Ireland or GermanyGermany (for European Customer Data). All employees complete mandatory security awareness training once per year. In addition to general resistance to online threats, we teach our staff to resist social engineering attacks through our support channels. All employees are trained in protecting the identities and confidential information of our clients. Although we do not generally handle protected health information (PHI), all employees are trained to identify and report any incidental contact with it.

Appears in 2 contracts

Samples: Data Processing Addendum, Data Processing Addendum

AutoNDA by SimpleDocs
Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!