EXTERNOS

Apresentar os requisitos de Segurança da Informação e Privacidade obrigatórios que deverão ser observados pela CONTRATADA, para desenvolver websites (sites) para anúncio, comercialização de produtos, serviços ou promoções, dentre outras necessidades que se façam necessárias, considerando o processamento, transmissão e/ou armazenamento de informações de clientes e colaboradores da CLARO.

2. APLICAÇÃO

Aplica-se à Claro S.A. e suas Controladas/Coligadas, bem como para todos aqueles que, mesmo não sendo colaboradores próprios, trabalhem dentro ou fora das instalações das Empresas ou ainda que tenham acesso às informações dos processos da Organização.

3. REFERÊNCIAS

Os seguintes documentos referenciados, no todo ou em parte, são normativas e padrões de mercado:

Para o desenvolvimento deste documento, foram considerados:

• ABNT NBR ISO/IEC 27001:2013: Tecnologia da Informação — Técnicas de Segurança — Sistemas de Gestão da Segurança da Informação;

• ABNT NBR ISO/IEC 27002:2013: Tecnologia da Informação — Técnicas de Segurança — Código de Prática para Controles de Segurança da Informação;

• ABNT NBR ISO/IEC 27005:2011: Tecnologia da Informação — Técnicas de Segurança — Gestão de Riscos de Segurança da Informação;

• ABNT NBR ISO/IEC 27011:2008: Técnicas de Segurança - Diretrizes para Gestão da Segurança da Informação para Organizações de Telecomunicações.

• ABNT NBR ISO/IEC 27701:2019: Tecnologia da Informação — Técnicas de Segurança — Extensão à ABNT NBR ISO/IEC 27002 para Gestão da Privacidade da Informação – Requisitos e Diretrizes;

• CÓDIGO DE ÉTICA, do Grupo América Móvil;

• CÓDIGO DE AUTORREGULAMENTAÇÃO PARA PRÁTICA DE E-MAIL MARKETING

(xxxx://xxx.xxxxx.xxx.xx);

• DECRETO Nº 8.771/2016 – Decreto que regulamenta o Marco Civil da Internet;

• LEI Nº 12.965/2014 – Marco Civil da Internet;

• LEI Nº 9.472/97: Lei Geral das Telecomunicações;

• LEI Nº 13.709/18 - Lei Geral de Proteção de Xxxxx Xxxxxxxx;

• LEI Nº 13.853/19 – Lei que altera a LGPD e cria a Autoridade Nacional de Proteção de Dados;

• Normas de Segurança da Claro.

• RESOLUÇÃO Nº 477, de 07.08.2007 – Aprova o Regulamento do Serviço Móvel Pessoal (SMP);

• XXXXXXXX.XX (xxxxx://xxxxxxxx.xx).

4. REQUISITOS DE SEGURANÇA PARA CONTRATAÇÃO DE SERVIÇOS DE TERCEIROS – Websites Externos 4.1.Organização de Segurança da Informação e Proteção de Dados Pessoais ‌

i. Para fins de organização da Segurança da Informação e da privacidade e proteção de dados pessoais, a CONTRATADA deve:

a) Possuir um modelo de gestão de Segurança da Informação e Privacidade, com o papel de elaborar, divulgar e atualizar as políticas e diretrizes de segurança e proteção de dados pessoais, que deverão ser apresentadas à Claro em caso de solicitação nesse sentido;

b) Designar um responsável pelo modelo de gestão de Segurança da Informação, que deverá atuar na gestão e no cumprimento das diretrizes e, se aplicável, um DPO, responsável pela estrutura e governança do programa de privacidade e proteção de dados pessoais;

c) Possuir uma política de Segurança da Informação (ou documento similar) revisada periodicamente e divulgada a todos os funcionários e terceiros, em que conste diretrizes de segurança e privacidade, contendo, no mínimo, os seguintes temas (não se limitando somente a estes):

• Classificação da Informação, inclusive de Dados Pessoais

• Mesa e tela limpa

• Segurança física

• Controle de acesso

• Senhas

• Manuseio da informação

• Licenciamento de software

• Backups

• Resposta a incidentes de segurança e de privacidade

• Acesso à internet

• Uso de correio eletrônico

• Procedimentos documentados

• Gestão de vulnerabilidades / patches

• Governança em privacidade

• Registro de tratamento de dados pessoais

d) Documentar e manter atualizados os processos e procedimentos internos relacionados à prestação do serviço e aos requisitos de Segurança da Informação e Privacidade (ISO 27701:2019);

e) Realizar durante a contratação e periodicamente treinamentos de conscientização para seus funcionários sobre os aspectos de Segurança da Informação e Privacidade exigidos neste documento;

f) Cumprir a legislação e regulamentações aplicáveis à prestação de serviço, particularmente a Lei Geral das Telecomunicações e a LGPD;

g) Designar responsáveis, custodiantes e usuários das informações de seus sistemas internos.

ii. Caso o serviço prestado envolva transações de cartões de pagamento, a CONTRATADA deverá estar em conformidade com o padrão PCI-DSS, evidenciando anualmente sua conformidade de acordo com as regras do PCI, bandeiras e adquirentes;

iii. Todas as informações de propriedade da Claro, bem como as de seus clientes devem ter sua utilização restrita à prestação do serviço contratado e devem ser tratadas como confidenciais, sendo assegurado o acesso dos profissionais às informações apenas na medida necessária à execução de suas tarefas.

4.2.Desenvolvimento

i. A CONTRATADA deve garantir as premissas básicas de segurança da informação (finalidade, necessidade, confidencialidade, integridade, disponibilidade e autenticidade) para todos os sistemas, sites e/ou aplicações próprias ou que serão desenvolvidas para cumprimento do objeto do contrato que manipulem dados ou informações da Claro, seguindo e implementando os controles estabelecidos abaixo:

4.2.1. Segurança para Sistemas Web

A) Autenticação

i. Requerer autenticação para todas as páginas e recursos, exceto para aqueles que são intencionalmente públicos;

ii. Utilizar apenas requisições POST para transmitir credenciais de autenticação;

iii. Desabilitar a funcionalidade de lembrar a senha (auto complete) nos campos de senha do navegador;

iv. Adicionar controle de Captcha (Completely Automated Public Turing test to tell Computers and Humans Apart) em páginas onde houver entradas de usuário/senhas para evitar possíveis ataques de força bruta com dicionários à autenticação;

v. Definição de complexidade mínima na criação de senhas, sendo elas:

• Tamanho mínimo de 8 caracteres;

• Senha não deve começar com caractere de espaço;

• Senha deve conter caractere minúsculo;

• Senha deve conter caractere maiúsculo;

• Senha deve conter caractere numeral;

• Senha deve conter caractere especial.

vi. Solicitar a troca periódica da senha conforme o tratamento da norma de gestão de acesso da Claro, há cada 150 dias, não podendo ser reutilizado senhas antigas.

B) Validação de Entradas

i. Validar todos os dados provenientes dos clientes antes do processamento, incluindo todos os parâmetros, campos de formulário, consentimentos, conteúdo das URLs e cabeçalhos HTTP, por exemplo: nomes e valores dos cookies. Certificar-se também de incluir automaticamente mecanismos de postback nos trechos de código JavaScript, Flash ou qualquer outro código incorporado;

ii. Verificar os valores de cabeçalho, tanto das requisições, como das respostas, que contém apenas caracteres ASCII;

iii. Validar dados provenientes de redirecionamentos para evitar que conteúdo malicioso seja incluído diretamente para o alvo do mecanismo de redirecionamento, podendo assim contornar a lógica do sistema e qualquer validação executada antes do redirecionamento;

iv. Usar apenas referências de arquivos internos ou em servidores controlados pela equipe de segurança em páginas que utilizarem JavaScript.

C) Gerenciamento de Sessão

i. Definir o domínio e o caminho para os cookies que contém identificadores de sessão autenticados para um valor devidamente restrito para o site;

ii. Disponibilizar a funcionalidade de logout em todas as páginas que requerem autenticação;

iii. Não expor os identificadores de sessão em URLs, mensagens de erro ou logs. Os identificadores de sessão devem apenas serem localizados no cabeçalho do cookie HTTP. Por exemplo, não trafegar os identificadores de sessão na forma de parâmetros GET;

iv. Gerar um novo identificador de sessão caso a segurança da conexão mude de HTTP para HTTPS, como pode ocorrer durante a autenticação. Internamente à aplicação, deve utilizar HTTPS de forma constante em vez de alternar entre HTTP para HTTPS;

v. Utilizar mecanismos complementares ao mecanismo de gerenciamento de sessão padrão para operações sensíveis do lado do servidor, como é o caso de operações de gerenciamento de contas, através da utilização de tokens aleatórios ou parâmetros associados à sessão. Este método deve ser usado para prevenção de ataques do tipo Cross Site Request Forgery;

vi. Utilizar mecanismos complementares ao gerenciamento de sessão para operações altamente sensíveis ou críticas utilizando tokens aleatórios ou parâmetros em cada requisição;

vii. Configurar o atributo "secure" para cookies transmitidos através de uma conexão TLS;

viii. Configurar os cookies com o atributo HttpOnly, a menos que seja explicitamente necessário ler ou definir os valores dos cookies através de scripts do lado cliente do sistema.

D) Controle de Acesso

i. Restringir o acesso às URLs protegidas somente aos usuários autorizados;

ii. Use o campo “referer” do cabeçalho somente como forma de verificação suplementar. Ele não deve ser usado sozinho como forma de checagem de autorização, pois o valor deste campo pode ser adulterado;

iii. Não disponibilizar Servlets que controlem através de parâmetros, credenciais de acesso e regras de navegação.

E) Proteção de Dados

i. Os controles de segurança de informações e TI devem ser aplicados adequadamente a todos os aspectos do desenvolvimento do(s) site(s) para garantir que os dados sejam protegidos adequadamente;

ii. O princípio geral deve ser o de que todos os dados são adequadamente protegidos do ponto de recepção, passando pelo armazenamento, transferência, processamento e até a eliminação segura dos dados. Assim, as atividades para proteção de dados devem envolver:

a) Remover comentários do código de produção que são acessíveis pelos usuários e podem revelar detalhes internos do sistema ou outras informações sensíveis;

b) Não incluir informações sensíveis nos parâmetros de requisição HTTP GET;

c) Desabilitar a funcionalidade de auto completar nos formulários que contenham informações sensíveis, inclusive no formulário de autenticação;

d) Desabilitar o cache realizado no lado cliente das páginas que contenham informações sensíveis. O parâmetro Cache-Control: no-store, pode ser usado em conjunto com o controle definido nos cabeçalhos HTTP “Pragma: no-cache”, que é menos efetivo, mas

é compatível com HTTP/1.0;

e) Implementar política de privilégio mínimo, restringindo os usuários apenas às funcionalidades, dados e informações do sistema que são necessárias para executar suas tarefas;

f) Dados confidenciais armazenados em banco de dados devem ser criptografados;

g) Proteger o código-fonte presente no servidor para que não seja acessado por algum usuário;

h) Contemplar um mecanismo de controle transacional no banco de dados (Commit/Rollback);

i) Implementar roteamento das conexões para o banco de dados sempre a partir da camada de aplicação. Nunca deve existir nenhum computador de usuário, desenvolvedor ou suporte conectado diretamente ao banco de dados em sistemas de produção;

j) Realizar o processo de desenvolvimento e homologação dos sistemas somente com bases de dados mascaradas e/ou dados fictícios, porém deve ser mantida a mesma estrutura das bases originais de produção e volume de dados suficientes para a execução dos testes, visando realizar simulações compatíveis à realidade do negócio;

k) Remover do aplicativo e/ou bases de dados as contas, IDs de usuário, senhas e dados de teste ou prova antes que ele se torne ativo ou seja instalado em produção;

l) Não armazenar senhas, strings de conexão ou outras informações confidenciais em texto claro ou em qualquer forma criptograficamente insegura no lado cliente. Aplicar também quando houver incorporação de formatos inseguros como: MS viewstate, Adobe Flash ou código compilado que roda no lado cliente;

m) Remover aplicações desnecessárias e documentação do sistema que possam revelar informações importantes para os atacantes;

n) O sistema deve dar suporte à remoção de dados sensíveis quando estes não forem mais necessários, como, por exemplo: informação pessoal ou determinados dados financeiros.

F) Segurança nas Comunicações

i. Filtrar os parâmetros que contenham informações sensíveis, provenientes do HTTP refere, quando realizar apontamentos para sites externos;

ii. Utilizar criptografia na transmissão de todas as informações sensíveis, incluindo TLS para proteger a conexão e sendo complementado por criptografia de arquivos que contém dados sensíveis ou conexões que não usam o protocolo HTTP. Os certificados TLS devem ser válidos, possuir o nome de domínio correto, não estarem expirados e serem instalados com certificados intermediários, quando necessário;

iii. Não retornar uma conexão insegura quando ocorre falha nas conexões TLS;

iv. Utilizar conexões TLS para todo conteúdo que requer acesso autenticado ou manutenção da confidencialidade das informações sensíveis;

v. Utilizar um padrão único de implementação TLS que é configurado de modo apropriado;

vi. Especificar a codificação dos caracteres para todas as conexões.

G) Configuração de Sistema

i. Desabilitar a listagem de diretórios;

ii. Restringir os privilégios do servidor web, dos processos e das contas de serviços para o mínimo

possível;

iii. Prevenir a divulgação da estrutura de diretórios impedindo que robôs de busca façam indexação de arquivos sensíveis, através da correta configuração do arquivo robots.txt, definindo diretórios que devem ser inacessíveis a estes indexadores em um diretório subjacente isolado. Assim, o acesso ao diretório pai definido no arquivo robots.txt deve estar desabilitado em vez de desabilitar cada diretório individualmente;

iv. Definir quais métodos HTTP, Get ou Post, a aplicação irá suportar e se serão tratados de modo diferenciado nas diversas páginas do sistema;

v. Desativar os métodos HTTP desnecessários, como extensões WebDAV. Caso seja necessário o uso de algum método HTTP estendido para suportar manipulação de arquivos, utilizar algum mecanismo de autenticação bem controlado;

vi. Certificar-se, se o servidor processar tantas requisições HTTP 1.0 e 1.1, de que ambos são configurados de modo semelhante ou assegurar que qualquer diferença que possa existir seja compreendida (ex. manuseio de métodos HTTP estendidos);

vii. Remover informações desnecessárias presentes nos cabeçalhos de resposta HTTP que podem estar relacionadas ao sistema operacional, versão do servidor web e frameworks de aplicação;

viii. Os servidores e recursos relacionados devem ser capazes de funcionar em redes IPv6.

H) Gerenciamento de Arquivos

i. Não salvar arquivos no mesmo diretório de contexto do sistema web. Os arquivos devem ser armazenados no servidor de conteúdo ou na base de dados;

ii. Prevenir ou restringir upload de qualquer arquivo que possa ser interpretado pelo servidor web;

iii. Não transmitir sem nenhum tratamento os dados informados pelo usuário a redirecionamentos dinâmicos. Se isto for permitido, então o redirecionamento deverá aceitar somente URLs relativas e validadas;

iv. Nunca enviar o caminho absoluto do arquivo para o cliente.

v. Administradores de sistema e banco de dados podem ter acesso privilegiado a dados confidenciais, porém este deve ser autorizado e monitorado;

vi. O acesso administrativo aos dados somente ocorrerá quando explicitamente autorizado e sempre será irreversivelmente registrado;

vii. Os dados devem ser armazenados e protegidos de acordo com sua classificação;

viii. As políticas de retenção de dados devem ser definidas, monitoradas e aplicadas.

4.2.2. Tratamento de Erros e Trilhas de Auditoria (Logs)

i. Todo o acesso deve ser auditável para identificar data, hora, atividade e pessoa responsável;

ii. Não expor informações sensíveis nas respostas de erros, inclusive detalhes de sistema, identificadores de sessão ou informação da conta do usuário;

iii. Usar mecanismos de tratamento de erros que não exibam informações de debug (depuração) ou informações da pilha de exceção;

iv. Retornar mensagens de erro genéricas ao cliente;

v. Tratar seus erros sem depender das configurações do servidor;

vi. Liberar a memória alocada de modo apropriado quando ocorrerem condições de erro;

vii. Tratar erros lógicos associados com controles de segurança por padrão “negar o acesso”;

viii. Implementar controles de log em um sistema confiável (neste caso o servidor);

ix. Incluir, adicionalmente, trilhas de auditoria em todos os sistemas para as funções de maior criticidade e relevância para o negócio. Estas funções deverão ser definidas pelas áreas responsáveis e o proprietário do sistema, quando necessário;

x. Não deverá existir nenhum processo ou função que altere ou apague qualquer registro da trilha de auditoria, salvo o script de retenção;

xi. O processo confidencial deve ser controlado por uma trilha de auditoria que forneça um registro completo e a responsabilidade individual pelo ciclo de vida dos ativos de informação para garantir que todos os ativos criados, processados e excluídos sejam totalmente contabilizados;

xii. O acesso a dados sensíveis é auditável para identificar data, hora, atividade e pessoa responsável;

o Indivíduos responsáveis são rastreáveis e podem ser responsabilizados.

xiii. A trilha de auditoria deve ser protegida em termos de integridade e o período de retenção deve ser definido. Não deve conter dados sensíveis;

xiv. Restringir o acesso e a leitura dos arquivos de logs aos usuários autorizados;

xv. Não registrar nos arquivos de log dados confidenciais utilizados na autenticação das credenciais de acesso (senhas, chaves privadas etc.) ou na autorização dos acessos (identificações ou senhas de sessão etc.);

xvi. Permitir, com o mecanismo de geração de trilhas de auditoria, a configuração de mecanismo de coleta de logs externo ou centralizado;

xvii. Armazenar os arquivos de log de forma segura e possuir restrição de acesso, principalmente nos casos de permissão de alteração e exclusão;

xviii. Registrar, pelo menos, os seguintes eventos, quando aplicáveis:

− acesso a dados sensíveis, ações de usuários administrativos;

− acesso às trilhas de auditoria;

− tentativas de acesso inválidas;

− utilização dos mecanismos de autenticação e identificação;

− inicialização do registro de auditoria;

− falhas de validação de dados de entrada;

− tentativas de conexão com tokens de sessão inválidos ou expirados;

− falhas de conexão TLS com o backend;

− falhas que ocorreram de criptografia.

xix. Prover, pelo menos, os seguintes registros para cada entrada no log:

− identificação do usuário, tipo de evento; data e hora;

− indicação de sucesso ou falha;

− origem do evento e identificação do dado, componente, recurso ou objeto relacionado.

xx. Garantir que as entradas de log que incluem dados não confiáveis não sejam executadas como um código na interface de visualização de logs;

xxi. Utilizar uma função de hash criptográfica para validar a integridade dos registros de log.

4.2.3. Tempo de Armazenamento

i. Os arquivos de logs de sistemas, recursos e redes que tramitem informações objetos do contrato firmado com a Claro devem ser armazenados de forma on-line pelo período mínimo de 5 (cinco) anos;

i. A CONTRATADA deve realizar as gravações das ligações de todas as operações realizadas para a Claro. As gravações devem ser armazenadas em locais seguros de acesso restrito por um período de, no mínimo, 5 (cinco) anos;

ii. Durante o cumprimento do contrato, o prazo de armazenamento poderá ser revisto pela própria Claro. A CONTRATADA deve estar ciente e preparada para se adequar em caso de alteração legislativa ou regulamentação pelas autoridades competentes, independentemente de prévia notificação da Claro de tal responsabilidade;

iii. A CONTRATADA deve definir um processo e um responsável para a disponibilização das gravações telefônicas à Claro. A Claro poderá solicitar a qualquer momento acesso a uma gravação e a CONTRATADA deve viabilizar sua entrega.

4.3.Identidade do Site

i. Todo o domínio utilizado para objeto de cumprimento do contrato deve ser registrado no Brasil (Xxxxxxxx.XX), por exemplo: “.xxx.xx”;

ii. A CONTRATADA deve usar o selo da Empresa em todas as suas peças de comunicação, de acordo com a orientação do Manual de Marca/Guia de Branding da área de Marketing, pois ele comprova que está autorizada, principalmente, a comercializar os planos e serviços.

4.4.Utilização de E-Mail ou E-Mail Marketing

i. Toda comunicação com o cliente da Claro utilizando correio eletrônico deve ser feita utilizando os domínios corporativos definidos pela Claro e criptografia. A Claro não autoriza comunicação através de domínios públicos (ex: Gmail etc.);

ii. Todo e-mail com endereço corporativo da Claro disponibilizado a CONTRATADA deve ser configurado de acordo com os padrões de identificação e segurança vigentes e homologados pela Claro.

iii. Para uso do e-mail marketing destinado a clientes, a CONTRATADA deverá observar que:

a) O envio do e-mail deverá conter a identificação do remetente, assunto e logotipo da CONTRATADA;

b) Na mensagem de e-mail, deverá ser inserido um termo de responsabilidade, que alerte sobre as boas práticas de segurança na prevenção contra falsos e-mails que visam fraudar o destinatário (phishing);

c) Somente poderão ser enviadas mensagens pelo endereço eletrônico vinculado ao seu domínio da CONTRATADA.

d) É vetada a prática do primeiro envio para se obter a permissão do destinatário para envios posteriores, que caracteriza a prática de SPAM;

e) Os clientes devem autorizar previamente o recebimento das mensagens (opt-in);

f) Para o envio de arquivos anexos, deverá ser obtida autorização prévia e comprovável do destinatário, específica para o tipo de arquivo em questão;

g) A veiculação deve ser apenas de conteúdo no HTML ou TXT sem qualquer recurso que possa ocultar, disfarçar ou obscurecer de qualquer maneira o código original da mensagem;

h) Deve ser verificado se o código HTML está de acordo com as recomendações do W3C utilizando, por exemplo, o validador disponível no site xxxx://xxxxxxxxx.x0.xxx/. Algumas

aplicações antispam incluem a validação do código em seus testes e podem até atribuir pontuação à mensagem, caso o código não seja válido;

i) Se o e-mail estiver em formato HTML, deve-se oferecer em local visível a possibilidade de visualizar o mesmo conteúdo em uma página da web, já que alguns softwares podem bloquear ou mesmo impedir a correta visualização. Componentes da mensagem, tais como imagens, hiperlinks, endereços eletrônicos, áudios e vídeos devem ser hospedados em servidores pertencentes à Empresa;

j) É vetada a utilização de link externo no corpo do e-mail;

k) É vedado o envio de arquivos com autoexecutáveis;

l) Deve-se limitar o tamanho das mensagens em 40MB (cabeçalho+texto+anexo) a fim de não sobrecarregar o sistema de envio nem a caixa de entrada do destinatário;

m) O conteúdo da mensagem deve ser genérico e ter como característica a impessoalidade, ou seja, não deve conter dados cadastrais de clientes da Empresa.

4.5.Proteção de Dados

i. As informações e dados de clientes, prospects etc. devem ser classificadas conforme critérios abaixo e criptografadas no armazenamento e transporte;

o CONFIDENCIAL: Informação de alto impacto deve ser protegida por:

a) sua relevância sobre decisões estratégicas, impacto financeiro, oportunidades de negócio, potencial de fraude ou requisitos legais;

b) seu impacto nos interesses do negócio, de seus clientes, fornecedores e colaboradores.

São informações que devem circular apenas entre os colaboradores definidos pelo executivo responsável pela geração da informação.

o CONFIDENCIAL LGPD: Informação de alto impacto com dados de pessoa natural, que deve ser protegida por:

a) sua relevância para fins de atendimento à Lei Geral de Proteção de Xxxxx Xxxxxxxx, podendo ser de cliente, colaborador próprio, terceiros ou prestadores de serviço;

b) seu impacto nos interesses do negócio, de seus clientes, fornecedores e colaboradores.

o USO INTERNO: Informação que, sem reserva ou restrição, deve ser mantida no âmbito interno da empresa e não deve ser divulgada ou ser disponível externamente. O acordo de confidencialidade deve estar previsto no contrato da contratada e deve ser assinado entre a contratada e seus recursos.

o PÚBLICA: Informação cuja divulgação não afeta à empresa em termos de perda de imagem e/ou econômica/financeira

ii. As operações de criptografia e decriptografia dos dados devem ser realizadas apenas em servidores seguros em ambiente seguro;

iii. As chaves de criptografia devem ser individuais e somente o dono da chave deve ter acesso a ela. O fornecedor deve possuir uma chave de criptografia exclusiva para troca de arquivos de produção e, caso o fornecedor possua mais de uma sede, as chaves de criptografia devem ser diferentes;

iv. A proteção, bem como o termo de consentimento de uso de dados pessoais e dados pessoais sensíveis devem estar de acordo com à LGPD.

4.6.Testes de Segurança

i. A CONTRATADA deve permitir que a área de Segurança da Informação da Claro (ou terceiro por ela designado) realize os testes de segurança necessários quando solicitado em sistemas, sites, aplicações etc. (objetos do contrato);

ii. O resultado do teste será enviado a CONTRATADA que deverá retornar um plano de ação no prazo de 30 (trinta) dias informando os prazos para correção das vulnerabilidades identificadas.

4.7.Gestão de Vulnerabilidade

i. A CONTRATADA deve manter um banco de dados ou ferramenta de inventário atualizada sobre ativos tecnológicos, sistemas operacionais e softwares base instalados na CONTRATADA, que inclua as informações de fabricantes, versões, níveis de atualização de patches e, no caso de software base, o sistema operacional em que este se encontra instalado;

ii. Implementar as correções de segurança (patches), conforme disponibilizadas pelos respectivos fabricantes dos softwares que suportam as operações;

iii. A CONTRATADA deve entregar para a Gerência de Segurança da Informação Corporativa da Claro, a cada 3 (três) meses, um relatório com plano de tratamento das vulnerabilidades identificadas. O resultado do trabalho não pode conter vulnerabilidades críticas;

iv. A CONTRATADA deve definir um procedimento para calcular o risco de cada vulnerabilidade identificado, considerando critérios de classificação da informação, probabilidade de exploração da vulnerabilidade e o impacto relacionado.

4.8.Segurança nas Aplicações/Aplicativos Móveis

v. Qualquer sistema desenvolvido para plataformas móveis, como Android, iPhone, iPad, Symbian etc., deve obrigatoriamente cumprir com os requisitos abaixo com o objetivo de evitar a exploração de vulnerabilidades comuns em aplicativos destas plataformas, que possuem características únicas em relação a sistemas desktops e aplicações web;

vi. Os requisitos abaixo são complementares aos citados anteriormente e devem ser aplicados conforme a plataforma da aplicação.

A) Configuração de Sistema

a) Os valores exclusivos de identificação do dispositivo (Device ID) não devem ser usados como controle de segurança;

b) O aplicativo deve ser assinado com um certificado digital válido;

c) O aplicativo não deve armazenar chaves secretas ou senhas no seu código executável;

d) O aplicativo deve desabilitar recursos de fotografia de tela como “print screen” ou “auto snapshot”, para impedir que informações sensíveis possam ser divulgadas por esta funcionalidade;

e) O aplicativo não deve ser executado em um dispositivo com alterações em seu sistema operacional. Tradicionalmente estas técnicas são conhecidas como “Root Device” no caso de sistemas Android e “Jailbreaking” no caso de sistemas iOS;

f) As permissões e os arquivos requisitados pelo aplicativo para o seu correto funcionamento devem seguir o princípio de privilégio mínimo;

g) Os logs do aplicativo não devem armazenar dados sensíveis no dispositivo;

h) Os arquivos binários do aplicativo devem ser ofuscados para evitar ataques que utilizem técnicas de engenharia reversa do código;

i) Todos os dados de teste devem ser removidos do container do aplicativo (arquivos

.apk, .ipa e .bar, entre outros formatos);

j) O aplicativo deve validar seus arquivos de configuração para avaliar se não foram alterados para inserir variáveis inseguras, como flags de depuração, permissões de leitura etc.);

k) O aplicativo deve utilizar as mínimas permissões necessárias para seu funcionamento para garantir a privacidade dos usuários e a usabilidade do sistema;

l) O aplicativo não deve criar arquivos com permissões globais no sistema de arquivos do dispositivo, como MODE_WORLD_READABLE ou MODE_WORLD_WRITABLE. Deve-se usar o princípio de privilégio mínimo para evitar que permissões excessivas concedidas a um aplicativo possam comprometer a segurança do dispositivo móvel;

m) O aplicativo deve manter em memória as credenciais de acesso (usuário e senha) o mínimo de tempo possível, apenas o suficiente para completar o processo de validação;

n) O aplicativo deve descartar e limpar toda a memória associada com os dados do usuário e todas as chaves mestras usadas para decifrar dados sensíveis;

o) O suporte ao JavaScript e aos Plugins devem estar desabilitados para quaisquer WebViews;

p) O sistema de acesso a arquivos deve estar desativado para quaisquer WebViews, como, por exemplo, “webview.getSettings ()” e “setAllowFileAccess (false)”, impedindo que aplicações web possam acessar conteúdo local do aplicativo;

q) Todos os serviços devem filtrar completamente e validar as entradas vindas do aplicativo. Ao lidar com consultas dinâmicas ou “ContentProviders”, deve-se garantir que estão sendo utilizadas consultas parametrizadas;

r) Deve-se restringir o uso do modo de depuração dos aplicativos evitando a fácil manipulação em tempo de execução por um atacante ou malware. Normalmente isto é possível com o uso da flag “debuggable = set false” em sistemas Android, por exemplo;

s) Deve-se invocar diretamente o aplicativo recebedor das chamadas e mensagens de sistemas, evitando o uso de recursos como a propagação (broadcast) de intents em sistemas Android ou App Extensions em sistemas iPhone;

t) O aplicativo deve implementar uma configuração padrão para o usuário o mais segura possível (buscando um equilibro entre segurança e usabilidade);

u) O aplicativo deve informar ao usuário sobre os possíveis riscos quando se mudam os parâmetros de segurança na configuração. Nestes casos, a opção padrão selecionada deve ser a mais restritiva do ponto de vista da segurança;

v) O aplicativo deve ser atualizado automaticamente nos dispositivos quando for necessário.

B) Gerenciamento de Sessão

a) O ID de sessão deve cumprir os seguintes requisitos:

• Deve ser alterado e diferente para cada login e autenticação válida do usuário;

• Deve ser removido após o processo de “LogOut” (desvinculação de dispositivos).

b) O aplicativo deve possuir a funcionalidade de bloqueio de tela por tempo de inatividade (timeout).

• Essa funcionalidade de bloqueio deve ser implementada com um código numérico PIN (com um mínimo de 4 dígitos) ou com um padrão de desenho na tela para assegurar que o aplicativo não seja utilizado de forma indevida devido à inatividade do dispositivo;

• A aplicação deve permitir configurar o tempo de expiração e o código ou padrão utilizado.

c) Dados web trafegados pelo aplicativo, como tráfego via HTTPS, não devem ser armazenados, mesmo em arquivos de cache.

C) Proteção de Dados

a) O aplicativo deve validar os certificados de criptografia utilizados durante a transferência de dados;

b) O aplicativo deve utilizar SSL para todas as conexões que:

• Transmitam credenciais de autenticação ou tokens de sessão do usuário;

• Enviem ou recebam dados sensíveis ou acessem operações sensíveis;

• Estejam relacionadas com a administração da aplicação.

c) Não devem ser enviados dados sensíveis através de canais alternativos, tais como SMS, MMS ou notificações;

d) O aplicativo não dever armazenar dados sensíveis em recursos compartilhados do dispositivo, como por exemplo, diretórios compartilhados ou o cartão SD. Para sistemas Android o armazenamento local de informações no dispositivo deve utilizar a criptografia de arquivos locais usando "setStorageEncryption";

e) O aplicativo não deve armazenar dados sensíveis nos bancos de dados locais do dispositivo. Se algum dado necessitar de armazenamento, este deverá usar técnicas de proteção (como truncamento, por exemplo), inclusive se dados sensíveis forem armazenados com o uso de técnicas de criptografia, como o iOSKeychain ou em bases SQLite em sistemas Android;

f) O aplicativo não deve oferecer a possibilidade de autocompletar para dados sensíveis, como senhas, informações pessoais ou de cartão de crédito;

g) O aplicativo não deve permitir a exportação de atividades sensíveis executadas pelo aplicativo;

h) Aplicativos que trafegarem dados sensíveis devem usar técnicas de Certificate Pinning (Fixação de Certificado, em tradução livre) para impedir a interceptação do tráfego do aplicativo.

4.9.Incidentes de Segurança e Privacidade

i. A estrutura de gerenciamento de Segurança da Informação da CONTRATADA deve manter e controlar a segurança por meio de uma equipe multifuncional que coordena a identificação, o agrupamento e a resolução de problemas de segurança, independentemente da estrutura do negócio;

ii. Deve ser mantido um mecanismo de resposta a incidentes, de segurança e privacidade, que inclua um processo para a investigação e mitigação de:

a) Violação acidental ou deliberada de regulamentos e procedimentos internos;

b) Suspeita ou detecção de comprometimento de sistemas ou recebimento de notificação de vulnerabilidades do sistema;

c) Invasão física ou lógica dos ativos ou informações;

d) Ataques de negação de serviço em componentes.

iii. No caso de incidente, a CONTRATADA deve:

a) Notificar imediatamente a Claro, através do e-mail xxxxx@xxxxx.xxx.xx, sobre a ocorrência de incidentes, irregularidades ou eventos suspeitos que afetem ou possam afetar a segurança das informações de propriedade da Claro;

b) Notificar imediatamente o responsável da Claro pela contratação;

c) Acionar o mecanismo de resposta a incidentes, a fim de mitigar os riscos

d) Garantir que os logs para análise ou perícia estejam disponíveis quando solicitados pela Claro.

4.10. Gestão de Continuidade de Negócios

i. A CONTRATADA deve assegurar a disponibilidade de seus ambientes, conforme contratado, considerando o tipo de atividade a ser exercida, sendo:

a) Caberá a CONTRATADA fornecer, quando solicitado pela Claro (a qualquer momento), as informações referentes à infraestrutura que suporta as atividades, bem como o mapeamento das localidades e o número de estações de atendimento e/ou operação disponíveis em cada uma das localidades onde estas são prestadas;

b) Caberá a Claro fornecer uma avaliação quanto aos negócios elegíveis e prioridade de recuperação das atividades.

ii. A CONTRATADA deve informar à Xxxxx xxxx e qualquer alteração de infraestrutura e/ou recursos em seu ambiente de trabalho e nos ambientes de contingência que atuarem ou fizerem qualquer referência ao objeto ora contratado para o perfeito cumprimento desta cláusula;

iii. A CONTRATADA deverá implementar o Sistema de Gestão de Continuidade Negócio:

• Plano de Gestão de Crise (exemplo: crise hídrica e elétrica);

• Plano de Gestão de Incidente;

• Plano de Recuperação de Desastre;

• Plano de Contingência Operacional;

• Plano de Teste e Validação; e

• Plano de Comunicação.

iv. Deverá ser definido e documentado entre o gestor do contrato da Claro e a CONTRATADA o prazo e/ou tempo máximo e mínimo para recuperação dos dados e/ou serviços em caso de desastres;

v. Será necessário definir procedimentos e ações para a transferência das atividades essenciais do negócio para localidades alternativas até a resolução e avaliação do incidente;

vi. Os ativos críticos para a continuidade dos processos de negócios essenciais devem ser objeto de proteção redobrada e hospedados em local que permita o seu uso nos procedimentos de emergência mesmo em casos de desastres;

vii. Deve ser incluída capacitação e orientação de todos os envolvidos nos planos de continuidade de processos, estando aptos a desenvolver suas atribuições;

viii. Deverão ser realizados testes periodicamente dos planos e elementos de contingência, com coletas de evidências;

ix. A CONTRATADA deve garantir os backups das informações em consonância com as disposições legais, realizar periodicamente testes de restauração, bem como possuir infraestrutura de contingência: geradores, nobreak, redundância de servidores de hospedagem da página web, redundância de links, redundância de equipamentos críticos para operação, refrigeração, reservatórios de água, site alternativo, etc.;

x. Os recursos humanos da CONTRATADA, envolvidos nos Planos de Continuidade de Xxxxxxx (PCN), deverão ser treinados no tema, conforme as suas atribuições e responsabilidades nos planos;

xi. Devem ser identificadas as soluções táticas para suportar a restauração das atividades exigidas dentro de um tempo de recuperação desejado. Em cada caso, devem ser avaliadas as alternativas a

fim de minimizar a probabilidade de um mesmo incidente afetar a solução de continuidade do negócio;

xii. Todo e qualquer incidente que comprometa a continuidade dos serviços deve ser comunicado de imediato ao gestor do contrato responsável, para as providências necessárias e, se necessário, acionar os respectivos planos de continuidade;

xiii. Devem ser desenvolvidos e implantados procedimentos para resposta e estabilização da situação após um incidente, utilizando-se dos planos de respostas específicos para cada tipo de cenário avaliado após a realização da análise de risco.

4.11. Diligências de Conformidade

i. A CONTRATADA obriga-se a manter, durante toda a execução do contrato, em compatibilidade com as obrigações por ela assumidas, todas as condições abaixo exigidas:

a) A CONTRATADA deverá responder aos reportes e envio de evidências solicitadas pela Gerência de Segurança da Informação Corporativa da Claro, contendo autoavaliação (self- assessment) dos requisitos de segurança determinados em contrato;

b) Ambientes físicos e lógicos de recebimento, tratamento e manipulação de dados/informações objetos do contrato poderão passar por vistorias de segurança periódicas designadas pela Gerência de Segurança da Informação Corporativa da Claro;

c) Permitir que colaboradores da Claro, a qualquer tempo, possam proceder à verificação na CONTRATADA de conformidade dos controles incluídos no contrato, bem como permitir a análise e verificação de seus procedimentos de atendimento e habilitação dos serviços;

d) As não conformidades identificadas devem ser corrigidas e um Plano de Ação deverá ser enviado à Claro com prazo para regularização. Vulnerabilidades classificadas como ALTA, conforme metodologia própria de análise de riscos da Claro não poderão ser corrigidas num prazo superior a 30 (trinta) dias.

4.12. Descarte

i. As informações obtidas nos termos do contrato firmado com a Claro que forem armazenadas, processadas, transmitidas e tratadas devem ser destruídas ou devolvidas após término de contrato com a CONTRATADA ou quando solicitado por parte da Claro;

ii. As mídias digitais, tanto as fixas como as removíveis, que contenham dados e informações da Claro, quando não forem mais utilizadas, requerem os seguintes cuidados no descarte:

a) Identificar e registrar as mídias que requerem descarte seguro, tais como fitas de backup, discos rígidos, DVDs, impressos e outros;

b) Triturar, incinerar ou inutilizar as mídias para que os dados não possam ser recuperados;

c) Os serviços terceirizados de coleta e descarte de papel, de equipamentos e de mídias magnéticas, deve ser efetuado por fornecedor com experiência e controles de segurança adequados.

5. ENCERRAMENTO DO CONTRATO DE SERVIÇOS

i. A substituição ou mesmo o encerramento dos serviços contratados pode ocorrer a qualquer momento. Para isto, alguns itens de segurança devem ser atendidos:

a) Notificação de rescisão e/ou elaboração de termo de distrato e quitação, caso encerramento amigável;

b) Garantia da revogação dos acessos;

c) Destruição dos dados armazenados, demonstrados pela CONTRATADA, quando solicitado;

d) Entrega de todas as gravações telefônicas e logs armazenados pela CONTRATADA;

e) Revisão dos planos de continuidades de negócio que envolvam a CONTRATADA;

f) Prazo para que sejam feitas as devidas regularizações, devendo estar previsto em contrato;

g) Atualização de normas e processos que envolvam a CONTRATADA.

ii. A área da Segurança da Informação Corporativa ou, na impossibilidade desta, um terceiro contratado, poderá realizar diligência para verificar se as cláusulas do contrato estão sendo atendidas, principalmente aqueles referentes à destruição das informações e revogação dos acessos.

Document Metadata

Table of Contents

EXTERNOS

Document Metadata