Security Program Development: Read Chapter 12 and pages 373-381


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The IS Steering Committee is developed as part of the first step gathering interested parties. This committee is then involved with the further steps. The left-hand side shows documentation this is created or read by each stage.
  • This shows the format of a security review (audit test)
  • CISM Exhibit 3.2 Further slides discuss each of these in detail Compliance: Track security issues
  • Metrics can be classified into three areas: Strategic (mgmt-oriented), operational (technical-oriented), and tactical (people-oriented)
  • Sample metrics: select the ones most important to your organization.
  • Automated tests could include: PC check for good passwords, open applications, security settings Check for backup tape/disk registration Comparison of access control planned versus actual
  • Example Entity-Level: Antivirus software on each PC. Firewall only permits N applications. Example Activity-Level: Sales are tracked to delivery without error.
  • This figure is taken from ISACA COBIT documentation
  • There are 4 sections to COBIT. This is the first one, and the areas it is interested in.
  • Zachman Framework is very similar to SABSA, was developed at nearly the same time.
  • CCTV=Close Circuit Televison
  • Development only delivers S/W to System Administration when QC has approved Compliance: tracks security issues, such as metrics or violations of procedures, and resolves security issues
  • Controls are designed from Policy
  • 3- At the architectural stage, controls are being designed. Preventative is best type of control. Management is not likely to understand technical details. 1 and 4 are not focused or general enough.
  • Security documentation is the focus of level 3 – organization-wide
  • Security Program Development: Read Chapter 12 and pages 373-381

    1. 1. Info. Security Program Development
    2. 2. Acknowledgments <ul><li>Material is from: </li></ul><ul><li>CISM Review Manual, 2009 </li></ul><ul><li>How to Comply with Sarbanes-Oxley Section 404, M Ramos, Wiley, 2006 </li></ul><ul><li>Author: Susan J Lincke, PhD </li></ul><ul><li>Univ. of Wisconsin-Parkside </li></ul><ul><li>Reviewers: </li></ul><ul><li>Funded by National Science Foundation (NSF) Course, Curriculum and Laboratory Improvement (CCLI) grant 0837574: Information Security: Audit, Case Study, and Service Learning. </li></ul><ul><li>Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and/or source(s) and do not necessarily reflect the views of the National Science Foundation. </li></ul>
    3. 3. Security Relationships Security Strategy & Alignment IT Risk Assessment Security requirements sign-off, Acceptance test, Access authorization Laws & Regulations Security monitoring, Incident response, Site inventory, Crisis management Security requirements and review Change control Security upgrade/test Security requirements in RFP Contract requirements Pur- chasing Quality Control IT Opera- tions Legal Dept Dept. Mgmt Business Risk Mgmt Executive Mgmt Security Manager
    4. 4. Road Map for Security (New Program) Interview stakeholders (HR, legal, finance) to determine org. issues & concerns Develop security policies for approval to Mgmt Security Policies Security Issues Info Security Steering Committee Conduct security training & test for compliance Improve standards Develop compliance monitoring strategy Training materials Documentation
    5. 5. Road Map for Security: Continuation Program – Security Review or Audit Test <ul><li>Objective : Is our web-interface to DB safe? </li></ul><ul><li>Scope : Penetration test on DB </li></ul><ul><li>Constraints : Must test between 1-4 AM </li></ul><ul><li>Approach : </li></ul><ul><li>Tester has valid session credentials </li></ul><ul><li>Specific records allocated for test </li></ul><ul><li>Test: SQL Injection </li></ul><ul><li>Result : </li></ul><ul><li>These problems were found: … </li></ul>
    6. 6. Security Program Requirements <ul><li>Must develop an enterprise security architecture at conceptual, logical, functional, and physical levels </li></ul><ul><li>Must manage risk to acceptable levels </li></ul><ul><ul><li>Risk develops the Business Case that convinces mgmt security should be performed </li></ul></ul><ul><li>Must be defined in business terms to help nontechnical stakeholders understand and endorse program goals </li></ul><ul><li>Must provide security-related feedback to business owners and stakeholders </li></ul>
    7. 7. Security Functions Strategy Policy Awareness Implemen- tation Compliance Monitoring Training & Publishing Monitor industry practices Provide recommendations Policy, Procedure, Standards Security architecture and engineering Testing, logs, metrics Metrics, investigation, security escalation
    8. 8. Policy Function: Policies & Procedures <ul><li>Policies </li></ul><ul><li>Direction of Management </li></ul><ul><li>Requires approval from senior mgmt </li></ul><ul><li>Should change infrequently </li></ul><ul><li>Communicated to entire workforce via varied means </li></ul><ul><li>Technology-independent </li></ul><ul><li>Should have 24 or less </li></ul><ul><li>One general mandate stated in fewer than 1-3 sentences </li></ul><ul><li>Procedures </li></ul><ul><li>Specific Directions </li></ul><ul><ul><li>Document every step </li></ul></ul><ul><ul><li>Changes with procedure </li></ul></ul><ul><li>Provided on Need-to-Know basis </li></ul><ul><li>Should be tested </li></ul><ul><li>Technology-specific </li></ul>
    9. 9. Example Policies <ul><li>Risks and potential impacts must be managed utilizing appropriate controls and countermeasure to achieve acceptable levels at acceptable costs </li></ul><ul><li>Monitoring and metrics must be implemented, managed, and maintained to provide ongoing assurance that all security polices are enforced and control objectives are met. </li></ul><ul><li>Incident response capabilities sufficient to ensure that impacts do not materially affect the ability of the organization to continue operations must be implemented and managed </li></ul><ul><li>Business continuity and disaster recovery plans shall be developed, maintained and tested in a manner that ensures the ability of the organization to continue operations under all conditions </li></ul>
    10. 10. Awareness Function: Types of Security Training Awareness: Create security-conscious workforce Employees, partners & vendors Newsletters, surveys, quizzes, video training, forums, posters Training: Necessary skills for a particular position HR, legal, middle or top mgmt Workshops, conferences Education: High level skills High-skilled professions: audit, security admin/mgmt, Risk mgmt… Organized and gradual development: teaching & coaching
    11. 11. Awareness Training <ul><li>Signed employment agreements, video, memos, emails, posters, seminars and training classes </li></ul><ul><li>A combination of parallel approaches </li></ul><ul><li>Knowledge areas: </li></ul><ul><ul><li>Back-up work-related files </li></ul></ul><ul><ul><li>Choosing passwords and avoiding exposure </li></ul></ul><ul><ul><li>Avoiding email and web viruses </li></ul></ul><ul><ul><li>Recognizing social engineers </li></ul></ul><ul><ul><li>Recognizing & reporting security incidents </li></ul></ul><ul><ul><li>Securing electronic & paper media against theft & exposure </li></ul></ul><ul><ul><li>Spotting malware that could lead to identity theft & desktop spying </li></ul></ul><ul><li>Metrics should be established to determine effectiveness of change in behavior and workforce attitude </li></ul>
    12. 12. Implementation Function Publicly Available Framework Guided Implementation Policy Level COBIT: Free NIST: Free ISO 17799: $50 SABSA Standards Level ISO 15408: $90 Procedures Level You Develop
    13. 13. Security Standards <ul><li>These standards can be used to develop or advance a security program (if one is not in place): </li></ul><ul><li>ISO/IEC 27001 </li></ul><ul><li>ISACA COBIT </li></ul>Lvl 1 Initial/ Ad hoc Lvl 2 Repeatable but intuitive Lvl 3 Defined Process Lvl 4 Managed & Measurable Lvl 5 Optimized Lvl 0 Nonexistent Where we are Where we want to be Gap Analysis: What do we need to do to achieve our goal? COBIT Levels
    14. 14. Monitoring Function: Includes Metrics <ul><li>Metrics allow independent auditors to attest that the security program is in place </li></ul><ul><li>Monitoring achievement of control objective is more important than perfecting security procedures </li></ul>
    15. 15. Monitoring Function: Metrics Project Plan or Budget Metrics Risk performance Disaster Recovery Test results Audit results Regulatory compliance results Policy compliance metrics Exceptions to policy/standards Changes in process or system affecting risk Incident management effectiveness Vulnerability Scan results Server config. standards compliance IDS monitoring results Firewall log analysis Patch mgmt status Tactical Metrics Opera- tional Metrics Strategic Metrics Metrics
    16. 16. Monitoring Function: Metrics Risk: The aggregate ALE % of risk eliminated, mitigated, transferred # of open risks due to inaction Cost Effectiveness: What is: Cost of workstation security per user Cost of email spam and virus protection per mailbox Operational Performance Time to detect and contain incidents % packages installed without problem % of systems audited in last quarter Organizational Awareness: % of employees passing quiz, after training vs. 3 months later % of employees taking training Technical Security Architecture # of malware identified and neutralized Types of compromises, by severity & attack type Attack attempts repelled by control devices Volume of messages, KB processed by communications control devices Security Process Monitoring: Last date and type of BCP, DRP, IRP testing Last date asset inventories were reviewed & updated Frequency of executive mgmt review activities compared to planned
    17. 17. Compliance Function <ul><li>Compliance : Ensures compliance with organizational policies </li></ul><ul><li>E.g.: Listen to selected help desk calls to verify proper authorization occurs when resetting passwords </li></ul><ul><li>Best if compliance tests are automated </li></ul>Time Audit: Snapshot of compliance in time Compliance: ongoing process Ensures adherence to policies
    18. 18. Security Baseline Today’s Baseline “ We are at 50% compliance but are striving for 100%” Goal Baseline “ We hope to be COBIT Level 3 (Or NIST compliant) within one year”
    19. 19. Security Framework & Architecture Framework: COBIT Architecture: SABSA/Zachman Controls
    20. 20. COSO Comm. of Sponsoring Org. of the Treadway Commission Information & Communication Proper tone & action from top mgmt. Identify & manage risk Manage change Define policies & procedures Monitor/audit controls Consider all Info. sources: Non-routine, external, informal Control Environment Risk Assessment Control Activities Monitoring
    21. 21. COSO: Two Levels of Controls <ul><li>Entity-Level Control </li></ul><ul><li>Cuts cross functions: </li></ul><ul><ul><li>Personnel policies </li></ul></ul><ul><ul><li>Computer controls </li></ul></ul><ul><ul><li>Risk identification </li></ul></ul><ul><ul><li>Financial reporting processes </li></ul></ul><ul><ul><li>System-wide monitoring </li></ul></ul><ul><li>Process Activity Level </li></ul><ul><li>Transaction processing is independent: </li></ul><ul><ul><li>Purchasing transaction </li></ul></ul><ul><ul><li>Sales (credit) transaction </li></ul></ul><ul><ul><li>Account balances </li></ul></ul><ul><ul><li>Disclosures </li></ul></ul><ul><li>Often documented via flowcharts </li></ul>
    22. 22. COBIT <-> COSO <-> SOX
    23. 23. COBIT: Planning & Organization <ul><li>Define a strategic plan </li></ul><ul><li>Define the information architecture </li></ul><ul><li>Define the IT organization and relationships </li></ul><ul><li>Communicate mgmt aims and direction </li></ul><ul><li>Manage human resources </li></ul><ul><li>Ensure compliance with external requirements </li></ul><ul><li>Assess risks </li></ul><ul><li>Manage quality </li></ul>From: How to Comply with Sarbanes-Oxley Section 404, M Ramos, Wiley, 2006
    24. 24. COBIT: Acquisition and Implementation <ul><li>Acquire and maintain application software </li></ul><ul><li>Acquire and maintain technology infrastructure </li></ul><ul><li>Develop and maintain procedures </li></ul><ul><li>Install and accredit systems </li></ul><ul><li>Manage changes </li></ul>From: How to Comply with Sarbanes-Oxley Section 404, M Ramos, Wiley, 2006
    25. 25. COBIT: Delivery & Support <ul><li>Define & manage service levels </li></ul><ul><li>Manage 3 rd party service levels </li></ul><ul><li>Manage performance & capacity </li></ul><ul><li>Ensure continuous service </li></ul><ul><li>Ensure systems security </li></ul><ul><li>Educate & train users </li></ul><ul><li>Manage the configuration </li></ul><ul><li>Manage problems & incidents </li></ul><ul><li>Manage data, facilities, operations </li></ul>From: How to Comply with Sarbanes-Oxley Section 404, M Ramos, Wiley, 2006
    26. 26. COBIT: Monitoring <ul><li>Monitor the process </li></ul><ul><li>Assess internal control adequacy </li></ul><ul><li>Obtain independent assurance </li></ul>From: How to Comply with Sarbanes-Oxley Section 404, M Ramos, Wiley, 2006
    27. 27. SSE-CMM Process Overview Engineering Process Risk Process Assurance Process
    28. 28. SSE-CMM: System Security Eng – Capability Maturity Model Stage 0 Nonexistent: Control processes are not recognized as important Stage 1 Initial/Ad Hoc Control processes are important but no coordinated effort exists Stage 2 Repeatable but Intuitive Many controls are in place but not documented; events are tracked Stage 5 Optimized Continual reevaluation ensures responsiveness and improvement Stage 4 Managed and Measurable Operating effectiveness is evaluated; automatic processes introduced Stage 3 Defined Process Controls, policies, procedures, and event handling are fully documented
    29. 29. Level 1 – Performed Informally <ul><li>Security design is poorly-defined </li></ul><ul><li>Security issues are dealt with in a reactive way </li></ul><ul><li>No contingency plan exists </li></ul><ul><li>Budgets, quality, functionality and project scheduling is ad hoc </li></ul><ul><li>No Process Areas </li></ul>
    30. 30. Level 2 – Planned & Tracked <ul><li>Procedures are established at the project level </li></ul><ul><li>Definition, planning & performance become de-facto standards from project to project </li></ul><ul><li>Events are tracked </li></ul><ul><li>Common Features include: </li></ul><ul><li>Planning Performance </li></ul><ul><li>Disciplined Performance </li></ul><ul><li>Verifying Performance </li></ul><ul><li>Tracking Performance </li></ul>
    31. 31. Level 3 – Well Defined <ul><li>Standardized security processes across organization </li></ul><ul><li>Personnel are trained to ensure knowledge and skills </li></ul><ul><li>Assurance (audits) track performance </li></ul><ul><li>Measures are defined based upon the defined process </li></ul><ul><li>Common Features include: </li></ul><ul><li>Defining a Standard Process </li></ul><ul><li>Perform the Defined Process </li></ul><ul><li>Coordinate Security Practices </li></ul>
    32. 32. Level 4 – Quantitatively Controlled <ul><li>Measurable goals for security quality exist </li></ul><ul><li>Measures are tied to the business goals of the organization </li></ul><ul><li>Common Features include: </li></ul><ul><li>Establish Measurable Quality Goals </li></ul><ul><li>Objectively Manage Performance (SLA) </li></ul>
    33. 33. Level 5 – Continuously Improving <ul><li>Continuous improvement arise from measures and security events </li></ul><ul><li>New technologies and processes are evaluated </li></ul><ul><li>Common Features include: </li></ul><ul><li>Improve Organizational Capability </li></ul><ul><li>Improve Process Effectiveness (ROI) </li></ul>
    34. 34. Security Architecture: SABSA Contextual Security Architecture: Business View: Business Risk Model Business Process Model Conceptual Security Architecture: Architects View: Control Objectives Security Strategies & Architecture Logical Security Architecture: Designers View: Security Policies Security Services Physical Security Architecture Builder’s view: Security Rules, Practices, Procedures Security Mechanisms Component Security Architecture Tradesman’s view: Security Standards Security Products & Tools Operational Security Architecture : Facility Manager’s View: Operational Risk Mgmt Security Service Mgmt Copyright SABSA Limited. Printed with permission From:
    35. 35. SABSA Lifecycle Strategy & Concept Design Implement Manage & Measure Logical, Physical, Component, Operational Contextual Conceptual Attributes defined and measured Copyright SABSA Limited. Printed with permission From:
    36. 36. Implementation of SABSA <ul><li>Do first 2 stages first – there can be considerable work in parallel for the subsequent stages. </li></ul><ul><li>For each stage answer: what, why, how, who, where, when </li></ul><ul><ul><li>On previous slide what and why are provided. </li></ul></ul><ul><li>When all 6 stages x 6 questions = 36 answers are done – plan is complete </li></ul>Develop Contextual (Business Risk) Develop Conceptual (Control Objectives) Develop Logical (Security Policies) Develop Physical (Security Procedures) Develop Component (Security Tools) Develop Operational (Service Mgmt) Copyright SABSA Limited. Printed with permission From:
    37. 37. Zachman Framework (Abbrev.) Zachman Institute for Framework Architecture Layer What (Data) How (Function) Where (Network) Who (People) When (Time) Why (Motive) Scope (Planner) Business Model (Owner) System Model (Designer) Technology (Builder) Component (Implementer) Functioning (Worker)
    38. 38. Control Practices <ul><li>These may be useful in particular conditions: </li></ul><ul><li>Automate Controls : Make technically infeasible to bypass </li></ul><ul><li>Access Control: Users should be identified, authenticated and authorized before accessing resources </li></ul><ul><li>Secure Failure : If compromise possible, stop processing </li></ul><ul><li>Compartmentalize to Minimize Damage : Access control required per system resource set </li></ul><ul><li>Transparency : Communicate so that average layperson understands control->understanding & support </li></ul><ul><li>Trust : Verify communicating partner through trusted 3 rd party (e.g., PKI) </li></ul><ul><li>Trust No One : Oversight controls (e.g., CCTV) </li></ul><ul><li>Segregation of Duties: See next page </li></ul><ul><li>Principle of Least Privilege : Minimize system privileges </li></ul>
    39. 39. Separation of Duties Development System/ Network Admin Business Audit Security/ Compliance Quality Control advises delivers S/W to serves tests or ensures quality of S/W or production advises & monitors for security Ensures procedures are professionally done
    40. 40. Summary of Physical Controls <ul><li>Access Control </li></ul><ul><li>Walls, Doors, Locks </li></ul><ul><li>Badges, smart cards </li></ul><ul><li>Biometrics </li></ul><ul><li>Security cameras & guards </li></ul><ul><li>Fences, lighting, sensors </li></ul><ul><li>Locked files </li></ul><ul><li>Clean desk </li></ul><ul><li>Paper shredders </li></ul><ul><li>Environmental Controls </li></ul><ul><li>Backup power </li></ul><ul><li>Air conditioning </li></ul><ul><li>Fire suppressant </li></ul>
    41. 41. Control Analysis Placement Effectiveness Efficiency Policy Implemen- tation Where are controls located? Are controls layered? Is control redundancy needed? Does control protect broadly or one application? If control fails, is there a control remaining? (single point of failure) If control fails, does appl. fail? Are controls reliable? Do they inhibit productivity? Are they automated or manual? Are key controls monitored in real-time? Are controls easily circumvented? Do controls fail secure or fail open? Is restrictive or permissive policy (denied unless expressly permitted or vice versa?) Does control align with policy & business expectation? Have controls been tested? Are controls self-protecting? Do controls meet control objectives? Will controls alert security personnel if they fail? Are control activities logged and reviewed?
    42. 42. Due Diligence Due Diligence = Did careful risk assessment (RA) Due Care = Implemented recommended controls from RA Liability minimized if reasonable precautions taken Senior Mgmt Support Risk Assessment Backup & Recovery Policies & Procedures Adequate Security Controls Compliance Monitoring & Metrics Business Continuity & Disaster Recovery
    43. 43. Question <ul><li>Which is MOST important for a successful security awareness program? </li></ul><ul><li>Technical training for security administrators </li></ul><ul><li>Aligning the training to organization requirements </li></ul><ul><li>Training management for security awareness </li></ul><ul><li>Using metrics to ensure that training is effective </li></ul>
    44. 44. Question <ul><li>Who can contribute the MOST to determining the priorities and risk impacts to the organization’s information resources? </li></ul><ul><li>Chief Risk Officer </li></ul><ul><li>Business Process Owners </li></ul><ul><li>Security Manager </li></ul><ul><li>Auditor </li></ul>
    45. 45. Question <ul><li>“ Passwords shall be at least 8 characters long, and require a combination of at least 3 of lower case, upper case, numeric, or symbols characters”. This is an example of a: </li></ul><ul><li>Policy </li></ul><ul><li>Procedure </li></ul><ul><li>Guideline </li></ul><ul><li>Standard </li></ul>
    46. 46. Question <ul><li>When implementing a control, the PRIMARY guide to implementation adheres to: </li></ul><ul><li>Organizational Policy </li></ul><ul><li>Security frameworks such as COBIT, NIST, ISO/IEC </li></ul><ul><li>Prevention, Detection, Correction </li></ul><ul><li>A layered defense </li></ul>
    47. 47. Question <ul><li>To detect fraud, the BEST type of audit trail to log would be: </li></ul><ul><li>User session logs </li></ul><ul><li>Firewall incidents </li></ul><ul><li>Operating system incidents </li></ul><ul><li>Application transactions </li></ul>
    48. 48. Question <ul><li>The FIRST step in the SABSA approach is to </li></ul><ul><li>Evaluate existing controls </li></ul><ul><li>Determine current security practices </li></ul><ul><li>Determine business risk </li></ul><ul><li>Define policies and procedures </li></ul>
    49. 49. Question <ul><li>In the architectural or design stage of the security life cycle, the MOST important guideline is: </li></ul><ul><li>Least Privilege </li></ul><ul><li>Management approval </li></ul><ul><li>Prevention, detection, correction </li></ul><ul><li>Confidentiality, Integrity, Availability </li></ul>
    50. 50. Question <ul><li>The PRIMARY focus of COBIT or CMM Level 4 is </li></ul><ul><li>Security Documentation </li></ul><ul><li>Metrics </li></ul><ul><li>Risk </li></ul><ul><li>Business Continuity </li></ul>
    51. 51. Question <ul><li>The MOST important metrics when measuring compliance include: </li></ul><ul><li>Metrics most easily automated </li></ul><ul><li>Metrics related to intrusion detection </li></ul><ul><li>Those recommended by best practices </li></ul><ul><li>Metrics measuring conformance to policy </li></ul>
    52. 52. Question <ul><li>Due Diligence ensures that </li></ul><ul><li>An organization has exercised the best possible security practices according to best practices </li></ul><ul><li>An organization has exercised acceptably reasonable security practices addressing all major security areas </li></ul><ul><li>An organization has implemented risk management and established the necessary controls </li></ul><ul><li>An organization has allocated a Chief Information Security Officer who is responsible for securing the organization’s information assets </li></ul>
    53. 53. Vocabulary <ul><li>Baseline, gap analysis, metrics, compliance </li></ul><ul><li>Security awareness, security training, security education </li></ul><ul><li>COBIT, CMM, Levels 1-5 </li></ul><ul><li>Due Diligence, Due Care </li></ul><ul><li>Answer questions from book page 1101: 1-10, 19, 24-25. </li></ul>