COTS versus Custom Software

COTS versus Custom Software

COTS software is commercial off-the-shelf software, such as Windows XP or Quicken 200X. COTS software includes commercially produced and supported software products that enhance the productivity of electronic computing devices. Generally, they are well tested, documented, and supported products that provide the advertised functionality. It is assumed that they provide the necessary security and privacy features associated with protecting the data that the application will process. This is usually not the case. In the rush to meet marketing and delivery dates, security is the first to be sacrificed. At a recent trade show, one software vendor was heard to say, "We think the market will be willing to forgo the security concerns to be able to utilize the enhanced functionality." This may be the case, but you can bet that the marketing materials do not highlight the fact that the product does not provide the users or their data with privacy or confidentiality.

We are not saying that all COTS products have this flaw. The point is that knowing what you are not getting is just as important as knowing what you are getting. Do not assume that a product does something unless you are explicitly told it does. You must verify what is and is not being done by products used with your system.

Custom Software

Custom software is proprietary software that is built internally, or contracted for, and usually integrates COTS software into a business's computer system to accomplish a business objective. Custom software is commonly used in linking a legacy inventory control system or a CRM system to a Web-enabled front end. It enables a traveling sales or marketing team to access current pricing information on a legacy system to be accessed via a Web or custom interface.

Custom software is usually requested to meet a specific functional or utility deficiency among COTS products or between COTS and legacy systems. Sometimes they are contracted to patch or fix security vulnerabilities or weaknesses that arise when legacy systems originally accessible only via closed internal networks become accessible to the outside world via Internet or wireless connections.

The potential for security weaknesses increases as the number of components designed to work independently under specific operating assumptions are integrated into larger, more complex systems. Software programs or components are usually tested for functionality, not security. As mentioned in earlier chapters, the exploitation of a component is usually accomplished by getting the software to do something it was not intended to do. Normally, from both a time and cost perspective, security testing is not performed unless it is specifically required or the software is destined for use in a security-critical area. Again, in these situations, the initial requirements often specify that this type of testing must be performed.

For example, when a software vulnerability was identified in a certain company, the developer was brought in, and the vulnerability was described. The developer's response was, "We knew about the issue, but we could not think of a situation in which users would encounter the circumstances that would allow that vulnerability to be exploited. And at the time, if they did, it would not grant them access to anything that they already did not have access to through some other means."

Here is how it became an issue. This software was integrated with other software and systems to provide Internet-based access for the entire company. Systems and services assumed that this piece of software was providing access control and authentication, so these systems blindly accepted requests coming from this process, further assuming that they were authorized. A network-based attack against this piece of software identified the vulnerability, and over time an exploitation was devised that allowed a network-based attack to gain access to the company's entire set of backend servers. It was not totally the fault of the software, however. Logs being generated had identified that someone was attempting to exploit the vulnerability, but the logs were not routinely examined.

You can learn several lessons from this brief example:

         Software will not always be used in the environment to which it was originally developed.

         You should not rely on other systems or services to provide security for you, unless you have verified that they are doing so in all cases.

         Logs are good as a security protection measure only if someone knowledgeable, who can identify potential attacks, examines them on a routine basis.

We will now look at several technologies being used, or contemplated, to provide add-on COTS and custom security solutions to networks, both wired and wireless.

 



Wireless Security and Privacy(c) Best Practices and Design Techniques
Wireless Security and Privacy: Best Practices and Design Techniques
ISBN: 0201760347
EAN: 2147483647
Year: 2002
Pages: 73

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net