Cybercrime & Vulnerability Issues: What Emergency Managers need to know

1. Cybercrime & Vulnerability Issues:What Emergency Managers need to know Jim Duncan, Security Engineer Juniper Networks, Secure Development Lifecycle Initiative Tuesday, 2014-10-14 North Carolina Emergency Management Association Fall Conference

2. Brief Biography • Subject-Matter Expert on software vulnerabilities • Currently working on prevention of flaws (Juniper SDL program) • Previously, product-security and cyber-security incident responder • Juniper, BB&T, Cisco, Penn State University, Old Dominion University • TRANSITS Instructor – helping National CSIRTs in emerging economies • Participant in multiple IRT and cybercrime-fighting forums (FIRST, ICASI) • Critical Infrastructure Protection evangelist (NIAC VDF, CVSS, ISACs) • Ideal candidate for the exit row! • (Also soccer referee, parliamentarian, piano technician, pistolsmith, etc., can’t keep a job!)

3. Why Am I Here today? • Cybercrime and vulnerabilities are here to stay • You know that already; this will not be yet another trend report • Technology Complexity – the Internet of Things – growing without bound • Implications for interactions with other disciplines both exciting and scary • Security, if any, is frequently low priority, or omitted from consideration entirely • Definitely no security in Version 0.1, which is what is deployed to first responders! • Technology is just a tool, you should not need to be an expert in it • How many of you are well-versed in internal combustion? • My goal is impart observations, rules, etc., for thinking about cyber systems and understanding the larger threats and countermeasures

4. Problems

5. Nature of Cybercrime • “Cybercriminals are business people, too.” • Amazing parallels to counterfeiting of old: front office, back office, etc. • Well-financed, distributed, smart, not greedy (mostly) • Misalignment of cultural expectations is a complicating factor • Definitions of “crimes” vary from place to place, hard to get support sometimes • Resourceful: example of CAPTCHA workaround • Well-researched: example of bank phishing aimed at small church officials • Follow the money and/or spirit: motivations explain a lot • All of the above apply to nation-state and populist activities, too

6. Confidentiality/Privacy/Reputational THreats • SWATting and EAS hijacks; not much help here except the obvious • D0Xing of staff and officials – Internet-based embarrassment is deadly • Teach staff how to protect themselves online if you expect them to protect other people’s stuff online. • Consider reputation-monitoring services • Monitor and prevent exfiltration of data in your stewardship • Don’t assume data was erased – it can never be completely erased • Use full-disk encryption and test it • Consider reputation-monitoring services for this as well

7. Telecommunications threats • DoS can’t be prevented, but often it can be managed • Various services for ensuring against DoS or mitigating once underway • Work with your ISP (maybe more than one ISP) • Make sure you have experts involved • Telephony DoS is old, but new again • Multiple efforts in multiple countries to improve technological response • “Honeypots” deployed to look for TDoS, do-not-call violations, other errors • VoIP is exciting, isn’t it? Yeehaw! • Fundamental flaw: circuit-switched v. packet-switched security models

8. Transportation Threats • GPS spoofing and jamming • Documented that thieves are using spoofing to hide stolen vehicles • Florida(?) motorist operated a cellphone jammer from his car during his daily commutes to force other motorists to put down their cellphones • Easy to imagine similar stunts to fraudulently redirect consumers away from competitors’ gas pumps or (pick a retail industry) • How do you know your GPS is receiving correct data? Anyone? • Highway sign hijacks are clever, but what if they are subtle? • Instead of “zombie” alerts, consider believable “Detour via…” instructions

9. Environmental THreats • EMP and solar flares • Really naïve in this area, despite decades of study • Recent work very revealing and alarming, but seems to be ignored • Structural HVAC, building & power controls, SCADA systems • Never underestimate the potential for someone to inadvertently connect these systems to something they shouldn’t be connected to • And never underestimate the ability of criminals to find them (e.g., Target) • What do you do when your EOC gets too hot? Too cold? Too wet? Dry? • Example of first World Trade Center attack in the early 1990s

10. Case Study Not Yet Published • Analysis of pre-hospital information system used by EMTs • It was in another state, not North Carolina. Relax! Resume breathing… • Criminals’ delight: • No AUP, no password policies • Ruggedized laptop running unpatched XP, plans to upgrade to Win7 • No full-disk encryption • Brand-name software vendor truly did not keep PII on device, but… • Helpful cache was uncovered, unencrypted, with PII for 13,500 patients! • THIS HAPPENED IN 2014!!! This is all too believable, unfortunately

11. Solutions

12. Occam’s Razor, Hanlon’s Razor, etc. • Occam’s Razor: “When considering multiple possible causes, select the cause requiring the least complexity” • Not guaranteed to be correct, but likely • Hanlon’s Razor: “Never attribute to malice that which is adequately explained by stupidity.” • Duncan’s Corollary: “Never attribute to an attack that which is adequately explained by negligence.” • “Negligence” can be misconfiguration, software flaw, or user error • Example of inadvertent internally-sourced “attack”

13. Avoid Bystander Effect/Diffusion of Duty • First responders would never do this in the real world, but they fall prey to it in the cyber world: Don’t assume someone else will respond! • Ask questions. Lots of questions. • Recipients of questions: be professional and answer appropriately • Consider documenting individual findings in “security observation reports” • Advocate for proper brainstorming practices • In the first round, get the ideas out there; no vetting whatsoever • Second round, go back and evaluate the first-round responses • Disciplined facilitator is sometimes needed for this to be effective

14. Replace Blacklisting with Whitelisting • Blacklisting: “That, which is not expressly denied, is permitted.” • Far too many systems start out this way • Painful to go back and close up unnecessary ports/services/features • Whitelisting: “That, which is not expressly permitted, is denied.” • Much safer • Start with all services disabled, then enable only those that are needed • Example: Instead of allowing browsing everywhere, and then blocking access to a few pages, block all pages except for a selected few.

15. Get Smart and Stay Smart on Crypto • “Gosh, crypto is hard!” • Doesn’t have to be difficult to understand the basics • Key length is important: long, but not too long (time is an issue, too) • Key space should be as large as possible (or reasonably pragmatic) • Don’t keep plaintext and encrypted text around, close by • Repetition means something failed; algorithm selection is important • Watch out for so-called “security improvement trade-offs” • Example of password-typing alternate-left-right scheme (“key space”, above) • Full-disk encryption is worth mentioning again, at this point

16. Understand Sphere of Action • Expectations and assumptions creep into our thought processes, distort our reasoning, and cause us to produce incorrect results • Cyber threats are globalbut not the typical disasters most of you handle • Example of NRP and Lori Bush, “There’s the hurricane/forest fire/flood!” • Cultural & linguistic differences affect results • Example of CAPTCHA workaround, earlier • Mismatch of importance regarding Asia/Pacific “loss of face” • Example of encipher/decipher v. encrypt/decrypt • Time and date formats (ISO-8601), ICS phonetic alphabet

17. Policies and Procedures • No excuses for not having Acceptable Use Policies, Password Policies, Data Retention Policies, and so forth; write’em down, publicize them • Don’t expect staff to pick good password management schemes; research apps, make recommendations (working group for NCEMA?) • Consider implementing two-factor access schemes • Remember that policies and guidelines should be viewed primarily as tools for education; enforcement comes only when education fails

18. Figure Out What Happened Later • “Accountability is the price of openness.” [Daniel E. Geer, Sc.D.] • No one builds a perfect system, so institute appropriate logging and auditing mechanisms so that after something goes wrong, you can backtrack to figure out what happened • Study Ken Thompson’s “Reflections on Trusting Trust” • 1984 ACM Turing Award lecture • Brilliant, short (3 pages) explanation on how all systems are flawed because humans are involved, and cannot be separated • Completely destroys the “Many eyes makes good security” argument

19. Don’t Attempt To Build Perfect Systems • “The perfect is the enemy of the good enough” (or something like that) • Lots of unnecessary effort is expended on lofty conceptions of the really cool and awesomely beautiful solution to a basic problem • Don’t build seamless systems, especially in an emergency • “Make them seamful, but with beautiful seams.” [Mark Weiser] • Example from ruggedized telecom-in-a-box in Hurricane Katrina

20. Be Part of the Solution, Not the Precipitate • Encourage proper brainstorming • Need sector-specific experts like you to think up interesting problems • We don’t know the stuff that you don’t even know you already know • Roll up the results into tabletop exercises • Collaborate with cybersecurity incident responders • We both learn from each other • We can help with cross-sector exercises • We’ll know who to call when we find something important

21. Anything Else? • Q&A • Contact Information: • Jim Duncan, jduncan@juniper.net, +1 919-608-0748