Change
Change management- anything used to govern like policies, procedures, and recorded a change in an organization
Occurs because of initiated within or outside the organization. It will impact IT infrastructure.
Scope can vary from routine like software updates or initiative to overhaul an organizations core.
Either way we need to look at potential risk and minimize adverse consequences.
Steps to help a company chart its path of change from inception to implementation
•identify and define the need for change
•design a high level plan
•obtain approval from management
•develop a budget
•assign personnel
•identify and address potential risks that could occur during the change or post implementation
•provide an implementation road map
•procdure necessary resources and train appropriate personel
•test system change
•execute
•review and monitor change and verify what needs to continued to be tested
Types of environments: segregated environment
•development environment: software programmers write code and can put it in without risk. Typically a source code editing tool is created and modified code syntax, automatic tools that have preconfigured code and a debugging tool to help fix errors.
•Testing environment: developers test and debug code to identify errors that need to be corrected
could be separate or one environment
•staging environment: organization can test programs in their final phases, intended to test functionality, compatibility, security, and performance prior to the deployment
•Production environment: application is deployed and made available to the end users
•Disaster Recovery environment: organization set up a disaster recovery environment to ensure that applications can be restored quickly, save critical data and systems, notify management, and recover in the event of an outage or attack.
Risks of Managing Change: are present in all steps of change and can affect existing systems, employees, and processes.
Types of risk:
•selection and acquisition risk: new IT resources is a fundamental area in which risk exists in the change of management process happens with
lack of experience or perspective,
lack of formal selection and acquisition process
software/hardware is vulnerable and incompatible
Can be mitigated by controls, AICPA recommends service org perspective (annual risk assessment, appropriate change management plan) and service auditors (obtain and inspect tha annual risk assessment performed and inspect a sample of the system change requests to determine whether the proper change management process was used)
•Integration risk: will the software integrate into the system and process mechanically and people wise. Happens with
User resistance
Lack of Management support
lack of stakeholder support
resource concern
business distruption
lack of system integration: Frankenstein system
•Outsource risk: budget or expertise
outsourced party doesn't understand the org
lack of expertise
lack of security
SOC2 engagement: service auditors should refer to the AICPA trust service criterion which recommends service organizations have policies and practices in place that properly authorize, design, develop or purchase, configure, document, test, approve, and implement change to the companies infrastructure, data, and applications.
Orgnaization should perform an annual risk assessment process that evaluates the economic, regulatory, and physical environment, industry, competition, and consumer dynamics, how new lines of business can affect internal controls, mgmt attitude to internal control, change in tech environment, partnership with vendors and other businesses
-did management do it right the first time?Sample system change to see if management did it right.
Controls to mitigate risks: step 2 after identifying risk. Done to mitigate disruptions.
Main categories of controls:
•policies and procedures
•emergency change policies
•standardized change requests
•impact assessments: analysis documenting the effect of a change will have on the organizations business activists as well as any potential disruptions that will help prepare and org for successful change implementation
•authorization: has appropriate level of authorization
•separation of duties
•Conversion controls: migration from an existing system or process to the new ones, so this will help minimize data conversion errors related to impacted IT assetss and resources
•Reversion access: when changes don't work out its good to have the ability to revert to the prior system, through parallel implementation in which an organization maintains two environments at the initial onset of change, one with the change implemented (development environment) and one without the change implemented (production environment)
•pre-implementation testing: we want to make sure before deployment everything is okay
•post-implementation testing
•ongoing monitoring
Documenting system controls:can help with trouble shooting, training and education, improve system performance. Should be implemented and tested with multiple components
steps:
•baseline configuration:allows benchmarks which is useful for patterns and evaluation. Establishes a starting point for reconfigurations so that changes are deployed in a consistent and secure enviorment.
checklist, provides a linear path so managers cantrack
baseline image
system uptime, ideally
resource utilization, ideally increased
failover time ideally minimized
•System component inventory: like hardware, software etc that would include the purpose of the component, location, current status, and whether its functioning properly. Can be used to track repairs, updates, replacements, guide to trouble shooting
Acceptance criterial of change: should be measurable (quantitative or qualitative) and specific and adequately documented, tested, and approved, and evaluated to review and monitor.
Examples:
•performance: both
•complieance: yes/no
•functionality: qualatitive
•scalability: quantitatively
Testing and implementing change control policies
Types:
•Logging: helps see whether it is followed
application logs: when employee accesses, executes funcation
change log: tracks requests, approval, and implementation ( can help with reversion)
event logs:
directory logs provides data on events involving Active Directory which is related to authenticating users, governing privileges for uses and the device that acccess AD
DNS server logs. Contain information and source and destination IP addresses, query and response detail, time stamp, and error
Endpoint log: more related to device
Security event logs: shared security system recourse like shared folders, printers, and files
System logs: record events like when a system is started, rebooted, or updated.
firewall log: keep tracks of all traffic
network log/perimeter log: provides intelligence from devices on a wider scale
proxy log: control internet access and enchanted performance for users
•monitoring: brings accountability, ability to troubleshoot, and tools for identifying and solving problems. Could be done by requiring authentication, audit trails
•Testing using continous adoption: automatically created, tested and deployed. regularly merging changes to their code in a central repository in which they automate building and testing code which helps identify bugs faster, enhance application quality,and shortens the time needed to release software updates.
risk of bugs in code, can't do complex well and needs standardized testing.leg work at the front end.
•Unit testing; refers to the process of examining the smallest increment or unit of an application to focus on the individual details
•Integration testing: follows unit testing, brooding views, helps plan for future maintainer or updates
•system testing: full, widest scope that application is working as designed. May be evaluated by quality assurance to discover ay material defects prior to releasing the final product
•acceptance testing: part of overall quality assurance to make sure the application helps the end users.
Results:
System administrator should evaluate the results of testing the design and implement ion of change control policies
•review written change management policies, confirm policies are kept up to date, and with proper acceptance and documentation
•proper sequence of events
Managing Change in a System:
common IT change management methodologies
•waterfall model: flows in one direction, sequential, teams are secretly working in sequence. Time consuming, benefits at the end, have to backtrack if error, idle time.
plan, analyze, design, develop, test, deploy, maintain
•agile model: not sequential, "there has got to be a better way", cross functional teams. Emphasizes deadline, communication, change, and feedback.
backlog (growing and shrinking to do list), planning, development, customer review, record and incorporate change
Patch management: systematic process of identifying specific vulnerabilities or software bugs in operating systems or applications and addressing them with patches
•reactive:
•proactive: using a vulnerability tool
Effective patch management processes include testing patches in test informant. Many customers regularly schedule patches but that can be exploited.
SOC 2: AICPA recommends maintaining a documented patch management process to meet its trust service criteria regarding properly authorizing and implementing changes to meet company objectives. Service auditors testing related controls should inspect the service organizations policies and procedures to determine whether they include rules on patch and change management.
System Conversion Methods: we are deciding to replace something
Smaller companies tend to be more aggressive, while larger companies are more cautious.
Different conversion methods:
•direct: direct changeover method. Risk is new system does not work.
•parallel: the new system is brought online and old system is still in use. Downside is that requires more time and effort but mitigates risk of old system not working
•piolet: org performs a conversion on a small scale in test environment while using old system. Allows adjustments to be made before implemtation.
•phased implementation: gradually changes over time.
•hybrid: combination
Change Management Testing Strategies: every system should be tested or else there will be functional issues or security vulnerabilities. helps determine errors or isn't operating as expected.
Steps:
•establish a testing plan, including roles, responsibility, and time line
•identify and prioritize the key areas of the software to test
•determine which type of test to run and specify the test objectives
•evaluate
•log and identify defects
•fix defects in timely manner
Change advisory board: will help adequately plan and respond to change. approve change, document, notify, and deploy.
they consider testing, staging, production, separation of duties
Good controls:
•automatic notifications
•code repository tools so that it changes can be aggregated, reviewed, approved, and implemented
•inventory of what happened so rollback can happen
•controls to make sure rollback happened properly
Test change of each
validating sampling in which only a small subset is tested