Esta lista de vulnerabilidades es una referencia clave en la industria de seguridad informática y conlleva una actualización que es importante que conozcamos quienes estamos involucrados en ella.
Particularmente una de las cosas que llama la atención es la inclusión de una categoría denominada A02: Cryptographic Failures. Esta categoría incluye los debilidades ( CWE ) asociadas a fallas criptográficas ya sea por problemas en las configuraciones o en las implementaciones de la criptografía en las aplicaciones. Entre ellas destacan:
Debilidad en las contraseñas.
Intercambio de llaves criptográficas sin autenticación.
Nivel de entropía insuficiente.
Problemas en la generación de datos pseudoaleatorios.
Transmisión de información sensible en claro.
entre muchos otros.
… seguramente estaré platicando de algunas en el transcurso de los días.
La lista actualizada de vulnerabilidades quedó de la siguiente forma:
A01:2021-Broken Access Control
A06:2021-Vulnerable and Outdated Components
A07:2021-Identification and Authentication Failures
A08:2021-Software and Data Integrity Failures
A09:2021-Security Logging and Monitoring Failures
A10:2021-Server-Side Request Forgery
El enlace oficial y toda la documentación la encuentran directamente en el portal de OWASP.org Top 10.
A friendly reminder just to make sure you are ready for the new lifetime on TLS digital certificates of a maximum of 398 days starting september this year.
What does it mean?
Every certificate issued by a public CA on or after September 1st, 2020, must have a maximum lifetime of 398 days to be trusted by web browsers.
The number of days will be taken from two attributes already present on all certificates: notBefore and notAfter.
All major browsers are preparing and releasing their new versions to support this change.
What are the benefits ?
The first benefit is in fact an increase on the security for web resources served under HTTPS decreasing the number of active days a cryptographic private key will have.
A second benefit is the one regarding crypto agility. A new fancy way to describe how prepared you are to change cryptographic algorithms, schemes or protocols when there is a major vulnerability which forces to deprecate rapidly any of them.
What impact could I have ?
If you already have valid Digital Certificates with an expiration date on September after September or even next year, you will have no impact on them, everything will continue to function as normal, but starting September 1st 2020, if you request a new certificate, renew or reissue an existing certificate, the new maximum expiration date will be of 398 days beginning on the day the certificate is issued (or reissued). So you will not be able to have a valid certificate for 18 months or 2-3 years as before when the validation period starts on of after September.
If for any reason a public CA issues a certificate with an expiration date of more than 398 days and you install it on your servers, all users or customers will receive an error saying the website is not secure and there is an error trying to access the website. Similar to when you are trying to access a website with a self-signed certificate installed or with a different common name in it.
This extraordinary guideline was written in collaboration with Digicert, Venafi, Thales, F5, MITRE, Symantec. All of them well known technology and security companies around the world.
The document has 4 different parts:
An Executive Summary
Security Risks and Recommended Best Practices
Approach, Architecture and Security Characteristics
This is a must for the administration of large-scale TLS server certificates, how to establish a formal TLS certificate management program and it also enumerates all elements that should be considered for inclusion in such a program.
It addresses some specific challenges like: The automatic renewal of digital certificates in production environments, working with DevOps and TLS certificates, implementing an architecture to be protected of attacks hidden in TLS connection tunnels, recommendations for key-lenght, signing algorithms, validity periods in digital certificates, recommendation for crypto-agility (a very popular topic in cryptography these days) and much more.
You can download the complete document directly from its site:
Recently I have been testing this tool when I work with Java Key Stores or Trust Stores. It’s KeyStore Explorer.
You can always use command line to execute cryptographic tasks in java using keytool library or bouncy castle, however for many daily activities like generating CSR files, creating cryptographic keys or managing several keystores or trust stores, you prefer a more friendly tool. This is where KeyStore Explorer fits in.
It’s support for cryptographic tasks, according to it’s website, is:
And you can handle, compare and manage many keystore files from the main window and explore their content easily:
There are many new technologies, controls, mechanisms, modules, libraries for protecting and securing assets and information. Usually these new technologies were created and developed by people with good skills in the field, however, one of the main problems is the implementation phase.
Believe it or not, most of the vulnerabilities, either published or zero-day, exist because of a bad or terrible implementation of something that is secure in escense.
Think about cryptography. In general, cryptographic standard algorithms are approved and validated by many cryptographers around the world but when it comes the implementation phase, the standard or algorithm is implemented by a group of peole working at the same company or sometimes by only one developer with limited training in security and/or cryptography.
One of these examples is WEP Security Protocol for Wireless communications. It has different vulnerabilities but particularly the vulnerability of the key stream is a consequence of a weakness in the implementation of the RC4 stream cipher, not the RC4 algorithm by itself.
On Internet, when protecting sensitive data, in transit you must use the security protocols you’ve heard of, like HTTPS, SSH, SFTP, FTP/S, TLS, VPN, IPSec and more, however, using only these protocols is not enough when following methodologies like “defense at depth”, where you need more security layers to tackle most of the threats and risks regarding data exposure when sending or receiving data.
In this post I will talk about recommendations you can follow to increase the level of security of critical and sensitive data while transmiting data anywhere, from internal networks to public or insecure networks.