An upcoming audit is often synonymous with activities, such as pulling together a series of reports and spreadsheets ready to be handed over to the auditor. But is it as simple as that? And is this true for SSH audits? Here are some reasons why a simple spreadsheet may not adequately prepare you for when an internal or external auditor steps through your door.

Worried about audit failures due to SSH risks? Here’s some advice.

1. You’ll need an understanding of your organization’s risk appetite

Audits have a specific purpose. While most of us think about compliance requirements like PCI DSS, Sarbanes-Oxley or Basel II/III; SSH audits are really more about demonstrating a specific area of IT risk. In other words, SSH risk audits are never a stand-alone process but usually go hand in hand with a strong understanding of existing enterprise policies and risk frameworks. During an SSH audit, special attention should be paid to HUMAN user awareness about SSH risks and whether required policies are in place. This human factor is often a weak part of any security risk pyramid. Bottom line, SSH audits should align with enterprise risk appetite and the related governance practices. This requires a culture that cannot be easily captured in a single spreadsheet.

2. You’ll need a workflow and 360-degree documentation of trusted relationships

SSH keys enable trusted relationships between accounts on assets. Once these trusted relationships are in place, the accompanying SSH keys can act on their own and don’t necessarily require any additional authorization. This is one of the core reasons why SSH audits are growing in popularity. This also means that prior to deployment, approvals may be required, including a clear description of where these connections will operate.

Documentation for this is not easily captured in a single or multi column spreadsheet. It requires you to have a workflow process in place whereby SSH keys can be requested, reviewed, and approved by humans, then followed by a step that documents these actions. It also may require capturing certain trust relationships in the form of network diagram, zones, or firewall rules exceptions made to enable these connections. In summary, before an SSH audit, you should implement a workflow and be able to capture broader context.

3. You’ll need a deep understanding of the purpose of SSH keys

SSH keys are implemented or used for a certain purpose. For example, they can be used for continuous automation, data transfer using SCP/SFTP, or orchestration of different often specialized IT processes. Auditors may be interested in these specific use cases and challenge InfoSec or risk teams as to why these keys exist with a certain privilege. To effectively answer these questions, InfoSec and risk teams need to have an understanding of IT workflows and their users so they can revoke unnecessary root access. Again, the capturing of this information often extends beyond the limits of a single spreadsheet and requires good understanding of the entire business IT ecosystem.

4. You’ll need to track the deployment of SSH keys and configurations

SSH configuration and keys that are deployed across a broad network leave you with a special type of animal to manage. Rather than just a single common config file, SSH keys can be highly customized by asset type and IT use case. In this sense, SSH keys are not excluded from configuration rules; they live in pairs and may need to match a certain length or can’t exceed a maximum lifetime. Configuring this manually from a single location is a no-go as InfoSec teams will need specialized tools to cope with very high volume of keys (thousands to millions) and a wide variety of SSH entities.

5. You’ll need to prove assurance via continuous monitoring

All actions taken place in step 4 are not a guarantee for passing an audit. Humans in the form of IT admins, adversarial activity, and configuration errors may slowly introduce new, weak keys that can be exploited by backdoors. In other words, you’ll need a continuous monitoring loop to baseline and evaluate the entire SSH deployment for usage or deployment exceptions. This is almost never done via a single tool but usually requires logging, baselining, and remediation mechanisms that are well outside the scope of a single spreadsheet.

Conclusion

SSH is a key component in most IT environments. In depth SSH audits will become more prevalent as regulations adopt new risk practices. A spreadsheet may be useful for tracking steps in place or as starting point, but you’ll need a broader subset of processes and tools to adequately prepare for an audit that involves SSH.

Related posts

Authors

Topics

Subscribe to our Weekly Blog Updates!