IT Governance, Risk, and Compliance » IT Support

Data Communications Risk in Distributed Computing – Part V

Robert Davis — Sat, 08 Sep 2012 00:14:43 +0000

Reducing data communication error risk for teleprocessing systems

Teleprocessing is the handling of data through a communications channel, such as telephone lines, microwave towers, or artificial satellites. It permits datum to be posted to files in a second location, with the processing results being printed in a third location.

A major problem created by teleprocessing capabilities is the potential devaluation of information assets based on data communication errors affecting information reliability. Consequently, technology owners must evaluate the ability of teleprocessing systems to resist such data corruption to ensure information asset devaluation is minimized and information reliability is maximized.

Sources:

Davis, Robert E. IT Auditing: IT Service Delivery and Support. Mission Viejo, CA: Pleier Corporation, 2008. CD-ROM.

Watne, Donald A. and Peter B. B. Turney. Auditing EDP Systems. Englewood Cliffs, NJ: Prentice-Hall, 1984. 6, 236-7, 467

Davis, Robert E. “IT Hardware Risks.” Suite101.com. Retrieved on 10/03/2010

Strangio, Christopher E. “Data Communications Basics: A Brief Introduction to Digital Transfer.” Camiresearch.com. Retrieved on 10/03/2010

“View Part I of the Data Communications Risk in Distributed Computing series here”

Post Note: “Data Communications Risk in Distributed Computing – Part V” was originally published through Suite101.com under the title “Data Communications Risk in Distributed Computing”

@TempleU News flash! Just received a Temple University appointment letter! As of 08/29/2012, I am the (First and Inaugural) CISA in Residence at Temple University! (Job Description Link: http://www.linkedin.com/in/havecisawilltravel)

Data Communications Risk in Distributed Computing – Part IV

Robert Davis — Wed, 05 Sep 2012 19:56:04 +0000

Signal fading is a decline in transmission strength. Fading can occur when a signal is transmitted by microwaves. Under certain conditions, the signal picked up by the receiving unit can be quite weak. A weak signal is more susceptible to transmission noise and error.

Signal distortion can result from lack of synchronization between the time datum is sent and the time they are received. Lack of synchronization typically occurs when a signal travels several paths with different delays in each path. This will result in distortion when there is overlapping in the receipt of data from the different signal paths.

Sources:

Davis, Robert E. IT Auditing: IT Service Delivery and Support. Mission Viejo, CA: Pleier Corporation, 2008. CD-ROM.

Watne, Donald A. and Peter B. B. Turney. Auditing EDP Systems. Englewood Cliffs, NJ: Prentice-Hall, 1984. 6, 236-7, 467

Davis, Robert E. “IT Hardware Risks.” Suite101.com. Retrieved on 10/03/2010

Strangio, Christopher E. “Data Communications Basics: A Brief Introduction to Digital Transfer.” Camiresearch.com. Retrieved on 10/03/2010

“View Part I of the Data Communications Risk in Distributed Computing series here”

Post Note: “Data Communications Risk in Distributed Computing – Part IV” was originally published through Suite101.com under the title “Data Communications Risk in Distributed Computing”

Data Communications Risk in Distributed Computing – Part III

Robert Davis — Fri, 31 Aug 2012 23:31:36 +0000

The electrical signal may be changed by mechanical component failure of the communications network, or by a problem related to the characteristics of data communications. Of these two error sources, the characteristics of data communications are by far more important.

Root causes of most data communication errors

Errors associated with the communication of data, rather than a mechanical failure, are generally due to noise, fading, or distortion.

Communication noise is electrical interference with the signal. It may be background noise or impulse noise, and it may be random or cyclical. Background noise usually has little effect on the transmission of a signal. Impulse noise, such as a sudden voltage surge, is more likely to mask or distort a signal. As long as the noise occurs randomly, it is usually easy to detect an error. Conversely, cyclical noise, such as voltage oscillation, can create compensating errors that are difficult to detect.

Sources:

Davis, Robert E. IT Auditing: IT Service Delivery and Support. Mission Viejo, CA: Pleier Corporation, 2008. CD-ROM.

Watne, Donald A. and Peter B. B. Turney. Auditing EDP Systems. Englewood Cliffs, NJ: Prentice-Hall, 1984. 6, 236-7, 467

Davis, Robert E. “IT Hardware Risks.” Suite101.com. Retrieved on 10/03/2010

Strangio, Christopher E. “Data Communications Basics: A Brief Introduction to Digital Transfer.” Camiresearch.com. Retrieved on 10/03/2010

“View Part I of the Data Communications Risk in Distributed Computing series here”

Post Note: “Data Communications Risk in Distributed Computing – Part III” was originally published through Suite101.com under the title “Data Communications Risk in Distributed Computing”

Data Communications Risk in Distributed Computing – Part II

Robert Davis — Wed, 29 Aug 2012 14:00:46 +0000

A common type of data communications risk

According to Christopher E. Strangio, the distance over which data moves within IT can vary from a few thousandths of an inch, as is the case within a single integrated circuit (IC) chip, to several feet along the main circuit board’s backplane connections. However, datum frequently must be sent beyond the local circuitry constituting an IT configuration.

In data communications, electronically encoded content is transmitted in the form of electrical signals. An inadvertent change in a signal will result in the datum received being in some way different from the datum sent. Typically, this increased information reliability risk is based on the probability of change in an electrical pulse due to the data communications facilities utilized for moving datum from one location to another.

Sources:

Davis, Robert E. IT Auditing: IT Service Delivery and Support. Mission Viejo, CA: Pleier Corporation, 2008. CD-ROM.

Watne, Donald A. and Peter B. B. Turney. Auditing EDP Systems. Englewood Cliffs, NJ: Prentice-Hall, 1984. 6, 236-7, 467

Davis, Robert E. “IT Hardware Risks.” Suite101.com. Retrieved on 10/03/2010

Strangio, Christopher E. “Data Communications Basics: A Brief Introduction to Digital Transfer.” Camiresearch.com. Retrieved on 10/03/2010

“View Part I of the Data Communications Risk in Distributed Computing series here”

Post Note: “Data Communications Risk in Distributed Computing – Part II” was originally published through Suite101.com under the title “Data Communications Risk in Distributed Computing”

Data Communications Risk in Distributed Computing – Part I

Robert Davis — Sat, 25 Aug 2012 00:09:33 +0000

As the distance between the message source and designated destination increases, accurate transmission becomes increasingly more risky.

Data communication systems are designed with transmission speed and capacity to meet the timeliness and volume needs of defined users. Nonetheless, data delivery speed and capacity are determined by the choice of equipment and channels, modulation technique, transmission mode, as well as transmission direction.

As discussed in Computer Hardware Risks – Part II, a failure in an electronic element of an information technology (IT) configuration can cause an error by affecting the frequency, timing, strength, or shape of an electrical pulse utilized to convey datum.

Sources:

Davis, Robert E. IT Auditing: IT Service Delivery and Support. Mission Viejo, CA: Pleier Corporation, 2008. CD-ROM.

Watne, Donald A. and Peter B. B. Turney. Auditing EDP Systems. Englewood Cliffs, NJ: Prentice-Hall, 1984. 6, 236-7, 467

Davis, Robert E. “IT Hardware Risks.” Suite101.com. Retrieved on 10/03/2010

Strangio, Christopher E. “Data Communications Basics: A Brief Introduction to Digital Transfer.” Camiresearch.com. Retrieved on 10/03/2010

Post Note: “Data Communications Risk in Distributed Computing – Part I” was originally published through Suite101.com under the title “Data Communications Risk in Distributed Computing”

Service Level Management of Cloud Computing – Part VIII

Robert Davis — Tue, 16 Nov 2010 00:03:53 +0000

Generally, cloud computing clients do not own the physical infrastructure, logical infrastructure or applications accessed by authorized personnel. Instead, clients avoid capital expenditures through leasing usage from the third-party provider. Service consumption payment plans are typically based on utilization and/or subscription rates defined in the third-party provider’s business model; where leasing arrangements can reflect block time, remote batch, or timeshare costing techniques. Nevertheless, entities that acquire cloud computing services should employ sound IT service management systems, processes, activities, and tasks to ensure defined QoS as well as financial expectations for selected third-party configurations are fulfilled.

“View Part I of the Service Level Management of Cloud Computing series here“

Service Level Management of Cloud Computing – Part VII

Robert Davis — Fri, 12 Nov 2010 04:52:07 +0000

Commercial cloud computing vendors are expected to meet achievable QoS requirements, and if the entity is vigilant, sign legally binding SLAs promoting expectation fulfillment. To ensure effective SLAs, OLAs must be defined and developed prior to deploying any cloud computing service. These OLAs should cover expectations that assist the entity’s IT organizational structure in services delivery and contractual negotiations.

Commonly, OLA utilization requires explaining how services will be technically delivered to support the SLA(s) in an optimal manner — with provisions for timely updating related to service quality. Consequently, an OLA should specify technical processes in terms meaningful to the cloud computing provider, and can support several SLAs.

“View Part I of the Service Level Management of Cloud Computing series here“

Service Level Management of Cloud Computing – Part VI

Robert Davis — Mon, 08 Nov 2010 20:32:21 +0000

SLR recording dictates identifying performance as well as capacity requirements and placing them in a SLM registry. These SLRs can encompass:

Scalability
Maintainability
Reliability
Availability
Performance
Security

During the initial cloud computing acquisition phases, an IT architect should define the QoS measurements for each of the SLRs. Furthermore, an entity’s IT clients should agree on: guidelines for dealing with reported problems that may require extended timeframes to resolve as well as information detailing the impact of problems on business processes, other IT configurations and service users.

“View Part I of the Service Level Management of Cloud Computing series here“

Service Level Management of Cloud Computing – Part V

Robert Davis — Thu, 04 Nov 2010 17:13:11 +0000

To enable SLM, customers as well as internal and external suppliers should be identified and managed. For most service providers, cloud computing infrastructure consists of services delivered through central sites utilizing configured servers. Whereby, IT services often appear as single access points to clients.

Descriptively, establishing sound SLM necessitates clear service specifications and interfaces defined with customers (Service Level Requirements (SLRs)). Furthermore, internal Operational Level Agreements (OLAs) and contracts with external suppliers will facilitate adherence to negotiated SLAs.

“View Part I of the Service Level Management of Cloud Computing series here“

Service Level Management of Cloud Computing – Part IV

Robert Davis — Mon, 01 Nov 2010 17:39:21 +0000

SLM can be considered QoS monitoring and management based on key performance indicators (KPIs). QoS KPIs can range from generic availability and usage statistics to entity-centric per-interaction indictors. Adequate SLM requires potential problems identification — such as gradual performance degradation — and alerts creation enabling downtime risk minimization. Consequently, SLM practices should include comparing actual performance to pre-defined expectations, determining appropriate actions and generating expressive reports to permit service improvement.

“View Part I of the Service Level Management of Cloud Computing series here“