Is partial compliance still "compliant"?

Question

I recently started work with an IT Vendor and we are STIG compliant.

Just last week a customer requested proof of compliance & my company sent them an excel sheet of RHEL STIG V1R2 with ~300 vulnerability ID's, as well as a note of which ID's we were not compliant with. Some non-compliance were on vulnerabilities with "Severity" high.

The customers took it, my company had no troubles sending it out. But it has left me very confused. Why can we say that we are "compliant" with 76 of 300+ non-compliant entries?

I have read a bit about a compliance process online & the books I saw typically stated that compliance had to be (a) Third party accredited (Ie some other reputable organization certifies you) or (b) VA or Configuration checks by customer ITSEC department.

As such could I ask

1. What is my company's stance with regards to STIG compliance? Is there a "partial compliance"?
2. Are there any potential issues that may arise from this that I should be prepared for?

Answer 1

In a perfect world, you would be 100% compliant with STIG, but it's not a perfect world. Also, realize that STIG or CIS Benchmarks are guidance. They can't possibly take into account every scenario. Some of the guidance for STIG (and CIS) hardening does not take into account situations around the deployment, e.g., cloud deployments or the use of alternative solutions.

Regarding Question 1: You haven't provided enough information about your company's policies/implementation of STIG to make a guess at their stance.

Is there a "partial compliance"? Yes, but that sounds more like an auditor's term for "not compliant but made an effort." In general, if you tell the auditor you follow STIG and provide a report that is not 100%, you can still be compliant based on why you've failed some controls.

If, for example, I use another tool to provide File Integrity Monitoring (FIM) other than AIDE, I will fail that part of the STIG audit but still provide the functionality that meets (or exceeds) the STIG. I am not following the letter of STIG, but I am following the spirit. It would probably be viewed as fully compliant.

Another example would be having a password set on GRUB. You would need console access to boot the system. If you're auto-scaling or have a cloud server type that doesn't allow for console access(AWS), your system won't boot. Technically, you're not compliant, but implementing the control would break your environment. This would be viewed as acceptable.

Regarding Question 2: Are there any potential issues that may arise from this that I should be prepared for?

Yes, document anything that differs from the expected control. Using the examples above, you should be able to explain that you're using a different tool for FIM and be able to show it's installed and running on sample hosts. For something like not having a bootloader password, explain why you can't implement it and what compensating controls are in place.

Auditors I've dealt with were never surprised that we didn't meet 100% of hardening guidance; all were pleasantly surprised when presented with documentation as to why we weren't at 100%.

P.S. Auditing tools for STIG/CIS compliance are not foolproof. I've seen false negatives for things like !! in the /etc/passwd instead of a !.