6 tips for adopting open source

No readers like this yet.
How far should openness extend?


Open source code drives collaborative innovation from a larger pool of developers at a lower cost, which is why federal agencies are adopting the "open source first" model. In fact Sonny Hashmi, CIO of the General Services Administration, recently announced that implementing open source software is among his top priorities this year.

So what’s the best way to increase your agency’s adoption of open source software and keep it secure? Here are six tips to get you there:

1. Standardize on a common platform.

Imagine the Army telling new recruits to stop by the gun store on the way to boot camp and pick out whichever rifle they want. You can picture the chaos that would ensue in training consistency, interoperability and logistics.

The same principle can be applied when designing a data center. Most developers want the latest tools at their disposal, but this desire conflicts with the goals of operations teams who want to provide a consistent, standardized, stable and secure foundation to build upon.  

For example, the use of Software Collections, a repository of  enterprise Linux tools, benefits both teams by providing the latest stable databases, development tools and programming languages that make developers happy, while packaging them in a consistent, standardized, stable and secure way that improves function and efficiency for operations teams.

2. Use systems management tools to automate your success.

Once you’ve standardized, you can automate. Systems management tools will transform a data center from an artisan workshop to a high-output IT factory. By attaching standard systems to a centralized management tool, a common dashboard will show the status of systems in real time and if security patches or bug fixes are needed. Just like the operations control in a large factory, these tools can ensure a data center factory is humming along for its end users.

3. Use SCAP for continuous monitoring of your datacenter's security posture.

So, you just installed some open source software. How do you properly secure it? Fortunately, the Security Content Automation Protocol (SCAP) transformed security policy from human-interpreted prose to machine readable, unambiguous XML. In the past, SCAP scanners were only available from proprietary companies. Today, open source tools like OpenSCAP are freely available, built into many operating systems and certified by the National Institute of Standards and Technology. By combining OpenSCAP with systems management tools, IT pros can run large-scale automated scans frequently, ensuring the efficiency and security of the data center.

4. Master navigation of vendor vulnerability databases and tools to minimize vulnerability windows.

When a data center is vulnerable to security flaws, the window of attack needs to be patched immediately. The best way to do so is to choose software that is officially compatible with CVE, the set of standard identifiers for publicly known security vulnerabilities and exposures.

When a vulnerability is recognized, it’s assigned a CVE number. This gives multiple vendors a single identifier to determine their vulnerability in a consistent and measurable way. Many open source projects and communities don’t consistently track against CVEs, but several companies who commercialize these projects do, so choose wisely.

In addition to tracking the CVEs, admins can use OpenSCAP to do vulnerability scans. OpenSCAP can use Open Vulnerability and Assessment Language (OVAL) content to scan systems for known vulnerabilities where remediation is available. The trick is to ensure your chosen vendors provide OVAL content consistently, so again, choose wisely.

5. Use government-certified software.

Just because code is open source doesn’t mean it’s not government certified. Just like commercially supported proprietary software, commercially supported open source software may also meet government certifications like the FIPS 140 cryptographic standards and Common Criteria.

If your team is writing their own cryptography, please tell them to stop. Not only will they need to take the code through a lengthy and expensive certification process, their code is probably not as secure as something that has been scrutinized by the public and certified by labs for years.

Using FIPS-certified cryptography libraries to write your applications eliminates the need to obtain a FIPS-certification yourself. Certified cryptography libraries let developers stand on the shoulders of the giants who already did the certification work.

6. Have a vendor at your side.

Ask 10 Linux administrators a question, and you’ll probably get 11 answers. Maybe 12. Which one’s right? The problem is even worse when doing web searches for issues, and some answers may actually do more harm than good.

By working with commercial vendors, you’re not only benefitting from their product knowledge, but you’re also benefiting from their experience with other customers who may have already solved the same problem you’re encountering.  Also, when it comes to open source, you can get features added to a project yourself, but that takes time, effort and influence. By working with a vendor who is a contributor to the open source community, your voice can be amplified and change can result faster.

With these tips, introducing open source code doesn’t have to be an intimidating process. Open source software can be just as secure as proprietary software, with far greater benefits. The reduced cost and collaborative nature of the software allows for faster and more substantial innovation, resulting in improved efficiency agencywide.

Originally posted on GCN. Reposted under Creative Commons with author permission. Republished from GCN, the original publisher of this article.

User profile image.
David Egts | Chief Technologist, North America Public Sector, Red Hat. Drum playing, motorcycle riding, computer geek, husband, dad, and catechist. Follow me on Twitter at @davidegts and check out the podcast I co-host!

1 Comment

IMHO, open source is worse than Microsoft EULA.
I'm not kidding. I do like it, I do live out of it, but it is still worse than Microsoft EULA.
GPL on the other hand is far better if you are going to tell fairy tails about sharing to community.
Just check few lines in header here: https://github.com/magento/magento2

It is obvious that Open Source is made exclusively just to pump code into other people projects so they can earn money and you can't use your own code unless you buy for example Enterprise licence :)

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.