Propósito

✔ Programação GLOBAL® - Quaisquer soluções e/ou desenvolvimento de aplicações pessoais, ou da empresa, que não constem neste Blog devem ser tratados como consultoria freelance. Queiram contatar-nos: brazilsalesforceeffectiveness@gmail.com | ESTE BLOG NÃO SE RESPONSABILIZA POR QUAISQUER DANOS PROVENIENTES DO USO DOS CÓDIGOS AQUI POSTADOS EM APLICAÇÕES PESSOAIS OU DE TERCEIROS.

Segurança Através de Obscuridade vs. Segurança Através de Transparência

Segurança Através de Obscuridade vs. Segurança Através de Transparência
#ProgramaçãoGlobal #AuditoriaSeguranca #CibersegurancaBestPractices #CodAberto #DesenvolvimentoSeguro #GestaoVulnerabilidades #ProcessoRevisao #Segurancasoftware #TransparenciaSeguranca #TSMC #Samsung #Intel #ASML #EUV


DOE UM CAFÉ


 Compre OS LIVROS DESTA SÉRIE 



VULNERABILIDADES ESTRUTURAIS NA INFRAESTRUTURA CRÍTICA DIGITAL GLOBAL: ANÁLISE DE DEPENDÊNCIAS SISTÊMICAS E RISCOS ASSOCIADOS


O debate clássico em segurança cibernética opõe "security through obscurity" (proteção através do sigilo) contra "security through transparency" (proteção através de transparência). O pessoal do software proprietário frequentemente argumenta que segredando código-fonte, vulnerabilidades são protegidas de malfeitores, conforme citamos no artigo original. E o pessoal do open source contra-argumenta que transparência permite descoberta e correção rápida de vulnerabilidades.


Incidentes como o do xz Utils torna este debate mais complexo. Por um lado, a vulnerabilidade foi descoberta porque a comunidade open source estava examinando código. Por outro lado, a vulnerabilidade permaneceu em código aberto durante TRÊS ANOS sem ser detectada, sugerindo que simplicidade de "many eyes" olhando para código não garante segurança. Jia Tan foi capaz de explorar confiança e gradualismo em inserção de código malicioso, contornando revisão de código.


Estudo de 2012 por Cavusoglu, Cavusoglu e Zhang publicado em IEEE Transactions on Software Engineering analisou histórico de vulnerabilidades em software open source versus proprietário. Conclusão foi surpreendente: ambas categorias apresentam vulnerabilidades críticas em proporções similares. Contudo, tempo para correção foi substancialmente menor em software open source, sugerindo que transparência acelera correção mesmo que não previna descoberta inicial.


O debate deveria evoluir de "transparência vs. sigilo" para "transparência com revisão rigorosa vs. sigilo sem revisão adequada." O Software proprietário que não for auditado por terceiros independentes frequentemente carrega vulnerabilidades desconhecidas. Software open source sem processo de revisão de código robusto também é vulnerável. A variável crítica é processo de revisão, não apenas abertura de código.


Sim, nós sabemos, nós sabemos, nós sabemos…


Ver essa mensagem é irritante. Sabemos disso. (Imagine como é escrevê-la...). Mas também é extremamente importante. Um dos maiores trunfos do ✔ Brazil SFE® é seu modelo parcialmente financiado pelos leitores. 


1. O financiamento dos leitores significa que podemos cobrir o que quisermos. Não sujeitos a caprichos de um proprietário bilionário. Ninguém pode nos dizer o que não dizer ou o que não reportar.


2. O financiamento dos leitores significa que não precisamos correr atrás de cliques e tráfego. Não buscamos desesperadamente a sua atenção por si só: buscamos as histórias que nossa equipe editorial considera importantes e que merecem o seu tempo.


3. O financiamento dos leitores significa que podemos manter nosso blog aberto, permitindo que o maior número possível de pessoas leia artigos de qualidade do mundo todo.


O apoio de leitores como você torna tudo isso possível. No momento, apenas 2,4% dos nossos leitores regulares ajudam a financiar nosso trabalho. Se você quer ajudar a proteger nossa independência editorial, considere juntar-se a nós hoje mesmo.


Valorizamos qualquer quantia que possa nos dar, mas apoiar mensalmente é o que causa maior impacto, permitindo um investimento maior em nosso trabalho mais crucial e destemido, assim esperamos que considere apoiar-nos. Obrigado!

👉 Siga André Bernardes no LinkedinClique aqui e contate-me via What's App.

Comente e compartilhe este artigo!

brazilsalesforceeffectiveness@gmail.com


 

 Compre OS LIVROS DESTA SÉRIE 

 Série Donut Project 
DONUT PROJECT: VBA - Projetos e Códigos de Visual Basic for Applications (Visual Basic For Apllication)eBook - DONUT PROJECT 2024 - Volume 03 - Funções Financeiras - André Luiz Bernardes eBook - DONUT PROJECT 2024 - Volume 02 - Conectando Banco de Dados - André Luiz Bernardes eBook - DONUT PROJECT 2024 - Volume 01 - André Luiz Bernardes


eBook - PT - Série DONUT PROJECT - Volume 07 - VBA TOP 50 Códigos Mais Importantes - Access — André Luiz BernardeseBook - PT - Série DONUT PROJECT - Volume 07 - VBA TOP 50 Códigos Mais Importantes - Excel — André Luiz Bernardes eBook - PT - Série DONUT PROJECT - Volume 07 - VBA TOP 50 Códigos Mais Importantes - Outlook — André Luiz Bernardes eBook - PT - Série DONUT PROJECT - Volume 08 - VBA TOP 50 Códigos Mais Importantes - Project — André Luiz Bernardes  eBook - PT - Série DONUT PROJECT - Volume 08 - VBA TOP 50 Códigos Mais Importantes - Project — André Luiz Bernardes  eBook - PT - Série DONUT PROJECT - Volume 08 - VBA TOP 50 Códigos Mais Importantes - Word — André Luiz Bernardes

Nenhum comentário:

Postar um comentário

diHITT - Notícias