Computer Outsourcing Security Risk

Computer Outsourcing Security Risk Essay, Research Paper

Inherent security risks of outsourcing — what the CIO should know

who were previously competitors are partnering in order that they may share risk, preserve capital, and gain market share from other competitors. It seems as though some companies soon will have outsourced so much of their business they will be in danger of becoming a business in name or brand only. While there can be many business benefits to outsourcing business functions and partnering with vendors and others in your business, the downside is always that it brings much added risk to your supporting systems, networks, and business critical applications. The more your network is extended and the more nodes or hosts are added-then all the more intrusion vectors (new and vulnerable risk points) become available for possible exploit and resultant harm to your company. As you connect your networks with various outsourcers, partners, vendors, alliances, and even consortiums you may, and probably will, connect with whom they do. The above connection scenario changes the established trust model from explicit and understood trust to one of transitive implicit trust. This is the “I may trust you but I do not necessarily trust who you trust” scenario. What can make the issue all the more complicated is that the company you outsource critical functions to may outsource some of its critical functions as well, and, you may not realize the potential impact to you until after long-term contracts are signed. Then it may be too late to amend contracts in order to protect your company from potential loss and liability. More connections to your network will bring more intrusion vectors or risks. These risk points must be tightly controlled and monitored at all times. Some companies may have hundreds of network connections, using a variety of communication methods, e.g. Internet, frame relay, leased line, microwave, wireless, satellite, fiber, ad nauseum. With so much variety in your connection types how will you know if a breach (successful or unsuccessful) in your network has occurred? How can you know what is happening in your partner’s networks, or in the networks of those whom he is connected to? It may likely be through your friendly partner connections that you become open to intrusion, not from a more direct outside intrusion. Watch those trusted host relationships carefully. Are you ready to respond to a breach of your network?

Usually, agreements are made and contracts are signed before a project team becomes involved in implementing a connection for a partner or an outsourcing contract. Use your in-house information security professional. They can offer you valuable expertise and experience before an outsourcer is chosen and contracts are signed. You will benefit from their lessons learned. If you do not have in-house professionals, hire outside professionals quickly. Retain them long-term if you need. It may also be time to review all of your current connections for risks to your business that can be easily mitigated with inexpensive controls and network re-design.

Security planning and risk assessments An adequate and formalized security planning process should be instituted to fully describe any new (or existing) projects, the controls, and residual risks to the sponsoring business line and the company as a whole. In doing so, risks are identified, and proper protective controls are implemented. The controls can be validated and a process instituted to monitor for continued compliance. In the end the residual risk should be low enough so that it is palatable to those who own or benefit from the project. A business-acceptable “Systems Security Planning Process” (based on general, platform, and technology specific standards) may include the following items. (There may be sub-sections for each section.)

Overview:

A project overview should be included that provides an executive summary of the project. The wording should be non-technical so that the application proponent(s) (see below) can easily understand the project and its components. Other applications/references: A section should be included that mentions other applications within the company that this application may interface with and any other relevant documentation.

Test schedule and target production date: Test and production target dates should be firmly established and documented. Test dates are important as network connectivity is usually first established at testing time. Since connectivity itself can be the largest risk factor you must pay close attention to connection dates. Responsible proponent(s) and auditor(s): Each application usually has an owner, sponsor, or proponent. In this case; we refer to them as the proponent. In some cases there may be several proponents. The planning process is to ensure that the proponent(s) are made aware of their risks. If your companies’ auditors are involved, their names should go here as well.

Data classification:

It should be clear to the proponents when the data to be used in a project is Confidential or Company Secret rather than just Internal Use Only. If so, extra care (e.g., encryption) may be required. Architectural, network, and data flow diagrams: Data flow and network diagrams help to clearly spell out where your company data is going and what physical network devices and computing platforms are to be used. Computing platform and environment descriptions: Each computing platform may have different security requirements.

Application access paths and access matrices: It is important to specify exactly how a user will gain access to systems and what platform security controls will control that access. This is the place to spell it out. An access matrix can provide a visual layout of who has access to what resources in an application or project.

General and platform specific security standards and controls: Ideally, each computing platform used in a project will have proper standards documents associated with their use (i.e. UNIX, MS-NT, Sun, etc.) This section should state which standards are used. Standards exceptions/issues, risks/exposures and mitigating controls: After all is said and done a project may still have some, and in some cases many, residual risks and exceptions to standards. These risks and exceptions should be clearly spelled out to the project proponent(s) for their acceptance.

Contracts

Your vendors, partners and outsourcers should be held to your high control standards when they connect to your networks and have custody of your data assets. Contracts should ensure this and hold them liable for any negligence. Contracts should stipulate what controls-related reporting the outsourcer provides. Such reports will help you understand how well your data is being handled. It should be required that you be notified within a reasonable period of time of exceptions or incidents that involve your data. Contracts need to have some planned obsolescence, as they may need to be revised over time as the technology itself changes. In short, perhaps it’s best to ask for every control to be addressed in the contract upfront whenever possible. Ensure when drafting the contract that you maintain complete control of the relationship, and that you maintain control of your most critical systems. In other words ensure that your contracts protect you and not the outsourcer. Ensure that your contracts provide you with the right to properly oversee and audit the outsourcer at your convenience. Consult with your in-house counsel and find experienced outside counsel if you must. Caution should be taken here. Your business is at risk.

Networking controls (firewalls and encryption)

After you and your vendor/partner have agreed on a secure and mutually acceptable contract and network connection design, you’re ready to connect and begin business. Well designed, configured, and closely monitored firewalls, supported by a concerned, attentive, and expert staff are absolutely key. All connections should consist of TCP/IP- based protocols only, if at all possible, and all must go through a central firewall method (we mention method, as there may be many actual machines). Routing all of your connections though a central point can provide you the ability to know exactly who is coming in and going out, and when. Obviously, one door is easier to guard than many, and since firewall rules become vastly complex, you want them in one place to assist in preventing configuration errors. This is one of those rare situations where having all your eggs in one basket is a good idea. It is just that you must be very diligent in watching that one basket. Of course, you will need a redundant basket hardware failures that inevitably occur at the worst possible moment.

Though there is some added cost, terminating connections can be segregated at the firewall method to further minimize your risks. Internet connections should terminate on separate subnets than frame relay, SNA, or point-to-point connections. Sensitive connections should be isolated from each other, as should encrypted links. Vendor owned, controlled, and supported connections, servers, and routers must be isolated with strictly defined, mutually agreed upon, and monitored routing and access controls. If a vendor supported server is successfully attacked, make sure it does not affect you because you let the vendor talk you into an ill-advised server-to-many-servers trust relationships for the sake of convenience.

Due to the number of network connections and their increasing complexity, the firewalls themselves can become difficult to manage and oversee. Firewall rules can become increasingly complex, installation of security software patches can lag behind, and monitoring can take more time than is available. Due to these issues some companies are even outsourcing their firewalls, monitoring, and maintenance to outside firms. Whether this is right for your company or not is up to you to decide.

Awareness and education

Again, today, your vendors and partners may not be aware of your issues, or of network security issues in general. Your first line of defense is to have experienced information security professionals provide counsel to you and represent your best interests. If you don’t have these professionals, find them quickly. Ask them to come in and train your staff. You will find it money well spent and it can help to avoid costly future issues-and it will help in vendor negotiations by agreeing on contract terms upfront. Rather than repeating the same message over and over again to those with whom you connect, consider working with your security professionals to develop a briefing on what your issues are and what you expect. This briefing can be general in scope so that you can feel free to e-mail it to them over the Internet. You may want a separate more detailed briefing complete with network diagrams, computer names, and network addresses that you can discuss once non-disclosure agreements are in effect.

The briefing should include a checklist of items so that they can be prepared to answer your basic questions-the information you need in order to ascertain how you’ll need to treat them: friendly or hostile. A friendly connection partner will have provided you with favorable third-party audit reports (standard auditing reports such as a SAS-70 and network penetration tests) and will not require the use of insecure networking protocols (e.g. UDP, ICMP, SNMP, etc.). And what are hostile connections? They may be those whom are extremely reluctant to provide you with any information, or those that may plainly have less than desirable controls and connections themselves, and know it.

Issues to evaluate with outsourcers, vendors, etc.

 Physical security: Card-key access, cameras, guards, etc.

 Personnel security: Procedures for screening employees, such as FBI fingerprint checks, etc.

 Procedural security: General and platform specific security standards

 Customer referrals: Contact current and past customers. Listen carefully to what others may tell you before contracts are signed.

 Change management procedures: Look for detailed procedures with separation between test and production.

 Determine their networking protocols: IP networks are inherently more risky than SNA networks. If the network is IP determine what risky protocols are being used (i.e. UDP, ICMP, etc.).

 Determine the vendor’s connectivity: Are they connected to the Internet, or to your competitors?

 Contractual liability specifications: Determine and agree on who will be liable for what and under what circumstances.

 Year 2000 compliance: Determine Year 2000 certification status and ensure the contract covers the issue adequately.

 Intrusion detection and overall network and firewall security methods, controls and monitoring: Ensure that vendor controls access to their network in an adequate manner.

 Third-party audits (SAS-70 and penetration tests): Obtain and review any third-party security reports your vendor can provide.

 Adequate insurance: Computer crime, fraud, property, general liability, etc.: To protect your company ensure your vendor is adequately covered.

 Business resumption planning: Be certain your vendor is capable of providing your business with service in the event of a disaster at their primary processing site.

Regular audits

Audits should occur on an adequate periodic basis to validate agreed upon controls at your site and the other party’s site. Consult your EDP audit department for guidance. Ally yourself with them, you will find them more than willing to do so with you.

Conclusions

As we all become interconnected we also become interdependent upon each other for our security needs. We must act together as a neighborhood watch patrol. Due to changing technology and the new electronic commerce marketplace we each must raise the bar on security. We must all protect our networks adequately against today’s modern threats and tomorrow’s unknown-and perhaps even more insidious-threats. We must demand that our vendors, partners, and outsourcing providers educate themselves in regard to our security concerns. Today, as most all applications are designed to be networked, they must be secure by design and default, not only after your own thorough analysis and fine-tuning conducted after purchase. Security is quality, and applications, networks and service should deliver built-in quality. Our common goal should be common high standards and controls so that we may protect shareholder’s assets, maintain customer’s privacy, and maintain quality and available systems in support of profit making motives.

Bibliography