Jen's Take On The Three Little Pigs...and Insecure Design

“A new category for 2021 focuses on risks related to design and architectural flaws, with a call for more use of threat modeling, secure design patterns, and reference architectures.” - OWASP

The Wolf loves an insecure design that he can huff and puff and blow

down. What is it and how can we prevent it? Let’s learn more together

about this topic!

“Little pig! Little pig! Let me in!” – The Wolf

“No, no, no! Not by the hairs of my chinny chin chin.” – All Three Little

Pigs

Insecure design stems from decisions made during the design phase for software or a system and its architecture. It exposes us to security weaknesses. Not good.

A lot of damage can be caused by an insecure design. Insecure design is the backbone of everything in the application. It exposes the organization to flaws, whether it’s data breaches causing a lack of trust and reputational damage, granting role access to the wolves, err, the bad guys, and causing a service disruption leading to financial losses or downtime, or legal repercussions, just to name a few. ”Secure design is neither an add-on nor a tool that you can add to software.” (owasp.org)

Like a home, if you don’t have a good foundation, the house is at risk for being blown down by a wolf, or in this case, a bad actor.

The next day, a wolf happened to pass by the lane where the three little pigs lived, and he saw the straw house, and he smelled the pigs inside. He thought the pig would make a mighty fine meal, and his mouth began to water.

The first little built his house out of straw.

The second little pig built his house out of sticks.

Then, they sang and danced and played together the rest of the day.

How do we get an insecure design? We get an insecure design by not thinking of the business risk BEFORE developing the solution/application. It might be time constraints and we choose to build our “house of straw”. It might be lax

security roles, and we choose to use “sticks as building material”.

Here are just a few ways that our solution could be compromised:

• Account takeover

• Accessing any environment and exploiting it

• Execute other attacks (cross-site scripting, path traversal, etc.)

• Modifying URL parameters

• Mining sensitive information about our account holders

• Bypassing authentication mechanisms, using legitimate accounts, and exploiting the system via password-protected resources

Either way, we’re talking about damage to our reputation if data was leaked and numerous hours of cleanup work to recover from the attack.

What are some common types of vulnerabilities that happen because of an insecure design:

• Improper privilege management

• Insufficiently protected credentials

• Unrestricted upload of file with dangerous type

• Trust boundary violation

• Generation of an error message containing sensitive information

• Improper restriction of rendered UI layers or frames

• External control of assumed-immutable web parameter

• Plaintext storage of a password

• Clear-text storage of sensitive information

• Lack of encryption of sensitive data

• Gaining administrative access to a system

• Weak authentication or improper access controls

• Code injections via input validation

• Not using SSL or TLS for transmitting data back and forth

We should always expect attacks. Threat actors are getting smarter every day and finding new ways to break into our applications and wreak havoc. Stay paranoid.

When should we consider secure design concepts when working on our applications? From the very beginning! If you haven’t taken secure design principles into account before the start of the design phase of the product lifecycle then you are at a higher risk.

The third little pig worked hard all day and built his house with bricks. It was a

sturdy house, complete with a fine fireplace and chimney. It looked like it could

withstand the strongest winds.

It was a secure design.

What if we’re past the design phase? You can utilize security tools to help identify vulnerabilities. Has the supporting documentation been kept up to date?

That will help the next team touching that code and can verify if the design is secure or needs to be refactored. Either way, you can still implement secure design concepts during new feature development and maintenance

phases of your application.

• Increase security by reducing the risk of vulnerability-opening mistakes—even though the design principles used were not originally conceived for security purposes

• Avoid security through obscurity. The idea is to generally keep secret the structure. However, to avoid it, have many sets of eyes on the code, which will help catch more vulnerabilities.

• Another way is working with the principle of least privilege. You only get access to what you truly need access to.

“Then I’ll huff, and I’ll puff, and I’ll blow your house down.” – The Wolf

Well! He huffed and he puffed. He puffed and he huffed.

And he huffed, huffed, and he puffed, puffed; but he could

not blow the house down. At last, he was so out of breath

that he couldn't huff and he couldn't puff anymore.

How can we prevent insecure design? As previously mentioned, it’s best to start with a secure design. Even so, it’s best to use security tools and stay up-to-date on vulnerabilities that could impact your system.

• Ask the important questions like a paranoid detective: What is worth protecting, and which shiny thing will attract wolves? Lock down the crown jewels first, then pretend everyone else is a suspiciously enthusiastic intern. Use threat modeling also for critical authentication, access control, business logic, and key flows. Assess every feature and every component.

• Integrate checks at each tier of your application (from frontend to backend).

• Penetration testing. Bring in ethical troublemakers to try huffing and puffing at your walls. If they can blow a hole in it, congratulations — you just found something to fix before a real wolf does.

• Schedule regular scans so security issues get caught while they’re still cute and fixable, not after they’ve grown into full-blown incidents that require metric tons of caffeine to fix.

• Filter all output. Sanitize everything your app says into the wild. No verbose error message, and watch what you log!

• When writing user stories, really define the use cases. Also, take the time to define the unsavory use cases. Try to break things.

• You should also define any security rules, checks and balances, and any necessary access controls. This will help with testing. Integrate security language and controls into user stories.

• Test your code! A bug that seems minuscule can put the application at risk and provide the perfect portal for threat actors to hack in and infect our “home” like termites.

• Write unit and integration tests to validate that all critical flows are resistant to the threat model. Compile use-cases and misuse-cases for each tier of your application.

• Pretend to be a malicious threat actor when testing. THINK LIKE A HACKER. Wear the hoodie if you feel like it. This can uncover additional security needs and assess the vulnerabilities and risks. It also allows for reprioritization for security improvements. Yes, it might slow down a feature, but tell me which is better...slowing down a feature and doing it right or taking a risk and slowing down business for the entire company?

• Rely on a library of secure design patterns.

This is not an all-inclusive list, but it’s a start. You cannot fix an insecure design by a perfect implementation. Remember, the key to secure design is to prepare with prevention and not just the treatment.

But this was too much.

The wolf danced about with rage and swore he would come down the chimney and eat up the little pig for his supper.

But while he was climbing on to the roof the little pig made up a blazing fire and put on a big pot full of water to boil.

Then, just as the wolf was coming down the chimney, the little piggy pulled off the lid, and plop! In fell the wolf into the scalding water.

So the little piggy put on the cover again, boiled the wolf up, and the three little pigs ate him for supper.

And that, kids, is the story of the Three Little Pigs and Their Insecure Design.