KSI-CNA-ULNUsing Logical Networking

Set VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS parameters (authorizedTcpPorts/authorizedUdpPorts) to your documented ingress allow-list, otherwise any 0.0.0.0/0 rule is NON_COMPLIANT. These three cover security-group ingress; for full SC-07 boundary evidence also collect NACL and subnet routing posture and, where used, restricted-common-ports and vpc-flow-logs-enabled. Note VPC_DEFAULT_SECURITY_GROUP_CLOSED may lag on deleted VPCs until the next baselining pass. These three rules read security-group ingress and nothing else; SC-07(b) — the logical separation FedRAMP's own guidance singles out — plus NACLs, route tables, gateways and VPC endpoints are a human's architecture assertion against this output. MAS-CSO-FLO is not claimed: its artifact is the enumeration of permitted connections, and a NON_COMPLIANT filter is empty on a compliant estate.

The commands split cleanly across the control family, and the gap in the middle is the one to be honest about. AC-17(1) — automated monitoring and control of remote access — is what session history and connection logs deliver, with two documented blind spots. Session Manager does not log sessions that connect through port forwarding or SSH, because SSH encrypts the session data inside the TLS connection and Session Manager is only the tunnel; an operator who port-forwards leaves a session record with no command content behind it. And describe-sessions reaches back 30 days only, so anything longer is an S3 or CloudWatch Logs query against the destinations named in the preferences document, not an SSM call. Client VPN retention is shorter still — terminated connections drop out of the API after 60 minutes, which makes the log group named in ConnectionLogOptions the only durable record, and Username is populated only for Active Directory authentication, so certificate-authenticated users are identified by CommonName or not at all. AC-17(2) is the strongest link in GovCloud, where the endpoints are FIPS 140-3 modules by construction; the Session Manager equivalent is kmsKeyId in the preferences document, and it is empty unless you set it, so an empty kmsKeyId is a finding rather than a default. AC-17(3) — routing remote access through managed network access control points — is the one nothing here proves. Session Manager and a Client VPN endpoint are managed access points, and ec2-instance-no-public-ip is the closest negative check, but that rule applies only to IPv4 and only to AWS::EC2::Instance: an IPv6-reachable instance, a load balancer fronting SSH, or a third-party jump host is invisible to it. Read the result as 'no EC2 instance carries a public IPv4 address', which is a useful sentence and not the control. AC-17 itself — the documented usage restrictions, configuration requirements and per-type authorization — is a record you write, and this telemetry only shows whether the estate matches it. One warning to carry into the evidence package: Session Manager logs the commands entered and their output, so a credential typed into a session lands in the log group you are about to hand an assessor.

CA-09 has four elements and this output serves parts of two of them. The part it holds: which internal connections exist. Every plane on which one component of the system reaches another leaves a resource behind — a peering connection, a Transit Gateway attachment, an endpoint, an endpoint connection, or a security-group rule that names another group instead of a CIDR — and five calls enumerate them completely for a Region. That enumeration is worth having on its own: it is the list the control's documentation requirement is written against, and most providers do not have it. What it does not hold is everything CA-09 asks you to record about each connection. The interface characteristics, the security AND PRIVACY requirements agreed for the connection, the nature of the information communicated, and the authorization to connect at all — none of them is a field. Two further elements of the control are not addressed here at all and should not be read as covered: terminating internal connections when the stated conditions are met, and reviewing the continued need for each connection on a stated frequency. The second of those is the one this inventory most nearly serves — a continuously collected enumeration is the substrate a periodic review runs on — but the review itself is a decision with a date and a reviewer, and none of that is in the response. They live in an interconnection agreement or an internal approval record, and the reconciliation of that record against this inventory is the CA-09 artifact. This recipe produces the column you reconcile against, which is why it is partial and why no assertion below claims more than attachment and state. Read every one of these lists as a history rather than an inventory. Peering connections persist in the response with Status.Code deleted, rejected, expired or failed; Transit Gateway attachments persist as deleted, failed or rejected; endpoints persist as Deleted or Rejected. A count taken over the raw response counts connections that do not exist, and — the direction that actually matters — a clause of the form 'every connection carries an authorization tag' evaluated over the raw response is answering about the dead ones too. Every assertion here is therefore narrowed by state, and the narrowing is the assertion. The completeness clauses are written as OFFENDER LISTS — a filter that selects the rows which fail, asserted to be empty — and not as 'every connection carries a tag'. This is not a style preference. A field projection over a list drops the rows where the field is absent instead of reporting them as false, so an every-row clause of the obvious form evaluates only the rows that already comply and is green on an estate where half the connections are untagged. The offender form was verified against synthetic responses before it was written down. The vacuity to state plainly: all five lists are empty on an account that has none of these, and an every-entry clause over an empty list is true. This evidence cannot distinguish 'no internal connections' from 'no connections in THIS Region' from 'the collection ran with a role that cannot see them'. Record the Region set the collection covered beside the output, because every one of these calls is Regional and nothing in the response says which Region produced it. Two directions, and only one of them is intuitive. Four of the five calls show what this account reaches OUT to. describe-vpc-endpoint-connections is the other direction — it is the provider-side view of who has connected IN to an endpoint service you publish — and a pendingAcceptance entry there is a connection request nobody has adjudicated. The same is true of a peering connection in pending-acceptance: an unaccepted request is not yet a connection, but it is a decision someone owes, and it belongs in the review the KSIs describe as persistent rather than in a quarterly surprise. OwnerId and ResourceOwnerId are what make 'internal' checkable at all, and they are also the join this grammar cannot do: deciding whether a peer account is inside the authorization boundary means comparing OwnerId against your own account list, and an assertion compares a field to a constant. Write the boundary's account set into the assessment and reconcile by hand; a tag naming the authorization record is the closest a field gets, which is what the assertions ask for. Security-group rules are included for a reason worth stating: they are the only one of the five that shows a connection with no resource of its own. A rule whose ReferencedGroupInfo names another security group is one component permitted to reach another by identity, and it is invisible to any inventory that looks only for peering connections and attachments. Description is free text and no AWS call validates it, so treat the description assertion as a documentation-completeness check rather than as evidence about the connection itself.