Original PDF at http://www.doc.gov.za/images/DraftDirISP_v4_o1.pdf
DRAFT DIRECTIVE FOR VALUE ADDED NETWORK (VAN) LICENSE HOLDERS PROVIDING INTERNET SERVICES
The Minister of Communications hereby-
(a) in terms of section 30(7)(a) of the Regulation of Interception of Communications And Provision of Communication-Related Information Act, 2002 (Act No. 70 of 2002), read with section 30(2) of the said Act, issue the directive in the Schedule in respect of value-added network (VAN) license holders providing internet services, hereafter referred to as internet service providers (ISPs); and
(b) in terms of section 30(7)(b) of the Regulation of Interception of Communications And Provision of Communication-Related Information Act, 2002 (Act No. 70 of 2002), determine a period of six months for compliance by internet service providers with the said directive.
SCHEDULE DIRECTIVE FOR INTERNET SERVICE PROVIDERS IN TERMS OF SECTION 30(7)(A) READ WITH SECTION 30(2) OF THE REGULATION OF INTERCEPTION OF COMMUNICATIONS AND PROVISION OF COMMUNICATION-RELATED INFORMATION ACT, 2002 (ACT NO. 70 OF 2002)
ARRANGEMENT OF CONTENT
PART 1: INTRODUCTORY PROVISIONS
1. Definitions
2. Application
3. Statement of general duties
PART 2: INTERCEPTION OF INDIRECT COMMUNICATIONS
4. General requirements in respect of interception
5. Unchanged state
of service
6. Security requirements for interception
7. Technical and
functional requirements
in respect of interception
PART 3: ROUTING, PROVISION AND STORING OF REAL-TIME COMMUNICATION-RELATED INFORMATION
8. General requirements in
respect of real-time
communication-related information
9. Recording and content of real-time
communication-related information
10. Security requirements in respect
of real-time communication-related
information
11. Technical and functional requirements in respect of real-time
communication-related information
PART 4: ROUTING, PROVISION AND STORING OF ARCHIVED COMMUNICATION-RELATED INFORMATION
12. General requirements in respect of archived communication-related
information
13. Content of archived communication-related information
14. Security
requirements in respect of archived communication-related information
15. Technical and functional
requirements in respect of archived communication-related information
PART 5: STORAGE PERIOD FOR COMMUNICATION-RELATED INFORMATION
16. Period for which communication-related information must be stored
17. Facilities
and Devices
18. Security Requirements
19. Functional Requirements
20.
Technical Requirements
PART 1: INTRODUCTORY PROVISIONS
In this directive, unless the context otherwise indicates, a word or expression to which a meaning has been assigned in the Act has the meaning so assigned, and:
"Act" means the Regulation of Interception of Communications and Provision of Communication-Related Information Act, 2002 (Act No. 70 of 2002);
“buffer” means the temporary storing of communication-related information in case the necessary telecommunication connection to route information to the IC is temporarily unavailable, and “buffered” has a similar meaning;
“direction” means a written or oral interception direction, real-time communication-related direction or archived communication-related direction, as the case may be;
“handover interface” means a pre-defined physical or logical interface across which the results of a direction or request are delivered between the ISP and the IC;
“identity” means a technical label which may represent the origin or destination of any communications traffic, as a rule clearly identified by a physical telecommunications identity number (such as a caller line identity number) or the logical communications identity number (such as an Internet Protocol address and/or Internet Protocol port number);
“Interception Centre” means an interception centre established in terms of section 32 of the Act and is herein referred to as the “IC”;
“interception measure” means a technical measure which facilitates the interception of communications traffic pursuant to the Act;
“interception target” means the customer whose indirect communications are to be intercepted, or whose real-time communication-related information or archived communication-related information is to be routed by an ISP to the IC or provided to a LEA, pursuant to a direction or request;
“internet service provider” means an internet service provider as defined in the Act and is herein referred to as an “ISP”;
"IPSec" means IP Secure, an industry-standard security protocol utilising modern data cryptographic techniques for the establishment of a secure tunnel;
“quality of service” means the quality specification of a communications channel, system, virtual channel, computer communications session, etc. “quality of service” may be measured in the case of an ISP, for example, in terms of latency or packet loss;
“result of interception” means the content of an indirect communication which is routed by an ISP to the IC pursuant to an interception directive or request;
“request” means a request in terms of section 7 of the Act;
“secure tunnel” means an encrypted and authenticated IP communication channel established using the most recently published versions of the IP Secure (IPSec), Transport Layer Security (TLS), or Secure Socket Layer (SSL) protocols;
“target identity” means the identity associated with an interception subject;
“target service” means a communications service utilised by an interception target and usually specified in a direction or request; for example, this refers to web (HTTP), e-mail (SMTP, POP and/or IMAP); chat (IRC), news (NNTP), web-mail (Hotmail, Yahoo etc.) and others.
“client” means the ISP customer whose indirect communications are to be intercepted, or whose real-time communication-related information or archived communication-related information is to be routed by the ISP to the IC, pursuant to a direction or request (synonymous to “interception target” or “interception subject”).
This directive applies to and is binding on all ISPs irrespective whether they have been issued with a licence under Chapter 5 of the Telecommunications Act, 1996 (Act No. 103 of 1996), or not.
3. Statement Of General Duties
3.1 An ISP must:
(a) provide a telecommunications service which has the capability to be intercepted;
(b) store communication-related information, in accordance with the provisions of the Act and this directive.
3.2 When a direction or request is presented to an ISP that ISP shall comply with the provisions of that direction or request.
PART 2: INTERCEPTION OF INDIRECT COMMUNICATIONS
4. General requirements in respect of interception
4.1 An ISP must:
(a) provide a telecommunications
service in
respect of which the packets of all indirect communications can be duplicated
and routed to the IC;
(b) apply software and/or hardware equipment on
its telecommunication system to duplicate and route to the IC all indirect
communications; and
(c)
ensure that the applied software and/or hardware equipment is capable
of identifying the targeted communication on the basis of:
4.2 In accordance with a direction or requestan ISP shall ensure that:
(a) the entire content of an indirect communication associated with a target identity can be intercepted during the period specified within the direction or request; and
(b) checksum information on the results of interception is recorded.
4.3 The ability to intercept telecommunications shall be provided by an ISP in respect of all interception targets utilizing its telecommunications system and in respect of all target services.
4.4 In so far as is technically feasible, the results of interception relating to an interception target shall be provided by the ISP in such a way that any indirect communication that does not fall within the scope of the direction or request shall be excluded by the ISP.
4.5 All results of an interception of an indirect communication provided at the handover interface shall be given a unique identification relating to the direction or request.
4.6 After a direction or a request has been presented, interception of the indirect communications shall proceed in accordance with that direction or request.
4.7 The ISP shall, in relation to each interception target duplicate and route the packets of each successful establishment of an indirect communication.
4.8 The provisions of paragraph 4.7 apply to multi-party or multi-way communications (eg. multicast), if and as long as the target identity participates in the multi-party or multi-way communications.
5.1 Interception shall be implemented and operated in such manner that no unauthorized person can detect any change from the unintercepted state.
5.2 Interception shall be implemented and operated in such manner that no telecommunicating parties can detect any change from the unintercepted state.
5.3 The operation of the target service shall not be altered as a result of any interception measure and the operation of any other service shall not be altered as a result of any interception measure.
5.4 The quality of service for the target’s service shall not be altered or degraded as a result of any interception measure. The quality of service of any telecommunications service other than the target‘s service shall not be altered or degraded as a result of any interception measure.
6. Security requirements for interception
6.1 Information on the manner in which interception measures are implemented in a given telecommunication installation shall not be made available to unauthorized persons.
6.2 Information relating to target identities and target services to which interception is being applied shall not
be made available to
unauthorized persons.
6.3 The ISP shall agree confidentiality on the manner in which interception
measures are implemented in a given telecommunications installation with
the manufacturers
of his technical installations for the implementation of interception
measures.
6.4 The technical arrangements required within a telecommunication system to allow implementation of the interception measures shall be realized with due care exercised in operating telecommunication installations, particularly with respect to:
(a) the need to protect information on which and how many target identities are or were subject to interception and the periods during which the interception measures were active;
(b) the restriction to a minimum, the number of staff engaged in implementation and operation of the interception measure;
(c) to ensure the clear delimitation of functions and responsibilities and the maintenance of third-party telecommunications privacy, interception provisioning is to be carried out in operating rooms accessible only by authorized personnel;
(d) the results of interception shall be delivered through a handover interface to the IC;
(e) no access of any form to the handover interface shall be granted to unauthorized persons;
(f) ISPs shall take all necessary measures to protect the handover interface against misuse;
(g) the results of interception shall only be routed to the IC as indicated in the direction or request when proof of the authority to receive, was received from the IC, and proof of the authority to send to the handover interface, has been furnished;
(h) authentication and proof of authentication shall be implemented subject to national laws and regulations;
(i) where switched lines to the IC are used, proof of authentication shall be furnished for each call set-up;
(j) in certain interception cases applicants may require, at the cost of the IC, the use of encryption or other confidentiality measures to protect the routing of the results of such interception;
(k) ISPs shall ensure that their handover interfaces support the use of encryption, authentication, integrity checking or other confidentiality measures and shall co-operate with applicants or the IC, or a person authorized by them, to implement such measures if required;
(l) in order to prevent or trace misuse of the technical functions integrated in the telecommunication installation enabling interception, any activation or application of these functions in relation to a given identity shall be fully recorded, including any activation or application caused by faulty or unauthorized input, and the records shall cover:(i) the target identities of the target service or target services concerned;
(ii) the beginning and end of the activation or application of the interception measure;
(iii) the IC to which the result of interception is routed;
(iv) an authenticator suitable to identify the operating staff (including date and time of input);
(v) a reference to the direction or request.
6.5 The ISPs shall take reasonable steps to ensure that the records referred to in paragraph 6.4(l) are secure and only accessible to specific nominated staff within their organizations.
7. Technical and functional requirements in respect of interception
7.1 The technical handover interfaces shall provide the results of interception for the entire duration of the interception measure dictated within the direction or request.
7.2 The configuration of the handover interface shall ensure that it provides the results of interception.
7.3 The configuration of the handover interface shall ensure that the quality of service of the telecommunications traffic provided at the handover interface is not inferior to that offered to the target service for that particular service.
7.4 The configuration of the handover interface shall be such that the routing to the IC of the result of interception provided at the interface can be implemented with industry standard transmission paths, protocols and coding principles.
7.5 Each interception target shall be uniquely associated with a single instance of the handover interface. (This could be achieved by the use of separate channels or unique interception identifiers).
7.6 The correlation between the indirect communication and communication-related information shall be unique.
7.7 The format for routing the intercepted indirect communications to the ICshall be an industry standard format.
7.8 ISPs must be able to route the intercepted indirect communications to the IC via a secure tunnel over circuit or packet switched connections.
7.9 The content of an indirect communication routed to the IC must include both incoming and outgoing content.
7.10 The IC will be informed of:
(a) the activation of an intercept measure;
(b) the deactivation of the intercept measure;
(d) the temporary unavailability of the intercept measure due to link failure or faults on the ISP’s side of the link; and
(e) the temporary unavailability of the intercept measure due to software and/or hardware failure within ISP equipment supporting the intercept measure.
7.11 An ISP shall ensure that the configuration of the telecommunication system is such that it can implement and operate each interception measurewith no or the minimum involvement of third parties.
7.12 Where an ISP makes use of any other telecommunication service provider’s telecommunication system, both that ISP and that other telecommunication service provider must co-operate in the provision of interception, if required.
7.13 An ISP must ensure that:
(a) any telecommunication service provider involved in the provision of interception facilities is given no more information relating to operational activities than is strictly necessary to allow authorized target services to be intercepted;
(b) any telecommunication service provider involved in the co-operative provision of interception facilities is given no more information relating to operational activities than is strictly necessary to allow authorized target services to be intercepted.
7.14 When duplication and routing to the IC of the packets of an indirect communication is, in exceptional cases, not possible the remainder of the results of the interception shall nevertheless be duplicated and routed to the IC.
7.15 Where the special properties of a given telecommunication service, and the justified requirements of the applicant, necessitate the use of various identifying characteristics for determination of the telecommunications traffic to be intercepted, the ISP shall ensure that the telecommunications traffic can be intercepted on the basis of the following characteristics:
(a) address information (physical and/or postal address);
(b) subscriber name (in certain instances the subscriber is billed for the service and he/she may not necessarily use the service);
(c) user name;
(d) e-mail address; and
(e) IP address and time stamp (time stamp indicating when the IP address was assigned).
7.16 In each case the characteristics shall be identifiable without unreasonable effort and shall be such that they allow clear identification of the interception target.
7.1.7 The ISP shall ensure that more than one interception measure can be operated concurrently for one and the same interception target and service. Multiple interceptions may be required for a single interception target to allow monitoring by more than one applicant.
7.18 If multiple interceptions are active, an ISP shall take reasonable precautions to safeguard the identities of the LEAs and ensure the confidentiality of the investigations.
7.19 The multiple interception measures, requested by different LEAs, may require information according to different lawful directions or requests.
7.20 Each ISP must ensure that the indirect communications of multiple customers can be intercepted simultaneously at any given time in its telecommunications system, and all the results of interception routed to the IC.
7.21 The arrangements made in a telecommunication system for the technical implementation of interception measures shall be set up and configured so as to enable the identification and elimination, without undue delay, of bottlenecks and potential bottlenecks in a regional or functional part of that system when several interception measures are operated concurrently.
PART 3: ROUTING, PROVISION AND STORING OF REAL-TIME COMMUNICATION-RELATED INFORMATION
8. General requirements in respect of real-time communication-related information
8.1 An ISP must provide a telecommunication service in respect of which all real-time communication-related information can be securely stored, retrieved and duplicated for:
(a) routing to the IC; or
(b) provision to a LEA.
8.2 Real-time communication-related information, related to an interception direction, must be immediately stored in the records of the ISP for a period of at least 90 days.
8.3 Real-time communication-related information, related to an interception direction, must be immediately retrievable from the records of the ISP within the 90-day time period.
8.6 An ISP must ensure that real-time communication-related information can immediately, on receipt of a direction, be:
(a) duplicated and routed to the IC; or
(b) provided to the LEA.
8.7 Real-time communication-related information must be stored in a format that allows for the extraction of the relevant requested information only, in a readable, intelligible and understandable format, and in accordance with the direction.
8.8 The ISP must ensure that real-time communication-related information is not accidentally or deliberately deleted from its records within the 90-day time period.
8.9 After a direction has been presented, the routing or provision of the real-time communication-related information shall proceed in accordance with that direction.
8.10 When real-time communication-related information cannot immediately be routed to the IC, it shall be buffered until it can be routed or it shall be provided by other means to the IC.
9. Recording and content of real-time communication-related information
9.1 When:
(a) both a real-time communication-related direction as well as an interception direction or request, in respect of the same target identity, are received; or
(b) only a real-time communication-related direction, that requires information as it becomes available, is received,
(c) an ISP shall be able to route or provide the real-time communication-related information in accordance with the direction concerned:(i) when an intercept target establishes a connection to the ISP;
(ii) for the duration the intercept target is connected to the ISPs network and
(iii) in accordance with an instruction contained in a direction or request.
9.2 An ISP must be able to provide the following real-time communication-related information for its subscribers:
(a) In respect of Network Access Systems (access logs specific to authentication and authorization servers used to control access to IP routers and/or network access servers):
(i) date and time of connection of client;
(ii) user name;
(iii) assigned IP address;
(iv) number of bytes transmitted and received;
(v) caller line identification in respect of dial-in users (in the case where caller ID is activated);
(vi) duration of session and
(vii) NIS IP address (if available).
9.3 An ISP must be able to provide the following real-time communication-related information for servers wholly owned and administered by the ISP:
(a) In respect of E-mail servers (SMTP, POP and/or IMAP logs):
(i) date and time of connection of client;
(ii) IP address of sending computer;
(iii) ID message (msgid);
(iv) sender (e-mail address);
(v) receiver (e-mail address);
(vi) status indicator;
(vii) user name and
(viii) duration of session (only for IMAP sessions).(b) In respect of File upload and download servers (File Transfer Protocol, FTP log):
(i) date and time of connection of client;
(ii) user name;
(iii) IP source and destination addresses;
(iv) path and file name of data object uploaded or downloaded; and
(v) duration of session.(c) In respect of Web servers (Hyper Text Transfer Protocol, HTTP log):
(i) date and time of connection of client;
(ii) IP source and destination addresses;
(iii) operation (i.e. POST or GET command);
(iv) path of the operation (eg. retrieval of html or image file);
(v) HTTP referrer header and
(vi) response codes.(d) In respect of Usenet (Network News Transfer Protocol, NNTP log):
(i) date and time of connection of client;
(ii) hostname (DNS name of assigned dynamic IP address, if available);
(iii) basic client activity (no content);
(iv) posted message identification;
(v) duration of session;
(vi) IP source address;
(vii) IP address and name of destination NNTP server and
(viii) message ID of requested articles or content.(e) In respect of Internet Relay Chat (IRC log):
(i) date and time of connection of client;
(ii) duration of session for each chatroom or channel;
(iii) nickname used during session and any changes to nickname during session;
(iv) hostname, if available;
(v) IP source address;
(vi) chatroom or channel name to which user joins/participates in and
(vii) any Identification information if provided by user.(f) Information available in the records of the ISP on any other protocol, not mentioned thus far, used in sending, downloading, uploading or accessing any communication:
(i) time and date of request;
(ii) IP address and/or hostname of user accessing the service and
(iii) a brief transaction record, if available.
10. Security requirements in respect of real-time communication-related information
10.1 Information on the manner in which storage measures in respect of real-time communication-related information are implemented by an ISP shall not be made available to unauthorized persons.
10.2 Real-time communication-related information shall not be made available to unauthorized persons.
10.3 The ISP shall agree confidentiality on the manner in which storage measures in respect of real-time communication-related information are implemented with the manufacturers of his technical installations for the implementation of storage measures.
10.4 The technical arrangements required within an ISP, to allow implementation of the storage measures in respect of real-time communication-related information, shall be realized with due care exercised in operating telecommunication installations, particularly with respect to:
(a) the need to protect information on which and how many target identities are or were subject to a real-time communication-related direction and the periods in respect of which the directions were applicable;
(b) the restriction to a minimum of staff engaged in implementation and operation of storing measures in respect of real-time communication-related information;
(c) to ensure the clear delimitation of functions and responsibilities and the maintenance of third-party telecommunications privacy, storing facilities in respect of real-time communication-related information shall be accessible only by authorized personnel;
(d) real-time communication-related information shall be delivered through a handover interface to the IC or provided to a LEA;
(e) no access of any form to the handover interface shall be granted to unauthorized persons;
(f) an ISP shall take all necessary measures to protect the handover interface against misuse;
(g) real-time communication-related information shall only be routed to the IC as indicated in the direction when proof of the authority to receive of the IC, and proof of the authority to send of the interface, has been furnished;
(h) authentication and proof of authentication shall be implemented subject to national laws and regulations;
(i) where switched lines to the IC are used, such proof shall be furnished for each routing of information.
(j) in certain interception cases applicants may require, at the cost of the IC, the use of encryption or other confidentiality measures to protect the routing of real-time communication-related information;
(k) ISPs shall ensure that their handover interfaces support the use of encryption, authentication, integrity checking or other confidentiality measures and shall co-operate with applicants or the IC, or a person authorized by them, to implement such measures if required;
(l) in order to prevent or trace misuse of the technical functions integrated in the telecommunication installation enabling the storing, routing and provision of real-time communication-related information, any activation or application of these functions in relation to a given identity shall be fully recorded, including any activation or application caused by faulty or unauthorized input, and the records shall cover all or some of:(i) the target identities of the target service or target services concerned;
(ii) the beginning and end of the activation or application of the real-time communication-related direction;
(iii) the IC to which the real-time communication-related information is routed or LEA to which it is provided;
(iv) an authenticator suitable to identify the operating staff (including date and time of input);
(v) a reference to the direction.
10.5 The ISP shall take reasonable steps to ensure that the records referred to in paragraph 10.4(l) are secure and only accessible to specific nominated staff within their organizations.
10.6 The ISP shall ensure the integrity of real-time communication-related information when it is recorded and stored.
10.7 An ISP shall ensure the physical, environmental and logical security of all stored real-time communication-related information.
10.8 An ISP shall employ measures to ensure the availability of real-time communication-related information.
11. Technical and functional requirements in respect of real-time communication-related information
11.1 The technical handover interfaces shall provide all the relevant requested real-time communication-related information only, in a readable, intelligible and understandable format, and in accordance with the direction.
11.2 The configuration of the handover interface shall be such that the routing to the IC of the requested real-time communication-related information provided at the interface can be implemented with industry standard transmission paths, protocols and coding principles.
11.3 Each instance of requested real-time communication-related information shall be uniquely associated with a single instance of the handover interface. This could be achieved by separate channels or the use of unique identifiers.
11.4 The format for routing the requested real-time communication-related information to the IC must be an industry standard format.
11.5 ISPs must be able to route the requested real-time communication-related information to the IC via a secure tunnel over fixed or switched connections.
11.6 The IC will be informed of:
(a) any change of the storage system, measures and functionality; and
(b) the temporary unavailability of stored real-time communication-related information.
11.7 An ISP shall ensure that the configuration of the storage system is such that it can store, maintain, extract, process, transmit or provide real-time communication-related information with no or the minimum involvement of third parties.
11.8 Where an ISP makes use of any telecommunication service provider’s telecommunication system or storage provider’s service, that ISP and other telecommunication service provider or storage provider must co-operate in the storing, routing or provision of real-time communication-related information, if required.
11.9 An ISP must ensure that:
(a) any telecommunication service provider or storage provider involved in the storing, provision or routing of real-time communication-related information is given no more information relating to operational activities than is strictly necessary to store, provide or route real-time communication-related information;
(b) any telecommunication service provider or storage provider involved in the co-operative storing, provision or routing of real-time communication-related information is given no more information relating to operational activities than is strictly necessary to allow the storing, provision or routing of real-time communication-related information.
11.10 When the provision or routing of all the requested real-time communication-related information is, in exceptional cases, not possible the remainder of the real-time communication-related information shall nevertheless be provided to the LEA or routed to the IC.
11.11 Storage devices or media shall be clearly indexed or the information contained identified to ensure the retrieval of only requested real-time communication information without unreasonable effort or delay.
11.12 An ISP shall ensure that more than one direction for real-time communication-related information can be operated concurrently for one and the same storage device or media.
11.13 If one or more directions for real-time communication-related information are processed, ISPs shall take precautions to safeguard the identities of the LEAs and ensure the confidentiality of the investigations and information.
PART 4: ROUTING, PROVISION AND STORING OF ARCHIVED COMMUNICATION-RELATED INFORMATION
12. General requirements in respect of archived communication-related information
12.1 An ISP must provide a telecommunication service in respect of which all archived communication-related information can be securely stored, retrieved and duplicated for-
(a) routing to the IC; or
(b) provision to a LEA.
12.2 Archived communication-related information pertaining to Network Access Systems only (access logs specific to authentication and authorization servers used to control access through the ISP network) must be available in the storage facility of the ISP for a period stipulated in Part 5 of this directive.
12.3 Archived communication-related information, referred to in paragraph 12.2 must be retrievable from the storage facility of the ISP within the five (5) year period.
12.4 An ISP must ensure that archived communication-related information can within the period specified in the direction, be-
(a) duplicated and routed to the IC; or
(b) provided to a LEA.
12.5 Archived communication-related information must be stored in a format that allows for the extraction of the relevant requested information only, in a readable, intelligible and understandable format, and in accordance with the direction.
12.6 When communication-related information is transferred to an archived storage facility, the ISP must ensure that:
(a) all the communication-related information that is required for archived communication-related information storage under this directive is transferred i.e. there is no lost data;
(b) the information is not transferred into archived storage before the expiry of 90 days from the date on which the indirect communication to which the real-time communication-related information relates, is recorded; and
(c) the integrity of the information is not compromised.
12.7 After a direction has been presented, the routing or provision of the archived communication-related information shall proceed in accordance with that direction.
13. Content of archived communication-related information
13.1 ISPs must be able to provide the following archived communication-related information for a period stipulated in Part 5 of this directive:
(a) In respect of Network Access Systems (access logs specific to authentication and authorization servers used to control access through the ISP network):
(i) date and time of connection of client;
(ii) user name;
(iii) assigned IP address;
(iv) number of bytes transmitted and received;
(viii) caller line identification in respect of dial-in users (in the case where caller ID is activated);
(ix) duration of session and (x) NIS IP address (if available).(b) In respect of E-mail servers (SMTP, POP and/or IMAP logs):
(i) date and time of connection of client;
(ii) IP address of sending computer;
(ix) ID message (msgid);
(x) sender (e-mail address);
(xi) receiver (e-mail address);
(xii) status indicator; and
(xiii) user name (if available).
14. Security requirements in respect of archived communication-related information
14.1 Information on the manner in which storage measures in respect of archived communication-related information are implemented by an ISP shall not be made available to unauthorized persons.
14.2 Archived communication-related information shall not be made available to unauthorized persons.
14.3 The ISP shall agree confidentiality on the manner in which storage measures in respect of archived communication-related information are implemented with the manufacturers of his technical installations for the implementation of storage measures.
14.4 The technical arrangements required within an ISP, to allow implementation of the storage measures in respect of archived communication-related information, shall be realized with due care exercised in operating telecommunication installations, particularly with respect to:
(a) the need to protect information on which and how many target identities are or were subject to a archived communication-related direction and the periods in respect of which the directions were applicable;
(b) the restriction to a minimum of staff engaged in implementation and operation of storing measures in respect of archived communication-related information;
(c) to ensure the clear delimitation of functions and responsibilities and the maintenance of third-party telecommunications privacy, storing facilities in respect of archived communication-related information shall be accessible only by authorized personnel;
(d) archived communication-related information shall be delivered through a handover interface to the IC or provided to a LEA;
(e) no access of any form to the handover interface shall be granted to unauthorized persons;
(f) an ISP shall take all necessary measures to protect the handover interface against misuse;
(g) archived communication-related information shall only be routed to the IC as indicated in the direction when proof of the authority to receive of the IC, and proof of the authority to send of the interface, has been furnished;
(h) authentication and proof of authentication shall be implemented subject to national laws and regulations;
(i) where switched lines to the IC are used, such proof shall be furnished for each routing of information.
(j) in certain interception cases applicants may require, at the cost of the IC, the use of encryption or other confidentiality measures to protect the routing of archived communication-related information;
(k) ISPs shall ensure that their handover interfaces support the use of encryption, authentication, integrity checking or other confidentiality measures and shall co-operate with applicants or the IC, or a person authorized by them, to implement such measures if required;
(l) in order to prevent or trace misuse of the technical functions integrated in the telecommunication installation enabling the storing, routing and provision of archived communication-related information, any activation or application of these functions in relation to a given identity shall be fully recorded, including any activation or application caused by faulty or unauthorized input, and the records shall cover all or some of:(i) the target identities of the target service or target services concerned;
(ii) the beginning and end of the activation or application of the archived communication-related direction;
(iii) the IC to which the archived communication-related information is routed or LEA to which it is provided;
(iv) an authenticator suitable to identify the operating staff (including date and time of input);
(v) a reference to the direction.
14.5 The ISPs shall take reasonable steps to ensure that the records referred to in paragraph 14.4(l) are secure and only accessible to specific nominated staff.
14.6 The ISP shall ensure the integrity of archived communication-related information when it is stored, during transfer thereof to any storage device or media and for the entire storage period set out in paragraph 17.
14.7 An ISP shall ensure the physical, environmental and logical security of all stored archived communication-related information.
14.8 An ISP shall
employ measures to ensure
the availability of archived communication-related information.
15. Technical and functional requirements in respect of archived communication-related
information
15.1 The technical handover interfaces shall provide all the relevant requested archived communication-related information only, in a readable, intelligible and understandable format, and in accordance with the direction.
15.2 The configuration of the handover interface shall be such that the routing to the IC of the requested archived communication-related information provided at the interface can be implemented with industry standard transmission paths, protocols and coding principles.
15.3 Each instance of requested archived communication-related information shall be uniquely associated with a single instance of the handover interface. This could be achieved by separate channels or the use of identifiers.
15.4 The format for routing the requested archived communication-related information to the IC must be an industry standard format.
15.5 ISPs must be able to route the requested archived communication-related information to the IC via a secure tunnel over fixed or switched connections.
15.6 The IC will be informed of:
(a) any change of the storage system, measures and functionality; and
(b) the temporary unavailability of stored archived communication-related information.
15.7 An ISP shall ensure that the configuration of the storage system is such that it can store, maintain, extract, process, transmit or provide archived communication-related information with no or the minimum involvement of third parties.
15.8 Where an ISP makes use of any telecommunication service provider’s telecommunication system or storage provider’s service, that ISP and other telecommunication service provider or storage provider must co-operate in the storing, routing or provision of archived communication-related information, if required.
15.9 An ISP must ensure that:
(a) any telecommunication service provider or storage provider involved in the storing, provision or routing of archived communication-related information is given no more information relating to operational activities than is strictly necessary to store, provide or route archived communication-related information;
(b) any telecommunication service provider or storage provider involved in the co-operative storing, provision or routing of archived communication-related information is given no more information relating to operational activities than is strictly necessary to allow the storing, provision or routing of archived communication-related information.
15.10 When the provision or routing of all the requested archived communication-related information is, in exceptional cases, not possible the remainder of the archived communication-related information shall nevertheless be provided to the LEA or routed to the IC.
15.11 Storage devices or media shall be clearly indexed or the information contained identified to ensure the retrieval of only requested archived communication-related information without unreasonable effort or delay.
15.12 The ISP shall ensure that more than one direction for archived communication-related information can be operated concurrently for one and the same storage device or media.
15.13 If one or more directions for archived communication-related information are processed, ISPs shall take precautions to safeguard the identities of the LEAs and ensure the confidentiality of the investigations and information.
PART 5: STORAGE PERIOD FOR COMMUNICATION-RELATED INFORMATION
16. Period for which communication-related information must be stored
Communication-related information, whether real-time or archived communication-related information, must be stored for a cumulative period of three (3) years from the date on which the indirect communication to which the communication-related information relates, is recorded.
PART 6: DETAILED SECUIRTY, FUNCTIONAL AND TECHNICAL REQUIREMENTS OF THE FACILITIES AND DEVICES FOR LAWFUL INTERCEPTION
ISPs are expected to abide by the following in terms of the functionality and security of the facilities and devices implemented to make their networks compliant to lawful interception (LI) requirements.
17.1 The ISP is expected to install and maintain LI interception software, probes and any associated tapping devices. The interception devices must be positioned in the ISP network to ensure that:
17.2 The ISP is expected to implement and manage one or more interception provisioning terminal for lawful interception (LI) compliance purposes. These terminals must be sufficiently closely located on the network to the probes or devices being managed by them so as to ensure that the delay in provisioning an interception based on RADIUS login information is minimised.
17.3 Where necessary, the ISP must implement mediation device(s) for the collection from these probes and devices, normalisation and delivery to an interception centre (IC) of intercept related information (IRI) tickets in the format specified within the technical requirement section of this document.
18.1 Interception provisioning terminals must be housed in an area with access controls implemented to limit access by authorised staff only.
18.2 Logical access control must be implemented on the provisioning terminals; at minimum, a password that is changed monthly is required.
18.3 The provisioning terminal must be configured to provide detailed logs of both successful and failed access attempts to the terminal.
18.4 The provisioning terminal and mediation device must be secured through means of a network firewall. The rule set on the firewall must explicitly deny all externally originated communication sessions unless it is from the interception centre (IC).
18.5 An anti-virus solution must be implemented for the provisioning terminals. The anti-virus definition files must be updated on at least a weekly basis from the vendor of the anti-virus software.
18.6 The communication
link between the mediation device and the IC for the delivery of intercept
related
information (i.e. HI2) and intercepted content (i.e. HI3) must be encrypted
using an IPSEC based link encryption software or device working in ESP
mode. The encryption
algorithm to be used is either 168-bit EDE mode Triple DES or 192-bit
CBC mode AES.
19. Functional Requirements
19.1 The following minimum functions must be implemented within the ISP for LI purposes; the processes used to support these functions must be well documented and auditable at all times:
20.1 Intercept related call content must be transmitted from the ISP mediation device to the interception centre through a shared or dedicated IP connection over the Internet. The hardware, software and bandwidth costs incurred to support this connectivity from the mediation device will be borne by the ISP.
20.2 As far as is possible, the ISP must adopt specifications relevant to its network from the following documents; any deviations and option choices from specifications provided in these documents must be communicated to and agreed upon by the IC prior to implementation:
| ETSI Technical Specification | Title | Description |
| TS 102 232 | Telecommunications security; Lawful Interception (LI); Handover Specification for IP Telephony |
Technical interface for mediation and handing over of intercepted IP telephony traffic to an IC |
| TS 102 233 | Telecommunications security; Lawful Interception (LI); Handover Specification for Email Delivery |
Technical interface for the mediation and handing over of intercepted e-mails to an IC |
| TS 102 234 | Telecommunications security; Lawful Interception (LI); Service Specification Details for Internet Access Services |
Specification of LI requirements for ISPs providing an Internet Access service directly to end-users |
Original PDF at http://www.doc.gov.za/images/DraftDirISP_v4_o1.pdf