Over the past year, we have had a great time developing and establishing the open source hardening framework within our company and outside. It has been a fantastic start and we are grateful to everyone who helped us get this off the ground.
However, to me, it is even more exciting to look forward at the potential this project holds. It is something we were so far only able to hint at.
Specifically, there are two key features missing, which could help this project tremendously: An user-interface and customization.
You have files on a system which you want to offer as an archive to download. Easy: There’s great libraries in virtually all languages to create archives like
tar on the fly and stream back the files.
But how about adding files to an archive on the fly? Or combining archive streams? This greatly depends on the type you use.
Gin + Gorilla = …
Most people don’t worry about this. But when it comes to safety and compliance, or even the occasional force-push or delete, you will be happy to still have a working backup of your repository. This is how to do it easily.
Sometimes your Chef run fails. Even though you’re greeted with bold red letters, you may still want the run to continue. Imagine, for example, bootstrapping nodes for the first time when no monitoring system is up yet. Or later on if monitoring fails. Your Chef run will break down due to missing components, even though you actually want it to complete, instead of failing halfway through.
Getting your application to write log info is easy. Just grab a small logging framework that writes to stdout or a logfile. They are available in all major languages, well-document, and easy to get going.
During the last years, logstash and friends have taken root in our environments and made our lives much easier.
With this in mind, I though it must be simple enough to get my scala applications equipped with some nice log-stashing. Here’s where I landed.
“Where do you store your documentation?” When you get this question during a security audit, you better have an answer that is centralized, failure-resistant, backup-ready, fully versioned and (as a bonus) manipulation resistant.
If you’re at a big company, you will find some shiny, ancient system, that handles these tasks. But if you’re at a startup, you usually neither care nor want such a behemoth.
At Sessionbird, we initially started pushing everything into OwnCloud. Recently, however, we moved our core documentation to Git.