SDA India is an online resource for Software, Development,IT, Architecture, Open Source, Mobile, Security, Databases, Delphi, C, OS, Asp, .Net, Php, Xml, Java
Articles
New Rewards, New Risks: Mitigating SOA-based Compliance Risks at the Network Layer
Brad Gray, VP Asia South, Juniper Networks
Brad Gray holds the position of Vice President, Asia South Pacific, at Juniper Networks’ operations in Singapore. With over fourteen years’ experience in data networking, and having spent seven years of those in South Asia, Brad comes equipped with a strong understanding of the enterprise and carrier market in Asia. Since joining Juniper, Brad has helped incumbent service providers build out IP-core networks, and introduce broadband services in ASEAN and India.
Prior to joining Juniper Networks, Brad was Vice President, Asia South Pacific, at Unisphere Networks.
Prior to joining Juniper Networks, Brad was Vice President, Asia South Pacific, at Unisphere Networks.
Many corporations are transitioning enterprise applications toward Service-Oriented Architecture, or SOA, a new, Extensible Markup Language (XML)-based approach to software that provides business advantages, such as data flexibility and reduced IT overhead costs. However, SOA can expose an organization to numerous new security risks. These risks can be serious enough to compromise a successful Sarbanes-Oxley, or SOX, compliance process if there is not an effective IT layer risk management process in place. This article will examine some of the most pressing compliance and security risks raised by SOA at the network layer, and explore cost-effective approaches to risk mitigation.
SOA: A Brief Technological Overview
Service-Oriented Architecture is an approach to enterprise architecture that is based on the idea of software applications sharing functions with one another as “services.” In contrast to conventional architectures, where each application stands alone within its own “silo” and performs its function strictly by using its own code base, an SOA opens up applications as both consumers and producers of functionality that other applications can leverage from each other.
For example, if a bank maintains separate credit card and mortgage loan processing systems, each would require access to customer information, such as social security numbers, addresses, and other relevant application information. Currently, each system has its own separate database containing duplicate sets of the same customer data. Alternatively, the bank may set up and maintain a proprietary middleware solution to keep both databases updated and maintained.
However, in a SOA-based approach to this situation, customer addresses, social security numbers, and other duplicate information would be exposed as a “service” that any system could invoke when it needed specific customer data. Now, with the advent of XML, the Internet, and other widely accepted standards, the ideal of achieving service orchestration and open interoperability of disparate, heterogeneous systems has finally come of age. In fact, SOA is everywhere and you’re probably using it in your daily life; some examples are Microsoft’s .NET, BEA’s Aqualogic, Oracle’s Fusion Middleware, and SAP’s NetWeaver.
The core unit of SOA is the Web Service, the de facto standard component model for SOA. Web Service is a discrete piece of application functionality that is communicated in a specialized format of XML known as Simple Object Access Protocol (SOAP). The Web Services standards (ratified by WS-I) also include UDDI, a registry of Web Services available to an enterprise, and Web Service Description Language (WSDL), a standard document that describes a Web Service’s functionality for potential consumers.
Business Benefits of SOA
Many large companies and public sector organizations have embraced SOA because of the paradigm’s potential to reduce IT operating expense while simultaneously promoting agility and flexibility. While this is easier said than done, it is possible to achieve breakthroughs in IT productivity and cost reductions by exposing enterprise applications as Web Services as opposed to alternative solutions to this issue, such as middleware. At the same time, by utilizing common open standards for interoperability, it becomes easier, cheaper, and faster—in theory at least—to have IT respond dynamically to shifts in business strategy and operational goals.
Security Risks with SOA at the Network Layer
However—and there’s always a “however” with this kind of complex, technological implementation—SOA increases an enterprise’s level of exposure to a number of security and compliance risks. Some of these risks are familiar to the IT audit field, and some are wholly new. All of the network risks of SOA, though, need to be addressed.
To understand how SOA heightens security and compliance risks, let’s take a quick look at some of the security characteristics of Web Services. Web Services expose application functionality to virtually any consumer that can access them over the Web. In other words, what once may have been a highly defended system is now open, through Port 80, to universal access. If this hasn’t turned on your internal audit “risk meter,” then consider the fact that Web Services have a purely logical relationship to one another. A Web Service is essentially a programming object that can be invoked through a unique URL. Therefore, as long as an application has access to the Web, it can invoke Web services that reside on machines and networks that could be anywhere in the world. Conversely—and this is where there can be trouble—any application that puts a Web Service’s URL into its code can invoke that system on the network without warning or access control, unless IT governs the Web Service and institute a range of network level controls. Finally, XML is an open standard that is text-based. If not controlled, it can be easily intercepted, read, and modified in transit.
SOA network-level risks present themselves both internally and externally. Systems within an enterprise that use Web Services to interoperate are more vulnerable to internal and external attacks. The situation becomes even more complex when these systems use Web Services exposed by outside entities, such as suppliers and business partners. Essentially, SOA can disrupt what has traditionally been considered to be the network perimeter. With SOA, a Web Service exposed to the public Internet OR a Web Service accessed from outside the network, means that the network no longer has a perimeter.
To round out the security issues, let’s look at SOA from another perspective; if you are exposing a service to outside entities, you should be concerned with how this service is going to be used and who is going to use it. That is, will your security be compromised because of the service, and if so, how can you be sure that only authorized parties are using this service and only for legitimate purposes?
If your applications are accessing services from outside entities, you need to be certain that you are truly accessing the correct service from the correct provider. (Spoofing and comparable forms of hacking are unfortunately quite common on the Internet.) Will your network and applications be compromised (worms, virus, trojans etc.) if you access this service? Finally, will this service be available when you need it? Will this service respond to your requests in a timely manner so that you can go about doing business as usual? What impact is the service going to have on your network traffic load?
At a high level, SOA defeats the concept of enterprise perimeter. Now, outside entities can have access to certain services from within your network. You need to look at traffic coming onto your network and make a determination as to who is connecting, apply appropriate security policy based on identity, and provide appropriate service with predictable performance/service levels. So, it becomes worth investigating to see if you need to augment your existing firewall solution with other solutions like intrusion prevention and access control if required.
The security risks can be divided into two broad categories: network-related risks and application-related risks. In order to understand these risks, let us look at an example of a payroll application accessing point-of-sale data from a business partner as well as from an HR database to know the employees salary data all exposed in the form of Web Services:
Network-related risks – The payroll system is running on a network and is accessing Web Services from an external entity, a business partner. First, the payroll system must know that it is accessing a valid service from a known entity and not a dummy service setup by a hacker. This risk can be called an Access Control risk. Second, the system should ensure that the partner system is not going to be a cause of network outage because that system was compromised by a hacker attack or a virus attack. This risk is an Endpoint Integrity risk. Similarly, the partner system would like to make sure that it is talking to a known entity and that the payroll system requesting a service is not going to compromise its own security and integrity.
Application-related risks – Once it is certain that communication is truly happening with a ‘safe’ system, it is important to ensure that the data exchange that happens between the payroll system and the partner system for point-of-sale information is not going to create additional vulnerabilities in the network (XML-related threats, etc.). It is important for the payroll system to ensure that the data was not modified in transit over the network by attackers intending to compromise the data. This risk is called Data Integrity risk. It is also important to ensure that the data received by the payroll system is confidential and not exposed for public consumption. This risk of public exposure of data is called Data Confidentiality risk. Finally, whether you continue business-as-usual depends on whether the data is available and accessible at any given point of time. This is termed as Data Availability risk.
The internal HR database system does not pose much of a challenge as compared to the external partner system, but best practices do indicate that it is always advisable to protect a network from internal threats as well.
Here’s a more detailed look at the various risks introduced above:
Access Control Risk
SOA adds a new element of risk to network access control and intrusion prevention. While not requiring a categorical shift in network security practices, SOA necessitates 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 close look at how they secure network and application resources from machines both from within the network as well as from outside the network that could impact the performance and availability of critical resources. At the systems level, a coordinated XML attack could even result in a Denial-of-Service (DoS) for the enterprise.
Endpoint Integrity Risk
SOA raises the level of exposure of system endpoints on the network. An SOA can expand the scope of a network dramatically, even to the point of including little-known 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 not under IT’s control, that Web Service consumer is, in effect, an endpoint on the network. Several security and compliance-related risks that arise with this situation require counter measures. When a Web Service request and response (usually taking the form of SOAP XML) travels back and forth on the various networks that connect the Web Service and its consumer, each hop in the message transit raises a level of exposure to eavesdropping, unauthorized message modification in transit, or lack of data availability due to message failure.
Data Integrity Risk
Exposing applications on a network to potentially unauthorized use as Web Services increases the risk of compromised data integrity. Because Web Services make more information about themselves publicly available than conventional software programs, Web Services are inherently more vulnerable to sophisticated attacks. For example, a hacker could configure a Web Services consumer to transmit an unauthorized database query, using an XML injection technique. Similarly, a Web Service is vulnerable to a range of XML external entity attacks, because a hacker could use the WSDL document to learn how to design a Web Service consumer to exploit specific vulnerabilities in the application. Existing application security controls may not be adequate to mitigate these types of threats. These controls may need to be configured and kept up to date as XML threats evolve. Data integrity risks also increase with SOA implementation because XML messages traveling across the open Internet can be intercepted and modified in transit, without detection.
Data Confidentiality Risk
SOA heightens data confidentiality risk levels in two ways. First, the XML messages that constitute the working mechanism of Web Services are text-based in their raw state and, as they travel across the public Internet, are highly vulnerable to eavesdropping. Second, unmitigated access control vulnerability in SOA can result in unauthorized access to confidential data, or improper disclosure of that data.
Data Availability Risk
Web Services not governed properly tend to have unpredictable load characteristics, which can produce a high level of risk for data availability, especially when combined with the threats of XML parser attacks and SOAP array overflow attacks.
Data availability is directly dependent on network availability, which if not properly governed, can have significant impact on the SOA. Hence, having a high availability architecture baked into network design is critical for reliable functioning of SOA. The unpredictable load characteristics of Web Services traffic can cause bottlenecks in the data network infrastructure as well, resulting in poor performance and response times from systems on the network. The ability for network infrastructure to scale without impacting network performance becomes critical for business applications that need always-on access to other systems on the network OR the internet. Web Services are vulnerable to attacks that send endless strings of XML, which overload the capacity of the Web Services to respond. This overflow then makes application data unavailable.
Impact of SOA Security Risks on Sarbanes Oxley Section 404 Compliance
It is unlikely that every security vulnerability within SOA will render internal controls over financial reporting deficient. However, as internal controls are connected, tested and certified for SOX 404 with their underlying software and network components, there may be quite a few places where increased risk from SOA can affect an internal control.
Management must first consider its planning and scoping of SOA in relation to critical business processes. For example, if SOA is used for a non-financial-related process, such as customer service calls and survey information, then SOA-related security would not be an issue. However if an entire sales cycle is significantly dependent upon SOA, then management should identify the financial risks related to SOA, and then rank them according to their financial assertion impact. This process is not only time consuming but involves different organization and different levels of management, such as IT Admin, VP of Operations, VP of Sales and so on. Creating a “What Could Go Wrong” worksheet that is specific to SOA security risks, change management risks, and impact to financial reporting, would provide a solid start to understanding how SOA impacts the current SOX compliance process.
Once the potential financial reporting risks using SOA 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 to provide to external auditors. Therefore, these types of companies are looking for alternatives, such as additional oversight on internal controls by upper management (e.g. CEO, BOD, etc.) or outsourcing it to other service providers. The United States’ Committee of Sponsoring Organization of the Treadway Commission (COSO) – which backs independent private sector studies on causal factors that can lead to fraudulent financial reporting – had released guidance dealing with “segregation of duties” issues with smaller public companies as well as IT General Controls. One should be aware that the guidance is very broad and does not specify SOA-related risks and controls. Therefore, setting up an internal SOX committee to spearhead the SOX compliance process is strongly recommended.
Solutions to SOA Compliance Challenges at the Network Layer
Comprehensive SOA Governance is the key to mitigating risk in SOA and assuring the effectiveness of the internal controls that rely on SOA components. There are many equally valid approaches to SOA Governance, but we recommend the following “best practice” guidelines when evaluating options. As standards, procedures and guidelines for SOA Governance are defined, which might ideally be part of an overall Information Security Governance document set, provide a highly automated mechanism to define, monitor, and enforce those standards during the SOA transition. Ideally, enterprises will implement an SOA Governance approach, which is embodied in interlocking sets of software and hardware that enables security policy for a Web Service to be defined during the design phase of the SOA, and continue to enforce and monitor those policies as the Web Service is deployed at runtime. Any serious SOA Governance approach also needs to 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 out to the network, or networks, that comprise an expanded SOA. To mitigate against the data availability, integrity, and confidentiality threats that SOA exacerbates, it is best to have a way to deploy network level countermeasures—usually consisting of high performance routing and security infrastructure, specialized security devices like XML firewalls, application acceleration products, and the like—and produce auditable records of compliance in a cost-effective manner. It is important to ensure that the services provided by the network take into account the requirement to interoperate with various systems using a standards-based approach, combined with the ability to handle unpredictable traffic loads without impacting performance. By taking a holistic approach to security to mitigate the different types of risks while leveraging existing investments, enterprises can pave a smooth path for the success of SOA.
Conclusion
Web Services and SOA, while offering clear business value, can also disrupt the security of a network, and affect compliance as a result. It is advised that architects, security executives, and compliance teams work together to identify network-specific risks in the SOA that could have a negative impact on the effectiveness of internal controls. There are risks, as we have noted, but the key to success in managing network security and availability risks in the SOA from a compliance perspective is to isolate those network issues that directly affect the highest value internal controls. If one does not weigh the costs and benefits of each countermeasure, compliance efforts may be stretched too thinly to be effective in this regard.
SOA: A Brief Technological Overview
Service-Oriented Architecture is an approach to enterprise architecture that is based on the idea of software applications sharing functions with one another as “services.” In contrast to conventional architectures, where each application stands alone within its own “silo” and performs its function strictly by using its own code base, an SOA opens up applications as both consumers and producers of functionality that other applications can leverage from each other.
For example, if a bank maintains separate credit card and mortgage loan processing systems, each would require access to customer information, such as social security numbers, addresses, and other relevant application information. Currently, each system has its own separate database containing duplicate sets of the same customer data. Alternatively, the bank may set up and maintain a proprietary middleware solution to keep both databases updated and maintained.
However, in a SOA-based approach to this situation, customer addresses, social security numbers, and other duplicate information would be exposed as a “service” that any system could invoke when it needed specific customer data. Now, with the advent of XML, the Internet, and other widely accepted standards, the ideal of achieving service orchestration and open interoperability of disparate, heterogeneous systems has finally come of age. In fact, SOA is everywhere and you’re probably using it in your daily life; some examples are Microsoft’s .NET, BEA’s Aqualogic, Oracle’s Fusion Middleware, and SAP’s NetWeaver.
The core unit of SOA is the Web Service, the de facto standard component model for SOA. Web Service is a discrete piece of application functionality that is communicated in a specialized format of XML known as Simple Object Access Protocol (SOAP). The Web Services standards (ratified by WS-I) also include UDDI, a registry of Web Services available to an enterprise, and Web Service Description Language (WSDL), a standard document that describes a Web Service’s functionality for potential consumers.
Business Benefits of SOA
Many large companies and public sector organizations have embraced SOA because of the paradigm’s potential to reduce IT operating expense while simultaneously promoting agility and flexibility. While this is easier said than done, it is possible to achieve breakthroughs in IT productivity and cost reductions by exposing enterprise applications as Web Services as opposed to alternative solutions to this issue, such as middleware. At the same time, by utilizing common open standards for interoperability, it becomes easier, cheaper, and faster—in theory at least—to have IT respond dynamically to shifts in business strategy and operational goals.
Security Risks with SOA at the Network Layer
However—and there’s always a “however” with this kind of complex, technological implementation—SOA increases an enterprise’s level of exposure to a number of security and compliance risks. Some of these risks are familiar to the IT audit field, and some are wholly new. All of the network risks of SOA, though, need to be addressed.
To understand how SOA heightens security and compliance risks, let’s take a quick look at some of the security characteristics of Web Services. Web Services expose application functionality to virtually any consumer that can access them over the Web. In other words, what once may have been a highly defended system is now open, through Port 80, to universal access. If this hasn’t turned on your internal audit “risk meter,” then consider the fact that Web Services have a purely logical relationship to one another. A Web Service is essentially a programming object that can be invoked through a unique URL. Therefore, as long as an application has access to the Web, it can invoke Web services that reside on machines and networks that could be anywhere in the world. Conversely—and this is where there can be trouble—any application that puts a Web Service’s URL into its code can invoke that system on the network without warning or access control, unless IT governs the Web Service and institute a range of network level controls. Finally, XML is an open standard that is text-based. If not controlled, it can be easily intercepted, read, and modified in transit.
SOA network-level risks present themselves both internally and externally. Systems within an enterprise that use Web Services to interoperate are more vulnerable to internal and external attacks. The situation becomes even more complex when these systems use Web Services exposed by outside entities, such as suppliers and business partners. Essentially, SOA can disrupt what has traditionally been considered to be the network perimeter. With SOA, a Web Service exposed to the public Internet OR a Web Service accessed from outside the network, means that the network no longer has a perimeter.
To round out the security issues, let’s look at SOA from another perspective; if you are exposing a service to outside entities, you should be concerned with how this service is going to be used and who is going to use it. That is, will your security be compromised because of the service, and if so, how can you be sure that only authorized parties are using this service and only for legitimate purposes?
If your applications are accessing services from outside entities, you need to be certain that you are truly accessing the correct service from the correct provider. (Spoofing and comparable forms of hacking are unfortunately quite common on the Internet.) Will your network and applications be compromised (worms, virus, trojans etc.) if you access this service? Finally, will this service be available when you need it? Will this service respond to your requests in a timely manner so that you can go about doing business as usual? What impact is the service going to have on your network traffic load?
At a high level, SOA defeats the concept of enterprise perimeter. Now, outside entities can have access to certain services from within your network. You need to look at traffic coming onto your network and make a determination as to who is connecting, apply appropriate security policy based on identity, and provide appropriate service with predictable performance/service levels. So, it becomes worth investigating to see if you need to augment your existing firewall solution with other solutions like intrusion prevention and access control if required.
The security risks can be divided into two broad categories: network-related risks and application-related risks. In order to understand these risks, let us look at an example of a payroll application accessing point-of-sale data from a business partner as well as from an HR database to know the employees salary data all exposed in the form of Web Services:
Network-related risks – The payroll system is running on a network and is accessing Web Services from an external entity, a business partner. First, the payroll system must know that it is accessing a valid service from a known entity and not a dummy service setup by a hacker. This risk can be called an Access Control risk. Second, the system should ensure that the partner system is not going to be a cause of network outage because that system was compromised by a hacker attack or a virus attack. This risk is an Endpoint Integrity risk. Similarly, the partner system would like to make sure that it is talking to a known entity and that the payroll system requesting a service is not going to compromise its own security and integrity.
Application-related risks – Once it is certain that communication is truly happening with a ‘safe’ system, it is important to ensure that the data exchange that happens between the payroll system and the partner system for point-of-sale information is not going to create additional vulnerabilities in the network (XML-related threats, etc.). It is important for the payroll system to ensure that the data was not modified in transit over the network by attackers intending to compromise the data. This risk is called Data Integrity risk. It is also important to ensure that the data received by the payroll system is confidential and not exposed for public consumption. This risk of public exposure of data is called Data Confidentiality risk. Finally, whether you continue business-as-usual depends on whether the data is available and accessible at any given point of time. This is termed as Data Availability risk.
The internal HR database system does not pose much of a challenge as compared to the external partner system, but best practices do indicate that it is always advisable to protect a network from internal threats as well.
Here’s a more detailed look at the various risks introduced above:
Access Control Risk
SOA adds a new element of risk to network access control and intrusion prevention. While not requiring a categorical shift in network security practices, SOA necessitates 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 close look at how they secure network and application resources from machines both from within the network as well as from outside the network that could impact the performance and availability of critical resources. At the systems level, a coordinated XML attack could even result in a Denial-of-Service (DoS) for the enterprise.
Endpoint Integrity Risk
SOA raises the level of exposure of system endpoints on the network. An SOA can expand the scope of a network dramatically, even to the point of including little-known 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 not under IT’s control, that Web Service consumer is, in effect, an endpoint on the network. Several security and compliance-related risks that arise with this situation require counter measures. When a Web Service request and response (usually taking the form of SOAP XML) travels back and forth on the various networks that connect the Web Service and its consumer, each hop in the message transit raises a level of exposure to eavesdropping, unauthorized message modification in transit, or lack of data availability due to message failure.
Data Integrity Risk
Exposing applications on a network to potentially unauthorized use as Web Services increases the risk of compromised data integrity. Because Web Services make more information about themselves publicly available than conventional software programs, Web Services are inherently more vulnerable to sophisticated attacks. For example, a hacker could configure a Web Services consumer to transmit an unauthorized database query, using an XML injection technique. Similarly, a Web Service is vulnerable to a range of XML external entity attacks, because a hacker could use the WSDL document to learn how to design a Web Service consumer to exploit specific vulnerabilities in the application. Existing application security controls may not be adequate to mitigate these types of threats. These controls may need to be configured and kept up to date as XML threats evolve. Data integrity risks also increase with SOA implementation because XML messages traveling across the open Internet can be intercepted and modified in transit, without detection.
Data Confidentiality Risk
SOA heightens data confidentiality risk levels in two ways. First, the XML messages that constitute the working mechanism of Web Services are text-based in their raw state and, as they travel across the public Internet, are highly vulnerable to eavesdropping. Second, unmitigated access control vulnerability in SOA can result in unauthorized access to confidential data, or improper disclosure of that data.
Data Availability Risk
Web Services not governed properly tend to have unpredictable load characteristics, which can produce a high level of risk for data availability, especially when combined with the threats of XML parser attacks and SOAP array overflow attacks.
Data availability is directly dependent on network availability, which if not properly governed, can have significant impact on the SOA. Hence, having a high availability architecture baked into network design is critical for reliable functioning of SOA. The unpredictable load characteristics of Web Services traffic can cause bottlenecks in the data network infrastructure as well, resulting in poor performance and response times from systems on the network. The ability for network infrastructure to scale without impacting network performance becomes critical for business applications that need always-on access to other systems on the network OR the internet. Web Services are vulnerable to attacks that send endless strings of XML, which overload the capacity of the Web Services to respond. This overflow then makes application data unavailable.
Impact of SOA Security Risks on Sarbanes Oxley Section 404 Compliance
It is unlikely that every security vulnerability within SOA will render internal controls over financial reporting deficient. However, as internal controls are connected, tested and certified for SOX 404 with their underlying software and network components, there may be quite a few places where increased risk from SOA can affect an internal control.
Management must first consider its planning and scoping of SOA in relation to critical business processes. For example, if SOA is used for a non-financial-related process, such as customer service calls and survey information, then SOA-related security would not be an issue. However if an entire sales cycle is significantly dependent upon SOA, then management should identify the financial risks related to SOA, and then rank them according to their financial assertion impact. This process is not only time consuming but involves different organization and different levels of management, such as IT Admin, VP of Operations, VP of Sales and so on. Creating a “What Could Go Wrong” worksheet that is specific to SOA security risks, change management risks, and impact to financial reporting, would provide a solid start to understanding how SOA impacts the current SOX compliance process.
Once the potential financial reporting risks using SOA 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 to provide to external auditors. Therefore, these types of companies are looking for alternatives, such as additional oversight on internal controls by upper management (e.g. CEO, BOD, etc.) or outsourcing it to other service providers. The United States’ Committee of Sponsoring Organization of the Treadway Commission (COSO) – which backs independent private sector studies on causal factors that can lead to fraudulent financial reporting – had released guidance dealing with “segregation of duties” issues with smaller public companies as well as IT General Controls. One should be aware that the guidance is very broad and does not specify SOA-related risks and controls. Therefore, setting up an internal SOX committee to spearhead the SOX compliance process is strongly recommended.
Solutions to SOA Compliance Challenges at the Network Layer
Comprehensive SOA Governance is the key to mitigating risk in SOA and assuring the effectiveness of the internal controls that rely on SOA components. There are many equally valid approaches to SOA Governance, but we recommend the following “best practice” guidelines when evaluating options. As standards, procedures and guidelines for SOA Governance are defined, which might ideally be part of an overall Information Security Governance document set, provide a highly automated mechanism to define, monitor, and enforce those standards during the SOA transition. Ideally, enterprises will implement an SOA Governance approach, which is embodied in interlocking sets of software and hardware that enables security policy for a Web Service to be defined during the design phase of the SOA, and continue to enforce and monitor those policies as the Web Service is deployed at runtime. Any serious SOA Governance approach also needs to 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 out to the network, or networks, that comprise an expanded SOA. To mitigate against the data availability, integrity, and confidentiality threats that SOA exacerbates, it is best to have a way to deploy network level countermeasures—usually consisting of high performance routing and security infrastructure, specialized security devices like XML firewalls, application acceleration products, and the like—and produce auditable records of compliance in a cost-effective manner. It is important to ensure that the services provided by the network take into account the requirement to interoperate with various systems using a standards-based approach, combined with the ability to handle unpredictable traffic loads without impacting performance. By taking a holistic approach to security to mitigate the different types of risks while leveraging existing investments, enterprises can pave a smooth path for the success of SOA.
Conclusion
Web Services and SOA, while offering clear business value, can also disrupt the security of a network, and affect compliance as a result. It is advised that architects, security executives, and compliance teams work together to identify network-specific risks in the SOA that could have a negative impact on the effectiveness of internal controls. There are risks, as we have noted, but the key to success in managing network security and availability risks in the SOA from a compliance perspective is to isolate those network issues that directly affect the highest value internal controls. If one does not weigh the costs and benefits of each countermeasure, compliance efforts may be stretched too thinly to be effective in this regard.
Related Links
None
