2020-02-04, 11:30–12:20, B. Con
We have created a Rudder policy that covers all OS that we support at our customers, or that will be coming around (i.e. beta of a new version).
For our managed systems, it covers distro-/OS-specific settings with a generic rule that “what makes sense everywhere, will be applied everywhere”.
For human eyes, it needs to have a clear design that eases understanding and maintenance.
experiences
A rough description how to approach building a hardening policy, anyway.
- kernel module blacklists, limits & sysctls
- fine-tuning addons like auditd or OSSEC for safety and low footprint
- mixing OS-specific and globally applicable settings
- breaking vendor support (my favorite OS ain’t supported?)
- abstracting OS-specific package and service names
- docs docs docs
- the necessity of independent testing (Lynis, Packer/inSpec, Monitoring) and its boundaries
why independent testing? because if we (flawed human) design the policy, we (same flawed human) should not design the final test :-)
takeaway
We'll wrap it up while looking at some practical stuff, i.e. why nsjail is awesome as a containment technology for services.
Should you walk into the room and listen you’ll get a rough idea of sustainable policy design but also of what a sec policy looks like if it's not made only for filling checklists.
Life is interesting!