Organizations migrating from Microsoft® Windows® to Linux® often have heartburn over their concerns for already established security configurations.
Regardless of the reasons for the migration, or even by adding Linux to the inventory an obvious question is raised: “Are my current system administrators (sysadmins) capable of managing Linux?”
Some Windows sysadmins might be wondering “Are they going to replace me, or train me to handle Linux?” while others might be opposed to the new architecture and are simply inflexible about learning something new.
Many Linux vendors offer some great training, resources, and professional services to assist in the migration. The top three that come to mind are Red Hat, Novell, and IBM. For starters, I would recommend reading IBM's nine-part developerWorks series by Chris Walden on moving your operational skills from a Windows® to a Linux® environment.
The process of lock down (hardening) is difficult, tedious, and time consuming even for an administrator working on an operating system they're familiar with. This process requires knowledge as to where to configure the item and often how to configure the item.
This process becomes even more complicated when a system administrator is confronted with an unfamiliar operating system because the “where” and “how” are different. By “how”, I mean the necessary tool or technique required to make the change.
Every good system administrator understands the basic, generic activities required to maintain the systems under their purview. Activities such as user account management, access control, backups and disaster recovery, and so on.
More to the point, system administrators understand the rationale in using core, fundamental technologies such as discretionary access controls—that's why I said they only need to know the “where“ and “how” not necessarily the “why”.
Every organization should have a security policy and if you don't—SHAME ON YOU! If you don't have one, create one but don't let technology set your policy.
What I mean by this is some organizations will use downloaded how-tos, lock down recipes, configuration guides to configure their systems. Once completed, they document how their systems are configured and call it a “policy.”
A policy is high-level and defines what is required to protect your assets and ensure business continuity. Its constraints are typically legal in nature (e.g., Privacy Act of 1947, HIPPA, or FISMA).
Additional constraints can be those imposed by an organization's mission objectives such as system availability and timely service. That's why it is important NOT to set your policy based on your technology's capability.
If your technology is insufficient, use something different. Don't compromise! Okay, I will step down from the soap box now...
Cross-posted from Security Blanket Technical Blog