How to get started with DFARS and FISMA compliance

There’s an easier way to accelerate compliance

If you’re reading this blog, you’re probably already aware of how difficult it is deploying hardware or software into the Federal Government. Just for table stakes, you may have to ensure your product is compliant with DFARS (Defense Federal Acquisition Regulation Supplement) and FISMA (Federal Information Security Management Act) regulations. Adapting operations to meet these required standards is non-trivial and often requires a significant investment on behalf of the organization.

To specify its policy in regards to cybersecurity, FISMA relies on NIST 800-53 for its information security guidelines while DFARS defers to the NIST 800-171 standard. The configuration management portion of both NIST 800-53 and NIST 800-171 are written broadly for the purpose of interpretation since they need to be applicable to any number of hardware and software solutions. This can be a bit frustrating to any organization required to be compliant. They want (and need) clear instructions on cybersecurity best practices, and how to properly implement the numerous controls contained within these NIST guidelines. To combat this problem, NIST endorses STIG and CIS as the preferred approach to satisfying its policies.

Getting to a state of compliance once is one thing, but enforcing continual compliance over time is a different story. DISA STIG and CIS baselines consist of 100’s of individual controls for each major system component, so applying and maintaining these baselines overtime put a strain on resources. That’s why MindPoint Group created Lockdown Enterprise. Using our cybersecurity and automation engineering expertise, we automate and maintain DISA STIG and CIS baselines so you don’t have to.

So far, Lockdown Enterprise includes automation baseline content for multiple versions of RHEL and Windows Server, along with other application components like PostgreSQL. Not only have we provided the capability to continually enforce a desired state of compliance, we’ve taken care to organize low-level configuration tasks into lists of annotated, human-readable code which can be used as a compliance artifact during regulatory assessment.

How does it work?

Take security requirement 3.4.9 in the NIST 800-171 guidance—“Control and monitor user-installed software”. To summarize, NIST requires policies, procedures, and configuration management controls in place to prevent unauthorized user-installed software–that’s it. Super vague, right? Engineers need better instruction to make this happen at the system level, which is where STIG and CIS come in. NIST policy 3.4.9 can be satisfied through a combination of SElinux enforcement and user separation instructions which are individually identified in the STIG or CIS baseline.

Lockdown Enterprise tags each control to a block of code in the baseline to clearly indicate how system settings were modified through automation. With the SLA provided as part of the subscription, we’ll help you map Lockdown Enterprise baselines back to NIST 800 policies to further clarify compliance in event of an audit or assessment.