©20

14 C

lifton

Lars

onAl

len

LLP

©20

14 C

lifton

Lars

onAl

len

LLP

CLAconnect.com

Incident Response and Forensic PreparednessTSCPA Expo

Michael Nyman, CPA, CISA, CISSP, CRISC, CIITPCliftonLarsonAllen LLPInformation Security Services

©20

14 C

lifton

Lars

onAl

len

LLP

Our perspective…CliftonLarsonAllen– Started in 1953 with a goal of total

client service– Today, industry specialized CPA and

Advisory firm ranked in the top 10 in the U.S.

2

©20

14 C

lifton

Lars

onAl

len

LLP

3

Agenda

• Cyber Crime Trends

• Incident Response components

• Common mistakes

©20

14 C

lifton

Lars

onAl

len

LLP

4

Learning Objectives

1. Recognize the current risk environment 2. Obtain an understanding of the fundamentals of responding

to a computer security incident3. Obtain an understanding of types of data that may be critical

to investigating an incident4. Understand some common mistakes that organization’s

make

At the end of this session, you will be able to:

©20

14 C

lifton

Lars

onAl

len

LLP

Security is a Business Issue, Not a Technical Issue

5

People Rules

`

Tools

Definition of a Secure System:“A secure system is one we can depend on to behave as we expect.”

Source: “Web Security and Commerce” by Simson Garfinkel with Gene Spafford

• Confidentiality• Integrity• Availability

©20

14 C

lifton

Lars

onAl

len

LLP

CliftonLarsonAllen – Mike Nyman• Mike Nyman

– Alphabet Soup– IT Controls / Security– Softball– Scoutmaster– Dad

©20

14 C

lifton

Lars

onAl

len

LLP

Boy Scouts, IT Professionals, & Incident Handling

• Boy Scouts

– Be Prepared

– Mountain Man

Rendezvous Trip

Preparation

– Road Trip!!!

7

©20

14 C

lifton

Lars

onAl

len

LLP

Boy Scouts, IT Professionals, & Incident Handling

• Mountain Man Rendezvous– R BAR C Scout Ranch– Daily Routine– Business as Usual…

8

©20

14 C

lifton

Lars

onAl

len

LLP

Boy Scouts, IT Professionals, & Incident Handling

• Boy Scouts

– Knife

9

©20

14 C

lifton

Lars

onAl

len

LLP

©20

14 C

lifton

Lars

onAl

len

LLP

CLAconnect.com

Cyber Crime Trends

©20

14 C

lifton

Lars

onAl

len

LLP

• City finance office• Mining company• Small CU ( ~$120M)• Catholic church parish• Rural hospital• Health care trade association• Collection agency• Main Street newspaper stand• Large CU (~$1.8B)

• On and on and on and on……………..

What do the following have in common?

11

©20

14 C

lifton

Lars

onAl

len

LLP

Three Reasons Why We Should Care

• Organized Crime– Wholesale theft of personal financial information

• Payment Fraud – Corporate Account Takeover– Use of online credentials for ACH, CC and wire fraud

• Hackers are targeting you!– A variety of cash out schemes

12

©20

14 C

lifton

Lars

onAl

len

LLP

Norton/Symantec Corp – The Cost• Norton/Symantec Corp.• Cost of global cybercrime: $114 billion annually.• Time lost due to cybercrime an additional $274 billion. • Cybercrime costs the world significantly more than the

global black market in marijuana, cocaine and heroin combined ($288 billion).

Hackers go for the “easy money” Credit union members are much easier targets than the

banks themselves

13

©20

14 C

lifton

Lars

onAl

len

LLP

Hackers, Fraudsters, and Victims • Opportunistic Attacks

• Targeted Attacks

14

©20

14 C

lifton

Lars

onAl

len

LLP

Hackers and Fraudsters• Objectives…

– Identity Theft and Account Hijacking◊ Phishing Identity theft and fraudulent credit◊ ACH fraud Corporate Account Take over's

– Targeted Attacks◊ Internal access for privilege escalation (“control systems”)◊ Corporate/Government Espionage - Mass data theft◊ Access to Intellectual Property (IP) or Financial Information◊ Targeted “Corporate Account Take Over”

– System Access for “Processing Power”◊ Bot Nets

15

©20

14 C

lifton

Lars

onAl

len

LLP

Phishing and ACH – Examples• Church ($29,000 and $32,000)• Public School District ($110,000)• County Hospital System ($150,000)• Trade Association ($1,088,000)• Manufacturing Company ($348,000)

Security Breach

• Credit Union Heartbleed• Credit Union Member “cash out”

16

©20

14 C

lifton

Lars

onAl

len

LLP

©20

14 C

lifton

Lars

onAl

len

LLP

CLAconnect.com

Incident Response

©20

14 C

lifton

Lars

onAl

len

LLP

Defining an Incident

• What is an incident– NIST 800-61 Rev2 - “A computer security incident is a

violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.”

• How does your response plan define an incident?

18

©20

14 C

lifton

Lars

onAl

len

LLP

Types of Incidents

• External – Email Phishing– Malicious Website– Website hacking– Social Engineering

• Internal– Malicious Insider– Rouge IT employee– Issues with vendors/service providers– External party physically intruding

19

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 1 - Church

20

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 1

• Background:– A Church’s internal network and internet banking account

was breached

– $30,000 fraudulent ACH payroll transaction was submitted via online banking and processed by the bank

– The organization’s workstation was infected with the Zbot Trojan through a “DocuSign” phishing email appearing to come from administrator@<organization>.org

21

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 1

• Lessons learned– No incident response plan

– No communication protocol

– Lack of employee awareness

– Lacking Segregation of Duties/Excessive Access

22

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 1

• Lessons learned– Weak network controls

◊ Shut down system – lost running memory◊ Server logging was not enabled◊ No formal IT support◊ Excessive spam containing malicious attachments and

links◊ No web content filtering system

• Don’t panic! Assess the situation first and maintain documentation!

23

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

• Develop an incident response policy and plan – Management should support the mission– Consider and define the following:

◊ Scope of the policy and plan◊ Computer security incidents◊ Roles and responsibilities◊ Prioritization (tie back to BIA)◊ Performance measures◊ Reporting and contact forms

24

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

• Develop incident response procedures– Establish lines of communication with internal and

external sources◊ Staff◊ Board◊ Examiners/Regulators◊ Law enforcement◊ Media◊ Vendors ◊ ISP

25

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

• Develop incident response procedures– Define and develop a team

◊ Determine capabilities of team members

– Consider other supporting groups◊ Legal◊ Human Resources◊ Media Relations◊ Outside (consulting) support

26

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

• Develop incident response procedures cont…– Documentation requirements

– Post incident response review – what can we improve on?

– Perform incident response procedure testing◊ Table top exercises◊ Simulations

– Establish a training program for IR team and employees

27

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

Incident Handler Communications and Facilities• Contact information for team members and others within and

outside the organization (primary and backup contacts)

• On-call information for other teams within the organization, including escalation information

• Incident reporting mechanisms, how to report incidents; at least one mechanism should permit people to report incidents anonymously

• Issue tracking system for tracking incident information, status, etc.

28

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

Incident Handler Communications and Facilities• Smartphones to be carried by team members for off-hour

support and onsite communications

• Encryption software to be used for communications among team members, within the organization and with external parties; for Federal agencies, software must use a FIPS-validated encryption algorithm20

• War room for central communication and coordination;

• Secure storage facility for securing evidence and other sensitive materials

29

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61Incident Analysis Hardware and Software:• Digital forensic workstations 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

30

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

Incident Analysis Hardware and Software:• 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

31

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

Incident Analysis Hardware and Software:• 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

32

©20

14 C

lifton

Lars

onAl

len

LLP

Incident Response Fundamentals – NIST 800-61

Incident Analysis Resources• Port lists, including commonly used ports and Trojan horse

ports • Documentation for OSs, applications, protocols, and intrusion

detection and antivirus products • Network diagrams and lists of critical assets, such as

database servers • Current baselines of expected network, system, and

application activity • Cryptographic hashes of critical files22 to speed incident

analysis, verification, and eradication

33

©20

14 C

lifton

Lars

onAl

len

LLP

Be Prepared• Documentation…

– Network diagrams

– Application diagrams and flow charts

– System inventories

– Locations and types of event logs available for analysis

34

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 2 – Public School District

http:// mytime-ufa.ru/images/nacha_paychange[.]html

35

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 2

• Employee clicked on a phishing email appearing to come from the National Automated Clearing House Association (NACHA)– Embedded link resolves to a Russian IP address

• Employee’s internet banking credentials were compromised

• Employee’s browser was injected with malicious HTML asking for additional confidential information when they visited the internet banking site– Employee also received a call from supporting actor in the

attack36

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 2

• Attacker initiated approximately $125,000 in fraudulent ACH transactions

• The “weird call” prompted the employee to call the bank and transactions were stopped

• Additional information:– Employee indicated to IT that anti virus logs were reporting

malicious activity the day before the malicious transaction activity

37

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 2• Lessons Learned

– No incident response plan (trend?)– Lack of employee awareness (trend?)– Lacking segregation of duties/excessive

access (trend?)– IT indicated the employees system was

“clean” – this was not the case– Lack of log retention– System was powered off

38

©20

14 C

lifton

Lars

onAl

len

LLP

Critical Data in an Incident

• System’s directly impacted – Employee indicated they clicked on email– AV logs indicate malicious files– Weird activity

• Logs– Server and workstation logs– Internet banking logs – detail is key!– Firewall– AV logs– IDS/IPS logs– Network packet capture

39

©20

14 C

lifton

Lars

onAl

len

LLP

Critical Data in an Incident

• System memory– In both cases described above, the system was powered

off…critical evidence was lost– Think before you pull the plug, don’t panic

◊ Why are we pulling the plug?◊ What data may be lost?

– Train employees on what to do if they think they have malware on their system

• Journaling – write everything down in detail• Other

– Video surveillance– Alarm and door logs 40

©20

14 C

lifton

Lars

onAl

len

LLP

Critical Data in an Incident

• Vendor systems - critical data may reside here!– Inventory where your data resides

◊ What data do vendors store, process, transmit?◊ What systems are used for wires, ACH, bill pay, etc…?◊ What happens if the data on those sites are compromised or

fraudulent transfers are approved?◊ What does the contract say?

– Do the vendor systems that control your data or money log ALL activity?

41

©20

14 C

lifton

Lars

onAl

len

LLP

©20

14 C

lifton

Lars

onAl

len

LLP

CLAconnect.com

Common Mistakes

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 3 - Hospital

• Finance person is phished• Employee’s internet banking credentials were

compromised• Fraudulent ACH payroll files totaling over $150,000

are sentLaw enforcementIndependent investigations (two of them…)Problems with investigation…Closing call to compare investigations

43

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 4 – Trade Association• Finance person receives “2000 spam

messages”• Later in the day, fraudsters make three

ACH transfers all within 30 minutes:– $8,000 to Houston– Two transfers for $540,000 each to Romania

• In this case, business insists the following controls were not followed:– Dollar limit/thresholds were exceeded– Call back verification did not occur

• Lessons learned…44

©20

14 C

lifton

Lars

onAl

len

LLP

Case Study 5 – Credit Union (Last Week)• Malware on the network • Windows domain credentials created• Core application credentials hijacked• Member accounts modified• “Cash” deposit at branch

– After close of business– Associated w/ employee who was not working that day

• $ Mule attempts to withdraw funds the next day

45

©20

14 C

lifton

Lars

onAl

len

LLP

Sources for Standards and Guidelines

• NIST 800-61: Computer Security Incident Handling Guidehttp://www.nist.gov/customcf/get_pdf.cfm?pub_id=911736

• PCI Requirementshttps://www.pcisecuritystandards.org/documents/PFI_Program_Guide.pdf

• SANS/GIAC Certified Incident Handler http://www.giac.org/certification/certified-incident-handler-gcih

• State laws:http://www.privacyrights.org/data-breach#10

46

©20

14 C

lifton

Lars

onAl

len

LLP

Conclusion

• Develop a mentality of:– “If (and when) this happens to us, we’ll be ready to

respond…” Not:– “This will never happen to us…because <fill in the blank>”

• Practice…

47

©20

14 C

lifton

Lars

onAl

len

LLP

Questions?

Hang on, it’s going to be a wild ride!!

Mike Nyman, Senior Manager

Information Security Services Group

Michael.nyman@claconnect.com

***(602)604-3524

©20

14 C

lifton

Lars

onAl

len

LLP

©20

14 C

lifton

Lars

onAl

len

LLP

CLAconnect.com

Thank you!

Michael Nyman, CPA, CISA, CISSP, CRISC, CIITPCliftonLarsonAllen LLPInformation Security Services

©20

14 C

lifton

Lars

onAl

len

LLP

References

• NIST SP800-61– http://csrc.nist.gov/publications/drafts/800-61-rev2/draft-

sp800-61rev2.pdf

• FFIEC Cybersecurity Guidance– https://www.fdic.gov/news/news/financial/2014/fil14021.html

• Verizon Breach Analysis Reports– http://www.verizonenterprise.com/DBIR/2014/

©20

14 C

lifton

Lars

onAl

len

LLP

NIST 800-86Supporting Forensics in the Information System Life Cycle • Performing regular backups of systems and maintaining previous

backups for a specific period of time

• Enabling auditing on workstations, servers, and network devices

• Forwarding audit records to secure centralized log servers (SIEM)

• Configuring mission-critical applications to perform auditing, including recording all authentication attempts

51

©20

14 C

lifton

Lars

onAl

len

LLP

NIST 800-86Supporting Forensics in the Information System Life Cycle • Maintaining a database of file hashes for the files of common OS

and application deployments

• Using file integrity checking software on particularly important assets

• Maintaining records (e.g., baselines) of network and system configurations

52