Languages
Pages
Legal
Security Architecture Challenges and Integration with EA
Security and Privacy Architecture integrated with Enterprise Architecture
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" [email protected]
– Technology trends and standards- Paul Patrick- BEA CSA• <[email protected]>
– Security Development Patterns and Practices- Jon Wall-Microsoft- Federal Security Consultant
• "Jon Wall" <[email protected]>
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…
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.
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.
CONSIDERATIONS FOR
DEVELOPING A SECURITY ARCHITECTURE(SA)
CUSTOMER/PARTNER NEEDS
BUSINESS NEEDS
LEGISLATION/REGULATIONS
Requirements
SASASASA
Dis
aste
r R
ecov
ery
Dat
a C
lass
/Ret
enti
on
Bac
kup
Tel
ecom
m S
ecu
rity
Info
rmat
ion
Sec
uri
ty
App
lica
tion
Sec
uri
ty
Ph
ysic
al S
ecu
rity
Taxonomy of Standard-based Security Strategy
AuthorizationService
AuditingService
CredentialService
PKIService
ProvisioningService
Security ServicesAuthentication
Service
XKMSX.509
WS-Trust
SAMLXACML
Username/PasswordSAMLX.509
WS-Security
SAMLUsername/Password
KerberosWS-SecureConversation
SPML
SAML/Kerberos
Portal Integration Data Mgmt
Application Server
Liberty Alliance .Net Passport
Single Sign-On
Digital Certificates
Aligning Guidance & Managing Compliance
Pervasive Principles
Broad Functional Principles
Detailed Principles
Regulations & Legislation
Business Risk
Business Requirements
Security Architecture
Map Common EA Elements and NIST
Guidance to Compliance Efforts
Map Common EA Elements and NIST
Guidance to Compliance Efforts
Focus on the Common Elements
Focus on the Common Elements
Integrate Security Architecture With
Common Business Goals &
Infrastructure
Integrate Security Architecture With
Common Business Goals &
Infrastructure
FEAF, NACIO, E-GOV 2002, others
FISMA/GISRA,NIAP CC, NIST 800-37
Integrated Security Approach linked to Enterprise Architecture
Government Support Needs
Strategies
Legal Mandates Incidents and Evaluations
Business Architecture
Services Layer
Components
Principles
Policies
Procedures
Security Technology
Research
Technical Layer
Industry Standards
Sec
uri
ty P
att e
rns
Drivers
NIS
T G
uide
lin
esSecurity & Privacy Service
Framework
Education byRole(s)
Information Center&
Collaborative Zone
1
2
3
4
5
Data Reference Model
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
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
Perimeter SecurityAuthorization
Role Manager- Policy Manager
Audit and Analysis
Authentication Manager
Sec
uri
ty-
Po
licy
an
d E
nfo
rcem
ent
Mg
mt
Intrusion Detection
Define Zones & Firewalls
Context-1
Portal
Business Architecture
…. Context-X
Authorization Manager
Logging
Service-Container Security Manager
• Service Component Security Features
•User Access Control
•Enforcement Mechanism
Platform Specific Protections- TRM
Elements for Service Security & Privacy Framework to Enterprise Architecture
Recommendation Task Force- Focused on Alignment and Integration
DiscoveryDiscovery
RequirementsRequirements
AcquisitionAcquisition
StrategyStrategy
ArchitectureArchitecture
IntegrationIntegration
ExecutionExecution
Manage “Integrated”Security and Privacy
Changes
Security and Service Models& Patterns
Technology & Standards:Leadership and Action
Obtain Executive
Buy-In andSupport
Establish Management
Structure and Control
Define anArchitecture
Processand Approach
Develop Baseline Enterprise
ArchitectureDevelopTarget
Enterprise Architecture
Develop theSequencing Plan
Usethe
EnterpriseArchitecture
Maintain the Enterprise Architecture
Section 3.1
Section 3.2
Section 4
Section 5
Section 5
Section 5
Section 6
Section 7
Controland
Oversight
Controland
Oversight
Update EA with Security and Privacy
Process from NIST
XML•Parse•Transform•Route•Manipulate
XML
DB
App
App
ServiceProvider
•SOAP•WSDL
•UDDI•ebXML
App
ServiceProvider
ServiceProvider
ServiceBroker
ServiceRequestor
ServiceRequestor Service
Security and PrivacyFramework
Depart. A
Agency
Depart. C
Agency
Agency
Agency
Security and Privacy Training- Analysis
CompetencyCenter
Interoperability
Update and Add to NIST GuidanceE-gov Policies and Rules
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
Critical Architectural Issues for Security
Application Server
• Legacy Systems with Poor Security Aspects• Introduction of Web Services
• Complexity of security technology
• Security infrastructure re-use
SOAP/HTTP
F I
R E
W A
L L
Custom Application
3rd-party Application
Web Application
Web Service
Kerberos, Passwords, SAML, SPML, SSL, TLS, Tokens, WS-Policy, WS-Security, XACML, X.509
?
Mainframe
Database
Web SSOServer
F I
R E
W A
L L
Unified Security Infrastructure
Database MainframeWeb SSOServer
Portal
AuthorizationServer
Security Framework
Customers
Partners
Suppliers
Employees
Integration
Server
Custom Applications Third Party Applications
Web Application Web Service
• 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 Giving
Way to Security Infrastructures
Security Services
ApplicationBusiness
Policy
“Application Security Infrastructure”
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
Pillars of IA Core Competencies
Dis
aste
r R
ecov
ery
Bac
kup
Information AssuranceInformation Assurance
Tel
ecom
m
Sec
uri
ty
Ph
ysic
al S
ecu
rity
App
licat
ion
Sec
uri
ty
Dat
a C
lass
/Ret
entio
n
Tel
ecom
m
Sec
uri
ty
Info
rmat
ion
Sec
uri
ty
Pillars Of Trustworthy Computing
SecuritySecurity
PrivacyPrivacy
ReliabilityReliability
Business Business IntegrityIntegrity
Vendors provide quality productsVendors provide quality productsProduct support is appropriateProduct support is appropriateEvidence and audits are soughtEvidence and audits are sought
DependableDependableAvailable when neededAvailable when neededPerforms at expected levelsPerforms at expected levels
Individuals control personal dataIndividuals control personal dataProducts and online services adhere to Products and online services adhere to fair information principlesfair information principles
Resilient to attackResilient to attackProtects confidentiality, integrity, Protects confidentiality, integrity, availability and dataavailability and data
It’s 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
Educate!
• You don’t know what you don’t 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
Design Requirements
• Defense in depth• Least privilege• Learn from Past Mistakes• Security is a Feature• Secure Defaults• ACTION ITEMS
– Follow these design principles
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
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
Security Analysis
SecuritySecurityTest &Test &
IntegrationIntegration
ThreatThreatDiscoveryDiscovery
AgreementAgreementDefinitionDefinition
ThreatThreatModelModel
AnalysisAnalysisToolsTools
TriageTriage
ImprovementsImprovementsFixesFixesMadeMade
FixFixPostedPosted
CreateCreateRisk Risk
AssessmentAssessment
BLBL ReadinessReadiness
DeploymentDeployment
Ten Laws
• Law #1:If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore.
• Law #2:If a bad guy can alter the operating system on your computer, it’s not your computer anymore.
• Law #3:If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.
• Law #4:If you allow a bad guy to upload programs to your web site, it’s not your web site any more.
• Law #5:Weak passwords trump strong
Ten Laws
• Law #6:A machine is only as secure as the administrator is trustworthy.
• Law #7:Encrypted data is only as secure as the decryption key.• Law #8:An out of date virus scanner is only marginally better
than no virus scanner at all.• Law #9:Absolute anonymity isn't practical, in real life or on the
web.• Law #10:Technology is not a panacea.• http://www.microsoft.com/technet/security/10imlaws.asp
The 10 Immutable Lawsof Security Administration
1. Nobody believes anything bad can happen to them, until it does2. Security only works if the secure way also happens to be the easy
way3. If you don't keep up with security fixes, your network won't be yours
for long4. It doesn't do much good to install security fixes on a computer that
was never secured to begin with5. Eternal vigilance is the price of security
The 10 Immutable Lawsof Security Administration
6. There really is someone out there trying to guess your passwords
7. The most secure network is a well-administered one
8. The difficulty of defending a network is directly proportional to its complexity
9. Security isn't about risk avoidance; it's about risk management
10. Technology is not a panacea
By Scott Culp – Security Program Manager at Microsoft Security Response Center
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/default.asp
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:
For more information on each of the IAC EA SIG
White Papers, go to:
http://www.ichnet.org/IAC_EA.htm