User Accounts Are Only the Tip of the Iceberg
How to secure M2M connections and protect encrypted networks
By: Jonathan Lewis
Sep. 30, 2013 07:45 AM
Identity and access management solutions provide governance and visibility capabilities that enable organizations to provision and control access to their applications, cloud infrastructure, servers and both structured and unstructured data. Enterprise IAM deployments are generally effective in managing the identities assigned to interactive, human users. However, within a typical enterprise there often are a greater number of identities assigned to the automated processes that drive much of the computing in large- scale data centers. As enterprises adopt more and more process automation, the number of non-human identities continues to grow while the number of identities assigned to human users remains relatively flat or even declines. The net result is enterprise IAM deployments are ignoring the much larger set of identities that actually perform most of the enterprise computing functions.
The vast majority of the identities enabling machine to machine (M2M) processes use Secure Shell for authentication, authorization and to provide a secure encrypted channel for M2M data transfers. For example, an automated process that retrieves server log data requires an authenticated and authorized connection to each server, plus a secure channel to move the log data to a centralized processing application. Secure Shell is ideal for these functions because:
In spite of these advantages, there are significant gaps in IAM governance of identities that use Secure Shell. Typically, the provisioning of these identities is decentralized. Identities may be assigned by application developers, application owners and process owners. This often leads to a lack of proper control and oversight over creation of identities and their authorizations. Without central management and visibility, enterprises cannot be sure how many Secure Shell identities have been created, what these identities are authorized to perform and what authorizations are in fact no longer needed. The scope and nature of this problem are not theoretical. The typical enterprise server has between 8 and 100 Secure Shell authorizations (i.e., public Secure Shell user keys). This adds up. A large enterprise may have over one million keys, which in turn establish an even greater number of unmanaged machine-to-machine (M2M) trust relationships.
The Challenge of Ubiquitous Encryption
Shockingly, access to M2M encrypted channels via Secure Shell, which uses keys to authenticate a non-human user, almost always lacks proper identity and IAM controls, creating a huge risk and compliance issue for most enterprises. Any interactive user who has the proper credentials - in the case of Secure Shell, a simple copy of the key file - can hijack these uncontrolled M2M networks. This means that, in many cases, the most valuable information in the enterprise has the least amount of protection from unauthorized access.
Most large organizations have between 100,000 to well over a million of these keys in their network environments. Even though these keys grant access to critical systems and servers, many have never been changed. Even more incredibly, many organizations have no process for approving and enforcing who can grant permanent access to servers using these keys. One study at a large bank, with over one million keys in use, found that 10 percent of these keys granted unlimited administrative ("root") access to production servers; a grave security risk.
The lack of security controls - coupled with the high value of data it protects - has made Secure Shell a target for hackers. A recent IBM X-Force study found most attacks against Linux/Unix servers utilize stolen or lost Secure Shell keys as a threat vector. Because many keys are deployed in one-to-many relationships, it is possible that a single breach related to a compromised key could have a cascading effect across a large swath of the network environment.
In an ironic twist, the very function that blinds prying eyes from spying on sensitive data in-transit also prevents systems administrators from seeing whether information is being accessed improperly using a stolen Secure Shell key. All data-in-transit encryption, including Secure Shell, blinds layered security defense systems to malicious activity originating from a hacker, trusted insiders, business partners and outsourced IT. This means that unless the enterprise has deployed an encrypted channel monitoring, security operations and forensics teams cannot see what is happening in the encrypted network. Encrypted channel monitoring enables security intelligence and DLP solutions to inspect, store and - if need be - stop traffic to make sure hackers or malicious insiders cannot use Secure Shell encryption to spirit away information in an undetectable and untraceable manner. This way, the network administrator can track what a user is doing inside the encrypted channel, without exposing the data in the clear during transmission.
Evolving Standards to Include Other Authentication Methods
Currently, compliance bodies are updating their regulations to specifically include other methods of authentication above and beyond user names and passwords - such as certificates and keys - in their regulatory language. This means that auditors will be required to flag instances where access is not being controlled via Secure Shell. This is a natural progression for compliance mandates, arriving at a time when the market is beginning to recognize that strong standards are required to ensure the safety of the enterprise's most critical business information.
Best practices based Secure Shell key management enables strong authentication practices, including:
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week