Juggling Business-Process Change

With increasing SOA initiatives, entities within corporations must monitor and control network risk

By Atchison Frazer

Every business-process change brings with it associated risk to the network. This risk factor is exacerbated many times over by the introduction of web 2.0 technologies and services-oriented infrastructures or web services that promise open interfaces and the benefit of reuse of applications within the corporate IT environment. These promised benefits extend to the entire enterprise, including supply chain partners.

With increased use of Service-Oriented Architecture (SOA) initiatives, organizations now have traded up for application flexibility and reconfigurability by having the equivalent of these objects encapsulated as web services, and then having those applications recombined to perform new tasks. The SOA network also has taken on the burden of increased operational complexity and, inherently, a whole range of security vulnerabilities because it is no longer just one application; it has become a set of user interfaces that must be kept operationally stable.

As organizations run all of these services and combinations of services, it is important that they understand which are the key services that are being reused and/or greatly altered on the fly and how to ensure those services are functionally robust and secure.

The entity within the enterprise that requests the process change should assess the risk level of the change to the network. It is prudent to model that change in a lab environment or with a network modeling tool that takes into account the impact on the network. One recommended best practice is to require requestors to assign one of these risk categories to each change request:

• High-risk—These network changes have the highest impact on user groups or particular environments, and might even affect an entire site. It is time-consuming or difficult to back out of the change. Make sure management is aware of the change and its implications, and notify all users.
• Moderate-risk—These network changes can critically impact user environments or affect an entire site, but it is a reasonably attainable scenario to back out of the change. It is recommended to notify all users of a moderate-risk change.
• Low-risk—These network changes have minor impact on user environments and it is easy to back out of the change. Low-risk changes rarely require more than minimal documentation. User notification is often unnecessary.

For example, many large, complex organizations grow through consolidation or merger and acquisitions, only to find they must deal with separate, distinct network architectures, connectivity issues and security solutions.

With security issues, Cisco enterprise architecture advisors will typically design firewall defense-in-depth services capabilities into the fabric of the network. This way, the customer can virtualize the core security infrastructure and provide services and capabilities to all subnets within the organization in a more consistent, cost-effective way.

When customers virtualize their security fabric, they can pull out discreet appliances that require potential on-site management and on-site support, and thus can be managed more centrally and efficiently through virtualized infrastructure architectures. The ongoing implementation and maintenance of such solutions requires all players in the central entity and the distributed agencies to operate from the same playbook in terms of best practices for security policy and change management.

One way to incorporate change management best practices is to tolerate additional risk levels to help identify the correct level of testing and validation prior to the change. The following are five different risk levels that help identify testing and validation requirements.

Risk Level 1: High potential impact to large number of users (500+) or business-critical service because of an introduction of new product, software, topology or feature. Change involves expected network downtime.

Risk Level 2: High potential impact to large number of users (500+) or business-critical service because of a large increase of traffic or users, backbone or routing changes. Change might require some network downtime.

Risk Level 3: Medium potential impact to smaller number of users or business service because of any nonstandard change, such as new product, software, topology, features or the addition of new users, increased traffic or nonstandard topology. Change might require some network downtime.

Risk Level 4: Low potential impact that includes the addition of new standard template network modules (building or server switches, hubs, or routers); bringing up new Wide Area Network (WAN) sites or additional proven access services and all risk level 3 changes that have been tested in the production environment. Change might require some network downtime.

Risk Level 5: No user or service impact that includes adding individual users to the network, and standard configuration changes such as password, banner, Simple Network Management Protocol (SNMP) or other standard configuration parameters. No expected network downtime.

One trend gaining currency in the enterprise is to implement a GRC (Governance Risk and Compliance) application, which is a flexible model of various rules along with automated notifications and remedies that must be applied to properly run a contemporary corporation. SAP, the most prominent application player in this space, reports 300 percent growth quarter over quarter for GRC solutions in the high-end enterprise, where SAP’s ERP solutions are prevalent.

IDC analyst Richard Heiman says GRC will continue to drive some direct compliance and risk management technology investments but, more important, GRC will become the filter through which other IT investments are evaluated. Organizations are beginning to understand the common denominators across multiple compliance initiatives and will look for broader information management, collaboration and process-automation technologies to embed compliance into operational activities.

GRC solutions contain customized logic to act on the intelligence derived from network events. This allows a company to express, monitor and demonstrate exactly how it will comply with governmental regulatory mandates such as Sarbanes-Oxley, as well as to create its own internal controls to perform activities such as protecting intellectual property or enforcing change management policies.

A critical success factor in passing an audit is the documented ability to illustrate the organization’s control over and insight into users’ access of IT infrastructure and capital assets affected by business-process change. This is a significant benefit to automating the change management and compliance processes in cases where systems and applications are modified, upgraded or discontinued. Such an automation effort must also properly segment officers’ duties. Their communications and actions are deemed privileged in contrast to routine and customary administrative functions.

Effective management of risk and compliance is vital in today’s large organizations, not only because of the introduction of new financial, environmental and other regulations, but because of the value that GRC applications provide in preventing surprises and identifying problems early enough so they can be solved with the lowest possible costs.

Companies with demonstrated abilities to reduce operational risk generally enjoy higher market capitalizations, as borne out by the popular risk management formula Capital Asset Pricing Model, which is based on the assumption that operational risk has an influence on an institution’s stock price and overall market value.

By establishing a comprehensive set of controls that are automatically monitored, the enterprise can actually move faster to implement its business-process changes, knowing that it will gain predictive intelligence and proactive mitigation against potential threats to corporate reputation and brand equity.

Atchison Frazer is Director of Enterprise Services Strategy for Cisco.