ACC540 Final Exam

Potential Advantages of BYOD

1. Asset mgmt: reduced load on asset mgmt since asset mgmt team need not capture the employee-owned asset details in as much detail as co-owned assets. 2. Cost advantages: cost reduction by offloading device procurement, maintenance, and data plan charges to employee. 3. Employee satisfaction: flexibility, familiarity, anytime/anywhere access, and connectivity for employees. Mobile, flexible workforce and higher productivity. 4. Efficiency: BYOD can improve bus process productivity by eliminating paper-based, manual, or onsite rqmts for dispatch, inventory mgmt, and helpdesk support. Also: -increased productivity -improved customer service -incr bus process efficiency. OSS software can cause exposure to legal risks. -employee retention -slightly better work-life balance.

Accountabilty for

1.Managing Service Agreements (APO09): Service manager. Define and manage service levels. Process: align IT-enabled services and service levels w/ enterprise needs/expectations (identification, specification, design, publishing, agreement, and monitoring of IT services, service levels, and performance indicators). Contract w/ 3rd party service providers- lay out risks/responsibilities for each party. Internal SLA is co help desk. Activities ex: -assess current IT services and service levels to identify gaps btw existing services and the bus activities they support. -analyze bus process to understand needs. Consider what services: -what services support each bus process -what future demands need consideration -analyze the bus process to understand the need -build a catalogue and publish -define/prepare service agreements (DSS04): can be internal (btw IT and other dptmts- help desk) or external (internet service provider, CSP, backup service provider). -monitor (collect data and evaluate performance w/ both ongoing and periodic reviews. Level of satisfaction w/ service level agreement). -follow up Managing Availability and Capacity (BAI04): Head IT ops. Process: balance current/future needs for availability, performance, and capacity w/ cost-effective service provision. Include assessment of current capabilities, forecasting of future needs based on bus rqmts, analysis of bus impacts, and risk assessment to plan/implement actions to meet identified rqmts. Balance current and future needs with realistic costs. Activites ex: -consider customer rqmts, bus priorities, bus objs, budget impact, resource utilization, IT capabilties, and industry trends in assessing availability, performance, and capacity of services/resourses. -Create a baseline (current needs)- bus priorities, resources, budget. -Forecast for future. -Monitor actual performance (by looking at downtime). -Follow up on incidents of failed performance. -Assess bus impact by mapping services and resources to bus processes, collecting data on availability patterns (how likely/costly is downtime?), doing scenario analysis (what if), and determining the likelihood and impact. -Adjust performance and capacity plans as needed -monitor and review, report results -follow up Managing Continuity (DSS04): Business continuity manager, head of IT ops, and COO. Process: establish/maintain a plan to enable the bus and IT to respond to incidents/disruptions in order to continue op of critical bus processes and required IT services and maintain availability of info at a level acceptable to the enterprise. Create and upkeep a plan to respond to probs while keeping info available enough so that operations continue. Activity ex: -identify internal and outsourced bus processes and service activities critical to the enterprise ops/necessary to meet legal/contractual obligations. -develop continuity plan (document and distribute) -need a formal plan -scenario analysis (likelihood/impact) -what are key bus processes/people (APO09) -develop the plan. Consider procedures to follow (health/safety first), bus partners/suppliers, resources required, define/document backup rqmts, what people are needed (skills), team focus (not just IT), and distribute the plan. -test and review the plan; assign roles/responsibilities, fire drill (roll through this w/ people), debrief, what improvements are needed/weaknesses -review regularly; what has changed in org? Impact of changes to business processes, infrastructure, OS, etc. -train

Management Layer Domains

32 total processes under mgmt layer. 1. Align, Plan and Organize (APO)- identification of how IT can best contribute to the achievement of bus objectives. Specific processes in this domain relate to IT strategy/tactics, enterprise architecture, innovation and portfolio mgmt. Others include mgmt of budgets/costs, HR, relationships, service agreements, suppliers, quality, risk, and security. 2. Build, Acquire and Implement (BAI)- makes IT stategy concrete by identifying the rqmts for IT and managing the IT investmt program and projects w/in that program. Also adresses mgmt of capacity, org change, IT change mgmt, acceptance and transitioning, and knowledge, asset, and configuration mgmt. 3. Deliver, Service and Support (DSS)- actual delivery of the IT services required to meet strategic and tactical plans. Includes processes to manage ops, service requests/incidents, problem mgmt, continuity, security services, and bus process controls. 4. Monitor, Evaluate and Assess (MEA)- processes responsible for the assessment of process performance and conformance, evaluation of I/C adequacy, and monitoring of reg compliance.

Board of Directors v Management Role in Risk Oversight (Cloud Computing)

BOD: Cloud computing S/B considered in the org's overall governance activities and regarded as a topic warranting discussion and inquiry by the BOD. Mgmt: to evaluate the internal environment (including the state of bus ops, process standardization, IT costs, and backlog of IT projects) along w/ the external environment (laws and regs, competition's adoption of cloud computing) when deciding whether to adopt cloud computing.

A RACI chart shows who is responsible, accountable consulted and informed contacted and informed consulted and in-charge contacted and in-charge

Consulted and informed

What activity will enhance IT frameworks, directly link the enterprise's risks and IT strategies, and provide real time monitoring of system reliability?

Continuous auditing and assurance.

Function of an Oversight Board

Ensure bus alignment as well as remove the ability of disstenters to criticize the org for a lack of bus conciousness. Group of people to ensure that an activity is done correctly. BOD signs off on formalized info security program.

The EDM domain is which type of process according to COBIT 5? Management Governance Internal audit All

Governance

IT Governance

Integral part of enterprise governance. Provides direction/control to help ensure investments made in IT bring value to the business, the IT resources are used responsibly, and that risks are mitigated. It is a subset of enterprise governance, focused on IT systems and their performance in the context of risk appetite and tolerance. Necessary to avoid falling behind. Also, w/o a strategy= trouble. CRO working w/ CISO is responsible, BOD is acctable and signs off.

SSAE 16

Statement on Standards for Attestation Engagements 16. Covers reporting on controls at a service org. Was finalized by auditing standards board (ASB) of the AICPA in January 2010. This supersedes SAS 70. Includes SOC 1 report, SOC 2 report (trust services criteria), SOC 3 report (AT 101, trust services criteria).

COBIT 5 Management Practices Related to IT Security

-Develop a security framework (write/enforce policies): write governance docs w/ co views on risk appetite. -Define indiv roles: org chart w/ responsibilities and acctability. -Identify threats to security/responses: be aware of current issues, monitor software updates/hardware matches. -Set up monitoring system: audit logs. -Use the system and evaluate info: review audit logs, terminate access for departed employees. -Train peeps so they're aware of security threats/current policies: mandatory and reviews. Provide timely/effective response to security incidents using preventive, detective, and corrective controls. This is a defense in depth approach, since there are layers of security. Should track # of incidents causing disruptions and if they are resolved quicky w/ appropriate procedures. APO13.01- Establish and maintain an ISMS. APO13.02- Define and manage an information security risk trtmt plan. APO13.03- Monitor and review the ISMS. ISMS= info security mgmt system DSS02.01- Define incident and service request classification schemes. DSS05.01- Evaluations of potential threats. Protect against malware. DSS05.02- Manage network and connectivity security. DSS05.03- Manage endpoint security. DSS05.04- Manage user identity and logical access. DSS05.05- Manage physical access to IT assets. DSS05.06- Manage sensitive documents and output devices. DSS05.07- Monitor the infrastructure for security-related events.

Challenges to the Value Creation of IT

-increasing costs -globalization of business/competition -insufficient # of staff in IT Capacity to deliver depends on: -timely, usable, reliable info abt customers/processes/markets/etc. -productive/effective practices (performance and knowledge measurement, etc). -ability to integrate tech.

Basic Facility Controls

-location/protection of IT data center -location/protection of equip w/in a data center -prevention/detection controls. Power losses= dual sources. Multiple power lines, batteries, generators, above-ground cables. Fire protection= non-water based v water based. Heat and humidity= constant monitoring of temp and humidity, as well as dust particles in air. Windowless, insulated rooms. Have "man trap" room on inside before accessing data center. Data center door won't open if outside door is open.

Risk Factors in Systems Development

-poor specs -Over budget/time -lack of structured approach -not meeting needs -poor documentation -abysmal testing -lack of user/mgmt involvement -scope creep (don't define what you want and it keeps getting bigger and bigger) -type of tech (new tech= more risk) -size of project (larger= more risky) -expertise of project team

Describe the important tasks that take place during the systems development phase of SDLC.

-running tests (on fake data only). -running simulations to see if the software is appropriately designed. -training to ensure employees will be able to use the system when it is implemented.

Defining Deficiencies

1. Control deficiencies: design/op of control doesn't allow mgmt or employees, in normal course of performing their assigned functions, to prevent/detect misstatements on a timely basis. -design deficiencies: necessary control missing or does not address intended risk. -op deficiencies: control doesn't op as designed, person performing control lacks necessary competency or auth to perform effectively. 2. Significant deficiencies: deficiency or combo of deficiencies in ICFR that are less severe than a material weakness, but still important enough to merit attention by those reponsible for oversight of the co's financial reporting. Mgmt must report these to the audit committee and auditor. 3. Material weaknesses: deficiency or combo of deficiencies where there's a reasonable possibility that a co's I/C will fail to prevent/detect a MM. Doesn't depend on whether MM occurred, just possibility. Could be a combo of deficiencies where >1 control deficiency affects the same financial reporting obj. Includes reasonable or probable. Mgmt must report to audit committee and auditor. Also can't say controls op effectively if have a material weakness! When evaluating deficiencies consider the magnitude of a potential misstatement and probability (likelihood) that it will occur. Indicators of material weakness include: -fraud involving senior mgmt -restatements of prior F/S -identification of MM by auditor -ineffective oversight by audit committee. Ask: -what is the potential magnitude? -what is the likelihood of occurrence (is it reasonably possible?) -what are common risk factors? -are there compensating controls that have a mitigating effect? -what are indicators of material weaknesses? -what would the "prudent official" conclude? Insights from research: -remediation rates of material weaknesses differ according to the type of MW. -rate of remediation by type is associated w/ co resources and corp governance quality. -changes in abnormal accruals (entity level probs w/ recs and IT. Access controls- SoD. Acct specific probs in rev, tax, and inventory. Failure to remediate for 2 yrs- any type of MW).

Benefits of Cloud Computing

1. Cost savings: pay only for computing resources used rather than purchasing/leasing equip that may not be fully utilized all the time. No physical space rqmts or utility costs. Orgs getting all computing resources from a CSP can get a tax benefit. 2. Speed of deployment: CSPs can meet the need for computing resources faster than most IT functions. 3. Scalability and better alignment of tech resources: org can scale up/down its capacity from one server to hundreds of servers w/o CAPEX. Enables an org to get large amts of computing resources for temporary computing-intensive tasks when needed w/o investing in excess capacity. 4. Decreased effort in managing tech: owning/operating IT function is costly/time consuming. Cloud computing allows org to focus on its core purpose and goals instead. CS offerings are also usually based on a prebuilt standardized foundation of tech that facilitates better support and makes provisioning computing resources easier, allowing for more consistent tech upgrades and expedited fulfillment of IT resource requests. 5. Environmental benefits: less power consumption, carbon emissions, and physical land use. Bus case for cloud computing is: -decouples IT needs and infrastructure -agility -storage -redundancy -cost -on demand -environment

Governance Issues that Should be Considered as IT Environments are Impacted by Cloud Computing

1. Data privacy- enterprises must ensure that access to customer, consumer, and enterprise data is properly identified, monitored, and secured. Service level agreements needed. 2. Regulatory impact- although enterprises may determine that significant savings may be realized by adopting cloud computing platforms, they need to identify/assess the regulatory impact of cloud computing on their environments. Industry regs cause diff concerns. 3. Testing capability- enterprise must ensure that applications can be properly developed according to business rqmts and validated prior to promotion and throughout production, given that the source code, documentation, and IT environment are in the cloud. If you use PaaS, are you able to do approp testing or not? For cloud computing, not a question of it will be done but rather how much to use. 1. IaaS: Infrastructure as a Service. Using others' data centers and infrastructure. 2. PaaS: Platform as a service. Using someone else's developing tools to make your own software. 3. SaaS: Software as a service. ERP systems, SAP, etc. -BPaaS: Business processes as a service. Outsourcing w/ cloud computing service model. Increased automation, less labor, lower costs. Public cloud market has increased a ton since 2008. Internet of Things (IoT)- Basically regular stuff connected to internet (internet fridge, internet baby monitor, etc,) Is regulation on the way? -congress is looking at this, has a working group. -consumers are confident in security of IoT devices, while professionals say security standards are insufficient. -data protection reforms in europe. Have "right to be forgotten," where you can have FB delete info you put on there, have to inform regulators w/in 3 days of data breach, people under 16 need parental permission before using social media, national watchdogs can issue fines on companies misusing people's online data, etc. These rules would extend to any co that has customers in the region (EU), nomatter where it is based. FB and Google are mad about it.

Risks of Cloud Computing

1. Disruptive force: facilitating innovation and cost-savings w/ cloud computing can be viewed as risk events for some orgs. Lowers barriers to entry 2. Residing in the same risk ecosystem as the CSP and other tenants of the cloud: 3rd party cloud solutions mean new dependency relationships w/ CSP are created regarding legal liab, the risk universe, incident escalation, incident response, and other areas. 3. Lack of transparency: CSP is unlikely to divulge detailed info about its processes, ops, controls, and methodologies. May not know where data is stored, how data is segregated w/in the cloud, etc. 4. Reliability and performance issues: system falilure is a risk event that can occur in any computing environment. More challenging w/ cloud computing. While service-level agreements can be structured to meet particular rqmts, CSP solutions might not always be able to meet performance metrics if a cloud tenant/incident puts an unexpected resource demand on the cloud. 5. Vendor lock-in and lack of app portability or interoperability: App software development tools developed by the CSP may create apps that only work w/in the CSPs specific architecture, and might not work well w/ systems outside the cloud solution. Makes it difficult to change providers. 6. Security and compliance measures: must comply w/ regs like SOX and HIPAA, aas well as data privacy regs. 7. High-value cyber-attack targets: consolidation of multiple orgs on a CSPs infrastructure is an attractive hacker target. 8. Risk of data leakage: more risk bc servers and resources are shared btw multiple orgs. 9. IT organizational changes: need fewer IT personnel. Hurts morale. 10. CSP viability: CSP could be young cos or new bus lines. Projected longevity and profitability of cloud services are unknown. Service method and deployment method affect risk because the amount of control corellates w/ risk. Less control w/ SaaS, so more risk. If the deployment method is public, there is less control and more risk. Delivery models from the least to most risky: IaaS, PaaS, SaaS. Deployment models from the least to most risky: private, hybrid, public. Most risky combo is the cheapest, most safe combo is the most expensive. IaaS is a private cloud, SaaS is a public cloud.

Basic Backup Controls

1. Hardware Backups -hot site" location already up and running (just move ops from one facility to another). More expensive. -cold site: location ready for hardware to move in. Like a shell. Cheaper to manage/maintain. Which one you need depends on your bus. 2. Software and data backups: -extent (grandparent, parent, child). At any given time, 3 days of transactions kept. Monday gp, Tues parent, Wed child. If something happens to one of the backups, have other two backups to go to. -frequency (daily) -location (off site). Need to have backup not in same geographical region. Esp for natural disaster. 3. Test the backup: regular tests!

Cloud Service Delivery Models

1. IaaS: Infrastructure as a Service. Using others' data centers and infrastructure. CSP provides virtual data center of resources (network, computing, and storage resources). 2. PaaS: Platform as a service. Using someone else's developing tools to make your own software. Development environments for building/deploying applications. CSP provides customers w/ tools that facilitate the creation of application systems that operate on the CSP hosted infrastructure. 3. SaaS: Software as a service. Applications orgs use to perform specific functions/processes Email, customer mgmt systems, ERP systems, spreadsheets, SAP, etc. -BPaaS: Business processes as a service. Type of SaaS gaining popularity. Entire bus processes (like payroll and supply chain) are outsourced to a 3rd party provider. Outsourcing w/ cloud computing service model- activities outsourced are supported by cloud service delivery solutions. Increased automation, less labor, lower costs. Broadly defined, the cloud is shared IT resources on a network.

5 Cobit Principles

1. Meeting stakeholder needs: COBIT 5 provides all the required processes/enablers to support business value creation through the use of IT. Strategic business/IT alignment that defines and links the enterprise (profit, NFP, and governmental included). Use balanced scorecard with IT related activities to verify whether stakeholder needs are being met. 2. Covering the enterprise end-to-end: COBIT 5 covers all functions and processes within the enterprise, not just IT. Manage IT like an asset. 3. Applying a single integrated framework: COBIT 5 aligns w/ other relevant standards and frameworks at a high level, so can serve as the overarching framework for GEIT. Enables complete involvement of the business mgmt. Other frameworks include Risk IT and Val IT. 4. Enabling a holistic approach: Efficient and effective implementation of GEIT requires a holistic approach, taking into acct the interaction of such components as processes, structures, and people. 5. Separating governance from mgmt: COBIT 5 makes a distinction btw governance and mgmt. Governance= BOD responsibility, mgmt= day-to-day processes. IT governance processes ensure that enterprise objs are met by evaluating stakeholder needs, setting direction through prioritization and decision-making, and monitoring performance, compliance, and progress against plans. COBIT 5 integrates w/ the other frameworks through a high level process mapping included at each process level. Includes previous guidance in its scope, such as Risk IT and Val IT, so that it is a "one-stop shop." COSO is used to guide mgmts assessmnet of I/C for SOX and has no recommendation for IT controls; COBIT is designed to provide managers/users/auditors w/ best practices for IT mgmt. It is compatible w/ COSO, so supports COSO IT model.

Cloud Deployment Models

1. Private cloud: cloud infrastructure is operated solely for an individual org and managed by the org or a 3rd party. Can be on or off org's premises. 2. Community cloud: cloud infratructure is shared by several orgs and supports a specific community w/ common interests (mission, industry collaboration, compliance rqmts). Managed by community orgs or 3rd party and can be on or off premises. 3. Public cloud: cloud infrastructure is available to general public or large industry group. Is owned by an org selling cloud services. 4. Hybrid cloud: cloud infrastructure is composed of 2+ clouds (private, community, or public) that remain unique entities but are bound together by standardized or proprietary tech that enables data and application portability.

Description of SOC Engagements

1. SOC 1: reports here focus solely on controls at service org likely to be relevant to an audit of a user entity's F/S. Performed in accordance w/ SSAE 16. Types of reports: -type 1: report of mgmts description of service org's system and suitability of design of controls to achieve related control objs as of a specified date. -type 2: report of mgmt description of service orgs system and suitability of the design and op effectiveness of the controls to achieve related control objs throughout a specified period. Contains details of tests and results, and is *necessary for SOX*. Based on SSAE 16. SOC 1 reports aren't for public use (restricted use report only for co an its auditors). Highly restricted. SOC 2 and 3 go by the trust services principles and criteria. 2. SOC 2: addresses controls at service org related to ops/compliance. Use at least 1 of the trust services principles: security, availability, processing integrity of system, confidentiality, privacy of info processed by system. Governed by AT101, attestation engagements. Can be type 1 (design) or type 2 (design and op effectiveness). Type 2 also includes description of auditor tests/results (like SOC 1 type 2 report). Also not for public use, generally restricted. SOC 2 reports have an ERM and compliance focus. SOC 1 T2 and SOC 2 T2 are the most common. 3. SOC 3: addresses controls at service org related to ops/compliance. Looks at same things at SOC 2, trust services principles. Governed by AT101, attestation engagements. Diff btw this and SOC 2 report is SOC 2 contains a detailed description of service auditor's tests of controls and results of those tests, as well as their opinion on the description of the service org's system. SOC 3 is a general-use report providing only the auditor's report on whether the system achieved the trust services criteria. Doesn't describe tests and results or give auditor's opinion on the description of the system. Allows SOC 3 seal to be shown on co's website- for customers to see. This is for public (general) use! The main differences are SOC 1 reports on the design/op effectivess of controls at the service org, while SOC 2 focuses on how the controls address security, availability, processing integrity, confidentiality, and privacy. SOC 2 shows the audit report w/ descriptions of tests, results, and opinions, SOC 3 just states whether auditor believes system achieved trust services criteria. Likewise, SOC 1 and 2 have restricted use, while SOC 3 is for public use.

Risks of BYOD

1. Security and compliance: -expose data to misuse, theft, and vulnerabilities. Nonauthenticated devices tethered to authenticated device could access corp network due to interconnection of devices. -since employees update device, more vulnerability to attack. -opens doors to virus/malware injection into corp network. -regs and standards have to be considered before implementing it. 2. Network/support capability and platform compatability: -BYOD can result in lots of additional devices being supported by IT infrastructure and staff. -need enough staff w/ approp skills -mobile device mgmt needs to happen. 3. Financials: -planning, implementation, ops, and scalability could reduce benefit of less CAPEX. -Op expenses may incr since users may want individual data plans and no volume discounts. Also may incr from telecom exp mgmt to track investmt costs in mobility space. 4. Employee privacy: -conflict w/ employee's user experience. -employee's personal data is lost in remote wipe. More: -portability: lose stuff if not encrypted -huge storage capacity: copy large amts of data that can be compromised -data interception and loss over networks -loss of device means remote wipe of data. Also need encryption and strong password. -users can modify security parameters. -may not be able to decrypt info. -nearly impossible to see what data is on the device. -patching/update issues: might not be able to do it all at once. -infrastructure and device: too many technologies to support, 3rd party apps, lack of control over networks and protocols. -security and compliance -devices being compatible w/ each other or org. -Most common use of smartphones for work is email. Attachments in emails can cause data security risks. -lost devices. No easy way for smartphone to connect w/ secure networks w/o running through another program. -can plug smartphones/USBs into other devices and quickly copy data. -co has to pay for it -so is now responsible for maintenance of device. To address data security issues should harden devices (shut down when not in use, turn off unused features). To ensure reg compliance (PCI-DSS, HIPAA, etc.) force updates, can't trust employees to do them. Consider whether your IT team is able to handle the network support, platform compatability, and development of apps.

Why Are Layers of Security Controls Important?

Any one layer alone is insufficient. Want enough layers of preventive controls to delay access to system, giving detective controls time to notice an intruder. Corrective controls can then stop intrusion before major damage occurs. Essentially layers enable the time-based model of security to function. Layers make it take more time for someone to hack the system. ID shows who you are, authentication proves it. After ID and auth, get access rights. Threat assessment should occur about whether this is an auth person or an intruder.

Roles of BOD v Management Concerning IT Security

BOD: -set direction and drive policy -provide resources -set budget -oversee mgmt actions Mgmt: -develop security framework and write security policy (ISMS) -ensure individual roles are clear/accountable -identify threats/responses -establish continual monitoring measures -monitor and review -embed awareness of security needs through training Chief Information Security Officer is Accountable.

BYOD

Bring Your Own Device. Allows IT's customers to use their own devices and mobile applications to enable bus services. Enables org's staff members to connect to the org's network and access official data on their personal devices. Exs: smartphones, laptops, tablets, USB devices for storage, PDAs, digital cameras, RFID, and mobile RFID (anything that isn't a desktop!). Employees buy their own devices and co reimburses them. Co has them on a leash!

Budget and Staff Considerations

Budget: Must understand current/projected budget availability for the term of the strategy. Doesn't necessarily have to align w/ current budget, but considering this helps ensure the alignment of financial guidelines and ensure that the strategy can be viable and credible when presented to leadership. If CFO rejects, you prob don't have a shot... Common mistake is to develop a strategy based on an assumption of a future budget request rather than working w/in the guidelines of projected budget availability. Staff: Level of staffing available for strategy execution. Size strategy based on current/expected staffing capabilties to ensure defined capabilities/obj can be met.

Responsibilities of the CISO in Regard to Value Delivery through IT

CISO= Chief Info Security Officer Responsible for ensuring that a process is in place to identify, evaluate, and prioritize projects that deliver value to the business and minimize managed/unmanaged risks related to process, controls, and tech. CISO specifically must ensure that a value delivery model is in place for info security projects to manage actual costs and maximize ROI.

Effect of Cloud Computing on Risk Assessment

Cloud computing can affect these points of risk assessment: 1. Risk profile: When a cloud solution is adopted, an orgs risk profile is altered due to changes in the likelihood of risks, potential impact of risks, and the inclusion of a subset of the CSP's risk universe. 2. Inherent and residual risk: Depending on the org, the non-cloud computing solutions' inherent/residual risk levels could be greater/less than those of the cloud computing options. 3. Likelihood and impact: likelihood of certain events and the related potential impact often change when cloud solutions are adopted.

Cloud Computing Risk Assessment

Co A provides: SaaS; devleops software. Co A contracts w/ a service provider to get: IaaS. Do SaaS, but don't have the infrastructure for it. Co A's auditor uses the following evidence to conduct a risk-based audit: 1. Risk IT (COBIT 5) 2. Cloud control matrix 3. Cloud computing risk assessment (european institute). 4. National Institute of Standards and Tech standards. Step 1: define COBIT objs and identify areas of high risk. Step 2: develop a risk-based audit program. Relevant COBIT control obj, audit procedure, and findings. Step 3: summarize specific risk and gaps. Step 4: create a heat map and consider whether the level of risk is beyond the cos appetite. Step 5: prioritize risk and take action based on risk appetite. Implement controls. Benefit should outweight the cost of implementing them, otherwise consider transfering, avoiding, or accepting the risk. Step 6: Is IT risk now better aligned w/ the cos overall bus risk and are unacceptable security issues under control?

Implementation Failure Case Study- In Class Exercise

Decide to adopt new IP phone system. Risk factors: -highly competitive industry (their convenience of rental locations, availability/quality of equip, and price are the reason company is competitive). -co is highly leveraged, dependent on maintaining/improving op performance to generate CFs to pay off debt. -co is highly dependent on their automated systems and the internet. Info systems internet-based, most sales transactions processed online or via phone. Implementation issues: -co appeared to be following COBIT before adopting new system. Pilot testing, transaction processing, employee interviews/surveys. -pilot testing revealed some probs, but system is the newest from a well-known vendor. -employees didn't like the system and thought mgmt wouldn't adopt it. -mgmt adopted it. -model that arrived wasn't same as one in pilot. -when it went live, system couldn't handle call volume, crashed. -bandaids applied while bugs worked out, calls often dropped, no control over timing of incoming calls. Vendor is working w/ co to fix this. SD risk factors that should have been red flags: -lack of mgmt involvement (w/o buy in and oversight can become a big prob) -lack of structured approach (should get approval at each step) -size of project (it was big) -type of tech (this was new) -expertise of project team Steps in SDLC w/ biggest probs: -initation: not listening to employees or thinking of user needs. -design: not user driven (users didn't want it and were ignored). -development: didn't do both pilot and parallel testing, just pilot. -implementation.

How Can Continuous Auditing Enhance Governance Frameworks

Defines tech/processes allowing an ongoing review/analysis of bus info on a real-time basis. Allows info system auditors to monitor system reliability on a continuous basis and gather selective audit evidence through the computer. This may become more relevant as businesses become more competitive, cost-concious, and global, and as they seek competitive advantages over others. Continous auditing provides a direct link to the business' risks and IT strategies. Makes sure there are continuous built-in controls embedded in system, like intrusion detection systems.

A log analysis is an example of a: Detective control Preventive control Corrective control None

Detective control.

Explain what an ISRM CMM Scale is used for. What is the meaning of the 0-5 maturity levels?

Developing an information security and risk mgmt strategy. CMM can be used to assess an org against a scale of 5 process maturity levels. Each level ranks the org according to its standardization of processes in the subj area being assessed. Higher is better.

Domain v Process

Domain: Included beneath the Processes. Subdivisions of processes diving them into governance and mgmt domains. Each process has a lifecycle from start to finish, and domains are set up using a lifecycle approach. Process: COBIT 5 processes are split into governance and mgmt areas. Collection of practices influenced by the enterprise's policies and procedures that takes inputs from a number of sources (including other processes), manipulates the inputs, and produces outputs (ie products & services). The EDM domain is the evaluate, direct, and monitor domain- sets out board's responsibilities for evaluating, directing, and monitoring the use of IT assets to create value for the enterprise. This covers setting the governance framework, establishing responsibilities in terms of value (investment criteria), risk factors (appetite), and resources (optimization), and maintaining the transparency on IT to stakeholders. Ex: At governance layer, there a 5 processes in EDM domain that set out the BODs responsibilities for EDMing the use of IT assets to create value.

SOC In-Class Exercise

Example 1: User: any users w/ need for confidence in service orgs controls. Concern: effectiveness of controls at the service org related to security, availability, procressing integrity, confidentiality, and/or privacy. Detail required: require very limited info (boundaries of system and achievement of applicable trust services criteria). *SOC 3*. Example 2: User: user entities (controller's office, SOX compliance office) and F/S auditors. Concern: effect of service org's control on user org's F/S assertions. Detail required: require detail on system controls, tests performed by the service auditor, and results of those tests. *SOC 1, type 2*. Example 3: User: user entities (security compliance, vendor mgmt), regulators, bus partners, others w/ suficient knowledge to appropriately use report. Concern: effectiveness of controls at the service org related to security, availability, processing integrity, confidentiality, and/or privacy. Detail required: require detail on system controls, tests performed by the service auditor, and results of those tests. *SOC 2, type 2*.

How to "Read" Cobit Processes

Find by domain prefix and process no. Process identification includes: -process ID: label (APO13). domain prefix (EDM, APO, BAI, DSS, MEA) and process no (ex EDM1.01). -process name: short description w/ main subj -area of process: governance v mgmt -domain name -process description: high level overview. -process purpose stmt -goal cascade info -Process goals/metrics: set of goals w/ example metrics.

GEIT

Governance of Enterprise IT. Addresses the definition and implementation of processes, structures, and relational mechanisms within the enterprise that enable business and IT staff to execute their responsibilities in support of creating or sustaining business value. This is an integral part of the overall corp governance. This is BOD and executive mgmt responsibility. BOD provides strategic direction to ensure objectives are achieved. Oversees and manages risks, verifies resources are used responsibly. IT governance is a subset of enterprise governance. Enterprise gov is a huge CAPEX (big resource), directly integrates w/ strategies, is a source of huge risks if unmanaged. It's important to appreciate the strategic importance of IT. Goal is to ensure that expectations for IT are met and IT risks are mitigated to approp levels.

Governance v. Management Processes

Governance processes: deal w/ stakeholder governance obj, such as value delivery, risk optimization, and resource optimisation. Include practices/activities geared towards evaluating strategic options, providing direction to IT, and monitoring the outcome. EDM- ensures enterprise objs are met by evaluating SH needs, conditions/options, setting direction (prioritization/decision making), monitoring performance/compliance/progress against agreed upon objs. Mgmt processes: cover the responsibility areas of enterprise IT and provide end-to-end coverage of IT. PBRM- mgmt builds, runs, and monitors activities in alignment w/ direction set by governance body to achieve objs.

DRP at HP the Ayodhya Crisis

HP bus services sites in India. Risk mgmt team responsibly for bus continuity plan. They're good about regularly communicating and doing bus impact analysis. Ayodhya dispute was a BFD. When court annouced its verdict, political riots. All public transportation stopped. Employees couldn't come in on day of verdict and next day. Severe impact since it was month end closure time. Expected impact of transactions being delayed was $100 million. Bus continuity plan: -regularly backup system to combat violence/vandalism. -ensure employee safety, they may not be able to safely come to work. -move key personnel to secure location. -work from home. -backups (on and off site). -more security guards around facilities. -warm or cold site. -reciprocal agreement (if can't work in one facility, go work in another). -cross-training employees to help make up missed work. -shut down center if alarm goes off (fire alarms, broken windows/doors, etc.).

Firm Culture

Important when developing ISRFM strategy in terms of adoption. Adoption won't be as quick/effective if members of org impacted by strategy don't support the implementation. If org has culture w/ open exhange of ideas, consensus activities and open discussion of the strategy will be most effective. If the org has a culture based on leadership directives and alignment w/ those directives, it won't benefit from open discussion/consensus, and should use specific guidance and messaging from senior leadership. A fundamental consideration in ISRM is the cultural change regarding how info protection activities are viewed w/in the org. Info security is often seen as an obstacle to success rather than a benefit b/c many security professionals focus on tech and restrictions to provide protection, which often prevents bus leaders from carrying out activities they see as bus enchancements.

ISRM

Info Security and Risk Management Strategy. Provides an org w/ a road map for info and info infrastructure protection w/ goals and objectives that ensure capabilities provided are aligned to bus goals and the org's risk profile. Needs its own strategy bc it has evolved into a more critical element of bus support activities. Ensures its ability to approp support bus goals and to mature/evolve effectively. Was a part of ERM- included in org's IT risk planning. Now broken out separately. ERM defines the orgs risk profile. Aligning w/ ERM allows bus leadership to be confident that the ISRM strategy is bus enabling (not disabling)

Key Performance Indicators (KPIs)

KPI is a measurable value that demonstrates how effectively a co is achieving key bus objs. Used to measure the effectiveness of functions/capabilities that are developed throughout the ISRM strategy. When developing these, consider the business value intended to be gained w/ the function/capability and define obj criteria used to assess this value. Need thresholds for acceptable/unacceptable limits. KPIs should be aligned w/ point-of-arrival guidelines as well as annual org goals. Monitor value and effectiveness. Help org to understand whether an individual function, as well as the overall org, is operating w/in acceptable tolerances. Example: Number of hacks that occurred, losses from hacks. Error rates in programming. Testing failures in testing. Quarterly sales figures.

Managed Risks v Unmanaged Risks

Managed: Risks that are minimized by mgmt to an acceptable level through careful planning and implementation of processes, controls, and tech. Unmanaged: Risks for which mgmt has not yet implemented processes, controls, or tech to minimize or eliminate the risk.

Legal Ambiguity for Data Stored in the Cloud

Org may be subj to multiple legal jurisdictions depending on where it resides, location of cloud infrastructure, and where the data is stored. There's a lot of ambiguity abt how the cloud computing paradigm fits in the international legal/regulatory environment.

According to the time based model of security (preventive, detective, corrective controls), which of the following equations would indicate effective security? P< D + C D< P + C P> D + C D> P + C

P> D + C

Definition of a Process per Cobit 5

Practice influenced by the company's policies and procedures that gathers inputs from a variety of sources, manipulates them, and produces outputs in the form of products and services. Practices specific to a company that convert inputs into product/service outputs.

Issues with Program Changes, Purchased Software, and OSS

Program changes: These are frequent in occurrence. May ignore adequate testing or be lacking in documentation. Lack of training could also be an issue. Migration issues, parallel and pilot testing required heavy user input when they already have day jobs. These often result from "emergencies." Still need SDLC processes, which are destroyed by poor controls! Should still be documenting everything (that change gets approp approval and if it gets tested again to see if it fixed anything). Purchased software: variety of options created for a multitude of situations. Controls can be optional or overriden. Need compatibility w/ IT infrastructure. This is often a user-driven decision w/ no IT involvement, and vendors have control of future changes. More issues include too much customization (more risk) which makes upgrades/support difficult and expensive. Purchased software isn't error free. Still need SDLC process. OSS (open source software): This is "free" software and you can go in and edit it any time (Moodle). Lacks vendor support, so isn't really free if you don't know what you're doing. May need to pay for your own consultants or need to train employees. Also not free because of future support/maintenance costs.

RACI Chart

Responsible, accountable, consulted, and informed. Suggested assignment of a level of responsibility for process practices to diff roles and structures. Prevent confusion by assigning clear oship for tasks/decisions. Matrix of all the activities/decision making authorities in an org against all the people/roles. At each intersection of activity/role it is possible to assign someone responsible, accountable, consulted or informed for that activity or decision. Responsible- person who does task, must get job done. Acctable- person ultimately acctable for task being completed right. Responsible ppl acctable to this person. Consulted- people not directly involved in doing task, but consulted. Could be stakeholder or subject matter report. Informed- those getting output from task or who have a need to stay informed.

SDLC is Both an ITCG and IT Governance Issue

SDLC= Systems Development Life Cycle. Could involve developing an application from scratch or customizing a larger, more complicated application (like SAP). Definition and maintenance of bus functional and technical rqmts. Issue for both bc it affects all parts of the IT systems. Poor documentation, testing, etc. leads to week controls. If the system isn't tested properly, then a working control could be weakened, or new risks introduced. ITGC because it looks over the entire organization and IT Governance because the board assigns resources and aligns the system with strategic objectives. Size of project is relevant- large projects require BOD approval. Need a structured approach to SDLC because it ensures consistency and allows for better implementation. Steps and activities of SDLC: 1. Systems analysis: Key obj of this phase is to conduct prelim. analysis, propose diff solutions, descr costs/benefits, and submit a prelim. plan w/ recommendations. Defines project goals into defined functions and ops of the intended application. Process of gathering/interpreting facts and diagnosing info needs. Also removes inconsistencies/incompleteness in those rqmts. -initiations: driven by users/bus processes. Identify obj of project, decribe prob to be solved ("what" issue) through prob documentation and program change request form, get bus line mgmt approval before submission to IT. Bigger changes need approval from Sr mgmt/BOD and IT steering. Everything must be documented/approved before moving on. For approved projects to be considered for feasibility there needs to be a creation of a project team of IT and key users. -feasibility: Assess IT infrastructure needs, driven by IT strategic plan/governance. Assess non-IT infrastructure needs, driven by key bus line mgmt. Measure costs/benefits by identifying hard, tangible costs v. soft costs. Soft costs include consultants, training systems, maintenance over time, etc. Documentation required includes decription of analysis and key mgmt approvals to proceed/stop project. Think about legal feasibility (meet legal stds?), operational feasibility (can be op/maintain it over time?), and scheduling feasibility (can it be implemented in a timely manner that the co can handle?). 2. Design: physical system is designed here w/ help of logical design prepared by system analysts. Analysts/designers work together and use certain tools/software to create overall system design and prob output. Still user/bus process driven need. Need integration w/ IT infrastructure issues. Focus on translation of user needs to IT specs (using an ERD diagram), and describe how system will be built/implemented. Documentation includes details of user specs and approvals of final design plans. Design is essentially the blueprint for a system. 3. Development: heavily involves programmers/customizers of purchased software. Work is typically subdivided in sub-phase called task allocation (each developer is assigned a part of the work depending on their skillset to complete coding efficiently). Need structured/standardized programming approach. Restricted access should be given to test copies only, and transfer to live production should be prohibited. Constant creation of programming audit trail and interaction w/ key bus line users. Focus here on testing (pilot v parallel) and creating test data (hypothetical v actual). Converting blueprint into real system. Pilot= implement to subset of users, parallel= roll out bits and pieces alongside existing system. Need both. Pilot helps find bugs, but doesn't allow you to test full volume of the system. Testing is often where things go bad, due to poor testing or insufficient amounts of testing. Programmers should never use live data! Focus on developing implementaton guidance in the form of user/operator procedures. Constant documentation of everything, including multiple approvals. There is involvement of IT quality assurance and internal audit here, with the focus being on adequate testing and compliance w/ the proj plan. 4. Implementation: Actually rolling out system. Focus on implementation plan. Actual SDLC procedures are applied to conversion, including data integrity and converting data. Formal implementation plan should consider how the timing will affect the bus operating cycle, the key players, training, back-out strategies (roll back to last update), parallel processing (roll out while old system is still going) , and the archiving policy for the old system. Documentation of key approvals for implementation. Store it twice! 5. Evaluation:Think abt if system meets bus rqmts and objs, if it's reliable and fault-tolerant, if it functions according to approved functional rqmts. Should assess effectiveness of development process and improve it (relfect and address weaknesses). Off-site storage of documenation for all programming, ops, actual sofware, user procedures, and testing data/results. Want more training and formal post-implementation review. Monitoring/adapting component here.

Which of the following SOC reports is appropriate for SOX compliance? SOC 1 Type 1 SOC 1 Type 2 SOC 2 Type 1 SOC 2 Type 2

SOC 1 Type 2

Which SOC reports are for public use? SOC 1 SOC 2 SOC 3 All

SOC 3.

Containerization

Segregates corp and personal data for storage on user's devices. One container for work, one for personal. No communication btw the profiles. Device integrity is checked before containers start, which reduces the risk to corp data. Also, the container w/ the corp data can be independently wiped w/o accidentally wiping the personal content of the employee. This doesn't work on all operating systems (iOS doesn't support). Also workflow and productivity may be affected and certain apps may be able to access data they shouldn't. App wrapping is a security implementation that basically wraps itself around the app and protects the program/app. Stops security threats immediately. More secure but also affects performance and slows productivity. App wrapping can be for the device as a whole or per application. If wrapped, access to other things on the device may be blocked. Email and calendar issues- do you want to maintain calendars?

Capability Maturity Model (CMM) Assessment

Simple and effective scale that an org can use to understand quickly which of its capabilities are functioning adequately and which need improvement to incr efficiency, reduce cost of operation, and incr value to the org. Can benchmark CMM assessment against other orgs w/ similar CMM methodology to understand level of capability/effectiveness compared to peers and competitors. CMM can be used to assess an org against a scale of 5 process maturity levels. Each level ranks the org according to its standardization of processes in the subj area being assessed. The subj areas can be as diverse as software engineering, systems engineering, proj mgmt, risk mgmt, system acq, IT services, and personnel mgmt. Higher on scale is better, so want a 5. Provides a way to benchmark where you are against others.

Elements of an Effective BYOD Program

Strikes a balance btw user-centric and device-centric strategies. Stakeholders, including customers, org functons (IT, HR, sales, legal, marketing), leadership, and exec board must all be involved in policy framing to avoid loopholes and ambiguity. -define clear/inclusive BYOD policy -focus on securing data-in-transit and at-rest (encryption for storage and only use VPN- virtual private network, i.e. encrypted tunnel- or SSL when accessing/storing data). -ensure compliance -develop/manage list of supported platforms and devices -equip the staff -consider investing in mobile apps development -ensure that corp network infrastructure is capable of meeting BYOD demands -include decommissioning as part of BYOD policy -use an affirmative contract for policy agreement (pretty much takes away employee's rights). -data certification (only allow ceritifed devices to be used on network). -proper anti-virus and security patches must be updated. -user ID when accessing the devices.

Affect of Cloud Service Delivery Model on Direct Control of the Technology Architecture

The amount of control retained over the tech architecture is dependent upon the selected CSD model. When org owns/manages its own facilities, it has control of apps, virtual machine, server, and storage. When using IaaS, org has control of apps, shares control of virtual machine w/ a vendor, and vendor has control of servers and storage. When using PaaS, org shares control of apps and virtual machine w/ vendor and vendor controls server and storage. When using SaaS, vendor controls all. Basically most control to least: self managed/owned, IaaS, PaaS, SaaS. When owning/managing, control all. When using IaaS or PaaS, control some. When using SaaS, control none.

Risk with Sourcing

Third parties can't assume org's risks, so org will always be responsible b/c they are the entity through which bus is transacted and must provide approp level of info security and risk mgmt. Lots of orgs dont realize that they can't transfer risks to a third party, even though they use third parties to provide ISRM capabilities. Sourcing can be an effective tool to accelerate the implementation of capabilities.

AICPA Service Organization Controls

This guidance is for CPAs (auditors of service orgs who report on the controls of a service org relevant to ICFR and trust services framework). Service orgs offer services to other orgs... some sort of task. Accting firms, payroll cos, medical billing, etc. Other cos outsource to these to perform functions for them. Risks of service org become risks of user org when service orgs provide critical processes. Increasing risks at service orgs led to new standards.

Time-Based Model of Security

Want to delay access to information using preventive controls to give detective and corrective controls time to work. The more time it takes to hack the system, the more likely it is that the hack will be detected. Preventive control ex: -Remote access controls: Firewall. Router. Intrusion prevention system. Hardening. -Physical access controls: Locks on doors, locked comp equipment, card keys, biometric security systems. Secure buildings (locks on doors/windows), security guards, cameras, electronic and metal detectors. Perimeter controls include restricted acess to building. -Logical access controls: Electronically restricting users (passwords- strength/storage), complimentary objects (badges, card keys, terminal keys), biometrics (fingerprints, retinal scans, facial scans), securing communications (encryption), securing online access (firewalls, virus protection). Others: Verification processes. Coding spreadsheet so can only enter numbers in date field. Detective control ex: log analysis. Intrusion detection systems. Bank recs. Mgmt auth. Inventory counts. Periodically testing effectiveness of existing security procedures. Corrective control ex: computer emergency response team (recognize, contain, recover, follow up). Insurance. Patch mgmt (fix known vulnerabilities. Keep up to date patches and virus control. Preventive and detective too). Define/communicate security incidents so they can be classified and treated. Corrective action S/B timely. Embed oship/acctability for IT risks at senior level w/ CISO. Security monitoring considers: -evidence of org security plan (prereq or afterthought?) -reg evaluation of security risks (nature of intrustion attemps and system failures) -use of global/specific policies (tracking latest best practices). -assignment of security responsibilities (is it clear who is responsible/acctable?) -intrustion testing (active attempts to gain unauth access)