Common use of Software Integrity Clause in Contracts

Software Integrity. The installed base of software on each Host is kept as small as possible. Software packages which have been deemed unnecessary or redundant have been eliminated so as to minimize the potential number of access points on any given Server. When an advisory for installed software is released from sources including CERT, SecurityFocus/BugTraq, and/or Synacor vendors, Synacor will immediately perform an evaluation of the relative risk. Highest priority (eg. Priority 1) is given where a known exploit is published that affects services accessible to public networks. Depending on the nature of the advisory a given service may be further restricted or shut down as we prepare an update. The time frames between an advisory, triage, testing and patching differ based on the severity of the advisory. A critical patch will be applied as soon as it has been staged and tested, and will receive the highest level of attention from Synacor staff; Adelphia will be notified either while the patch is being evaluated, or as soon afterward as possible, when relevant to the customer’s service. Non-critical patches will be applied as part of the Maintenance Window; however, Synacor may not reveal all details (other than affected services) to the customer until after the patch has been applied to prevent potential security breaches. With few exceptions, such as a fundamental design issue that necessitates changes that cannot be easily ported to installed versions, any updates related to security are applied to the existing version of the software, even if the fix is released by an upstream source in new release. This is to avoid ancillary changes which may result in undesired behavior or even new security risks. Regardless of source, any updates are tested independently for suitability before general deployment, both to test the correctness of the fix itself as well as general functionality. This review process is, of course, expedited in the case of a serious risk. The review process is: apply patch, build package, install on a test host, review by QA and System Administration personnel with an attempt to run any known exploit if one exists, install on a pilot machine, review again, and general deployment. Data Backups, backup handling: All data backups are performed once per night, only over a secured Private Network to a protected Host residing in a locked rack. Backups are kept off-site as defined herein. The on-call Synacor Systems Administrator is alerted in the event of a backup failure for immediate resolution. Alltapes that have been used to contain sensitive data are stored in a locked cabinet in the Synacor operations center, accessible only by Synacor personnel as described in the Physical Security section below, or in a locked office at Synacor’s corporate headquarters, accessible only to Synacor’s Systems staff and Controller. Failover Testing In order to ensure that the redundancy of Synacor’s architecture is working, Synacor will perform failover testing on the following components during initial deployment, and once every six (6) months, including but not limited to, web servers, database servers, and redundant network equipment. Additionally, load balancers will be failover tested once every three (3) months. Monitoring and Auditing Monitoring of hosts is performed both through the use of a central server and agents running on the individual machines. Among other things, log files and running processes are periodically checked against a checklist specifically given to that class of Host. Any deviation is immediately brought to the attention of the on-call Synacor personnel. The polling occurs every 5 minutes for each Host. Push updates from the clients are also on a 5 minute interval with slight delay randomization. There are processes running on two separate machines which ensure connectivity to the monitoring server and contact a Synacor administrator in case of failure. In addition, a test message is sent through the Monitoring notification infrastructure every 30 minutes in order to ensure that Monitoring infrastructure is operating to the designed specifications. In addition to local logging, each host reports a subset of system events to a central Host, which is monitored by the Synacor staff for any suspicious activity. Logs are archived for a period of one (1) year. Physical Security Twenty-Four (24) hour by Seven (7) days a week building security, including but not limited to uniformed guard service, interior and exterior closed-circuit television surveillance, provided by the Main Place Liberty Group. The collocation facility, provided by Switch and Data, includes several forms of security and access control including but not limited to individual pass card access to the administration facility, with an additional secured door protecting the server room. Inside the facility is an additional closed-circuit television system, with the additional capability for off-site monitoring by authorized personnel. Staffing of the facility is maintained Twenty-Four (24) hour by Seven (7) days a week, providing constant monitoring and a point of contact for any non-secured personnel. Visitors are required to be signed in and are provided with escort until such time as they vacate the secured area. The only personnel allowed physical access to Synacor’s servers are authorized Synacor employees, paid contractors, and vendors or other entities escorted by authorized Synacor staff members. Authentication and Authorization Accounts on any Host are created on a strictly discretionary basis, with access on most Hosts being restricted solely to Synacor administration staff. Superuser (root) access is even more stringently restricted, with no one outside the current Synacor administration staff having access to the passwords. When each account is created it is created it is assigned a one time (Non-Dictionary) password, which is transmitted to the intended user face-to-face or through a phone call in which the recipient’s identity is verifiable , in order to facilitate the user setting their own. All passwords, including those which are strictly temporary, are verified with the ‘cracklib’ (Defined: A password library which can be used to prevent users from creating passwords which can easily be guessed by and intruder) module to be sufficiently strong. Once accounts are created, authentication is done solely via encrypted channels: either TLS (“Transport Layer Security”) or SSH (“Secure Shell”). Incident Management Synacor has adopted the following Incident Response Plan. Incidents are defined as malicious attacks to gain access to Synacor systems, including hacking attempts and other intrusions. Identifiable denial-of-service attacks are also included, when they target equipment controlled by Synacor. Security Incident Response Team (“SIRT”) The primary SIRT team will be comprised of the following roles: The SIRT Team Leader, currently the Systems Manager, is responsible for overseeing the team and conducting policy review once a year and after each incident. The SIRT Incident Lead will be selected based on the nature of the incident, and will either be a Synacor System Administrator, Network Administrator, or the IT Manager. The Incident Lead is responsible for coordinating and reporting on the response. The SIRT Communications Lead is responsible for managing communications between the response team, internal interested parties such as account managers and Synacor executives, and external clients as appropriate. This role is currently assigned to the Senior Account Manager.

Software Integrity. The installed base of software on each Host is and will be kept as small as possiblepossible by Synacor. Software packages which that have been deemed unnecessary or redundant have been eliminated so as to minimize the potential number of access points on any given Server. Only necessary software packages will be used by Synacor on a going-forward basis. When an advisory for installed software is released from sources including CERT, SecurityFocus/BugTraq, and/or and Synacor vendors, Synacor will immediately perform an evaluation of the relative risk. Highest priority (eg. e.g., Priority 1) is will be given where a known exploit is published that affects services accessible to public networks. Depending on the nature of the advisory advisory, a given service may be further restricted or shut down as we prepare Synacor prepares an update. The time frames between an advisory, triage, testing and patching differ will differ, as appropriate, based on the severity of the advisory. A critical patch will be applied by Synacor as soon as it has been staged and tested, and will receive the highest level of attention from Synacor staff; Adelphia Client will be notified either while the patch is being evaluated, or as soon afterward as possible, when relevant to Client’s or the customerUser’s service. Non-critical patches will be applied by Synacor as part of the Maintenance Window; however, to prevent potential security breaches, Synacor may not reveal all details (other than affected services) to the customer Client or User until after the patch has been applied to prevent potential security breachesapplied. With few exceptions, such as a fundamental design issue that necessitates changes that cannot be easily ported to installed versions, Synacor will apply any updates related to security are applied to the existing version of the software, even if the fix is released by an upstream source in new release. This is Such process will be followed in order to avoid ancillary changes which that may result in undesired behavior or even new security risks. Regardless of source, Synacor will test any updates are tested independently for suitability before general deployment, both in order to test both the correctness of the fix itself as well as its general functionality. This Synacor will expedite such review process is, of course, expedited in the case of a serious risk. The Such review process iswill involve the following steps: apply patch, build package, install on a test host, review by Synacor’s QA and System Administration personnel with an attempt to run any known exploit if one exists, install on a pilot machine, review again, and general deployment. Data Backups, backup handling: All data backups are performed once per night, only over a secured Private Network to a protected Host residing in a locked rack. Backups are kept off-site as defined herein. The on-call Synacor Systems Administrator is alerted in the event of a backup failure for immediate resolution. Alltapes that have been used to contain sensitive data are stored in a locked cabinet in the Synacor operations center, accessible only by Synacor personnel as described in the Physical Security section below, or in a locked office at Synacor’s corporate headquarters, accessible only to Synacor’s Systems staff and Controller. Failover Testing In order to ensure that the redundancy of Synacor’s architecture is working, Synacor will perform failover testing on the following components during initial deployment, and once every six (6) months, including but not limited to, web servers, database servers, and redundant network equipment. Additionally, load balancers will be failover tested once every three (3) months. Monitoring and Auditing Monitoring of hosts is performed both through the use of a central server and agents running on the individual machines. Among other things, log files and running processes are periodically checked against a checklist specifically given to that class of Host. Any deviation is immediately brought to the attention of the on-call Synacor personnel. The polling occurs every 5 minutes for each Host. Push updates from the clients are also on a 5 minute interval with slight delay randomization. There are processes running on two separate machines which ensure connectivity to the monitoring server and contact a Synacor administrator in case of failure. In addition, a test message is sent through the Monitoring notification infrastructure every 30 minutes in order to ensure that Monitoring infrastructure is operating to the designed specifications. In addition to local logging, each host reports a subset of system events to a central Host, which is monitored by the Synacor staff for any suspicious activity. Logs are archived for a period of one (1) year. Physical Security Twenty-Four (24) hour by Seven (7) days a week building security, including but not limited to uniformed guard service, interior and exterior closed-circuit television surveillance, provided by the Main Place Liberty Group. The collocation facility, provided by Switch and Data, includes several forms of security and access control including but not limited to individual pass card access to the administration facility, with an additional secured door protecting the server room. Inside the facility is an additional closed-circuit television system, with the additional capability for off-site monitoring by authorized personnel. Staffing of the facility is maintained Twenty-Four (24) hour by Seven (7) days a week, providing constant monitoring and a point of contact for any non-secured personnel. Visitors are required to be signed in and are provided with escort until such time as they vacate the secured area. The only personnel allowed physical access to Synacor’s servers are authorized Synacor employees, paid contractors, and vendors or other entities escorted by authorized Synacor staff members. Authentication and Authorization Accounts on any Host are created on a strictly discretionary basis, with access on most Hosts being restricted solely to Synacor administration staff. Superuser (root) access is even more stringently restricted, with no one outside the current Synacor administration staff having access to the passwords. When each account is created it is created it is assigned a one time (Non-Dictionary) password, which is transmitted to the intended user face-to-face or through a phone call in which the recipient’s identity is verifiable , in order to facilitate the user setting their own. All passwords, including those which are strictly temporary, are verified with the ‘cracklib’ (Defined: A password library which can be used to prevent users from creating passwords which can easily be guessed by and intruder) module to be sufficiently strong. Once accounts are created, authentication is done solely via encrypted channels: either TLS (“Transport Layer Security”) or SSH (“Secure Shell”). Incident Management Synacor has adopted the following Incident Response Plan. Incidents are defined as malicious attacks to gain access to Synacor systems, including hacking attempts and other intrusions. Identifiable denial-of-service attacks are also included, when they target equipment controlled by Synacor. Security Incident Response Team (“SIRT”) The primary SIRT team will be comprised of the following roles: The SIRT Team Leader, currently the Systems Manager, is responsible for overseeing the team and conducting policy review once a year and after each incident. The SIRT Incident Lead will be selected based on the nature of the incident, and will either be a Synacor System Administrator, Network Administrator, or the IT Manager. The Incident Lead is responsible for coordinating and reporting on the response. The SIRT Communications Lead is responsible for managing communications between the response team, internal interested parties such as account managers and Synacor executives, and external clients as appropriate. This role is currently assigned to the Senior Account Manager.