This is part two of a two-part series. To read part one, click here.

Holes in IAM Governance
 

Identity and access management solutions assist in controlling the access to cloud infrastructure, applications, servers and both structured and unstructured data. These solutions are good at managing the identities assigned to interactive human users, but not so the larger number of identities assigned to the automated processes that drive much of the computing in large-scale data centers. As non-human identities continue to grow, IAM implementations are not addressing the majority of identities present in an enterprise: the identities performing the bulk of operations.

The majority of identities that enable M2M processes use Secure Shell for authentication and authorization because a secure encrypted channel is needed for M2M data transfers. However, holes exist in IAM governance of identities that use Secure Shell. Instead of a centralized provisioning procedure, application developers, application owners and process owners may all have identity creation and assignation privileges. 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.

Fundamental Questions
 

In light of open source vulnerabilities like Heartbleed, many organizations have followed Google’s lead in re-thinking how they use and manage open source technologies, both in their products and within their organization. And that’s a good thing. The point here is not that open source is bad. Rather, it is a call to action for technology executives to take another look at the critical but oft-forgotten infrastructure that their businesses are riding on, especially when it is something as ubiquitous and critical as encryption technologies like SSL or Secure Shell. Important questions to ask include:

• Are we properly managing our enterprise open source technologies?
• Do we know who is creating keys?
• Are we able to quickly address vulnerabilities by rotating keys or updating to new versions?
• Are we aware of who has access to what?
• Can we tell if someone has acted maliciously?
• Does either a vendor or internal resources properly support our open source software, or are we just hoping for the best?

A Strong (Security) Profile
 

In general, OpenSSL has done an amazing job of encrypting sensitive data for two-thirds of all websites and has done so on a shoestring. However, lack of sufficient funding and oversight allowed vulnerabilities to go unpatched for far too long. Unscrupulous actors are constantly on the lookout for any opportunity, and a vulnerability in encryption software is hacking gold. If a vulnerability can enable hackers to steal Secure Shell keys, which allow undetected access to your network, something has got to change – and fast.

Change comes in the form of greater visibility, strong IAM controls and centralized provisioning – all best practices for using OpenSSL and implementing Secure Shell protocol. Heartbleed showed the world how dangerous an OpenSSL vulnerability can be, but adhering to these best practices will close loopholes and enable greater insight into your security profile.

Matthew brings over 10 years of high technology sales, marketing and management experience to SSH Communications Security and is responsible for all revenue-generating operations. His expertise in strategically delivering technology solutions that anticipate the marketplace has helped the company become a market leader.

Prior to joining the company, Matthew served as a member of the executive management team of Automaster Oyj which was successfully acquired by ADP Dealer Services Nordic. Before this, Matthew played professional soccer in Germany and Finland.

Matthew holds a BA in German from the University of South Carolina and an MBA from the Helsinki School of Economics and Business Administration.