SOA security Fundamentals, part 1th: Developing a roadmap to protect large SOA applications

10 steps to achieve better SOA security

Introduction: This series provides a roadmap to secure implementation of a service-oriented architecture (service-oriented architecture, SOA). A total of three parts of this series, this is the 1th part of this article, which will cover a 10-step process to help you work from building an SOA security team to creating an effective requirements gathering process. In part 2nd, we'll see how to create an abstract design, and part 3rd will discuss test cases.

I recently had the opportunity to participate in an SOA project-specifically, a security implementation of a large automatic control system. I read as many books on the subject as I could, I studied it online, and even sent emails to my former colleagues and friends to ask about the relevant issues. To my surprise, there was no roadmap for the step-by-step process I needed to help me achieve the goal of securing a large SOA application.

Finally, I had to create one of these processes myself. I have developed a simple process that contains 10 steps, as described in this article.

Step 1th Select the right team

The task of migrating large, critical infrastructure applications to SOA is daunting. It is even more difficult to protect it, and it is often necessary to adopt a new perspective to recognize it-and may even require a new set of security personnel to carry out the relevant work. Most security teams have very little training in SOA or even programming. A common approach for security authorities is to send out requests and hope that the Organization will be able to follow them. So the 1th step (which is often the hardest part) is to make sure that you have the right team.

The team should have an owner who has knowledge of security and software architecture and, ideally, knowledge of SOA. Like the Enterprise Architect, the secure Enterprise Architect (Security Enterprise Architect,sea) will be responsible for creating the overall SOA security model to integrate all the different security requirements at each granularity level. Sea will enter the SOA governance board, together with the Enterprise Architect (Enterprise Architect,ea) to ensure that all SOA implementations meet the requirements of security requirements and the security business analyst who is responsible for creating the artifacts needed throughout the process Business ANALYST,SBA) and Security systems Engineer (Systems Engineers, SSE) team to guide. Sea will also be responsible for working with programmers who write security service code and security system testers who test them before deploying the system.

Step 2nd Create a detailed project plan

For a large SOA system, step 2nd requires high-level management understanding that it will not be possible to integrate it into the old security model by improving the new SOA: this does not work. If the focus from the outset is on traditional security mechanisms, such as firewalls, intrusion detection systems, and security monitoring, this will be completely out of the reach of SOA security implementations. You will be responsible for making sure that everyone is aware of what is necessary to make the SOA security implementation clear by developing detailed project plans and budgets.

You need to be aware that any transformation to the SOA model involves inherent security contradictions: the more obvious the SOA features of the system, the worse its security. The process of transforming the current system into an SOA through service-oriented modeling and analysis technology requires the formation of business-design-related documentation. The use of formal languages that relate business design to information systems usually only illustrates the situation of contradictory, inefficient, and complex non-SOA systems. However, this complexity masks most of the problems, making it difficult for those looking for opportunities to disrupt the enterprise system to find these vulnerable links. When these systems are decomposed and SOA is enabled, the architecture that the malicious user faces is simpler and more easily compromised.

SOA advocates may deny this, but those responsible for securing the system know that open systems with centralized control points and web enabled are inherently less secure and require more responsive and flexible methods. There is no way to circumvent this problem, project planners (often assigning an appropriate set of tasks to SOA security) must keep in mind that SOA security requires detailed project planning and budgeting to allocate the necessary time for security teams to analyze and understand the new challenges of SOA implementation.