Meta trend
Volatility and immaturity in security technology will continue to make enterprisewide technology architectures impractical through 2003. However, the need for a consistent approach, scalability, agility, and auditability will drive development of adaptive, top-down security architectures encompassing consistent policy frameworks, strong process orientation, service definitions, formal roles/responsibilities, and domain-specific technology standards (2002-03). Scalable technology architectures for security will evolve as a result of broader standards (2004-06).

Rulings by the Federal Trade Commission pertaining to privacy and security issues (e.g., against Eli Lilly and Microsoft) have focused not on monetary fines, but on the requirement that a "security program" be established and maintained to protect the privacy and confidentiality of (consumer) information. Meta Group interprets this as a precursor to (if not the equivalent of) requiring a security architecture, which Meta Group defines as a set of guiding principles and the resultant embodiment of those principles in the form of an orderly and comprehensive arrangement of security components (e.g., people, process, and technology).

[an error occurred while processing this directive]

Meta Group believes the benefits of taking an architecture-based approach to information security include reduced liability (regulatory, contractual, and tort/negligence) and improved efficiency and effectiveness of security initiatives derived from increased reuse and consistency. The challenge, however, is that a standardized, comprehensive security architecture does not exist, nor does Meta Group expect one anytime soon.

Through 2003-04, progress toward an industry-standard security architecture will be limited to developing domain-specific building blocks (e.g., perimeter security architecture) and constructive frameworks/models. Undoubtedly, these efforts will be fueled by the activities of such high-profile organizations as the President's Critical Infrastructure Protection Board (e.g., publication of information security "best practices"). With auditability and efficiency as primary filtering mechanisms, Meta Group believes these initial building blocks will coalesce into de facto standards by 2004-05. However, Meta Group is skeptical that a formal, standardized security architecture will emerge prior to 2005-06.

Components
This lack of applicable standards does not obviate the need for organizations to have an information security architecture. Indeed, without one, evidence suggests that enterprises will default to a haphazard, reactive, tactical approach to constructing a secure environment, regrettably wasting resources and introducing more vulnerabilities as they proceed to fix others. Fortunately, because it would be a "living document," a prestandard architecture could presumably be adapted over time to comply with any eventual standards. Therefore, Meta Group recommends that information technology organizations embrace the concept of an information security architecture, which includes the following main components:

• A statement of high-level objectives: This serves as the linkage between business goals and information security goals.
• A process-centric organizational model: The goal is to clearly delineate roles and responsibilities pertaining to information security. Also, the head of information security within an enterprise will be the owner of the architecture defined within.
• A hierarchically structured policy framework: This links business requirements through to domain-specific technology and configuration details in a highly flexible manner.
• A catalog of security processes: The catalog should include both strategic and operational security processes.
• A security services framework: This is a reference model, taxonomy, or linked list that bounds the scope of the security services to be provided, indicates their inter-relationships, and provides a common language for both IT and business to use when discussing security controls.
• A domain structure: This is the decomposition of the enterprise into manageable portions, with groupings ideally based on sets of resources that have similar security requirements.
• Trust-level definitions: These typically take the form of a matrix that correlates relative degrees of trust with the corresponding security controls (i.e., technologies and processes) required to achieve and support each trust level.
• Tools and templates: These are needed to support development of the security program and execution of the security processes (e.g., a trust modeling tool to establish the required trust level of a new application or project, or a trust measurement tool to assess the "as is" trust level of a given domain).
• Technology option matrices: These map generic security services to the corporate-approved mechanisms and products for delivering those services.