Security Vulnerabilities

Have new ideas for the next release of IHMC CmapTools and IHMC CmapServer?
We welcome your suggestions and we will carefully consider whether to incorporate them into the software.
Post Reply
ncgreenfield
Posts: 5
Joined: Wed Oct 29, 2014 8:38 am

Security Vulnerabilities

Post by ncgreenfield »

I've been trying to get IHMC CmapTools and CmapServer introduced into my organization, however, because this is 'open source', there's a concern regarding software vulnerabilities in the tool.

It would be great if the tool could be scanned for any software vulnerabilities and then post the results on the site.
acanas
Posts: 753
Joined: Tue Mar 17, 2009 5:52 pm

Re: Security Vulnerabilities

Post by acanas »

CmapTools is not open source. Its been examined and authorized for use internally at the US Navy, NSA, an many other such organizations. Send me a message if you need contacts to get in touch with.
ncgreenfield
Posts: 5
Joined: Wed Oct 29, 2014 8:38 am

Re: Security Vulnerabilities

Post by ncgreenfield »

Okay, I understand the misunderstanding I had regarding CmapTools when I thought it was open source. So I do realize that CmapTools is actually proprietary software.

I'm at the final leg of getting this software approved in my organization, however, I'm required to provide "hard evidence" that details how this product counters potential vulnerabilities based upon 2 questions that I answered "YES" from my organization's internal submission process:

1. RISK: Does this product provide a remote access capability or allow remote sharing of information? YES
: Limit use of remote takeover/sharing products & tools to those that provide strong authentication, secure (encrypted) comms channels, clean end user driven session break, close on user timeout etc and provide controls to limit (block) exfiltration of data and session recording.

2. RISK: Does this product have accounts used (or provide the ability to elevate account access rights) to administer configurations settings or the access rights of other accounts? YES
: What controls are in place to ensure access is approved in advance? What controls are in place to ensure access is logged? What controls are in place to manage data sharing? How is communications secured? How is monitoring handled to ensure data sharing isn't compromised?

For the CmapServer, I understand the 'risks'. I'm not so sure about the CmapTools side of the equation.

Since I'm required to submit 'hard evidence', or at least provide a link to a website or case study, I'll be able to push this forward to get it adopted in my organization (hopefully).
acanas
Posts: 753
Joined: Tue Mar 17, 2009 5:52 pm

Re: Security Vulnerabilities

Post by acanas »

Hi,

From the client point of view, there is no chance the data in the client can be reached from another computer through the CmapTools client itself. There are no accounts involved in the CmapTools client. So the risks are the same as, say, a word processor or spreadsheet program.

Regarding the CmapServer
1. RISK: Does this product provide a remote access capability or allow remote sharing of information? YES
: Limit use of remote takeover/sharing products & tools to those that provide strong authentication, secure (encrypted) comms channels, clean end user driven session break, close on user timeout etc and provide controls to limit (block) exfiltration of data and session recording.
Access to a CmapServer can be configured to be SSL, and the client can be configured to only access CmapServers configured to use SSL. PKI encyrption can also be configured for the client-server authentication.

The client does not open a session with the CmapServer and maintain the session open. Each transaction (e.g. open a Cmap, close a Cmap, get the content of a folder) is independent and therefore independently validated through the userid+password authentication. If and upload or download breaks, the 'session' is closed after a timeout. So there is no chance of leaving a session open. When a Cmap stored on a CmapServer is being edited, a 'hearbeat' message is sent by the client to the server so the server maintains the file locked.

The client does provide session recording in the sense that the construction of a Cmap can be recorded, but this does not involve the communication with the CmapServer.

When in synchronous collaboration, client-to-client communication is all through the CmapServer, there is no direct communication between clients. The synchronous collaboration can be turned off in the CmapServer configuration.
2. RISK: Does this product have accounts used (or provide the ability to elevate account access rights) to administer configurations settings or the access rights of other accounts? YES
: What controls are in place to ensure access is approved in advance? What controls are in place to ensure access is logged? What controls are in place to manage data sharing? How is communications secured? How is monitoring handled to ensure data sharing isn't compromised?
The CmapServer uses two authentication schemes: userid+password stored in each project.idx file on each folder, and LDAP. There is a 'master' userid+password that is stored encrypted in the CmapServer's configuration file, but this file is in a separate folder from the resources (Cmaps, etc.) -- no way to access it using the CmapTools client. If desired, the serverRootFolder (where the user files are stored) can be located on a separate drive than the configuration file. Since every operation is a separate transaction, every operation (open, save, move, list contents, etc.) is validated for permissions separately.

The CmapServer does not provide a separate log of user access.

Data sharing is controlled through permissions at the folder level (see http://cmap.ihmc.us/Publications/WhiteP ... pTools.pdf). When the folder is created, the permissions (and administrator) are seet.

The communication is secured by configuring the server to only use SSL communication. No monitoring is done to ensure data sharing isn't compromised.

Hope this helps. There are no studies regarding vulnerabilities, as far as we know.
Post Reply