Security Architecture Challenges and Integration with EA

1
Security Architecture Challenges and Integration
with EA

• Security and Privacy Architecture integrated with
  Enterprise Architecture

2
Scope

• EA has integrated Security and Privacy into all
  levels of models
• Challenge getting Security and Privacy at the
  Planning Table
• New Threats- new technologies- trends and
  standards- constantly changing
• Recommendations for Security and Privacy Linked
  to FEA Reference Models- Marianne Carter- CA-
  Federal Security Specialist
• Carter, Marianne" Marianne.Carter_at_ca.com
• Technology trends and standards- Paul Patrick-
  BEA CSA
• ltPaul.Patrick_at_bea.comgt
• Security Development Patterns and Practices- Jon
  Wall-Microsoft- Federal Security Consultant
• "Jon Wall" ltjwall_at_microsoft.comgt

3
Issues

• Government Security and Privacy Direction are not
  consistent with the e-government needs
• E-government Act provides NIST leadership on
  defining the standards
• EA Reference Models do not address Security and
  Privacy
• Business Case and Budgeting needs security and
  privacy considerations
• Integrated and weaved everywhere

4
Challenges

• View from System to Enterprise Perspective
• Alignment of NIST Guidance with e-government
  Transformation needs
• New Threats constantly evolving
• Analyze Threats and determine countermeasures to
  deploy
• Current government process not agile enough to
  adapt and respond to threats and emerging
  technologies
• (Security Architecture must be holistic and
  address key principles such as Defense in
  Depth..)
• Security Architecture woven into the Strategy,
  Enterprise Architecture, Business Case ,and
  Budget Cycle.

5
Step 5 Security and Privacy with EA- Really
Weaved with all other steps

• Integrating Security and Privacy Architecture
  with Enterprise Architecture
• The paper provides initial concepts needed for a
  Security Service Framework along with process
  changes that are needed for updates into the FEAF
  2.0 draft. The integration of Security thinking
  and practices as an "aspect" of all the
  Enterprise Architecture is key. The paper weaves
  the Security Architecture process with the
  Enterprise Architecture.

6
CONSIDERATIONS FOR DEVELOPING A SECURITY
ARCHITECTURE(SA)
SA
SA
Requirements
BUSINESS NEEDS
Information Security
Data Class/Retention
Application Security
Telecomm Security
Physical Security
Disaster Recovery
Backup
LEGISLATION/REGULATIONS
CUSTOMER/PARTNER NEEDS
7
Taxonomy of Standard-based Security Strategy
Single Sign-On
Digital Certificates
Liberty Alliance
.Net Passport
Security Services
AuthorizationService
Auditing Service
CredentialService
PKI Service
ProvisioningService
AuthenticationService
XKMSX.509 WS-Trust
SAMLXACML
Username/PasswordSAML X.509 WS-Security
SAMLUsername/PasswordKerberos WS-SecureConversat
ion
SPML
8
Aligning Guidance Managing Compliance
Integrate Security Architecture With Common
Business Goals Infrastructure
Map Common EA Elements and NIST Guidance to
Compliance Efforts
FISMA/GISRA, NIAP CC, NIST 800-37
FEAF, NACIO, E-GOV 2002, others
Focus on the Common Elements
9
Integrated Security Approach linked to
Enterprise Architecture
Drivers
Government Support Needs
Legal Mandates
Incidents and Evaluations
1
Business Architecture
3
Strategies
Security Privacy Service Framework
Data Reference Model
Principles
Services Layer
Policies
2
NIST Guidelines
Security Patterns
Procedures
Components
4
Security Technology
Technical Layer
5
Research
Industry Standards
Education by Role(s)
Information Center Collaborative Zone
10
Best Practices

• Externalize management of identity and policy
  from the application
• Externalize policy enforcement from business
  logic in application code
• Protection as close to target as possible
• Provides context necessary for business-like
  decisions
• Service-based Security Architecture
• Open, flexible, and extensible

11
E-gov Security Service Framework Features

• Key Principles Framework that is tailored to
  agencies unique security requirements
• Business Line Modeling Approach to Divide the
  Enterprise or Business Line into Zones with
  Governance Structure- Responsibilities
• Tools to support the Modeling and Analysis of
  Security and Privacy and Report creation-
  integrate into Business Analyst Portal
• Services Framework
• Define a set of services and Open Service
  Interfaces for component architecture(preliminary-
  thoughts included)
• E-Authentication Common Services- Need to become
  eSecurity
• Single Sign On through the Portal- must address
  the Firstgov.gov portal and related one-stop
  sign-ins and many of the basics must be covered!
• Access Control by Requestor Application and
  Transaction Services
• Logging of Intra/Inter Enterprise Integration
  messages and Legacy System database updates
• Technical Reference Model Level
• Certified components- Operating Systems- similar
  to the existing NIST/NSA CERT program
• Firewalls that protect the physical environment

12

Elements for Service Security Privacy Framework
to Enterprise Architecture
Define Zones Firewalls
Perimeter Security Authorization
Intrusion Detection
Portal
Business Architecture
Role Manager- Policy Manager
.
Context-1
Context-X
Security- Policy and Enforcement Mgmt
Authentication Manager
Service-Container Security Manager

• Service Component Security Features
• User Access Control
• Enforcement Mechanism

Authorization Manager
Logging
Platform Specific Protections- TRM
Audit and Analysis
13
Recommendation Task Force- Focused on Alignment
and Integration
Technology Standards Leadership and Action
14
To Put It Simply

• Without security, e-business simply cannot
  prosper
• Security is an essential requirement for
  successful e-business
• Vision
• Defense in depth
• Focus on application-level security

15
Critical Architectural Issues for Security

• Legacy Systems with Poor Security Aspects
• Introduction of Web Services

• Complexity of security technology

• Security infrastructure re-use

Kerberos, Passwords, SAML, SPML, SSL, TLS,
Tokens, WS-Policy, WS- Security, XACML, X.509
Application Server
Custom Application
3rd-party Application
Web Application
16
Unified Security Infrastructure
Portal
Custom Applications
Third Party Applications
Integration
Web Application
Web Service
Server
Security
Framework
Database
Web SSOServer
AuthorizationServer
Mainframe
17
Application Security Infrastructure

• Controls What Application Users Are Allowed To Do
• Throughout the Application, Not Just at the Edge
• Across Multiple Related Applications
• Beyond Enterprise Boundaries
• Bridges Business Logic and Security Services
• Business Processes Drive Security Needs
• Delegate Administration to Business Units
• Custom Code/Integration GivingWay to Security
  Infrastructures

Application Business Policy
Security Services
18
Industry Directions

• Defense in Depth
• Use of layers of security not just at perimeter
• Interoperability based on standards
• Seldom a single security vendor in an enterprise
• Focusing on Identity and Access Management
• Recognition of no central identity repository
• Security as a pervasive infrastructure
• Based on a general-purpose, adaptable
  architecture
• Adoption of Application Security
• Security presented in language of business
• Utilize role-based authorization
• Consideration for context of transaction

19
Information Assurance
Pillars of IA Core Competencies
Information Security
Data Class/Retention
Telecomm Security
Telecomm Security
Physical Security
Application Security
Disaster Recovery
Backup
20
Pillars Of Trustworthy Computing

• Resilient to attack
• Protects confidentiality, integrity, availability
  and data

Security
Privacy

• Individuals control personal data
• Products and online services adhere to fair
  information principles

Reliability

• Dependable
• Available when needed
• Performs at expected levels

Business Integrity

• Vendors provide quality products
• Product support is appropriate
• Evidence and audits are sought

21
Its Not Just About Technology

• Security requires a framework composed of
• Process (procedures, guidelines)
• Technology (hardware, software, networks)
• People (culture, knowledge)
• Security needs to be comprehensive
• Technology is neither the whole problem nor the
  whole solution

22
Educate!

• You dont know what you dont know!
• More eyes ! more secure software
• We teach the wrong things in school!
• Security features ! secure features
• Raises awareness
• ACTION ITEMS
• Mandatory security training for all employees

23
Design Requirements

• Defense in depth
• Least privilege
• Learn from Past Mistakes
• Security is a Feature
• Secure Defaults
• ACTION ITEMS
• Follow these design principles

24
Threat Models

• You cannot build secure applications unless you
  understand threats
• We use SSL!
• Find different bugs than code review
• Implementation bugs vs higher-level design issues
• Approx 50 of bugs come from threat models

25
Threat Modeling Process

• Create model of app (DFD, UML etc)
• Build threat tree
• Categorize threats to each tree node with STRIDE
• Spoofing, Tampering, Repudiation, Info
  Disclosure, Denial of Service, Elevation of
  Privilege
• Rank threats with DREAD
• Damage potential, Reproducibility,
  Exploitability, Affected Users, Discoverability

26
Security Analysis
Threat Model
27
Ten Laws

• Law 1If a bad guy can persuade you to run his
  program on your computer, its not your computer
  anymore.
• Law 2If a bad guy can alter the operating
  system on your computer, its not your computer
  anymore.
• Law 3If a bad guy has unrestricted physical
  access to your computer, its not your computer
  anymore.
• Law 4If you allow a bad guy to upload programs
  to your web site, its not your web site any
  more.
• Law 5Weak passwords trump strong

28
Ten Laws

• Law 6A machine is only as secure as the
  administrator is trustworthy.
• Law 7Encrypted data is only as secure as the
  decryption key.
• Law 8An out of date virus scanner is only
  marginally better than no virus scanner at all.
• Law 9Absolute anonymity isn't practical, in
  real life or on the web.
• Law 10Technology is not a panacea.
• http//www.microsoft.com/technet/security/10imlaws
  .asp

29
The 10 Immutable Lawsof Security Administration

• Nobody believes anything bad can happen to them,
  until it does
• Security only works if the secure way also
  happens to be the easy way
• If you don't keep up with security fixes, your
  network won't be yours for long
• It doesn't do much good to install security fixes
  on a computer that was never secured to begin
  with
• Eternal vigilance is the price of security

30
The 10 Immutable Lawsof Security Administration

• There really is someone out there trying to guess
  your passwords
• The most secure network is a well-administered
  one
• The difficulty of defending a network is directly
  proportional to its complexity
• Security isn't about risk avoidance it's about
  risk management
• Technology is not a panacea
• By Scott Culp Security Program Manager at
  Microsoft Security Response Center

31
Additional Resources

• http//msdn.microsoft.com/library/default.asp?url
  /library/en-us/dncode/html/secure02132003.asp
• http//www.microsoft.com/technet/treeview/default.
  asp?url/technet/itsolutions/techsol/showcase/defa
  ult.asp

32
Contact Information

• For more information about IAC, go to
• www.iaconline.org
• For more information about the IAC EA SIG, please
• contact Kay Cederoth at
• Kay.Cederoth_at_CA.com
• For more information on each of the IAC EA SIG
• White Papers, go to
• http//www.ichnet.org/IAC_EA.htm