O Security Hub Compliance Analyzer (SHCA) gera artefatos em apoio ao credenciamento do Sistema de Informação do Departamento de Defesa Risk Management Framework (RMF). Utilizando a documentação fornecida pela Amazon Web Services, mapeando controles NIST800-53-Rev-5 para IDs de controle de segurança do AWS Security Hub, o SHCA solicita a conformidade do ambiente atual do Security Hub e gera um arquivo zip armazenado no Amazon S3 contendo artefatos discretos em CSV, JSON, OCSF fornece ao SecOps artefatos para importação para a ferramenta RMF.
Security Hub com o padrão de segurança da publicação especial NIST 800-53 Revisão 5 e em execução por pelo menos 24 horas para produzir resultados
** Para obter mais informações sobre como ativar este padrão, visite Habilitando e desabilitando padrões de segurança)
Todas as descobertas no Security Hub são extraídas e salvas em JSON.
A descoberta mais recente de cada ID de controle/recurso no JSON é gravada em um arquivo CSV para melhor análise e legibilidade
Um resumo de todos os controles é criado a partir do arquivo CSV seguindo a seguinte metodologia
Esta etapa cria um arquivo para cada controle NIST SP 800-53 com base no status desse controle e os armazena em duas pastas:
Além disso, esta etapa recupera e inclui vários arquivos de um bucket S3. As pastas e seu conteúdo são:
Esses arquivos fornecem dados abrangentes sobre o estado de segurança dos recursos da AWS, com base nas verificações de segurança automatizadas NIST SP 800-53 do Security Hub.
Aqui está o que você precisa instalar para usar o AWS CDK.
Validando a instalação do Python 3.7 ou posterior, pip, virtualenv e Node.js no Linux
node --versionTodos os desenvolvedores do AWS CDK, mesmo aqueles que trabalham em Python, Java ou C#, precisam do Node.js 14.15.0 ou posterior. Todas as linguagens suportadas usam o mesmo backend, que roda em Node.js. Recomendamos uma versão com suporte ativo de longo prazo. Sua organização pode ter uma recomendação diferente.
Outros pré-requisitos dependem da linguagem na qual você desenvolve aplicativos AWS CDK e são os seguintes:
python3 --versionpip3 --versionvirtualenv --versionwget --versionjq --versionnpm install -g aws-cdkExecute o comando a seguir para verificar a instalação correta e imprima o número da versão do AWS CDK.
cdk --version O arquivo cdk.json informa ao CDK Toolkit como executar o aplicativo.
Este projeto é configurado como um projeto Python padrão. O processo de inicialização também cria um virtualenv dentro deste projeto, armazenado no diretório .venv . Para criar o virtualenv ele assume que existe um executável python3 (ou python para Windows) em seu caminho com acesso ao pacote venv . Se por algum motivo a criação automática do virtualenv falhar, você poderá criar o virtualenv manualmente.
Para criar manualmente um virtualenv no MacOS e Linux:
$ python3 -m venv .venv
Após a conclusão do processo init e a criação do virtualenv, você pode usar a etapa a seguir para ativar seu virtualenv.
$ source .venv/bin/activate
Se você estiver em uma plataforma Windows, você ativaria o virtualenv assim:
% .venvScriptsactivate.bat
Assim que o virtualenv for ativado, você poderá instalar as dependências necessárias.
$ pip install -r requirements-deploy.txt
Baixe o AWS Lambda Layer para AWS SDK for Pandas (AWS Wrangler) e coloque-o no seguinte local: Consulte README.md para obter mais informações.
bash update_aws_wrangler.sh
A implantação de pilhas com o AWS CDK exige que buckets dedicados do Amazon S3 e outros contêineres estejam disponíveis para o AWS CloudFormation durante a implantação. Criá-los é chamado de bootstrapping. Para inicializar, emita:
cdk bootstrap aws://ACCOUNT-NUMBER/REGION
Neste ponto, você pode sintetizar o modelo CloudFormation para este código.
$ cdk synth
Modifique os seguintes valores em cdk.json - "environment": "shca" - Dê um nome descritivo para a implantação SHCA. Pode ser qualquer valor e não afeta a funcionalidade. É para rotular os recursos SHCA na conta AWS. - "vpc_cidr": "10.30.0.0/24" - Define o intervalo CIDR para uma pequena VPC criada para a execução das funções Lambda, para não criar o [Lambda.3] As funções Lambda devem estar em uma descoberta de VPC. Selecione um intervalo CIDR que ainda não esteja em uso em seu ambiente. - "schedule_frequency_days": 7 - Esta configuração determina com que frequência você gostaria que o SHCA gerasse relatórios de conformidade. - "send_failure_notification_email": true ou false - Se true , o email será enviado para o endereço fornecido em failure_notification_email . - "failure_notification_email": [email protected] - Este endereço de e-mail receberá notificações em caso de falha na execução do SHCA.
A partir daqui você tem duas opções de como instalar o SHCA (CloudShell ou CDK)
Se você não tiver acesso a um laptop ou ambiente de desenvolvimento onde possa instalar os pré-requisitos acima, o serviço CloudShell poderá ser usado para implantar o SHCA. Além disso, usando credenciais temporárias do AWS IAM Identity Center, podemos usar um único CloudShell em uma conta para fazer chamadas de API do CloudFormation e implantar código em qualquer conta à qual você tenha acesso.
O CloudShell é aprovado pela DISA para uso em ambientes IL2-IL5, incluindo regiões comerciais e GovCloud. Consulte o pessoal de conformidade da sua organização para garantir que o CloudShell seja aprovado para uso na implantação da AWS da sua organização.
Baixe o código-fonte como shca-main.zip, do branch principal deste repositório.
Navegue até o serviço CloudShell na conta AWS que você usará para atuar como seu ambiente de implantação. Certifique-se de ter espaço suficiente no CloudShell antes de realizar a implantação. Se você ficar sem espaço, ele falhará.
Faça upload do código-fonte no CloudShell. Descompacte os arquivos e faça cd no diretório shca-main :
unzip shca-main.zip && cd shca-main
Cole as credenciais temporárias do AWS IAM Identity Center para a conta na qual você deseja implantar o SHCA . O AWS CDK usará essas credenciais temporárias (agora definidas como variáveis de ambiente) para implantar o código na conta de destino correta, mesmo se você estiver usando o CloudShell de outra conta.
Execute aws sts get-caller-identity e verifique se o principal e o número da conta correspondem aos valores esperados.
Conceda permissões de execução e execute ./cloud_shell_deployment.sh
chmod +x cloud_shell_deployment.sh && ./cloud_shell_deployment.sh
Digite y quando o CDK solicitar no shell ambas as vezes .
$ cdk deploy
cdk ls lista todas as pilhas no aplicativocdk synth emite o modelo CloudFormation sintetizadocdk deploy implanta esta pilha em sua conta/região padrão da AWScdk diff compara a pilha implantada com o estado atualcdk docs abre documentação do CDK Depois que o SHCA for implantado:
Navegue até o serviço Step Functions/State Machines:
Selecione YOUR-ENVIRONMENT-NAME-State-Machine
Se você acabou de implantar o SHCA pela primeira vez, verifique se a máquina de estado foi executada com êxito visualizando a execução. Se a máquina de estado foi executada com êxito, pule para a etapa 6 . Caso contrário, para executar o SHCA sob demanda, selecione "Iniciar execução":
Selecione “Iniciar execução” novamente na janela pop-up. Deixe todos os valores padrão.
Role até o final da página e aguarde que todas as etapas sejam concluídas com êxito. Você verá este "ExecutionSucceeded" na parte inferior, uma vez concluído.
Navegue até o console do Amazon S3 e encontre e selecione o bucket chamado "-resources-%YOUR_ACCOUNT_NUMBER%"
Neste intervalo, navegue até customer/compliance_scraper/
Baixe o arquivo zip dos artefatos mais recentes.
Revise os arquivos contidos no zip
Consulte CONTRIBUINDO para obter mais informações.
Este projeto está licenciado sob a licença Apache-2.0.
