Once upon a time, there was a father reading fairy tales to his children. It so happens that the father was a security engineer and penetration tester by trade. And sure enough, he could not but notice those foolish goats breaking not just one but several core security concepts! Inevitably they got into serious trouble for doing so – they got eaten by the big, black wolf.
Since the father also happens to be an author for Coder’s Kitchen, he decided to compose a short and (hopefully lighthearted) article about core security concepts everyone should have heard about. So that you all can better keep your young goats (or other secure systems of concern) safe from the evil wolves out there.
The wolf and seven young goats: A fairy tale of bad security practices
For those few of you who do not know (or do not properly remember) the particular fairy tale, I will quickly narrate the important pieces but you can read it in full here if you like.
Once upon a time, there was a mother goat and her seven young goats. And it happened that the mother had to leave the young ones to get some food. She told the young goats to beware and only open the door for her and not the evil wolf who may try to disguise himself. She also told them that the wolf is easy to discern by his rough voice and black paws. Then she left.
The wolf arrives – to (cyber-) attack some goats
Soon enough, the wolf came to the house. He asks them to let him in – naturally. But the young goats noticed his rough voice and told him: “You are not our mother for she has a soft voice. Go away wolf!” And so the wolf went away.
The wolf returned after having eaten some chalk to soften his voice. I have some doubts about this, kids do not try this at home!
Once again, he asks the goats to let him in. This time however, the young goats noticed the black paw and told him: “You are not our mother for she has white feet!” And so the wolf went away.
He returned a final time, after having bullied the baker into showering his feet with flour to make them white. A final time he asks them to let him in. This time, he has a soft voice and white feet as well. And so, the young goats let him in.
Oh-oh.
Unsurprisingly, the wolf immediately began rounding up the young goats for a proper snacking, despite them trying their best to scatter and hide themselves. The wolf found six out of the seven and ate them all before leaving to have a nice nap.
What a lovely day – for him.
Mother goat return – to a serious security incident
As the mother returned, she found the house with an open door and no goats in sight! That is pretty dark.
She was calling out for her young goats by name and only when she reached the last, youngest one, did he reveal himself.
The youngest has hidden himself in the clock case. It told the mother goat all about the wolf and his siblings.
What a debacle…
The fairy-tale ends with a series of (pretty disturbing) shenanigans of mother goat, which sees the young goats saved and the wolf drowned in a well. The details of that last section need not concern us for the sake of this article, however.
And they lived happily ever after… (well, the goats do, the wolf is pretty dead).
Security concepts gleaned from the fairy tale
Interestingly, we can learn a good handful of important security lessons from the follies (and prudence) of those fairy-tale goats. Let us have a quick overview before going over each one in turn and some (limited) detail, shall we?
The many follies of the goats
- Mother goat chose weak authentication criteria (“smooth voice” and “white feet”)
- The authentication criteria were (apparently) easy to forge
- They never tested how the young goats react to an attempted intrusion.
- The young goats told the wolf exactly how they knew it was him and not the mother
The one good thing
While the goats did make a lot of (grave) mistakes, they also did get one thing right. When the wolf gained entry, they scattered and hid themselves, allowing one of their number to escape the wolf and tell the mother goat what happened. This enabled the happy ending of the fairy tale, as the mother goat was able to rescue the other six missing young goats.
Or in other (IT) words: the goats have a redundant, distributed system with backups and (useful) event logs (seven young goats, not just one) as well as an incident response plan (“scatter and hide”).
Security concept 1: The weakest link
The house of the goats apparently is very secure. Unless the door is opened from within of course. That is why the wolf does attempt to trick the young goats into opening the door rather than trying to break it open. The young goats are only as secure as their ability to discern the wolf from the mother goat. This is a perfect example of the principle of weakest link.
To be the weakest link in a chain
In short, a system is only as secure as its least secure element – just as the weakest link in a chain will determine when the entire chain breaks.
Example: Let us consider a password protected file.
For such a task the AES algorithm is the obvious choice. It is the industry standard and widely available and also very secure.
As far as we know.
But choosing a weak password will seriously reduce the security rating.
To the point of uselessness.
For example, should we use a five character password, an attacker simply could brute-force guess it on an average laptop within a couple of minutes. No need whatsoever to try and break the AES algorithm or even search for implementation weaknesses.
Need another example? Let us consider a car.
It has quite a few micro-controllers that control its engine, breaks, ABS, whathaveyou. Now, the old model of the car does not have any fancy connectivity features. Everything is wired within the car chassis and thus (kinda) hard to reach for an average remote attacker.
Recently though, the car is getting a new version. Including a head unit stuffed with fancy, “smart” features, including an internet connection, WiFi, Bluetooth, all the buzz and then some. It runs on a hastily coupled together Linux or android variant and is connected to most of the same “old school” micro-controllers.
Surprisingly, the car still needs to drive and why develop the same feature twice, right?
But what have we now?
A system of several dozen vulnerable, safety critical subsystems connected to an ill tested edge node.
Which is readily addressable via the internet.
Would you want to drive such a car?
Security concept 2: Strong authentication criteria
Mother goat told the young two criteria with which to discern the wolf and not let him in: the course voice and the black foot. First of all, using a blacklist in such a situation is a very bad idea. What would have happened if a hungry bear would come along rather than the wolf? Or a hungry farmer?
Mother goat should really have used a whitelist, describing herself and telling them to not let anyone else in. This brings us to the second and even more pressing issue. The criteria themselves are weak and not even close to being restrictive enough. What if the wolf was a grizzled, old one with greying, white fur?
Multi-factor authentication
But hey, mother goat was using two-factor authentication (2FA) – isn’t that very secure?
It is – if it is well done. And also if your users are mindful of phishing attempts. A big issue here is the use of two similar factors. Both are biometric in nature (voice and foot color). And both can be readily forged, as shown by the wolf eating chalk and flouring his feet. Proper 2FA will use two very different factors, typically one relying on (secret) knowledge and one possession or biometric. Examples are a password (knowledge) plus a digital certificate or hardware token (possession) or a fingerprint (biometric).
In the fairy tale, mother goat could have carried with her something unique from the household (maybe a cup made by the young goats?) to show in addition to her soft voice. Or she and the young goats could have come up with some kind of passphrase only she would get right?
Security concept 3: Beware of error and debug messages
Maybe the biggest folly of all, was the young goats telling the wolf exactly how they knew it was him.
This blunder allowed the wolf to adapt and overcome each authentication factor in turn.
That is like a “Forgot your password?” feature that just signs you in after changing “your” password without sending a reset link to the email address.
Verbose error messages are very useful for development, no doubt about that. But they have no place in a live secure system, as they can be used as a side-channel by an attacker to better steer his attacks. Yet, it commonly happens. So common in fact, that there is a CWE describing just such a thing. CWE, if you wonder, stands for Common Weakness Enumeration: basically a list of common security pitfalls. You can consider it as a condensed, generalized, and summarized encyclopedia, created from the many CVE (Common Vulnerability and Exposures) found in actual software. And of course, a handful of actual vulnerabilities stemming from such an oversight.
Do note that I am not advising against having good and proper error reporting. Rather, you should be very mindful of how and to whom you report those error messages. Writing them into a local log file is (probably, depending on your threat scenario) fine. But putting them into an HTML response or otherwise displaying it openly to a potential attacker might be a very bad idea.
Side-channel attacks
Attacks exploiting some kind of side-channel are well-known and a frequent source for CVEs. The classic side-channels are timing, energy consumption, electromagnetic emission and sound. Timing-related attacks are the easiest to achieve and most widely exploited, as most other side channels require close proximity to the target. They are also a right and proper topic all by themselves – maybe I will get around to write something about those at some point in the future.
Just know, that even if your security algorithm and protocols are well chosen and used as intended, their implementations may be susceptible to attacks. Even if they are correct. I’ll just leave the obligatory “don’t implement your own crypto” statement here. It’s hard and you are practically guaranteed to get some minute detail wrong. You do remember the weakest link, don’t you?
Security concept 4: Use secure logging and distributed backups
The one thing saving the goats from a complete disaster was the fact that one young goat managed to successfully hide from the wolf and report back to mother goat.
What we see here, is the effect of good logging (the young goat telling the mother what happened) and backup.
Having such a “doomsday plan” is vital. Because there is no such thing as 100% security – and everyone telling you otherwise is either unprofessional, limiting the scope, or trying to sell you some snake oil.
Thus, having a well thought-out incident response and backup-and-recovery plan is absolutely inevitable. It will enable you to recuperate from a security incident in a matter of days – at most. Whereas getting hit from a cyber attack without a good plan, may very well be the end of you – or at least the end of your little goats.
Security concept 5: Test your security thoroughly
Another major folly of mother goat was to never actually test how her young will behave.
After all, the young goats may have simply opened the door for anyone asking them nicely. Or forget the factors they were told to look out for. If she had done a quick test run, she may also have noticed that the goats were telling how they noticed something was off – which was later to (very nearly) doom them all.
As with any other feature: that which is not tested will not work. And this is even worse for security.
Testing a secure system
Obviously, you need to do functional testing, as you do for any piece of software you write, right?
But that is just the tip of the proverbial iceberg.
Before you actually write a single piece of your secure system, you should actually start by putting together a proper plan about how to actually achieve a secure system.
That is, you will want to design a secure system from the ground up. You want to be secure by design.
Because “tagging-on” security as an afterthought at the end of your development cycle … really does not work.
It was and still is tried.
Repeatedly.
And it did not work.
Like ever.
Security is just too disruptive, as it slices through all layers and components.
As part of such a secure design, you will be creating a threat and risk analysis (TARA or TRA). Not only is such a document required by various legal requirements (ISO 21434, UNECE R.155, R.156, as well as the developing EU cybersecurity act) but it really helps to think methodically about the requirements for a system’s security and thus guide design and implementation decisions.
During the development of your secure system, you will also have to do robustness testing (e.g. by using Fuzzing).
This is to check that you did not introduce any vulnerabilities in the process of trying to make the system secure.
After all, if the implementation of your secure communication stack is vulnerable, an attacker will not even try to circumvent any kind of authentication measures – he would just walk right in through the front door that does not properly close.
And once you have done all that, you should find an experienced penetration tester for a good and proper shakedown of your system. Much better he identifies the weak link of your system, than a real attacker. Also much cheaper compared to dealing with a real incident.
Mother goat could (and really should) have asked the friendly shepherd’s dog of the neighborhood to come by and seek entry while she was “gone” to test her security measures.
The end: Keep your goats secure
As usual, when it comes to security, it is important for everyone involved (from developers to system architects and management) to get into the “security mindset”. That is obviously a process, which will not happen overnight.
But making people aware of the reasons and concepts that are important to make a secure system happen is the most important (first) step.
I hope you enjoyed my little story-time about some of the core security concepts and how some foolish goats failed to adhere to them to their detriment.
