SIAS-NET-01 Network segmentation and boundary protection
- Mandatory
- Yes
- Severity
- High
- Applies
- Conditional — the applicant controls network or cloud network configuration for in-scope systems
- SecurityInspect Verified profiles
- VP-CLD
Control objective
In-scope systems are reachable only through intended paths, so that a compromise elsewhere cannot spread to them easily and internet exposure is limited to what the service needs.
Testable requirement
- 1.The applicant must maintain a current network and data-flow diagram of the in-scope environment that shows trust boundaries, internet entry points, connections to networks outside the scope and to third parties, and flows of Restricted data. It must be reviewed at least every 6 months and after any material change.
- 2.Network controls (firewalls, cloud security groups and network access control lists, and container network policies) must deny inbound traffic by default and allow only ports, protocols and sources that have a documented business justification.
- 3.In-scope systems must be separated from networks outside the scope, including corporate user networks and non-production environments, so that only justified flows are possible.
- 4.Systems that store Restricted data must not be directly reachable from the internet. Internet traffic must terminate on a designated tier, such as a load balancer, reverse proxy, API gateway or web tier.
- 5.Outbound traffic from systems that store Restricted data should be limited to required destinations.
- 6.Network rule sets must be reviewed at least every 6 months, and unused or unjustified rules removed.
Applicability and scope
Conditional — the applicant controls network or cloud network configuration for in-scope systems. It may be marked not applicable only where the scope consists solely of SaaS whose network configuration the applicant cannot control, as shown in the shared-responsibility map (SIAS-TPR-05). SecurityInspect Verified profiles: VP-CLD (limited to the named cloud tenants or accounts).
Pass criteria
- 1.The diagram was reviewed within the last 6 months and matches the observed architecture, with no undocumented internet entry point.
- 2.No inbound rule allows traffic from any source to non-designated ports on in-scope systems, and every sampled rule has a documented justification.
- 3.Segmentation testing (A4, M3) shows no unjustified path from networks outside the scope.
- 4.No Restricted-data store is directly reachable from the internet.
- 5.A rule review was completed within the last 6 months.
Severity
High. Escalate a finding to Critical when a reachable path exposes Restricted or other sensitive data or credentials to unauthenticated parties.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 1.2, 1.3, 1.4
- Trust Services Criteria
- CC6.6
- ISO/IEC 27001:2022
- A.8.20, A.8.22
- Theme (SecurityInspect wording)
- limiting network paths to what is needed
SIAS-NET-02 Protection of administrative and remote-access services
- Mandatory
- Yes
- Severity
- Critical
- Applies
- All scopes
- SecurityInspect Verified profiles
- VP-EXT
Control objective
No one can reach administrative or remote-access services for in-scope systems without strong authentication through a controlled path, because exposed administrative services are a common route to compromise.
Testable requirement
- 1.Administrative interfaces of in-scope systems must not be reachable from the internet except in one of these ways: (a) through an access gateway (VPN, zero-trust access broker or bastion host) that requires multi-factor authentication and is the only network path to the interface; (b) where the interface itself enforces multi-factor authentication for every user; or (c) for machine-to-machine administrative connections such as deployment pipelines, where access is restricted to named source addresses and authenticated with short-lived or hardware-bound credentials. Administrative interfaces include SSH, RDP, VNC, database listeners, hypervisor, storage and network-device management, container-orchestration control planes, cloud management consoles and the administrative functions of web applications.
- 2.All interactive remote access by workforce members and third parties to in-scope systems, or to networks that contain them, must require multi-factor authentication (see SIAS-IAM-02).
- 3.Remote-access gateways and administrative interfaces must not accept vendor-default or shared credentials, must not transmit credentials in cleartext, and must be patched within the SIAS-VPM-02 remediation times.
- 4.Cleartext administrative protocols (for example, Telnet, FTP, administrative pages over unencrypted HTTP, and SNMP versions without authentication and encryption across untrusted networks) must not be used for in-scope systems.
- 5.Remote administrative sessions must be logged (who, from where and when), and the logs kept under SIAS-LOG-02.
- 6.Administrative access paths must be removed when no longer needed. Vendor remote access must follow SIAS-TPR-04.
Applicability and scope
All scopes. Cannot be marked not applicable. SecurityInspect Verified profiles: VP-EXT (tested from the internet against the declared internet-facing assets; requirements 1, 3 and 4 are assessed in full, requirement 2 is assessed for every internet-reachable remote-access path by the direct test in E4, and requirements 5 and 6 are assessed for those paths from the applicant's records).
Pass criteria
- 1.A1 and A4 find no administrative interface reachable from the internet other than through a path that meets requirement 1(a), 1(b) or 1(c).
- 2.Every internet-reachable remote-access path required a second factor in the E4 direct test, and multi-factor policies have no exclusions other than break-glass accounts that meet SIAS-IAM-02 requirement 7. Where SIAS-IAM-02 is assessed, a failure of this criterion is recorded under SIAS-IAM-02; it is scored here only where SIAS-IAM-02 is not assessed, as in a VP-EXT profile (§2.11).
- 3.No default or shared credentials are accepted (by configuration review and any authorized check), and no credentials are transmitted in cleartext.
- 4.The product and version of every remote-access gateway and administrative interface was identified (A2). KEV-listed or overdue vulnerabilities found on them are recorded as findings under SIAS-VPM-02, not here (§2.11).
- 5.No cleartext administrative protocol is in use for in-scope systems.
- 6.Remote administrative sessions are logged for every sampled session.
- 7.Vendor remote access follows SIAS-TPR-04.
Severity
Critical. A failure is recorded as a Critical finding by default. It may be lowered one level only for a partial failure, with written rationale, quality-reviewer concurrence and approval by the second independent reviewer.
Informative framework mappings
- HIPAA Security Rule
- §164.312(d), §164.312(e)(1)
- PCI DSS v4.0.1
- 1.4, 8.4
- Trust Services Criteria
- CC6.6
- ISO/IEC 27001:2022
- A.8.5, A.8.20
- Theme (SecurityInspect wording)
- no administrative access without strong authentication
SIAS-NET-03 Endpoint protection and hardening
- Mandatory
- Yes
- Severity
- High
- Applies
- All scopes (workstations, laptops, mobile devices and servers used to access or administer in-scope systems)
- SecurityInspect Verified profiles
- None
Control objective
Devices that access, administer or run in-scope systems resist malware and misuse, and their security state is known.
Testable requirement
- 1.Every in-scope endpoint must be enrolled in central management (endpoint or mobile device management, or configuration management for servers) that reports its configuration and health.
- 2.Anti-malware or endpoint detection and response (EDR) software must be installed, active, updated and reporting centrally on every in-scope workstation, laptop and server whose platform supports it.
- 3.Endpoints must follow a documented hardening baseline based on a recognized public benchmark or the supplier's security guidance. The baseline must include at least: host firewall enabled; unnecessary services disabled; local administrator rights limited to named administrators; automatic screen lock after no more than 15 minutes of inactivity; and operating system and application security updates applied within the SIAS-VPM-02 and SIAS-VPM-03 times.
- 4.Laptops and mobile devices must have full-disk or device encryption enabled.
- 5.Administrative access to in-scope systems must be allowed only from managed endpoints that meet the baseline, for example by device conditions enforced in the identity provider. Unmanaged or personal devices may access in-scope data only through controls that prevent it from being stored locally (for example, application protection policies or virtual desktops).
- 6.The applicant must have a procedure for reporting lost or stolen devices and must be able to lock or wipe them remotely.
Applicability and scope
All scopes (workstations, laptops, mobile devices and servers used to access or administer in-scope systems). Cannot be marked not applicable. SecurityInspect Verified profiles: none.
Pass criteria
- 1.100% of endpoints used for administrative access to in-scope systems are managed, protected by EDR or anti-malware, encrypted (for laptops and mobile devices) and consistent with the baseline.
- 2.At least 95% of other in-scope endpoints meet requirements 1 to 4 at the time of testing, and every device that does not is blocked from in-scope access or has a remediation ticket due within 14 days.
- 3.Administrative access from unmanaged devices is technically blocked.
- 4.Screen lock is set to 15 minutes or less on every sampled device.
- 5.Every sampled EDR or anti-malware alert was triaged.
- 6.The lost or stolen device procedure exists, and every case in the look-back period was acted on.
Severity
High. Escalate a finding to Critical when EDR data or other evidence shows active compromise of an in-scope endpoint that has not been contained.
Informative framework mappings
- HIPAA Security Rule
- §164.308(a)(5)(ii)(B), §164.310(c), §164.312(a)(2)(iii)
- PCI DSS v4.0.1
- 1.5, 5.2, 5.3
- Trust Services Criteria
- CC6.8
- ISO/IEC 27001:2022
- A.8.1, A.8.7
- Theme (SecurityInspect wording)
- managed, protected and hardened devices
SIAS-NET-04 Wireless and remote-work network safeguards
- Mandatory
- No
- Severity
- Medium
- Applies
- Conditional — wireless networks or remote-work connections reach in-scope systems
- SecurityInspect Verified profiles
- None
Control objective
Wireless networks and remote-work connections do not give outsiders a way into in-scope systems.
Testable requirement
- 1.Wireless networks with a network path to in-scope systems must use WPA3 or WPA2-Enterprise. Networks that use WPA2 with a shared key, WPA, WEP or open authentication must have no network path to in-scope systems.
- 2.Guest and device (Internet of Things) wireless networks must be segmented from in-scope systems (see SIAS-NET-01).
- 3.Default credentials on wireless infrastructure must be changed, wireless management interfaces must not be reachable from guest networks, and wireless infrastructure must be patched within the SIAS-VPM-02 times.
- 4.At sites that host in-scope systems, the applicant must check for unauthorized wireless access points at least quarterly, by wireless scanning or wireless intrusion detection.
- 5.Remote-work access to in-scope systems must use an encrypted channel (VPN, zero-trust access broker or TLS to the in-scope application) from a managed endpoint that meets SIAS-NET-03, or through controls that prevent in-scope data from being stored locally. Home and public networks must be treated as untrusted.
- 6.The applicant should give remote workers written guidance on remote-work security, such as changing home router default passwords and caution on public networks.
Applicability and scope
Conditional — wireless networks or remote-work connections reach in-scope systems. Requirements 1 to 4 apply to sites with wireless networks that reach in-scope systems; requirement 5 applies where remote-work connections reach them. SecurityInspect Verified profiles: none.
Pass criteria
- 1.Every wireless network with a path to in-scope systems uses a permitted security mode.
- 2.The M2 test shows no path from guest or device networks to in-scope systems or wireless management interfaces.
- 3.Wireless infrastructure has no default credentials and no patch older than its SIAS-VPM-02 time.
- 4.Unauthorized access point checks were performed in every quarter of the look-back period (at least one for an initial assessment with a 90-day look-back).
- 5.Remote-work access to in-scope systems is encrypted and comes only from managed endpoints or through no-local-storage controls.
Severity
Medium. Escalate a finding to Critical on the standard triggers, for example where a guest wireless network gives unauthenticated access to Restricted data.
Informative framework mappings
- HIPAA Security Rule
- §164.312(e)(1)
- PCI DSS v4.0.1
- 2.3, 11.2
- Trust Services Criteria
- CC6.6
- ISO/IEC 27001:2022
- A.6.7, A.8.20
- Theme (SecurityInspect wording)
- safe wireless and remote connections
SIAS-NET-05 Email and domain security
- Mandatory
- No
- Severity
- Medium
- Applies
- Conditional — domain names are in scope or in-scope services send email
- SecurityInspect Verified profiles
- VP-EXT
Control objective
In-scope domains are hard to spoof, hijack or take over, and email reaching in-scope users is filtered for phishing.
Testable requirement
- 1.Every in-scope domain that sends email must publish an SPF record that ends in a fail or soft-fail policy and stays within the protocol's DNS lookup limit; must sign outbound mail with DKIM; and must publish a DMARC policy of quarantine or reject that applies to all mail, with aggregate reports received and reviewed.
- 2.Every in-scope domain that does not send email must publish records that reject all mail claiming to come from it: an SPF record that authorizes no senders and a DMARC reject policy.
- 3.DNS records for in-scope domains must not point to resources the applicant no longer controls (dangling records that could allow a subdomain takeover). Records must be removed when the resource they point to is decommissioned.
- 4.Registrar and DNS-hosting accounts for in-scope domains must be protected by multi-factor authentication, limited to named administrators and set to renew automatically. Primary domains should use registrar or registry lock where offered.
- 5.In-scope domains should publish CAA records that restrict certificate issuance. Sending domains should publish MTA-STS and TLS reporting. DNSSEC should be enabled where the DNS provider supports it.
- 6.Inbound email to in-scope users must be filtered for phishing, malicious attachments and malicious links, and users must have a way to report suspected phishing.
Applicability and scope
Conditional — domain names are in scope or in-scope services send email. SecurityInspect Verified profiles: VP-EXT (applies to the declared domains; requirement 6 applies when the declared domains receive email).
Pass criteria
- 1.Every sending domain has a valid SPF record within the lookup limit, DKIM signing for every legitimate sending source seen in the sampled DMARC reports, and a DMARC policy of quarantine or reject applied to all mail.
- 2.Every non-sending domain has an SPF record that authorizes no senders and a DMARC reject policy.
- 3.No dangling DNS record exists for any in-scope domain.
- 4.Registrar and DNS-hosting accounts use multi-factor authentication, have named administrators only and are set to auto-renew, and no in-scope domain is within 30 days of expiry without a confirmed renewal.
- 5.Inbound filtering and a phishing reporting mechanism are in place.
- 6.The "should" items in requirements 4 and 5 are recorded as Observations when absent; they do not affect the rating.
Severity
Medium. Escalate a finding to Critical when the tester confirms that a dangling record could be claimed by an unauthenticated party and the affected hostname would receive credentials or session tokens for an in-scope system.
Informative framework mappings
- HIPAA Security Rule
- No direct mapping
- PCI DSS v4.0.1
- 5.4
- Trust Services Criteria
- CC6.6
- ISO/IEC 27001:2022
- A.5.14, A.8.21
- Theme (SecurityInspect wording)
- protecting domains and email from abuse
