TL;DR: Production Linux environments are often difficult to secure. In this two-part blog series, we discuss practical steps to crawl, walk, and then run toward more secure and well-regulated production environments.
Ensuring security for Production Linux environments can be a daunting task. Because Linux began as an open source, collaborative project, it has evolved in ways that are distinct from proprietary operating systems like Windows and MacOS, and (like most systems we use today) it wasn’t designed with security in mind from day one.
Driven by developers excited by its limitless potential and ease of access, Linux has become the backbone of development infrastructure today—and security teams are increasingly being asked to catch up and protect these environments after the fact.
Securing Unique Production Linux Environments
Linux is in many ways optimized for the developer experience. Developers prize flexibility and speed, and with Linux systems they can use quick-to-install open source tools that help them accomplish their tasks. Plus, since they are standing up the systems themselves, they have root access from the start to do whatever they wish.
Every Linux environment is unique, and most security teams lack any substantial visibility into Production Linux environments. Linux is also extremely customizable, which is part of why it’s difficult to gain visibility into production environments—no two systems are quite the same.
The diversity in environments combined with the “after-the-fact” access security teams have is why putting policies in place and installing security tools often slows or outright breaks things. And that’s if you can find a security product to use—compared to other operating systems, there are few choices on the market. In other words, managing Linux security isn’t like managing Windows security. There’s no one-size-fits all, decades-tested, rule-based approach.
So, you may be wondering: how do I begin to tackle security in a Production Linux environment? How do I take what is an organic, freeform environment and gain better visibility and control without slowing down development processes?
Well, you have to crawl before you walk, and walk before you run.
In this post, we’ll break down what it means to crawl when it comes to Linux security, with some tips on how to get started and take action. In our next post, we’ll finish up with what it means to walk and run, too.
Crawl: Gain Visibility
For those just getting started with Production Linux security, the watchword is visibility.
Knowledge is power, and organizations cannot protect what they don’t know exists. When it comes to visibility, the biggest area of concern for security teams is user (or account) behavior. In other words, what are users—or the shared accounts we use regularly—doing inside these systems? Often, user accounts have huge amounts of power inside of Production Linux environments, and activities may not be easily attributable to an actual person—and if these accounts are compromised (via credential theft, for example) or are used by a disgruntled insider with malicious intentions, they could do serious damage to a company’s systems, IP, or sensitive data.
Start by taking stock of your user base and the accounts they use, auditing who is in your cloud, and understanding what they’re doing in production environments. The key is to gather information before trying to implement new policies or tools to control user behaviors—a draconian approach from day one will likely incite rebellion and resentment.
This worksheet can help the organization self-assess where things currently stand. At this step, a tool that provides user attribution and command line visibility is a huge help, because it lets you see who is doing what across every single session. (We are beginning to offer this functionality for free—sign up for the beta here.)
This step is all about:
wading through it to understand behavioral patterns
and prioritizing next steps and addressing possible risks.
With a clearer sense of what is happening inside Production Linux environments, you can start to understand what’s normal and what’s not for your unique organization.
Up Next: Walking and Running
Once organizations have visibility, the natural next steps are to manage access and eventually implement controls. However, these things can only happen with a good sense of the behaviors and activities taking place within the organization. Also, security maturity is not always even—in other words, your organization may be crawling in one sense, but walking in another. And even once you start running, Production Linux security is a marathon, not a sprint.
Stay tuned for our next post about walking and running toward Production Linux security, where we’ll provide frameworks for improving role-based access and control.