For last couple of days I managed to read a bit about composite systems and how useful the component based Software Engineering when it comes to the industry. The flexibility of coupling and decoupling components in a composite systems and reusability of using one component in a number of such systems makes them very attracted in numerous applications.
But at the same time we have to consider about the security concerns in that approach. These concerns can be divided into two categories.
1.Security concerns of the component
2.Security concerns when the component is inegrated and used
When forming or modifying composite systems by coupling and decoupling different components the integrator has to evaluate how the component is secured itself. In other words how securely the component is being built by the developer.
Also the integrator has to evaluate how the system is secured from the components. A set of secure components doesn’t always guarantee a secure system. The integrator has to determine for what extent the system can trust the component.
This brings us to the topic of Trust Management in component based software engineering.
Subscribe to:
Post Comments (Atom)
2 comments:
Indeed! When you think about production deployments of these component based software products security scenarios become much more complex. There are an increasing number of products being deployed with fail-safe designs 'cos of their importance to critical business needs. So even though you have sufficiently isolated each component from rest of the system now you have to allow two or more products to interact, making the security scenarios much more complex. And you have to loose the grip of isolation and make the state of one system visible to another.
As one example, if there are handover procedures when one system fails, now you have to make sure security is not compromised before/during/after the handover process.
Yeah due to this complexity it is difficult to find the EXACT solution. But the complexity can be avoided by profiling the security properties of these components. These profiling need a common syntax. Also it's required to have a common way to specify the contracts between different components in a system. Basically the integrator, which can be a software agent or a human, can make decisions easily. Also it is required to profile the security properties of the composite system after the integration in the same way. The reason is that the composite system can be a component of a global composite system.
Post a Comment