Information Systems Compliance and Inspection Trends

1. Information Systems Compliance and Inspection Trends 2012 Joint Security Awareness Council Seminar By: Tim Chancellor Robert Huth, Speaker

2. IS Compliance Requirements • 1-206 Security Reviews • Contractor Reviews. Contractors shall review their security system on a continuing basis and shall also conduct a formal self-inspection at intervals consistent with risk management principles. • 8-103. IS Security Manager (ISSM). The ISSM: • Ensures that periodic self-inspections of the facility's IS Program are conducted as part of the overall facility self-inspection program and that corrective action is taken for all identified findings and vulnerabilities. Self-inspections are to ensure that the IS is operating as accredited and that accreditation conditions have not changed. • Are Self Inspections enough? • Compliance Program

3. What is Compliance • Compliance simply means meeting the requirements of a regulation or standard • What are these regulations or standards • NISPOM Chapter 8 • IFSO Manual • Baseline Security Configurations • ISSPs • Other ODAA documents • NIST 800 series • DISA STIGS

4. Compliant Program • Systems in place include • Means to Identify requirements • Putting in place procedures to prevent non-compliance • Testing the procedures to ensure they work • Fixing any issues discovered • Ensuring the issues don’t repeat • Documenting the procedures, test controls and results (Tracking) • You say what you do and do what you say

5. ODAA Metrics • ODAA is keeping metrics • On plan submittal • Number of errors ISSMs make • Will report ISSMs to Corporate FSO as unsuitable • ODAA Manual • The ISSM will be given two opportunities for resubmission. If after the second resubmission (or third submission) the plan is still rejected, the plan will be archived, and appropriate corporate management will be notified

6. Trends in Compliance • ISSP’s are testing ISSM and ISSO competence during ATO reviews and annual inspections • DSS is now nearly or fully staffed • Conducting a more in-depth look during inspections • ISSP’s are trained and knowledgeable on all operating systems • Approvals and oversight by the ISSP’s come down to trust. Do they trust you? Without a structured program that’s repeatable – Trust will be hard to build. • ODAA expects ISSMs and ISSOs to understand and to implement risk management practices based on standards • Master System Security Plans (MSSP) getting more attention • Strict adherence to ISFO Process Manual • MSSP for MUSA test sets and multiple type test sets must be delineated on separate profiles

7. Trends in IS Inspections • We’re seeing more technical findings related to OS and Applications • ISSPs are paying particular attention to hardware baselines and configuration diagrams for accuracy • What’s going to get me in trouble with DSS? • Systems self-certified but inconsistent with the MSSP • Example • MSSP MUSA reflects system in a closed area but resides in a restricted area • Policy lockout is set for 5 tries when the policy states a max of 3 tries

8. Trends in IS Inspections (Con’t) • SSP documentation incomplete or inaccurately reflects the operational requirements • ODAA baseline configurations not implemented • Not doing Weekly Audits • Logs not properly filled out • ODAA is emphasizing both administrative and technical security requirements • Administrative • Contractual • Technical • Standards • ODAA expects ISSMs and ISSOs to understand and to implement risk management practices based on standards

9. DSS Audit Trends • Details, details, details • Compliance, compliance, compliance • Audit Logs not protected • BIOS not protected or configured properly • Operating system certification checklists not documented • User revalidations not being conducted • Local system security policies on the system not matching what is identified in plan • Trusted Download issues • Administrative accounts (PASSWORDS on administrative accounts set to never expire) • Making sure all classified / unclassified (media) is marked properly • Hardware that is called out in the Profile is not found, AND there is no record in the hardware removal log indicating when the hardware was removed When hardware is removed from the baseline it must be documented in the maintenance log including any clearing or sanitization performed • System not approved for Periods Processing

10. DSS Audit Trends • Spreadsheet of all IS showing they were ties back to the original MSSP and ATO letter (family tree concept) • Strict adherence to the Industrial Security Field Operations (ISFO) Process Manual Master System Security Plan requirements • Checked all operating systems (O/S) used on campus to ensure they are approved under an active MSSP • All O/S listed on the software baseline were checked for an antivirus solution. If one is not available you must list actions taken to remediate the non-compliance • At least one system with the O/S listed on the software baseline for each IS was checked for compliance with the associated MSSP • IP addresses were checked on the LAN’s and WAN’s to determine the origin and IEEE 803.2 compliance

11. DSS Audit Trends • Review of every MSSP and Profile was conducted for accuracy • Annual revalidation and training requirement was questioned and process provided • Questioned how often backups of security audit data was done and if backups were stored at an off-site location • BIOS on each reviewed system checked for boot order and Bluetooth connection on laptops • Requested documentation on systems that were mobile within the facility and off-site location. Also wanted explanation of mobile system process • Ask ISSO to attempt to removed a random Data Link Library file from the Sys32 directory and then find the action in the Event Viewer Logs

12. DSS Audit Trends • Checked for Telnet on Unix Systems • Checked audit logs for all network encryption devices to ensure they were being maintained • Looked for current service packs on operating systems • Checked hardware to ensure it was listed on the baseline or maintenance log • Checked the NIC and network services on all of the standalones to make sure they were not enabled • Questioned if policy was in place for identifying those use group accounts e.g. Administrator or Root • Checked 254’s to see if the Level of Concern is really “Basic” and if we really have a contractual requirement.

13. DSS Audit Trends • Anti-virus definitions out of date. (Max of 30 days for updates) • System configuration no longer conforms to the MSSP to which it accredited. • Software Baselines not accurately reflecting all security relevant software. • Privileged users not acknowledging in writing that they understand their responsibilities. • More hardware nomenclature is being compared to hardware baselines to include hard drives. • Ensure there is a direct correlation between self-certified systems and the profile that they were certified under. • Ensure group passwords are set to expire.

14. DSS Audit Changes • Security Rating Matrix (Enhancements) • Primary goals • More quantifiable, less subjective rating process • Standardize and improve consistency • Takes into account all aspects of the contractor facility's security program • Uses a numerical based rating system that gives credit for items exceeding the NISPOM, and deducts points in case of administrative or serious findings • Rating calculation scored based on above and beyond requirements, isolated, systemic and repeat administrative findings, and serious findings

15. Security Rating Matrix (Enhancements)

16. New ISFO Process Guide Highlights (May 26th implementation) • Lockout Policy • 3 unsuccessful attempts in 15 minutes • 60 minute lockout period • Generic and Group Accounts • All generic or group accounts will be deleted or disabled • GCA letter is required if the account is required to stay active • Self-certification lost due to the customer letter • Passwords • 14 characters with complexity (uppercase, lowercase, numbers) • Special characters not mentioned • 60 day expiration

17. Take Aways • Briefing ISSP inspectors on how things work at your facility. • The “devil is in the details” remains true about plan documentation • Ensure your logs contain sufficient information to ensure that someone with no knowledge of your will have the information required to make proper judgments. • Ensure ODAA baseline configuration requirements are being met • Strict adherence to the Master plan concept and self-certification requirements specified in the ISFO Process Manual. • Ensure that everything you self certify can be traced back to a document that authorizes your action. • DSS audits becoming more quantifiable and less subjective

18. Questions? Questions?