Enterprise Security Architecture

1
Enterprise Security Architecture

• Rolf von Roessing CISA, CISM

2
Overview (1)

• Security Architecture Managerial Framework
• Corporate (security) governance Rules of
  Engagement
• Linking Management and Infrastructure Two Worlds
  Apart?
• Useful Standards A Starting Point for Designing
  a Security Architecture

3
Overview (2)

• Process and Infrastructure Architecture is
  Dynamic, Not Static
• Step-By-Step Life Cycle for an Enterprise
  Security Architecture
• Phase 1 Threats, Risks, Business Impact
• Phase 2 Business Case, Strategy
• Phase 3 Framework ISO Areas, CobiT Baseline
• Phase 4 Implementation, Project Management
• Phase 5 Closure (?) No More Than A Gateway
• Phase 6 Internal Review, Audit and Compliance

4
Managerial Framework

• Security as a concept requires extensive
  investment
• Cost-benefit analysis is a prerequisite to
  implementing a security architecture
• Basic assumption limited amount of money,
  maximise security impact
• Business management interests differ from those
  of security management

5
Managerial Framework

• Process-driven View Architecture is a management
  process as well as a concept
• Process yields Return on Security Investment
• Management must consider organisational aspects
  of security

6
Corporate (Security) Governance

• Increasing maturity, increased control density
• Corporate Governance mandates appropriate
  security as an abstract concept
• Three-tier model of security-related control
  objectives
• Security must fit in with the broader concept
  of corporate governance

7
Corporate (Security) Governance
ISO 17799
BCI GPG
Y2K
ARPA CERT 1988
ORM
CG
HS
CivD
Critical Infrastructure Protection (CIP)
IT Disaster Recovery
BCM
General IT Security Few Incidents Relative
Stability
CIP
Evolving CERTs
1972
1980
1988
1990
1992
1994
1996
1998
2000
2002
Business
Protection, Continuity
Information Technology
Strategy
8
Corporate (Security Governance)

• Rules of Engagement highly diversified
• National / Regional variations
• Security is influenced by a multitude of
  otherwise unrelated rules and regulations
• Architectural work requires navigation even
  outside the IT / security box

9
Rules of Engagement
ISO 17799
ISO 15208
Industry/ Prof.
ISO TR 13335
SECURITY
ISO 12207
BSI Baseline
ISO TR 15504-2
COBIT etc
Software Lifecycle Processes Assessment of IT
Software Processes
10
Rules of Engagement

• Legal provisions binding, but unspecific
• Some laws on certain aspects of security (e. g.
  signatures) but not comprehensive
• Directives, guidelines etc. set the political
  scene, but no framework for action
• Industry frameworks (e.g. Basel II) security as
  a prerequisite

11
Rules of Engagement
Incident Mgmt
Product Certs
Disaster Recovery
SECURITY
Operational Risk
BCM
Facilities Mgmt
Health Safety
Human Resources
12
Linking Management and Infrastructure

• Infrastructure is just that not a management
  process, not a management evaluation
• Business view is different from infrastructure
  view
• Infrastructure supports business processes
• Links are provided by the security management
  process

13
Linking Management and Infrastructure

• Security management design, implement, maintain
  infrastructure and architecture
• Security architecture ? the house
• Security management ? living in the house
• Security management owns checkpoints / gateways
  for architecture evaluation and development

14
Useful Standards

• ISO 17799 general framework and guideline
• ISO TR 13335 more specific framework for IT
  security
• BSI Baseline Manual toolbox for detailed
  security work
• Austrian Security Handbook
• COBIT audit and control framework, linking to
  other ISACA documents

15
Useful Standards

• CobiT Security Baseline Survival Kits
• Security Architecture Components (SANS)
• ISF Security Standard
• EnSEC
• Other Toolkits, depending on region and industry
  sector
• ISACA SOX Guidelines as a high-level test tool

16
Starting Point

• Use ISO to define security management process
  make it a living architecture
• Use framework templates to define basic
  architecture elements serving
• Confidentiality
• Integrity
• Availability
• Non-repudiation
• Move on to technology level

17
Process and Infrastructure

• Architecture and infrastructure must be flexible
• Security management process continuous
  improvement
• Architecture improves from a defined state to
  another defined state (without losing the level
  of security in the process)

18
Process and Infrastructure

• Systems analysis approach examine all states of
  the overall security system
• Current state apply security criteria
• Transition state monitor levels of security
• Future state assess security improvement
• Dynamic infrastructure is adaptable to quality
  management standards

19
Step-by-Step Life Cycle

• Phase 1 (Analysis) Threats, Risks, Business
  Impact
• Phase 2 (Analysis) Business Case, Strategy
• Phase 3 (Implementation) Framework ISO Areas,
  CobiT Baseline
• Phase 4 (Implementation) Detailed
  Implementation, Project Management
• Phase 5 (Verification) Closure (?) No More
  Than A Gateway
• Phase 6 (Verification) Internal Review, Audit
  and Compliance

20
Threats and Threat Analysis

• Resist the temptation to classify technical
  threats stick to business (see business case
  below)
• Deductive threat identification
• use CERT or other sources for stats on major
  threats
• use internal stats and logs where available
• Inductive threat identification
• where targets of threats, or threat patterns are
  known, extrapolate to understand where the next
  hit will be
• Whats a threat? anything were not prepared
  for, anything we refuse to acknowledge

21
Threats and Threat Analysis

• Consider architectural weaknesses (threats from
  within)
• Consider possible internal threats and attack
  paths both organisational and technical
• Consider external threats on the principles of
  known weaknesses and statistics
• Remember that most serious threats are home-made.

22
Network Vulnerabilities

• External (WAN / MAN) layer
• the usual suspects (at component level, 3rd party
  operator level, DDoS, DNS, etc.
• the other side business pressure, dependency
  patterns, loss of knowledge, SLA deficiencies
• First line internal (LAN, Extranet) layer
• the usual suspects (at perimeter) hacks, DoS,
  scan hit, hijack etc. etc. ? refer to CERTs and
  others for detailed operational info
• the other side increasing admin effort, LAN /
  firewall / perimeter cost spiralling, IDS and
  other requires rework, regulatory requires
  extended logging...

23
Network Vulnerabilities

• Second line internal (LAN, Intranet) layer
• the usual suspects sniff run, social, spam,
  virii / worms / spybots etc. ? general human
  error or breach of confidence
• the other side HR side pressure, forced errors,
  underfunding, architectural weaknesses
• Third line internal (Core, management info,
  critical financials) layer
• the usual suspects inside jobs, former
  employees, support staff
• the other side top mgmt unaware, lack of
  training, inbuilt weaknesses (e.g. mgrs
  notebooks or PDA / phone)

24
Network Vulnerabilities
3rd Party Networks
LAN / WAN Infrastr.
USER
diminishing influence and awareness
increasing risk and reduced control
Physical Surroundings
3rd Party Managed Services
25
Network Vulnerabilities

• Analysis step 1 assume user-centric perspective
• Analysis step 2 review tiers / lines of defence
• Analysis step 3 review user involvement,
  awareness and understanding
• Analysis step 4 reconcile threat scenario with
  user view

26
Web Environments

• Rising importance of Internet-enabled business
  processes
• complex opt-in / opt-out user interaction
• user choice re. connecting device(s)
• pervasive access paradigm (802.11x, 802.16 etc.)
  is replacing monitored access
• Typical business problems arising
• transaction ownership (responsibility for
  different stages
• managed services / outsourced services in the
  chain
• roaming employment patterns

27
Web Environments

• Application Layer
• convergence towards XML and similar standards
• seamless data continuum across traditional
  Office, Comms, Transaction apps
• increased entropy in business data use
• Network Layer
• uplink / downlink diversity
• tunnels and other devices replace controlled
  networks
• weakest link in the chain is often predominant
• Physical Security
• end user side wide range of threats to physical
  security
• provider side probably secure, but no
  transparency

28
Risk Analysis

• Analysis Phase assess likelihood of material
  threats or threat scenarios
• Use stats and other empirical data as appropriate
• Avoid the risk list approach expect the
  unexpected
• User operational risk categories (e. g. Basel II)
  where possible

29
Risk Analysis

• in security risk analysis, some predefined
  weightings may exist
• not all security-related events / threats have
  the same significance depending on prevention
  and existing environments
• Many attacks or security events have clear
  prerequisites, e.g. Microsoft environment

30
Impact Analysis

• Business impact is often neglected what does a
  security threat mean for balance sheet, P/L and
  reputation?
• Impact analysis in business terms is a
  requirement in many regulatory frameworks
• Technology impact is distinct and different from
  business impact
• Impact is a time-dependent concept

31
Impact Analysis

• Use impact analysis concepts from standard BCM
  frameworks PAS 56, ISO 17799, NFPA 1600, GPG and
  others
• calculate types of potential damage over time, or
  use best estimate
• ensure direct liaison with business process
  owners who have bottom line responsibility

32
Impact Analysis
BUSINESS LAYER BALANCE SHEET AND P/L IMPACT
CORE
Applications, ERP, databases, Interbank etc.
internal systems
Dependencies
LAN / WAN, Components, Cabling / WLAN etc.
Networks and internal infrastructure
external interfaces and service providers,
usually customer-facing
33
Impact Analysis
34
Impact Analysis
35
Impact Analysis
36
Step-by-Step Life Cycle

• Phase 1 (Analysis) Threats, Risks, Business
  Impact
• Phase 2 (Analysis) Business Case, Strategy
• Phase 3 (Implementation) Framework ISO Areas,
  CobiT Baseline
• Phase 4 (Implementation) Detailed
  Implementation, Project Management
• Phase 5 (Verification) Closure (?) No More
  Than A Gateway
• Phase 6 (Verification) Internal Review, Audit
  and Compliance

37
Business Case

• Potential damage (and associated cost) vs.
  required security investment
• Non-technical assessment of available options
  focus on the money side
• The business case is not about the best available
  technology its more pragmatic
• Assume that the 80 solution will be selected

38
Business Case

• Talking business means managerial discretion all
  solutions are politically loaded
• Given that there is no perfect security, aim for
  the maximum of security at reasonable cost
• Assume that strategy (see below) is a living
  thing
• Assume continuous improvement / maturity cycle
  for security management

39
Business Case
D
EUR
P1
Going Concern Line
P0
C0
C
t
t0
where P1 P1 (t) and C GC P1 therefore shows
the point of no return where business cannot
continue
40
Business Case
high
Potential Damage
Security Investment
Security investment is subject to a cost-benefit
view how much should be invested in IT security
to obtain a) adequate protection, and b) keep
cost at a reasonable level?
Cost / Performance
low
Risk
high
Investment higher than potential damage
potential damage will occur with a high
probability
?
?
TARGET
?
41
Strategy

• As a result of the business case and the
  reasoning behind it, formulate strategy as
  follows
• go for major weaknesses and aim at the 80 level
  of IT security
• design a scalable architecture that addresses
  threats from simple to advanced
• cover as much business impact as possible in the
  first round
• leave enough room for continuous improvement, do
  not commit to technology dead ends

42
Strategy

• This is a broadband approach, perhaps neglecting
  the detail. However, the maximum cover at minimum
  cost is what business wants
• Architecture sets the scene, but should be no
  more than an enabler for detailed solutions
• The objective is to win the war, not individual
  battles against specific enemies
• Business will tell you that your resources are
  limited. Using them wisely is the strategists
  secret.

43
Step-by-Step Life Cycle

• Phase 1 (Analysis) Threats, Risks, Business
  Impact
• Phase 2 (Analysis) Business Case, Strategy
• Phase 3 (Implementation) Framework ISO Areas,
  CobiT Baseline
• Phase 4 (Implementation) Detailed
  Implementation, Project Management
• Phase 5 (Verification) Closure (?) No More
  Than A Gateway
• Phase 6 (Verification) Internal Review, Audit
  and Compliance

44
Policies and Procedures

• Security Policy monolithic document defining the
  framework
• Include business objectives, organisational
  objectives, tone from the top
• Make people feel theyre doing the right thing
  when living IT security in day-to-day business

45
Policies and Procedures

• The security policy may look trivial to IT
  security experts...
• ... but not to users how many times have you
  had to explain security basics to unsuspecting
  users?
• The security policy is designed to evoke
  security-conscious behaviour, more than anything
  else

46
Policies and Procedures

• Procedures always refer to the security policy.
• Procedures detail tasks, responsibilities and
  individual solutions
• Recommend template-based approach for
  security-related procedures
• Balance control density with control objectives
  dont over-regulate.

47
Policies and Procedures
48
Policies and Procedures
49
Procedural Level

• Critical business activities / IT services
• QoS indicators and agreed quality
• Use layered model to identify security-related
  interfaces
• Apply defence-in-depth, but dont over-engineer
  the procedures

50
CobiT Security Baseline

• use as baseline document for security controls
• use mappings against ISO 17799 where appropriate
• use mappings against other local security
  standards for detailed requirements

51
Step-by-Step Life Cycle

• Phase 1 (Analysis) Threats, Risks, Business
  Impact
• Phase 2 (Analysis) Business Case, Strategy
• Phase 3 (Implementation) Framework ISO Areas,
  CobiT Baseline
• Phase 4 (Implementation) Detailed
  Implementation, Project Management
• Phase 5 (Verification) Closure (?) No More
  Than A Gateway
• Phase 6 (Verification) Internal Review, Audit
  and Compliance

52
Security Toolbox

• Firewalls and Related Technology
• Virtual Private Networking (VPN)
• Intrusion Detection
• Signatures, Encryption, File Integrity
• Mobile Security

53
Security Toolbox

• Firewalls and Related Technology
• Virtual Private Networking (VPN)
• Intrusion Detection
• Signatures, Encryption, File Integrity
• Mobile Security

54
Firewalls etc.

• FW have become much more intelligent, but
  certainly more complex to administer
• Seamless array of fw / DMZ still difficult to
  handle
• Critical issues are (still) in configuration
  management and administrative effort
• Essential as first line despite occasional
  capacity problems

55
Firewalls etc.

• Main risk is the de-zoning of mobile units no
  longer under the FW regime
• Home users, unauthorised users and other
  organisational problems cannot be covered by FW /
  DMZ
• Long history and relative success breed careless
  behaviour in the presence of FW / DMZ arrangements

56
Security Toolbox

• Firewalls and Related Technology
• Virtual Private Networking (VPN)
• Intrusion Detection
• Signatures, Encryption, File Integrity
• Mobile Security

57
VPN

• Tunnels and virtual networks have matured to a
  level of very high security, but this works both
  ways
• Combined VPN / signature / token solutions most
  convenient and widespread
• Escrow / retrieval problem still unsolved for
  encrypted VPN comms
• Available from most major distributors

58
VPN

• Providing access through VPN tunnels raises the
  question of end point (user) security
• Control issues around mobile device security (see
  below) when granting tunnel access
• Restrictive handling required, preferably with a
  (more expensive) token solution

59
Security Toolbox

• Firewalls and Related Technology
• Virtual Private Networking (VPN)
• Intrusion Detection
• Signatures, Encryption, File Integrity
• Mobile Security

60
Intrusion Detection

• Host-based or network-based packaged solutions
  have reached a high level of maturity
• Deploy HDS / NDS in accordance with data
  classification (ISO or other)
• Performance trade-off still difficult for larger
  environments
• Does the environment / data QoS actually require
  intrusion detection?

61
Intrusion Detection

• Regulatory background (logging, monitoring etc.)
  often requires HDS / NDS to be deployed on a
  large scale
• Beware of honeypots and other bait illegal in
  many European countries
• What is intrusive? Ensure clear and unambiguous
  guidelines for logging and escalation

62
Security Toolbox

• Firewalls and Related Technology
• Virtual Private Networking (VPN)
• Intrusion Detection
• Signatures, Encryption, File Integrity
• Mobile Security

63
Integrity Tools

• Signatures now central to many second line of
  defence strategies
• Legal background firmly established
• Authenticity problem is taking on a new
  significance (high-powered transactions, spam,
  Outlook address snatching etc.)
• PKI-based signatures (preferably qualified in
  the legal sense) desirable, but organisationally
  difficult

64
Integrity Tools

• Encryption and signatures two sides of the same
  equation
• Encrypted data traffic now standard, but requires
  complementary signatures (cover both
  confidentiality and integrity)
• Mature discipline most products provide
  state-of-the-art algorithms and convenience
• In order to authenticate the transaction, all
  integrity components have to be present

65
Integrity Tools

• Other integrity tools (watermark, Digital Rights
  Management etc.) highly controversial
• Consider the moral dimension of using integrity
  checks what purpose does it serve?
• Traditional approaches, particularly (water-)
  marking, still face known technical problems in
  terms of resilience
• Pervasive / ubiquitous computing still offers
  enough loopholes to circumvent DRM / copy protect
• As a rule, attacker has unlimited time to crack
  integrity protection mechanisms

66
Integrity Tools

• While data integrity is one of the central third
  line of defence tools, suggested solutions have
  an interest
• DRM and IPR protection appear to be dominant
  objectives, as opposed to value-free integrity
  protection
• Current toolsets support withholding /
  restricting rather than non-repudiation and
  authenticity
• The elegance of classic PKI / asymmetric
  cryptography and signatures has not been reached
  again
• Quick fix mentality in technical solutions to
  integrity problems

67
Security Toolbox

• Firewalls and Related Technology
• Virtual Private Networking (VPN)
• Intrusion Detection
• Signatures, Encryption, File Integrity
• Mobile Security

68
Mobile Security

• Major challenge to the defence-in-depth paradigm
  (no depth, but width)
• Exponential growth in classes of mobile devices
  and device functionality
• Likely to become the single most important
  security problem of the 2000s / 2010s
• Transition from portable to wearable
• Much more accessible to wider circles of users
  with limited security awareness

69
Mobile Security

• Desktop PC in a physically controlled, logically
  secured environment ? transitioned to notebook PC
  with limited logical control (loopholes) and no
  physical control
• Notebook PC transitioned to PDA ? very weak
  logical control, no physical control
• PDA transitioned to mobile phone ? very weak
  logical control, security problems at operating
  system level, user security problems
• Mobile phone transitioning to push devices
  (Blackberries) ? strong logical control, no
  physical control

70
Mobile Security

• Ease of use mantra blinds users to security
  issues
• Blackberries etc. have pushed ubiquitous
  computing towards the managerial classes, with
  predictable security consequences
• New generation of mobile phones has pushed
  affordable mobile power towards unsuspecting
  users, with equally predictable security
  consequences
• Provider push opens up all sorts of auto-config
  issues not covered in traditional security
  architectures

71
Step-by-Step Life Cycle

• Phase 1 (Analysis) Threats, Risks, Business
  Impact
• Phase 2 (Analysis) Business Case, Strategy
• Phase 3 (Implementation) Framework ISO Areas,
  CobiT Baseline
• Phase 4 (Implementation) Detailed
  Implementation, Project Management
• Phase 5 (Verification) Closure (?) No More
  Than A Gateway
• Phase 6 (Verification) Internal Review, Audit
  and Compliance

72
Closure

• Enterprise Security Architecture set of
  building blocks to be deployed with a defined
  purpose and a business case
• Implementation should be followed by closure (as
  mandated by most project management
  methodologies)
• In a maturity model, closure is the end of an
  individual cycle. Architecture must remain
  flexible
• No more than a quality gateway determine
  whether current state is sufficiently well
  developed to reach next maturity level

73
Closure

• Apply state machine model prior state seen as
  secure, check new state after implementation
• New state / new maturity level should be more
  secure than previous level
• Do not permit temporary weaknesses in
  environments under construction
• Architecture provides spinal chord for ongoing
  improvement

74
Step-by-Step Life Cycle

• Phase 1 (Analysis) Threats, Risks, Business
  Impact
• Phase 2 (Analysis) Business Case, Strategy
• Phase 3 (Implementation) Framework ISO Areas,
  CobiT Baseline
• Phase 4 (Implementation) Detailed
  Implementation, Project Management
• Phase 5 (Verification) Closure (?) No More
  Than A Gateway
• Phase 6 (Verification) Internal Review, Audit
  and Compliance

75
Security Audit

• Three-tiered approach preferred
• control self-assessment
• independent internal audit
• independent external audit
• Have independent auditors define the criteria for
  security architecture
• No wishful thinking!

76
Security Audit

• Follow ISO 17799 Chapter 12 independent means
  just that
• Audit should consider technology case and
  business case. The concept of reasonable
  security is to be applied.
• Establish relevance of individual findings and
  recommendations.

77
Security Audit

• Audit the life cycle, not only current state
• Review improvement / maturity path over time
• With growing maturity, more reliance may be
  placed on control self-assessment
• Regulatory environment requires more
  comprehensive external audit
• Allow yourself the luxury of frequent and
  in-depth external confirmation of what you think
  it just looks better.

78
Summary

• Security Architecture Managerial Framework ?
• Corporate (security) governance Rules of
  Engagement ?
• Linking Management and Infrastructure Two Worlds
  Apart? ?
• Useful Standards A Starting Point for Designing
  a Security Architecture ?

79
Summary

• Process and Infrastructure Architecture is
  Dynamic, Not Static ?
• Step-By-Step Life Cycle for an Enterprise
  Security Architecture
• Phase 1 Threats, Risks, Business Impact ?
• Phase 2 Business Case, Strategy ?
• Phase 3 Framework ISO Areas, CobiT Baseline ?
• Phase 4 Implementation, Project Management ?
• Phase 5 Closure (?) No More Than A Gateway ?
• Phase 6 Internal Review, Audit and Compliance ?