How ACSC Enables Security & Compliance

ACSC enables organizations to meet a number of key security and compliance requirements.

Risks without ACSC

ACSC mitigates a number major security risks, including:

• Unencrypted traffic that is subject to interception and alteration.
• Encrypted traffic with weak authentication (or other vulnerabilities).
• Exposed access to vulnerable servers or applications.
• Network connections that are not traceable to individual users and devices.
• Stolen, reused, or weak passwords.

Consequences of these risks

Not addressing these risks can have serious consequences:

• 84% of critical infrastructure incidents could have been prevented with security best practices such as asset and patch management, credential hardening, and the principle of least privilege (according to IBM Security X-Force Threat Intelligence Index 2024).
• In 70% of data breaches, attackers gained their initial access either via stolen credentials, phishing, or server/app vulnerability (according to the 2024 Verizon Data Breach Investigations Report).
• 90% of for-sale cloud assets on the dark web are cloud account credentials according to IBM Security X-Force Threat Intelligence Index 2024).

Security benefits to using ACSC

ACSC provides strong network security controls, including:

• All traffic (except select local connections) goes through ACSC.
• All inbound traffic is blocked except for access by users authenticated through ACSC.
• If outbound traffic is sent to the Internet, it is encrypted with strong encryption until it reaches the Anti-Cloud data center.
• If outbound traffic is sent to other ACSC endpoints, it is encrypted with strong encryption the whole way through.
• ACSC authentication & encryption uses strong 256-bit encryption keys with automatic key rotation.
• All ACSC connections are mutually authenticated.
• Users never have to use passwords for ACSC access, and never interact with ACSC keys directly.
• All access between ACSC endpoints is logged.
• ACSC cryptographically binds a private IP address to a user/device identity (therefore you can simply use IP addresses to identify/authenticate/authorize users on servers/apps protected by ACSC).

How ACSC prevents security incidents

According to both the 2024 Verizon Data Breach Investigations Report and the IBM Security X-Force Threat Intelligence Index 2024, the top three initial access vectors for security breaches are:

1. Weak or previously stolen credentials to valid accounts
2. Phishing for credentials (as part of the incident itself)
3. Exploiting unpatched application vulnerabilities

ACSC can prevent attacks that use these vectors. The key is to deploy ACSC on your systems, preventing network access to them except through ACSC.

ACSC prevents attackers from using weak or stolen credentials to access protected systems, because:

• ACSC credentials are 256-bit keys generated randomly, never reused, and rotated frequently.
• Strong keys means brute-force attacks won’t work on ACSC.
• Never reusing keys means credential stuffing attacks won’t work on ACSC.
• Frequent key rotations mean that even if keys are stolen, they are quickly rendered invalid.
• If MFA is used with ACSC, attackers must also steal the MFA device to authenticate with ACSC.
• If a smart card is used with ACSC, attackers must also physically steal the smart card to use ACSC.

ACSC prevents attackers from using phishing to access protected systems, because:

• End users never see or touch their ACSC credentials.
• Therefore, users can’t enter their credentials into a phishing webpage.

ACSC prevents attackers from exploiting vulnerabilities to access protected systems, because:

• Network access to protected systems requires using ACSC.
• Using ACSC requires valid credentials.
• Without valid credentials to ACSC, attackers have no way to access protected systems to exploit them.

HIPAA requirements ACSC can help meet

ACSC can help meet several HIPAA technical safeguards (section 164.312). If you use ACSC to protect systems which maintain or use PHI (Protected Health Information), then ACSC can help meet these requirements:

• Access control (164.312(a)): ACSC can ensure that only authorized people/programs have network access to systems which maintain PHI.
  • Unique user identification (164.312(a)(2)(i)): ACSC can ensure that a unique private IP address can be used to identify each specific person/program.
  • Encryption and decryption (164.312(a)(2)(iv)): ACSC can ensure that all network access to PHI is encrypted securely.
• Audit controls (164.312(b)): ACSC can log all network access to systems that maintain or use PHI.
• Person on entity authentication (164.312(d)): ACSC can authenticate all network connections to systems containing PHI.
• Transmission security (164.312(e)): ACSC can prevent unauthorized access to PHI when transmitted.
  • Encryption (164.312(e)(2)(ii)): ACSC can ensure that all PHI transmitted over the network is encrypted securely.

PCI requirements ACSC can help meet

ACSC can help meet several PCI DSS requirements. If you use ACSC to protect the systems in your CDE (Cardholder Data Environment), then ACSC can help meet these requirements:

• 1.2 Network security controls (NSCs) are configured and maintained.
  • ACSC can mitigate the risk for insecure network services, protocol, and ports (1.2.6).
• 1.3 Network access to and from the cardholder data environment (CDE) is restricted.
  • ACSC can restrict wired and wireless network traffic to only traffic that is necessary and has an authorized business purpose (1.3.1 & 1.3.2).
• 1.4 Network connections between trusted and untrusted networks are controlled.
  • ACSC can restrict traffic between trusted and untrusted networks to:
    • Prevent communications with trusted system components except that are authorized to provide publicly accessible network services, protocol, and ports (1.4.2).
    • Prevent forged source IP addresses from entering the trusted network (1.4.3).
    • Prevent system components that store cardholder data from being directly accessible from untrusted networks (1.4.4).
• 2.2 System components are configured and managed securely.
  • ACSC can reduce the risk of using insecure network services, protocol, and daemons (2.2.5).
  • ACSC can encrypt all network access using strong cryptography (2.2.7).
• 4.2 PAN (Primary Account Number) is protected with strong cryptography during transmission.
  • ACSC uses strong cryptography which does not allow insecure algorithms or key sizes; and it accepts only specific keys that have been individually allow-listed (4.2.1).
• 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.
  • ACSC can ensure that a unique private IP address can be used to identify each specific user (8.2.1).
  • ACSC can provide a mechanism for third-party network access which can be monitored, and disabled when not needed (8.2.7).
• 8.3 Strong authentication for users and administrators is established and managed.
  • ACSC uses strong authentication, using strong public-key cryptography that protects the authentication material (8.3.1 & 8.3.2).
• 8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.
  • ACSC can require MFA for all network access (8.4.1, 8.4.2, & 8.4.3).