How Not to Buy Insecure Software

By: (GCIH, GPEN, GWAPT)

Publication: Nebraska Banker , January 2016

Many of our vendor relationships have the power to help or hurt our Nebraska Banker Jan. 2015overall information security level.  The request for proposal (RFP) for software vendors must go beyond the typical due diligence questions in order to maintain or increase your information security level. Technical questions must be asked and it may be necessary to have the questions forwarded to the vendor’s technical support or development staff. Asking a software vendor the following questions and getting appropriate answers helps to ensure you are buying secure software and also reveals the maturity level of the vendor.

  1.  Does your software or any piece of your software require a user to be an “Administrator” on their workstation? Since users who are logged into their workstations with administrative levels of access are a high security risk, a vendor response of “yes” to this question should raise a red flag.
  2. Can all operating systems and third-party software patches be installed on systems as soon as they are released by manufacturers? The ability to quickly patch systems is a key control in preventing compromise. If a vendor indicates “no” to this question, dig deeper and find out what software can’t be patched, why, and if there are compensating controls you can utilize.
  3. Can all systems run antivirus software with scheduled and real-time scanning enabled? Inability to run antivirus on all systems raises a red flag.
  4. Does your product require a dedicated connection such as a T1 or VPN? Can access to and from the connection be restricted? When you have a dedicated connection with a vendor, potential traffic – good or bad – can come into your network. The initial entry point resulting in the 2013 Target compromise was a vendor VPN connection[i]. It is necessary to restrict origination and destination of vendor network traffic. Additionally, it is necessary to restrict internal systems’ access to the vendor by allowing only necessary network protocols and ports. If a vendor indicates “no” to this question, ask for more information. If the vendor continues to indicate no access restrictions, it is time to move to other vendors.
  5. What accounts, such as service accounts or interactive accounts, are necessary for the software to function? Having a good inventory accounts, including their owner and purpose, helps ensure vendor software is installed to specification and assists in future troubleshooting and documentation.
  6. What privilege levels do these accounts need on the domain and on local systems? Vendor accounts should be assigned with standard “Domain User” privileges within the domain. Specific elevated privileges can be assigned as necessary on specific servers. Often vendors will request a “Domain Administrator” account in order to install software. However, once installed with that level of privilege, it is frequently impossible to remove the administrative rights. The result is the vendor has access to your domain as an administrator. This should certainly raise a red flag. 
  7. Describe security measures and parameters for vendor accounts and default accounts in vendor-supplied software. Vendors may utilize pre-defined credentials within software or as part of the implementation process. The ability to specify and change strong passwords for accounts in the software is important for your network security. Find out whether password credentials are stored in clear text or encrypted within the software. 
  8. Is data transferred securely? Make sure software uses secure protocols for data transfer. If a vendor transfers with FTP, tell them “No thank you,” and ask if they support secure methods such as SFTP, HTTPS, or FTPS. 
  9. What methods are utilized to manage servers and software? Are these methods secure? Vendors often utilize web-based remote control software to provide support. Be sure any remote connections require the end user to initiate or acknowledge the connection, use encryption (HTTPS), and are only enabled for the duration of the support session.
  10. Technical documentation of how the software works. This includes lists of software utilized (operating systems, databases, web servers, etc.), technical network diagrams, and logical network diagrams. Include network ports and protocols used for communication and where they are used. Having this level of documentation for a system helps IT staff determine how the software will work in your environment and define any additional controls that may be needed.

By asking the right questions, you can choose a software vendor who will not bring down your organization’s information security level. In addition, your IT staff will have a better understanding of how the software operates will more efficient in troubleshooting and operations. Make sure you get requirements, service level agreements, penalties or exit clauses written into the contract before you sign. Then having a vendor adhere to the contract items will increase the organization’s security level, and will have a positive impact on your next IT audit and regulatory examination.  

Ty Purcell is a Security and Compliance Consultant for CoNetrix. CoNetrix is a provider of information security consulting, IT/GLBA audits and security testing, and tandem – a security and compliance software suite designed to help financial institutions create and maintain their Information Security Program. Visit our website at www.conetrix.com to learn how CoNetrix can improve your Cybersecurity maturity.

 

 



[i] Krebs, B. (2014, February 14). Target Hackers Broke in Via HVAC Company [Web log post]. Retrieved December 18, 2015 from http://krebsonsecurity.com/2014/02/target-hackers-broke-in-via-hvac-company/