In-house Application (Software) – An Internal Audit Perspective


In-house applications, which are software applications developed by an organization for its own internal use, are becoming more and more prevalent. UKIA’s clients say it is because they “can create it themselves for less” and that “any purchased product will have to be customized and is therefore a waste of time and money.”
UK Internal Audit (UKIA) conducts information technology (IT) audits around the University and across the state. Through these reviews, UKIA has noted both advantages and disadvantages associated with developing in-house applications.
 
Advantages:

  • Software can be written to operate using the organization’s business procedures, whereas third-party software often requires the organization to conform to business practices set by the application developer. These preset business practices may not serve the organization as well as the dependable procedures the organization has developed for itself.
  • The expenses of in-house applications are controlled. The organization determines the priorities for the in-house software development, including flexible customization and phased functionality enhancements. Moreover, an organization using an in-house application won’t be beholden to vendor fee increases due to the expense associated with migrating to another product.

 
Disadvantages:
Conversely, building and maintaining an in-house application with proper information security can be a daunting and exhausting task. UKIA has uncovered a few key disadvantages with in-house applications which include, but are not limited to:

Business Continuity for in-house applications is often hindered by inadequate system documentation and back-up on a secondary server. UKIA has found departments facing problems with operational continuity of their in-house application due to the departure of the application developer and the critical design and information not being adequately documented. These systems can be hard to maintain, improve, and expand because there is a general lack of understanding of the system. The staff who were experts on the application may have left the department, and staff who entered the field after it became a "legacy" application never learned how to use it and have no documentation from which to learn. Additionally, if the in-house application runs on only antiquated hardware, the cost of maintaining the system may eventually outweigh the cost of replacing both the application and hardware unless some form of emulation or backward compatibility allows the software to run on new hardware.

Upgrades and Patches are necessary for in-house applications to keep current with operating systems and technology trends. Departments with in-house applications may find that current security patches are unavailable and cannot be applied. There can also be production configurations that cause security problems. These issues can put the application at risk of being compromised by attackers or knowledgeable insiders.

System Integration may pose issues for in-house application as developers often neglect to follow a comprehensive development methodology and do not factor in the possibility of future need for integration with other systems. Integration with newer systems may also be difficult because new software may use completely different technologies. Integration across technology is quite common in computing, but integration between newer technologies and substantially older ones is not common.

Security from an audit standpoint could be considered the most important risk factor of all. Hackers employ a variety of techniques to gain access to sensitive data, disable operations, and administer other malicious activities aimed at the information systems. However, many in-house application developers are so focused on functionality and features that information systems security is an afterthought. Time and again, this approach to information systems security has proven to be disastrous because vulnerabilities go undetected, allowing information systems to be attacked and damaged. Security should be considered in every step of the development process.

Most large organizations like the University of Kentucky have already installed antivirus applications, firewalls and Intrusion Detection Systems (IDSs) to protect their networks and host operating systems. However, in several of its IT reviews, UKIA has noted that in-house developed applications receive relatively little attention by the unit’s IT staff, who assume that they are protected by firewalls and other defenses at the network perimeter. Yet these in-house applications are the major reason organizations invest in IT in the first place, and the data they contain is often among the organization's most valuable assets. 

Though a critical component of a layered defense, firewalls cannot detect and stop the types of threats directed at in-house applications. Other widely deployed tools, intrusion detection systems, perform only passive monitoring and after-the-fact forensics rather than preventing attacks, which have moved to the information systems, circumventing network-based firewalls. Malware, such as worms, propagate so quickly that signature-based antivirus protection is useless and intrusion detection systems do not provide protection, only faster notification that your security has failed.   

Consequently, from UKIA’s perspective, if the creation and development of your In-house application is not properly planned, adequately documented and strategically focused, the likelihood of these disadvantages emerging is more likely than not.

We’ll go into more detail on specific in-house application vulnerabilities in a future edition of Reed’s Read. Meanwhile, for a review of your unit’s specific IT security risks, including an assessment of your in-house applications, contact UKIA at 859.257.3126.

If you would like to receive news and information about current risks, fraud concerns and more, please subscribe to UKIA’s listserv by sending an e-mail to LISTSERV@lsv.uky.edu with the following text in the message body: subscribe INTERNALAUDIT-L.