100 Myth Busters in Cybersecurity

At the present time, the UK has a problem with some of the concrete it has used in the past. And, so, not all the concrete is unsafe — and…

100 Myth Busters in Cybersecurity

At the present time, the UK has a problem with some of the concrete it has used in the past. And, so, not all concrete is unsafe — and it is important that experts in the usage of concrete and building design carefully explain to the general public their decisions and the parameters they apply. It is not good to just to say, “All the buildings are unsafe … just rip them all down!”. Or, just because a building might fall down in 100 years, there is no need to say that it is unsafe at the current time. But, in cybersecurity, there are some who can carry this type of message to their customers — so let’s call them snake-oil salespeople in order to simplify things!

I recently heard from a company that was given the advice that 128-bit encryption could be easily cracked. It was such a generalised statement, and where, at the current time, we would have to gather all the energy — and many times more — on the planet to crack a single key.

And some people are already criticising public key encryption methods before quantum computers are even ready to go into production. I often get messages for the posting of information on RSA and ECC of “but asymmetric keys can be cracked by quantum computers”, and leave it there.

This is like saying that we should tear down every building at the current time, as we know they will fall down in the future. Like it or not, public key encryption is used in virtually every single Web connection, and without it, we could not trust anything online.

So, here’s my 100 (mostly true) casmagorical, genuinely healing, and elixirs of life for cybersecurity myth-busters:

The security of your system is often as strong as the weakest link in the chain.
Academic and professional certification normally provides surface knowledge; it is up to you to develop depth and expertise. To be an experts takes time and a serious commitment to learning. You don’t become an expert by passing an exam or taking a test.
If your answer to “explain XYZ” is “XYX stands for ..”, then you need more depth in your knowledge.
Even the best security companies get hacked.
Humans are generally good at coding but generally not very good at secure coding, and are generally not very good at testing the security of the things they have created (it’s called ‘parental love’).
Humans tire quickly when faced with complexity and often over-simplify things.
Humans tend to avoid the things they don’t like doing and spend their time on the things they like.
Just because an auditor signs something off doesn’t mean it is secure.
A risk register is not a diary but a work in progress.
Good companies know their risks and have incident response plans.
If a human does know something, they will often try to cover the facts rather than admit it to.
Most of our data and processing now exist in the public cloud.
Wherever possible, reduce surface area, build layers of abstraction and reduce complexity.
If you need to, log everything that might be of use. But remember that logs reveal sensitive data about your company.
Log information for debugging and security analysis are often different things. Beware of mixing the two.
Your logging should be layered and dynamic — ranging from full-on to full-off, and have levels in between.
Extract out single switches are parameters, e.g. logging level.
The method of creating a foothold is often different from the method used to sustain contact.
The attack method (e.g. ransomware) on a system is typically different to the access method (e.g. phishing).
Detectors for properly targeted spear phishing often do not work well.
Trust methods and not humans.
Be humble with your knowledge, and don’t overstretch yourself.
Don’t generalise things.
You can never know everything about everything in cybersecurity — no matter your education or professional certification — you will always have gaps.
You have all the theoretical knowledge of cybersecurity in the world — it often counts for little if you don’t have the hands-on knowledge.
You can have all the hands-on knowledge in the world, but it often does truly help to properly understand something without understanding the theory.
For pedagogy, cybersecurity is more psychomotor than Bloom’s taxonomy.
Assess the practice skills of graduates as much as their theoretical knowledge.
Your main adversary is typically more knowledgeable than you.
Humans are creative and sloppy and can over-simplify things.
If someone has a big enough budget, they can crack most things (but typically not the methods, but the humans).
Base judgments on peer-reviewed publications and not what Bob says.
Don’t trust publications in paper-mill journals or places that lack rigous peer review.
Don’t fully trust a paper that was submitted last Tuesday and has just been published by a journal.
Your main cybersecurity risk is often the person sitting beside you and not some person on the other side of the planet.
Usability will often trump security.
Getting code into production will often trump security.
Most systems are not designed with security in mind and see it as an add-on.
Most developers have little idea about the mathematical principles of the methods they are using.
Most developers were never trained on cryptography and have little idea about how public key encryption actually works.
Many developers have never taken a security/networking module in their academic studies.
Most of our databases are not encrypted.
If a single key is used to encrypt all of our data, then all of our data is breached on a single discovery of the key.
Cloud security is actually likely to be more secure than on-premise security, as it often guards against insiders and outsiders.
Even network engineers struggle with the concept of VLANs — the rest of the world has little chance of understanding them.
If you can, encrypt data at source, and don’t rely on network encryption.
If you can, overlay your security tunnel.
Key rotation is often healthy, but it possibly only needs to be changed on a yearly basis.
Use systems which keep copies of secret keys and do not delete instantly but give a time period for deletion.
Perform scans of our network looking for secret keys that are stored in places that they shouldn’t be.
Teach your developers that test certificates are only for testing.
When it boils down to it, cryptography often just uses simple EX-OR (add) and multiply operations that focus on a single bit at a time — and where carry-overs in calculations just don’t exist.
All our normal arithmetic operations, such as a(b+c) = a.b+ac, can be conducted using (mod p), and where p is a prime number.
Never take it for the fact that method X is unsafe just because Bob says it is. Always probe for the limits and what is meant by ‘unsafe’.
Machines are good at spotting bugs in code but not good at understanding how code actually runs in real-life systems.
Never, ever roll your own crypto. Security by obfuscation never works that well. Use key-based methods.
SSL/TLS tunnels can be broken with proxies and Web Application Firewalls (WAFs).
A software proxy on your computer is able to examine traffic before it is sent over SSL/TLS.
Generally, encryption methods are mathematically secure; it is the implementation by human slaves that is often the problem.
The SHA-1 hash (160 bits) is still generally fairly safe at the current time for collisions but is not recommended.
With MD5, we have 170 billion, billion, billion, billion possible hash values. Finding a hash collision is highly probable in a relatively short period of time — and costs less than $10.
With MD5, it is relatively inexpensive to find three data inputs which give the same hash value.
Anything greater than a random 72-bit nonce or salt value is generally safe against brute force attacks where the salt value is unknown.
The salt value is typically stored with a hashed password, so although rainbow tables cannot be used, we can use a dictionary attack on the hashed value (but taking common words and adding the salt).
Salted hashed passwords generally take the salt value and add it to the start or the end of the password before it is hashed.
A nonce, salt or IV in symmetric key encryption is generally added into the process (and not added to the input data). The salt must always be retained.
Digital security is all about encryption — integrity, authorization, and trustworthiness are just as important.
Symmetric key, asymmetric key and one-way hashing methods are different things and have different roles.
It is almost impossible to ever get a collision with SHA-256 as there are 115,792 billion, billion, billion, billion, billion, billion, billion, billion different hash values.
We generally lose around 1 bit of security every 12–18 months (due to Moore’s Law).
Generally, anything below 72-bit security could be feasiblity cracked with brute force at a reasonable cost.
If we follow Moore’s Law and lose one bit of security each year. It would take 56 years for 128-bit encryption to be crackable.
ECC does encrypt data. It is typically used for key exchange and digital signatures.
RSA can encrypt data, but it has significant overhead, so it is typically just used to encrypt small amounts of data, such as encryption keys.
Generally, 512-bit RSA is unsafe, but 1K RSA is much more expensive to crack and at the limits of our current cracking.
RSA can sign data but is not used in key exchange.
The private key of a public key pair should always be protected by a strong password and/or multi-factor authentication.
For the best security, the private key of a public key pair should only exist in an HSM (Hardware Security Module) or a secure enclave.
Backups of private keys should always have strong security applied.
We hardly ever use discrete logs anymore for key exchange (DH) or digital signatures (DSA).
Adi Shamir’s secret share method is provable and secure. For an any 5-from-8 sharing system, you cannot reconstruct with four shares.
If you want perfect security — use a one-time pad — but it’s not going to be easy to do that, as you will have to create a new pad for every cipher.
256-bit ECC generally gives 128-bit symmetric key-level security.
A 2K modulus for RSA is generally safe at the current time for cracking.
Randomly generated keys are almost impossible to crack at the current time.
Https does not rely on one security mechanism — it was two: key exchange and digital signing. One sets up the security of the connection and the other defines the trustworthiness of the server.
Digital certificates are not magical pixie dust that only the fairies can understand — they just contain a trusted public key of an entity.
A trusted entity signs a digital certificate with its private key — a leak of that key will cause all of the certificates signed by it to be untrusted.
The DES method of using a Fiestal cipher is generally still security — it is the key size that is the problem. Generally, the 56-bit key used can be fairly easily cracked with brute force, but the 112-bit key used in 3DES is generally secure (but not recommended) at the current time.
ECDSA signatures are safe at the current time as long as a random nonce value is used for each signature and then never used again or revealed.
The cost of cracking a cipher or hash is typically measured in the time taken by a cloud-based GPU cluster to perform and relates directly to the amount of energy consumed.
Most hashing methods use a salt value for the hash, and so rainbow table attacks are mostly a thing of the past.
256-bit symmetric key encryption is generally safe from the rise of quantum computers.
Wi-fi password cracking is extremely difficult with a secure password, as we capture the PBKDF2 on registration, and it is extremely costly to crack for a strong password.
256-bit hashing is generally safe from the rise of quantum computers.
The security of a key cannot be generated with the number of bits that it has, as it all depends on the key entropy — and this relates to the number of possible keys that are likely to be generated.
Passwords shouldn’t be stored with a generalised hashing method — a KDF (Key Derivation Function) should be used.
MACs (Message Authentication Codes) require Bob and Alice to share the same secret. If Eve finds out the secret, she can send trusted messages.
Hardware and software tokens use the signing of a message to prove the ownership of a secret key — this can be with public key signing or use a MAC method.
The private key of a public key pair is used to create a digital signature.

And how do you stop becoming an oil-snake salesperson? Go learn, and develop a deeper understanding of how things actually work:

https://asecuritysite.com