Proposal for an Enterprise Security Architecture based on the Zachman Framework, applicable to large, medium and small enterprises.

1. A Proposal for an
Enterprise Security Architecture Based
on the Zachman Framework
Joaquin Marques, Founder & CEO, Kanayma LLC

2. “Tactics is knowing what to do when there is
something to do. Strategy is knowing what to do
when there is nothing to do.”
Savielly Tartakover
Polish Chess Grand Master
Quote 1

3. "The significant problems we face cannot be solved
at the same level of thinking we were at when we
created them."
Albert Einstein
Quote 2

4. Frank Lloyd Wright
"A doctor can bury his mistakes but an architect
can only advise his clients to plant vines."
Quote 3

5. “…a software architecture is not targeted towards solving a specific
software problem, but rather it constrains the solution space from which
all possible solutions are derived. A good architecture provides a flexible
framework which can accommodate higher to unspecified problems in
that domain; i.e., its future proof. Conversely, the bad architecture
accommodates only the currently specific problems.”
Guy Fortin, Architect
Magellan Management Systems
Nortel, Ottawa
Quote 4

6. Why use the Zachman Framework for
Enterprise Security Architecture?
• Helps organize all thinking on security at all levels
• Helps organize all documentation on security at all levels
• Helps organize all security information gathering
• Offers a view of enterprise security tailored for each constituency:
board members, CSO, Chief Architect, business unit heads, application
architects, designers, programmers, infrastructure people, using views
and language they are familiar with
• Offers different orthogonal views on security from a data, function,
network, people, time and motivation perspective
• Zachman can be applied to all areas, not just security
• ZF can be introduced gradually but it is immediately useful

7. • It is the “formal name of a classification schema used to organize an
enterprise’s artifacts and help facilitate thinking, reasoning and
communicating among the participants of the enterprise”
• ZF provides an independent, holistic view of the enterprise
• ZF is neutral with respect to methodology, process and technology.
Such changes may affect artifacts, but not ZF
• ZF is neutral with respect to “breath of scope”: it can model small
subcomponents to worldwide enterprises
• ZF models all aspects of the business, not just IT
• ZF is a two-dimensional framework, with six rows (perspectives) and
six columns (aspects)
What is the Zachman Framework for
Enterprise Architecture?

8. • It is not a methodology, such as RUP. It helps to organize existing artifacts
from any methodology so that they can be best viewed from multiple
perspectives and aspects
• It is not an IT framework, but a whole enterprise framework that can be used
to focus on IT and share the results with the business, in their own language
• It is not a process or technology, but it can be used to capture processes and
technologies
• It does not force an enterprise view on you if that is not your goal: it can be
used to describe a simple component
• It does not force you to use all perspectives and all aspects at once: use as
many or as few as are most useful.
• It does not force a language onto you: each perspective can use the language
most appropriate to it.
What the Zachman Framework for
Enterprise Architecture is not …

9. What are “Perspectives” in
the Zachman Framework?
• Planner - one who establishes the universe of discourse; the background, scope, and
purpose of the enterprise
• Owner – the recipient or user of the enterprise’s end product or service
• Designer – the engineer or architect who mediates between what the owner desires
and what is technically and physically possible
• Builder – general contractor who oversees the production of the end product or service
• Subcontractor – one responsible for building and assembling the parts for the end
product or service
• Functioning enterprise – the physical manifestation of the end product or service
A perspective represents a unique point of view or frame of reference on a topic or issue from
an actual role played by an actual participant on the enterprise based on an ordered logical
method

10. What are “Aspects” in
the Zachman Framework?
• Things – lists, important items, material composition and databases; generically known as
DATA, they answer the what interrogative
• Processes – specifications, transformations and software; also known as FUNCTION, they
answer the how interrogative
• Connectivity – locations, communications, network, and hardware; better known as
NETWORK, they answer the where interrogative
• People – workflows, operating instructions and organizations; they answer the who
interrogative
• Timing – life cycles, events, state transitions, and schedules; also known as TIME, they answer
the when interrogative
• Motivation – strategies, desired results and means of achievement; they answer the why
interrogative
An aspect is the result of using an ordered logical method to break an issue or topic into its defined,
logical parts. Each aspect is a response to one of the six basic interrogatives: what, how, where,
who, when, why.
All six aspects provide a complete enterprise view from each perspective.

11. What does the Zachman
Framework look like?
Things
Processes
Connectivity
People
Timing
Motivation
Planner
Owner
Designer
Builder
Subcontractor
Functioning
Enterprise
Aspect
Perspective
It is a two-dimensional schema showing six perspectives
against six aspects, with a total of thirty six cells.

12. The Zachman Framework can be
applied recursively…
Enterprise
Organization
Role
Multiple ZFs can be embedded and used to capture different scope levels,
such as Enterprise, Organization, and Role, as shown above

14. The Zachman Framework from an Enterprise
Security Architecture Perspective
• At its heart, security is about people’s access to systems and data. People are at the
center of security architecture
• Zachman offers a People column, so let’s focus on it
• The People column offers an Enterprise, Organization Unit, Role, User, and Identity
perspective, one per row
• Users and identities can change, but roles very seldom change within an organization
• Of all those perspectives, the one that makes more sense for Enterprise Security
Architecture is a Role-based perspective. Thus, we choose role-based security
• All other perspectives on security are still valid, as long as they are explicitly or implicitly
constrained by “role”
• Every relevant piece of enterprise security belongs to an appropriate cell in the
Zachman Framework

15. Security Architecture Levels: Focus
on the “People” Column
Role-level
Security
Example: Authorization
User-level
Security
Example: Authentication
Identity-level
Security
Example: SSL Session
Organization-level
Security
Examples: B2B Certification
Chief Security
Officer/Architect
Enterprise-level
Security
Example: Single Sign On (SSO)
Business Unit/
Security Architect
Application Security
Architect/Designer
Application
Programmer
Security Programmer
/Security DBA
Focus

16. A Zachman “Designer” Perspective of an
Enterprise Security Architecture
• Since we are assuming role-based security, we will also focus on the “role” or
“designer” row of ZF, row 3, also known as the “System Model” or “logical”
level.
• In IT, “designer” row 3 corresponds to an “Application Security
Architect/Designer” level, i.e., someone doing the security systems level
architecture or design
• The next slide will show how each aspect (data, function, network, people,
time, motivation) of row 3 provides information on security from an
“Example”, “Perspective”, “Focus Question” and “Implementation” point of
view.
• A “Focus Question” is a question that helps us determine the appropriate
contents for a ZF cell, row or column
• The slide after next shows the complete Focus Question inherent in row 4,
from a “Systems” & “Role” perspective

17. Security Architecture from the “Application
Security Architect/Designer Level” Row Perspective
Example
Description
Focus Question
Implementation
Logical Data
Model
Application
Architecture
Distributed
Systems
Architecture
Human
Interface
Architecture
Processing
Structure
Business Rule
Model
Role-based
Data Access
Model
Role-based
Authorization
APIs
Location-based
Security
Architecture
Role-based
Security
Architecture
(Authorization)
Processing
Cycles/System
Events per
Role
Business
Objectives
based on a
specific
Role
Which data
entities can
each role
access?
Which methods
can each role
execute?
Which IT
resources can
each role have
access to?
What other
roles can each
role interact
with?
Which system
events can each
role initiate or
accept?
Which business
rules guide or
constrain each
role?
LDAP Record
/Role Profile
vis-avis data
fields
LDAP Record/
Role Profile
vis-à-vis apps
& methods
SiteMinder
Policy Rules,
Blaze Rules &
Configuration
Rules
SiteMinder
Authorization
Rules, Policy Rules,
Blaze Rules &
GUI Rules
SiteMinder
Policy Rules &
Blaze Rules
SiteMinder
Policy Rules &
Blaze Rules

18. Security Architecture Focus Question from the “Application
Security Architect/Designer Level” Row Perspective
Designer Focus Question
“For each Role in an Organization:
• which data entities can that role access?
• what apps and methods can the role execute?
• which IT resources can the role have access to?
• what other roles in what organizations can the role interact with?
• which system events in which processing cycles can the role initiate
or accept?
• which business rules guide or constrain the role?”

19. A Zachman “Owner” Perspective of an
Enterprise Security Architecture
• In row 2 of ZF, also known as the “Business Model” or “conceptual” level, the
“Organization Unit” is the “role”
• In IT, “owner” row 2 corresponds to an “Business Unit/Security Architect”
level, i.e., someone doing the “business level” security architecture or design
• The next slide will show how each aspect (data, function, network, people,
time, motivation) of row 2 provides information on security from an
“Example”, “Perspective”, “Focus Question” and “Implementation” point of
view.
• A “Focus Question” is a question that helps us determine the appropriate
contents for a ZF cell, row or column
• The slide after next shows the Focus Question inherent in row 2, from a
“Business & Organization Unit” perspective

20. Security Architecture from the “Business Unit/
Security Architect” Row Perspective
Example
Description
Focus Question
Implementation
Semantic
Model
Business
Process Model
Business
Logistics
System
Work Flow
Model
Master
Schedule
Business Plan
Organization
Unit-based
Business-
Entity Access
Model
Organization
Unit-based
Business
Process
Authorization
Model
Distributed
Security
Architecture
within an
Organization
Unit
Workflow
Security
Architecture
Business
Cycles/Busines
s Events per
Organization
Unit
Business
Objectives/
Business
Strategies
by
Organization
UnitWhat business
entities can
each
Organization
Unit access?
Which business
processes can
each
Organization
Unit perform?
Which business
locations can
each Org Unit
work from?
What other
organization
units can each
Org Unit
interact with?
Which business
events can each
Organization
Unit initiate or
accept?
Which business
objectives can
the
Organization
Unit support?
Metadata model
of relationships
between
business entities
& organizations
Business
Process Model
doc detailing
Org Unit’s
processes
Business
Logistics doc
detailing where
work gets done
in Org Unit
Workflow
Model doc
detailing
restrictions on
interactions
Master
Schedule
detailing
business cycles
& events
Business Plan
for the
Organization
Unit

21. Security Architecture Focus Question from the “Business
Unit/Security Architect” Row Perspective
Owner Focus Question
“For each Organization Unit:
• which business entities can it touch?
• which business processes can it perform?
• which business locations can it work from or with?
• what other organization units can it interact with?
• what business cycles/events can it initiate or accept?
• what business objectives can it support?”

22. A Zachman “Planner” Perspective of an
Enterprise Security Architecture
• In row 1 of ZF, also known as the “Scope” or “contextual” level, the “Enterprise” is the “role”
• In IT, “planner” row 1 corresponds to an “Chief Security Officer/Architect” level, i.e., someone
doing the “enterprise level” security architecture or design
• The next slide will show how each aspect (data, function, network, people, time, motivation) of
row 1 provides information on security from an “Example”, “Perspective”, “Focus Question” and
“Implementation” point of view.
• A “Focus Question” is a question that helps us determine the appropriate contents for a ZF cell,
row or column
• The slide after next shows the Focus Question inherent in row 1, from a “Scope of Enterprise”
perspective

23. Security Architecture from the “Chief Security
Officer/ Architect” Row Perspective
Example
Description
Focus Question
Implementation
List of Things
Important to
the Business
List of
Processes the
Business
Performs
List of Locations
in which the
Business
Operates
List of
Organizations
Important to
the Business
List of Events
& Cycles
Significant to
the Business
List of
Business Goals
& Strategies
Class of
Businesses &
Business
Products
allowed by law
Class of
Business
Processes
authorized by
law
Major Business
Locations the
Enterprise is
allowed to work
from
Major
Organizational
Units allowed to
interact with one
another by law
Enterprise
Business
Cycles/Busines
s Events that
impact security
Enterprise
Business Goals
and Strategies
that impact
security
What types of
business
products can
the Enterprise
handle?
What classes
of business
processes can
the Enterprise
perform?
What major
business locations
can the Enterprise
operate from?
What other
organizations can
the Enterprise
interact with?
What business
cycles/events can
the Enterprise
initiate or accept?
Which major
business goals &
strategies can the
Enterprise
support?
List of Things
Important to
the Business
List of
Processes the
Business
Performs
List of Locations
in which the
Business
Operates
List of
Organizations
Important to
the Business
List of Events
& Cycles
Significant to
the Business
List of
Business Goals
& Strategies

24. Planner Focus Question
“For the Enterprise:
• which types of business products can it handle?
• which classes of business processes can it perform?
• what major business locations can it operate from?
• what other major organization units & enterprises can it interact with?
• what major business cycles/events can it initiate or accept?
• what major business goals/strategies can it support?”
Security Architecture Focus Question from the “Chief
Security Officer/ Architect” Row Perspective

25. A Zachman “Application Programmer”
Perspective of Enterprise Security Architecture
• In row 4 of ZF, also known as the “Technology Model” or “physical”
level, the “User” plays the “role”
• In IT, “builder” row 4 corresponds to an “Application Programmer”
level, i.e., someone doing “application level” security coding
• The next slide will show how each aspect (data, function, network,
people, time, motivation) of row 4 provides information on security
from an “Example”, “Perspective”, “Focus Question” and
“Implementation” point of view.
• A “Focus Question” is a question that helps us determine the
appropriate contents for a ZF cell, row or column
• The slide after next shows the Focus Question inherent in row 4, from
a “User & Role” perspective

26. Security Architecture from the “Application
Programmer” Row Perspective
Example
Description
Focus Question
Implementation
Physical Data
Model
System Design Technology
Architecture
Presentation
Architecture
Control
Structure
Rule Design
Role-based
Data Access
Model
Role-based
Authentication
and
Authorization
APIs
Distributed
Security
Architecture
Role-based
Security
Architecture
Component
Cycles &
Executes per
Role
Role-based
Business Rule
with conditions
& actions
Which data
segs/tables/key
s can the user
access?
Which methods
& functions
can the user
execute?
Which
Hrdw/Sftw can
the user have
access to?
What other
users/roles can
the user
interact with?
Which
executes can
the user initiate
or accept?
What conds &
actions biz
rules
guide/constrain
each user?
List of
segments,
tables and keys
a given user &
role can access
List of methods
and functions a
given user &
role can access
List of Hrdw &
Sftw a given
user & role can
have access to
List of other
users/roles a
given user &
role can have
access to
List of
executes a
given user &
role can initiate
or accept
List of
conditions &
actions biz rules
guiding/constrai
ning a user/role

27. Builder Focus Question
“For each User playing a given role:
• which data segments/tables/keys can that user access?
• what methods and functions can the user execute?
• what hardware/system software can the user have access to?
• what other users playing what roles can the user interact with, using what
screen formats?
• which executes in what component cycles can the user initiate or accept?
• what conditions/actions in what business rules guide or constrain the user?”
Security Architecture Focus Question from the
“Application Programmer” Row Perspective

28. A Zachman “Security Programmer/DBA”
Perspective of Enterprise Security Architecture
• In row 5 of ZF, also known as the “Detailed Presentations” or “out-of-context”
level, the “Identity” plays the “role”
• In IT, “subcontractor” row 5 corresponds to an “Security Programmer/DBA”
level, i.e., someone doing “security module/subsystem level” coding
• The next slide will show how each aspect (data, function, network, people,
time, motivation) of row 5 provides information on security from an
“Example”, “Perspective”, “Focus Question” and “Implementation” point of
view.
• A “Focus Question” is a question that helps us determine the appropriate
contents for a ZF cell, row or column
• The slide after next shows the Focus Question inherent in row 5, from an
“Identity & Role ” perspective

29. Security Architecture from the “Security Programmer/
Security DBA” Row Perspective
Example
Description
Focus Question
Implementation
Data Definition Program Network
Security
Architecture
Security
Architecture
Timing
Definition
Rule
Specification
Role-based
Data Field
Access Model
Role-based
Authentication and
Authorization
APIs
Distributed
Security
Architecture
Role-based
Security
Architecture
Machine
Cycles &
Interrupts per
Role
Role-based Business
Rule Specification w/
sub-conditions &
steps
Which fields &
addresses can
the identity with
a given user/
role access?
What program
language statements
& I/O control blocks
can the identity with a
given user/role
execute?
What network
addresses/ protocols
can the identity with
a given user/role
have access to/use?
What other
identities played by
given users/roles
that the identity with
the given user/role
can interact with?
What interrupts in
what machine
cycles can the
identity with the
given user/role
initiate?
what sub-conditions
& steps in what
business rules
specifications
guide or constrain
the identity?
List of fields &
addresses the
identity with a
given user &
role can access
List of program
language statements
& I/O control
blocks the identity
with a given user &
role can access
List of network
addresses &
protocols the identity
with a given
user/role can have
access to or use
List of other
identities played by
given users/roles
that the identity with
the given user/role
can interact with
List of interrupts
& machine cycles
the identity with
the given
user/role can
initiate
List of sub-conditions
& steps in business
rules specifications
that guide or constrain
the identity with a
given user/ role

30. Subcontractor Focus Question
“For each Identity played by a given user in a given role:
• which data fields & addresses can it access?
• what program language statements & I/O control blocks can it execute?
• what network addresses can it have access to and what network protocols can it use?
• what other identities played by given users with given roles can it interact with?
• what interrupts in what machine cycles can it initiate?
• what sub-conditions/steps in what business rules specifications guide or constrain the identity?”
Security Architecture Focus Question from the “Security
Programmer/Security DBA” Row Perspective

31. A Zachman “Functioning Enterprise” Perspective of
an Enterprise Security Architecture
• Row 6 of ZF, also known as the “Functioning Enterprise” level, represents
reality, i.e., the actual “running” enterprise. Thus, the “Actual Enterprise” is
the “role”
• In IT, row 1 corresponds to someone at the “CIO/CSO” level, i.e., someone in
charge of the “enterprise level” security monitoring and decision-making
• The next slide will show how each aspect (data, function, network, people,
time, motivation) of row 1 provides information on security from an
“Example”, “Perspective”, “Focus Question” and “Implementation” point of
view.
• A “Focus Question” is a question that helps us determine the appropriate
contents for a ZF cell, row or column
• The slide after next shows the Focus Question inherent in row 6, from a
“Functioning Enterprise” perspective

32. Security Architecture from the “Chief Information
Officer/ Chief Security Officer” Row Perspective
Example
Description
Focus Question
Implementation
DATA FUNCTION NETWORK ORGANIZA-
TION
SCHEDULE STRATEGY
Class of
Actual
Businesses &
Business
Products
Class of Actual
Business
Processes
Actual Major
Business
Locations the
Enterprise
works from
Actual
interacting
Organizations
Actual
Enterprise
Business
Schedules
Actual
Enterprise
Business
Strategies
What types of
business
products does
the Enterprise
handle?
What classes of
business
processes does
the Enterprise
perform?
What major
business
locations does
the Enterprise
operate from?
What other
organizations
does the
Enterprise
interact with?
What business
schedules does
the Enterprise
initiate or
accept?
Which business
strategies does
the Enterprise
support?
List of Things
Actually
Important to
the Business
List of Actual
Processes the
Business
Performs
List of Actual
Locations in
which the
Business
Operates
List of Actual
Organizations
Important to
the Business
List of
Schedules
Actually
Significant to
the Business
List of
Strategies
Actually
Important to
the Business

33. Functioning Enterprise Focus Question
“For the Functioning Enterprise:
• which types of business products does it actually handle?
• which classes of business processes does it actually it perform?
• what major business locations does it actually operate from?
• what other major organization units & enterprises does it actually
interact with?
• what major business cycles/events does it actually initiate or accept?
• what major business goals/strategies does it actually support?”
Security Architecture Focus Question from the “Chief
Information Officer/ Chief Security Officer” Row Perspective

34. Where does all this lead us?
By compiling all the focus questions for each cell of each row,
we generate the Focus Question Matrix for Enterprise Security
shown in the next page. This matrix becomes the Enterprise
Architect’s main tool for information gathering and organizing
of Enterprise Security data … his/her main instrument to share
such information with other organizations at all levels of the
enterprise …

35. Enterprise Security Architecture –
Focus Question Matrix
What types of
business products
can the Enterprise
handle?
What classes of
business processes
can the Enterprise
perform?
What major
business locations
can the Enterprise
operate from?
What other
organizations can
the Enterprise
interact with?
What business
cycles/events can
the Enterprise
initiate or accept?
Which major
business goals &
strategies can the
Enterprise support?
What business
entities can each
Organization Unit
access?
Which business
processes can each
Organization Unit
perform?
Which business
locations can each
Org Unit work
from?
What other
organization units
can each Org Unit
interact with?
Which business
events can each
Organization Unit
initiate or accept?
Which business
objectives can the
Organization Unit
support?
Which data entities
can each role
access?
Which methods can
each role execute?
Which IT resources
can each role have
access to?
What other roles
can each role
interact with?
Which system
events can each
role initiate or
accept?
Which business
rules guide or
constrain each role?
Which data
segs/tables/keys
can the user access?
Which methods &
functions can the
user execute?
Which Hrdw/Sftw
can the user have
access to?
What other
users/roles can the
user interact with?
Which executes can
the user initiate or
accept?
What conds &
actions biz rules
guide/constrain
each user?
Which fields &
addresses can the
identity with a
given user/ role
access?
What program
language
statements & I/O
control blocks can
the identity with a
given user/role
execute?
What network
addresses/
protocols can the
identity with a
given user/role
have access to/use?
What other
identities played by
given users/ roles
that the identity
with the given user/
role can interact
with?
What interrupts in
what machine
cycles can the
identity with the
given user/role
initiate?
what sub-
conditions & steps
in what business
rules specifications
guide or constrain
the identity?
What types of
business products
does the Enterprise
handle?
What classes of
business processes
does the Enterprise
perform?
What major
business locations
does the Enterprise
operate from?
What other
organizations does
the Enterprise
interact with?
What business
schedules does the
Enterprise initiate
or accept?
Which business
strategies does the
Enterprise support?
Chief Security
Officer/Architect
Business Unit/
Security Architect
Application Security
Architect/Designer
Application
Programmer
Security Programmer
/Security DBA
CEO/COO/CIO

36. Benefits
• ZF can serve all enterprise constituencies, not just IT.
• ZF models all aspects of the business, not just IT.
• ZF does not change the way people go about their business, just the way they
collect and organize their designs, policies, strategies, documentation, etc.
• ZF provides a business perspective of enterprise architecture.
• ZF can model from small subcomponents to worldwide enterprises.
• ZF facilitates the capture, classification and organization of existing or new
architecture artifacts by using focus questions that guide the architect to
collect the data from multiple perspectives and aspects.
• ZF can be used to capture and organize the full spectrum of security at all
levels of the enterprise.

37. Benefits (Continued)
• ZF does not require that you answer every single focus question to fill every
single cell: just fill only those cells that make sense to fill given the scope and
requirements of the project. You may leave all other cells blank if they fall
outside your focus area.
• ZF can be used for any topic or issue, and not just for security, such as
business rules, data management, SOA, business monitoring, integration,
compliance, etc.
• Two closely related areas, such as security and risk management, will produce
different focus questions.
• A cell may contain links to any content relevant to answering its focus
question: text, pics, diagrams, etc.
• Both business and IT management will also be able to look at and make use of
enterprise architecture by using the ‘Owner’, ‘Planner’, and ‘Functioning
Enterprise’ perspectives.

38. Conclusions
• For ZF to be effective at the Enterprise level, it needs to be socialized
gradually, leading gently by example. Enterprise Security Architecture can be
an excellent first example.
• For ZF to be effective at the Enterprise level, we need to expose it by creating
a place for it on the architecture groups’ website, and directing people to it
for information on architecture delivered from ‘their’ point of view.
• ZF helps to bring hidden potential problems, due to subtle implicit
assumptions, to the fore. For example, the ZF example presented here makes
explicit the assumption that the security architecture is role-based. What if
one or more of the systems to be integrated under a Single Sign On initiative
are not role-based but user- or identity-based? How can we integrate such a
mixture? ZF makes such potential security mismatches apparent from the
start.

39. Contact Info
Please Contact
Joaquin Marques
Founder & CEO
Kanayma LLC
3523 Greenway Drive
Jupiter FL 33458
(561) 339-7897
joaquin@kanayma.net
Skype id: jmmg57
Website: https://kanayma.net