Do you know the story about the princess who saved her kingdom from a dragon? I'd be surprised if you heard of this particular fairy tale, because I invented it to teach a lesson about secure software development. In this story, a king sacrificed poor children to appease a dragon, which is not a very nice thing for a king to do. But the important part is why he thought this was a good way to save his kingdom from the dragon.
You see, as long as the dragon could eat children, it never bothered to do anything more strenuous like destroying castles or burning down villages. So the king made sure that there was always a child readily available for the dragon to eat so it wouldn't do even more damage to the villages and people of the kingdom.
The king was neither clever nor lazy by offering up children to the dragon to save the kingdom. He was pragmatic. And pragmatic is considered good in his society and, unfortunately, in software development. So we too live in a world where function comes first, and security is an afterthought and mostly reactive.
In the fairy tale, the king has a lottery to choose the next child to be the tasty treat. However, the king's daughter thinks that's unfair, and so she decides to replace all the names of the kids on the ballots to make certain she'll be picked next. Of course, the prospect of losing his daughter makes the king rethink his tactic (notice I didn't say strategy, because in this series you'll learn the difference, and why it's important to know the difference). So the king ordered his knights to hunt down the dragon and kill it.
Just to be clear, in this metaphor "feeding children to the dragon" is patching vulnerabilities in production. Finding the dragon before it eats the children or burns down villages is akin to finding vulnerabilities and fixing them during development. Which brings us to threats. The dragon is not a threat, it's a vulnerability. By focusing on the dragon as the threat and not as a vulnerability that the kingdom has, the king is employing the wrong tactic. The dragon is basically eating the resources of the kingdom. Like a software bug that eats resources (memory, bandwidth, disk space, and even security controls), the dragon needs to be discovered and removed. However, the king first tries to live with the dragon and give it the resources it needs to keep it from becoming a more damaging problem. At least until his daughter became the resource.
Now, I see what you're thinking. You still think the dragon is the threat. And maybe it is also a threat. I mean, we're talking dragons here. However, the tactics for dealing with threats and dealing with vulnerabilities are very different. You find and fix or remove vulnerabilities, which is not something you can do with threats. You often have no way to find the threat until it's too late. But you can find the vulnerability before it becomes a problem.
There's a whole set of application security tools and practices that can reduce the number of bugs that slip through QA and compilers to become a vulnerability. Things in Java like uninitialized variables and instance variables which, if they make it into production, can only be caught with live security testing. The infamous NullPointerException, when performing operations on a property that has not been initialized and points to null results, is no exception, and can leave a door open to a threat.
So the king's mistake is not that he raised a daughter with a rebellious streak and a strong sense of social justice, but that he treated his vulnerability like a threat and compensated for it. He attempted to control the dragon, letting it waste resources, rather than eliminate it when he had the chance. If it's affecting your resources, then it's a vulnerability you need to fix or remove. If you don't, your story won't end "happily ever after."
1. If the dragon is the vulnerability, then what is the princess?
2. Feeding children to the dragon to prevent further problems is a metaphor for what software development or administrative practice?
3. From the logs, you notice that some unauthorized person is pulling other people's credit card data off your public web server's database. What tactics do you apply to deal with this? Is it a threat or vulnerability?
This is the first of a blog series on secure development and application security. Whether you're a developer or security professional, check back regularly for tips and allegorical tales. And be sure to take the little quiz at the end of each post. It's there to reinforce the lesson, just like the story does. So do it or, you know, dragons.