This is the slide deck for my talk on six essential security services for the NZISF forum on 9 February 2017.

1. The Six essential
security services
Hinne Hettema
IT Security Team Leader
The University of Auckland
Email: h.hettema@auckland.ac.nz
PGP Key ID: B1EA7147 | PGP Key Fingerprint: AC12 2983 2EA1 B328 95BB B4AE EDA5 8E90 B1EA 7147
NZISF | 9 February 2017 | Auckland

2. root@myops:~# whoami
• Theoretical chemist and philosopher by training (PhD 1993 and 2012)
• Wrote DALTON program code [in FORTRAN]
• Played with supercomputers such as Cray Y-MP
• First got hacked in 1991
• Worked 15 years as IT Infrastructure architect for various NZ
companies
• Now lead the IT Security team @UoA by day
• Public speaker and cybersecurity blogger, Gartner Research Circle
• Present at technical cyber security conferences

3. root@myops:~# whoami > graphic

4. My mission:
Become a ‘second generation’ security leader, focusing on the security challenges of new
technology for large organisations: the cloud, threat intelligence handling and sharing, and
big data initiatives to drive an improved security posture for complex organisations.

5. Contents
1. The root of the problem
2. A conventional view: cyber security is a business problem
3. A maverick view: cyber security is a business problem
4. The six essential security services
5. A call to action

6. The root of the problem

7. Security train wreck: why the mess?
The IT industry creates and maintains eternal economic disincentives to
build better security into anything:
1. Rapid consumerisation, hence feature driven development (security
is not a feature)
2. Time and Cost driven market model (lowering quality)
3. Security has to be relearned at each new phase of development
(why, oh why is ‘telnet’ the most common IoT port?)
With IoT, to make it worse, these disincentives are meeting:
4. Long expected lifetimes

8. And the business response
Operational Security dimension Fear Resilience
Security posture Reactive Proactive
Incident approach Panic [denial, anger, bargaining] Controlled chaos
Security team HR “we need a fall guy” “build the team”
Security monitoring Haphazard
[Worse] Vendor driven
Controls based on
• attacker behaviour/movement
• known exploit risks
• known vulnerability/exposure
Predictability None / little Anticipated events
People impact Burn-out Busy
Security perception IT problem
Hackers are nerds doing bad things!
Business problem
Hackers are people too
Defence focus Border
Fortress
Defence in depth
“Assume breach”
Immune system
Resilience and antifragility

9. A conventional view: cyber
security is a business problem

10. Cyber security as a risk exercise
• Cybersecurity usually seen as an area of tactical IT risk
• Risk treatment strategies
• Accept (who accepts what risk on behalf of whom?)
• Mitigate (what to put in place?)
• Transfer (insurance?)
• Two notes
• Trends cannot always be extrapolated
• Cyber security risk is ‘black swan’ territory, so actuarial calculations are
problematic

11. All your risks are belong to us
• Tactical IT risk hides cybersecurity risk safely somewhere in the realm
of the ‘techies’
The four mistakes people make when looking to get security leadership:
1. Short-change how much risk is actually involved
2. Get the reporting structure wrong
3. Overemphasise the technical
4. Looking for five-legged unicorns (the ‘skill shortage’)
http://www.heidrick.com/Knowledge-Center/Publication/Four-mistakes-to-avoid-when-hiring-your-next-security-chief

12. Compliance focus
• Compliance is not a comprehensive
answer to risk
• Rather than a baseline, compliance
becomes the end-goal (understandable if
the starting point is abject non-
compliance…)
• Focus on compliance can lead to ‘box-
ticking’ exercise and poorly conceived or
mis-scoped security solutions

13. Governance, Risk, Compliance
What can possibly go wrong…?
• Cybersecurity usually seen as an area of tactical IT risk (risk of mis-
scoping)
• Struggle to get from the IT department up to board level
• Focus on compliance leads to box-ticking exercise
• Compliance concerns drive security solutions that don’t work
• This gives security a bad name
• Solution: disband your security team…

14. If all this works so bad, let’s just…

15. A maverick view: cyber security
is a business problem

16. Recognise the true complexity
http://cyber-analysis.blogspot.co.nz/2014/10/cyber-terrain-model-for-increased.html

17. Crims and others on the cyber terrain…
• Unlike ‘acts of god’ attacks are intentional
Cyber attack is a very attractive mode of crime or espionage / sabotage
• Very large economies of scale
• Very low chance of getting caught
• Very easy to do in different jurisdictions, so low chance of conviction
• Methods and tools readily available
• In large quantity and variety
18

18. Prospect theory and your cybers
• GRC models are based on ‘rational behaviour’
• We are evolutionary primed to prefer fast solutions that help us
survive (something rustles in the bushes…)
• Daniel Kahnemann: Thinking Fast, Thinking slow
• Look at prospect theory
• Loss feels 2.25 as bad as a similar gain feels good
• Overweight small probabilities, and underweight big ones
• Defenders: avoid a big loss (becoming the next Sony), overestimate small
probabilities (APT), easy attitude to adopt is to become big risk takers (spend
megabucks on some flashing lights automated kill chain mitigation device)

19. The ‘operations dilemma’
• Good cyber security depends on a lot of small things done well
• Which each help to mitigate a ‘small loss’
• Or have small gains
Operations?
• It’s ‘operational’, and hence it’s cost minimised
• Or it’s assumed ‘done already’
• Operational people outside security often have a ‘break fix’ attitude
(incentivise lack of outages), so no patching, no hygiene, ‘but it works’

20. Outcomes of the ‘operations dilemma’
1. Many criminally under-adopted (hard to get budget for) tools
• 2FA or two-step verification
• Canaries (thinkst or canary.tools)
• Understanding the threats in your context – any logging and monitoring
projects
• Certificate health and maintenance
2. Overspending on high risk technical solutions
• Non-contextualised threat intelligence feeds and tooling
• Automated threat mitigation tools
• ‘Prevention’ and DLP tools

21. ‘Operations Dilemma’ restated
• We can get action if there are massive and costly breaches
• Otherwise it’s hard to get visibility and budget
• We don’t help ourselves: Department of ‘No’
• How many of us can
• Provide instant and up to date metrics on small breaches and incidents
• Define the services that the security team provides to the rest of the
organisation?
• Work our people in virtual teams, devops, cloud?
• Work with agencies and trust groups if required?

22. Strategic aspects of cyber security
Consider this
• Almost all ‘new’ business is heavily digital or has IT as a central
component
• Existing and new customers need to trust you if they are to continue
business with you
• We want to use ‘cloud’ to cut costs
• We’re rapidly re-engineering ‘IT’ from waterfall to DevOps
• ‘Cloud’ is a strategic choice and changes all security architectures we
have so far been comfortable with (firewalls will become irrelevant)

23. Where to focus security operations?
‘Services’ help define ‘security’ in terms the rest of the business
understands
• Compliance approach is still primarily preventive
• ‘Beyond compliance’ is proactive, predictive and corrective in each
stage of the IT factory
• Step 1: What can we learn from actual breaches that happened to us?
24

25. The six essential security
services: best practice, maturity,
examples

26. The six essential security services
• Strategy
• Policies
• Architecture
• Penetration testing
• Monitoring and Alerting
• Incident response

27. Strategy: why
• Cyber security is now firmly a matter of boards, who need education
themselves (a good strategy can help)
• No longer ‘just an IT issue’
• Security is becoming exponentially more complex: it’s about
maintaining trust in the digital assets of an organization,
understanding the threats to that trust, and sharing that intelligence
with the community in a controlled fashion
• Security landscape changes incredibly quickly
• Strategy needs to be forward looking and anticipate changes

28. Strategy: how
• Strategy is narrative and
contextual
• Focus on two upper levels of the
pyramid of pain in your business
context
• The ‘why’ of the attack
landscape is most important
• Build on existing strengths:
reputation, mission, values,
value chain
David Bianco: The pyramid of pain http://detect-
respond.blogspot.co.nz/2013/03/the-pyramid-
of-pain.html

29. Strategy: forward or backward looking
Recommended strategic settings:
• Assume breach
• Fully informed management
• Threat hunting, collection and
intelligence program
• Address how to work with
agencies – legal, organisational,
reputational
Backward looking strategy is focusing on
• Compliance
• Anything with ‘ISO’
• Risk management
Forward looking strategy focuses on
• Antifragility
• Resilience
• Threat hunting and discovery
• Cloud enablement
• Trust and its implementation

30. Policies: how, why, maturity
• My least favourite area!
• Writing is easy, adoption is key
• Can plunder other sites, but no substitute for understanding your
own business
Maturity
• Immature: Policies for each technology element
• Mature: Policies focusing on trust anchors, data classification, use

31. Architecture
Aim for Defensible Architecture
Understand and document the key elements driving security posture:
1. Security zones: geographic, legal, physical, logical (not just defence
in depth!)
2. User, workload and data perimeters
3. Trust calculations for user / data access or data / data access
4. Controls and detection

32. Key architecture practices
• Trust modelling
• Threat modelling
• Mitigations integrated with a risk framework
• Monitoring and detection baked in from day 1

33. Penetration / security testing
• Works two ways:
• Backward into the next design iteration
• Forward into deploying operational protection
• And bugs can get fixed
• Mix of manual and automated
• Works on application hardening
• Aspect of QA – integrate with QA service?

34. Penetration testing: maturity
Immature
• Run an automated scan across every web site
Mature
• Do you architects threat model? Great! You’ve just got yourself a test
plan for penetration testing
• Don’t forget your buildings, access cards, shadow cloud
• For stuff that you can’t fix: implement deployment controls

35. Monitoring and Alerting
• Think along the threat chain
• Understand the various stages of an attack, at least conceptually and
in the context of your business
• Select detection, mitigation and tooling techniques that suit your
businesses
• Be wary of ‘automated kill chain mitigation’ tools

36. Attack stages: the ‘kill chain’
Source: A “Kill Chain” Analysis of the
2013 Target Data Breach: Majority Staff
Report For Chairman Rockefeller, March
26, 2014, diagram attributed to
Lockheed Martin

37. The kill chain as a detection tool
Source: A “Kill Chain” Analysis of the
2013 Target Data Breach: Majority Staff
Report For Chairman Rockefeller, March
26, 2014

38. Tooling examples
• Ingress / egress at the border
• Flow data
• Packet captures
• IDS close to key services
• Logon / logoff intelligence
• System logs
• Host systems – HIDS / HIPS / system hardening

39. Kill chain derived Tooling Matrix
Border Hosts Internal
network
Storage …
Discovery NIDS Referrers Flows, patterns
Weaponisation FW Logs
Delivery FW, Flows AV, EMET,
HID[P]S
Exploitation NIS AV Internal IDS
Installation HID[P]S
Configuration
Ports Files, changes
Lateral
movement
FW, Logs, flow
data
Command and
Control
Flows
Egress traffic
File access
Actions
objectives
Flows
Destruction

40. Alerting strategy
Leading principle: Alerts are based on contextualised data
Example – automate this:
• IDS detects attack against a server [say, ssh brute forcing]
• When was the last vulnerability scan done?
• Where is the report?
• Should a report be run now?
• Is the server vulnerable to this attack? [Yes / Maybe / No]

41. Contextualisation
• This can drive the ‘big data threat intelligence’ strategy
• Can’t buy everything
• Your own logs and auth records are key components
• Consolidate on noSQL solution, with large storage
• Automate threat indicator collection
• Do not generate alerts if not necessary

42. Incident response: maturity
• No maturity: nothing or headless chicken
• Low maturity: SIEM
• Lots of false positives
• Analysts sit waiting for an alarm to go off
• Passive activity, turning you into a victim
• No capability to consume and use threat intelligence
• High maturity:
• Contextualised TI, warning early in kill chain
• Blue teaming
• Active hunting

43. The elites: Threat Intelligence Sharing
• Open source feeds
• Sharing collectives / trust groups
• Commercial feeds
• Your own attack intelligence
• Network
• Memory
• Antivirus
• Logs
• Enterprise data stores

44. A call to action

45. Where to from here?
• Start with an understanding of the business
• A full-fledged security strategy not necessary on day 1, but executive
support is required
• Start with incidents, monitoring and alerting and build out from there
• If that’s hard, think ‘logs’
• Architecture / threat modelling your processes is next
• Put monitoring and alerting around identified threats (past incidents)
• Investigate incidents in depth to understand your adversary

46. Key considerations in security leadership
1. Drive from tactical to strategic: know how to articulate the
dimensions of ‘trust’ and ‘security’ for new business
2. Step out of tech: Understand ‘security’ in terms of the ‘cyber
terrain’ (people, process, technology)
3. Drive the closure of the incident response loop (organisational
learning)
4. Develop and contextualise threat intelligence by enriching logs and
incident data before buying expensive platforms and feeds
5. Work with agencies and trust groups
http://www.heidrick.com/Knowledge-Center/Publication/Does_Your_Security_Chief_Have_Board_Level_Commercial_Savvy

47. Questions?