What are the biggest security risks/concerns that you feel that architects need to address when implementing SOA? Assume that the SOA implementation includes mashups, B2B integration, and legacy rejuvenation.
Clarification added 3 months ago:
Just to clarify, what security concerns does SOA introduce above and beyond our traditional architectures/systems?
Good Answers (16)
Ashwini A
Vice President - Governance, Risk & Compliance at Mascon Global (GRC)
Best Answers in: Information Security (1)
There are multiple new threat vectors that SOA, B2B and especially Mashups introduce. Mashups are traditionally being done where many public web based services, like Google maps, Amazon etc are being leveraged within enterprise applications to show useful content. While great from an end user perspective, to see your customers on a map, from a security perspective it is absolutely horrendous. Many developers don't understand the implications of using these public services and doing mashups. so education is very important.
When you say SOA - is it "true" SOA or just doing the same thing as always, just using webservices instead. If it is the latter, there is really not a whole lot of complication besides making sure the webservices are not accessible to any application that should not have access to the data - even internally. So have a good layer of security that authenticates who is using the webservice and only then allows them through (over SSL ofcourse).
In a true SOA paradigm, you need a lot more emphasis on security as you don't really want to burden each service with its own security layer. Security itself needs to be designed as a service that is being used to allow/deny every transaction taking place, and every connection request between services, application to service, user to service, service to service etc.
Additionally, when you build a composite application using these services, that application as a unit needs to have its security realm that is enforced and propagated down to all sub services.
products like Securent etc, really help design and build that external "Security service" that applications can use, and where policies can be centrally managed.
So in short - there are a lot more risks/concerns that architects need to address.
Jordan B
Principal SOA, EA, Solution Architect; Sr. Consulting Manger; Evangelist & Biz Dev; Practitioner; Project Manager, LION
Information Security Policy: The wrong people having access to information they shouldn't have access to. That can be internal, cross-departmental, or a Trading Partner.
Geoff F
"Hands-on" Software Architect and Senior Developer
Best Answers in: Computers and Software (3), Web Development (3), Starting Up (2), Enterprise Software (2), Software Development (2), Occupational Training (1), Offshoring and Outsourcing (1), Planning (1), Professional Organizations (1), Information Storage (1), Using LinkedIn (1)
Clearly define authorization roles for each information entity. To do this well, you must understand the application, the client organizations, the users and the audiences for the information.
I would also spend time understanding "the 3rd stop" for what information is provided. Where does it go after it was picked from your design? What are the service contracts for an assigned role?
Jane P
Senior Consultant at Improving Enterprises
Best Answers in: Software Development (3), Resume Writing (1), Personal Taxes (1), Professional Books and Resources (1), Web Development (1)
Security includes 3 aspects: authorization, authentication, and transport security.
Authorization means that only those authorized should get access.
Authentication means that the system has a reasonable way to verify that its users are who they say they are.
Transport security is about preventing snooping and modification to data while on the wire.
The hardest challenge is to make the system secure and usable at the same time. You need a consistent authentication policy, a way to manage access permissions, and a way to track changes, in addition to secure communication protocols.
Jane P also suggests this expert on this topic:
You are all right, there are so many software security flaws today.
In my opinion the code that handles network traffic should be analyzed for the possibility of a buffer overflow.
If the software is POPULAR the bug could result in a working exploit.
Thats also the reason i am hired to scan for known and zero day exploits.
Rick L
Chief Information Security Officer, Published Author & Advisor
Best Answers in: Information Security (9), International Law (1), Antitrust Law (1), Professional Organizations (1), E-Commerce (1), Information Storage (1)
A big risk is due to the nature of grouping services together.A vulnerability in one service under the umbrella of SOA has potentially greater impact to remaining services. Also, data reuse and transfer withing SOA services is now more likely to be distributed across systems requiring additional security control to protect that data.
John J
Identity Theft, Risk Management and Security Expert.(LION). TopLinked.com 11mil connections. I accept all invites!
Best Answers in: Risk Management (1), Information Security (1)
The biggest risk I usually see is who and where the info is stored and accessed.
The second is the quality of the info and the quality/security of how the info is used.
What architects need to build into their systems is tracking and access monitoring, also HEAVY data encryption, which is audited CONSTANTLY.
Also comprehensive background checks on employees and their stations not being able to download info into zip chips.
Risk accessment must have a strong relationships with the architects to help build in the safeguards, but...the safeguards are only as good as the makings and the constant monitoring and auditing.
Sitaraman L
Security Architect at TechDemocracy and Information Technology and Services Consultant
Best Answers in: Information Security (4)
Couple of things that is often overlooked / not address (various reasons such as development time, cost, lack of awareness, etc) is Transport level security - SSL doesnt just solve it (Encryption and digital signatures are must) and the another one is Identity Propagation. When you bring multiple systems or data together through services, you have to propagate the Identity of the actual user or process to all the systems. (In technology terms its Security Token Service).
Another important concern is to address data confidentiality policy. You have to have consistent Security policy and have enough blessings from executives to make it happen.
Another important challenge it introudcues is the adoption by internal and external team when its fully secured. You have to have equal amount of training and knowledge sharing on importance of security as much as importance of SOA. Equally weigh the security risk and solutions and pick the one that is more secure and at the same time can be easily adopted ( oh well its easier said than done).
Thanks
Ram
SOA security is technically no different than any other access to information. Any access must have authentication to prove the individual is who they say they are and there must be authorization to give them access to only the functions and information they are allowed. There also must be a secured transport when required.
Architects must stand in the gap and demand that security be part of providing any service and not let an overzealous development staff or marketing group open the organization to security breaches. In the effort to meet deadlines, security can unfortunately be treated with duct tape solutions.
My biggest concerns are 1) exposure of web services outside the firewall and mitigating the threats that come with that in a performant, configurable, and cost effective way 2) propagation of credentials across and orchestration, event chain, and legacy systems access 3) end to end proof of policy compliance and auditability.
I am most concerned that people don't understand the threats. If they don't understand the many new threats then they cannot create security measures to prevent them from disrupting the business.
Here is an article that talks about the threats.
http://soa.sys-con.com/node/232071
Hi Mike,
What I see most are the threats that are related to messaging in terms of access to the XML payload. In traditional applications, we have gotten pretty good at authentication (even though that is still hackable sometimes). However, in SOA with web massaging across HTTP/HTTPS, it is easier to find a point in the messaging process where the payload can be accessed. This can lead to a variety of attacks: malware, large payloads, XPATH injection, etc.
I hope this helps!
Randy
Let me bring up a couple of points that haven't been brought up yet:
#1) Interoperability - Choose technologies that are standard and are implemented by multiple platforms/vendors/opensource solutions.
#2) Choose the heavy stick wisely - Remember add XML Encryption slows down your app server considerably. Plan for it and consider Hardware XML solutions as well (Caveat #1).
3 big concerns architects need to address when implementing SOA are 1) propagating and managing identities 2) establishing and enforcing security policy and 3) maintaining auditability and compliance. The inherent openness of an SOA creates security challenges that must be addressed. As the applications are re-purposed and re-used, they may be extended to a new set of users, groups of people not originally envisioned in previous instances, and thereby creating security holes and risks. So traditional resource-centric security, while still necessary, is no longer adequate for dynamic SOA environments. SOA security must add a user-focused security layer, called trust management, as well as a message-focused security layer to the environment. And it must ensure that all of this remains auditable.
Links:
Joseph D
PM/IT/PS Executive, Data Management & Analytics Specialist, and Team Builder
Best Answers in: Computers and Software (1)
Mike,
security for SOA has the same concerns as security for any other data integration/sharing technology. One difference is that with SOA, we are finally coming around to something that I first wrote about almost a decade ago. The need to move away from a firewall, bastion, DMZ mentality to be concerned with controlling the flow of information, rather than restricting it. SOA security must make sure that the right data gets to the right person in a continuum of roles from public information available to all through specific data available only to one. Authentication, authorization, validation and encryption are all parts of this. But SOA must look at the source, the data and the recipient and treat all three in concert.
Although previous lessons on security still apply, SOA does introduce a concernable amount of risk to security and especially in protection of information. A service that provides contact information can innocently be exposed in an application to the wrong users. As more and more applications reuse services, the risk of exposing information inadvertently rises. Proper controls and procedures in the "design" and "runtime" governance of a SOA infrastructure with a clear security strategy becomes vital.
More Answers (1)
Steven R suggests this expert on this topic:
Security between business partners seems paramount to me but I will recommend Eric respond to this.
