Application Development Using TOGAF

Application Development Architecture based on TOGAF

The generally accepted areas of concern for the security architect are:

• Authentication: The substantiation of the identity of a person or entity related to the enterprise or system in some way.

• Authorization: The definition and enforcement of permitted capabilities for a person or entity whose identity has been established.
  

• Audit: The ability to provide forensic data attesting that the systems have been used in accordance with stated security policies.
  

• Assurance: The ability to test and prove that the enterprise architecture has the security attributes required to uphold the stated security policies.
  

• Availability: The ability of the enterprise to function without service interruption or depletion despite abnormal or malicious events.
  

• Asset Protection: The protection of information assets from loss or unintended disclosure, and resources from unauthorized and unintended use.
  

• Administration: The ability to add and change security policies, add or change how policies are implemented in the enterprise, and add or change the persons or entities related to the systems.
  

• 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.)
  

Typical security architecture artifacts would include:

* Business rules regarding handling of data/information assets

• Written and published security policy
  

• Codified data/information asset ownership and custody
  

• Risk analysis documentation
  

• Data classification policy documentation
  

New security requirements arise from many sources:

* A new statutory or regulatory mandate

• A new threat realized or experienced
  

• 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. Security Inputs

Written security policy
Relevant statutes
List of applicable jurisdictions

Security Outputs

List of applicable regulations
List of applicable security policies
Security team roster
List of security assumptions and boundary conditions

Determine "what can go wrong?" Security Inputs

Threat analysis matrix
Risk analysis
Documented forensic processes
Validated business policies and regulations
List of interconnecting systems
New disaster recovery and business continuity requirements

Security Outputs

Event log-level matrix and requirements
Risk management strategy
Data lifecycle definitions
List of configurable system elements
Baseline list of security-related elements of the system
New or augmented security-related elements of the system
Security use-case models:
    Normative models
    Non-normative models
List of applicable security standards:
    Protocols
    Object libraries
    Others ...
Validated interconnected system list
Information classification report
List of asset custodians
Function criticality statement
Revised disaster recovery and business continuity plans
Refined threat analysis matrix