Creating an initial server build is no easy task. Now add to that the process of ensuring correct compliance with FISMA, PCI, FedRAMP, or any other compliance control family, and you’re left with a very large task. The Center for Internet Security’s CIS tool does a great job of checking whether or not your systems meet the correct compliance standards for your industry. But that still leaves an enormous amount of time which needs to be spent going through each of the isecurity controls and validate the the settings have been properly implemented.
Atomic Secured Linux
Enter Atomic Secured Linux. ASL is a Unified Security Suite addon for Linux systems designed to protect servers against zero day threats. One of the more under-rated features of ASL is its ability to re-configure your server based on the various compliance standards. While this would most likely have devastating side effects to a live production server, it is the perfect tool to use when configuring one from the ground up (more on that later).
ASL’s Compliance Modules
ASL comes with five different compliance modules – CIS, DHS, DISA, NISPOM, and PCI. You will find that based on security controls, these modules often overlap. Each profile’s security controls are already mapped to each other, and simultaneously activated. There are literally thousands of changes it will make based both on the profile and platform. The changes themselves are mapped directly from the STIG’s referenced above, so if you want a full list check out the STIG for that particular platform.
Here’s what the ASL developers have to say. “A lot of those controls overlap with what ASL does, and in many cases they have no real world security impact. We have government customers that bought ASL for no other reason than they can run the STIG tool and then remove ASL on the system. ”
Do not test this setting in a live environment!
When it comes to these compliance settings, here’s something you should be very aware of when utilizing this part of Atomic Secured Linux. Often when you enable a Compliance setting, these settings may “break” things. Because ASL does not publish compliance standards, they have no control over the fact that they may break something (i.e. disable an operation).
The folks at ASL had this to say when discussing how a Compliance setting could break things for users. “ASL already includes a very secure set of configuration settings, in some cases more secure than these standards. So you don’t really get much from a security point of view. These are for compliance requirements only. If something is worth doing from a security perspective, we already do it. So you don’t gain anything from a security perspective by using these compliance standards.”
Simply put, if you need to protect your systems but do not have to be compliant, then don’t enable compliance settings. That will make your life much easier and headache free.
Atomic Secured Linux is a great security suite for both experts and beginners.
If you are operating in a shared-hosting environment and/or have public-facing servers; then we think you will find Atomic Secured Linux Unified Threat Manager a must-have tool for your security and compliance requirements. But what puts ASL at the top of list as an essential proactive protection tool is the fact that it is extremely easy to use, full of features, dependable and fully-supported. Whether you are an advanced user or someone with absolutely no security background experience, the Atomic Secured Linux Unified Security Suite add-on is going to help you get the job done faster, more efficiently and better than other security protection options.
Please visit Atomic Rocket’s ASL page for more information.