For those of you who deploy #honeypot resources or other active deception, how do you represent them to regulatory audits, or programs like FedRAMP? Are there specific steps you take to clarify that these are intentional "misconfigurations?"
@mttaggart@SecurityWriter What is the intention of including these assets in scope for accreditation? Why not carve out a subnet from your net block for honeypots, explicitly define your accreditation boundary to not include them, and isolate them from your accredited assets? Can you keep them as far away as possible from your accreditation but make it look like they are on the same network? In my experience with FedRAMP, if an asset has a CVE pop on a scan, your sponsor will require it patched within POA&M allowances for the severity, no exceptions.
@SecurityWriter I mean in a comprehensive audit, say for regulatory compliance, an asset is an asset is an asset, right? Servers don't get a pass because they serve a security function. So that's the basis of the question; how do you describe those assets/applications so the intentional "vulnerabilities" pass muster?
Add comment