The Linux Foundation is no stranger to the world of open source and free software — after all, we are the home of Linux, the world’s most successful free software project. Throughout the Foundation’s history, we have worked not only to promote open-source software, but to spread the collaborative DNA of Linux to new fields in hopes to enable innovation and access for all.
This is why the Linux Foundation IT staff has decided to release some of the internal IT checklists and policy guides as part of the “Useful IT Policies” open-source project on GitHub (https://github.com/lfit/itpol). Generalized versions of these internal documents are made available under the Creative Commons “Attribution-ShareAlike” license in hopes that other IT teams will fork them, adapt them, tweak them to fit their needs — and hopefully contribute back in true spirit of open-source collaboration.
We chatted with Konstantin Ryabitsev, Sr. Systems Administrator and head of the Linux Foundation Collaborative IT projects, about the goals and motivations behind the project.
Q: What prompted your decision to open-source these documents?
In doing this, we were inspired by other projects who have taken similar steps, such as when the recently defunct Ada Initiative released their excellent AdaCamp policies under a Creative Commons license. Our team has been producing open-source software and free documentation throughout the years, and extending this approach to our internal documentation was simply the next logical step.
Q: What documents are available?
Thus far, we have released two documents adapted from our internal IT policies. First one is a generalized version of our Linux workstation security checklist, which we hope will be useful to other IT teams. In the document, we go into some detail about the reasoning behind our recommendations and try to provide a rough guideline for what we consider essential steps, what is more of a nice to have, and what is likely to be seen as “too paranoid” by most other sysadmins. This is not to say that “paranoid” recommendations shouldn’t be considered — the “paranoid” label is more of a fair warning that implementing these measures will require a significant amount of dedication on the part of the sysadmin in order to be worth the effort.
The second document is a shorter checklist for establishing trusted team communication. It discusses subjects like using OpenPGP or S/MIME for sending and receiving encrypted email, securing IM conversations by using the OTR protocol, and establishing firm policies on what subjects should be never communicated over untrusted channels (passwords, internal policy decisions, security-sensitive details, etc).
Q: Do other companies provide such checklists and guidelines?
Absolutely, there are quite a number of workstation hardening documents published by reputable IT security companies, which everyone should absolutely consult. We by no means claim that our checklists are better, smarter, or more exhaustive. Based on our experiences as security-minded sysadmins, we think these are useful recommendations that strike a workable balance between security and usability. Other systems administrators should approach these documents just like they do all other open-source resources: they can evaluate them, adapt them, hack on them until they fit their team’s requirements, and hopefully contribute back via patches or feedback. This is why we released them on GitHub under a free license.
Q: Will there be other documents in the future?
Definitely, as time allows — and we invite other teams to contribute theirs. Open-source projects are successful because instead of reinventing the same things over and over again, we draw on the collective works and experiences of other developers who chose to freely share their expertise with others. There is absolutely no reason why we should treat policy documents differently from any other code, or keep them strictly proprietary. We hope that others will choose to freely share their guidelines and policy documents, to everyone’s mutual benefit.
