Your SlideShare is downloading. ×
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
IAC Secure eBiz Secu..
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

IAC Secure eBiz Secu..


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Hit these briefly. Already talked about these above. Revise EA Process to include cross-agency and cross-application factoring Adopt a CBA-oriented SDLC Adopt interoperability standards – Technical Reference Model Develop a program to evaluate and acquire COTS/GOTS components Institute a mechanism for development of cross-agency components Adopt CBA infrastructure for development Manage cultural change
  • Basic Pillars of Information Assurance Your customer should be addressing all these facets of IA
  • Let’s discuss security, an important topic which we’re all taking very seriously. We all need Security in our increasingly complex and changing world. Security requires a framework composed of: Process including procedures, guidelines and an ongoing commitment to process improvement. Technology including hardware, software and networks and People including culture and knowledge. Security needs to be comprehensive . Security will fail if we only focus on part of the problem. Technology is neither the whole problem nor the whole solution . Microsoft recognizes the seriousness of security issues. We recognize that we have needed to take, and are now taking a leadership role to address solutions. Microsoft’s extensive and serious security efforts include the following: Microsoft developed the Strategic Technology Protection Program (STPP) as a two-phase program representing an unprecedented mobilization of Microsoft's people and resources to integrate product, services and support. The Strategic Technology Protection Program (STPP) consists of both Near-term and longer term programs that we’ll discuss in depth on the next slide. Process : Microsoft provides Prescriptive Architecture Guides such as the Internet Data Center Reference Architecture Guide, including security and firewall specific chapters which are available now. In addition, the Enterprise Datacenter guide, which includes security and firewall specific chapters, will be available the first half of 2002. This Architecture Guide can be found on or on In addition, the Microsoft Solution for Intranets - Prescriptive Architecture Guide is a valuable resource and can be found on or you can search on the word Prescriptive at The Microsoft Solution for Intranets - Prescriptive Architecture Guide describes how manage and share information in an organization’s intranet. Technology : Under technology, it’s important to factor in baselines, standards, products and security tools for deploying a secure infrastructure. Microsoft-specific efforts include the following: All of our developers are undergoing significant training, and making sure that security is a top priority from the beginning of the design cycle to the end and ship dates. We are increasing the number of tests -- and making them more stringent -- as we test the procedures around security for our products. We are changing some of the processes in which we ship products with different lock-down criteria and a default configuration. In addition, we have the secure Windows Initiative. For that, we have a team of dedicated security professionals within Microsoft looking at every aspect of Windows development with the specific goal of making Microsoft products the most secure available on the market today. People : The third part of creating a secure enterprise is the people component. That includes the staff, training, security mindset as well as external review of security processes. Microsoft provides Guidelines and Microsoft services to assist in this area.
  • Scott Culp of the Microsoft Security Response Center recently published the Ten Immutable Laws of Security (, a listing of ten facts of life regarding computer security. Administrators have their own set of immutable laws, one that's entirely separate from the list for users. So, they canvassed the network administrators, security gurus, and other folks at Microsoft, and developed the list that follows, which encapsulates literally hundreds of years of hard-earned experience. As in the case of the immutable laws for users, the laws on this list reflect the basic nature of security, rather than any product-specific issue. Don't look for a patch from a vendor, because these laws don't result from a technology flaw. Instead, use common sense and thorough planning to turn them to your advantage. Here’s some highlights from the laws: Security can’t be based on voluntary measures. Get executive commitment to security and the authority to mandate security. Balance security with productivity – don’t create a police state. Try to automate as much as possible and ease the impact to end users. When interference with users daily work is necessary, communicate the reasons for it. Stay up to date all the time – new bugs gets found all the time and will be utilized by hackers quickly. No chain is stronger than the weakest link. Think defense in depth and remember physical security. Systems must be secured even before being put on the network. Law 3 and 4 is about prevention, this is about detection. Be alert, monitor critical systems and be ready to respond. Prevention can’t prevent everything, e.g. many DoS attacks are difficult to prevent.
  • Continued with observations for the 10 laws: Password authentication is often the weakest link of all, do an especially good job in this area to have good policies & controls. Think of using alternative authentication mechanisms, like Smartcards. Create a strong security policy and good operational procedures and document them. Make clear responsibilities. Consider setting up an internal “Red Team”. Keep it simple. Sometimes, business imperatives will override security risks. Your network security will be compromised. Plan for this – this is the reaction stage or contingency planning. It takes more than technology to have security. Think about processes and people as well.
  • Transcript

    • 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" [email_address]
        • Technology trends and standards- Paul Patrick- BEA CSA
          • <>
        • Security Development Patterns and Practices- Jon Wall-Microsoft- Federal Security Consultant
          • &quot;Jon Wall&quot; <>
    • 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 &quot;aspect&quot; 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) CUSTOMER/PARTNER NEEDS BUSINESS NEEDS LEGISLATION/REGULATIONS Requirements SA SA Disaster Recovery Data Class/Retention Backup Telecomm Security Information Security Application Security Physical Security
    • 7. Taxonomy of Standard-based Security Strategy Authorization Service Auditing Service Credential Service PKI Service Provisioning Service Security Services Authentication Service XKMS X.509 WS-Trust SAML XACML Username/Password SAML X.509 WS-Security SAML Username/Password Kerberos WS-SecureConversation SPML Liberty Alliance .Net Passport Single Sign-On Digital Certificates SAML/Kerberos Portal Integration Data Mgmt Application Server
    • 8. Aligning Guidance & Managing Compliance Map Common EA Elements and NIST Guidance to Compliance Efforts Focus on the Common Elements Integrate Security Architecture With Common Business Goals & Infrastructure FEAF, NACIO, E-GOV 2002, others FISMA/GISRA, NIAP CC, NIST 800-37 Pervasive Principles Broad Functional Principles Detailed Principles Regulations & Legislation Business Risk Business Requirements Security Architecture
    • 9. 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 Security Patterns Drivers NIST Guidelines Security & Privacy Service Framework Education by Role(s) Information Center & Collaborative Zone 1 2 3 4 5 Data Reference Model
    • 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 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. Perimeter Security Authorization Role Manager- Policy Manager Audit and Analysis Authentication Manager Security- Policy and Enforcement Mgmt 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
    • 13. Recommendation Task Force- Focused on Alignment and Integration Technology & Standards: Leadership and Action Manage “Integrated” Security and Privacy Changes Security and Service Models & Patterns Update EA with Security and Privacy Process from NIST Service Security and Privacy Framework Security and Privacy Training- Analysis Competency Center Interoperability Update and Add to NIST Guidance E-gov Policies and Rules
    • 14. To Put It Simply…
      • Without security, e-business simply cannot prosper
        • Security is an essential requirement f or successful e-business
      • Vision:
        • “ Defense in depth”
        • Focus on application-level security
    • 15. 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
      Custom Application 3rd-party Application Web Application Kerberos, Passwords, SAML, SPML, SSL, TLS, Tokens, WS-Policy, WS- Security, XACML, X.509 SOAP/HTTP F I R E W A L L Web Service ? Mainframe Database Web SSO Server
    • 16. Unified Security Infrastructure Database Mainframe Web SSO Server Portal Authorization Server Security Framework Integration Server Custom Applications Third Party Applications Web Application Web Service F I R E W A L L Customers Partners Suppliers Employees
    • 17.
      • 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
      “Application Security Infrastructure” Security Services Application Business Policy
    • 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. Pillars of IA Core Competencies Disaster Recovery Backup Information Assurance Telecomm Security Physical Security Application Security Data Class/Retention Telecomm Security Information Security
    • 20. Pillars Of Trustworthy Computing Security Privacy Reliability Business Integrity
      • Vendors provide quality products
      • Product support is appropriate
      • Evidence and audits are sought
      • Dependable
      • Available when needed
      • Performs at expected levels
      • Individuals control personal data
      • Products and online services adhere to fair information principles
      • Resilient to attack
      • Protects confidentiality, integrity, availability and data
    • 21. 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
    • 22. 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
        • Mandatory security training for all employees
    • 23. Design Requirements
      • Defense in depth
      • Least privilege
      • Learn from Past Mistakes
      • Security is a Feature
      • Secure Defaults
        • 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
        • S poofing, T ampering, R epudiation, I nfo Disclosure, D enial of Service, Elevation of Privilege
      • Rank threats with DREAD
        • D amage potential, R eproducibility, E xploitability, A ffected Users, D iscoverability
    • 26. Security Analysis Threat Model Security Test & Integration Threat Discovery Agreement Definition Analysis Tools Triage Improvements Fixes Made Fix Posted Create Risk Assessment BL Readiness Deployment
    • 27. 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
    • 28. 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.
    • 29. The 10 Immutable Laws of 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 Laws of 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
    • 32. Contact Information
      • For more information about IAC, go to
      • For more information about the IAC EA SIG, please
      • contact Kay Cederoth at:
      • [email_address]
      • For more information on each of the IAC EA SIG
      • White Papers, go to: