Host and Networking Auditing
Auditing versus attacking
Auditing compares a system's actual configuration against a defined baseline or standard, without necessarily exploiting it. Typical work includes reviewing local users and groups, password and lockout policy, file and share permissions, installed software and patch levels, running services, scheduled tasks, logging and retention settings, firewall rules, and network device configurations. Frameworks such as CIS Benchmarks, ISO 27001, and PCI DSS provide the control language; the auditor's job is to gather evidence and state gaps.
Scanning and evidence
Vulnerability scanners like Nessus or OpenVAS are common audit tools. Know the difference between credentialed (authenticated) and uncredentialed scans: credentialed scans see installed packages, registry settings, and patch state, so they produce fewer false positives and more accurate results. Uncredentialed scans infer from banners and can misreport. Always validate scanner output manually. False positives are normal; false negatives are more dangerous because they create false confidence. Keep raw exports, screenshots, timestamps, and scope notes as evidence.
Traps candidates hit
A frequent trap is treating a clean scan as proof of security; scanners miss logic flaws, weak processes, and misconfigurations they cannot see. Another is confusing auditing with penetration testing: an audit may report that SMB signing is disabled; a penetration test would try to exploit relay or coercion. Questions may also ask about baselines, patch cadence, least privilege, and separation of duties. Be careful with compliance language: passing a checklist does not guarantee security, and a finding can be a process gap rather than a technical vulnerability.
Rule of thumb
Audit against a named baseline, prefer credentialed scanning where authorized, and verify every high-severity result before reporting. If you cannot show the evidence, mark the control as unverified rather than compliant.