INF526: Secure Systems Administration Response Planning · INF526: Secure Systems Administration....

INF526: Secure Systems Administration

Response Planning

Prof. Clifford Neuman

Lecture 722 February 2017OHE100C

Class Presentation Schedule2/8 Miles Wright-Walker - Developing adversarial security plan2/15 Matthew Jackoski - Red Teaming / Pen Testing Tools 2/22 Abdulla Binkulaib - Developing a response plan3/1 Jikun Li - Linux security administration3/8 Daniel Dmytrisin - Network security components & Tech 3/22 Haibo Zhang - Network Security administration3/29 Mariam Fahad Bubeshait - Configuration Management4/5 Mohammed Alsubaie – SIEM and Intrusion Detection4/12 Vishnu Vadlamani - Network Monitoring/Attack Forensics4/19 Andrew Gronski - Accreditation and acceptance testing

1

Response Planning

What are you responding to?– All failures, security or reliability– Some parts of the plan will be similar– Other parts will depend on the nature of the failure

We start with Disaster RecoveryThen we move onto intrusion response

2

Disaster Recovery Planning● Business Continuity Plan (BCP)● IT Disaster Recovery Plan (IT DR Plan)● IT DR Plan vs BCP● Terminology● How to write an IT DR Plan● Backup Strategies● Replication Technologies

3

Material by Vini GuptaMS Student Summer 2016

Business Continuity Plan• The processes and procedures that are carried out by an organization to ensure

that essential business functions continue to operate during and after a disaster.• This type of planning enables them to re-establish services to a fully functional

level as quickly and smoothly as possible.• BCP mostly covers Non-IT aspects of business.• It includes identification of the resources that are needed to maintain the

business continuity, such as:– Critical personnel– Key business processes– Recovery of vital records– Critical suppliers identification– Contacts of key vendors and clients.– Standby Equipment– Legal Help– Financials– Alternate infrastructure– Alternate accommodation, etc.

4


IT Disaster Recovery Plan • A plan that provides a structured approach for

responding to unplanned incidents that threaten an IT infrastructure, which includes hardware, software, networks, processes and people.

• Key reasons for implementing an IT DR Planare to protect:– the organization’s investment in its technology infrastructure– the organization’s ability to conduct business

5


Disaster Recovery vs Business Continuity

6


Terminology1. Recovery Point Objective (RPO) - The interval of time that

might pass during a disruption before the quantity of data lost during that period, exceeds the BCP’s maximum allowable threshold or ‘tolerance’.

2. Recovery Time Objective (RTO) - The duration of time and a service level within which a business process must be restored after a disaster in order to avoid unacceptable consequences associated with a break in continuity.

3. Key Performance Indicator (KPI) - A measurable value that demonstrates how effectively a company is achieving key business objectives

7


How to Write a DR Plan

8


Selecting the Team• Identification of key personnel (contact information) and

their roles.• Non-ambiguous chain of command.• Determination of responsibility for each role.

Mostly, the DR teams fall under the supervision on CIO or Senior IT Manager (known as Recovery Team Head), but there are other roles too:

– Business Continuity/Disaster Recovery planning expert– Business unit/operations stakeholders– Network and Infrastructure delivery– IT systems and services– Other support staff as needed

9


Next Steps1. Risk Identification2. Assess Vulnerability3. Determine Impact

Risk Assessment and Business Impact Analysis

10


4. Identify Critical Business Functions and Services

• Definition and analysis of RTOs and RPOs.• Thinking about services, not IT assets.

11


• Chord Diagrams – Display

connection between services and assets

– Color and Width –Stated Recovery time

• Thin green –instant

• Thick orange –a week

5. Design and Implement Mitigation Strategies

• Thinking beyond recovery of services• Analyzing factors important for restoration:

– People, facilities, suppliers, replication and backup

12


• IT Resilience Maturity Model

– Asks around 10 questions and measures the standard of existing technologies and processes that are plugged into BCP.

– The tool models the responses on a radial chart.

– Maturity rating can be compared with a

– model of responses from peers, SMEs and

– organizations in highly regulated industries.

6. Agree on Activation Plans• Generate a runbook, documentation for the plan.

– For use by management who will take the actions.– It should be descriptive and spell out its assumptions

• While stored securely, one should assume others may know what it contains, and this could be used by adversaries. Don’t include critical passwords, etc.

• Should spell out who is to be contacted, including any mass notifications.

• Should be specific, get general enough to cover multiple kinds of incidents.

– E.g. chapters for IT failure, power failure, hacked systems.

13

7. Testing• Plan should be tested for efficiency.• KPIs should be formulated, along with testing

strategies and corresponding testplan.• Metrics should be recorded and analysed for:

– Test coverage ?– Success ?– Meeting the recovery objectives ?

• Full disaster recovery test, at least once per year.• Analysis should be documented..

14


8. Updates and Maintaining the Plan

• Your systems change and so must the plan• If there are changes to the control systems

your plan must be updated.• Schedule a review quarterly to see if any

changes require updates to the plan.• Review teams, activities, and update

documentation of plan.

15

Backups and Replication• Backups

– Full Backup - full and complete backup of the entire system.

– Incremental Backup - only archives data that has been modified that day.

– Differential Backup -storage of all the files that have changed or been added since last full backup...

16


Differential vs Incremental• Differential Backup

– More files to be backed up, therefore takes more time and uses more storage space.

– Faster restoration because only the last full backup and the last cumulative backup must be applied.

– More manageable with lesser number of disks.• Incremental Backup

– Fewer files to be backed up, therefore faster backup less storage– Restoration takes longer because all the backup disks are used.– Difficult to manage and maintain with larger number of disks.– High risk of whole chain becoming unrecoverable if any disk corrupted.– Testing of backup every time would be costly and time-consuming.

• Incremental may be preferred for cloud backup– Less data to transfer, clear recovery points.

17


ReplicationProvides backup process for immediate failover• Synchronous

– Writes data to primary and secondary sites at the same time.– It’s expensive.– Introduces latency, slows down the primary site.– Preferred for applications with low RTOs (Recovery Time Objectives) that can’t

abide data loss.• Asynchronous

– There’s a delay before the data is written to secondary site.– Designed to work over distances and use less bandwidth.– There is a risk of losing data during an outage.

• Journaling– Basically an incremental backup (per transaction)– Replayed from journal and last image of system when restarting.

18


Replication TechnologiesArray Based

– Compatible storage arrays use built-in software to automatically copy data from one storage array to another.

– Works both synchronously and asynchronously, replicating data between similar storage array models at logical unit number (LUN) or volume block level.

– Drawback - lack of heterogenous support.– Example: EMC MirrorView

Host Based– Practice of using servers to copy data from one site to another.– Usually file-based and asynchronous.– For efficiency and security, includes capabilities such as deduplication, compression, encryption

and throttling.– Cheapest and easiest.– Example: CA XOsoft, Double-Take software, InMage System Scout, Neverfail

Network Based– Requires additional device, either an intelligent switch (EMC RecoverPoint and FalconStor

continuous Data Protector (CDP) ) or an inline appliance (IBM SAN Volume Controller (SVC) or LSI Corp’s StoreAge Storage Virtualization Manager (SVM) ).

– ● Works both synchronously and asynchronously

19


Reference on Recovery• http://www.databarracks.com/• https://tools.databarracks.com/• http://www.disasterrecovery.org/• http://www.standbyconsulting.com/continuity-planning/bcp-vs-drp• http://everyday-tech.com/disaster-recovery-plan-templates-and-sample-documents/• https://www.youtube.com/watch?v=OUzlPZn5n6E• http://searchdisasterrecovery.techtarget.com/feature/IT-disaster-recovery-DR-plan-template-A-free-

download-and-guide• http://www.druva.com/blog/understanding-rpo-and-rto/• https://www.klipfolio.com/resources/kpi-examples• https://www.rackspace.com/en-us/disaster-recovery-planning/resiliency• http://searchdisasterrecovery.techtarget.com/tutorial/Data-replication-technologies-and-disaster-

recovery-planning-tutorial

20


Intrusion Response PlanningWhat is an intrusion or incident?

– An action likely to lead to grave consequences especially in diplomatic matters

– Consequences can affect company revenue andbusiness

– Incident examples• Virus• Malicious code• Trojan horse• Espionage

21

Material by Reshma RavindranMS Student Summer 2016

Incident Response PlanResponse: An act of responding. Something constituting a reply or a reaction.

– The activity or inhibition of previous activity of an organism or any of its parts resulting from stimulation

– The output of a transducer or detecting device resulting from a given input.

– Action taken to prevent or recover from an intrusion occurrence or breach.

22


Relationship to Policy• Security policy defines what it means to be

secure for a system, organization or other entity. For an organization, it addresses the constraints on behavior of its members as well as constraints imposed on adversaries by mechanisms such as doors, locks, keys and walls.

• Response planning is the next phase of security policy implementation, documenting actions to be taken in the inevitable case an intrusion occurs.

23


Sample ScenarioTime: 20:13

A V.P. is giving a party at home. Decides to show off new web site.

While viewing corporate leadership page V.P. notices certain pictures of persons (including V.P.) and bio information have been modified to be less than favorable.

24


Information to Gather• Time and date reported (specify time zone)• Name of contact.• Phone number and/or email of contact.• System suspected to be affected.• Technical details of system if known.

– IP address(es), OS, patches loaded,– physical location, services running,– suspected access point (vulnerability).

• Time and date ‘incident’ noticed by contact.• Description of incident.

25


Scenario ContinuedTime: 20:20

Helpdesk finishes entering information into log.Helpdesk verifies that page has been modified.Per security policy all incidents affecting the company in a ‘Public’ manner are considered Priority 1.

Time: 20:21Helpdesk reviews POC list and calls the Security Manager’s pager.

This specific SecManager insists on notification of all Priority 1’s.Another approach would be an on call security member that updates the Manager after reviewing situation.

26


Scenario ContinuedTime: 20:27

Helpdesk reviews POC list and calls the Security Manager’s pager.After being updated of current situation SM requests helpdesk to contact NT server on call person and have him meet him at office in 30 minutes.SM gets ready for a late night at the office.

Time: 20:30Helpdesk checks POC list and calls on call SA.Helpdesk explains basic situation to SA.SA assures he is getting ready to go.

27


Scenario ContinuedTime: 2100

SA and SM meet at server room.Quick discussion of current assets reveals that there is a backup server available with recently loaded OS, services, and patches.SA begins process of restoring data from backup tape while SM begins process of bit by bitcopy of compromised server.

Time: 2300SA finishes restoring webserver data and verifies that data restored has not been manipulated.Since current backup policy states full backups at 0100 every day this gives a roughly 18 hour window for the data manipulation to have occurred.SA brings new server online and updates logs for Incident.

28



Good news! Through the diligent work of the SA and SM information was found that showed that the data was manipulated at 1957 by a dial in account.This shows that the incident may have remained unseen by public.Further review of online web defacement authorities (attrition.org) shows no mention of defacement.

Time: 0800Coordination with HR reveals that the owner of the account had recently been passed over for a promotion.Normally that user account would not have rights to the webserver directories but an earlier update to the server created a hole for internal users.The SA quickly reconfigured file access for server and closed hole.

29



Coordination with HR, Legal, and the employee’s direct supervisor showed that due to previous poor work record and misconduct it would be in the best interest of the company to terminate the employment of the individual in question.

Conclusion:Due to proper procedures and quick response of all personnel involved the incident was quickly contained, resolved, and business returned to normal.Communication and coordination is especially important in Incident Response.Any break down in the chain can cause the entire process to fail.

30


Formal Intrusion Response Plan• Overview• Purpose• Incident Response Goals• Incident Definition• Incident Planning• Incident Response Lifecycle

31


Overview, Purpose, Goals, Defintion• The incident response plan defines what constitutes a

security incident and outlines the incident response phases. how information is passed to the appropriate personnel, assessment of the incident, minimizing damage and response strategy, documentation, and preservation of evidence

• The policy is designed to protect the organizational resources against intrusion.

• Incident Response Goals:– Verify that an incident occurred.– Maintain or Restore Business Continuity.– Reduce the incident impact.– Determine how the attack was done if the incident happened.

32


Incident Definition• Loss of information confidentiality (data theft)• Compromise of information integrity (damage to data or unauthorized

modification).• Theft of physical IT asset including computers, storage devices,

printers, etc.• Damage to physical IT assets including computers, storage devices,

printers.• Denial of service.• Misuse of services, information, or assets.• Infection of systems by unauthorized or hostile software.• An attempt at unauthorized access.• Unauthorized changes to organizational hardware, softwaare, or

configuration.• Reports of unusual system behavior.• Responses to intrusion detection alarms.

33


Incident Response Planning

• Define roles and responsibilities• Establish procedures detailing actions taken

during the incident.– Detail actions based on type of incident such as a virus,

hacker intrusion, data theft, system destruction.– Procedures should consider how critical the threatened

system or data is.– Consider whether the incident is ongoing or done.

34


Incident Response Life Cycle

35


Preparation• Policies and Procedures

– Computer Security Policies -These involve many policies including password policies, intrusion detection, computer property control, data assessment, and others.

– Incident Response Procedures– Backup and Recovery Procedures

• Implement policies with security tools including firewalls, intrusion detection systems, and other required items.

• Post warning banners against unauthorized use at system points of access.• Establish Response Guidelines by considering and discussing possible

scenarios.• Train users about computer security and train IT staff in handling security

situations and recognizing intrusions.• Establish Contacts -Incident response team member contact information

should be readily available. An emergency contact procedure should be established. There should be one contact list with names listed by contact priority.

• Test the process.

36


Detection Analysis• Analysis and Assessment -Many factors will determine the

proper response including: Is the incident real or perceived?

• Is the incident still in progress?• What data or property is threatened and how critical is it?• What is the impact on the business should the attack

succeed? Minimal, serious, or critical?• What system or systems are targeted, where are they

located physically and on the network?• Is the incident inside the trusted network?

37


Recovery• Restore affected systems to their original state. Be sure to preserve evidence

against the intruder by backing up logs or possibly the entire system. Depending on the situation, restoring the system could include one or more of the following re-install the affected system(s) from scratch and restore data from backups if necessary. Be sure to preserve evidence against the intruder by backing up logs or possibly the entire system.

• Make users change passwords if passwords may have been sniffed.• Be sure the system has been hardened by turning off or uninstalling unused

services.• Be sure the system is fully patched.• Be sure real time virus protection and intrusion detection is running.• Be sure the system is logging the correct items

38


Recovery (2)• Documentation -Document what was discovered about the incident including

how it occurred, where the attack came from, the response, whether the response was effective.

• Evidence Preservation -Make copies of logs, email, and other documentable communication. Keep lists of witnesses.

• Notifying proper external agencies -Notify the police if prosecution of the intruder is possible.

• Assess damage and cost -Assess the damage to the organization and estimate both the damage cost and the cost of the containment efforts.

39


Post Incident• Review response and update policies -Plan and take preventative steps so the

intrusion can't happen again. Consider whether an additional policy could have prevented the intrusion.

• Consider whether a procedure or policy was not followed which allowed the intrusion, then consider what could be changed to be sure the procedure or policy is followed in the future.

• Was the incident response appropriate? How could it be improved?• Was every appropriate party informed in a timely manner?• Were the incident response procedures detailed and cover the entire situation?

How can they be improved?• Have changes been made to prevent a re-infection of the current infection?

Are all systems patched, systems locked down, passwords changed, anti-virus updated, email policies set, etc.?

• Have changes been made to prevent a new and similar infection?• Should any security policies be updated?• What lessons have been learned from this experience?

40


Prioritization• To help prioritize the timing and resources needed to deploy corrective action,

resource proprietors and resource custodians must assess the impact of a security incident based on the following factors:

• How the incident will impact existing functionality of the affected systems

• Whether the incident breaches the confidentiality or integrity of covered data (Protection Level 2) or non-covered data

• How much of the user population is affected by the security incident

• What’s the reputational/financial impact to organization

41


Example – Berkeley IR Plan

42


Tools for Incident Response• Digital forensic workstations21 and/or backup devices to create disk images,

preserve log files, and save other relevant incident data• Laptops for activities such as analyzing data, sniffing packets, and writing reports• Spare workstations, servers, and networking equipment, or the virtualized

equivalents, which may be used for many purposes, such as restoring backups and trying out malware

• Blank removable media• Portable printer to print copies of log files and other evidence from non-networked

systems• Packet sniffers and protocol analyzers to capture and analyze network traffic• Digital forensic software to analyze disk images• Removable media with trusted versions of programs to be used to gather evidence

from systems• Evidence gathering accessories, including hard-bound notebooks, digital cameras,

audio recorders, chain of custody forms, evidence storage bags and tags, and evidence tape, to preserve evidence for possible legal actions

43


Additional Tools• One of the most important resources required for incident response,

are system logs. Logs are normally kept individually in each network device. Products such as netForensics, Contegoor ArcSight, may be considered for this process

• Another important tool to consider is computer forensics and security software. When an incident is suspected, forensics software allows you to take a snapshot of a system, capturing and preserving live data, such as, local data storage, open ports, system registry and a RAM dump. Tools involved in this are Encase Enterprise , acessdata FTK etc.

44


The CIRTThe CIRT is a group consisting of employees with expert knowledge from various departments. Not only are Information Technology staff needed to handle incidents from the technical aspect, CIRT members should include key staff from many areas of the organization.

– Information Security– Help Desk– Telecommunication– Legal/ audit– Public media relations– Human resources– Physical security management– Management

45


Industry Response PlansEducation:

UCSD - http://blink.ucsd.edu/technology/security/CIRT/index.html

Berkeley - https://security.berkeley.edu/incident-response-planning-guideline

USC Payment related - https://policy.usc.edu/files/2015/05/Appendix-C-PCI-Incident-Response-Plan.pdf

FinancialSANS Guidelines - https://www.giac.org/paper/gsec/3902/incident-response-planning-smaller-financial-institutions/106243

VISA - http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/downloadabledocuments/incidentresponse.doc

AICPA - http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/downloadabledocuments/incidentresponse.doc

46


http://blink.ucsd.edu/technology/security/CIRT/index.html

https://security.berkeley.edu/incident-response-planning-guideline

https://policy.usc.edu/files/2015/05/Appendix-C-PCI-Incident-Response-Plan.pdf

https://www.giac.org/paper/gsec/3902/incident-response-planning-smaller-financial-institutions/106243

http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/downloadabledocuments/incidentresponse.doc

http://www.aicpa.org/interestareas/informationtechnology/resources/privacy/downloadabledocuments/incidentresponse.doc

Group Exercise One

• Decide on the software components to be deployed to implement software requirements on next slide.– Custom development should be simple scripts.– Use packages for database and other components.

• Decide on the VM’s to be created to run those software components.– You can run more than one software component within a VM if you

choose.– Decide on the methods you will use to contain access to those software

components, and to the information managed by those components.• Configure communication between VM’s and to the outside• Install packages• Write scripts and demonstrate basic flow through system.• Report on progress as group now by email on Tuesday 7 Feb.

47

Banking• Your organization must:

– Maintain a database of account holders– A database of account balances– Enable web access by customers who:

• Can update their personal information• Check their account balance• Transfer funds to another account (by number)• View transactions on their account• Submit an image of a check for deposit

– (check should be viewable, but you do not need to scan it or process it)

• Access is needed– Via web from the open internet– Outbound email confirming transactions– All other interactions may be limited by information flow policies

to internal machines.

48

Connecting to VMs• VNC – Virtual Network Computing

– Install TightVNC or other Client on machine from whichaccess is attempted.

– Install and configure VNC server on Virtual Machine– A VNC Server can be run inside your VM, or in the hypervisor

• Inside the VM is likely easier• Portmapping a must

– Find the IP using dynamic DNS– But multiple VM’s on a shared NAT need to be mapped manually to

different ports.• We are trying to gain access to a server under which you can

run VM’s which you would connect to the same way you would here, via VNC– Address mapping would be easier.

49

INF526: Secure Systems Administration Response Planning · INF526: Secure Systems Administration....

Documents

Transcript of INF526: Secure Systems Administration Response Planning · INF526: Secure Systems Administration....