Volume 6
or control . Unlike passwords , an administrator , developer or third-party vendor can provision themselves access to your critical infrastructure or automate a process or file transfer . This process of provisioning , de-provisioning and recertification of SSH user key-based access is infrequently if never addressed in the IAM frameworks of enterprises .
Second , SSH user keys — unlike certificates — don ’ t have expiration dates . This means that SSH user key-based access continues to exist , even after an application is decommissioned or a user leaves the company .
Thirdly , an SSH user key does not need to be associated to a user account . This means a key will not necessarily establish the identity of the user associated with it . When an SSH user key is generated , the identity that associated is not connected .
To summarize , a user can provision SSH user keybased access themselves without oversight to my most critical infrastructure . This key-based access does not expire . Does that mean it is not clear which identity it is associated with ? And there are millions of these across my enterprise , which we don ’ t have an inventory of , and they are providing access to my most critical systems ? Yes .
Lack of Understanding of the Potential Impact
In tandem with the lack of understanding of the technical aspects of the SSH protocol , together with the lack of regulatory oversight and governance of SSH user key-based access , we have an additional concern .
July-Aug 2016 Edition
to gain access to new assets and further elevate privilege , as well as how they exfiltrate data and assets from an organization . In fact , LightCyber ’ s Cyberweapons 2016 Report indicates that in over 50 percent of the cases , the SSH protocol is the tool of choice to gain this lateral movement across the assets of an enterprise .
Furthermore , the malicious actors are aware that SSH user keys are not being managed and , as a result , they go after private keys to gain access to assets . From there , they will often create new key pairs , which will generate them access to the outside directly or move those assets automatically to servers in the cloud . This is all achieved using something called “ port forwarding ” via “ SSH tunneling ,” which would allow the malicious actor to extract this data via the encryption itself , rendering firewalls ineffective .
And this is all happening under our noses . Why ? Because we don ’ t know who owns the keys to attain that encrypted access and because we are not able to look inside the encryption of those sessions .
The potential impact is clear . We lose our data – or worse , our customer ’ s data . We lose our intellectual property . We lose our reputation , we lose our brand and , in turn , we lose revenue and shareholder value .
In addition to the financial impacts , the other consideration is operational resilience . The potential downtime in critical systems , should SSH user keybased access to those systems be compromised , is a concern we need to consider seriously . Our disaster recovery systems , which are failovers to our production systems , often share identical SSH user keys that ensure the processes of those systems fail over in an identical manner . This means that any compromised keys in production environments can also equally affect the failover to disaster recovery systems . So are SSH user keys the “ Big Short ” of the security industry ?
SSH is the malicious actor ’ s ( either a rogue insider or hacker ) tool of choice , and it is the primary means by which they move laterally within an enterprise
The parallels are uncanny . All the ingredients are there . We have a lack of market understanding around the power of the SSH protocol and the criticality of the access it provides to our infrastructures . We have a gap in regulatory and governing
49