Gerenciamento de patches de emergência

Sistemas Windows

A NICE 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. Microsoft Atualizações Críticas e outros patches são executados através de um ciclo de teste e aplicados em um cronograma regular. Essa programação normalmente é um ciclo de patches de 30 dias, começando com a Patch Tuesday do Microsoft. A NICE 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 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 CXone, depois em clusters alfa e beta e, em seguida, na produção. A NICE 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. 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 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 são corrigidos em uma base calendarizada 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.

Informação Segurança 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 interna usada em 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 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 usa objetivos de nível de serviço ao aplicar patches. Esses objetivos garantem que:

  • As vulnerabilidades conhecidas são corrigidas a tempo.

  • Os patches são compatíveis 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) unidade de negócios for afetado, o(a) unidade de negócios 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(à) unidade de negócios 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.