Dynamic behavior monitoring
Note: As of March 2018, this feature is not yet available, pending FedRAMP approval. If you want to use this feature, contact support and our team will let you know our estimated timeline for approval.
cloud.gov uses a range of security features to prevent application containers from interfering with other containers or with the hosts they run on. As an additional security measure, cloud.gov will also automatically monitor application containers for suspicous behavior using Sysdig Falco.
Definition of suspicious behavior
cloud.gov uses the default Falco ruleset. We will add to our ruleset over time, particularly to flag behavior which is not compatible with the existing container security restrictions.
For example, we plan to implement a rule that monitors whether the application filesystem is modified after deployment, and if it is, to restart the app instance. This would help customers fulfill SI-7 (“Software, Firmware and Information Integrity”) responsibilities.
Action taken when Falco observes suspicious behavior
When Falco observes suspicious behavior in an application container, cloud.gov adds a log entry to the application logs. For example, an attempt to create a directory within a protected path (such as
/bin) will result in a log entry like this:
2018-03-22T09:36:17.13-0400 [FALCO/0] ERR 13:36:17.084775186: Error Directory below known binary directory created (user=<NA> command=mkdir -p /bin/hack directory=/bin/hack) (pid=<redacted>, ppid=<redacted>) (pid=<redacted>, ppid=<redacted>)
You can view logs generated by this feature just like any other application logs.
cloud.gov will automatically restart applications flagged for high-severity suspicious behavior to reset them to their original state and deny a foothold to attackers. If you follow the best practice of running more than one instance of your application, this will not affect your application’s availability.
How you should respond to logs about suspicious behavior
During development, you should diagnose the source of the behavior and remove it from your application. This will prevent noise from false-positives in your logs. (We will investigate how we can enable you to explicitly suppress logs about behavior that is expected.)
For production deployments, you should configure alerts based on logs like this. When you and your team receive the alerts, you should closely examine preceding logs from your application for any signs of intrusion. Doing this may help you fulfill the requirements of RA-5, SI-3, and AU-6 when seeking an ATO for your application from your agency Authorizing Official.