iac secure ebiz secu
DESCRIPTION
TRANSCRIPT
Security Architecture Challenges and Integration with EA
Security and Privacy Architecture integrated with Enterprise Architecture
• 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– Technology trends and standards- Paul Patrick- BEA
CSA– Recommendations for Security and Privacy Linked
to FEA Reference Models- Mariane Carter- CA- Federal Security Specialist
– Security Development Patterns and Practices- John Wall-Microsoft- Federal Security Consultant
Challenges
• View from System to Enterprise Perspective• Alignment of NIST Guidance with e-government
Transformation needs• New Threats- Immediate Needs but “slowly”
moving Changing Technologies with Open Standards that have to vetted- Keeping your options open
• New ideas like Business Line Architecture or Federated Data Management will need security approach.
Critical Architectural Issues for Security
Application Server
• 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
To Put It Simply…
• Without security, e-business simply cannot prosper– Security is an essential
requirement for successful e-business
• Vision: A secure world without firewalls– “Defense in depth”
– Focus on application-level security
• 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”
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
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
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
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
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.
Challenges
• 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…
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
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
E-gov Security Service Framework Features
• Key Principles: Framework that is tailorable to agencies’ unique security requirements• Business Line Modeling: Approach to Divide the Enterprise or Business Line into “Zones” with
Governance Structure- Responsibilites• Tools to support the Modeling and Analysis of Security and Privacy and Report creation- integrate
into Business Analyst Portal e.g. SAEM based Data Base tool• Services Framework:
– Define a set of services and Open Service Interfaces for component architecture(preliminary- thoughts included)
– E-Authentication Common Services – Single Sign On through the Portal- must address the Firstgov.gov portal and related “one-
stop” sign-ins– 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
Summary Elements for Service Security & Privacy Framework to Enterprise Architecture
Perimeter SecurityAuthorization
Role 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
Logger
Service-Container Security Manager
•User Access Control
•Enforcement Mechanism
•Code-Resource Access Control
Platform Specific Protections
NIST Action
• E-government 2002….OMB-NIST actions????• Need to get information from Bob Haycock about
what they have done.
Secure Software Development Concepts
Jon R. Wall
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