First Principles Vulnerability Assessment


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

No notes for slide

First Principles Vulnerability Assessment

  1. 1. First PrinciplesVulnerability AssessmentComputer Architecture &Operating Systems DepartmentUniversitat Autònoma de BarcelonaElisa HeymannManuel Brugnoli
  2. 2. 2The Bad News• The bad guys are trying to do really bad thingsto us.• They are smart, dedicated and persistent.• No single approach to security can besufficient.• The attackers have a natural advantage over thedefenders.We have to approach the defense of our systems assecurity in depth.
  3. 3. 3The Good News• We started by trying to do something simple:Increase our confidence in the security of somecritical Grid middleware.• We ended up developing a newmanual methodology:First Principles VulnerabilityAssessment• We found some serious vulnerabilities … and morevulnerabilities … and more.
  4. 4. 4Key Issues for Security• Need independent assessment– Software engineers have long known thattesting groups must be independent ofdevelopment groups• Need an assessment process that isNOT based solely on knownvulnerabilities– Such approaches will not find new typesand variations of attacks
  5. 5. 5Our Piece of the Solution SpaceFirst Principles Vulnerability Assessment:• An analyst-centric (manual) assessment process.• You can’t look carefully at every line of code so:then identify key resources andprivilege levels, component interactionsand trust delegation, then focused componentanalysis.Don’t start with known threats …… instead, identify high value assets in thecode and work outward to derive threats.• Start with architectural analysis,
  6. 6. First Principles Vulnerability AssessmentUnderstanding the SystemStep 1: Architectural Analysis– Functionality and structure of the system,major components (modules, threads,processes), communication channels– Interactions among components and with users
  7. 7. Architectural Analysis: Condorcondor & rootOS privilegesusermasterCondor submit hostscheddshadowsubmit1. fork3. submit jobClassAd8. forkmasterCondor execute hoststarterstartdjob1. fork8. fork10. start jobmasterStork server hoststork_server1. forkCondor execute hostmasternegotiator collector1. fork 1. fork5. Negotiatorcycle2. machineClassAd4. jobClassAd5. Negotiatorcycle6. Reportmatch6. Reportmatch7. claim host9. establishchannel
  8. 8. First Principles Vulnerability AssessmentUnderstanding the SystemStep 2: Resource Identification– Key resources accessed by each component– Operations allowed on those resourcesStep 3: Trust & Privilege Analysis– How components are protected and who canaccess them– Privilege level at which each component runs– Trust delegation
  9. 9. condorOS privilegesrootusergeneric Condor daemon(a) Common Resources on All Condor HostsCondorBinaries &LibrariesCondorConfigetcOperationalData &Run-timeConfig FilesspoolOperationalLog Fileslogckpt_server(b) Unique Condor Checkpoint Server ResourcesCheckpoint Directoryckpt(d) Unique Condor Submit ResourcesshadowUser’s Filesuser(c) Unique Condor Execute ResourcesUser Job starterJob ExecutionDirectoriesexecuteSystem CallForwarding andRemove I/O(with StandardUniverse Jobs)Send and ReceiveCheckpoints(with StandardUniverse Jobs)Resource Analysis: Condor
  10. 10. First Principles Vulnerability AssessmentSearch for VulnerabilitiesStep 4: Component Evaluation– Examine critical components in depth– Guide search using:Diagrams from steps 1-3Knowledge of vulnerabilities– Helped by Automated scanning tools
  11. 11. First Principles Vulnerability AssessmentTaking ActionsStep 5: Dissemination of Results– Report vulnerabilities– Interaction with developers– Disclosure of vulnerabilities
  12. 12. First Principles Vulnerability AssessmentTaking Actions
  13. 13. 13Studied SystemsCondor, University of WisconsinBatch queuing workload management system15 vulnerabilities 600 KLOC of C and C++SRB, SDSCStorage Resource Broker - data grid5 vulnerabilities 280 KLOC of CMyProxy, NCSACredential Management System5 vulnerabilities 25 KLOC of CglExec, NikhefIdentity mapping service5 vulnerabilities 48 KLOC of CGratia Condor Probe, FNAL and Open ScienceGridFeeds Condor Usage into Gratia Accounting System3 vulnerabilities 1.7 KLOC of Perl and BashCondor Quill, University of WisconsinDBMS Storage of Condor Operational and Historical Data6 vulnerabilities 7.9 KLOC of C and C++
  14. 14. 14Studied SystemsWireshark, wireshark.orgNetwork Protocol Analyzerin progress 2400 KLOC of CCondor Privilege Separation, Univ. of WisconsinRestricted Identity Switching Module21 KLOC of C and C++VOMS Admin, INFNWeb management interface to VOMS data (rolemgmt)35 KLOC of Java and PHPCrossBroker, Universitat Autònoma de BarcelonaResource Mgr for Parallel & Interactive Applicationsin progress 97 KLOC of C++
  15. 15. 15In Progress for EMIARGUS, wireshark.orggLite Authorization Servicein progressglExec 0.8, NikhefIdentity mapping servicein progress
  16. 16. What about Automated TOOLS?– Everyone asks for them– They may help but …... they are definitely not enough!
  17. 17. Manual vs. AutomatedVulnerability AssessmentThe literature on static analysis tools is self-limiting:– Missing comparison against a ground truth– Tool writers write about what they have found– Limited discussion of false positivesEvery valid new problem that a tool find isprogress, but it’s easy to lose perspectiveon what these tools are not able to do
  18. 18. 18EMI• Roadmap needed:– gridFTP– CREAM– WMS• We need input from you!
  19. 19. 23How do You Respond?A change of culture within the development team:• When security becomes a first-class task, and whenreports start arriving, awareness is significantlyincreased.• This effects the way developers look at code andthe way that they write code.• A major landmark: when your developers startreporting vulnerabilities that they’ve found on theirown.
  20. 20. 24Thank you.Questions?