ISSAP Session 6 Requirements Analysis and Security Standards/Guidelines

1. ISSAP Session 6Requirements Analysis and Security Standards/Guidelines 19 September 2011

2. Requirements • Questions from Session 5 ? • Session 1, 2, 3, &4 handouts are posted on www.silverbulletinc.com/DM2 • Contact Shelton Lee for credentials • Shelton.lee@lmco.com

3. Requirements • Schedule – Ten Sessions 08/24/2011 Organization08/29/2011 Access Control pg 3-6208/31/2011 Access Control pg 62-117 09/07/2011 Cryptography pg 125-17209/12/2011 Cryptography pg 173-21209/14/2011 Physical Security pg 222-28509/19/2011 Requirements pg 293-35109/21/2011 BCP & DRP pg 357-371 Telecom pt 1 pg 379-399 09/26/2011 Telecomm pt 2 pg 399-44009/28/2011 Review

4. Requirements • Requirements are critical to the proper assignment of controls to any operation • Key areas are: • Analysis of design requirements • Value of data • Design architecture • Understanding information systems security standards and guidelines • Assessment of information system security effectiveness • Attack vectors

5. Requirements • Requirements stem from business need and policy • Risk Analysis • Should be conducted • Risks should be mitigated • May be accepted • OCTAVE Operationally Critical Threat, Asset, and Vulnerability Evaluation • NIST SP 800-30 • ISO/IEC 27005

6. Requirements • Requirements gathering, capture, specification • Capture: spreadsheet, table, database • Products: Rhapsody, DOORS, System Architect, Quality Center • ISSAP should insist on following industry best practices as a measure of due dilligence and ethics

7. Requirements • Risk Theory • Risk = Vulnerability * threat * Impact Countermeasures • Risk Analysis • Business case • System characterization • Threat Analysis • Vulnerability and Control Analysis • Risk mitigation strategy • Risk Level • Residual Risk

8. Requirements • Define Requirements • Identify requirements • Verify and validate requirements • Document Requirements • Iterate • Avoid ambiguous, untracable, unusable • Will drive cost up and usability down

9. Requirements • Attack Vectors • Must be familiar with common types • No single layer is enough • CVE • Firewalls and AV • Zero day • Heuristics • “Vector” refers to method of attack • Not payload • Virus decreasing, trojan and spyware increasing • Single tasking vs multitasking

10. Requirements • Attack by e-Mail • Generally by attachment • Social engineering: enclosed URL • Combining with spam • Often mistakes in english - Check actual URL (may need to look at source)

11. Requirements • Attack By Deception • Social engineering • Fraud, scam, hoaxes, virus, worms • Convince people to act out of the ordinary • Slow escalation – innocuous start • Hoaxes • Target ignorance and credulity • May be DOS through multiplication • “send to all your friends” • Damage through deletion

12. Requirements • Hackers • Term of respect ? • Crackers • Black vs white hat • Unlike code, are flexible and can recognise opportunities • Often use trojans and root kits

13. Requirements • Web page attack • Counterfeit sites • Redirection • Misspelling • Popup pages can install malware, spyware, adware, trojans. Diallers or scamware • Can close connection then try to dialup

14. Requirements • Worms • Stand alone program • Virus is a code fragment • Windows DCOM vulnerability • Any remote access service • Many install trojans • Disable

15. Requirements • Malicious Macros • WORD and Excell Macros • Major issue of 1995 – Melissa • Can turn off now • Macro can do almost anything (usually VB) • Instant messaging, IRC, P2P file sharing • Valuable internally • Not over Internet • Attachments are main problem • Malicious URLs

16. Requirements • Viruses • Six attributes of malware • Insertion • Activation • Evasion • Replication (virus, worm) • Payload • Eradication • Vectors • E-mail attachments, downloaded files, worms, etc

17. Requirements • Asset and Data Valuation • Priceless data may be under protected • Unimportant have excess protection • “All data has value and shall be protected in accordance with value” • Context is important • Business Impact Analysis

18. Requirements • Context and Data Value • Effect of loss • Afford a few days downtime or not • Hot spares • Offsite backup • Corporate vs Departmental • Local priorities vs global • Different colors of money

19. Requirements • Business, Legal, and Regulatory Req’mts • Healthcare: HIPAA • PCI DSS • Sarbanes Oxley • Gramm-Leach-Biley Act (GLBA) • Federal Information Security Management Act of 2002 • EU • Directive 95/46/EC collection storage disclosure PII • Directive 2002/58/EC cookies, spam, telemarketting • Calif 1386 • MOA/MOU

20. Requirements • Product Assurance Evaluation Criteria • Orange Book • Part of “rainbow” series • 1984 • D-1 to A-3 rating, C-2 enough for most • ITSEC • European (and Canada) • One less than Common Criteria (E3 ~ EAL4) • Common Criteria • EAL 1-7 (7 highest, 1 “this box is blue”) • EAL 4 most common (no admin/security seperation) • 5 or higher for classified • Driver NSTISSP #11

21. Requirements • Common Criteria Part 1 • v2.3 ISO/IEC 15408:2005 ISO/IEC 18045/2005 • September 2007, Version 3.1 and Revision 2 (NIB) • Assurance based on evaluation • Profile • Target • Three Sections • Part 1 Introduction and general model • Part 2 Security Functional Requirements • Part 3 Security Assurance Requirements • Defines security profiles and security targets

22. Requirements • US, France, Germany, UK, Canada 1998 • Maintain Standards • Increase availability of products and profiles • Eliminate duplicate evals • Continuous improvement • 1999 Australia and NZ • Many More • NVLAP National Voluntary Laboratory Accreditation Program – required to be CC test lab • Now National Information Assurance Partnership (NIAP) Approved Common Criteria Testing Laboratories (CCTL)

23. Requirements • CC Part 2 • Security Functional Components • Target of Evaluation (TOE) must have a set of Security Functional Requirements (SFR) • SFR may include Security Functional Policies (SFP) All SFP are implemented under TOE Security Functionality (TSF). TSF: all hardware software and firmware of a TOE directly or indirectly relied upon for security enforcement

24. Requirements • Target of Evaluation (TOE) • TOE may be an IT product or a part of one • Software application (SA) • Operating system (OS) • SA in an OS • SA in and OS and a workstation • OS and workstation • Smart Card • Cryptographic coprocessor in a smart card • LAN including all connected devices • Database application without the client software • One famous case of a server that was not connected to a network.

25. Requirements • EAL overview (table in book) • 1 functionally tested • 2 structurally tested • 3 methodically tested and checked • 4 methodically designed, tested and reviewed • 5 semiformally designed and tested • 6 semiformally verified design and tested • 7 formally verified design and tested

26. Requirements • There is a long section in the book on the different Common Criteria level detail you will just need to study. • CC Part 3 Assurance Paradigm • Threats need to be clearly articulated • Measures taken to reduce threat and mitigate vulnerabilities • Identify probable future threat vectors and eliminate, mitigate, or notify

27. Requirements • Significance of Vulnerabilities • Threat agengts will continually seek to find vulnerabilities • Some will acquire the target • Lack of trusted products make it difficult to resist attack and likely attacks will occur • IT breaches come from deliberate attacks • Take steps to • Expose, remove, or neutralize all exercisable vulnerabilities • Minimise by reducing residual risk • Monitor so that an exploit of a weakness will be detected

28. Requirements • Cause of Vulnerabilities • Many causes: some types • Inadequate requirements • Defects in hardware or software • Poor development standards or design choices • May meet requirements and still have defects • Misconfiguration • Improper controls on configuration

29. Requirements • CC Assurance • Assurance through active investigation to determine security properties of target • Assurance through Evaluation • Evaluation techniques include: • Analysis and checking of processes and procedures • Checking that P&P are being applied • Analysis of correspondance between TOE design against requirements • Verification of proofs • Analysis of guidance documents • Analysis of functional tests developed and results • Independent functional testing • Analysis for vulnerabilities including flaw hypothesis • Penetration testing

30. Requirements • CC Evaluation Assurance Scale • Greater assurance stems from greater effort • Goal: minimum effort needed to provide necessary assurance • Increasing level based on: • Scope – Amount of IT product included • Depth – deployed to finer level • Rigor – applied in structured manner

31. Requirements • CC Evaluation Assurance Scale • List on NIAP web site • Products in test http://www.niap-ccevs.org/in_evaluation/ • Products no longer active • List of available protection profiles • CC Parts 1-3 • Other useful information • Home is now http://www.niap-ccevs.org/

32. Requirements • ISO/IEC 27000 series • Originally BS 7799 became ISO 17799 • Now ISO 27001/2005 • Information Security Management • Original standard had no certification means 27002 filled gap

33. Requirements • 27001 • Formulate security controls • Manage security risks vs cost • Compliance with laws and regulations • Implimentation and management of controls • Definition of new security management and governance processes • Identification and clarification of existing security processes • Use by management to determine status • Use by auditors to determine compliance • Use by organization to provide information to custormers and trading partners • Implementation of business enabling information security

34. Requirements • Software Engineering Institute (SEI) Carnegie Mellon – Capability Maturity Model Key (CMM) Practices v1.1 • Measure of how an organization does development • Superceded by Capability Maturity Model Integration (CMMI) • Request by government and assistance of MITRE • Based on actual practice • Reflects best state of the practise • Reflects needs of individuals performing software process improvement, process assessments, or capability evaluation • Is documented • Publicly available

35. Requirements • CMM (CMMI) developed by • Performing and observing process assessments and capability evals • Studying non-software organizations • Participating in meetings and workshops • Soliciting and analyzing change requests • Soliciting feedback from industy and government

36. Requirements • CMM has five levels • Level 1 unstructured/chaotic • Level 2 some processes are repeatable • Planning,tracking, oversight, contracts, QA, CM, process development, definition, training • Level 3 – all processes are repeatable • Organization standard process • Integrated software management • Anticipate and solve problems • Software Product Engineering defined • Analyze system requirements, develop software requirements, develop software architecture, design software, impliment code, integrate code, test • Intergroup cooperation • Peer Reviews

37. Requirements • CMM Level 4 • Processes must be managed • Quantitative Process Management • Establish and track goals for performance • Software Quality Management • Define goals • Establish plans • Base on needs, customer, and end state

38. Requirements • CMM Level 5 • Optimization • Continual Improvement • Change management (must be communicated) • Software-related technology innovations • Technology selection • Standard products • Process change management • Define goals • Management sponsorship • Training and incentives • Improvement opportunities identified • Pilots to assess effectiveness

39. Requirements • Unless flowdown and communications are provided, CMMI level 5 is indistinguishable from level 1.

40. Requirements • ISO 7498 • Systems Interconnection • Common basis for coordination of standards development • Open Systems Interconnection • Does not specifically address requirements analysis but is needed • Reference model to identify areas needing improvement • Phased transition to OSI standards

41. Requirements • ISO 7498 Basic reference Model of OSI • Clause 4 – reasons for OSI, defines what is connected, scope of intrconnection, modeling principles • Clause 5 – general nature of reference model: layered, what is layering, principles to describe layers • Clause 6 specific layers • Clause 7 description of layers • Clause 8 description of management aspects of OSI • Clause 9 compliance and consistency with OSI reference model.

42. Requirements OSI 7 layer stack 7. Application Layer NNTP · SIP · SSI · DNS · FTP · Gopher · HTTP · NFS · NTP · SMPP · SMTP · SNMP · Telnet · DHCP · Netconf · RTP · SPDY · (more) 6. Presentation Layer MIME · XDR · TLS · SSL 5. Session Layer Named Pipes · NetBIOS · SAP · L2TP · PPTP · SOCKS 4. Transport Layer TCP · UDP · SCTP · DCCP · SPX 3. Network Layer IP (IPv4, IPv6) · ICMP · IPsec · IGMP · IPX · AppleTalk 2. Data Link Layer ATM · SDLC · HDLC · ARP · CSLIP · SLIP · GFP · PLIP · IEEE 802.3 · Frame Relay · ITU-T G.hn DLL · PPP · X.25 · Network Switch · 1. Physical Layer EIA/TIA-232 · EIA/TIA-449 · ITU-T V-Series · I.430 · I.431 · POTS · PDH · SONET/SDH · PON · OTN · DSL · IEEE 802.3 · IEEE 802.11 · IEEE 802.15 · IEEE 802.16 · IEEE 1394 · ITU-T G.hn PHY · USB · Bluetooth · Hubs

43. Requirements • Payment Card Industery Data Security Standard (PCI-DSS) • Anything dealing with credit cards • Control Objectives/PCI DSS Requirements • Build and Maintain a Secure Network • 1. Install and maintain a firewall configuration to protect cardholder data • 2. Do not use vendor-supplied defaults for system passwords and other security parameters • Protect Cardholder Data • 3. Protect stored cardholder data • 4. Encrypt transmission of cardholder data across open, public networks • Maintain a Vulnerability Management Program • 5. Use and regularly update anti-virus software on all systems commonly affected by malware • 6. Develop and maintain secure systems and applications • Implement Strong Access Control Measures • 7. Restrict access to cardholder data by business need-to-know • 8. Assign a unique ID to each person with computer access • 9. Restrict physical access to cardholder data • Regularly Monitor and Test Networks • 10. Track and monitor all access to network resources and cardholder data • 11. Regularly test security systems and processes • Maintain an Information Security Policy • 12. Maintain a policy that addresses information security

44. Requirements • PCI-DSS • PCI-SSC Security Standards Council • Payment application best practices (PABP) now Payment Application Data Security Standards (PA-DSS) • PCI auditors (PCI DSS QSA) qualified security assessor • QSA on behalf of a PCI council approved consultancy (Big 4) • Small companies may do “self assessment) • Under 80,000 transactions • Self-Assessment Questionnaire (SAQ) • Current version (book) 1.2 (PCI) 2.0

45. Requirements • Architectural Solutions • Service Oriented Architecture (SOA) • Client-Server Architecture • Distributed Centralized Architecture • Database Architectures • Descibe the functional model includingtypes of data to be processed, bandwith required, and topology • Hub and Spoke, Ethernet, Star, Token Ring, etc • ISSAP must be able to design architecture that will compliment and supports the functional architecture • May require Common Criteria • Best practice involves defense in depth • People, Technology, Operations (include processes and procedures) (and policy)

46. Requirements • Defense In Depth • Protect • Detect • React • Three primary elements • People • Technology • Operations

47. Requirements • People • Awareness training • Clearly written policy • Consequence to organization and individual – liability for management • Incentives/rewards (coffee cup)

48. Requirements • DinD • See figure of layered system Network>Enclave Boundry>Enclave • Enterprise Information Security Architecture • Key component of portfolio

49. Requirements • Security Architecture Process • Define system use and purpose • Define security architecture components • Define architectural model • Design Security Architecture • Develop System Security Interfaces and Design (detailed) • Once you have architecture • Iterate system security design • Allocate security services • Design security management services • Design transfer services (flow) • Physical/Administrative/Environmental services • Final deliverables

50. Requirements • Architecture Frameworks • DODAF (thank you Shelton) • Clinger-Cohen Act response • Administered by Off. Of DoD Dep. CIO Enterprise Architecture and Standards Directorate • Led to NATO AF and MoDAF • Zachman Framework • FEAF Federal Enterprise Architectural Framework • TOGAF The Open Group • MoDAF (UK) • NIH EAF • Sherwood Applied Business Security Architecture (SABSA) Framework and Methodology • Service Oriented Modeling Framework (SOMF)