Leveraging Change Control for Security

Jeff Lawson, TripwireGeoff Hancock, Advanced Cybersecurity Group

Cybersecurity and IT Change Management2016 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”.

FOG OF MORE

IT SECURITY & COMPLIANCE AUTOMATION7

Definition of Configuration Management :

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

8

Key challenges of Configuration Management

• Complexity • No formal change control process• Silos that separate security from IT operations teams• “If it ain’t broke don’t fix it” approach• Little or no documentation • Reconciliation • Lack of automation

9

Cybersecurity gaps in the organization can be correlated into a number of factors

• Disparate systems with no oversight or joined up management• Slow change management leading to processes being

circumnavigated, ignored or no joined up decision-making• Security not built in, but bolted on after the event

10

Cybersecurity gaps in the organization can be correlated into a number of factors

• Legacy thinking rather than agile planning• Poor succession planning for legacy platforms• Lack of security process maintenance• Management out of the loop with corporate protection

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.

13 TRIPWIRE PROPRIETARY & CONFIDENTIAL. NOT FOR DISTRIBUTION

Elements of Successful Change Management

14 TRIPWIRE PROPRIETARY & CONFIDENTIAL. NOT FOR DISTRIBUTION

Elements of Successful Change Management 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 TRIPWIRE PROPRIETARY & CONFIDENTIAL. NOT FOR DISTRIBUTION

Elements of Successful Change Management 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

Elements of Successful Change Management

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

Business Impact of Change Management

18

Its not the tools you use it’s the process you manage. It’s not the tools you use;

it’s the process you manage.

HELPING YOU MANAGE THE PROCESS

Tripwire Enterprise And Change

20

The Great DisruptorA Necessity To Conducting Secure and Agile Business

21

Detect ChangeHow Can You Manage What You Don’t Know?

22

Reconcile ChangeHow Can You Validate Without A Source?

23

Respond When NeededBe A Hero, Know When And How To Fix Outages

24

Solution ValuesIn Short, There Is No Doubt

25

Change Is EverywhereDon’t Be Caught With The Wrong Bag

tripwire.com | @TripwireInc

Thank You

27

Questions AnswersThe 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.

Though not a traditional use case in change management, the way business are operating in agile modes and the need for DevOps processes is certainly making this more popular. Version control is most certainly done using tools and processes for the code and libraries used in deployment. Yet those version control systems are just like any critical application you may have within your environment: They all have access controls, configuration files, APIs, and security holes. Using configuration management for version control tools keeps them secured as possible, protecting the integrity of what you are storing.

What Change Management Systems does Tripwire Integrate with?

Tripwire Enterprise has an event integration framework in place to pass information back and forth between virtually any change management or ticketing system (CMS). The most common implementations are Remedy, ServiceNow, Jira and the level of such integration can go as fine-grained as you need. With a 2-way data integration, you can both automatically promote/approve changes in Tripwire Enterprise that were part of planned changes or tickets within your CMS and create tickets for changes that were detected that did not match what was expected or were not part of the plan. This adds value to both sides of the solution.

Can you provide some use cases or scenarios for BAU tasks?

From what I have seen, Business As Usual (BAU) with Tripwire and Change Control is generally characterized as an easy way to promote changes detected in environments where change is constantly occurring via a set of tasks. A great example I have seen is Development environments where code is being pushed via automated tools such as Puppet/Chef. You still want to have the historical information of the change for Incident Response/Auditing, but spending time doing very granular change control does not make sense. Instead you are to reduce the noise by dictating, users, groups, processes, etc. that are “allowed” as a BAU process. There are absolutely risks with this approach, but it is a good step to maturity.

When a change was made, how can you tell who made the change?

With Tripwire Enterprise, the installed Agent can listen in on events being produced at the OS level. This gives us many advantages over tying in with OS Auditing and correlation. 1) We collect the user account associated with the change as the change occurs, guaranteeing the information is there 2) We also collect process information at the same time to correlate who did it with what process was used to accomplish the task 3) We can pick up most changes in real-time, without having to run heavy weight scans 4) Our technique is has a very small overhead compared to native OS audit logging

28

Its not the tools you use it’s the process you manage. APPENDIX

Some extra things to consider…

29

Its not the tools you use it’s the process you manage.

Top Five Things To Do

CIS 20 Critical Security Controls

30

• Accurate 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.

• e.

Key components to a change management program.

31

Customer and/or Client ImpactHigh (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 ImpactHigh (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 ComplexityHigh (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 ChangeHigh (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

SecurityHigh (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 ImpactHigh (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