A Security Testing Methodology that Fits Every IT Budget

40
A Security Testing Methodology that Fits Every IT Budget Tom Hasman SRA International, Inc. Rochester Security Summit October 20, 2010

description

There are many different methodologies for implementing and testing security controls in an IT system to ensure that it is operating under an “acceptable level of risk.” Many of these methodologies require the use of software to aid in this measurement. While the execution of technical tools is important, it can sometimes place a financial burden on an organization (especially a small business) that may not have the resources to purchase the software or hire trained personnel to run the tools and conduct an analysis of the results. This presentation provides an overview of a security testing methodology developed by the Federal Government through the Department of Commerce’s National Institute of Standards and Technology (NIST) Computer Security Division that is available for use by the security community at no cost. The NIST methodology allows an organization to test their security posture by analyzing controls that are listed in 18 different security categories. Attendees will: 1. Be presented a comprehensive security testing approach that limits the need for using automated tools 2. Take away an understanding of National Institute of Standards and Technology (NIST) security controls and learn how to apply them to their information systems 3. Be shown techniques for documenting testing results 4. Be apprised of best practices for conducting security testing of information systems Tom Hasman, Senior Information Security Analyst, SRA International Tom is Senior Information Security Analyst on the Information Assurance team for SRA International. Tom specializes in Security Tests & Evaluations in support of the government’s Certification & Accreditation process. He performs risk assessments and makes recommendations to clients for prioritizing and mitigating vulnerabilities. Tom also develops security policies and procedures for government clients.

Transcript of A Security Testing Methodology that Fits Every IT Budget

  • 1. A Security Testing Methodologythat Fits Every IT Budget Tom Hasman SRA International, Inc. Rochester Security Summit October 20, 2010

2. DisclaimerPoints of view or opinions expressed in this presentation do not necessarilyrepresent the official position or policies of SRA. 2 Copyright 2010 3. About SRASRA Founded in 1978 Based in Washington, DC; offices throughout the US - Durham, NC; San Diego; San Antonio; Colorado Springs; Scranton, PA, Rochester, NY Offices in Europe too United Kingdom, Germany, France and the Czech Republic Work for government organizations and commercial clients serving the national security, civil government and global health markets Expertise in areas including: air surveillance and air traffic management; contract research organization (CRO) services; cyber security; disaster response planning; enterprise resource planning; environmental strategies; IT systems, infrastructure and managed services; logistics; public health preparedness; public safety; strategic management consulting; systems engineering; and wireless integration. Current workforce: 7,100+ employees Website: www.sra.com3 Copyright 2010 4. Speaker BiographyTom Hasman Senior information security analyst on Information Assurance team at SRA Joined SRA in December 2000 Arlington, VA office Background in risk management and security testing; conducted over 100 risk assessments and security tests on government systems for clients including EPA, DHS, DOC, DOI, USITC, and Dept of Treasury Advises clients on security policy and how they can implement a strong risk management program with limited security resources Past speaker at Computer Security Institute (CSI) Conference and the RSA Security Conference MA in Government from Johns Hopkins University and wrote/defended masters thesis on information warfare. 4Copyright 2010 5. AgendaIntroduction why test? Problems with security testing Alternate testing solution Implement security program and controls before testing Testing security controls Creating a test report Best practices Summary Questions POC information and web site link 5 Copyright 2010 6. Why Conduct Security Testing?Its the Law! FISMA - requires federal agencies have an effective program for protecting their data and information systems (risk management) HIPAA Security Standards Sarbanes-Oxley Section 404 Management of Internal Controls A key component of risk management is the implementation of a good security testing program Security Testing is part of best practices It increases awareness about security of the system Identifies systems risks, vulnerabilities, etc. Provides improved basis for making decisions Provides justification of expenditures Security Test = High confidence that assets are adequately protected - assuming the test went well 6Copyright 2010 7. Problems with Security TestingCost Many security testing methodologies require the use of expensive software to aid in testing Expertise Even free tools require technical expertise to analyze results Time A lot of time spent reviewing tool outputHire an expert = $$$$Do it yourself = lots of lost time Too much time/money spent on technical solution, not enough time/energy on personnel 7Copyright 2010 8. Alternative Testing SolutionFree tools from the federal governments Department of Commerce National Institute of Standards and Technology (NIST) Computer Security Division Requires minimal technical background Series of Special Publications that: Help you categorize your system (C, I, A ratings) Help you choose the appropriate security control to implement in your system Help you test those controls to ensure that are implemented correctly (system operating at acceptable level of risk.) 8Copyright 2010 9. Questions to ask before testingWhat am I trying to protect? How sensitive is the data Do I have a security program? What methodology is used? How mature is it? Have I implemented a minimum set of security controls? Implemented Planned Accept risk 9Copyright 2010 10. Sensitivity of DataBased on three security objectivesConfidentiality Assurance that information is not disclosed to unauthorized persons, processes, or devices Integrity Guarding against improper information modification or destruction Availability Timely, reliable access to data and information services for authorized users10Copyright 2010 11. What am I trying to protect? (Categorize Your Systems C, I, A Levels)FIPS 199 security categorization of federal systems Use is required for government information systems Used to determine C, I, A levels of system NIST SP 800-60 carries out FIPS 199 requirements NIST SP 800-60 Guide for Mapping Types of Information and Information Systems to Security Categories Revision one released in August 2008 Contains guidelines for mapping types of information and information systems to security categories In other words, helps determine C, I, A levels (L, M, H) based on type of information system processes All NIST SP are available at http://csrc.nist.gov/publications/nistpubs/ index.html11Copyright 2010 12. What am I trying to protect? (cont) NIST SP 800-60 ExampleFinancial Management Heading Information TypeCI AFunds Control MM LAccountingLM LPaymentsLM LSecurity Category RatingMM L Overall Rating = Moderate 12Copyright 2010 13. Do I have a security program? (Risk Management Framework)NIST SP 800-37 Guide for Applying the Risk Management Framework to Federal Information Systems Latest version released in February 2010 Old ModelConduct system certification & accreditation (C&A)once every 3 yearsIgnore IT security program until C&A is due again New ModelMaintains the need for a C&A every 3 yearsOrganizations must practice continuous monitoringA subset of controls should be tested yearlyMinimizes burden of C&A (controls constantly tested)13Copyright 2010 14. Have I Implemented a minimum set of controls?NIST SP 800-53 Rev3 Latest version is August 2009 (updates to May 1, 2010) Establishes minimum set of security controls based on system information C, I, A levels Document has baseline + control enhancements for those areas where C, I, A is medium or high 17 families among Management, Operational and Technical controls + 1 family for Program Management Originally designed for systems but many controls can be applied at the organization levelAwareness & TrainingIncident ResponseContingency Planning 14Copyright 2010 15. Implementing Security Controls (continued)Rev 3 removed duplicate questions in rev2 Example: Session Termination (AC-12) and Network Disconnect (SC-10) very similar Now under SC-10 in revision 3 New controls added Many new controls in SC family including:Fail state, honeypots, security of information at rest Program Management (PM) family also addedImplementing controls at organization levelEx appointing CISO, capital planning for security Offers the ability to designate common- and hybrid-controls Common implement at a organizational level (AT-2) Hybrid combination of organization/system (CP-2) 15 Copyright 2010 16. Implementing Security Controls (cont2) Minimum Security Requirements Access Control (T) Awareness and Training (O) Audit and Accountability (T) Security Assessment and Authorization (M) Configuration Management (O) Contingency Planning (O) Identification and Authentication (T) Incident Response (O) Maintenance (O) Media Protection (O) Physical and Environmental Protection (O) Planning (M) Personnel Security (O) Risk Assessment (M) Systems and Services Acquisition (M) System and Communications Protection (T) System and Information Integrity (O) Program Management (PM) organization-wide 16Copyright 2010 17. Implementing Security Controls (cont3) Rev3 also provides priority for controlimplementation Priority Code (P1) implement first Priority Code (P2) implement only after all P1controls are in place Priority Code (P3) implement only after all P1and P2 controls in place Unspecified Priority Code (P0) governmentdoes not require for federal systems Organization may choose to implement17Copyright 2010 18. Implementing Security Controls (cont4) Use the priority codes to help guidewhat controls you will implement Make Adjustments for:BudgetOrganizational/company missionIncludes capability to test technicalcontrols Minimizes the need for security scans**As long as your honest*Security scans still needed periodically*Big organizations should run scans on aregular basis 18Copyright 2010 19. Now tested under SC-10 Screen capture from NIST 800-53 rev3 19 Copyright 2010 20. Control enhancement is optional see next slide NIST SP 800-53 Example #1 (AT-2)20Copyright 2010 21. No control enhancements for L, M, HNIST SP 800-53 No control Example #1 (AT-2) enhancements21Copyright 2010 22. NIST SP 800-53 Example #2 (AC-2)22 Copyright 2010 23. NIST SP 800-53Control enhancements Example #2 (AC-2) for M, H 23Copyright 2010 24. No enhancementsEnhancementsNIST SP 800-53Control enhancements Example #2 (AC-2) for M, H 24Copyright 2010 25. Control enhancements increase for L, M, HNIST SP 800-53Increasing control Example #3 (AU-3)enhancements for each level25Copyright 2010 26. NIST SP 800-53Optional control Example #4 (AT-5)(Not selected for L, M, H) 26Copyright 2010 27. Testing Security Controls NIST SP 800-53A used to test implemented controls Latest version published in June 2010 Three types of tests Examine Interview Test (require the use of automated tools) Observe new account with weak password, user attempting to perform administrative functions, obscuring passwords Follows the same format as NIST SP 800-53 17 control families + 1 program level family Categorized under 3 classesManagement, Operational, Technical Guidelines for testing vary based on sensitivity of information Low, moderate, high system impact levels 27 Copyright 2010 28. AT-2: Testing the control28 Copyright 2010 29. AC-2: Assessment Objective29Copyright 2010 30. System Manager, System Administrator, HR AC-2: Testing the baseline control30Copyright 2010 31. AC-2: Testing the control enhancements 31 Copyright 2010 32. AU-3: Assessment Objective and Testing the baseline control 32 Copyright 2010 33. AU-3: Testing the control enhancement33Copyright 2010 34. Test ReportOutput of all testing activities Used to communicate to management security posture of organization Several ways to communicate results: Table format Paragraph format Hybrid Paragraph format executive summary of testing activities Table format lists test results 34 Copyright 2010 35. Sample Test Report Control Test MethodTest DateTest ResultPass/Fail AC-2- Examined Account Management 10/16/10 - Account management handbookFail Handbook V1.4 dated contains procedures for opening 5/12/10 and closing accounts but often - Interviewed System Manager10/19/10system administrator creates Abigail Hasmannew accounts without system - Interviewed System10/20/10manager approval Administrator Sam Hasman - Human resources rep not contacted - Interviewed Human Resources 10/20/10on a regular basis. Result = Rep Linda Hasmanmany accounts of departed employees remain openAT-2- Examined security awareness 10/2/10- PowerPoint slides very detailed andPassPowerPoint slides easy to understand. - Examined security awareness 10/2/10- Security posters placed aroundposter near elevator (wearbuilding (elevators, kitchen) arebadge and dont let peopleeye catching and communicatetailgate)10/4/10message effectively - Examined training records Excel- Training records spreadsheetspreadsheet10/8/10includes names of all - Interviewed Training employees and date PowerPointCoordinator [Name here]10/8/10presentation was completed. - Interviewed five employees - Training coordinator very [list names here]knowledgeable- Employees discussed content ofslides (verified that theyactually took the training)35 Copyright 2010 36. Sample Test Report (continued)ControlTest Method Test DateTest ResultPass/FailAU-3- Examined auditing procedures 9/30/10- Audit procedures very detailed and Pass - Examined sample audit report 9/30/10 contain list of specific eventsto be audited. - Sample report included the list ofaudited events identified in theprocedure. PE-7- Examined visitor sign in log for 10/2/10- Visitor sign in log was missingFail(Visitor9/15/10-9/30/10information. In many cases,Control) - Interviewed two front desk 10/2/10the name of the employeesecurity officersaccompanying the visitor was [list names here] not listed. In some other cases, the date of the visit was missing. - Front desk security officers noted that they are often overwhelmed with multiple tasks and therefore cant always scrutinize employees when they are signing in visitors.36Copyright 2010 37. Best Practices Do not begin testing until you: Know sensitivity of system/organizational data Have a security methodology in place Implemented minimum set of security controls Give interviewees background on task before conducting interview Take interview notes on a laptop Do not use paper and pen Write up test results as you complete interviews When possible, try to include something positive in test results 37Copyright 2010 38. SummaryTesting leads to a good risk management program High confidence that assets are protected from external and internal threats Following a test methodology such as NIST or OCTAVE minimizes your need to conduct expensive and time consuming vulnerability scans Practice Continuous Monitoring of security controls 38 Copyright 2010 39. Questions 39Copyright 2010 40. Contact Information & Website for NIST Publications Tom Hasman [email protected] 585-473-6512 (office) 585-857-3718 (cell) All NIST SP are available at: http://csrc.nist.gov/publications/PubsS Ps.html40Copyright 2010