by Scott Muniz | May 10, 2022 | Security, Technology
This article is contributed. See the original author and article here.
CISA and the Federal Bureau of Investigation (FBI) have updated the joint cybersecurity advisory, Strengthening Cybersecurity of SATCOM Network Providers and Customers, originally released March 17, 2022, with U.S. government attribution to Russian state-sponsored malicious cyber actors. The United States assesses Russia launched cyberattacks in late February against commercial satellite communications networks to disrupt Ukrainian command and control during the Russia invasion, and those actions had spillover impacts into other European countries.
CISA is working with both international and JCDC partners to strengthen our collective cybersecurity resilience—especially in the critical infrastructure that governments and citizens rely on—and to protect against and respond to malicious cyber activity. We continue to urge public and private sector partners to review and implement the guidance contained in U.S. government cybersecurity advisories, including Strengthening Cybersecurity of SATCOM Network Providers and Customers, the January 2022 cybersecurity advisory on Protecting VSAT Communications, and the April 2022 cybersecurity advisory on Russian State-Sponsored and Criminal Threats to Critical Infrastructure. CISA also recommends partners review the CISA Shields Up, Shields Up Technical Guidance, and Russia webpages to stay current on the preventive measures that can help guard against Russian cyber threats and tactics.
by Contributed | May 9, 2022 | Technology
This article is contributed. See the original author and article here.
Descubra vulnerabilidades e automatize a atualização de dependências com GitHub Dependabot
Dando continuidade ao artigo Como manter meu código seguro usando o GitHub nesse artigo vamos ver como o Dependabot pode nos ajudar a manter nosso código mais seguro.
Dependabot
Dependabot é um recurso que além de identificar vulnerabilidades nas dependências do seu código, ele pode te ajudar criando Pull Requests com a atualização da dependência com a versão já corrigida. Ele está disponível para todos os repositórios e recentemente foi liberada uma atualização que permite a atualização das dependências privadas do seu repositório.
Para isso ele conta com o GitHub Advisory Database uma lista de vulnerabilidades de segurança conhecidas, agrupadas em duas categorias:
GitHub-reviewed advisories – As vulnerabilidades que já foram identificadas e analisadas pelo GitHub, para essas são geradas notificações sempre que uma vulnerabilidade for identificada nas dependências do seu repositório, para isso, o alerta do Dependabot deve ser ativado.
Unreviewed advisories – As vulnerabilidades que estão listadas no feed do National Vulnerability Database, o Dependabot não gera alertas para essas vulnerabilidades, pois não houve verificação sobre a validade ou integridade por parte do GitHub.
O GitHub adiciona vulnerabilidades na lista do GitHub Advisory Database a partir das seguintes fontes:
Como habilitar o Dependabot
Para habilitar, você precisa acessar o menu Security -> Dependabot alerts e habilitar a opção Enable Dependabot alerts
Painel de Segurança do portal do GitHub, nela está destacado os seguintes termos: Security, Dependabot alerts, Enable Dependabot alerts
Com isso o Dependabot já passa a monitorar seu repositório em busca de vulnerabilidades nas dependências do seu repositório.
A partir de agora o Dependabot passará a gerar aletas sempre que:
- Uma nova vulnerabilidade for adicionada no GitHub Advisory Database
- O Gráfico dependência for atualizado. Exemplo um desenvolvedor faz um push de um commit que atualiza alguma dependência que esteja na lista do GitHub Advisory Database .
O que acontece depois de habilitar o Dependabot
Acessando novamente o menu Security -> Dependabot alerts é possível visualizar se há algum alerta de vulnerabilidade. Você terá acesso a uma lista completa de todas as vulnerabilidades encontradas em seu repositório, podendo filtrar por Pacote, ecossistema ou manifesto, há a opção de ordenar por mais novo, mais antigo, gravidade, localidade do manifesto ou nome do pacote.
Alertas do portal do GitHub, agora com uma lista de vulnerabilidades e com os seguintes termos destacados: Security e Dependabot alerts
Clicando no alerta é possível obter mais informações sobre a vulnerabilidade, que pode incluir a descrição, nível de gravidade, nome do pacote afetado, ecossistema do pacote, as versões afetadas e as versões de patch, impacto e algumas informações opcionais como, por exemplo, referências, soluções alternativas e créditos. Além disso, um link para o registro CVE, onde você pode ler mais detalhes sobre a vulnerabilidade, suas pontuações CVSS e seu nível de gravidade qualitativa.
Detalhes de uma vulnerabilidade destacando as seguintes informações Severity, Affected versions, Patched version, impact, Patches, workarounds, weaknesses CVE ID e GHSA ID
O dependabot também envia notificações para os mantenedores do repositório onde a vulnerabilidade foi encontrada. Por padrão o mantenedor receberá um e-mail com um breve relato sobre a descoberta.
E-mail enviado pelo Dependabot
Localize repositórios com vulnerabilidades
Acessando o GitHub Advisory Database é possível identificar quais repositórios possui dependências com vulnerabilidade, para isso acesse o GitHub Advisory Database clicando nesse link.
Tela inicial do GitHub Advisory Database
No GitHub Advisory Database é possível filtrar as vulnerabilidades por ecossistema, CVE/GHSA ID, nome do pacote, gravidade ou ordenar por mais novo, mais antigo, atualizado recentemente ou menos atualizado recentemente. Ao localizar a vulnerabilidade desejada é possível ver quais repositórios utiliza a dependência.
Resultado de pesquisa do GitHub Advisory Database, destacando o termo Dependabot alert
Resultado de pesquisa do GitHub Advisory Database mostrando quais repositórios há a dependência selecionada, o nome do repositório está destacado.
Atualize as dependências com ajuda do Dependabot
Após um alerta ser gerado, se já existir uma versão com a correção da vulnerabilidade o Dependabot abre um Pull Request com a ação corretiva, em alguns casos quando o as informações são suficientes uma pontuação de confiabilidade é gerada.
O Pull Request passa pelos mesmos testes que os demais Pull Requests gerados pelo time responsável pelo repositório, portanto fica na responsabilidade do mantenedor do repositório avaliar e se estiver tudo correto aprovar o Pull Request. A aprovação dos Pull Requests podem ser automatizada utilizando as Actions para saber mais sobre como automatizar o Dependabot com o GitHub Actions acesse esse link
Pull request aberto pelo Dependabot
Conclusão
O Dependabot é um recurso que não podemos deixar de habilitar em nossos repositórios, é grátis, faz boa parte do trabalho sozinho e nos ajuda a manter nosso código muito mais seguro.
by Scott Muniz | May 9, 2022 | Security
This article was originally posted by the FTC. See the original article here.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
by Contributed | May 8, 2022 | Technology
This article is contributed. See the original author and article here.
This 7th of May, my colleague Paloma Garcia and I, delivered a session in Spanish “No encuentro donde esté el problema de la query” where we compare the performance in two different environments (production and staging) where our customer reported differences in execution time. In this article you could find out the link about the session recorded in Global Azure event
Abstract Spanish version
=======================
Muchas veces recibimos casos en soporte de Azure SQL Database donde nos indican que al ejecutar la query en la base de datos de producción tarda más que en la base de datos de preproducción con las mismas características de base de datos. En esta charla explicaremos una serie de pasos que seguimos para encontrar cuál es la razón de esta diferencia e intentaremos arreglar el entuerto.
Abstract English version
=======================
Many times, we received cases in Azure SQL Database support where customer noticed us that running a query on the production database takes longer than on the staging database with the same database characteristics. In this session we will explain a series of steps that we follow to find what is the reason for this difference and we will try to fix the mess.
Enjoy!
by Contributed | May 7, 2022 | Technology
This article is contributed. See the original author and article here.
Final Update: Saturday, 07 May 2022 06:09 UTCCustomers with Application Insights components in Korea South during 05/07, 03:45 UTC through 05/07, 04:30 UTC may have experienced intermittent data gaps and incorrect alert activation.- Root Cause: We determined that one of our downstream services became unhealthy.
- Incident Timeline: 45 minutes – 05/07, 03:45 UTC through 05/07, 04:30 UTC
We understand that customers rely on Application Insights as a critical service and apologize for any impact this incident caused.-Deepika
Initial Update: Saturday, 07 May 2022 04:58 UTCCustomers with Application Insights components in Korea South may experience intermittent data gaps and incorrect alert activation starting from 03:45 UTC.- Work Around: None
- Next Update: Before 05/07 10:00 UTC
We are working hard to resolve this issue and apologize for any inconvenience.-Deepika
Recent Comments