Gerenciamento de patches de emergência

Sistemas Windows

A NICE CXone deverá aplicar patches aos sistemas CXone afetados o mais rápido possível se:

  • O código de prova de conceito estiver disponível publicamente sobre uma possível exploração.

  • Um novo patch de segurança crítico é lançado.

O objetivo desses patches é remover imediatamente as vulnerabilidades no ambiente de nuvem da organização. As atualizações críticas da Microsoft e outros patches são executados por meio de um ciclo de teste e aplicados regularmente. Esse cronograma geralmente é um ciclo de patch de 30 dias, começando com o Patch Tuesday da Microsoft. A NICE CXone também mantém um cronograma de aplicação de patches do Linux com uma classificação de prioridade semelhante. Os patches críticos não devem esperar a aplicação de patches do mês seguinte.

Patches e atualizações são documentados em um registro de controle de alterações (CCR). Eles devem ser avaliados pelo Conselho de gerenciamento de alterações NICE CXone em relação ao seguinte:

  • Impacto.

  • Análise de risco.

  • Medidas necessárias adotadas antes da aprovação.

Patches e upgrades também devem passar por avaliações técnicas e de colegas.

Os patches e upgrades são testados primeiro no laboratório da NICE CXone, depois em clusters alfa e beta e, em seguida, na produção. A NICE CXone mantém um processo de gerenciamento de alterações de emergência para problemas críticos inesperados.

O teste é realizado em atualizações por um departamento de controle de qualidade (QA) dedicado. Esse departamento utiliza as práticas das diretrizes da NICE CXone. Essas diretrizes são encontradas em:

  • Ciclo de vida do desenvolvimento de segurança (SDLC).

  • Documentos de políticas e procedimentos.

As equipes de operações da NICE CXone atualizam ou aplicam patches a todos os dispositivos CXone aplicáveis. A aplicação de patches ocorre durante uma janela de manutenção definida, normalmente abrangendo três horas fora do horário de pico à noite, dependendo do local. A janela de manutenção é divulgada como parte do contrato do cliente. A manutenção pode resultar em uma breve interrupção enquanto os servidores são reiniciados ou os clusters sofrem failover.

Sistemas e software não-Windows

O Linux e outros sistemas operacionais e dispositivos não-Windows recebem patches de forma agendada e ad-hoc. Eles seguem o mesmo processo e ciclo do CCB (Conselho de controle de alterações) acima. As versões atuais são conhecidas e comparadas com vulnerabilidades e exposições comuns relevantes (CVEs) e corrigidas.

O setor de Segurança da Informação avalia software de terceiros ou não-Windows. Eles fazem isso usando:

  • Análise orientada por QA.

  • O Centro de Segurança.

  • Outros controles e relatórios de detecção.

A Segurança da Informação comunica essas vulnerabilidades aos respectivos proprietários e grupos, como SysOps ou P&D. As vulnerabilidades classificadas como "Críticas" ou "Altas" devem ser corrigidas dentro de 30 a 90 dias. Certas ameaças dentro dessas vulnerabilidades devem ser gerenciadas dentro do período de 30 dias.

Ferramentas

Infra-Tools é uma ferramenta usada no Windows. Ela detecta automaticamente o status de software e hardware. Essa ferramenta é executada por grupos de Operações de Sistemas. Ela garante que máquinas e softwares sem patches sejam sinalizados e corrigidos.

Os firewalls fazem inspeção profunda de pacotes durante IDS/IPS com proteção contra ameaças habilitada.

O NICE CXone emprega outras ferramentas administrativas de pesquisa do cenário de ameaças internamente. SIEMs de registro em log inspecionam logs de servidores apropriados em busca de anomalias.

Objetivos de nível de serviço

O NICE CXone usa objetivos de nível de serviço ao aplicar patches. Esses objetivos garantem que:

  • as vulnerabilidades conhecidas sejam corrigidas a tempo.

  • os patches estejam em conformidade com:

    • PCI-DSS

    • Outros requisitos de infraestrutura de segurança com escopo definido.

Uma escala é usada para descrever o risco de patches e eventos. O grupo de proprietários de dispositivos internos classifica a vulnerabilidade como "Crítica", "Alta", "Média" ou "Baixa".

  • As vulnerabilidades críticas devem ser corrigidas dentro de 30 dias.

  • As vulnerabilidades altas devem ser corrigidas dentro de 60 dias.

  • As vulnerabilidades médias devem ser corrigidas dentro de 90 dias.

  • As vulnerabilidades baixas devem ser corrigidas dentro de um período definido pelo grupo de proprietários de dispositivos internos.

A Segurança da Informação passa as informações sobre os pontos fracos para o Centro de Segurança. Eles fazem isso com relatórios de inspeção de vulnerabilidade.

Ciclo de correção

A análise de ameaças críticas começa imediatamente após a descoberta. A definição da ameaça e o plano de ação são determinados em um período de 72 horas. Em seguida, o plano entra no ciclo de correção. O ciclo de correção consiste no seguinte:

  1. Arquitetura de uma solução.

  2. Engenharia da solução.

  3. Implementação no laboratório para testes.

  4. Passar a solução para o QA.

  5. Cronograma de lançamento.

  6. Processo de avaliação e aprovação de colegas do Conselho de Alterações.

  7. Implantação.

A análise, definição, plano de ação e ciclo de correção devem ocorrer em até 30 dias após a detecção. Se um serviço do(a) usuário for afetado, o(a) usuário será notificado sobre o progresso das atualizações. As atualizações são fornecidas à medida que cada etapa do ciclo de correção é implementada. Após a correção bem-sucedida, dependendo do incidente, um RCA é entregue ao(à) usuário afetado(a).

Exceções

A correção manual e a catalogação são executadas para servidores e dispositivos que não:

  • Comunicam-se com servidores WSUS.

  • Podem captar atualizações.

Os relatórios de serviços sem patches são fornecidos à Segurança da Informação para ações de visibilidade, acompanhamento e correção.