M2M FEATURE

November 13, 2013

The Rise of the Machines: The Role of M2M in Identity and Access Management Strategies


While the main focus of IAM deployments has historically been on interactive, human users, in reality, these connections are just a small fraction of the access control and governance universe.

Identity and access management solutions provide governance and visibility capabilities that enable organizations to provision and control access to their applications, cloud, servers and both structured and unstructured data. The initial wave of IAM deployments have done admirable work with centralizing provisioning, enforcing policies and creating visibility in access control instances where user names and passwords are used. With so many different users, profiles and permissions, deploying these solutions is no easy feat.

Yet to deploy a truly comprehensive access control program, organizations will need to address uncontrolled access via other methods of authentication – including keys – that provide access to mission critical infrastructure and the enterprise’s most important data. This can seem daunting. In large environments, this can mean taking control of over one million keys and many times more unmanaged trust relationships – a daunting task.

Using Secure Shell for M2M Encryption

The biggest share 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 roles because:

  • Public key (PKI)-based authentication supported by Secure Shell enables credential presentation without requiring an interactive user (i.e., a person) to login via username and password or any other interactive authentication process.
  • Secure Shell-based PKI-based authentication process secures the login credentials. The private Secure Shell user key is never sent over the network.
  • Secure Shell provides definitions and limits to the functions a process may perform under a Secure Shell authorization. By doing so, it satisfies the “need to know, need to do” criteria of basic IAM governance.
  • Secure Shell ensures that data-in-transit is fully confidential through encryption of all transmitted data.

Even though Secure Shell has been a highly beneficial tool, there are significant gaps in the identity governance process that incorporate the use of Secure Shell. Usually these identities are provisioned in a decentralized process and assigned by application developers, application owners and process owners. This haphazard approach leads to a lack of proper control and oversight over creation of identities and their authorizations. Without central management and visibility, enterprises have no way of knowing how many Secure Shell identities exist within the network, what these identities are authorized to perform and what identities need to be removed altogether. The scope and nature of this problem are not theoretical. The typical enterprise server environment has anywhere between eight and 100 Secure Shell public Secure Shell user keys. Even more incredibly, a large enterprise may have well over one million keys, which raise the number unmanaged M2M trust relationships to truly untenable levels.

Is Comprehensive Network Encryption Possible?

While many in IT security use Secure Shell to securely access remote servers, most are surprised to discover that M2M communication makes up the majority – in some cases over 90 percent of all Secure Shell traffic – on their network. The vast majority of Secure Shell trust relationships provide access to production servers and carry high-value payloads; including credit card information, healthcare records, national secrets, intellectual property and other highly critical information.

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.

Given the sheer volume of these connections, along with the high sensitivity level of the data it carries, it’s astonishing that these M2M encrypted channels nearly always lack proper identity and IAM controls. This creates a huge risk and compliance issue for enterprises: any interactive user who has the proper credentials – even just a copy of the Secure Shell key file – can hijack these uncontrolled M2M networks. The end result is that the most valuable information in the enterprise often has the least amount of protection from unauthorized access.

The lack of security controls, especially when considering the high value of data it protects, has made Secure Shell a target for hackers. A recent IBM X-Force study found that most attacks against Linux and Unix servers use stolen or forgotten 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.

Tragically, the very function that prevents network insider espionage on data in-transit also prohibits 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 security systems to malicious activity originating from hackers, 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 view the flow of data within 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 ferret away data 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.

Compliance Standards Take Notice

Moving to protect themselves against both hacker attacks and security compliance mandates, many enterprises are strengthening interactive user authentication methods, including enforcing password complexity, requiring frequent password changes and deploying two-factor authentication. These methods are intended to prevent hacker attempts to access interactive accounts through brute force attacks, lost or stolen passwords or spoofed credentials. These approaches are now considered best practices and are highlighted in compliance standards like PCI, HIPAA, FISMA and SOX.

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

In order to ensure security and accountability, it is in the organization’s best interest to research, design and deploy an IAM strategy that includes processes designed specifically for M2M communications. A comprehensive IAM program designed around best practices-based and including provisions for Secure Shell-based M2M security must address provisioning and intelligence across large, complex and heterogeneous environments.

Best practices based Secure Shell key management enables strong authentication practices, including:

  • Monitoring traffic in encrypted channels
  • Discovery and continuous monitoring of trust relationships and unauthorized key deployments and removals
  • Restricting root access to servers so that only the key manager can provision or revoke keys
  • Controlling where each key can be used from and what commands can be executed using the key
  • Automated key creation, rotation and removal
  • Enforcing proper key type, size and version of Secure Shell

Moving Forward

In a market where the amount of network-connected users, devices and machines is exploding, it has become more critical than ever to make sure that the enterprise’s IAM strategy includes strong Secure Shell access controls to govern its M2M communications. IT security, compliance and audit teams alike must come together to address Secure Shell access control and governance issues. Without these controls, enterprises leave themselves open to risk of data compromise and running afoul of compliance mandates. By critically examining the organization’s Secure Shell environment, IT teams can control M2M access problems and keep their organizations’ data safe.




Edited by Rachel Ramsey


Back to m2m Evolution Home



COMMENTS

blog comments powered by Disqus


RELATED M2M ARTICLES




 
M2M Evolution Conference
The robust M2M conference program will focus on topics that inform and educate our audience of the latest and greatest technologies, current and future regulatory policies, new verticals, new applications and all of the hottest topics in Machine-to-Machine Industry. The M2M Evolution Conference is trending to become the leading educational and networking event in the M2M Industry and we’d like you to be a part of it.

Topics Include:
  • M2M and Smart Energy
  • M2M and Healthcare
  • M2M in the Enterprise
  • M2M and the Service Provider