2011 at GSW
GUI Config Tool
Windows Explorer style interface allowing provisioning and configuration management. Familiar to use operations such as copy, paste, rename, delete, export, import are applied to configurations on a user or system basis. Create templates and quickly view summary configuration data.
TEAM SERVICES provides your mobile device users a breakthrough in Telnet/SSH2 technology that shatters all prior usability and efficiency standards by allowing unprecedented user collaboration. Now mobile device users are empowered to share resources, transfer, swap, share and recover dropped sessions. All from the mobile device, no system administrator necessary. All operations can be performed in under 60 seconds.
Video Overviews
Team Services the first feature set to offer Video overviews. We are excited to provide additional methods to meet customer expectations. Visit the GSW Video Channel!
Request a Webinar
Want to know more about UTS, RC MDMS or GSWBrowse? Request a Webinar. Give us a call or use our contact form and request a webinar.
Privacy Policy - Terms of Use
Security Options with the GSW UTS
Security is Serious Business - Ask Questions! - View PDF Version
| Question | When Should I use Proprietary Encryption Protocols? |
| Answer | Almost never. Your application should be
designed in such a way that a standard cryptographic protocol can be
used. Don't be fooled by companies intermixing words like proprietary or customer encryption with terms such as AES, 3DES, Blowfish, etc. What this means is that the vendor is using standard cryptographic algorithms mixed up with their own proprietary cryptographic algorithm. Encryption algorithms are just a small part of a cryptographic protocol. You can bet the weak link is the proprietary component. MAJOR RED FLAG. |
| Question | A vendor claims to use SSH but when I look closely, it does not look like it is being used END to END. |
| Answer | Some companies claim to have SSH but when you examine their claim, SSH may only be used within the server but things change to proprietary from the server to the devices, which is where the data is most vulnerable. In this case the weakest link is the transmission of data from the server to the device, making the entire solution unsecure. Again, when evaluating security software keep an eye out for the words end-to-end and proprietary mixed. |
| Question | A vendor claims to have FIPS 140-2 but they don't have a FIPS 140-2 compliant client. |
| Answer | Again as unfortunate as it is, some companies claim to have features when they simply just not not. They may be compliant on parts of the server, but if its not FIP 140-2 complaint on the client then its not compliant END to END. |
| Question | Why is proprietary Encryption a Red Flag? |
| Answer | Existing Cryptography for our industry is quite
good dues to dedicated, highly skilled mathematicians and the best
cryptographers at security agencies such as the NSA (National Security
Agency) and first class universities. Good cryptography algorithms
require complicated mathematics in addition to expensive technologies
for development. Algorithm acceptance requires testing and scrutiny of
many brilliant people as well as industry peer review and time in the
field. Commercial software vendors typically venture in to the proprietary cryptographic arena to save time or money. A few "sharp" engineers creating a proprietary cryptographic algorithm is not remotely comparable to established cryptographic algorithms standardized by dedicated agencies, often looking 20+ years into the future. At best it is arrogant when software vendors believe they can do a better job than the professional cryptographers; at worst customer systems are breached. |
| Question | Our vendor says they developed their own cryptographic protocol? |
| Answer | Run, Run, Run as fast as you can! Encryption protocols are extremely difficult to design and are not for the faint of heart. This is a very dangerous situation because there is a false sense of security. Developers often believe they have correctly implement a cryptographic protocol or encryption algorithm only to late find out that many significant potential exploits and other security risks exist after many months of deployment. There is no replacement for many years of public scrutiny and testing. . |
| Question | Our vendor refuses to give details of their cryptographic protocol design on the grounds that it jeopardizes the security of the solution? |
| Answer | All standard cryptographic protocols are described in detail on the level of design. Your vendor is trying to achieve security by obscurity. This simply does not work because of all the hardware and software tracing tools available to determined hackers. Security by obscurity can never work. |
