Common use of Controle de Aplicações Clause in Contracts

Controle de Aplicações. 3.1. A solução deverá possuir a capacidade de reconhecer aplicações, independente de porta e protocolo, com as seguintes funcionalidades: 3.1.1. Deverá permitir a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos. 3.1.2. Deverá permitir a inspeção do payload do pacote de dados com o objetivo de detectar através de expressões regulares assinaturas de aplicações conhecidas pelo fabricante independente de porta e protocolo. A checagem de assinaturas também deverá determinar se uma aplicação está utilizando a porta default ou não, incluindo, mas não limitado a RDP na porta 80 ao invés de 389; 3.1.3. Deverá aplicar heurística a fim de detectar aplicações através de análise comportamental do tráfego observado, incluindo, mas não limitado a Encrypted Bittorrent e aplicações VOIP que utilizam criptografia proprietária; 3.1.4. Deverá identificar o uso de táticas evasivas, ou seja, deverá ter a capacidade de visualizar e controlar as aplicações e os ataques que utilizam táticas evasivas via comunicações criptografadas; 3.1.5. Para tráfego criptografado SSL, deverá decriptografar pacotes a fim de possibilitar a leitura de payload para checagem de assinaturas de aplicações conhecidas pelo fabricante; 3.1.6. Deverá permitir decodificação de protocolos com o objetivo de detectar aplicações encapsuladas dentro do protocolo e validar se o tráfego corresponde com a especificação do protocolo. A decodificação de protocolo também deverá identificar funcionalidades específicas dentro de uma aplicação, além de detectar arquivos e outros conteúdos que deverão ser inspecionados de acordo as regras de segurança implementadas; 3.1.7. Deverá permitir identificar o uso de táticas evasivas via comunicações criptografadas; 3.1.8. Deverá atualizar a base de assinaturas de aplicações automaticamente; 3.1.9. Deverá reconhecer aplicações em IPv6; 3.1.10. Deverá permitir limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem; 3.1.11. Deverá permitir adicionar controle de aplicações em todas as regras de segurança do dispositivo, ou seja, não se limitando somente a possibilidade de habilitar controle de aplicações em algumas regras; 3.1.12. Deverá permitir múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas, decodificação de protocolos e análise heurística; 3.1.13. Deverá permitir o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas; 3.1.14. Deverá permitir nativamente a criação de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da solução, sem a necessidade de ação do fabricante, mantendo a confidencialidade das aplicações do órgão; 3.1.15. A criação de assinaturas personalizadas deve permitir o uso de expressões regulares, contexto (sessões ou transações), usando posição no payload dos pacotes TCP e UDP e usando decoders de pelo menos os seguintes protocolos: HTTP, FTP, SMB, SMTP, Telnet, SSH, MS-SQL, IMAP, IMAP, MS-RPC, RTSP e File body. 3.1.16. O fabricante deverá permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações; 3.1.17. Deverá permitir alertar o usuário quando uma aplicação for bloqueada; 3.1.18. Deverá permitir que o controle de portas seja aplicado para todas as aplicações; 3.1.19. Deverá permitir criar filtro na tabela de regras de segurança para exibir somente: 3.1.19.1. Regras que permitem passagem de tráfego baseado na porta e não por aplicação, exibindo quais aplicações estão trafegando nas mesmas, o volume em bytes trafegado por cada a aplicação por, pelo menos, os últimos 30 dias e o primeiro e último registro de log de cada aplicação trafegada por esta determinada regra; 3.1.19.2. Aplicações permitidas em regras de forma desnecessária, pois não há tráfego da mesma na determinada regra; 3.1.19.3. Regras de segurança onde não houve passagem de tráfego nos últimos 90 dias; 3.1.19.4. Deverá possibilitar a diferenciação de aplicações Proxies (ghostsurf, freegate, etc.) possuindo granularidade de controle/políticas para os mesmos; 3.1.20. Deverá permitir a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: 3.1.20.1. Tecnologia utilizada na aplicação (Client-Server, Browser Based, Network Protocol, etc). 3.1.20.2. Nível de risco da aplicação. 3.1.20.3. Categoria e subcategoria de aplicações. 3.1.20.4. Aplicações que usem técnicas evasivas, utilizadas por malwares, como transferência de arquivos e/ou uso excessivo de banda, etc.

Controle de Aplicações. 3.1. A solução deverá possuir a capacidade Deverá contar com ferramentas de reconhecer visibilidade que permitam administrar o tráfego de aplicações, independente permitindo a execução de porta e protocolo, com as seguintes funcionalidades: 3.1.1. Deverá permitir a liberação aplicações autorizadas e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolosnão autorizadas. 3.1.23.2. Deverá permitir a inspeção do payload do pacote de dados com o objetivo de detectar através de expressões regulares assinaturas de aplicações conhecidas pelo fabricante independente de porta e protocolo. A checagem de assinaturas também deverá determinar se uma aplicação está utilizando a porta default ou não, incluindo, mas não limitado a RDP na porta 80 ao invés de 389; 3.1.3. Deverá aplicar heurística a fim de detectar aplicações através de análise comportamental do tráfego observado, incluindo, mas não limitado a Encrypted Bittorrent e aplicações VOIP que utilizam criptografia proprietária; 3.1.4. Deverá identificar o uso de táticas evasivas, ou seja, deverá ter a capacidade de visualizar e controlar as aplicações e os ataques que utilizam táticas evasivas via comunicações criptografadas; 3.1.5. Para tráfego criptografado SSL, deverá decriptografar pacotes a fim de possibilitar a leitura de payload para checagem de assinaturas de aplicações conhecidas pelo fabricante; 3.1.6. Deverá permitir decodificação de protocolos com o objetivo de detectar aplicações encapsuladas dentro do protocolo e validar se o tráfego corresponde com a especificação do protocolo. A decodificação de protocolo também deverá identificar funcionalidades específicas dentro de uma aplicação, além de detectar arquivos e outros conteúdos que deverão ser inspecionados de acordo as regras de segurança implementadas; 3.1.7. Deverá permitir identificar o uso de táticas evasivas via comunicações criptografadas; 3.1.8. Deverá atualizar a base de assinaturas de aplicações automaticamente; 3.1.9. Deverá reconhecer aplicações em IPv6; 3.1.10. Deverá permitir limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem; 3.1.11. Deverá permitir adicionar O controle de aplicações em todas deve identificar as regras mesmas independente das portas e protocolos assim como técnicas de segurança do dispositivoevasão utilizadas. 3.3. Descrever técnicas utilizadas pela solução para a detecção das aplicações (Assinaturas, ou sejaHeurística, não se limitando somente a possibilidade de habilitar controle de aplicações em algumas regras;etc). 3.1.123.4. Deverá permitir suportar múltiplos métodos de identificação e classificação das aplicações. 3.5. O controle de aplicações é baseado em Inspeção IPS ou inspeção profunda de pacotes (Deep Packet Inspection). 3.6. Para manter a segurança da rede eficiente, por pelo menos checagem de assinaturas, decodificação de protocolos e análise heurística; 3.1.13. Deverá permitir deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;. 3.1.143.7. Deverá permitir nativamente suportar a criação de aplicações customizadas pela interface gráfica do produto. 3.8. Deverá incluir a capacidade de atualização para identificar novas aplicações. 3.9. Deverá atualizar a base de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da solução, sem a necessidade de ação do fabricante, mantendo a confidencialidade das aplicações do órgão; 3.1.15. A criação de assinaturas personalizadas deve permitir o uso de expressões regulares, contexto (sessões ou transações), usando posição no payload dos pacotes TCP e UDP e usando decoders de pelo menos os seguintes protocolos: HTTP, FTP, SMB, SMTP, Telnet, SSH, MS-SQL, IMAP, IMAP, MS-RPC, RTSP e File bodyautomaticamente. 3.1.163.10. O fabricante deverá deve permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações;do fabricante. 3.1.173.11. Deverá permitir alertar o usuário quando uma aplicação for foi bloqueada;. 3.1.183.12. Deverá permitir possibilitar que o controle de portas seja aplicado para todas as aplicações;. 3.1.193.13. Deverá possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc.) possuindo granularidade de controle/politicas para os mesmos. 3.14. Deverá possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, YIM, Facebook Chat, etc.) possuindo granularidade de controle/politicas para os mesmos. 3.15. Deverá possibilitar a diferenciação e controle de partes das aplicações como por exemplo permitir criar filtro na tabela o YIM chat e bloquear a transferência de regras de segurança para exibir somente:arquivos. 3.1.19.1. Regras que permitem passagem de tráfego baseado na porta e não por aplicação, exibindo quais aplicações estão trafegando nas mesmas, o volume em bytes trafegado por cada a aplicação por, pelo menos, os últimos 30 dias e o primeiro e último registro de log de cada aplicação trafegada por esta determinada regra; 3.1.19.2. Aplicações permitidas em regras de forma desnecessária, pois não há tráfego da mesma na determinada regra; 3.1.19.3. Regras de segurança onde não houve passagem de tráfego nos últimos 90 dias; 3.1.19.43.16. Deverá possibilitar a diferenciação de aplicações Proxies (ultrasurf, ghostsurf, freegate, etc.) possuindo granularidade de controle/políticas politicas para os mesmos;. 3.1.203.17. Deverá incluir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais aplicações através da integração com serviços de diretório, autenticação via ldap, Active Directory, E-diretório e base de dados local. 3.18. Deverá possuir integração com Microsoft Active Directory para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em Usuários e Grupos de usuários. 3.19. Deverá possuir integração com Radius para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em Usuários e Grupos de usuários. 3.20. Deverá possuir integração com Ldap para identificação de usuários e grupos permitindo granularidade de controle/politicas baseadas em Usuários e Grupos de usuários. 3.21. Deverá incluir a capacidade de criação de políticas baseadas no controle por aplicação, categoria de aplicação, subcategoria, tecnologia e fator de risco. 3.22. Deverá incluir a capacidade de criação de políticas baseadas no controle por usuário, grupos de usuários ou endereço ip. 3.23. Deverá incluir a capacidade de criação de políticas baseadas em “traffic shaping” por aplicação, usuário, origem, destino, túnel vpn-ipsec-ssl. 3.24. Deverá permitir o controle, sem instalação de cliente de software, em equipamentos que solicitem saída a criação internet para que antes de grupos estáticos iniciar a navegação, expanda-se um portal de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: 3.1.20.1. Tecnologia utilizada na aplicação autenticação residente no firewall (Client-Server, Browser Based, Network Protocol, etcCaptive Portal). 3.1.20.23.25. Nível de risco da aplicaçãoSuporte a autenticação Kerberos. 3.1.20.33.26. Categoria Deverá possuir suporte a identificação de usuários em ambiente Citrix e subcategoria de aplicaçõesMicrosoft Terminal Server, permitindo visibilidade e controle granular por usuário sobre o uso das aplicações que estão nestes serviços. 3.1.20.4. Aplicações que usem técnicas evasivas, utilizadas por malwares, como transferência de arquivos e/ou uso excessivo de banda, etc.

Controle de Aplicações. 3.1. A solução deverá possuir a capacidade Deverá contar com ferramentas de reconhecer visibilidade que permitam administrar o tráfego de aplicações, independente permitindo a execução de porta e protocolo, com as seguintes funcionalidades: 3.1.1. Deverá permitir a liberação aplicações autorizadas e bloqueio somente de aplicações sem a necessidade não autorizadas. 3.2. O controle de liberação de aplicações deve identificá-las independente das portas e protocolos, bem como de técnicas de evasão utilizadas. 3.1.23.3. O fornecedor deverá descrever as técnicas utilizadas pela solução para a detecção das aplicações (Assinaturas, Porta/Protocolo, Heurística, etc) e se as mesmas são baseadas em inspeção IPS ou inspeção profunda de pacotes (Deep Packet Inspection); 3.4. Deverá permitir a inspeção do payload do pacote de dados com o objetivo de detectar através de expressões regulares assinaturas de aplicações conhecidas pelo fabricante independente de porta e protocolo. A checagem de assinaturas também deverá determinar se uma aplicação está utilizando a porta default ou não, incluindo, mas não limitado a RDP na porta 80 ao invés de 389; 3.1.3. Deverá aplicar heurística a fim de detectar aplicações através de análise comportamental do tráfego observado, incluindo, mas não limitado a Encrypted Bittorrent e aplicações VOIP que utilizam criptografia proprietária; 3.1.4. Deverá identificar o uso de táticas evasivas, ou seja, deverá ter a capacidade de visualizar e controlar as aplicações e os ataques que utilizam táticas evasivas via comunicações criptografadas; 3.1.5. Para tráfego criptografado SSL, deverá decriptografar pacotes a fim de possibilitar a leitura de payload para checagem de assinaturas de aplicações conhecidas pelo fabricante; 3.1.6. Deverá permitir decodificação de protocolos com o objetivo de detectar aplicações encapsuladas dentro do protocolo e validar se o tráfego corresponde com a especificação do protocolo. A decodificação de protocolo também deverá identificar funcionalidades específicas dentro de uma aplicação, além de detectar arquivos e outros conteúdos que deverão ser inspecionados de acordo as regras de segurança implementadas; 3.1.7. Deverá permitir identificar o uso de táticas evasivas via comunicações criptografadas; 3.1.8. Deverá atualizar a base de assinaturas de aplicações automaticamente; 3.1.9. Deverá reconhecer aplicações em IPv6; 3.1.10. Deverá permitir limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem; 3.1.11. Deverá permitir adicionar controle de aplicações em todas as regras de segurança do dispositivo, ou seja, não se limitando somente a possibilidade de habilitar controle de aplicações em algumas regras; 3.1.12. Deverá permitir suportar múltiplos métodos de identificação e classificação das aplicações. 3.5. Para manter a segurança da rede eficiente, por pelo menos checagem de assinaturas, decodificação de protocolos e análise heurística; 3.1.13. Deverá permitir deve suportar o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas;. 3.1.143.6. Deverá permitir nativamente suportar a criação de aplicações customizadas pela interface gráfica do produto. 3.7. Deverá incluir a capacidade de atualização para identificar novas aplicações. 3.8. Deverá atualizar a base de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da soluçãoautomaticamente, sem a necessidade durante o período de ação do fabricante, mantendo a confidencialidade das aplicações do órgão;suporte/garantia contratado 3.1.15. A criação de assinaturas personalizadas deve permitir o uso de expressões regulares, contexto (sessões ou transações), usando posição no payload dos pacotes TCP e UDP e usando decoders de pelo menos os seguintes protocolos: HTTP, FTP, SMB, SMTP, Telnet, SSH, MS-SQL, IMAP, IMAP, MS-RPC, RTSP e File body. 3.1.163.9. O fabricante deverá deve permitir a solicitação de inclusão de aplicações na base padrão de assinaturas de aplicações;assinaturas. 3.1.173.10. Deverá permitir alertar o usuário quando uma aplicação for bloqueada;. 3.1.183.11. Deverá permitir possibilitar que o controle de portas seja aplicado para todas as aplicações;. 3.1.193.12. Deverá possibilitar a diferenciação de tráfegos Peer2Peer (Bittorrent, emule, neonet, etc.) possuindo granularidade de controle/políticas para os mesmos. 3.13. Deverá possibilitar a diferenciação de tráfegos de Instant Messaging (AIM, YIM, Facebook Chat, etc.) possuindo granularidade de controle/políticas para os mesmos. 3.14. Deverá possibilitar a diferenciação e controle de partes das aplicações como, por exemplo, permitir criar filtro na tabela o chat e bloquear a transferência de regras de segurança para exibir somente:arquivos. 3.1.19.1. Regras que permitem passagem de tráfego baseado na porta e não por aplicação, exibindo quais aplicações estão trafegando nas mesmas, o volume em bytes trafegado por cada a aplicação por, pelo menos, os últimos 30 dias e o primeiro e último registro de log de cada aplicação trafegada por esta determinada regra; 3.1.19.2. Aplicações permitidas em regras de forma desnecessária, pois não há tráfego da mesma na determinada regra; 3.1.19.3. Regras de segurança onde não houve passagem de tráfego nos últimos 90 dias; 3.1.19.43.15. Deverá possibilitar a diferenciação de aplicações Proxies (ultrasurf, ghostsurf, freegate, etc.) possuindo granularidade de controle/políticas para os mesmos;. 3.1.203.16. Deverá incluir a capacidade de criação de políticas baseadas na visibilidade e controle de quem está utilizando quais aplicações através da integração com serviços de diretório, autenticação via LDAP, Active Directory, Edirectory e base de dados local. 3.17. Deverá incluir a capacidade de criação de políticas baseadas no controle por aplicação, categoria de aplicação, subcategoria, tecnologia e fator de risco. 3.18. Deverá incluir a capacidade de criação de políticas baseadas no controle por usuário, grupos de usuários ou endereço IP. 3.19. Deverá incluir a capacidade de criação de políticas baseadas em “traffic shaping” por aplicação, usuário, origem, destino, túnel vpnipsec- ssl. 3.20. Deverá permitir o controle, sem instalação de cliente de software, em equipamentos que solicitem saída a criação internet para que antes de grupos estáticos iniciar a navegação, expanda-se um portal de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: 3.1.20.1. Tecnologia utilizada na aplicação autenticação residente no firewall (Client-Server, Browser Based, Network Protocol, etcCaptive Portal). 3.1.20.23.21. Nível de risco da aplicaçãoDeverá suportar autenticação Kerberos. 3.1.20.33.22. Categoria Deverá possuir suporte a identificação de usuários em ambiente Citrix e subcategoria de aplicaçõesMicrosoft Terminal Server, permitindo visibilidade e controle granular por usuário sobre o uso das aplicações que estão nestes serviços. 3.1.20.4. Aplicações que usem técnicas evasivas, utilizadas por malwares, como transferência de arquivos e/ou uso excessivo de banda, etc.

Controle de Aplicações. 3.1. A solução deverá possuir a capacidade de reconhecer aplicações, independente de porta e protocolo, com as seguintes funcionalidades: 3.1.1. : Deverá permitir a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos. 3.1.2. Deverá permitir a inspeção do payload do pacote de dados com o objetivo de detectar através de expressões regulares assinaturas de aplicações conhecidas pelo fabricante independente de porta e protocolo. A checagem de assinaturas também deverá determinar se uma aplicação está utilizando a porta default ou não, incluindo, mas não limitado a RDP na porta 80 ao invés de 389; 3.1.3. ; Deverá aplicar heurística a fim de detectar aplicações através de análise comportamental do tráfego observado, incluindo, mas não limitado a Encrypted Bittorrent e aplicações VOIP que utilizam criptografia proprietária; 3.1.4. ; Deverá identificar o uso de táticas evasivas, ou seja, deverá ter a capacidade de visualizar e controlar as aplicações e os ataques que utilizam táticas evasivas via comunicações criptografadas; 3.1.5. ; Para tráfego criptografado SSL, deverá decriptografar pacotes a fim de possibilitar a leitura de payload para checagem de assinaturas de aplicações conhecidas pelo fabricante; 3.1.6. ; Deverá permitir decodificação de protocolos com o objetivo de detectar aplicações encapsuladas dentro do protocolo e validar se o tráfego corresponde com a especificação do protocolo. A decodificação de protocolo também deverá identificar funcionalidades específicas dentro de uma aplicação, além de detectar arquivos e outros conteúdos que deverão ser inspecionados de acordo as regras de segurança implementadas; 3.1.7. ; Deverá permitir identificar o uso de táticas evasivas via comunicações criptografadas; 3.1.8. ; Deverá atualizar a base de assinaturas de aplicações automaticamente; 3.1.9. ; Deverá reconhecer aplicações em IPv6; 3.1.10. ; Deverá permitir limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem; 3.1.11. ; Deverá permitir adicionar controle de aplicações em todas as regras de segurança do dispositivo, ou seja, não se limitando somente a possibilidade de habilitar controle de aplicações em algumas regras; 3.1.12. ; Deverá permitir múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas, decodificação de protocolos e análise heurística; 3.1.13. ; Deverá permitir o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas; 3.1.14. ; Deverá permitir nativamente a criação de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da solução, sem a necessidade de ação do fabricante, mantendo a confidencialidade das aplicações do órgão; 3.1.15. ; A criação de assinaturas personalizadas deve permitir o uso de expressões regulares, contexto (sessões ou transações), usando posição no payload dos pacotes TCP e UDP e usando decoders de pelo menos os seguintes protocolos: HTTP, FTP, SMB, SMTP, Telnet, SSH, MS-SQL, IMAP, IMAP, MS-RPC, RTSP e File body. 3.1.16. O fabricante deverá permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações; 3.1.17. ; Deverá permitir alertar o usuário quando uma aplicação for bloqueada; 3.1.18. ; Deverá permitir que o controle de portas seja aplicado para todas as aplicações; 3.1.19. ; Deverá permitir criar filtro na tabela de regras de segurança para exibir somente: 3.1.19.1. : Regras que permitem passagem de tráfego baseado na porta e não por aplicação, exibindo quais aplicações estão trafegando nas mesmas, o volume em bytes trafegado por cada a aplicação por, pelo menos, os últimos 30 dias e o primeiro e último registro de log de cada aplicação trafegada por esta determinada regra; 3.1.19.2. Caso essa informação não possa ser exibida através da criação de filtro, tais informações deverão ser exibidas em tabelas ou gráficos em dashboards e/ou monitores do console de gerenciamento; Aplicações permitidas em regras de forma desnecessária, pois não há tráfego da mesma na determinada regra; 3.1.19.3. Caso não seja possível criar filtro, deverá ser possível visualizar a sessões associadas a uma determinada regra, através do campo “hit count”; Regras de segurança onde não houve passagem de tráfego nos últimos 90 dias; 3.1.19.4. Caso não seja possível criar esse filtro, deverá ser possível visualizar a data e horário da última vez que houve associação de tráfego a uma regra; Deverá possibilitar a diferenciação de aplicações Proxies (ghostsurf, freegate, etc.) possuindo granularidade de controle/políticas para os mesmos; 3.1.20. ; Deverá permitir a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: 3.1.20.1. : Tecnologia utilizada na aplicação (Client-Server, Browser Based, Network Protocol, etc). 3.1.20.2. Nível de risco da aplicação. 3.1.20.3. Categoria e subcategoria de aplicações. 3.1.20.4. Aplicações que usem técnicas evasivas, utilizadas por malwares, como transferência de arquivos e/ou uso excessivo de banda, etc.

Controle de Aplicações. 3.1. A solução deverá possuir a capacidade de reconhecer aplicações, independente de porta e protocolo, com as seguintes funcionalidades: 3.1.1. Deverá permitir a liberação e bloqueio somente de aplicações sem a necessidade de liberação de portas e protocolos. 3.1.2. Deverá permitir a inspeção do payload do pacote de dados com o objetivo de detectar através de expressões regulares assinaturas de aplicações conhecidas pelo fabricante independente de porta e protocolo. A checagem de assinaturas também deverá determinar se uma aplicação está utilizando a porta default ou não, incluindo, mas não limitado a RDP na porta 80 ao invés de 389; 3.1.3. Deverá aplicar heurística a fim de detectar aplicações através de análise comportamental do tráfego observado, incluindo, mas não limitado a Encrypted Bittorrent e aplicações VOIP que utilizam criptografia proprietária; 3.1.4. Deverá identificar o uso de táticas evasivas, ou seja, deverá ter a capacidade de visualizar e controlar as aplicações e os ataques que utilizam táticas evasivas via comunicações criptografadas; 3.1.5. Para tráfego criptografado SSL, deverá decriptografar pacotes a fim de possibilitar a leitura de payload para checagem de assinaturas de aplicações conhecidas pelo fabricante; 3.1.6. Deverá permitir decodificação de protocolos com o objetivo de detectar aplicações encapsuladas dentro do protocolo e validar se o tráfego corresponde com a especificação do protocolo. A decodificação de protocolo também deverá identificar funcionalidades específicas dentro de uma aplicação, além de detectar arquivos e outros conteúdos que deverão ser inspecionados de acordo as regras de segurança implementadas; 3.1.7. Deverá permitir identificar o uso de táticas evasivas via comunicações criptografadas; 3.1.8. Deverá atualizar a base de assinaturas de aplicações automaticamente; 3.1.9. Deverá reconhecer aplicações em IPv6; 3.1.10. Deverá permitir limitar a banda (download/upload) usada por aplicações (traffic shaping), baseado no IP de origem; 3.1.11. Deverá permitir adicionar controle de aplicações em todas as regras de segurança do dispositivo, ou seja, não se limitando somente a possibilidade de habilitar controle de aplicações em algumas regras; 3.1.12. Deverá permitir múltiplos métodos de identificação e classificação das aplicações, por pelo menos checagem de assinaturas, decodificação de protocolos e análise heurística; 3.1.13. Deverá permitir o controle sobre aplicações desconhecidas e não somente sobre aplicações conhecidas; 3.1.14. Deverá permitir nativamente a criação de assinaturas personalizadas para reconhecimento de aplicações proprietárias na própria interface gráfica da solução, sem a necessidade de ação do fabricante, mantendo a confidencialidade das aplicações do órgão; 3.1.15. A criação de assinaturas personalizadas deve permitir o uso de expressões regulares, contexto (sessões ou transações), usando posição no payload dos pacotes TCP e UDP e usando decoders de pelo menos os seguintes protocolos: HTTP, FTP, SMB, SMTP, Telnet, SSH, MS-SQL, IMAP, IMAP, MS-RPC, RTSP e File file body. 3.1.16. O fabricante deverá permitir a solicitação de inclusão de aplicações na base de assinaturas de aplicações; 3.1.17. Deverá permitir alertar o usuário quando uma aplicação for bloqueada; 3.1.18. Deverá permitir que o controle de portas seja aplicado para todas as aplicações; 3.1.19. Deverá permitir criar filtro na tabela de regras de segurança para exibir somente: 3.1.19.1. Regras que permitem passagem de tráfego baseado na porta e não por aplicação, exibindo quais aplicações estão trafegando nas mesmas, o volume em bytes trafegado por cada a aplicação por, pelo menos, os últimos 30 dias e o primeiro e último registro de log de cada aplicação trafegada por esta determinada regra. Caso essa informação não possa ser exibida através da criação de filtro, tais informações deverão ser exibidas em tabelas ou gráficos em dashboards e/ou monitores do console de gerenciamento; 3.1.19.2. Aplicações permitidas em regras de forma desnecessária, pois não há tráfego da mesma na determinada regra. Caso não seja possível criar filtro, deverá ser possível visualizar a sessões associadas a uma determinada regra, através do campo “hit count”; 3.1.19.3. Regras de segurança onde não houve passagem de tráfego nos últimos 90 dias. Caso não seja possível criar esse filtro, deverá ser possível visualizar a data e horário da última vez que houve associação de tráfego a uma regra; 3.1.19.4. Deverá possibilitar a diferenciação de aplicações Proxies (ghostsurf, freegate, etc.) possuindo granularidade de controle/políticas para os mesmos; 3.1.20. Deverá permitir a criação de grupos estáticos de aplicações e grupos dinâmicos de aplicações baseados em características das aplicações como: 3.1.20.1. Tecnologia utilizada na aplicação (Client-Server, Browser Based, Network Protocol, etc). 3.1.20.2. Nível de risco da aplicação. 3.1.20.3. Categoria e subcategoria de aplicações. 3.1.20.4. Aplicações que usem técnicas evasivas, utilizadas por malwares, como transferência de arquivos e/ou uso excessivo de banda, etc.