You’re Not Done (Yet) Turning Securable Applications into Secure Installations using SCAP

1. You’re Not Done (Yet)Turning Securable Applications into Secure Installations using SCAP Charles Schmidt Sept 23, 2011

2. Who Am I The MITRE Corporation • A U.S. non-profit research company chartered to work in the public interest • No products – what we are talking about is free • Other companies can and have productize this work Charles Schmidt • 11 years of work in security automation standards

3. Engineers Cannot Create Secure Applications • Perfect engineering will not produce secure applications • “secure applications” = do their part in protecting an enterprise • No flaws, no weaknesses, no bugs - Still not secure

4. Perfect Engineering A very well engineered barrier… … in a sub-optimal configuration

5. Security • Security = well built software that is correctly deployed and managed given an enterprise’s mission needs • Developed using good security engineering practices • Placed in a user environment, configured, and maintained • At best, engineering makes an application securable • Why should you care? • Because you want your customers & yourself to have actual security, not the illusion thereof • Otherwise you wouldn’t be here • Because most examples of bad configuration are not as obvious as the picture • Because you can help

6. The Missing Link • Between the mission experts (users) and the tool experts (engineers) • Tool experts know how the app and supporting infrastructure works • Mission experts know the local constraints of their enterprise • Not perfect alignment, but there is alignment - otherwise app would not be usable in the enterprise • Engineers may not know the mission of the destination enterprise • Engineers do know their general use cases • There must be a link for security to be achieved

7. Documentation vs. Guidance • Documentation is the complete guide to an app • Guidance is a set of suggestions for how to configure it • Analogy: • Documentation is a map • Guidance is a route • Guidance cannot be a straightjacket - variances in mission must be allowed • Users can take detours, but let them detour from a well-planned route

8. Automated Security Guidance • Automated security guidance • Guidance in a format that supports automated assessment • A route and an auto-pilot • User gets a list of all compliance and non-compliance • User only becomes involved when there is a need to change something • In most enterprises, this will be a minority of items • User now can focus on critical elements • Where their mission requires special configurations • Where their configurations do not meet best security practices • Use documentation to tell which is which

9. SCAP SCAP OCIL • US Government’s approach to automated guidance is SCAP • Security Content Automation Protocol • The unification of a suite of smaller focused standards • Identifies how these standards work together to support security automation • All component standards are usable alone – SCAP just shows how to connect

10. Common Vulnerabilities and Exposures (CVE) From http://cve.mitre.org • Enumerate software vulnerabilities – provide common name • Minimal description and references • Expanded descriptions available at http://nvd.nist.gov E.g. CVE-2009-1045:

11. Common Vulnerability Scoring System (CVSS) • Scores a given vulnerability based on its likely danger • Score runs between 0 (no danger) and 10 (extreme danger) • Three parts • Base – the inherent danger of the vulnerability • A provider can fill this out ahead of time • Temporal – changes over time • Depends of maturity of exploits and remediations • Environmental – reflects specific dangers to an enterprise • Depends on how critical the threatened component is and the impact of failure • CVSS Vectors describe factors contributing to scores • E.g., (AV:N/AC:M/Au:N/C:C/I:C/A:C) = 9.3 • Exploitable over the network • Exploit is moderately difficult • No authentication needed • Critical impact to confidentiality, integrity, and availability

12. Common Configuration Enumeration (CCE) • Enumerate configuration functions in software • Minimal description, possible ways to configure, and references • CCEs do not contain recommendations – policy neutral

13. Common Platform Enumeration (CPE) • Means of naming pieces of software/hardware • Allows recommendations, vulnerabilities, etc. to be tied to specific software or software sets • CPE names are composed of a descriptive URI • cpe:/{part}:{vendor}:{product}:{version}:{update}:{edition}:{language} • Part is “o” for Operating System, “a” for Application, or “h” for Hardware • Empty blocks cover all possible values (e.g. all versions or all editions) • Examples: • cpe:/o:microsoft:windows_xp::sp1 • Microsoft Windows XP Service Pack 1 (all versions, editions, and languages) • cpe:/a:apache:http_server:2.3.6 • Apache Software Foundation Apache HTTP Server 2.3.6

14. Extensible Configuration Checklist Description Format (XCCDF) • Standard format for security guidance • XML format is machine readable and can be converted to human-readable documents • Can drive automated assessment of system compliance • Tailoring structures allow users to easily customize recommendations & assessments • Standardized format allows content to be used by tools from multiple vendors

15. Sample XCCDF <Rule id="mlom_service" weight="10.0"> <title>MLOM_Service automatically enabled</title><description>The MLOM_Service is required to support the MakeLotsOfMoney web application. Ensure automatic startup to prevent application failure. </description> <checksystem="http://oval.mitre.org/XMLSchema/oval-definitions-5"> <check-exportexport-name="oval:developer.com:var:10000" value-id="mlom_service_var"/><check-content-refhref="mlom_guidance_oval.xml“ name="oval:developer.com:def:142"/></check></Rule><Value id="mlom_service_var" type="number"><title>MLOM_Service automatically enabled </title><description>Defines the startup state of the service</description><value>2</value><value selector="automatic">2</value><value selector="manual">3</value><value selector="disabled">4</value></Value>

16. Open Vulnerability Assessment Language (OVAL) • Standardized format to express assertions about system state • Describe how to locate system artifacts (registry keys, configuration files, RPM packages, etc.) • Describe assertions about the state of these system artifacts • Can combine to create sophisticated assertions with many factors • Public repositories of OVAL content exist • http://www.redhat.com/security/data/oval/ (RedHat Errata) • http://oval.mitre.org (Public OVAL repository – many platforms) • Many uses • Vulnerability detection • Inventory • Configuration assessment • Patch detection • Many vendor tools ingest OVAL content and produce OVAL results

17. Sample OVAL (1) <definition id="oval:developer.com:def:142"><metadata><title>MLOM_Service State</title><affected family="windows"><platform>Microsoft Windows 7</platform></affected><description>MLOM_Service start state = automatic</description></metadata><criteria><extend_definition comment="Windows 7 is installed"definition_ref="oval:gov.nist.cpe.oval:def:1"/><criterion comment="Registry key mlomserv!Start = automatic"test_ref="oval:developer.com:tst:10001"/></criteria></definition>

18. Sample OVAL (2) <registry_test id="oval:developer.com:tst:10001" version="1" comment="Registry key mlomserv!Start = variable"><objectobject_ref="oval:developer.com:obj:10000"/><statestate_ref="oval:developer.com:ste:10000"/></registry_test><registry_object id="oval:developer.com:obj:10000" version="1"><hive>HKEY_LOCAL_MACHINE</hive><key>SYSTEM\CurrentControlSet\Services\mlomserv</key><name>Start</name></registry_object><registry_state id="oval:developer.com:ste:10000" version="1"><type>reg_dword</type><valuedatatype="int"var_check="all"var_ref="oval:developer.com:var:10000"/></registry_state>

19. Open Checklist Interactive Language (OCIL) • Standardized format for user questionnaires • Can express question trees, with follow-on questions based on prior responses • Can also be used to guide the collection of system findings and evidence • Used for… • Collection of non-technical assessment information • User assessment • Newer standard • Limited vendor support but expected to grow

20. Current SCAP-Validated Vendors Information current as of May 13, 2011 Logos are trademarked by their respective corporations List of validated vendors and products available at http://nvd.nist.gov/scapproducts.cfm

21. Security Guidance Use Case • Publish guidance for an application • Authors might be application engineers or third-party integrators • Guidance not just for app, but relevant underlying infrastructure • E.g. Web framework or server • Reflect applications requirements as well as security recommendations • May include multiple postures for different cases • E.g., DMZ installation vs. interior installation • From SCAP • XCCDF for guidance framework • OVAL for technical checks/OCIL for non-technical checks • If a public application, use CCE and CPE to annotate • Users utilize for initial configuration and ongoing maintenance • Can tailor policy for local needs

22. Inventory Management Use Case • Name and detect application presence • Identify relevant software and versions • Identify necessary supporting architecture • From SCAP • If a public application, register a CPE • Define OVAL checks for detection • Users can automatically detect instance/version • Alert to rogue instantiations • Alert to obsolete versions • Correlate to alerts and other information

23. Vulnerability Management Use Case • Alert users to discovered software flaws • Provide a means for users to understand and respond appropriately • From SCAP • If a public app, register a CVE • If a custom application, CVE is unnecessary • Use CVSS to alert users as to nature of threat • Create OVAL definitions to determine when the flaw has (not) been patched • Users gain rapid understanding of the threat (if any) • Know the number of issues • Know the magnitude of the necessary response • Know when their environments are vulnerable and when not • Patching failures are a major cause of enterprise vulnerabilities – using automated tools lowers the bar

24. OWASP Project • OWASP OVAL Content Project • A recently created project to create OVAL content of interest to the OWASP community • Gaurav Kumar – Project leader • https://www.owasp.org/index.php/OWASP_OVAL_Content_Project • This will provide content that can then be part of customized guidance bundles

25. Conclusion • Cannot just provide well built applications • Need to provide link to user and their enterprise • Do not just describe features/use to users • Better to provide guidance that covers common cases • User gets to work from a baseline instead of first principles • Automated guidance is best of all • User only needs to pay attention to things that are not “normal” • SCAP is an easy, well tested way to provide automated guidance • We want to help • Mailing lists, documentation, online courses all available

26. For More Information… • More information on the standards • CVE – Vulnerabilities; http://cve.mitre.org • CVSS – Scores severity of vulnerabilities; http://www.first.org/cvss/ • CCE – Configuration controls; http://cce.mitre.org • CPE – Platforms/applications; http://cpe.mitre.org • XCCDF – Structuring guidance; http://nvd.nist.gov/xccdf.cfm • OVAL – Checking language; http://oval.mitre.org • OCIL – Questionnaire language; http://scap.nist.gov/specifications/ocil • NVD – Resources for SCAP users; http://nvd.nist.gov/home.cfm • Making Security Measureable – More resources on SCAP and beyond; http://measurablesecurity.mitre.org/ • MITRE provides free training on guidance development • See our web site for more information: http://benchmarkdevelopment.mitre.org/

27. Thank You