First PrinciplesVulnerability AssessmentComputer Architecture &Operating Systems DepartmentUniversitat Autònoma de BarcelonaElisa HeymannManuel Brugnoli
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.
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.
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
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,
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
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
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
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
First Principles Vulnerability AssessmentTaking ActionsStep 5: Dissemination of Results– Report vulnerabilities– Interaction with developers– Disclosure of vulnerabilities
First Principles Vulnerability AssessmentTaking Actions
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++
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++
What about Automated TOOLS?– Everyone asks for them– They may help but …... they are definitely not enough!
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
18EMI• Roadmap needed:– gridFTP– CREAM– WMS• We need input from you!
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.