European Reseller

Helping bring new products to market

Friday, Oct 31st

Last updateFri, 31 Oct 2014 9am

You are here: Home Security Delivering M2M Security Within Encrypted Networks

Delivering M2M Security Within Encrypted Networks

J.Lewis WEB

Delivering M2M Security Within Encrypted Networks

 As cloud services explode in popularity, enterprises are increasingly turning to their channel partners for governance and visibility options that enable them to provision and control access to their applications, cloud infrastructure, servers and both structured and unstructured data. For the most part, those solutions today mainly take the form of enterprise identity and access management (IAM) strategies, which are generally effective in managing the identities assigned to interactive, human users.

 

Jonathan Lewis, director of product marketing, SSH Communications Security

With the rise of embedded devices within the network environment, however, the number of identities assigned to the automated processes that drive much of the computing in large-scale data centers is rapidly outstripping the number of identities assigned to human users. In fact, as enterprises adopt more and more process automation, the number of non-human identities has continued to grow even as the number of identities assigned to human users has remained stable or even declines.  The ultimate result is that enterprise IAM deployments ignore the lion’s share of identities that perform most of the enterprise’s computing functions.

One sensible place to begin examination of a strategy’s IAM robustness is to examine how it secures and manages network access for automated processes. The vast majority of the identities enabling these 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:

·         It provides facilities to define and limit what functions a process may perform under a Secure Shell authorization. This meets “need to know, need to do” criteria of basic IAM governance.

·         Public key (PKI) based authentication supported by Secure Shell enables the process to present its credentials without requiring an interactive user to login via username and password – or via any other interactive authentication process.

·         The PKI based authentication process used by Secure Shell provides security for the login credentials. The private Secure Shell user key is never sent over the network.

·         Finally, Secure Shell provides for confidentiality of data-in-transit. Communications over a Secure Shell channel are encrypted.

Despite these benefits, identities that use Secure Shell often suffer from significant gaps in IAM governance. Normally, the provisioning of these identities is decentralized. Identities might be provisioned by app developers, app 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 ensure the number of Secure Shell identities within their network environments, what these identities are authorized to perform and which authorizations can be retired. These problems are not conjecture. The average server can have anywhere from eight to over a hundred Secure Shell authorizations (i.e., public Secure Shell user keys). A large enterprise may have over one million keys, which likewise leads to an even greater number of unmanaged M2M trust relationships.

A Completely Encrypted Environment: Costs and Benefits

While many in IT security use Secure Shell to access servers remotely, 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.

Incredibly, 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 enterprises that find themselves in this situation. Any interactive user who has the proper credentials (in the case of Secure Shell, this can be simply a copy of the key file) can hijack these uncontrolled M2M networks. This means that, in many cases, the enterprise’s most valuable information has the least amount of protection from unauthorized access.

 

As noted earlier, most large enterprises 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.  Unbelievably, many organizations have no process for approving and enforcing which administrators can grant permanent access to servers using these keys.  One study at a large bank found that 10 percent of the bank’s 1,000,000+ keys granted unlimited administrative (“root”) access to production servers, a grave security risk.

 

The lack of sufficient security controls, combined with the sensitivity of data it protects, has made Secure Shell a target for hackers. A recent IBM X-Force study found that 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 therefore possible that a single breach related to a compromised key could have a cascading effect across a broad section of the network environment.

 

In a tragic twist, the very function that prevents malicious insiders from spying on sensitive data-in-transit also prevents sysadmins from knowing whether information is being spied on using a stolen Secure Shell key.  All data-in-transit encryption, including Secure Shell, blinds layered security defense systems to malicious activity from hackers, trusted insiders, business partners or outsourced IT. This means that unless the enterprise has deployed encrypted channel monitoring, neither security nor forensics teams can watch what is happening 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 spirit away information undetected. Instead, 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 on Today’s Security Needs

Moving to protect themselves against both hacker attacks and security compliance mandates, many enterprises are bolstering interactive user authentication methods; including enforcing password strength, requiring periodic password changes and implementing two-factor authentication. These methodologies are designed to confound hacker attempts to access interactive accounts through brute force attacks, lost or stolen passwords, or spoofed credentials. These approaches, considered best practices today, are codified in compliance requirements like HIPAA, PCI, FISMA, SOX.

 

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

A holistic IAM program based on best practices and including provisions for Secure Shell-based M2M security must address both the provisioning and intelligence aspects of IAM across large, complex and heterogeneous environments. To provide the highest levels of security and accountability, it is in the organization’s best interest to research, design and deploy an IAM strategy that includes processes tailor-made for M2M communications.

 

Best practices include:

·         Discovery and continuous monitoring of trust relationships and unauthorized key deployments and removals

·         Enforcing proper key type, size and version of Secure Shell

·         Controlling where each key can be used from and what commands can be executed using the key

·         Monitoring traffic in encrypted channels

·         Restricting root access to servers so that only the key manager can provision or revoke keys

·         Automated key creation, rotation and removal

 

Looking Ahead

While ubiquitous encryption can deliver clear benefits for network security, if left unmanaged it can present a significant threat to the business. Professionals in compliance, audit and security must address Secure Shell access control and governance issues. The absence of controls creates security vulnerabilities and can cause an organization to run afoul of compliance mandates, resulting in the risk of fines and other liabilities. In an environment where ever-increasing numbers of users, devices and machines are connected to the Internet and the company network, ensuring that the enterprise’s IAM strategy includes strong Secure Shell access controls in M2M communications is mission-critical.

 

About the Author:

Jonathan Lewis is director of product marketing for SSH Communications Security, where he is responsible for communicating the value and importance of effective Secure Shell access governance. Jonathan has diverse experience in the network and security industry including technical and business management roles at companies ranging from start-ups to global enterprises.  His technology expertise includes VPN, Firewall, SSL, SSH and DDoS mitigation. Jonathan holds BS and MS degrees from McGill University and an MBA from Bentley College.

·         Finally, Secure Shell provides for confidentiality of data-in-transit. Communications over a Secure Shell channel are encrypted.

 

Despite these benefits, identities that use Secure Shell often suffer from significant gaps in IAM governance. Normally, the provisioning of these identities is decentralized. Identities might be provisioned by app developers, app 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 ensure the number of Secure Shell identities within their network environments, what these identities are authorized to perform and which authorizations can be retired. These problems are not conjecture. The average server can have anywhere from eight to over a hundred Secure Shell authorizations (i.e., public Secure Shell user keys). A large enterprise may have over one million keys, which likewise leads to an even greater number of unmanaged M2M trust relationships.

 

A Completely Encrypted Environment: Costs and Benefits

While many in IT security use Secure Shell to access servers remotely, 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.

 

Incredibly, 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 enterprises that find themselves in this situation. Any interactive user who has the proper credentials (in the case of Secure Shell, this can be simply a copy of the key file) can hijack these uncontrolled M2M networks. This means that, in many cases, the enterprise’s most valuable information has the least amount of protection from unauthorized access.

 

As noted earlier, most large enterprises 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.  Unbelievably, many organizations have no process for approving and enforcing which administrators can grant permanent access to servers using these keys.  One study at a large bank found that 10 percent of the bank’s 1,000,000+ keys granted unlimited administrative (“root”) access to production servers, a grave security risk.

 

The lack of sufficient security controls, combined with the sensitivity of data it protects, has made Secure Shell a target for hackers. A recent IBM X-Force study found that 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 therefore possible that a single breach related to a compromised key could have a cascading effect across a broad section of the network environment.

 

In a tragic twist, the very function that prevents malicious insiders from spying on sensitive data-in-transit also prevents sysadmins from knowing whether information is being spied on using a stolen Secure Shell key.  All data-in-transit encryption, including Secure Shell, blinds layered security defense systems to malicious activity from hackers, trusted insiders, business partners or outsourced IT. This means that unless the enterprise has deployed encrypted channel monitoring, neither security nor forensics teams can watch what is happening 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 spirit away information undetected. Instead, 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 on Today’s Security Needs

Moving to protect themselves against both hacker attacks and security compliance mandates, many enterprises are bolstering interactive user authentication methods; including enforcing password strength, requiring periodic password changes and implementing two-factor authentication. These methodologies are designed to confound hacker attempts to access interactive accounts through brute force attacks, lost or stolen passwords, or spoofed credentials. These approaches, considered best practices today, are codified in compliance requirements like HIPAA, PCI, FISMA, SOX.

 

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

A holistic IAM program based on best practices and including provisions for Secure Shell-based M2M security must address both the provisioning and intelligence aspects of IAM across large, complex and heterogeneous environments. To provide the highest levels of security and accountability, it is in the organization’s best interest to research, design and deploy an IAM strategy that includes processes tailor-made for M2M communications.

 

Best practices include:

·         Discovery and continuous monitoring of trust relationships and unauthorized key deployments and removals

·         Enforcing proper key type, size and version of Secure Shell

·         Controlling where each key can be used from and what commands can be executed using the key

·         Monitoring traffic in encrypted channels

·         Restricting root access to servers so that only the key manager can provision or revoke keys

·         Automated key creation, rotation and removal

 

Looking Ahead

While ubiquitous encryption can deliver clear benefits for network security, if left unmanaged it can present a significant threat to the business. Professionals in compliance, audit and security must address Secure Shell access control and governance issues. The absence of controls creates security vulnerabilities and can cause an organization to run afoul of compliance mandates, resulting in the risk of fines and other liabilities. In an environment where ever-increasing numbers of users, devices and machines are connected to the Internet and the company network, ensuring that the enterprise’s IAM strategy includes strong Secure Shell access controls in M2M communications is mission-critical.

 

About the Author:

Jonathan Lewis is director of product marketing for SSH Communications Security, where he is responsible for communicating the value and importance of effective Secure Shell access governance. Jonathan has diverse experience in the network and security industry including technical and business management roles at companies ranging from start-ups to global enterprises.  His technology expertise includes VPN, Firewall, SSL, SSH and DDoS mitigation. Jonathan holds BS and MS degrees from McGill University and an MBA from Bentley College.