NIST has taken a look at how companies use Secure Shell (SSH), and doesn't much like what it sees.
In spite of the depth of access generally handed SSH implementations for a host of different activities – “file transfers, back-ups, software/patch management, disaster recovery, provisioning and data base updates”, as SSH (the company) says – users aren't working hard enough to protect those activities.
The report says: “Management of automated access requires proper provisioning, termination, and monitoring processes, just as interactive access by normal users does. However, the security of SSH-based automated access has been largely ignored to date”.
An SSH process running under a patch management system, it continues, will be given things root access to accounts or administrator-level access to the Oracle database. Security is, therefore, critical.
As always, the most important security considerations fall under the heading of “normal security practice”: NIST points to the vulnerabilities in old versions of SSH to recommend proper patch management; user accounts need to be managed and deleted if they're not required. SSH client/server configurations need to be watched, and keys need to be continually monitored and audited.
Many of the NIST recommendations echo the concerns expressed last year by the protocol's author Tatu Ylonen when he called for a new version of SSH. ®
Narrower topics
- Authentication
- Black Hat
- Common Vulnerability Scoring System
- Cybercrime
- Cybersecurity
- Cybersecurity and Infrastructure Security Agency
- Cybersecurity Information Sharing Act
- Data Breach
- Data Protection
- Data Theft
- DDoS
- Digital certificate
- Encryption
- Exploit
- Firewall
- Hacker
- Hacking
- Identity Theft
- Infosec
- Kenna Security
- NCSC
- Palo Alto Networks
- Password
- Phishing
- Ransomware
- REvil
- Spamming
- Spyware
- Surveillance
- TLS
- Trojan
- Trusted Platform Module
- Vulnerability
- Wannacry
- Zero trust
