Security for Web 2.0 and Externally Hosted Technologies Simon Szykman Chief Information Officer - PowerPoint PPT Presentation

slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Security for Web 2.0 and Externally Hosted Technologies Simon Szykman Chief Information Officer PowerPoint Presentation
Download Presentation
Security for Web 2.0 and Externally Hosted Technologies Simon Szykman Chief Information Officer

play fullscreen
1 / 20
Security for Web 2.0 and Externally Hosted Technologies Simon Szykman Chief Information Officer
121 Views
Download Presentation
whitney-grant
Download Presentation

Security for Web 2.0 and Externally Hosted Technologies Simon Szykman Chief Information Officer

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Security for Web 2.0 and Externally Hosted Technologies Simon Szykman Chief Information Officer National Institute of Standards and Technology

  2. External Hosting & Web 2.0 • What is External Hosting • Any external information system operated on behalf of an agency, including web applications • What is Web 2.0? • “...a broad collection of recent trends in Internet technologies and business models.  Particular focus has been given to user-created content, lightweight technology, service-based access and shared revenue models. “ (Gartner, 2006) • Web 2.0 is not any one single thing, frequently involves external hosting.

  3. Government Use of Web 2.0 (examples) • Dissemination of information to the public using third party sites. • Collaboration, both public and private, using third party sites and applications. • Using a service from a third party hosted application: • Payment processing • Emergency notification systems • Scientific applications • HR applications

  4. Web 2.0 Security Risks Open, collaborative web applications can be more difficult to protect. New technologies are increasingly available and easy to use – users may not understand who they’re actually sharing information with. Focus is on functionality and speed of use - not on weighing the risks. Agency websites or those provided on behalf of your agency could be defaced or compromised through new technical vulnerabilities. 

  5. Potential Impacts Sites could be used to target users through browser vulnerabilities or social engineering. Compromised site could be used as a launching point for attacks against other sites/systems.  Sensitive information could be lost. Compromised site could be used to disseminate false or altered information. Reputation could be harmed eroding public and Congressional confidence. 

  6. Web 2.0 Security in the News January 27th - My.BarackObama.com Infects Visitors With Trojan February 12 - Digg.com Hit By Comments Spam That Leads To Malware February 21 - Travel-Booking Site for Federal Agencies Hacked February 27th - Facebook Users Are Still Abused By Rogue Applications March 2nd - New Worm Spreads Across Facebook, MySpace, Hi5 And Other Social Networks March 9th - Spam from 750 Compromised Twitter Accounts Invites Users To Visit Porn Website March 11th - Google Docs Users May Have Had Their Documents Shared With Strangers

  7. Federal Information Security Management Act (FISMA) • All Federal Government IT, IT services, and IT services being operated on behalf of the Federal Government must be tested and authorized. The head of each agency shall provide “information security protections commensurate with the risk and magnitude of the harm resulting from unauthorized access, use, disclosure, disruption, modification, or destruction of • information systems used or operated by an agency or • by a contractor of an agency or • other organization on behalf of an agency”

  8. Protection • Web 2.0 and externally hosted services are an extension of the Federal organization • Need to apply Risk Management Framework to these technologies. • If an incident happens, no amount of third-party (ir)responsibility will avert agency accountability.

  9. Security Standards & Policies • Regulations require implementing and validating controls specified in federal security standards. • Includes Information, IT, Physical and Personnel security requirements. • What must be implemented and how it is implemented depends on impact to the mission. • Low impact systems: 101 controls • No-impact systems don’t exist. • Policies are based on standards as well as current threats and risks.

  10. Scoping / Testing (OMB) Circular A-130, Appendix III: "adequate security" means security commensurate with the risk and magnitude of the harm resulting from the loss, misuse, or unauthorized access to or modification of information.

  11. Scoping / Testing Point of testing is to document everything so that the Authorizing Officials can make an informed decision on risk. With third party IT services, probably will not be able to test everything. Probably will have failures that can not be fixed. Scope controls, look at mitigations. Must get to the point of “adequate security” where there is a balance. Authorizing Officials must feel that the risks are balanced by the mitigations.

  12. Testing • Testing divided into two areas: • Testing of what the third party controls • Testing of what the Federal agency controls • Analyze all controls to determine scope. • Depth of testing will be based on impact.

  13. Third-Party Testing • Could include: • Previous security audits (internal or external) • Interviews - in person, phone • Risk of relying on interview, not test • C&A (or equivalent) documents from the vendor • Contingency plans, system diagrams, documented access controls, maintenance procedures, vulnerability scan results, personnel security practices, physical security documentation, software and hardware inventories, etc... • Tests that the third party permits the agency to perform • Continuous monitoring or equivalent • Remediation plans and activities (POA&Ms) • Company reputation – news reports

  14. Testing • Internal testing (internal to the Federal agency): Assess what is controlled on your side • Password controls or controls on access to hosted application or information • Authorization policies/procedures • Disaster recovery • Incident response • Procedures for interfacing with third party

  15. Examples • Case 1 - YouTube: • Hosting publicly available data only on www.youtube.com • What is the risk? Site could be defaced / videos replaced causing possible erosion of NIST’s reputation. Data can not be stolen, it is already publicly available. • How tested? Insured proper incident response in case of defacement. Scoped and tested other applicable controls. Accepted some risk for not fully testing all possible controls based on impact of data and impact of a compromise as well as company reputation.

  16. Examples • Case 2 – Emergency Notification System: • Third party hosts NIST staff contact information. NIST can access via third party web site in case of an emergency and issue emails or phone calls to staff. • What is the risk? Contact information includes PII. Compromise of system could result in PII loss or issuing false emergency announcements. • In this case another agency (GSA) did full C&A against FISMA regulations. Examined GSA’s C&A packet, comfortable with results and moved forward. • Conducting additional local testing of things within NIST’s control and risk assessment before going live.

  17. Recommendations • Apply the Risk Management Framework. • Assess as much of the security picture as possible, locally and on the third-party side. • Examine total cost of ownership. Look at security as part of cost, don’t always go for the lowest bidder. • Limit access to applications and information to only those that need access. • Develop and document procedures so everyone knows what to do when something unexpected happens.

  18. Recommendations • Create policy on Web 2.0. • Excerpt from NIST Web 2.0/Social Media Policy: Web 2.0 or social media software and services often present computer security issues beyond those created with static Web pages. Use of Web 2.0 software or services for deploying official NIST Web content must ensure compliance with NIST and DOC information system security policies. For example, software or services must be tested for security vulnerabilities and formally approved prior to use by the Office of the Chief Information Officer (i.e., through the NIST IT Security Certification and Accreditation process). In addition, NIST OUs must ensure that NIST-hosted software and services are aligned with the existing and planned NIST information technology infrastructure.

  19. Recommendations Ensure that Access & Use Policies for individuals account for social media and web 2.0 technologies. Make sure that internal customers know to engage CIO/security staff (early!) when exploring the use of web 2.0 technologies and deployment of externally hosted applications/services. Make sure clear security requirement are documented in contracts.

  20. Questions?