1. Copyright Justin C. Klein Keane InfoSec Training Introduction to Information Security Concepts

2. Copyright Justin C. Klein Keane Vocabulary: Security Policy Refers to the way a system is supposed to function Can be explicit or implicit Outlines assumptions of protections and violations If you users don't have passwords is account hijack a violation of policy?

3. Copyright Justin C. Klein Keane Vocabulary: Incident Security incident is a violation (or series of violations) of a systems security policy Scope can vary from narrow to broad Incidents are events caused by (malicious) behavior Can be automated (a virus) or manual (abuse of access)

4. Copyright Justin C. Klein Keane Vocabulary: Threat Potential cause of a security incident Can be purposeful (a specific tool used to break into a site or a malicious insider) Accidental (floods, fire, lost backup tape, etc.)

5. Copyright Justin C. Klein Keane Vocabulary: Vulnerability Flaw in a system that could allow a threat to violate the security policy Can be a result of oversight or architecture Logic flaws can present vulnerabilities Vulnerabilities are static aspects of systems

6. Copyright Justin C. Klein Keane Vocabulary: Exploit Exploit is when a threat capitalizes on a vulnerability Exploits can be manual or automated Exploits demonstrate that there is a problem with a system

7. Copyright Justin C. Klein Keane Vocabulary: Malware Software that does bad stuff Malware include virus and worm code Includes software designed to modify legitimate systems to: Allow unauthorized remote access Hide evidence of intrusion Exfiltrate data from a target Surreptitiously monitor user activity And more...

8. Copyright Justin C. Klein Keane What is Security? Defined in terms of threats Secure from what?

9. Copyright Justin C. Klein Keane Security Concepts The Golden Rule (Au) Authentication  Users are who they claim to be, or at least can present credentials Authenticity  Data has not been altered and remains true to its original form Audit  The system can track what activity, data and users

10. Copyright Justin C. Klein Keane Security as Asset Protection A secure system must protect: Confidentiality  Threat: Information disclosure Integrity (and Reliability)  Threat: Data corruption Access  Threat: Denial of service

11. Copyright Justin C. Klein Keane Security Lifecycle Security is a process not a product Complexity is the enemy of security Security is an evolutionary landscape “Secure” is a point in time evaluation “Secure” is defined by known threats

12. Copyright Justin C. Klein Keane 0 day 0 day is a vulnerability for which there is no patch available If 0 day cannot be predicted, how can we defend against it? 0 day can often be mitigated How can we detect 0 day? Defense in depth is often the only defense against 0 day When evaluating security you should assume 0 day

13. Copyright Justin C. Klein Keane A Word on Software Bugs Software engineering is a robust, and mature, field of academic study All software projects of sufficient size and complexity contain bugs, regardless of development process A certain number of bugs will be security related Conclusion: all software contain security related bugs

14. Copyright Justin C. Klein Keane Classifying Software Bugs Not all bugs are the same Bugs may present wildly varying threats Bugs may have different risks associated with them All bugs are significant, however

15. Copyright Justin C. Klein Keane Even if it's bug free Bug free software can still have vulnerabilities: Configuration problems:  Default or weak credentials  Improper trust model  Etc. Logic flaws  Fundamentally insecure design  Software functions exactly as designed but the result is an unintended vulnerability Two bug free systems might have insecure interaction

16. Copyright Justin C. Klein Keane Vulnerability Synergy Linking one vulnerability to another Chains of low risk, or low significant vulnerabilities can lead to a serious vulnerability Even if highest risk bugs are all patched, a combination of low risk bugs could lead to compromise

17. Copyright Justin C. Klein Keane Sisyphean Task A sufficiently resourced and motivated attacker will always compromise security Defenders must be right 100% of the time, attackers need only succeed once You can't possibly defend against everything Attacker motivation is unknowable

18. Copyright Justin C. Klein Keane Protect, Detect, React The security lifecycle, also known as the security hamster wheel of pain EVERY step is critical Detection is dependent on observation and reporting Logs are some of the best places to do detection More on each step later

19. Copyright Justin C. Klein Keane How can we get ahead? The protect/detect/react cycle often requires an incident to move from detect/react to better protection It is important to keep the cycle moving independently of a security incident Collecting metrics is key to making informed decisions Start with security first...

20. Copyright Justin C. Klein Keane Threat modeling Maximize ROI with high impact, low cost, mitigations Good authentication, authorization and audit Fault tolerance or Rugged Design Applications should protect against unexpected actions This includes good exception handling Test driven design, with tests that should fail Secure Application Development Lifecycle (SDLC) Secure Design

21. Copyright Justin C. Klein Keane Penetration Testing Actively attacking your own systems Can reveal flaws in protection, including gaps Can proactively identify vulnerabilities (prevent 0 day) Helps more accurately frame risk assessment

22. Copyright Justin C. Klein Keane Application Security Testing Black box Penetration testing Gray box Some level of access and documentation available White box Full code review, often combined with other testing tools

23. Copyright Justin C. Klein Keane Using Automation Automation is critical for a timely review Automation can lead to false positives Automated tools without skilled human operators can be useless Deluge of false positives Poor risk assignment

24. Copyright Justin C. Klein Keane Gold Standard for Security Reporting Security reporting after a review should include: List of vulnerabilities, ranked/grouped by severity Demonstration of exploit List of suggested mitigation and work around strategies List of patches and/or fixes for the issue A good security test should be repeatable

25. Copyright Justin C. Klein Keane Resource Allocation In the real world resources are limited Given the scope of security it is impossible to cover all fronts How does one make smart resource allocation decisions?

26. Copyright Justin C. Klein Keane Risk Calculations Risk can be used to draw comparisons Risk generally calculated: Risk = Likelihood x Severity Good risk ratings allow you to compare apples to apples Can focus attention and resources to greatest need How can we baseline these without METRICS?

27. Copyright Justin C. Klein Keane Flaw in Risk Calculation Likelihood can never actually be measured because it is within the attackers control How can you quantify what you don't know? Severity may hinge on unknown consequences or attacker motivation Some resources may escape risk calculation

28. Copyright Justin C. Klein Keane Non Technical Threats Risk calculation involves assessing threats Some threats are not strictly system related: Reputational damage Misinformation Business risks (ex: grant funding)

29. Copyright Justin C. Klein Keane Typical Poor Risk Calculation Home user doesn't protect their machine because they have no data of value Risk = medium likelihood x low impact Home user may not understand full impact: Attacker can use webcam Attacker can use mic to record conversations Attacker can use connection to compromise wireless router to allow anonymous wireless

30. Copyright Justin C. Klein Keane Linchpin in Most Flaws Many risk calculations fail because the assessor measures risk based on: Perceived attacker motivation Without understanding what an attacker is after there is no effective way to protect resources “Industry best practice” may provide a guide

31. Copyright Justin C. Klein Keane Moving Forward Goal is an adaptive, metrics based information security program Resources should be fluid, and allocated based on actual need Reactive capabilities should be maximized Reduction of misguided protective measures Constant metrics gathering and reevaluation Learn, grow, share