The Four W s


The Four W's

Critical security flaws and exploits can exist across multiple server or application components. This fact reinforces the critical importance of end-to-end securitynot just security for a server or a specific application component. However, how should security architects and developers begin establishing end-to-end security? We can get started from the perspective of the four W's:

  • Which applications are we protecting?

  • Who are we protecting the applications from?

  • Where should we protect them?

  • Why are we protecting them?

End-to-end security requires a particular scope and has implications based on deployment environment constraints such as network services, operating systems, and the application and identity infrastructure. The four W's can help us to identify and define those boundary constraints that are relevant to a particular deployment environment.

Which Applications Are We Protecting?

Business applications and mission-critical business services require protection from unauthorized access, and they use different levels of security access control. It is important to identify and determine which application resources need security and access control. To do so, security and access control may need to be designed based on:

  • Network applications

  • Network boundaries

  • Business data or messages

  • Required user-specific operations and transactions

  • Required administrative tasks

Who Are We Protecting the Applications From?

Applications and resources that contain personal data or sensitive business transactions require protection from users other than the owner. In other words, the system needs to protect these applications and resources from the public Internet and unauthorized users. It is important for security architects and developers to consider the possibility of protecting these applications and resources by categorizing users in their organization by rights and privileges granted. Users can then be grouped based on their access rights. Security architects and developers should also consider giving access to highly confidential data or strategic resources to only a few trusted administrators. It may be prudent not to allow administrators to access data or resources unless they have an active user account specifically defined to carry out only selected operations. Throughout the application life-cycle, logging, monitoring, and auditing user access and application events is necessary.

Where Should We Protect Them?

Understanding which applications need protection and from whom is not sufficient for end-to-end security. The next important consideration is where we should protect them. The protection should address all the aspects of an application and its associated resources, including its different tiers, components, users, hosts, and network infrastructure. The enforced protection can be based on architecturally significant security criteria such as the specific location (e.g., single or multiple server machine, intranet, or Internet), type of connection (e.g., TCP/IP or SOAP), nature of the objects or resource (e.g., database objects), communication (e.g., SSL/TLS, IPSec), client infrastructure, and so on.

Why Are We Protecting Them?

A fault in the system security of business applications may cause great damage to an organization or to individual clients. Understanding the potential for damage from security breaches will help security architects and developers protect business applications and resources properly. Thus, it is important to understand the threat levels and vulnerabilities and then plan and establish a service recovery and continuity program for all potential failures.




Core Security Patterns. Best Practices and Strategies for J2EE, Web Services, and Identity Management
Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management
ISBN: 0131463071
EAN: 2147483647
Year: 2005
Pages: 204

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net