SSH vs RDP Auditing: CISA Comparison Guide
SSH vs RDP auditing involves evaluating remote access security. Auditors must verify that SSH (Port 22) and RDP (Port 3389) are not exposed to the public internet, prioritize key-based authentication over passwords, and ensure robust session logging is enabled to maintain an immutable audit trail for compliance.
What are the core differences between SSH and RDP from an auditor's perspective?
When you're auditing remote access, you first need to understand the nature of the beast. Secure Shell (SSH) is primarily a command-line interface (CLI) tool used mostly for Linux/Unix systems. Remote Desktop Protocol (RDP) provides a full graphical user interface (GUI), typically for Windows environments. From a CISA perspective, the difference isn't just about the interface; it's about the attack surface.
SSH is generally leaner and more efficient, but RDP's graphical nature often introduces more vulnerabilities and a larger footprint for attackers to exploit. As an auditor, you aren't just checking if the tool works—you're evaluating whether the tool's capabilities align with the principle of least privilege. If a user only needs to restart a service, why are they using a full RDP session when an SSH command would suffice?
How should you audit port configurations and internet exposure?
This is a classic CISA exam topic. You'll be looking at Port 22 for SSH and Port 3389 for RDP. The golden rule here is simple: these ports should never be open to the wide-open internet (0.0.0.0/0). If you see this in your audit evidence, it's an immediate critical finding. Publicly exposed RDP ports are essentially beacons for brute-force attacks and ransomware.
During your review, look for the implementation of a VPN or a Jump Box (Bastion Host). A secure architecture requires the user to authenticate to a secure gateway before they can even attempt to connect to the internal SSH or RDP port. Use tools like Nmap to verify that these ports are filtered or closed to external traffic and only accessible via authorized internal segments.
Which authentication methods provide the strongest audit trail?
Password-based authentication is the baseline, but for a high-maturity organization, it's a weakness. For SSH, you should be looking for key-based authentication. Public/private key pairs are significantly harder to brute-force than passwords and provide a stronger tie to a specific device or user.
For RDP, your audit should focus on Network Level Authentication (NLA) and Multi-Factor Authentication (MFA). NLA is crucial because it requires the user to authenticate before a full RDP session is established, reducing the risk of Denial of Service (DoS) attacks. As an auditor, check the password policy: are they rotating? Are the keys stored in a secure vault? If the organization is still relying on single-factor passwords for remote admin access, you've found a significant control gap.
How do you evaluate session logging and auditing capabilities?
Knowing who logged in is only half the battle; you need to know what they actually did. For SSH, you'll want to review the `syslog` or `auth.log` files to track login attempts and sudo commands. For RDP, the Windows Event Viewer is your best friend—specifically Event ID 4624 (Successful Logon).
However, local logs are a risk because a privileged user can simply delete them to hide their tracks. To pass a rigorous CISA-level audit, the organization must use centralized logging, such as a SIEM (Security Information and Event Management) system. This ensures that logs are streamed in real-time to a write-once-read-many (WORM) storage location, creating an immutable audit trail that cannot be tampered with by the system administrator.
What are the common CISA pitfalls when auditing remote access?
Many candidates make the mistake of only auditing the 'official' policy and ignoring 'shadow IT.' In the real world, developers often open a temporary RDP port to fix a bug and forget to close it. As an auditor, you must verify the actual state of the network, not just the documentation.
Another common trap is overlooking legacy accounts or 'test' accounts that have administrative privileges. This is where consistent practice is key. At Cert Sensei, we provide 1,000 expert-curated ISACA CISA practice questions with detailed expert reasoning and domain-level analytics. We help you train your brain to look for these subtle gaps, ensuring you don't miss a critical finding during the exam or in your professional career.
How do these protocols impact the overall risk profile of an organization?
Ultimately, SSH and RDP are the primary gateways for lateral movement. If an attacker compromises a single set of credentials, they can use RDP to jump from workstation to server, often with a GUI that makes it easy to explore the network. SSH can be just as dangerous if the user has root privileges without restriction.
Your audit should evaluate the 'Sudoers' file for SSH and the 'Remote Desktop Users' group for RDP. Are these groups bloated? Is there a quarterly review of who has remote access? By focusing on the lifecycle of the access—from request to revocation—you transition from a simple technical check to a comprehensive governance audit.
❓ Frequently Asked Questions
Should I recommend changing default ports (e.g., 22 to 2222) to improve security?
No. This is 'security by obscurity' and does not stop a determined attacker using a port scanner. Instead, recommend a VPN, a Jump Box, or IP whitelisting to actually secure the access.
Is RDP inherently less secure than SSH?
Not necessarily, but it has a larger attack surface due to the complexity of the GUI and the underlying Windows protocols. When properly configured with NLA and MFA, it is highly secure.
How often should remote access logs be reviewed for CISA compliance?
While frequency depends on the risk profile, the industry standard is automated, real-time alerting via a SIEM for failed login attempts or unauthorized access to critical servers.