CYBERSECURITY PENETRATION TESTING - INTRODUCTION

Transcription

1 CYBERSECURITY PENETRATION TESTING - INTRODUCTION

2 Introduction Pen-testing 101 University Focus Our Environment Openness and learning Sharing and collaboration Leads to Security Weaknesses

3 What is Penetration Testing?

4 What Is Penetration Testing?

5 Why do Penetration Testing?

6 Attacker Profiles

7 Script Kiddies (Minor)

8 Hacker Group (Minor)

9 Criminal Organization (Major)

10 Patriot Hacking (Major)

11 Nation State Cyber Terrorism (Major)

12 Hacktivist(Moderate)

13 Hacktivist / Criminals? (Moderate)

14 Black Hat Professional (Moderate)

15 Vulnerability Assessment / Penetration Testing

16 Vulnerability Testing / Assessment

17 Vulnerability Testing / Assessment

18 Penetration Testing

19 Vulnerability Assessment NOT = Penetration Testing

20 Types of Penetration Tests

21 Types of Penetration Tests

22 Whitelisting

23 Penetration Testing

24 Reconnaissance

25 Reconnaisance What is available out there about you. csoe Intended / developed for Humor In part two. Less benign samples

26 Scanning

27 Gaining Access

28 Maintaining Access

29 Clearing Tracks

30 CYBERSECURITY PENETRATION TESTING EXPERIENCE CONFIDENTIAL

31 Agenda RFP Phase 1 (Assessment) Results Phase 2 (Penetration) Results Where do we go from here?

32 RFP Phase Penetration Testing at UVic Approach Phases Lessons

33 Penetration Testing at UVic Why Internal Audit? Client: Audit Committee Scope: University Wide/Multi-Jurisdiction

34 Approach RFP for Specialists Defined Attacker Profile (Moderate) Double Blind / Black Box / Remote Contracted Specialists Phase 1 - Vulnerability Assessment (inc. Social Engineering) Phase 2 - Penetration Testing

35 Phases Phase 1: Using a double-blind / black box approach, the proponent will employ all possible non-disruptive and non-destructive means of identifying vulnerabilities in the UVic environment that would allow penetration past UVic s defences (information security and cultural) and allow an attacker to gain access to the core financial systems and/or personal (employee, student, or member of the public) information. Interlude Phase 2: Within a defined scope, the proponent will perform an ethical (white hat) hack to perform a minimal disruption and non-destructive penetration with the objective of gaining evidence of access to core financial systems and/or employee, student or member of the public personal information

36 Select an Attacker Profile Establishes scope and context for RFP Defines how communications regarding the project will be handled Allows nature and extent of vulnerability scans and tests to be defined Establishes scope and context for assessing and reporting results

37 Be Very Specific in Your RFP Due to potential legal concerns with inadvertently scanning non-uvic information resources a number of proponents declined to submit responses or failed to meet selection criteria in this respect

38 Set Clear Rules of Engagement Vulnerability scanning can break systems or cause unexpected problems Rules of Engagement: What can be touched and what cannot Inside or outside Business Hours Who to contact when things go wrong

39 Involve Information Security Trusted IT Staff Member Part of the Audit Team A team member who Knows what we are likely to break Knows who we might need to inform Is supportive of the testing Is able to stick handle Can tell us if we broke something

40 Phase 1 (Assessment) Social Engineering Whitelisted Vulnerability Scanning Perimeter Defense Testing Lessons, Lessons, and More Lessons

41 Phishing

42 Common Phishing Example

43 Social Engineering

44 Social Engineering

45 Social Engineering Results 4 hours 838 phishing s sent 99 viewed, 49 responded nn sets of valid credentials obtained 1 unreported download of a Trojan Horse *** nn% compromise rate Statistically, not a great Detected/reported within minutes Shut down within a few hours

46 Trust Your Penetration Tester Do a thorough background check Select a trusted vendor Because they may gain access

47 Whitelisted Vulnerability Scanning Not feasible to scan every IP on network 3,000+ IP s targeted Assets of high value Assets of low awareness/visibility Representative Sample Whitelisted attacker Avoided assets where disruption would have a high negative impact

48 Vulnerability Scanning Results 3,260 Systems, 1000 top attack vectors 323 (10%) had vulnerabilities. Risk = Vulnerability (likelihood) Consultant report Consequences (impact) our analysis False Positives

49 Do or Don t: Whitelisting? Attackers wouldn t be whitelisted Moderate attackers would attack from behind the perimeter defence Or use Stealth to circumvent detection And actually don t do vulnerability scans

50 Perimeter Defense Testing Four series of Tests, no Whitelisting Payload Detection Needle in a Haystack Everything Plus the Kitchen Sink Lost in the Crowd Proved that the firewall doing its job Which is great against minor attackers

51 Do or Don t: Stealth Scanning? A stealth (detection avoidance) approach to vulnerability assessment carries significant cost implications and an undesirable engagement duration and is not how an attacker in our moderate range tends to attack the organization

52 Do or Don t: Stealth Scanning? There were benefits to whitelisted scanning (patch management validation) but it didn t prove much. Stealth scanning passes perimeter defences And interestingly finds new things

53 Other Test Elements Detection and Reporting of Security Incidents Effectiveness and Efficiency of Responding to a cyberattack Weaknesses in distributed (self managed) systems

54 Distinguish Between Scanning and Assessment Scanning is well. Scanning; seeing if ports respond Assessment is testing to see if a potential vulnerability is responsive We upset people with our terminology!

55 Involve General Counsel Because sometimes well intentioned internal staff take matters into their own hands in somewhat unexpected ways Even when policy and procedures would lead us to believe they would act in a different way

56 Be Prepared for Minor Disruption Unexpected disruptions occur during vulnerability assessments As staff react to these as security incidents, communication is needed to calm down the situation Such communications should be drafted in advance

57 Be Prepared for Mea Culpa In a partly distributed, multi-jurisdictional IT environment It s important to accept ownership for the impact of the engagement And get all fingers pointing squarely at us

58 Assess Organizational Responses It s not just about the technical vulnerabilities It s an opportunity to see how the organization reacts to unexpected events And potentially identify some areas for improvement

59 Look at Response Mechanisms Originally we just wanted to see if we were vulnerable but assessing organizational reaction and response was actually more interesting - Social Engineering - Incident Response and Internal Communication - Incident Attribution

60 Inform Staff of Perimeter Testing For additional testing of perimeter defences Tell people when testing will start and when testing will end Just in case a real attack happens at the same time

61 Involve System/Business Owners in Risk Evaluation Technical vulnerability does not = business risk you need to assess the real business impact risk. Fixing vulnerabilities will be an organizational / unit exercise

62 Share What You Learn Keep track of learnings for any future engagements and Share internally Share externally

63 Safeguard Findings Even When Reporting When discussing vulnerabilities in a multijurisdictional environment principle of least privilege applies It takes a swack of effort to only tell people about their systems perhaps we could have outsourced this a bit better

64 Keep Vulnerability Reporting Relevant Do not waste (anyone s) time and effort on low risk vulnerabilities and especially on informational items After going to the extent of testing rather than scanning, potential false positives were not helpful they were just annoying Exclude items with no appreciable risk factor or no solution.

65 Recognize You Can t Win Even when you tell people what s going on they may not believe you and auditors are scary people no matter what we do to try and generally people don t know we exist or what we do anyway

66 Put a Non-technical Wrapper Around the Technical Details Vulnerability scans are not the sorts of things most people can read or want to read vulnerabilities need context the why do I care factor And we wanted Board clarity but also educational awareness

67 Perform Follow-up Testing A Vulnerability Test in not a one-time event Ensure remediation is effective Look for new vulnerabilities The Auditors Mantra: Trust, but Validate

68 Phase 2 (Penetration) Social Engineering Check (Phase 1) Vulnerability Mitigation Validation Privilege Escalation SpearPhishing More Lessons

69 Engagement Differences Technical Components Vulnerability Mitigation Validation Privilege Escalation People Components Social Engineering Check SpearPhishing

70 Social Engineering Check From our original compromised accounts, some were still active in the UVic Domain Did they change their passwords like we requested? Surprise Some Didn t

71 Vulnerability Mitigation Validation Retested 26 of the highest risk hosts from Phase 1 Undertook stealth scanning and found even more issues than when whitelisted Tried to exploit vulnerabilities Nothing to Report

72 Privilege Escalation

73 Privilege Escalation Created an isolated target desktop Activated the compromise Attacker tried to compromise desktop standard protection Nothing to Report

74 SpearPhishing

75 SpearPhishing

76 Reconnaisance 9iC9I After Questions. A bit more far fetched?

77 SpearPhishing Exercise The Target (image deleted)

78 SpearPhishing Exercise

79 SpearPhishing Exercise

80 SpearPhishing Exercise

81 SpearPhishing Exercise The Target (sorry, image still deleted)

82 SpearPhishing Results Targets were Institution Leaders nn hours 90 SpearPhishing s sent nn responded nn submitted credentials nn submitted valid credentials 1 person not on our list gave credentials nn% compromise rate

83 Sacred Cows Displeasure with Internal Audit Perfect example of real SpearPhishing Phishing Not = SpearPhishing Are some organizational elements untouchable?

84 The Weakest Link

85 The Weakest Link

86 Low Cost Technical Solution

87 Multi-Factor Authentication (MFA)

88 Where Do We Go From Here? Our IT department is trying to setup proactive phishing training and awareness processes We may roll out MFA to key users Internal Audit future involvement in Penetration Testing

89 As Promised The Sequel id=annotation_202513&feature=iv&src_vid= F7pYHN9iC9I&v=Rn4Rupla11M

90 Questions 8 Minutes for Questions