Friday, December 28, 2012

Security Plans Boost Security & Cut Costs


Enterprise Security ..







Enterprise Security Planning with TOGAF-9



The Open Group Architecture Framework (TOGAF) is a framework - a detailed method and a set of supporting tools for developing enterprise architecture . TOGAF 9 is much different from other architecture frameworks such as Zachman , as it is lot more process driven and gives you a way to essentially codify architectural patterns . Key enhancement in TOGAF 9 is the introduction of a seven-part structure and reorganization of the framework into modules with well-defined objectives. This will allow future modules to evolve at different speeds and with limited impact across the entire blueprint -- something that's needed if you're looking to create architecture within compartments and have those compartments operating independently . TOGAF 9, first of all, is more business focused. Before that it was definitely in the IT realm, and IT was essentially defined as hardware and software. The definition of IT in TOGAF 9 is the lifecycle management of information and related technology within an organization. It puts much more emphasis on the actual information, its access, presentation, and quality, so that it can provide not only transaction processing support, but analytical processing support for critical business decisions
 
TOGAF Structure 
 

 

 
1. Introduction : This part provides a high-level introduction to the key concepts of enterprise architecture and in particular the TOGAF approach( definitions of terms used throughout TOGAF).
2. Architecture Development Method :  It describes the TOGAF Architecture Development Method (ADM) - a step-by-step .
3. ADM Guidelines and Techniques :collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM.
4.  Architecture Content Framework :  describes the TOGAF content framework, including a structured meta model for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables.
5.  Enterprise Continuum & Tools : discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
6.  TOGAF Reference Models : provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure .
7.   Architecture Capability Framework : discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.

TOGAF-9 Security Architecture
Security Architecture is a cohesive security design which addresses the requirements and in particular the risks of a particular environment/scenario and specifics what security controls are to be applied where. The design process should be reproducible. This definition is intended to specify only that, architecture is a design, which has a structure and addresses the relationship between the components .
 Security for Architecture Domains
All groups of stakeholders in the enterprise will have security concerns. These concerns might not be obvious as security-related concerns unless there is special awareness on the part of the IT architect. It is desirable to bring a security architect into the project as early as possible. In TOGAF 9, throughout the phases of the ADM, guidance will be offered on security-specific information which should be gathered, steps which should be taken, and artifacts which should be created. Architecture decisions related to security, like all others, should be traceable to business and policy decisions, which should derive from a risk analysis. 
Areas of Concerns for Security Architecture
  1. Authentication: The authenticity of the identity of a person or entity related to the system in some way .
  2. Authorization: The definition and enforcement of permitted capabilities for a person or entity whose identity has been established.
  3. Audit: The ability to provide forensic data attesting that the system was used in accordance with stated security policies.
  4. Assurance: The ability to test and prove that the system has the security attributes required to uphold the stated security policies.
  5. Availability: The ability of the system to function without service interruption or depletion despite abnormal or malicious events.
  6. Asset Protection: The protection of information assets from loss or unintended disclosure, and resources from unauthorized and unintended use.
  7. Administration: The ability to add and change security policies, add or change how policies are implemented in the system, and add or change the persons or entities related to the system.
  8. Risk Management: The organization's attitude and tolerance for risk. (This risk management is different from the special definition found in financial markets and insurance institutions that have formal risk management departments.
Security Architecture Artifacts
Typical security architecture artifacts should include :
  1. Business rules regarding handling of data/information assets .
  2. Written and published security policy.
  3. Codified data/information asset ownership and custody .
  4. Risk analysis documentation .
  5. Data classification policy documentation .
  6.  
        ADM Security Architecture Requirement Management

Security Policies and security standards are one of the most important part of enterprise requirement management process. Security policies are established at executive level and have the characteristics like durability, resistant to impulsive change, and not technology specific. Once established act as a requirement for all architecture projects. Security standards are highly dynamic and state technological preferences used to support security policies. Security standards will manifest themselves as security-related building blocks in the Enterprise Continuum. Security patterns for deploying these security-related building blocks are referred to in the Security Guidance to Phase E.
New security requirements arise from many sources :
  1. A new statutory or regulatory mandate .
  2.   A new threat realized or experienced .
  3.  A new IT architecture initiative discovers new stakeholders and/or new requirements .   
 In the case where 1. and 2. above occur, these new requirements would be drivers for input to the change management system discussed in Phase H. A new architecture initiative might be launched to examine the existing infrastructure and applications to determine the extent of changes required to meet the new demands. In the case of 3. above, a new security requirement will enter the requirements management system .
Finally ,Unless the security architecture can address a wide range of operational requirements and provide real business support and enablement, rather than just focusing upon short-term point solutions, then it will likely fail to deliver what the business expects. This type of failure is a common phenomenon throughout the information systems industry, not just in the realm of security architecture. Yet it is not sufficient to compile a set of business requirements, document them and then put them on the shelf, and proceed to design a security architecture driven by technical thinking alone.
Being a successful security architect means thinking in business terms at all times, and setting up quantifiable success metrics that are developed in business terms around business performance parameters, not technical ones.
 
 
Reference :
 

Tuesday, October 2, 2012

About Me:


Name of a flower, closeness or permanent consider the depth and calm and a good listener to talk . This is I'm (Rania ) in Arabic meaning , My character almost is part of the meaning of my name in the last section . My First breaths launched on July of the year 1991.
The life in my mind is Good relationship with God ,my family and my friends . I'm drawing some life in my imagination ; I wish to live it some day So I'm dreamer .

I'm IS student @taibah at 5th levels .

Monday, October 1, 2012