How a cloud native packet capture platform can meet the DoD SCCA Requirement
Traditionally full packet capture systems exist to obtain the network communications between various hardware devices – servers, switches, routers – in a physical network environment. With the advent of Kubernetes and cloud native environments that type of traditional approach is no longer effective (or relevant) to provide information into ephemeral resources. Information from microservices and containers such as pod-to-pod, namespaces, and intra-pod communications, etc. are critical for continuous observability and forensic inspection for performance, security, and reliability engineering applications. The evolution of infrastructure and network communications has evolved into virtualized and cloud native architectures such that new technologies are needed to operate and monitor those systems.
Recently, we were approached to partner with a global cloud service provider (CSP) to meet the Department of Defense Secure Cloud Computing Architecture Functional Requirements PDF (DoD SCCA) for Full Packet Capture (FPC) by providing a cloud native FPC solution for their new environments.
As more Public Sector Agencies and Enterprises move to containerized / cloud native architectures, we are surprised to hear that the traditional network monitoring vendors are taking a “best efforts approach” in they are offering hardware-based or hybrid/virtualized FPC solutions that, technically speaking, “may” help them meet the requirements, but functionally are like “fitting a square peg in a round hole.” With the evolution to cloud native and Kubernetes we expect to see demands for truly cloud native full packet capture solutions increase; already various government agencies have been soliciting for upgraded PCAP offerings per a recent GCN article.
Building off the MantisNet CVF® platform - combining the CVF® sensors with open source and commercial tools (MantisNet CVF + CSP compute, storage, database, analytics and UI) we can build and demonstrate a simple, efficient and innovative approach to delivering full packet capture capability as a cloud native service offering. This approach doesn’t need hardware packet capture based solutions, off-line (off cloud) analysis needs, or sidecar add-ons to perform the function.
For this particular CSP deployment, legacy hardware and virtual/hybrid packet capture systems were not an option– since they require external systems to augment the cloud infrastructure to access the virtual and physical network traffic increasing physical threat vectors. There are many articles and vendors that you can search to explain how they work as an add-on to the cloud environment to accommodate FPC requirements.
We’ll discuss why a cloud-native full packet capture solution is needed, how it’s done, how we (in partnership with a CSP) meet the specific requirements and the potential operational improvements and cost savings.
Why cloud native full packet capture is needed
The network communications that make-up what is known as a packet traffic still exist in cloud native network communications. However, those communications are now typically virtual, or ephemeral, and are not accessible in a way that more traditional solutions approach their physical or virtual packet capture and analytics. The CVF sensors are designed to harness the communications within the namespace, or from the various containers and microservices to produce a packet and publish as a PCAP file- whereas the legacy approach is to wait for the traffic to bubble up to a VM or physical access point to acquire it. Along with traditional information, the CSP and Public Sector clients are also getting critical information associated with the containerized or ephemeral resources to better identify security and performance issues. You can see a comparison (image below) of the increased cloud native resource information over traditional packet information that will be more helpful in analysis.
DoD and other industry regulations have these requirements for FPC in the environment for logging requirements and to be used in forensic purposes for security and performance. As systems move to the cloud and cloud native architectures there is a definite need to provide a Full Packet Capture solution that operates as a native function in the environment that leverages the same benefits that the cloud provides.
How cloud native FPC is done and meets the DoD SCCA FPC requirements
In this instance we’ve partnered with the CSP and other partners to architect the Full Packet Capture (PCAP) data to work with their own cloud services such as databases, storage, compute and analytic or visualization tools. We foresee that this can be replicated across any CSP environment where there are inherent cloud services to integrate with.
By partnering with the CSP, we keep the functionality within the cloud deployment which helps in achieving the Full Packet Capture Requirements, per the DoD SCCA functional requirements (Table 16).
22.214.171.124 – The FPC shall support integration with SIEM systems to effect data search and retrieval, such as the capability to pull select timeframes of captured data
MantisNet agents can publish Full Packet Capture data into serialized metadata formats (JSON) or write the data to PCAP format. The JSON output contains a comprehensive amount of detail including (but not limited to): full packet data, five-tuple, and time stamps. Both JSON and PCAP can be ingested by many leading SIEM providers.
126.96.36.199 – The FPC shall provide the means to reconstruct all network traffic sessions traversing the SCCA component.
The MantisNet CVF agents do not provide reconstruction per-se; however, the agents can produce all the information/metadata needed to reconstruct network sessions. Therefore, in partnership with the CSP the MantisNet CVF agents produce the full packet capture and requisite metadata which could be streamed to a CSP storage service, where any reconstruction / reassembly can be done with worker programs and cloud services.
188.8.131.52 – The FPC shall provide defined data queries that run against metadata
MantisNet can work with the CSP or client to understand the specific details of the queries / analytics that you expect to be executed against the resulting CVF metadata so as to assure that the metadata produced by the MantisNet CVF agents supports any query types that the customer requires.
184.108.40.206 – The FPC shall provide a capability to request an arbitrary subset of packets
The MantisNet CVF provides composable, programmable functionality that is controlled via the GraphQL open API. MantisNet can work with the CSP and/or client and provide training (if needed) on how to interact with the CVF agents to produce the required subset of packets.
220.127.116.11 – The FPC shall locally store captured traffic for 30 days
The MantisNet CVF solution does not provide local storage. MantisNet can publish and stream the Full Packet Capture data to a CSP storage solution to fulfill this storage timeframe requirement.
18.104.22.168 – The FPC data shall be isolated from user and data plane traffic via cryptographic or physical means.
MantisNet CVF controller and agents will be deployed within privileged user space, inheriting any cryptographic boundaries already in place. For instances where MantisNet agents stream FPC data to a message bus (we recommend NATS), that message bus will also employ cryptographic means for protection.
22.214.171.124 – The FPC data shall be query-able from a secure remote location on the management network
MantisNet controller and agents will be deployed within privileged user space, inheriting any RBAC and other security, access and authorization mechanisms in use. For data that is already captured and hosted in proposed CSP storage, for timeframe requirements, that will be managed by the CSP and/or client procedures.
126.96.36.199 – The FPC function shall be configurable according to traffic flow source and destination points to avoid multiple point capture
MantisNet controller and agents can be programmed to perform filtering at the Full Packet Capture source to exclude certain traffic types.
Cloud Native vs. Hardware/VM Full Packet Capture Cost Considerations
Since this is a software based approach and deployed within the cloud environment and availability zone the needed cloud services inherently exist to power and enable the function. One can calculate that some costs will be reduced or eliminated entirely. These may include hardware/VM based FPC system and support, cloud egress costs, offline storage, other cloud and compute fees.
For Agencies and cloud providers seeking a cloud native solution that meets the DoD SCCA we have outlined this approach for you to consider. Please contact us to discuss client and environment specific details.