paul green president and founder of g2, inc
Post on 14-Jan-2016
103 Views
Preview:
DESCRIPTION
TRANSCRIPT
• 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.
Our ClientsOur Clients
Still True in 2006Still 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
1.1. What is Security Automation What is Security Automation (XCCDF/OVAL)?(XCCDF/OVAL)?
Let’s Address Two Questions.Let’s Address Two Questions.
2.2. How can security automation How can security automation improve the system security improve the system security configuration lifecycle?configuration lifecycle?
What is Security Automation?What is Security Automation?
Conceptual AnalogyConceptual Analogy
Outsource
In-House
Conceptual AnalogyConceptual Analogy
Outsource
In-House
a.) Troubleshoot/Analyze
• Conduct Testing
• Is there a problem?
• Cause of error condition?
• Is this check reporting correctly?
b.) Document/Report Findings
c.) Recommendations
d.) Remediate
Conceptual AnalogyConceptual Analogy
Outsource
In-House
a.) Troubleshoot/Analyze
• Conduct Testing
• Is there a problem?
• Cause of error condition?
• Is this check reporting correctly?
b.) Document/Report Findings
c.) Recommendations
d.) Remediate
Standardize & Automate
a.) Troubleshoot/Analyze
• Is there a problem?
• Cause of error condition?
• Is this check reporting correctly?
More DATA
Conceptual AnalogyConceptual Analogy
Before After
Error Report
Problem: Air Pressure Loss
Diagnosis Accuracy:All Sensors Reporting
Expected Cost: $25.00
Diagnosis:Replace Gas Cap
Conceptual AnalogyConceptual Analogy
XML Made SimpleXML Made Simple
XCCDF - eXtensible Car Care Description Format
OVAL – Open Vehicle Assessment Language
<Car> <Description> <Year> 1997 </Year> <Make> Ford </Make> <Model> Contour </Model> <Maintenance> <Check1> Gas Cap = On <> <Check2>Oil Level = Full <> </Maintenance> </Description></Car>
<Checks> <Check1> <Location> Side of Car <> <Procedure> Turn <> </Check1> <Check2> <Location> Hood <> </Procedure> … <> </Check2></Checks>
XCCDF & OVAL Made SimpleXCCDF & OVAL Made Simple
XCCDF - eXtensible Checklist Configuration Description Format
OVAL – Open Vulnerability Assessment Language
<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>
<Checks> <Check1> <Registry Check> … <> <Value> 8 </Value> </Check1> <Check2> <File Version> … <> <Value> 1.0.12.4 </Value> </Check2></Checks>
The Connected PathThe Connected Path
800-53 Security Control
800-68 Security Guidance
NVD Produced 800-68 in XML Format
COTS Tool Ingest
API Call
Result
RegQueryValue (lpHKey, path, value, sKey, Value, Op);
If (Op == ‘>” )
if ((sKey < Value )
return (1); else
return (0);
Result
AC-7 Unsuccessful Login Attempts
AC-7: Account Lockout Duration
AC-7: Account Lockout Threshold
- <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>
lpHKey = “HKEY_LOCAL_MACHINE”
Path = “Software\Microsoft\Windows\”
Value = “5”
sKey = “AccountLockoutDuration”
Op = “>“
800-53 Security Control
800-68 Security Guidance
NVD Produced 800-68 in XML Format
COTS Tool Ingest
API Call
The Connected PathThe Connected Path
The Connected PathThe Connected PathFor each OS/application
Required technical security controls
Low LevelCheckingSpecification
Security Specifications for PlatformsAnd Application- Vulnerabilities- Required Configurations- Necessary Security Tools
List of all knownvulnerabilities
SecureConfigurationGuidance
How Does This Change the Lifecycle?How Does This Change the Lifecycle?
What Are My SSCL Goals?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
Adopt & Adapt
Compliance & Correction
Develop & DeployReview & Revise SSCLSSCL
The System Security Configuration LifecycleThe System Security Configuration Lifecycle
• 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
• 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
Adopt & Adapt
• We now have a framework that provides traceability between our customized checklists and high level requirements. (e.g. 800.53, 8500)
• 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.
NSAP
Adopt & Adapt
Develop & Deploy
• Develop configuration scripts (address all standard OS’s and builds) based on standards/checklists from A&A
• Customize standard/checklist based on compatibility and risk assessment
• Incorporate standards/checklists into automated auditing toolset
• 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
Develop & Deploy
NSAP• We want to create build scripts that interpret
standardized XML inputs and configure build scripts
• We can now convert the current organization’s custom checklists into standardized XML format. (XCCDF/OVAL)
• Learn how to express “customer specific checks” that are may not be included in CCE
Develop & Deploy
• Report and communicate results– In many cases this process is still paper-based, are
the results produce 1000’s of pages of information.
Compliance & Correction
• Analyze output from each of the scanning tools, in certain cases this includes manual cross referencing of findings
• Remediate (initial cycles will produce large amounts of remediation)
• A machine readable format can support a seamless integration with XCCDF compatible tools.
• Using CCE, we now also have a common reference that allows us to map the configuration results between different security tools.
Compliance & Correction
• We can develop scripts to compare the standardized XML output from each of the scanning tools.
• Now we begin the decision process of determining and implementing the appropriate remediation path.
NSAP
• This can include the analysis of compensating controls.
Compliance & Correction
What’s Available Today?What’s Available Today?
• 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
So Why Should You Care?So Why Should You Care?
• 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.
top related