Se já passou por uma auditoria SOC 2, sabe como é. São semanas a fazer capturas de ecrã de painéis de controlo e a procurar provas em cerca de uma dúzia de ferramentas, enquanto espera que o auditor não faça uma pergunta de seguimento à qual não consiga responder. Felizmente, a SOC 2 não tem de ser assim tão penosa, especialmente se as ferramentas que já utiliza para a segurança estiverem a gerar as provas por si, como um subproduto do simples facto de estarem a fazer o seu trabalho.
É isso que a Segurança « Aikido » pode fazer pelas aplicações e pelo « segurança na nuvem ». Eis como isto se relaciona com o que o SOC 2 realmente exige e em que aspetos difere, dependendo se se pretende obter um relatório do Tipo 1 ou do Tipo 2.
SOC 2 Tipo 1 vs. Tipo 2
A sociedade de revisores oficiais de contas licenciada responsável pela sua auditoria está a avaliar os seus controlos em relação aos Critérios de Serviços de Confiança que definiu no âmbito do seu projeto. A segurança é a única categoria obrigatória, mas a maioria das empresas acrescenta a disponibilidade, a confidencialidade ou ambas (a privacidade e a integridade do processamento são as outras duas categorias). Em última análise, as categorias que uma empresa escolhe para além da segurança dependem das suas necessidades empresariais.
O tipo de relatório, SOC 2 Tipo 1 ou Tipo 2, determina o tipo de provas necessárias:
- O Tipo 1 é um instantâneo num determinado momento. O auditor verifica se os seus controlos estão concebidos de forma adequada numa data específica. O que está a fazer é apresentar o seu sistema e comprovar que os controlos existem e estão configurados corretamente neste momento.
- O Tipo 2 abrange um período (normalmente de 3 a 12 meses) e atesta que os controlos funcionaram eficazmente ao longo desse período. Este é o mais difícil. São necessárias provas contínuas sob a forma de registos, marcas temporais e históricos de correção. Estas provas têm de demonstrar que um controlo não só existia no primeiro dia, mas continuou a funcionar no dia 47 e no dia 214.
Muitas equipas subestimam a importância da preparação para a auditoria de Tipo 1, porque bastam enviar uma captura de ecrã da configuração e seguir em frente. Mas depois são apanhadas de surpresa pela auditoria de Tipo 2, porque, nessa altura, o auditor exige o registo completo e as capturas de ecrã já não são suficientes. As ferramentas que apenas ajudam a produzir um instantâneo não são de grande utilidade quando se trata de elaborar um relatório de Tipo 2 ano após ano.
O lugar que o « Aikido » ocupa nos Critérios de Serviços de Confiança
Aikido consolida SAST, DAST, SCA, secrets , deteção de container e varredura IaC, gestão da postura na nuvem (CSPM), deteção de malware e pentest de IA numa única plataforma. Isto proporciona-lhe um painel de controlo unificado: um único local onde pode obter todas as suas evidências, com um SLA e um fluxo de trabalho de correção integrados. Os auditores pretendem um relato coerente sobre as vulnerabilidades detetadas e corrigidas dentro de prazos definidos, e não seis exportações diferentes combinadas de forma desorganizada com formatos de data e hora distintos.
Eis alguns dos controlos em que o site Aikido pode ajudar:
Acesso lógico (CC6.1) e proteção de limites (CC6.6)
AikidoAs verificações na nuvem do [nome] assinalam a falta de aplicação da autenticação multifator (MFA) e controlos de acesso mal configurados, e a sua deteção de « secrets » analisa continuamente as credenciais expostas nos repositórios e na infraestrutura. A norma CC6.6 aborda a proteção contra ameaças externas nos limites do sistema. As regras de postura na nuvem do [nome] Aikido assinalam lacunas na segmentação da rede e serviços expostos, fornecendo-lhe essas evidências diretamente.
Transmissão e encriptação de dados (CC6.7)
Cloud e as verificações do « SAST » confirmam a encriptação em trânsito (e, normalmente, também em repouso, embora deva confirmar este aspeto com a interpretação do seu auditor específico), pelo que não é necessário verificar manualmente as configurações TLS em todos os serviços antes de uma auditoria.
Integridade do software e malware (CC6.8)
AikidoA análise de dependências e a deteção de malware oferecem-lhe um inventário em tempo real do que está a ser executado e assinalam pacotes conhecidos como maliciosos ou comprometidos. Isto responde diretamente à exigência de «prevenir ou detetar e agir perante a introdução de software não autorizado ou malicioso» prevista na CC6.8.
Monitorização e « gerenciamento de vulnerabilidades » (CC7.1/CC7.2)
A análise contínua em SAST, SCA, contentores e DAST produz exatamente o tipo de evidência sustentada que um auditor de Tipo 2 pretende ver ao longo de todo o período de auditoria. O acompanhamento do SLA (tempo de correção em relação a limiares definidos) cria um registo datado e exportável. E embora a SOC 2 não exija explicitamente um teste de penetração, espera-se geralmente que as organizações realizem esses testes para garantir que os controlos se mantêm eficazes caso sejam confrontadas com um ataque real. O pentest de IA daAikido implementa agentes de IA que agem como verdadeiros atacantes, descobrindo e explorando falhas nas suas aplicações, APIs e infraestrutura. Os relatórios dos testes de penetração mostram tudo o que foi testado e as vulnerabilidades encontradas. E para testes contínuos, oAikido Infinite é um serviço de monitorização contínua pentest de IA.
Gestão da mudança (CC8.1)
AikidoOs «gates» de CI/CD e as verificações de segurança do SCM proporcionam-lhe um registo integrado de gestão de alterações com dois pontos de controlo. O controlo de pull requests verifica cada pull request e rejeita-o quando os problemas recém-introduzidos atingem o seu limiar de gravidade. O controlo de lançamentos aplica a mesma lógica a uma compilação ou lançamento, pelo que um commit que não cumpra o limiar não é lançado. É o próprio utilizador que define o limiar, que pode variar entre «baixo» e «crítico», e os controlos abrangem vulnerabilidades de dependências, SAST, IaC, secrets e problemas relacionados com malware. No GitHub, a proteção de ramos com verificações de estado obrigatórias faz com que uma verificação com falha bloqueie a fusão. Todos os PRs, decisões de controlo, substituições e exceções são registados e passíveis de auditoria.
Avaliação de riscos (CC3.2)
A pontuação de gravidade e a verificação de « reachability analysis » (que verifica se uma função vulnerável é efetivamente acessível no seu código, em vez de estar apenas presente numa árvore de dependências), o CVE análise de explorabilidade e o pentest de IA , que valida se uma vulnerabilidade é explorável no seu ambiente, alimentam todos um processo de « priorização baseada em risco ». Quando a funcionalidade « análise de explorabilidade » está ativada, o Agente Aikido analisa como um pacote vulnerável é utilizado nos seus repositórios e contentores. Cada execução é registada num histórico, e pode exigir aprovação humana antes de qualquer ação ser aplicada. Os auditores esperam cada vez mais ver isto, em vez de aceitarem a desculpa de que «acabamos por corrigir tudo».
Disponibilidade (A1.2)
Cloud As verificações da integridade e da completude das cópias de segurança apoiam os critérios de disponibilidade, que se situam totalmente fora da série CC, constituindo os seus próprios critérios «A».
A preparar-se para a certificação SOC 2
Um painel que apresenta a deteção de vulnerabilidades e o cumprimento do SLA relativo à correção ao longo de todo o período de auditoria fornece ao auditor tudo o que este necessita. Sem essa visão contínua, o que se tem é uma troca interminável de e-mails a solicitar «mais cobertura» desse período.
É claro que nenhuma ferramenta, por si só, garantirá que passe na auditoria. Os auditores vão sempre querer ver as suas políticas, procedimentos, avaliações de risco, análises de acesso e processo de resposta a incidentes.
No entanto, o Aikido trata da parte mais tediosa e repleta de evidências da certificação SOC 2 e permite a sua exportação durante a época de auditorias. O gerenciamento de vulnerabilidades, a verificação do controlo de acesso, o acompanhamento da gestão de alterações e a validação da encriptação estão todos reunidos numa única plataforma com um único caminho de exportação.
Se estiver a dar prioridade ao Tipo 1, tendo o Tipo 2 como objetivo a curto prazo, configure a análise contínua e o acompanhamento SLA com antecedência, mesmo antes do início oficial do período de auditoria. As provas que não tiver recolhido não passam a existir retroativamente e, no caso do Tipo 2, o prazo para «operar eficazmente ao longo de todo o período» começa no dia em que o auditor indicar.
