Technical Risk Technical Remediation Technical Myth Mike Scher Director of Labs Neohapsis, Inc.

1. Technical Risk Technical Remediation Technical MythMike ScherDirector of LabsNeohapsis, Inc.

2. Neohapsis 101 - Who we are and what we do • Information Security Consultancy with an emphasis on R&D and QA/QC • Network Computing Magazine's Chicago Lab • Producers of the SANS Security Alert Consensus Newsletter (SAC) • Security Design, Testing, Forensics

3. Managing Technical Risks • Legal Risk Management • Infrastructure Security • Financial Risk Management (Insurance) • Risk Transfer and Due Diligence

4. Technical Risks • Risks to Systems • Process Disruption • Access to data • Risks to Data • Data can be disclosed or ‘stolen’ • Data can be altered • Data can be destroyed • Data can become unavailable

5. How Technical Risks to Data Ripen Gaps: • Lack of policy • regarding access to and placement of sensitive data • Lack of technical access controls • that implement system and data access policies • Lack of policy verification and enforcement • that audits technical access controls

6. How Technical Risks to Data Ripen Ambiguities or lapses: • Ambiguity or oversight in policy • from no authoritative source of policy interpretation • Ambiguity or oversight in application of technical access controls • from no authoritative source of technical policy planning and review

7. How Technical Risks to Data Ripen Technical failures in access controls • Complexity of technical security systems • System interactions • Unpredictable failure modes • Inability to validate security aspects of vendor-provided systems, including security systems • Technical limitations of corporate test groups • Time and materials limitations of testing • Legal limits from statute and license

8. Protections for Data • WHO - Authentication systems • IDs • Passwords • Certificates • Tokens • WHAT and HOW - Access control / authorization systems • Firewalls (and “intrusion prevention”) • Routers, switches • Operating system controls • WWHW Review - Audit Systems • Intrusion Detection • Logging • Event aggregation and analysis (SIM)

9. AAA • Authentication systems validate who it is • Access control systems limit what they can do • Audit Systems review who did what, when

10. Policy is Critical • Without coordination of Who, What, and How, and the ability to test and audit, security is a matter of reaction • Reactive security is costly • Reactive security is ultimately ineffectual • Policy, well-implemented and reviewed, means proactive security, anticipating needs

11. Examples of Technical Risks • External Access Controls • Too many internal applications open to outside • VPN and dial-up access based on weak access controls • Access to Internal applications dependent on 3rd party’s security • Online Applications • User account guessing (weak access controls) • Session ID spoofing/guessing • Insufficient input data scrubbing • “SQL tampering” • Arbitrary command execution • “Cross-site scripting” • Audit Issues • No or unverifiable history of who accessed what • No ability to monitor copies of data

12. Authentication • User identification • Who do you claim to be? • Note the use of the term claim • Examples: • a userid: “jsmither” • a name: “Joshua Smither” • a SS#: 111-11-1111 • An e-mail address: jsmither@example.com • Not always unique, even on the system

13. Authentication (cont.) • User identification + Something else = • Reasonable association of the person with the ID presented • Why “reasonable”? • All access controls can be defeated • Many can be “spoofed” • Reasonability depends (ideally) on a risk analysis • What does the ID guard?

14. Authentication (cont.) • PLUS Something else (How can I reasonably assume you are who you claim to be?) • Password • Digital Certificate • “One-time” password (e.g., tokens) • Biometric • ANI (“caller-ID”) • Physical locality (including IP address) • Combinations of techniques

15. Problems in Authentication • Username/Password • Easily stolen when sent “in clear” • Or via “trojan horse” programs, worms, viruses • Can be “weak” or “strong” (vs. guessing or “cracking”) • Weak: mouser1 (guessable) r!verb3d (crackable) • Strong: 9i63vDvK • When they are memorable, they are weak • When they are strong, they are unmanageable • People almost always either pick weak passwords or they record their passwords someplace handy (perhaps protected by a single password) • Anyone can use anyone else’s password

16. Problems in Authentication (cont.) • Digital Certificates • Large password protected by a small password • File can be taken just like any other • User’s password to activate the certificate may be • Guessed • Cracked • Snooped • More like a “rubberstamp” signature in a locked drawer • But owner may have no indication of its theft • Rebuttable presumption of identity unlikely to ever be rebutted

17. Problems in Authentication (cont.) • Biometrics • Biometrics are static, and easily copied once known • Never-ending escalation of spoofing tricks against the reader, never-ending need to upgrade readers • Remote biometric authentication raises issues • Credentials injected into the stream • Biometric readers use a variety of cryptographic methods to ensure data integrity and reader legitimacy • At that point, biometrics are a fixed password in a public-key authentication system

18. Problems in Authentication (cont.) • IP addresses (network locality) • Spoofable for some kinds of connections • Don’t establish that the user initiated the action

19. Authorization Systems Essentially Access Control Lists (ACLs) • On Firewalls / IPS • On Gateways and Routers • On Servers • On Workstations

20. Firewalls • Help provide an initial layer of defense at boundaries • Provide network accounting mechanisms • Can be used as a broad access control device • Some firewalls can do ACL and pattern-based content control including virus filtering

21. Firewalls (cont.)

22. Firewalls (cont.) • All firewalls are not created equal • Proxy vs. “stateful” • Proxy vs. Proxy • Proxy vs. “IPS” • There is no “best” firewall • Don’t solve host/server-level problems • Have a history of their own security problems • Often provide a false sense of security

24. Gateways • Whose traffic goes where… and how? • Gateways don’t just include firewalls • Alternate Routers • Wireless • Dial-up • Legacy (X.25) • Virtual Private Network (VPN) gateways • Any information security program must take all gateways to the corporate network into account.

25. VPNs • VPN: • Simulate a point-to-point, dedicated telco line as closely as reasonably possible • Identify user or remote network (authentication) • Limit access (authorization) • Log accesses and violations (accounting)

28. VPNs (cont.) • Inherently serve one real purpose: • Make doing a very risky thing as safe as reasonably possible • Then why do we use them? • Costs • Also, costs • Oh, and costs, too.

29. VPNs (cont.) (Not to mention, costs.) • The Big Myths about VPNs: • inherently add security • authenticate end-users • ensure authorized use • always less expensive than dedicated telco connectivity

30. VPNs (cont.) • Risks (especially in connecting a home user to the enterprise network) are significant • Privacy of the connection and authentication traffic • Theft/compromise of authentication credentials • End user’s system used as live gateway to private network after the user authenticates • End user fooled into authenticating to trojan gateway • Store-and-forward (time-delayed) attacks from compromised end-user system

31. Logs (audit trails) and Authentication • System logs of “who was on what system when” depend on Authentication credentials of the user • Authentication credentials are often combined for greater assurance • password + biometric + locality • token(one-time password) + password + locality

32. Intrusion Detection Systems • Misuse detection vs. Anomaly detection • Host based (HIDS) vs. Network based (NIDS) • HIDS: Active Audit trail monitoring • NIDS: Snooping network traffic for signs of malfeasance • Almost all report to a central collection, correlation and alert-generating server • Useful as an early-warning system and for trending trouble areas • Useful for some types of after-the-fact damage analysis

33. The Upshot • Defense in depth is becoming the new best practice in most industries • Use firewalls at least at corporate borders • Use IDS internally and at borders • Secure servers and put IT policies in place to maintain their security • Use strong authentication devices for all remote access • Use VPNs with strong authentication and limit remote users’ capabilities • Defense in depth requires coordinated, intelligent policies, risk analysis, and regular technical review • Never assume a product is so secure that it is all you need for security – even a firewall • IT staff need to get and stay up to date, reviewing new issues almost on a daily basis • Manage IT risks as a part of conducting business

34. Questions ?

35. URLs • Us: http://www.neohapsis.com • Many security mailing list archives: http://archives.neohapsis.com • Security Alert Consensus (SAC): http://www.sans.org/sansnews/ • Mike: mscher@neohapsis.com