control, and governance
New Rewards, New Risks: Mitigating SOA Risks at the Network Layer
Although highly effective, service-oriented architectures (SOAs) can increase an organization's number of network security risks. Understanding the different risks an SOA can bring will enable internal auditors to help organizations mitigate vulnerabilities while taking advantage of this integrated Web services approach.
Sonia Luna, CPA
Vice President, Enterprise Marketing
Hugh Taylor, CISM
Vice President, Marketing Communications
Many companies are starting to use SOAs, an extensible markup language (XML) approach to software that provide organizations with many benefits, such as data flexibility and reduced IT overhead costs. While advantageous, SOAs can expose an organization to security risks that can compromise existing network-based internal controls. To mitigate these risks, IT managers and internal auditors need to work together to examine the different SOA compliance and security vulnerabilities at the network layer and explore cost-effective approaches to risk mitigation before implementing an SOA.
SOA'S SECURITY RISKS
Known commercially as .NET, AquaLogic, or NetWeaver, SOA enables software applications to communicate with one another by using a low level of proprietary middleware, thus reducing operating expenses and promoting IT flexibility. In contrast to conventional architectures in which each application stands alone and performs certain activities by using its own code, SOA is based on the idea that applications and programs can share their IT functionality with one another as a series of services. This allows applications to act as consumers and producers of IT functions that existing applications can then leverage from each other.
Unfortunately, SOA use increases an organization's level of exposure to a number of security and compliance risks. Some of these risks may be familiar to many IT auditors and some may be new, such as the kinds of network vulnerabilities that need to be addressed before implementing an SOA. To understand how SOA heightens security and compliance risks, it is important for internal auditors and IT managers to examine the security characteristics of a Web service.
The core unit of an SOA is the Web service, a discrete piece of application functionality that is communicated in a specialized XML format known as simple object access protocol (SOAP) and operates by exposing application functionality over the Internet. Therefore, what was a highly defended system is now open to universal access through port 80, the port that is designated for Web traffic and is usually left open so that companies can communicate to the outside world via the Internet.
Besides exposing application functionality, Web services have a purely logical relationship to one another. A Web service is essentially a programming object that can be called up through a unique uniform resource locator (URL). Hence, as long as an application has Internet access, it can use any Web service residing on servers anywhere in the world. This creates a security risk because any application that puts a Web service's URL into its code can use that system on the network without any warning or access control, unless the IT department restricts access or implements a network-level control over the Web service. In addition, because the SOA is XML-based, the SOA increases the transmitted information's risk of interception and modification by a third party.
Unauthorized use is another Web service security risk. If a company exposes a Web service to an outside entity, the IT department should be concerned with how this service is going to be used and who is going to use it. Therefore, if the application is being accessed by a third party, IT staff needs to make sure the correct service is being used by the correct provider. Conversely, if the organization is accessing a Web service from another organization, the IT department needs to make sure the correct Web service is being accessed from the correct provider. For instance:
All of these questions need to be answered before implementing an SOA.
At a higher level, SOAs defeat the concept of the enterprise perimeter because, once implemented, outsiders can have access to certain services from within the network. This means that network administrators need to look at incoming network traffic and determine who is connecting to the network, establish user access based on the service in use, and provide the appropriate service based on expected performance or service levels. Network administrators also should investigate whether they need to augment their existing firewall application with another solution, such as intrusion prevention or detection software.
SOA security vulnerabilities fall into two categories: network- and application-related risks. The example described in the next couple of paragraphs can help IT auditors understand these risks and other more specific vulnerabilities emanating from these two risks. The example describes a payroll application that accesses point-of-sale data from a partner and a human resources (HR) database that obtains employee salary information.
Web service-enabled networks are more vulnerable to internal and external attacks because the Internet-based access of the Web service disrupts the network's perimeter. In this example, the payroll system runs on a network and accesses a partner's Web service. To access the Web site, the designated IT employee first must determine whether the payroll system is accessing a valid service from a known entity and not a dummy service setup by a hacker, which would create an access control risk. Second, the IT employee should ensure that the partner system is not going to cause a network outage if the system is compromised by a hacker or a virus attack, thus creating an endpoint integrity risk. Similarly, the partner organization's IT department should make sure its system is talking to a known entity and the payroll system requesting the service is not going to compromise its own security and integrity.
Once the IT department is certain that communication is taking place with a safe system, it is important to make sure that the data exchange between the payroll system and the partner system for point-of-sale information is not going to create additional vulnerabilities in the network. For instance, the payroll system needs to verify that the transmitted data was not modified over the network, which would create a data integrity risk. It is also important to determine whether the data received by the payroll system is confidential and is not exposed for public consumption, which would create a data confidentiality risk. Finally, whether the organization is able to continue business-as-usual depends on the data's availability and accessibility at any given point in time. Consequently, if the data is not available, a data availability risk could be created.
Here's a more detailed look at the various risks introduced above:
Access Control Risks
SOAs add a new element of risk to network access controls and intrusion prevention efforts. While not requiring a categorical shift in network security practices, SOAs necessitate a thorough look at access control rules, security standards, and guidelines. Web services are always machine-to-machine interactions, and many access controls are configured for human-to-machine connections. With SOA, network administrators must take a closer look at how they secure network and application resources from machines residing within the network and outside the network that could impact the performance and availability of critical business resources. At the systems level, a coordinated XML attack could result in a denial-of-service (DoS) for the organization.
Endpoint Integrity Risks
SOAs raise the level of a network's system endpoint exposure. An SOA can expand a network's scope dramatically, even to the point of including third parties and their respective networks into what is essentially a greater, SOA-based network. If an application is offering a Web service to a remote system that is not under the IT department's control, the Web service's consumer is in effect an endpoint on the network.
Endpoint exposure risks require countermeasures. When a Web service request and response travels through the various networks that connect the Web service and the consumer, each "hop" in the message's transmission raises the information's level of exposure to eavesdropping, unauthorized message modification, or lack of data availability due to a message failure.
Data Integrity Risks
Exposing applications on a network to potential unauthorized use as a Web service increases the risk of compromised data integrity. Because a Web service makes more information publicly available than a conventional software program, this kind of service is inherently more vulnerable to a sophisticated attack. For example, a hacker could configure a Web service user to transmit an unauthorized database query using an XML-injection technique, which consists of XML procedural calls that are sent to a Web service to gain unauthorized use to the Web service.
Similarly, a Web service is vulnerable to different XML external entity attacks because hackers could use a Web service's description language document — a standard document that describes a Web service's functionality for potential consumers — to learn how to design a Web service consumer that can exploit specific application vulnerabilities. Because existing application security controls may not be able to mitigate these types of threats, these controls may need to be configured and kept updated as XML threats evolve. Data integrity risks also increase with SOA implementation because XML messages traveling across the Internet can be intercepted and modified without detection.
Data Confidentiality Risks
SOAs heighten data confidentiality risk levels in two ways. First, the XML messages that constitute the working mechanism of a Web service are text-based in their raw state and are highly vulnerable to eavesdropping as they travel across the Internet. Second, an unmitigated access control vulnerability in the SOA can result in unauthorized access to confidential data or the improper disclosure of that data.
Data Availability Risks
Web services that are not governed properly tend to have unpredictable load characteristics that can cause data to become unavailable, especially when combined with the threats of XML content-based attacks (e.g., the increased use of central processing unit resources) and SOAP array overflow attacks, a new variation on buffer-overflow intrusions in which an attacker sends an XML request with an array length that exceeds specified XML definitions. Data availability is directly dependent on network availability, which, if not governed properly, can have a significant impact on the SOA. Hence, having a high-availability architecture that is part of the company's network design is critical for the SOA's reliable functioning.
Furthermore, the unpredictable load characteristics of Web service traffic can cause bottlenecks in the data network infrastructure, resulting in poor performance and response times from systems on the network. The ability for the network infrastructure to scale up without impacting network performance becomes critical for business applications that need "always-on" access to other systems on the network or the Internet. As a result, a Web service is vulnerable to attacks that send endless XML strings, which overload the capacity of the Web service to respond and affect the data's availability.
THE IMPACT OF SOA RISKS ON SECTION 404 COMPLIANCE
It is unlikely that every security risk within the SOA will affect all of the internal controls over financial reporting. However, as internal controls are connected, tested, and certified with their underlying software and network components for Section 404 compliance with the U.S. Sarbanes-Oxley Act of 2002, there may be places where increased risk from SOA can affect an internal control.
To identify SOA impacts on internal controls, management first needs to consider its planning and scoping of SOA in relation to other critical business processes. For example, if SOA is used for a non-financial process, such as customer service calls and survey information, SOA security would not be an issue. However, if an entire sales cycle is dependent significantly on SOA, management should identify the financial risks related to SOA and rank them according to their financial assertion impact. This process is not only time consuming, but involves different levels of management and company functions, such as IT administrators, the organization's vice president of operations, and senior managers in the sales department. Creating a "what could go wrong" worksheet or similar document that is specific to SOA security risks, change management risks, and impacts to financial reporting could help internal auditors and organizations understand how the SOA impacts the current Sarbanes-Oxley compliance process.
Once potential SOA financial reporting risks are identified, management should validate proper internal controls over those risks. For smaller public companies, identifying proper segregation of duties using SOA has been the most troublesome information to give to external auditors. Therefore, these types of companies are looking for alternatives to provide evidence of sufficient internal control documentation, such as additional upper management oversight of internal controls or outsourcing SOA security to other service providers.
The Committee of Sponsoring Organizations of the Treadway Commission (COSO) recently released guidance in June 2006 titled Internal Control Over Financial Reporting – Guidance for Smaller Public Companies. The guidance discusses some of the issues regarding segregation of duties in IT and other IT security internal control matters. Because the guidance is broad and does not specify SOA-related risks and controls, internal auditors should recommend that organizations set up an internal Sarbanes-Oxley committee to spearhead the compliance process.
Comprehensive governance is the key to mitigating SOA risks and assuring the effectiveness of the internal controls that rely on SOA components. Consequently, any standards, procedures, and guidelines for SOA governance need to be defined as part of the organization's information security governance document. For instance, auditors should recommend that the IT department implement a highly automated SOA management solution that defines, monitors, and enforces each standard, procedure, or guideline during the SOA transmission process. Ideally, companies will implement an SOA governance approach that enables security policies for Web services to be defined during the SOA's design phase and that continues to enforce and monitor those policies as the Web service is deployed. The SOA governance approach also should include an audit log feature that can validate the existence and persistence of SOA security policy enforcement.
In addition, SOA governance policy should be extended to the networks that comprise an expanded SOA. To mitigate against the risks that SOA exacerbates, it is best to produce auditable compliance records in a cost-effective manner and have a way to deploy network-level countermeasures. A good countermeasure should consist of a high-performance IT network and security infrastructure that provides the needed level of availability and reliability without compromising the SOA's ability to handle large loads of traffic.
Finally, it is important for IT departments to ensure that network services take into account interoperability requirements among different systems using a standards-based approach that handles unpredictable traffic loads without impacting the SOA's performance. By taking a holistic approach to security, organizations can mitigate the different types of risks, pave a smooth path that leads to a successful implementation and use of SOA, and leverage existing investments.
Although SOA offers organizations many benefits, it also can disrupt a network's security and current compliance landscape. Therefore, IT departments and internal auditors need to work together to identify SOA network-specific risks that could have a negative impact on the effectiveness of internal controls. Although some of these risks may prove difficult to overcome, the key to success in managing SOA network security is to isolate the network issues that directly affect key internal controls. Otherwise, compliance efforts may be stretched too thinly to be effective in this regard.
For more information about SOA, auditors can refer to "Can a Service-Oriented Architecture Hinder Sarbanes-Oxley Compliance Efforts?" published in the October 10, 2006 issue of ITAudit. In addition, internal auditors can visit the following Web sites:
Sonia Luna, CPA, is the founder of SOX Solutions, a Sarbanes-Oxley solutions provider for all types of publicly traded companies. Luna has more than 10 years of working experience with clients from different industries, ranging from Fortune 500 international companies to small organizations. Previously, she worked with Ernst & Young as an audit manager.
Hugh Taylor, CISM, is the vice president of SOA Software, a provider of enterprise service-oriented architecture management, security, and governance solutions. Taylor is the author of The Joy of SOX: Why Sarbanes-Oxley and Service-oriented Architecture May Be the Best Thing That Ever Happened to You and Understanding Enterprise SOA.
Steven Wastie is vice president of enterprise marketing at Juniper Networks. Prior to Juniper, Wastie was vice president of marketing at Hummingbird, a provider of enterprise content management solutions. Previous responsibilities include product management and marketing roles in Europe and Asia for Netscape and AT&T.
COMMENT ON THIS ARTICLE
Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.