AC-17 Remote access

Start from the network, not the policy document, and list every path into the system that a person or outside party can use from outside the boundary. Typical sources are firewall and VPN configurations, identity provider application lists, cloud security groups, jump hosts, remote desktop services, vendor tunnels and SaaS administrator consoles. Group the results into types such as VPN, zero-trust access, bastion, vendor tunnel and remote desktop, then write usage restrictions, configuration and connection requirements, and implementation guidance for each type. Interview system and network administrators to find access that exists only in someone's habits. In OPNsense, aliases can group address ranges so the inventory maps to rules an assessor can check. Confirm with your own environment whether operational technology and cloud accounts are in scope before you declare the list complete.

Assessors expect an authorization for each type of remote access, recorded before that type is allowed to connect, and a per-person ticket does not show that. The symptom is a folder of approvals that name individuals but never state which access type was approved, for which systems, or until when. Fix this by recording a dated authorization per type with the approver, the systems in scope, the accounts permitted and the review date. Link each authorization to the account records under AC-2 so the two can be compared. Re-authorize when a type changes, such as a new VPN profile or a new vendor tunnel. The SP 800-53A examine method for this control names remote access authorizations as an object, so keep them in a form that can be produced on request.

Vendor access usually bypasses the process because a project team sets up a tunnel or shared account to meet a deadline, and nobody adds it to the inventory. Assessors find it by comparing firewall rules and identity records against the documented list, and the gap shows up as sources or accounts with no matching authorization. Close it by treating each vendor connection as its own documented type with named accounts for external users under IA-8, a defined time limit, multi-factor authentication where the platform supports it, and logging. Review the vendor contract for access terms and the controls the vendor asserts, since AC-20 covers outside systems. Block unlisted sources in the rule set and review rule changes at each change window.

The moderate baseline adds AC-17(1) for monitoring and control, AC-17(2) for encryption of confidentiality and integrity, AC-17(3) for managed access control points and AC-17(4) for privileged commands. These are often assumed because a vendor default exists, and assessors test the running configuration. Confirm that remote sessions produce logs, ship them to a central store and that a sample session can be traced from login to command. Verify the encryption settings on each remote path with a test, not a datasheet. Show that remote access enters only through the defined concentrators or bastions, and that privileged commands run over remote paths are restricted and logged. For web-based administration consoles, a web application firewall such as Coraza, with ModSecurity-compatible rulesets, can add inspection. Confirm the platform's capability for each enhancement before you write it into the system security plan.

Evidence collected once shows the system on one day, and an assessor will notice when screenshots, rule exports or account lists no longer match the environment. The usual symptom is a firewall rule for a retired vendor still active, or an MFA enrollment list that predates a staff change. Fix it by scheduling recurring exports of rule sets, VPN and bastion group membership, identity provider access assignments and second-factor enrollment, with a named owner for each. Store each export with its date. Tie the exports to change management so that a configuration change triggers a fresh export. Authentik's authenticator validation stage and FreeIPA's OTP support both let you show current second factors, so use those records rather than a point-in-time screenshot.

Your team owns the control, and it can produce the evidence without outside help if it has the time and the skills to configure logging, export rule sets and keep records current. An implementation partner such as DeployOpen can prepare the systems, configuration and evidence under a fixed scope agreed in writing before work starts, but it does not issue assessment reports or certifications. An independent assessor tests the control against the SP 800-53A procedures and decides the result. Cost depends on the number of remote access types, the number of connected systems, how much logging already exists and whether vendors need their own access records. Ask any provider for a written scope listing the types covered, the systems in scope, the evidence delivered and who will answer assessor questions.

The effort depends less on the VPN product than on how many types of remote access the organization allows and how well those types are already documented. NIST does not publish a effort figure for AC-17, so the honest answer is that a single VPN with one user population is the smallest version of the job. The work includes writing usage restrictions, connection requirements and implementation guidance for that access type, obtaining a recorded authorization before connections are permitted, and then producing evidence that the configuration matches the documentation. Effort rises when the VPN has several user groups, split tunneling, administrator access paths, or logging that must be reviewed. Ask your assessor or consultant to break the estimate into documentation, configuration, testing and evidence collection so you can see where the hours go.

Yes, in most organizations the control owner, the security team and the network team can do the work without an outside partner. The organization owns the control, so it must write the remote access documentation, approve each access type and keep the records. Outside help is useful when the team lacks time, lacks experience with the enhancements on monitoring, encryption, managed access points and remote privileged commands, or needs a second pair of eyes before an assessment. Check internal skills against the assessment procedure in SP 800-53A, which asks assessors to examine documents, interview administrators and test the remote access capability. If a gap appears in any of those three areas, that is where a partner would add value.

The work needs named owners on both sides. Security or compliance staff need to define each permitted type of remote access, such as VPN, remote desktop, or privileged administrative sessions, and agree who can authorize it. Network and identity engineers must document the configuration, including how sessions are encrypted, how users authenticate and which access points are managed. Operations staff must keep the logs that show who connected, when and from where, and be able to produce them on request. Each type of access needs a written owner and a recurring review, so that the documentation does not drift from the running system.

NIST does not set implementation timelines for SP 800-53 controls. Under FISMA, timelines for federal systems are set by OMB Circular A-130, and the duration for any organization depends on scope. The main drivers are the number of remote access types, how much current documentation exists, whether the enhancements for monitoring, encryption and managed access points are already in place, and how quickly reviewers can approve the authorizations. Ask any partner for a schedule tied to a written scope, with milestones for documentation, configuration changes, testing and evidence collection, rather than a generic duration.

No. An implementation partner can prepare the remote access configuration, documentation and evidence, but only an independent assessor or auditor can perform the assessment and report on it. The organization retains responsibility for its controls and for the authorization decision. DeployOpen prepares systems, controls and evidence for compliance assessments, and does not issue audit reports, attestations or certifications. When you select an assessor, confirm their independence from the team that built the controls and agree in advance which assessment methods they will use for AC-17.

A useful quote states the scope in writing before work starts. It should list the types of remote access in scope, the baseline (low, moderate or high) and which AC-17 enhancements are included, such as monitoring, encryption, managed access control points and privileged commands. It should name each deliverable, for example updated remote access documentation, configuration records, test results and an evidence package mapped to the SP 800-53A procedure. Ask which systems and environments are excluded, which tasks the client must perform, who approves changes, and what happens if the scope changes. Fixed-scope engagements are the usual format at DeployOpen, and the quote follows from that written scope rather than from a published price list.

Several self-hosted tools can generate evidence for parts of AC-17, but none of them satisfies the control alone. A firewall such as OPNsense can pass, block or reject traffic by source, destination, port and protocol, and can log each rule match for review. An identity system such as authentik or FreeIPA can enforce second factors during login, which supports the authentication side of remote access. Coraza can protect web-based remote access endpoints against common application attacks. Confirm each tool's capabilities against your own environment before you rely on it in an assessment, and keep the configuration exports, log samples and change records that show the control operating.