Security is serious business! Don't be afraid to ask questions about Telnet and SSH. You want to clearly understand what you are purchasing.
SSH Server Security Q&A:
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. When evaluating security software keep an eye out for the words end-to-end and proprietary mixed.
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 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 do 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.
For more information on the Georgia SoftWorks UTS (Telnet Server and SSH Server), please visit our website or give us a call!
