{"component": "clause", "props": {"groups": [{"samples": [{"hash": "jc4W3vBK90e", "uri": "/contracts/jc4W3vBK90e#vulnerabilities", "label": "Implementation and Maintenance Agreement", "score": 35.0207977295, "published": true}, {"hash": "2V9xEghE0hy", "uri": "/contracts/2V9xEghE0hy#vulnerabilities", "label": "Framework Agreement", "score": 33.3027458191, "published": true}, {"hash": "bwoNueOmLio", "uri": "/contracts/bwoNueOmLio#vulnerabilities", "label": "Framework Agreement", "score": 33.1549263, "published": true}], "size": 7, "snippet_links": [{"key": "during-the-term-of-the-agreement", "type": "clause", "offset": [0, 32]}, {"key": "contractor-and-or", "type": "clause", "offset": [37, 54]}, {"key": "the-manufacturer", "type": "definition", "offset": [55, 71]}, {"key": "relevant-product", "type": "definition", "offset": [79, 95]}, {"key": "product-or-service", "type": "clause", "offset": [226, 244]}, {"key": "prevention-measures", "type": "definition", "offset": [252, 271]}], "snippet": "During the term of the Agreement the Contractor and/or the manufacturer of the relevant product are obliged to inform or publish information about the discovered vulnerabilities of the information and communication technology product or service, their prevention measures and deadlines.", "hash": "18c71899067ae8137b1315be8e3d5fb8", "id": 1}, {"samples": [{"hash": "798endcyO8f", "uri": "/contracts/798endcyO8f#vulnerabilities", "label": "Data Processing Addendum", "score": 34.8432273865, "published": true}, {"hash": "aqGF0K9zD0Q", "uri": "/contracts/aqGF0K9zD0Q#vulnerabilities", "label": "Data Processing Addendum", "score": 34.7935943604, "published": true}, {"hash": "4GBhB7LR0nO", "uri": "/contracts/4GBhB7LR0nO#vulnerabilities", "label": "Data Protection Agreement", "score": 32.4367218018, "published": true}], "size": 5, "snippet_links": [{"key": "provider-shall", "type": "clause", "offset": [0, 14]}, {"key": "in-place", "type": "clause", "offset": [29, 37]}, {"key": "security-vulnerabilities", "type": "definition", "offset": [54, 78]}, {"key": "notice-of", "type": "definition", "offset": [169, 178]}, {"key": "business-days-of", "type": "clause", "offset": [256, 272]}, {"key": "public-acknowledgement", "type": "clause", "offset": [277, 299]}, {"key": "scoring-system", "type": "definition", "offset": [630, 644]}, {"key": "the-risk", "type": "clause", "offset": [678, 686]}, {"key": "as-agreed", "type": "clause", "offset": [690, 699]}, {"key": "use-of-open-source-code", "type": "clause", "offset": [726, 749]}], "snippet": "Provider shall have controls in place to identify any security vulnerabilities in the Solutions during development and after release. Provider shall provide RSA written notice of: (a) publicly-acknowledged vulnerabilities/zero-day exploits within five (5) business days of the public acknowledgement, and (b) internally-known yet publicly-undisclosed vulnerabilities/zero-day exploits within ten (10) business days of their discovery. Provider commits to remediate all vulnerabilities identified in the Solutions at Provider\u2019s expense, and to remediate vulnerabilities with a base score above 4 as defined by Common Vulnerability Scoring System in a timeframe commensurate with the risk or as agreed upon with RSA. Provider\u2019s use of open source code shall not alter Provider\u2019s responsibility to identify and remediate vulnerabilities as described here.", "hash": "f55929f17f69821ead3067f8f7b593c0", "id": 3}, {"samples": [{"hash": "47UU45jyUn2", "uri": "/contracts/47UU45jyUn2#vulnerabilities", "label": "End User Agreement", "score": 25.6507263184, "published": true}, {"hash": "iHibSt5tIr3", "uri": "/contracts/iHibSt5tIr3#vulnerabilities", "label": "End User Agreement", "score": 22.4291572571, "published": true}, {"hash": "gMiF4LtgpdK", "uri": "/contracts/gMiF4LtgpdK#vulnerabilities", "label": "End User Agreement", "score": 22.4291572571, "published": true}], "size": 6, "snippet_links": [{"key": "figure-6", "type": "definition", "offset": [0, 8]}, {"key": "an-overview", "type": "clause", "offset": [15, 26]}, {"key": "at-the-end-of", "type": "clause", "offset": [154, 167]}, {"key": "successful-attack", "type": "definition", "offset": [176, 193]}, {"key": "a-site", "type": "definition", "offset": [322, 328]}, {"key": "the-user", "type": "clause", "offset": [349, 357]}, {"key": "important-information", "type": "definition", "offset": [372, 393]}, {"key": "web-servers", "type": "clause", "offset": [795, 806]}, {"key": "server-software", "type": "clause", "offset": [879, 894]}, {"key": "national-institute-of-standards-and-technology", "type": "definition", "offset": [1753, 1799]}, {"key": "in-time", "type": "definition", "offset": [2095, 2102]}, {"key": "relevant-banks", "type": "definition", "offset": [2399, 2413]}, {"key": "is-likely", "type": "definition", "offset": [2447, 2456]}, {"key": "publication-date", "type": "clause", "offset": [2567, 2583]}, {"key": "december-2016", "type": "clause", "offset": [2585, 2598]}, {"key": "communications-security", "type": "definition", "offset": [2631, 2654]}, {"key": "online-banking", "type": "clause", "offset": [2658, 2672]}, {"key": "network-traffic", "type": "clause", "offset": [2822, 2837]}, {"key": "target-site", "type": "definition", "offset": [2898, 2909]}, {"key": "client-support", "type": "definition", "offset": [3333, 3347]}, {"key": "data-session", "type": "definition", "offset": [3560, 3572]}, {"key": "where-one-party", "type": "clause", "offset": [3730, 3745]}, {"key": "the-connection", "type": "clause", "offset": [3761, 3775]}, {"key": "the-problem", "type": "clause", "offset": [4148, 4159]}, {"key": "browser-support", "type": "clause", "offset": [4259, 4274]}, {"key": "the-banks", "type": "clause", "offset": [4397, 4406]}, {"key": "the-issue", "type": "clause", "offset": [4442, 4451]}, {"key": "a-number", "type": "definition", "offset": [4495, 4503]}, {"key": "integrity-of", "type": "clause", "offset": [4581, 4593]}, {"key": "not-offer", "type": "clause", "offset": [4717, 4726]}, {"key": "lack-of", "type": "clause", "offset": [4856, 4863]}, {"key": "the-assumption", "type": "clause", "offset": [5170, 5184]}, {"key": "the-period", "type": "clause", "offset": [5284, 5294]}, {"key": "length-of", "type": "clause", "offset": [5457, 5466]}, {"key": "number-of-sites", "type": "definition", "offset": [5539, 5554]}, {"key": "significant-change", "type": "definition", "offset": [5907, 5925]}, {"key": "reduction-in", "type": "definition", "offset": [5941, 5953]}, {"key": "very-weak", "type": "definition", "offset": [5975, 5984]}, {"key": "acknowledged-by", "type": "definition", "offset": [6289, 6304]}, {"key": "security-of", "type": "clause", "offset": [6444, 6455]}, {"key": "authentication-codes", "type": "clause", "offset": [6464, 6484]}, {"key": "encryption-key", "type": "definition", "offset": [6516, 6530]}, {"key": "to-export", "type": "definition", "offset": [6551, 6560]}, {"key": "to-construct", "type": "clause", "offset": [6635, 6647]}, {"key": "closure-of-the", "type": "clause", "offset": [6755, 6769]}], "snippet": "Figure 6 shows an overview of the vulnerabilities and how often we encountered them among the 80 surveyed banks. Each vulnerability is discussed briefly. At the end of 2014, a successful attack was made against SSL 3.0 and TLS 1.0 when block ciphers are used. An adversary manipulates a user\u2019s browser to send requests to a site using SSL/TLS where the user is logged in. Important information can be derived by observing the cipher text, such as session cookies that can be used to hijack sessions. This attack was named POODLE [Mo\u00a8ller et al. 2014; \u2587\u2587\u2587\u2587\u2587\u2587\u2587 2014]*. Vulnerabilities to POODLE are only noted for 2015 since the attack was not yet known in 2013. For SSL 3.0, the only way to protect against POODLE is by disabling cipher suites that use block ciphers. POODLE also works with some web servers that implement padding in TLS 1.0 incorrectly, which updates to the web server software might be able to solve. Figure 6 shows the number of banks that are vulnerable to POODLE with either SSL 3.0 or TLS. Five banks overlap, and are vulnerable to POODLE attacks with both protocol versions. Therefore, 30 out of 80 banks in our survey are vulnerable to POODLE attacks. Within the SSL/TLS protocol suite (up to versions 3.0/1.0, respectively), one method to encrypt data is with block ciphers used in Cipher-Block Chaining (CBC) mode. The SSL/TLS standard mandates that chained Initialization Vectors (IVs) are used with CBC mode encryption. With chained initialization vectors, the last block of the previous ciphertext is used as an IV for the next message. This presents a vulnerability that can be exploited using a Blockwise Chosen-Boundary Attack (BCBA) [\u2587\u2587\u2587\u2587\u2587 and \u2587\u2587\u2587\u2587\u2587 2011]*. A BCBA applied on a HTTPS session is known as a BEAST attack [National Institute of Standards and Technology 2011]*. BEAST can be mitigated by letting servers only allow connections exclusively using TLS 1.1 or 1.2. Figure 6 shows that between 2013 and 2015 the number of banks that are vulnerable to BEAST attacks has increased. An explanation for this is that banks that became vulnerable at one point in time stopped supporting RC4, the only streaming cipher supported by SSL/TLS, since it is vulnerable to attacks [AlFardan et al. 2013]. The only alternative without disabling support for the older SSL 3.0 and TLS 1.0 protocol versions were cipher suites that applied CBC, and by implementing those the relevant banks became vulnerable to BEAST. This is likely seen as the preferable alternative, since the BEAST attack ACM Computing Surveys, Vol. 49, No. 4, Article 61, Publication date: December 2016. A Survey of Authentication and Communications Security in Online Banking 61:23 \u2212 can be mitigated by browsers by implementing 1/n 1 record splitting as a workaround [\u2587\u2587\u2587\u2587\u2587\u2587\u2587 2012; \u2587\u2587\u2587\u2587\u2587\u2587 2013]*. If an attacker can observe network traffic and manipulate a victim\u2019s browser to sub- mit requests to a target site, it is possible to retrieve data from the TLS stream when DEFLATE compression is used. An attacker can steal session cookies with CRIME, which makes it possible to hijack a session [Ristic 2012]*. While this attack is easier to execute compared to BEAST, it is also easier to defend against by disabling TLS com- pression. This can be done server- or client-side. The vulnerability is only exploitable when both server and client support and use TLS compression when a session is es- tablished. In 2013 only seven banks supported TLS compression, which after 2 years was reduced to four banks. SSL/TLS renegotiation makes it possible to use the same data session over multiple connections. Originally, the SSL and TLS protocols did not consider that different parties can use the same data session due to renegotiation, where one party has control of the connection before renegotiation, and the other afterwards. This allows a man- in-the-middle to inject plain text in an established session with a web server before the web server is reconnected with the user\u2019s browser through renegotiation [Ristic 2009]*. As a response, some sites disabled the renegotiation feature [Ristic 2010]*, while others implemented an extension which fixed the problem [Rescorla et al. 2010]*. Renegotiating is cryptographically protected when both the server and the browser support the extension, thereby preventing the same data session to be shared between an end-user and a man-in-the-middle. Half of the banks that were vulnerable in 2013 fixed the issue in the following 2 years. SSL/TLS supports a number of cipher suites with different key sizes to support the confidentiality and integrity of an established session. Some of these cipher suites are merely meant for testing and unlike regular cipher suites, they do not offer either authenticity of the server\u2019s identity (such as with anonymous (Elliptic curve) \u2587\u2587\u2587\u2587\u2587\u2587- \u2587\u2587\u2587\u2587\u2587\u2587\u2587) or encryption, due to the lack of required algorithms in the suite. To prevent this, insecure cipher suites should be disabled. Only two sites from our survey sup- ported insecure ciphers in 2013, which have since then fixed this issue. The SSL Server Test from Qualys designates all cipher suites that are less than 112 bits as \u201cweak.\u201d If the assumption is made that data has to stay confidential and its integrity safeguarded against eavesdroppers for the period \u201c2031 and Beyond,\u201d a minimum of 128 bits conforms with recommendations by NIST [\u2587\u2587\u2587\u2587\u2587\u2587 et al. 2012]*. This is why any applied cipher suite with a symmetrical key length of less than 128 bits is considered vulnerable. However, there are a large number of sites that deploy cipher suites of which the shortest key length is 112 bits. These sites are noted separately in Figure 6 to distinguish sites that slightly deviate from NIST recommendations (less than 128 bits but at least 112 bits) and those which deviate significantly (less than 112 bits, i.e., 40 or 56 bits). Not much has changed since 2013. The most significant change was a moderate reduction in banks that supported very weak ciphers (from 17 to 10 banks). These banks disabled the weaker cipher suites in their web server configurations, forcing clients to use the stronger alternatives. Support for SSL 2.0 (with cipher suites enabled) or SSL 3.0 is considered a vulner- ability. SSL 2.0 has a number of flaws that were already acknowledged by \u2587\u2587\u2587\u2587\u2587\u2587\u2587\u2587\u2587 et al. [2002]. These are the use of the same cryptographic keys for message authenti- cation and for encryption (which makes the security of Message Authentication Codes (MACs) unnecessarily weak when encryption key size is limited due to export restric- tions), the sole dependence on MD5 as a vulnerable hash function to construct MACs, the lack of handshake protection, and the possibility to truncate a connection due to relying on the closure of the TCP connection. SSL 3.0 is also considered insecure since all available cipher suites for that protocol version are vulnerable. Cipher suites using ACM Computing Surveys, Vol. 49, No. 4, Article 61, Publication date: December 2016.", "hash": "7210779b11fb9fd3a5d2cc1a8fa7c6d1", "id": 2}, {"samples": [{"hash": "mBXQyrZknL", "uri": "/contracts/mBXQyrZknL#vulnerabilities", "label": "Data Protection Agreement", "score": 33.0482978821, "published": true}, {"hash": "iZICSIyfibK", "uri": "/contracts/iZICSIyfibK#vulnerabilities", "label": "Data Protection Agreement", "score": 25.3860378265, "published": true}, {"hash": "aOfsMbuX9wl", "uri": "/contracts/aOfsMbuX9wl#vulnerabilities", "label": "Data Protection Agreement", "score": 24.6550312042, "published": true}], "size": 3, "snippet_links": [{"key": "provider-shall", "type": "clause", "offset": [0, 14]}, {"key": "in-place", "type": "clause", "offset": [29, 37]}, {"key": "security-vulnerabilities", "type": "definition", "offset": [54, 78]}, {"key": "notice-of", "type": "definition", "offset": [170, 179]}, {"key": "business-days-of", "type": "clause", "offset": [252, 268]}, {"key": "public-acknowledgement", "type": "clause", "offset": [273, 295]}, {"key": "ten-business", "type": "definition", "offset": [388, 400]}, {"key": "scoring-system", "type": "definition", "offset": [621, 635]}, {"key": "the-risk", "type": "clause", "offset": [669, 677]}, {"key": "as-agreed", "type": "clause", "offset": [681, 690]}, {"key": "use-of-open-source-code", "type": "clause", "offset": [718, 741]}], "snippet": "Provider shall have controls in place to identify any security vulnerabilities in the Solutions during development and after release. Provider shall provide Dell written notice of (a) publicly-acknowledged vulnerabilities/zero day exploits within five business days of the public acknowledgement; and (b) internally-known yet publicly-undisclosed vulnerabilities/zero day exploits within ten business days of their discovery. Provider commits to remediate all vulnerabilities identified in the Solutions at Provider\u2019s expense, and to remediate vulnerabilities with a base score above 4 as defined by Common Vulnerability Scoring System in a timeframe commensurate with the risk or as agreed upon with Dell. Provider\u2019s use of open source code shall not alter Provider\u2019s responsibility to identify and remediate vulnerabilities as described here.", "hash": "bfb4d10474398f830a3f9ac37555f6c2", "id": 4}, {"samples": [{"hash": "980sCCbmd22", "uri": "/contracts/980sCCbmd22#vulnerabilities", "label": "Data Processing Addendum", "score": 35.1543273926, "published": true}, {"hash": "7VMlVm4nTN4", "uri": "/contracts/7VMlVm4nTN4#vulnerabilities", "label": "Data Processing Addendum", "score": 27.0807666779, "published": true}], "size": 3, "snippet_links": [{"key": "provider-shall", "type": "clause", "offset": [0, 14]}, {"key": "in-place", "type": "clause", "offset": [29, 37]}, {"key": "security-vulnerabilities", "type": "definition", "offset": [54, 78]}, {"key": "notice-of", "type": "definition", "offset": [176, 185]}, {"key": "business-days-of", "type": "clause", "offset": [263, 279]}, {"key": "public-acknowledgement", "type": "clause", "offset": [284, 306]}, {"key": "scoring-system", "type": "definition", "offset": [637, 651]}, {"key": "the-risk", "type": "clause", "offset": [685, 693]}, {"key": "as-agreed", "type": "clause", "offset": [697, 706]}, {"key": "use-of-open-source-code", "type": "clause", "offset": [740, 763]}], "snippet": "Provider shall have controls in place to identify any security vulnerabilities in the Solutions during development and after release. Provider shall provide NetWitness written notice of: (a) publicly-acknowledged vulnerabilities/zero-day exploits within five (5) business days of the public acknowledgement, and (b) internally-known yet publicly-undisclosed vulnerabilities/zero-day exploits within ten (10) business days of their discovery. Provider commits to remediate all vulnerabilities identified in the Solutions at Provider\u2019s expense, and to remediate vulnerabilities with a base score above 4 as defined by Common Vulnerability Scoring System in a timeframe commensurate with the risk or as agreed upon with NetWitness. Provider\u2019s use of open source code shall not alter Provider\u2019s responsibility to identify and remediate vulnerabilities as described here.", "hash": "e173bb0415131f27411fd98cd9fa974a", "id": 5}, {"samples": [{"hash": "4J5jwEOR7l4", "uri": "/contracts/4J5jwEOR7l4#vulnerabilities", "label": "Acceptance and Acknowledgment of Terms", "score": 31.3664112091, "published": true}, {"hash": "3wNgZGRi42y", "uri": "/contracts/3wNgZGRi42y#vulnerabilities", "label": "Acceptance and Acknowledgment of Terms", "score": 31.2131175995, "published": true}], "size": 2, "snippet_links": [{"key": "services-for", "type": "clause", "offset": [45, 57]}, {"key": "critical-systems", "type": "definition", "offset": [58, 74]}, {"key": "sensitive-data", "type": "clause", "offset": [94, 108]}, {"key": "third-party", "type": "clause", "offset": [160, 171]}, {"key": "the-application", "type": "clause", "offset": [186, 201]}, {"key": "security-vulnerabilities", "type": "definition", "offset": [228, 252]}, {"key": "without-limitation", "type": "clause", "offset": [265, 283]}, {"key": "the-open", "type": "clause", "offset": [320, 328]}, {"key": "security-project", "type": "definition", "offset": [345, 361]}, {"key": "see-\u2587", "type": "clause", "offset": [363, 368]}], "snippet": "Provider must provide vulnerability scanning services for critical systems or systems hosting sensitive data. Provider must provide attestation by an objective third party, stating that the application has been tested for known security vulnerabilities, including, without limitation, the \"OWASP Top-10\" as published by the Open Web Application Security Project (see \u2587\u2587\u2587.\u2587\u2587\u2587\u2587\u2587.\u2587\u2587\u2587 for current list of the top 10).", "hash": "4e1bb026abaad9eb97b5cf0361738c6c", "id": 6}, {"samples": [{"hash": "5zx0WNY2lHt", "uri": "/contracts/5zx0WNY2lHt#vulnerabilities", "label": "Request for Proposals", "score": 32.2396316528, "published": true}, {"hash": "6UBnKm0jhpE", "uri": "/contracts/6UBnKm0jhpE#vulnerabilities", "label": "Request for Proposals", "score": 31.990530014, "published": true}], "size": 2, "snippet_links": [{"key": "your-products", "type": "definition", "offset": [65, 78]}, {"key": "data-breach", "type": "definition", "offset": [97, 108]}, {"key": "end-user", "type": "definition", "offset": [116, 124]}], "snippet": "Identify any known circumstances where a vulnerability in any of your products has resulted in a data breach for an end user.", "hash": "65b4fefe4132c53f770b464387806ea4", "id": 7}, {"samples": [{"hash": "kLLKm9sZFfZ", "uri": "/contracts/kLLKm9sZFfZ#vulnerabilities", "label": "Authenticated Key Agreement Scheme", "score": 21.2505130768, "published": true}, {"hash": "5yTSg6Llg4O", "uri": "/contracts/5yTSg6Llg4O#vulnerabilities", "label": "Authenticated Key Agreement Scheme", "score": 21.2477760315, "published": true}], "size": 2, "snippet_links": [{"key": "security-of-the", "type": "clause", "offset": [150, 165]}, {"key": "applies-to", "type": "clause", "offset": [198, 208]}], "snippet": "The vulnerabilities of the BYka scheme are broken down and analysed in the three main parts:\n(1) Strength of the keys against brute force attacks\n(2) Security of the underlying \u2587\u2587\u2587\u2587\u2019\u2587 scheme, as it applies to the BYka scheme\n(3) Resilience against node capture", "hash": "ca18c337574fd548c8a4398981a78339", "id": 8}, {"samples": [{"hash": "hYNStjT9Fzj", "uri": "/contracts/hYNStjT9Fzj#vulnerabilities", "label": "Contract (Flight International Group Inc)", "score": 18.0, "published": true}, {"hash": "5WVR7NLjR0c", "uri": "/contracts/5WVR7NLjR0c#vulnerabilities", "label": "Contract (Flight International Group Inc)", "score": 18.0, "published": true}], "size": 2, "snippet_links": [{"key": "processes-and-procedures", "type": "clause", "offset": [49, 73]}, {"key": "the-process", "type": "clause", "offset": [135, 146]}, {"key": "part-of-the-plan", "type": "clause", "offset": [292, 308]}, {"key": "based-on", "type": "definition", "offset": [340, 348]}, {"key": "changes-in", "type": "definition", "offset": [376, 386]}, {"key": "scope-of-the-program", "type": "clause", "offset": [391, 411]}, {"key": "the-primary", "type": "clause", "offset": [538, 549]}, {"key": "organization-and", "type": "clause", "offset": [584, 600]}, {"key": "other-data", "type": "clause", "offset": [700, 710]}, {"key": "to-determine", "type": "clause", "offset": [984, 996]}, {"key": "the-information", "type": "clause", "offset": [1060, 1075]}, {"key": "in-time", "type": "definition", "offset": [1076, 1083]}], "snippet": "(OPSEC vulnerabilities are normally found in the processes and procedures routinely used by organizations. This section should discuss the process by which vulnerabilities to critical information will be determined. This section will become more focused as the program/activity matures. This part of the plan will require periodic updating based on new threat information and changes in the scope of the program/activity. Determining vulnerabilities involves a systematic analysis of how an operation or activity is actually conducted by the primary and supporting organizations. The organization and activity must be viewed as an adversary might view it. Actions and things that can be observed, or other data that can be interpreted or pieced together to drive critical information, must be identified. These potential vulnerabilities must be matched with specific threats. Once you determine what an adversary needs to know and where that information is available, it is necessary to determine if it is possible that the adversary could acquire and exploit the information in time to capitalize on it. If so, a vulnerability exists.)", "hash": "d263bb375b896c165ff31869b3243819", "id": 9}, {"samples": [{"hash": "fKw6Uj6SpB3", "uri": "/contracts/fKw6Uj6SpB3#vulnerabilities", "label": "Master Services Agreement", "score": 26.6153316498, "published": true}], "size": 1, "snippet_links": [{"key": "section-4", "type": "definition", "offset": [34, 43]}, {"key": "this-agreement", "type": "clause", "offset": [47, 61]}, {"key": "a-non", "type": "clause", "offset": [88, 93]}, {"key": "fully-paid", "type": "clause", "offset": [119, 129]}, {"key": "in-perpetuity", "type": "definition", "offset": [172, 185]}, {"key": "business-purposes", "type": "definition", "offset": [195, 212]}, {"key": "derivative-works", "type": "clause", "offset": [261, 277]}, {"key": "based-on", "type": "definition", "offset": [278, 286]}, {"key": "to-third-parties", "type": "clause", "offset": [301, 317]}, {"key": "information-provided", "type": "clause", "offset": [331, 351]}, {"key": "by-customer", "type": "clause", "offset": [370, 381]}, {"key": "in-connection-with", "type": "clause", "offset": [474, 492]}, {"key": "the-services", "type": "definition", "offset": [493, 505]}, {"key": "customer-network", "type": "clause", "offset": [693, 709]}, {"key": "required-products", "type": "clause", "offset": [724, 741]}, {"key": "as-required-by", "type": "clause", "offset": [876, 890]}, {"key": "applicable-law", "type": "definition", "offset": [891, 905]}, {"key": "disclosure-of", "type": "clause", "offset": [992, 1005]}, {"key": "the-data", "type": "clause", "offset": [1006, 1014]}], "snippet": "Notwithstanding the provisions of Section 4 of this Agreement, Customer grants to Cysiv a non-exclusive, royalty-free, fully paid-up, sublicensable, transferrable license, in perpetuity, for all business purposes, to use, reproduce, distribute, display, create derivative works based on, and disclose to third parties all data and information provided or made available by Customer or its personnel, contractors, or representatives or otherwise learned or observed by Cysiv in connection with the Services regarding: (i) potential or actual Vulnerabilities; (ii) the detection, identification, blocking, removal, remediation, or resolution thereof; or (iii) all logs and data, coming from the Customer Network, whether from Required Products or Cysiv tools or agents deployed within the Customer Network, including any Cysiv connectors, Cysiv collectors, or otherwise. Except as required by Applicable Law, Cysiv may not, without Customer\u2019s approval, identify Customer in connection with its disclosure of the data and information licensed to Cysiv under this Section to third parties.", "hash": "c04720a485ee65b59dd7034e72f62a80", "id": 10}], "next_curs": "ClgSUmoVc35sYXdpbnNpZGVyY29udHJhY3RzcjQLEhZDbGF1c2VTbmlwcGV0R3JvdXBfdjU2Ihh2dWxuZXJhYmlsaXRpZXMjMDAwMDAwMGEMogECZW4YACAA", "clause": {"parents": [["confidentiality", "Confidentiality"], ["physical-access-controls", "Physical Access controls"], ["contingency-planning-policies", "Contingency Planning Policies"], ["solution-security", "Solution Security"], ["competent-supervisory-authority", "COMPETENT SUPERVISORY AUTHORITY"]], "size": 48, "title": "Vulnerabilities", "children": [["the-supplier-must", "The Supplier must"], ["audit-trail", "Audit Trail"], ["data-retention", "Data Retention"], ["recoverability", "Recoverability"]], "id": "vulnerabilities", "related": [["vulnerability-management", "Vulnerability Management", "Vulnerability Management"], ["infrastructure-vulnerability-scanning", "Infrastructure Vulnerability Scanning", "Infrastructure Vulnerability Scanning"], ["screening", "Screening", "Screening"], ["capabilities", "Capabilities", "Capabilities"], ["safeguarding-and-protecting-children-and-vulnerable-adults", "Safeguarding and Protecting Children and Vulnerable Adults", "Safeguarding and Protecting Children and Vulnerable Adults"]], "related_snippets": [], "updated": "2025-07-23T06:00:56+00:00"}, "json": true, "cursor": ""}}