Improving Linux Security with DevSecOps

Ask people who run IT departments these days what keeps them up at
night, and they'll probably tell you it's security—or the lack of
it. With the explosive growth of malicious attacks on everything from hospitals
to Fortune 500s, security—not hardware, software and even staff—is
what currently makes life miserable.

That's why organizations of all sizes are looking to change
fundamentally how they do security. It's no longer a single team's job to make sure
systems are secure and internal auditing is good enough to identify and
mitigate attacks. Today, everyone is responsible for security, which is the
guiding principal of DevSecOps.

Just as in DevOps, which aims to speed the development of software by improving
collaboration and balancing the competing interests of operations teams and
developers, DevSecOps seeks to get everyone thinking about security together
and up front. Trying to bake in security after systems are built and
code is deployed is simply too late.

Steps That Make for a More Secure Linux Environment

Fortunately, you can make things more secure by design by using some common
tools and practices. You don't need a "Security Initiative" to
lower your risk of breaches and hacks. You can start small, share what you
know and lower your risks today.

Establish Baselines

One of the best ways to improve security is to know what you have in the first
place. Security experts lament the fact that most organizations, many of which
have grown organically over time, haven't taken the time to define standard
rules for their systems that can be repeated and shared. For example, good
baselines will include:

Machine-level firewall rules: firewalls aren't just for the
edge. You should deploy them at the machine level for bare metal, VMs and
containers that are off-premises and on. One size doesn't fit all, either.
Web server firewalls should look different from application server firewalls.
If that sounds like an overwhelming challenge given the number of servers you
manage, you need to think seriously about automation.

More deliberate port rules: which ports are open and closed to
whom and to where? Is port 22 open on all your systems? Does it need to be? If
it is, is access limited to certain subnets?

Limit access: which users and groups have access to which
systems? Do developers need access to all your dev servers or just a subset?
Which machines have access to each other? Web servers probably should be able
to talk to your database servers, but do they need to talk to other application
servers?

By asking a few routine questions like this, you can begin to define and
implement some solid baselines. Share them on a wiki using MediaWiki, TikiWiki
or PmWiki to make updates a snap. Wikis make documentation easier, which makes
adoption and use easier—and more effective.

Machine-Level Firewalls

You can deflect a lot of bad activity by setting a few good firewall
rules—even on systems that don't see the outside world. After all, not all
security problems come from the outside.

Iptables is robust, ubiquitous and relatively easy to manage, even from the
command line. So, if you want to give only a single specific subnet shell
access to your Linux servers, you can add a rule like this:

John S. Tonello is Director of IT for NYSERNet, Inc., in Syracuse, New
York. He's been a Linux user and enthusiast since he installed his first Slackware
system from diskette 20 years ago. You can follow him @johntonello.