37C3 - Writing secure software

using my blog as example

I have previously given talks about security principles and approaches like Least Privilege, TCB Minimization, and Self Sandboxing. The most frequent feedback has been "I don't know how to apply this in practice". So, in this talk, I will show how I applied those principles in a real-world software project: a CRUD web app. My blog.

I introduced dangerous attack surface on purpose so I could some day give a talk about how to apply these techniques to reduce risk. This is that talk.

I will also introduce the concept of append-only data storage.

The end goal of this talk is to show how much more security you can achieve if you don't take an existing architecture and try to sprinkle security over it, but you make architectural decisions with security in mind.

This is rarely done in practice because there is a fundamental disagreement between security and software engineering. Security is about limiting what can be done with the software, while software engineering is about not limiting what can be done with the software.

My goal with this talk is to show what kind of security gains are possible architecturally. You, too, can sleep soundly at night. Even if the software is written in C. Even if you have bad ACLs or a buffer overflow in the software.

Fefe

#37c3 #Security

[capability-snob]

Don't add security - remove insecurity.
The strategy here is Principle Of Least Privilege + isolation by default, which is the first step in the path to Capability Theory. The talk mentions Sandstorm, which is a pretty solid capability system, the security model exposed to applications in sandstorm is a lot more powerful than what POSIX exposes

[adrasx]

Just a side node. From a security perspective there's no user input. There's only hacker input

[lovealien]

So fefe is keeping his tiny application more or less secure, but what do I do with those behemoths of hundreds of megabytes of compressed java code that people want to use?
Is it even possible to fulfill these needs with tiny more or less secure applications?
The situation reminds me a bit of those proofs of program correctness. Who can afford these for non tiny programs except for some extraordinary projects?

[unixerius]

"Threat modeling sounds like a dirty word, like there's effort involved." I've had lots of fun with dev teams, teaching them about threat modeling and doing guided sessions with them... Even the cynical team members eventually join in and start seeing the fun in the process.

[Hapkumdo]

Seems like the "What does the industry do" slides were mainly added, so Fefe could have a quick laugh between slides :)

[computer_toucher]

I, too, knew what company the "Password Management" bit was about before he said it. I can't believe they're still in business after all their f-ups.

[jacyjung]

My approach to writing secure software would be the total opposite. Use as much open source software as possible that is already used and maintained. Refrain from rewriting anything that has been already done and is audited by the open source community. Like a webserver, an ldap server. The probability that you forget something in your own "threat model" when you do this on your own is far more likely than something that is already battle-tested. This way you only get more obscurity, not security.
Second, having a modular approach is more maintainable. What if the developer that knows this very hand-crafted specific architecture is gone? What if a quick fix is needed, that would be easily available by updating a dependency, but here you have the responsibility in-house. Do you always want that responsibility? And then you need a new feature and you think you just give the process a tiny bit more permission and suddenly a big hole at the other end of the threat model opens.
If you want to do that, I would much rather spend the time on applying the "threat model" to an existing open source package and by that even give back something to the community.

[Hydroxytryptophan]

The irony: generating static HTML is "cool" again.
Serving static content via a well-proven minimalist web server should be as secure as it gets, and even if an attacker gets in, there is pretty much only static content.

The point of the talk is to keep your stack/software as lean as possible for what your software has to archive, but then he "bloats" it with a dynamic architecture and LDAP.
However, most of the points are still valid.

[patt]

There was an open source project mentioned which is about running open source projects securely. What was the name ? I can’t find it.

[plebius]

So what you do first. Is you write it down. Then you set that on fire. Now with recent development's people can retrieve back information for ash. So next we are going to get the ash and place it in a blender with about 7ml of vinegar. (We wont use something stronger as you may want a margarita after. ) Turn it on and blend into a mush. Now we want to make sure that no one can retrieve this in the future either, and we don't know how advancements will go. So get 10 cans of tuna. Place into large bowl and mix ash/vinegar mulch. Stir vigorously. Now bring said mixture to your local cattery. Give as treat.

And this is how I ended up on a watchlist.

[MaxJones]

Dear comment section: take this talk with a bit more humor.

[camelotenglishtuition]

Loved this talk, his sarcasm is amazing! lol

[niklas]

I personally didn't like this talk.

1. Password Manager was hacked => Ha ha, use SSH keys. Well, until every website in exists allows for login with my ssh keypair I think you'll have to stick with using passwords (and therefore, a password manager).
2. Writing anything yourself actually isn't the smartest solution. Of course, bloatware and unnecessary software should be avoided, but in general I'd say that there is a good chance that the popular, open-source solution with code audits is more secure than the thing you hacked together. And that's not to criticise your skill in any way, but just because you wrote it yourself (and therefore you know of no vulnerabilities) doesn't mean that it doesn't have any.
3. Your example is a bit far away from the reality of software development. Sure, we should always think about minimising attack surface etc., but I feel like there is no bigger takeaway than this in your talk.
4. I personally didn't like your style of presenting. You spoke with such high confidence that it seemed condescending to me, especially when you put "the industry doing hilarious, dumb things" and you "being smart, doing everything yourself" that much in contrast.

I'd be really happy to see another security talk from you, but please be more constructive next time and give advice which can actually be generalized.

[aaronr.]

20:40 instead of maintaining own journal maybe btrfs snapshots ??

[jlf_]

Expected way better. A little disappointed. Yes, the industry is full of blostware, but this talk was just not it.

[MazeFrame]

The comments down here explain why "security - no even nice to have" is the accepted state of the world.

[JonnnyBeeGod]

Shame he couldn’t answer the last question

[ACuteAura]

ahh fefe. unhinged ranting, ignoring all surrounding complexity. you mean a blog you spent years hardening for fun has less attack surface than a company that has to run a whole lot more software, some of which they don't control, and with a market filled with developers less senior that are expected to deliver on a timeline? shock.

why do you invite this dude again, this is such a boring preachy talk.

[weichslgartner]

Rewrite everything from scratch in memory unsafe C is the way to write secure software?

[svenstarson]

Calling for waterfall development methology and bashing on agile as being a root-cause for insecure software devaluates the parts of the talk that are spot on. My eyebrows were already raised, when he mentioned "the old days" and implied that these were "the GOOD old days", which is usually "hindsight biased". No matter if you are designing a software or a hardware, good engineering uses "system thinking" and tries to "design for failure" (which this talk demonstrates with a tiny pet-project to explain the principles) .