Leveraging Change Control for Security
Download as PPTX, PDF0 likes1,539 views
The document discusses the critical issue of misconfigured IT systems as a primary vulnerability leading to significant cybersecurity breaches, supported by various reports and case studies, including the 2016 OPM breach. It emphasizes the importance of establishing effective configuration management processes, monitoring, and governance to minimize risks associated with IT changes. Lastly, it outlines a risk assessment framework for evaluating the impact of changes on resources, security, and service levels in organizational settings.
Leveraging Change Control for Security
- 4. 2016 DBIR noted that miss-configured IT systems were the route that hackers took to exploit IT systems across thousands of companies. In 2015 PWC report indicating that “poor system configurations were the cause of major breaches”, in a survey they conducted of over 1000 IT and Cybersecurity professionals. OPM Breach 2016. Inspector General & Congressional Oversight committee report that “OPM wasn't even sure of what it had on its network”. "OPM does not maintain a comprehensive inventory of servers, databases, and network devices”. HP Cyber Risk Report. “Server misconfigurations were the number one vulnerability”. “Over and above vulnerabilities such as privacy and cookie security issues, server misconfigurations dominated the list of security concerns, providing adversaries unnecessary access to files that leave an organization susceptible to an attack”. 2015-States responsible for IT configuration of IT Systems. “Misconfigured database has led to the disclosure of 191 million voter records”.
- 7. The ability to create, edit and manage IT security hardening policies in a way that fits real-world business processes and continually balances risk and productivity
- 11. CYBERSECURITY CONFIGURATION CONSIDERATIONS Ensure change control processes cover desktops, servers, networks, applications, databases. Invest in automated capabilities to assess, monitor, and enforce. Leverage dynamic white-listing to ensure applications and system remain compliant and secure.
- 12. CYBERSECURITY CONFIGURATION CONSIDERATIONS Continuous monitoring of all change requests can help prevent system downtime, compliance violations, and increased risk exposure. A single management platform pulls together all change control process and policy information, delivering a more efficient and effective change management program. Centralized management of security, compliance, and change control process significantly lowers total cost of ownership.
- 14. Planning Identify/Assessment of High Value Assets System mapping Service mapping ID current and future state configurations Prioritize the most important systems, how they are configured and what other systems they are connected to Internal systems External systems
- 15. Governance • Establishing appropriate organizational structures • Roles and responsibilities • Engage stakeholders • Support the change effort Business impact and value of current configurations • Tie business services to key systems, their use and configurations
- 16. Implementation • Identification of needed changes from old and new systems Operations • Monitor, update and secure each system (the process) Evaluate business risk • Impact of both doing and not doing the change • Analyze timing of the change to resolve any conflicts and minimize impact
- 17. Evaluate business risk (cont.) • Ensure all affected parties are aware of the change and understand its impact • Determine if the implementation of the change conflicts with the business cycle • Ensure current business requirements and objectives are met
- 27. Questions Answers The Onion? Seriously? Well, not quite seriously. The story, though published in the Onion, was meant to show just how far cyberwar has come…far enough to make fun of it! How is version control integrated into configuration management in a DevOps environment? Really two sides to this coin – having configurations that are prebuilt: gold images, recipes/scripts where those configurations are under version control is probably the first use case. Version control gives you the fine grained ability to see and control change, but it does not give you the ability to compare those configurations under control to a secured standard or internally created policy. Here, configuration management can help keep those version controlled items at a state that is secure and known to work properly, and alert when changes to them open up risk.
- 30. Documentation – Identify the information relevant to a specific change that needs to be collected throughout the change management process. • Continuous Oversight – Change Advisory Board (CAB) The CAB is tasked with balancing the need for change with the need to minimize risks. • Formal, Defined Approval Process – All changes will follow the established multiple level approval process to ensure routine changes are completed with minimum restrictions while complex, high impact changes receive the oversight necessary to guarantee success. • Scope – Establish the specific areas that this policy will cover. Examples include Payroll and HR Applications, E-Commerce and Store Applications, Purchase Applications, Supply Chain Applications, Accounting and Business Applications, Logistic Applications groups. Also included are all changes associated with the Software Development Life Cycle (SDLC) program, hardware and software changes.
- 31. and/or Client Impact High (4) – Impacts several internal and/or external customers, major disruption to critical systems or impact to mission critical services. Moderate (3) – Impacts several internal customers, significant disruption to critical systems or mission critical services. Low (2) – Impacts a minimal number of internal customers, minimal impact to a portion of a business unit or non- critical service. No Risk (1) – No impact to internal customers, as well as no impact to critical systems or services. Risk levels
- 32. IT Resource Impact High (4) – Involves IT resources from more than two workgroups and crosses IT divisions or involves expertise not currently staffed. Moderate (3) – Involves IT resources from more than two workgroups within the same IT division or involves expertise that has limited staffing. Low (2) – Involves IT resources from one workgroup within same IT division. No Risk (1) – Involves a single IT resource from a workgroup. Risk levels
- 33. Implementation Complexity High (4) – High complexity requiring technical and business coordination. Moderate (3) – Significant complexity requiring technical coordination only. Low (2) – Low complexity requiring no technical coordination. No Risk (1) – Maintenance type of change Risk levels
- 34. Duration of Change High (4) – Change outage greater than 1 hour and affecting clients during Prime/Peak times. Lengthy install and back-out. Moderate (3) – Change outage less than 1 hour during Prime/Peak times or greater then 1 hour during Non-Prime times. Low (2) – Change outage less than 1 hour during Non-Prime times and affecting clients during Non-Prime times. No Risk (1) – No outage expected. Risk levels
- 35. Security High (4) – Affects critical data or server security and the back-out would likely extend the window timeframe. Moderate (3) – Affects non-critical data or server security and has a moderate back-out plan which would not extend window timeframe. Low (2) – No security issues and easy back-out plan. No Risk (1) – No back-out plan needed. Risk levels
- 36. Service Level Agreement Impact High (4) – Impacts SLA during business Prime/Peak times. Moderate (3) – Impacts SLA during business Non-Prime times. Low (2) – Little measurable effect on SLA times. Risk levels