Paul Green President and Founder of G2, Inc

2. Paul Green President and Founder of G2, Inc We are trusted security advisors to the Federal Government and Fortune 500. We are recognized as having subject matter expertise in the implementation security compliance monitoring software.

3. Our Clients

4. Still True in 2006 “Through 2005, 90 percent of cyber attacks will continue to exploit known security flaws for which a patch is available or a preventive measure known.”  Gartner Group, May 6, 2002 

5. Let’s Address Two Questions. What is Security Automation (XCCDF/OVAL)? • How can security automation improve the system security configuration lifecycle?

6. What is Security Automation?

7. Conceptual Analogy

8. Conceptual Analogy Outsource In-House

9. Conceptual Analogy Outsource a.) Troubleshoot/Analyze • Conduct Testing • Is there a problem? • Cause of error condition? • Is this check reporting correctly? b.) Document/Report Findings In-House c.) Recommendations d.) Remediate

10. Outsource In-House Conceptual Analogy Standardize & Automate a.) Troubleshoot/Analyze a.) Troubleshoot/Analyze • Conduct Testing • Is there a problem? • Cause of error condition? • Is this check reporting correctly? • Is there a problem? • Cause of error condition? • Is this check reporting correctly? b.) Document/Report Findings More DATA c.) Recommendations d.) Remediate

11. Conceptual Analogy Before After Error Report Problem: Air Pressure Loss Diagnosis Accuracy: All Sensors Reporting Diagnosis: Replace Gas Cap Expected Cost: $25.00

12. XML Made Simple XCCDF - eXtensible Car Care Description Format OVAL – Open Vehicle Assessment Language <Checks> <Check1> <Location> Side of Car <> <Procedure> Turn <> </Check1> <Check2> <Location> Hood <> </Procedure> … <> </Check2> </Checks> <Car> <Description> <Year> 1997 </Year> <Make> Ford </Make> <Model> Contour </Model> <Maintenance> <Check1> Gas Cap = On <> <Check2>Oil Level = Full <> </Maintenance> </Description> </Car>

13. XCCDF & OVAL Made Simple XCCDF - eXtensible Checklist Configuration Description Format OVAL – Open Vulnerability Assessment Language <Checks> <Check1> <Registry Check> … <> <Value> 8 </Value> </Check1> <Check2> <File Version> … <> <Value> 1.0.12.4 </Value> </Check2> </Checks> <Document ID> NIST SP 800-68 <Date> 04/22/06 </Date> <Version> 1 </Version> <Revision> 2 </Revision> <Platform> Windows XP <Check1> Password >= 8 <> <Check2> FIPS Compliant <> </Maintenance> </Description> </Car>

14. The Connected Path 800-53 Security Control Result 800-68 Security Guidance API Call NVD Produced 800-68 in XML Format COTS Tool Ingest

15. The Connected Path 800-53 Security Control Result RegQueryValue (lpHKey, path, value, sKey, Value, Op); If (Op == ‘>” ) if ((sKey < Value ) return (1); else return (0); AC-7 Unsuccessful Login Attempts 800-68 Security Guidance API Call AC-7: Account Lockout Duration AC-7: Account Lockout Threshold NVD Produced 800-68 in XML Format lpHKey = “HKEY_LOCAL_MACHINE” Path = “Software\Microsoft\Windows\” Value = “5” sKey = “AccountLockoutDuration” Op = “>“ - <registry_test id="wrt-9999" comment=“Account Lockout Duration Set to 5" check="at least 5"> - <object>   <hive>HKEY_LOCAL_MACHINE</hive> <key>Software\Microsoft\Windows</key>   <name>AccountLockoutDuration</name>   </object> - <data operation="AND">   <value operator=“greater than">5*</value> COTS Tool Ingest

16. The Connected Path For each OS/application FISMA/FIPS 200 List of all known vulnerabilities 800-53 Low Level Checking Specification Required technical security controls Secure Configuration Guidance • Security Specifications for Platforms • And Application • Vulnerabilities • Required Configurations • Necessary Security Tools

17. How Does This Change the Lifecycle?

18. What Are My SSCL Goals? • To facilitate easy-to-manage, consistent server compliance monitoring • Evolve server security strategy from reactive to proactive • Reduce attack surface and minimize operational risk • Near-real-time, verifiable server compliance documentation • These products will automate and change the way we validate and test our high-level requirements

19. The System Security Configuration Lifecycle Adopt & Adapt Develop & Deploy Review & Revise SSCL Compliance & Correction

20. Review existing industry and government configuration checklists and standards (CIS, NIST, NSA, Vendors, etc.) Checklists are often prose documents or spreadsheets and are not machine readable Difficult to manage these files, AND, nearly impossible to compare “side-to-side” Adopt & Adapt

21. Customize standard/checklist based on compatibility and risk assessment These are often conglomerations of various checklists creating N number of “custom” baselines When we account for operational issues we end up with NN variations. In the end, how does your “custom” implementation compare to the original standards? Adopt & Adapt

22. Adopt & Adapt • Educate our clients that a machine readable format for checklists allows us to spend less time on document management and more time focused on other activities in the lifecycle. Adopt & Adapt • We now have a framework that provides traceability between our customized checklists and high level requirements. (e.g. 800.53, 8500) NSAP

23. Develop & Deploy • Customize standard/checklist based on compatibility and risk assessment • Develop configuration scripts (address all standard OS’s and builds) based on standards/checklists from A&A • Incorporate standards/checklists into automated auditing toolset

24. Develop & Deploy • We can now convert the current organization’s custom checklists into standardized XML format. (XCCDF/OVAL) Develop & Deploy • A larger number of man hours can now be saved by using tools that accept the machine readable XCCDF format by directly importing the policies into the security tools • We want to create build scripts that interpret standardized XML inputs and configure build scripts NSAP • Learn how to express “customer specific checks” that are may not be included in CCE

25. Compliance & Correction • Analyze output from each of the scanning tools, in certain cases this includes manual cross referencing of findings • Report and communicate results • In many cases this process is still paper-based, are the results produce 1000’s of pages of information. • Remediate (initial cycles will produce large amounts of remediation)

26. A machine readable format can support a seamless integration with XCCDF compatible tools. Compliance & Correction • We can develop scripts to compare the standardized XML output from each of the scanning tools. Compliance & Correction • Using CCE, we now also have a common reference that allows us to map the configuration results between different security tools. NSAP • Now we begin the decision process of determining and implementing the appropriate remediation path. • This can include the analysis of compensating controls.

27. NIST Windows XP Configuration Guide (SP 800-68) http://csrc.nist.gov/itsec/download_WinXP.html Policy statement represented in XCCDF Configuration checks represented in OVAL Covers: registry settings, file permission checks, password policies, account lockout policies, audit policies Download at: http://checklists.nist.gov/NIST-800-68-WinXPPro-XML-Alpha-rev1.zip What’s Available Today?

28. The adoption of this process will provide the first ever hard linkage between a high-level guidance document and specific security configuration settings. This could be the beginning of a process of connecting the dots between regulations and security settings. So Why Should You Care?