Enterprise Security Architecture - PowerPoint PPT Presentation

1 / 79
About This Presentation
Title:

Enterprise Security Architecture

Description:

Analysis step 1: assume user-centric perspective ... push opens up all sorts of auto-config issues not covered in traditional security architectures ... – PowerPoint PPT presentation

Number of Views:2320
Avg rating:5.0/5.0
Slides: 80
Provided by: MA9658
Category:

less

Transcript and Presenter's Notes

Title: 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 ?
Write a Comment
User Comments (0)
About PowerShow.com