of 46/46
Info. Security Program Development

Info. Security Program Development. Acknowledgments Material is sourced from: CISM® Review Manual 2012, ©2011, ISACA. All rights reserved. Used by permission

  • View
    218

  • Download
    0

Embed Size (px)

Text of Info. Security Program Development. Acknowledgments Material is sourced from: CISM® Review Manual...

  • Info. SecurityProgram Development

  • AcknowledgmentsMaterial is sourced from:CISM Review Manual 2012, 2011, ISACA. All rights reserved. Used by permission.CISA Review Manual 2011, 2010, ISACA. All rights reserved. Used by permission.

    Author: Susan J Lincke, PhDUniv. of Wisconsin-ParksideReviewers/Contributors: Todd Burri, Kahili Cheng

    Funded by National Science Foundation (NSF) Course, Curriculum and Laboratory Improvement (CCLI) grant 0837574: Information Security: Audit, Case Study, and Service Learning. 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.

  • ObjectivesThe student should be able to:Define security baseline, gap analysis, metrics, compliance, policy, standard, guideline, procedureDescribe COBIT, CMM, Levels 1-5Develop security metrics

  • Security Program RequirementsMust develop an enterprise security architecture at conceptual, logical, functional, and physical levels Must manage risk to acceptable levelsRisk develops the Business Case that convinces mgmt security should be performedMust be defined in business terms to help nontechnical stakeholders understand and endorse program goalsMust provide security-related feedback to business owners and stakeholders

  • SecurityFramework & ArchitectureArchitecture: SABSA/ZachmanFramework: COBIT, CMM

  • Implementation FunctionPublicly Available Framework Guided Implementation

    Policy LevelCOBIT: FreeNIST: FreeISO 17799: $50

    SABSAStandards LevelISO 15408: $90Procedures LevelYou Develop

  • SABSA LifecycleStrategy &ConceptDesignImplementManage &MeasureLogical,Physical,Component,OperationalContextualConceptualAttributes defined and measuredCopyright SABSA Limited. Printed with permissionFrom: www.SABSA.com

  • Implementation of SABSADo first 2 stages first there can be considerable work in parallel for the subsequent stages.For each stage answer: what, why, how, who, where, whenOn previous slide what and why are provided.When all 6 stages x 6 questions = 36 answers are done plan is completeDevelop Contextual(Business Risk)DevelopConceptual(Control Objectives)Develop Logical(Security Policies)Develop Physical(Security Procedures)Develop Component(Security Tools)DevelopOperational(Service Mgmt)Copyright SABSA Limited. Printed with permissionFrom: www.SABSA.com

  • Security Architecture: SABSAContextual Security Architecture:Business View: Business Risk ModelBusiness Process ModelConceptual Security Architecture:Architects View: Control ObjectivesSecurity Strategies & ArchitectureLogical Security Architecture:Designers View: Security PoliciesSecurity ServicesPhysical Security ArchitectureBuilders view: Security Rules, Practices, ProceduresSecurity MechanismsComponent Security ArchitectureTradesmans view: Security StandardsSecurity Products & ToolsOperationalSecurity Architecture:

    FacilityManagers View:OperationalRisk Mgmt

    SecurityService MgmtCopyright SABSA Limited. Printed with permissionFrom: www.SABSA.com

    Copyright SABSA Limited. Printed with permissionFrom: www.SABSA.com

  • Zachman Framework (Abbrev.)www.ZIFA.com: Zachman Institute for Framework Architecture

    LayerWhat(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)

    www.ZIFA.com: Zachman Institute for Framework Architecture

  • COBIT HistoryCOSOComm. of Sponsoring Org. of the Treadway CommissionInformation & CommunicationProper tone & actionfrom top mgmt.Identify & manage riskManage changeDefine policies & proceduresMonitor/auditcontrolsConsider all Info. sources:Non-routine, external, informal

  • COSO: Two Levels of ControlsEntity-Level Control Cuts cross functions:Personnel policiesComputer controlsRisk identificationFinancial reporting processesSystem-wide monitoringProcess Activity LevelTransaction processing is independent:Purchasing transactionSales (credit) transactionAccount balancesDisclosuresOften documented via flowcharts

  • COBIT COSO SOXhttp://www.isaca.org/

  • COBIT:Planning and OrganizationPO1 Define a strategic IT plan.PO2 Define the information architecture.PO3 Determine technological direction.PO4 Define the IT processes, organisation and relationships.PO5 Manage the IT investment.PO6 Communicate management aims and direction.PO7 Manage IT human resources.PO8 Manage quality.PO9 Assess and manage IT risks.PO10 Manage projects.Source: COBIT 4.1, 2007 ISACA, All rights reserved.

  • COBIT:Acquisition and ImplementationAI1 Identify automated solutions.AI2 Acquire and maintain application software.AI3 Acquire and maintain technology infrastructure.AI4 Enable operation and use.AI5 Procure IT resources.AI6 Manage changes.AI7 Install and accredit solutions and changes.Source: COBIT 4.1, 2007 ISACA, All rights reserved.

  • COBIT:Delivery and SupportDS1 Define and manage service levels.DS2 Manage third-party services.DS3 Manage performance and capacity.DS4 Ensure continuous service.DS5 Ensure systems security.DS6 Identify and allocate costs.DS7 Educate and train users.DS8 Manage service desk and incidents.DS9 Manage the configuration.DS10 Manage problems.DS11 Manage data.DS12 Manage the physical environment.DS13 Manage operations.Source: COBIT 4.1, 2007 ISACA, All rights reserved.

  • COBIT:MonitoringME1 Monitor and evaluate IT performance.ME2 Monitor and evaluate internal control.ME3 Ensure regulatory compliance.ME4 Provide IT governance.

    Source: COBIT 4.1, 2007 ISACA, All rights reserved.

  • SSE-CMM Process OverviewEngineeringProcessRisk ProcessAssuranceProcess

  • SSE-CMM: System Security Eng Capability Maturity ModelStage 0 Nonexistent:Control processes are not recognized as importantStage 1 Initial/Ad HocControl processes are important but no coordinated effort existsStage 2 Repeatable but IntuitiveMany controls are in place but not documented; events are trackedStage 5 OptimizedContinual reevaluation ensures responsiveness and improvementStage 4 Managed and MeasurableOperating effectiveness is evaluated; automatic processes introduced Stage 3 Defined ProcessControls, policies, procedures, and event handling are fully documented

  • Level 1 Performed InformallySecurity design is poorly-definedSecurity issues are dealt with in a reactive wayNo contingency plan existsBudgets, quality, functionality and project scheduling is ad hocNo Process Areas

  • Level 2 Planned & TrackedProcedures are established at the project levelDefinition, planning & performance become de-facto standards from project to projectEvents are tracked

    Common Features include: Planning PerformanceDisciplined PerformanceVerifying PerformanceTracking Performance

  • Level 3 Well DefinedStandardized security processes across organizationPersonnel are trained to ensure knowledge and skillsAssurance (audits) track performanceMeasures are defined based upon the defined processCommon Features include:Defining a Standard ProcessPerform the Defined ProcessCoordinate Security Practices

  • Level 4 Quantitatively ControlledMeasurable goals for security quality existMeasures are tied to the business goals of the organizationCommon Features include:Establish Measurable Quality GoalsObjectively Manage Performance (SLA)

  • Level 5 Continuously ImprovingContinuous improvement arise from measures and security eventsNew technologies and processes are evaluatedCommon Features include:Improve Organizational CapabilityImprove Process Effectiveness (ROI)

  • Security BaselineTodaysBaselineWe are at 50%compliance butare striving for 100%GoalBaselineWe hope to beCOBIT Level 3(Or NIST compliant)within one year

  • Security StandardsThese standards can be used to develop or advance a security program (if one is not in place):ISO/IEC 27001ISACA COBITLvl1Initial/Ad hocLvl2Repeatablebut intuitiveLvl3DefinedProcessLvl4Managed &MeasurableLvl5OptimizedLvl0NonexistentWherewe areWhere wewant to beGap Analysis: What do we need to do to achieve our goal?COBIT Levels

  • Achieving Higher Maturity LevelsLevel 3: Policy DocumentationLevel 4-5: Metrics

  • Security FunctionsStrategyPolicyAwarenessImplemen-tationComplianceMonitoringTraining &PublishingMonitor industry practicesProvide recommendationsPolicy,Procedure,StandardsSecurity architectureand engineeringTesting, logs,metricsMetrics, investigation,security escalation

  • Level 3: Security PolicyPolicy = First step to developing security infrastructureSet direction for implementation of controls, tools, proceduresApproved by senior mgmtDocumented and communicated to all employees and associates

  • Example PoliciesRisks shall be managed utilizing appropriate controls and countermeasure to achieve acceptable levels at acceptable costsMonitoring and metrics shall be implemented, managed, and maintained to provide ongoing assurance that all security polices are enforced and control objectives are met.Incident response capabilities are implemented and managed sufficient to ensure that incidents do not materially affect the ability of the organization to continue operationsBusiness 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

  • Security Policy DocumentDefinition of information securityStatement of management commitmentFramework for approaching risk and controlsBrief explanation of policies, minimally covering regulatory compliance, training/awareness, business continuity, and consequences of violationsAllocation of responsibility, including reporting security incidentsReferences to more detailed documents

  • Policy DocumentationPolicy= Direction for ControlPhilosophy of organizationCreated by Senior MgmtReviewed periodicallyEmployees must understand intentAuditors test for complianceProcedures:Detailed steps toimplement a policy.Written by processownersStandards:An image ofwhat is acceptableGuidelinesRecommendationsand acceptablealternatives

  • Policies, Procedures, StandardsPolicy Objective: Describes what needs to be accomplishedPolicy Control: Technique to meet objectivesProcedure: Outlines how the Policy will be accomplishedStandard: Specific rule, metric or boundary that implements policy

    Example 1:Policy: Computer systems are not exposed to illegal, inappropriate, or dangerous softwarePolicy Control Standard: Allowed software is defined to include ...Policy Control Procedure: A description of how to load a computer with required software.

    Example 2:Policy: Access to confidential information is controlledPolicy Control Standard: Confidential information SHALL never be emailed without being encryptedPolicy Guideline: Confidential info SHOULD not be written to a memory stickDiscussion: Are these effective controls by themselves?

  • Policy Function:Policies and ProceduresPoliciesDirection of ManagementRequires approval from senior mgmtShould change infrequentlyCommunicated to entire workforce via varied meansTechnology-independentShould have 24 or lessOne general mandate stated in fewer than 1-3 sentences

    ProceduresSpecific DirectionsDocument every stepChanges with procedureProvided on Need-to-Know basisShould be testedTechnology-specific

  • Level 4 Monitoring:Includes MetricsMetrics allow independent auditors to attest that the security program is in placeMonitoring achievement of control objective is more important than perfecting security procedures

  • Monitoring Function: MetricsProject Plan or Budget MetricsRisk performanceDisaster Recovery Test resultsAudit resultsRegulatory compliance resultsPolicy compliance metricsExceptions to policy/standardsChanges in process or system affecting riskIncident management effectivenessVulnerability Scan resultsServer config. standards complianceIDS monitoring resultsFirewall log analysisPatch mgmt status

  • Monitoring Function: Metrics

    Risk:The aggregate ALE% of risk eliminated, mitigated, transferred# of open risks due to inactionCost Effectiveness:What is: Cost of workstation security per userCost of email spam and virus protection per mailboxOperational PerformanceTime to detect and contain incidents% packages installed without problem% of systems audited in last quarterOrganizational Awareness:% of employees passing quiz, after training vs. 3 months later% of employees taking trainingTechnical Security Architecture# of malware identified and neutralizedTypes of compromises, by severity & attack typeAttack attempts repelled by control devicesVolume of messages, KB processed by communications control devicesSecurity Process Monitoring:Last date and type of BCP, DRP, IRP testingLast date asset inventories were reviewed & updatedFrequency of executive mgmt review activities compared to planned

  • Workbook: MetricsMetrics SelectedMajor Risks:FERPA ViolationCracking AttemptWeb AvailabilityLunatic gunmanWhat are the most important areas to monitor in your organization?

    CategoryMetricCalculation & Collection MethodPeriod of ReportingStrategicCost of security/terminalInformation Tech. Group1 yearCost of incidentsIncident Response totals6 monthsTactical% employees passing FERPA quizAnnual email requesting testing1 year% employees completing FERPA trainingTwo annual trainings with sign-in. Performance review1 year# Hours Web unavailableIncident Response form6 monthsOpera-tional# brute force attacksIncident Response form1 month# malware infectionsIncident Response form1 month

  • Question The difference between where an organization performs and where they intend to perform is known as:Gap analysisQuality ControlPerformance MeasurementBenchmarking

  • Question 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:StandardPolicyProcedureGuideline

  • Question The FIRST step in the SABSA approach is toEvaluate existing controlsDetermine current security practicesDetermine business riskDefine policies and procedures

  • Question In the architectural or design stage of the security life cycle, the MOST important guideline is:Least PrivilegeManagement approvalPrevention, detection, correctionConfidentiality, Integrity, Availability

  • Question The PRIMARY focus of COBIT or CMM Level 4 isSecurity DocumentationMetricsRiskBusiness Continuity

  • Question Employees should never open email attachments, except if the attachment is expected and for business use. This is an example of a:PolicyProcedureGuidelineStandard

  • Question The MOST important metrics when measuring compliance include:Metrics most easily automatedMetrics related to intrusion detectionThose recommended by best practicesMetrics measuring conformance to policy

  • Reference

    Slide #Slide TitleSource of Information9Security Architecture: SABSACISM: page 15810Zachman FrameworkCISA: page 95 Exhibit 2.514COBIT: Planning and OrganizationCISA: page 425 and CISM: page 15015COBIT: Acquisition and ImplementationsCISA: page 425 and CISM: page 15016COBIT: Delivery and SupportCISA: page 425 and CISM: page 15017COBIT: MonitoringCISA: page 425 and CISM: page 15028Security FunctionsCISM: page 173 Exhibit 3.1231Security Policy DocumentCISA: page 99,10034Policy Function: Policy and ProceduresCISA: page 99 -10135Level 4: Monitoring: Includes MetricsCISM: page 192 -19436Monitoring Function: MetricsCISM: page 192

    Conceptual business objectives of the program; logical policies; functional - procedures; physical implementation. (One possible model.) Acceptable risk level the risk an organization is willing to take rather than pay to avoid it Business terms how does security help you with the bottom line? Feedback let them know how security is performing (via metrics), make sure they stay aware of security issues*

    COBIT (Control Objectives for Information and related Technology) a set of practices and standards for IT governanceNIST National Institute of Standards and TechnologyISO International Organization for StandardizationSABSA (Sherwood Applied Business Security Architecture) a methodology for IT security

    Some of these are discussed later in the presentation.*The loop here means that everything is evolving. The manage and measure means that we will learn how well we are doing and how we can improve. That modifies our strategy, and we loop again.*The first two levels are highly business-related, related to assets, risk, policy at strategic level.*This is a diagram of the full SABSA architecture.

    Zachman Framework is very similar to SABSA, was developed at nearly the same time. Both use this matrix idea to define goals/processes at highest and lowest levels.*COSO was created as a method to adhere to Sarbanes-Oxley (SOX) security legislation. SOX is federal legislation to regulate corporate reporting of finances. COSO has 5 functional areas: Control environment, risk assessment, control activities, monitoring, and information and communication. The left side defines the meaning of each of these functional areas. COSO is the forerunner of the COBIT standard, which is focused on IT/Security.*Entity-level control cuts across functions and systems: login/password to a system example.Process Activity level defines how a specific process is implemented securely.Example Entity-Level: Antivirus software on each PC. Firewall only permits N applications.Example Activity-Level: Sales are tracked to delivery without error.**Source: IT Control Objectives for Sarbanes-Oxley, 2nd Edition, 2006, ISACA. All rights reserved. Used by permission.COSO is a model for strategic, corporate governance; whereas CobiT is a recommendation focused on IT governance at the operational level. COBIT was derived from COSO and as can be seen, is aligned with it. Do you recognize that the 5 COSO objectives are listed as COSO Components on this figure? The four on top: Plan and Organize, Acquire and Implement, Deliver and Support, Monitor and Evaluate then all relate to IS. COBIT develops standards for each of these 4 areas. From COBIT, an organization can determine its maturity level. There are two regulations that work with this: Section 302 and 404.There are 4 sections to COBIT. This is the first one, and the areas it is concerned with.

    *Area 2 of COBIT

    *Area 3 of COBIT

    *Area 4 of COBIT

    *COBIT was derived from System Security Engineering Capability Maturity Model. This CMM recommendation is where the maturity levels originally come from. The main 3 concerns for SSE-CMM are shown above.Engineering: Designing IS/SecurityAssurance: Ensuring controls are effective*Stage 0: Is not aware that (security) controls are importantStage 1: Is aware that security controls are important, but haphazard in implementationStage 2: Repeatable: Has project management and many controls and knowledge but not documentedStage 3: Defined = Documented processesStage 4: Managed and Measurable = Uses metricsStage 5: Optimized = Process improvementFire-fighting is the idea that we run around all the time solving the most recent emergency problem.*SLA=Service Level AgreementsROI = Return on Investment, a business statistic measuring the value of assets.This shows both definitions of Security Baseline: where we are, and where we think our minimum level of security should be.*These levels (0-5) are part of the ISACA COBIT recommendation**Source: CISM Review Manual 2009, 2008, ISACA. All rights reserved. Used by permission.Exhibit 3.2Further slides discuss each of these in detail

    Strategy is designed by senior management to make sure security policies are formulated with business objectives in mind and that activities are coordinated throughout the organization. It may include the formation of a steering committee to take charge of the strategy. Compliance: Analyze performance related to security, policies, and security-related legal issues

    Policies are rules. With ISACA, policies are at a high level, as indicated above, since senior management approves them.**Policies are high-level directives unspecific and general.E.g.: Incident response shall be defined and documented and regularly tested and maintained.Procedure: Detailed list of steps to perform some operation:E.g.: Computer Recovery for Malware InfectionStandard: Set of rules defining acceptable implementationE.g.: List of Permitted Software Packages for Office ComputersGuidelines: Recommendations for behavior; not absolutely required but preferred. Implementations may vary depending on project circumstances.E.g. Software Documentation Recommendations*A policy is a high level statement of intended result. A standard is a concrete measurement that correlates to a policy its how you know when youre there. A procedure is a set of instructions for meeting the standard.

    *control objective: where we want to be: this means setting incremental goals. In our last slide, our control objective was to achieve level 3, (not level 5.)

    **Metrics can be classified into three areas: Strategic (mgmt-oriented or high-level), tactical (mid-level, tends to be people-oriented), and operational (low-level, tends to be technical).

    *Metrics should be selected from the highest-priority risks, and are best if their collection is automated.Sample metrics: select the ones most important to your organization.The top part shows the major risks for a school: lunatic gunman, FERPA violation, cracking attempt, web availability.Once we know are risks that we want to monitor for, we can define metrics at each of the strategic, tactical, and operational level. The Calculation and Collection method defines how the statistic will be gathered. The period of reporting is how often we will review the results of the statistics. Normally we review metrics for Operational level more often than Strategic, for example.*1 Gap Analysis *Standard is the correct answer: A Detailed law -> Shall, Require Policy is a high level management directive Procedure is a step-by-step description of an implementation Guideline is a recommendation -> Should3**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-wide4 -Standard*4 Metrics measuring conformance to policy*