I’m now of the mind that a NIDS, while certainly able to satisfy the project’s needs, is more complicated than NJ Coast needs. My suggestion to the team is to consider dropping a NIDS and go with a HIDS (Host IDS) instead. This would entail getting/processing host and application logs from the AWS VMs and K8s containers.
Why is this sufficient? We only have two protocols (three if you’re pedantic) heading into the NJ Coast system: SSH and HTTP/S. In both cases, there is already robust logging at the VM and container levels. There really isn’t any need for us to analyze traffic at the packet level; doing so is pointless overhead. Using just host and container logs (e.g., OS-level, SSH-related, Apache-related) we should have no problems tracking the state of NJ Coast.
This can be managed in a whole raft of homegrown or AWS ways; I’ll defer to Steve/James to pick a solution that’s secure and convenient. However, going with a service like Amazon’s CloudWatch may be the easiest:
Chris also suggested the possibility of using something from Amazon’s Market Place (https://aws.amazon.com/mp/scenarios/security/ids/). Many of these would likely work well, though they might offer more power than we need (they also might be pricier than a service like CloudWatch). But, again, I’ll defer to Steve/James to pick the solution they feel fits best.
In the end, we want VM and contain logs to be securely gathered in a central location where they can be processed, visualized, and alerted on in (more or less) real time.
Per Tim's suggestion from May 23.
I’m now of the mind that a NIDS, while certainly able to satisfy the project’s needs, is more complicated than NJ Coast needs. My suggestion to the team is to consider dropping a NIDS and go with a HIDS (Host IDS) instead. This would entail getting/processing host and application logs from the AWS VMs and K8s containers.
Why is this sufficient? We only have two protocols (three if you’re pedantic) heading into the NJ Coast system: SSH and HTTP/S. In both cases, there is already robust logging at the VM and container levels. There really isn’t any need for us to analyze traffic at the packet level; doing so is pointless overhead. Using just host and container logs (e.g., OS-level, SSH-related, Apache-related) we should have no problems tracking the state of NJ Coast.
This can be managed in a whole raft of homegrown or AWS ways; I’ll defer to Steve/James to pick a solution that’s secure and convenient. However, going with a service like Amazon’s CloudWatch may be the easiest:
Chris also suggested the possibility of using something from Amazon’s Market Place (https://aws.amazon.com/mp/scenarios/security/ids/). Many of these would likely work well, though they might offer more power than we need (they also might be pricier than a service like CloudWatch). But, again, I’ll defer to Steve/James to pick the solution they feel fits best.
In the end, we want VM and contain logs to be securely gathered in a central location where they can be processed, visualized, and alerted on in (more or less) real time.