The engineering part of social engineering or why just lying your way in don't get you anywhere. aluc#
I’m Aluc I’m a old hacker who loves the blood of your network
Preface:
What is Social Engineering? <ul><ul><li>*Social:  ( adjective   1  relating to society, its organization, or hierarchy.  2...
<ul><li>Needed Skillset: </li></ul><ul><li>physical </li></ul><ul><li>Logical </li></ul><ul><li>Customer Preparation </li>...
<ul><li>Needed physical/psychical Skillset: </li></ul><ul><li>understanding of craftsmanship </li></ul><ul><li>ideal life ...
Everyone talks about NLP, what is this? NLP is a communications model created in the  early 70’s by John Grinder, David Go...
The Modeling: “ Modeling is the process of creating useful maps of human experiences. (abilities)” --David Gordon   In thi...
Example: An 8 year old girl with Tourette's &quot;copied&quot; the cover of the Junie B. Jones book as part of a book repo...
Example: An 8 year old girl with Tourette's &quot;copied&quot; the cover of the Junie B. Jones book as part of a book repo...
Why Modeling: Practical: correct problems and add    abilities Evolutionary: Perceiving structure and    systems Spiritual...
Experiential Array: Array and Graphic by David Gordon
<ul><li>Understanding keywords and difference between attributes and states: </li></ul><ul><li>A human's brain can process...
<ul><li>How do we use this: </li></ul><ul><li>listen in conversations to keywords </li></ul><ul><li>like “stress” “freedom...
<ul><li>Convert Attributes into States: </li></ul><ul><li>  try to generate and feel states for yourself </li></ul><ul><li...
<ul><li>Cold Reading / What is your first impression? </li></ul><ul><li>  Clothes - Uniform type  </li></ul><ul><li>  Body...
Micro Expressions: Based on the system which Dr.Friesen developed, we can divide about 1000 unique facial expressions whic...
Micro Expressions: some charts from Dr. Lightman:
<ul><li>Intelligence Gathering before 1st customer meeting: </li></ul><ul><li>Internet search: </li></ul><ul><li>Maltego <...
<ul><li>Meet the Client: </li></ul><ul><li>find out what his business is </li></ul><ul><li>find out about the company's hi...
<ul><li>Threat Modeling: </li></ul><ul><li>assets (resources which can become    targets)  </li></ul><ul><li>threats </li>...
<ul><li>Threat Modeling: </li></ul><ul><li>STRIDE ­ Model </li></ul><ul><li>S poofing Identity  </li></ul><ul><li>T amperi...
<ul><li>Threat Modeling: </li></ul><ul><li>DREAD ­ Model </li></ul><ul><li>D amage Potential </li></ul><ul><li>R eproducib...
Threat Modeling:
<ul><li>The Assessment: </li></ul><ul><li>Storyboard </li></ul><ul><li>Team </li></ul><ul><li>Insertion point </li></ul><u...
<ul><li>Infiltration: </li></ul><ul><li>tailgating / piggybacking </li></ul><ul><li>steal fingerprints </li></ul><ul><li>u...
Example Infiltration Hardware:
<ul><li>Finding and fetching data: </li></ul><ul><li>Printer </li></ul><ul><li>Spearphishing </li></ul><ul><li>Dumpster di...
<ul><li>Exfiltrate Data: </li></ul><ul><li>USB key </li></ul><ul><li>printout in trash </li></ul><ul><li>over the net </li...
<ul><li>Active Compromise: </li></ul><ul><li>Alarm system </li></ul><ul><li>Video surveillance </li></ul><ul><li>Employee/...
<ul><li>Passive Compromise: </li></ul><ul><li>Employee has a hunch but can't grab it </li></ul><ul><li>Admin/User changes ...
Thx for listening! See/hear me at:  http://youtube.com/theAluc  ...I guess
Upcoming SlideShare
Loading in …5
×

28c3 version of "The engineering part of social engineering"

1,485 views

Published on

Published in: Education, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,485
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • 1. Identifikation der „Assets“ bzw. Sicherheitsziele Am Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase ist es durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden. 2. Übersicht der Architektur Einfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „use cases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren. 3. Dekomposition der Architektur Hier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen. 4. Bedrohungen herausstellen An Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden. 5. Sicherheitslücken finden Die identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 1. Identifikation der „Assets“ bzw. Sicherheitsziele Am Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase ist es durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden. 2. Übersicht der Architektur Einfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „use cases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren. 3. Dekomposition der Architektur Hier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen. 4. Bedrohungen herausstellen An Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden. 5. Sicherheitslücken finden Die identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 1. Identifikation der „Assets“ bzw. Sicherheitsziele Am Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase ist es durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden. 2. Übersicht der Architektur Einfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „use cases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren. 3. Dekomposition der Architektur Hier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen. 4. Bedrohungen herausstellen An Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden. 5. Sicherheitslücken finden Die identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 1. Identifikation der „Assets“ bzw. Sicherheitsziele Am Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase ist es durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden. 2. Übersicht der Architektur Einfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „use cases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren. 3. Dekomposition der Architektur Hier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen. 4. Bedrohungen herausstellen An Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden. 5. Sicherheitslücken finden Die identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 1. Identifikation der „Assets“ bzw. Sicherheitsziele Am Anfang sind normalerweise Anforderungen, Sicherheitsrichtlinien, Normen oder sonstige Vorschriften gegeben, welche auf Schlüsselziele abgebildet werden können. Diese klaren Ziele helfen bei der Aufgabenverteilung und –übersicht. Während der Entwicklungsphase ist es durchaus möglich, dass sich die Anforderungen an die Software ändern. Jedes mal, wenn neue Informationen verfügbar werden, sollte man sie gegen die aktuell erforderlichen Richtlinien abgleichen und das über weitere Vorgehen entscheiden. 2. Übersicht der Architektur Einfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „use cases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren. 3. Dekomposition der Architektur Hier wird die Architektur detailliert untersucht. Bsp. wird bei Webanwendungen das zugrunde liegende Netzwerk und die Infrastruktur des Hosts betrachtet. Es werden Vertrauensgrenzen gesetzt und mittels Datenflussdiagrammen interne Abläufe nachvollziehbar dargestellt. So kann man auch Einstiegspunkte des Nutzers in die Software aufzeigen. 4. Bedrohungen herausstellen An Hand der Sicherheitsrichtlinien, dem gewonnenem Architekturwissen und allgemein bekannten „Threats“ kann man nun herausfinden, welche Bedrohungen für das System realistisch sind (siehe „STRIDE“‐Modell). Danach müssen diese natürlich bewertet werden, damit man jeder relevanten Bedrohung ihren angemessenen Aufmerksamkeitsgrad zuordnen kann (siehe „DREAD“‐Modell). Parallel dazu ist eine gute Dokumentation unentbehrlich. Diese Daten könnten in ein Bugtracking‐System eingepflegt und direkt dessen Reportfunktionalitäten genutzt werden. 5. Sicherheitslücken finden Die identifizierten Bedrohungen müssen mit gegebenen Schwachstellen in Verbindung gebracht werden. Auch hier können allgemein gültige Informationen über Schwächen in verwendeten Technologien hilfreich sein, um vorliegende Sicherheitslücken zu finden.
  • 28c3 version of "The engineering part of social engineering"

    1. 1. The engineering part of social engineering or why just lying your way in don't get you anywhere. aluc#
    2. 2. I’m Aluc I’m a old hacker who loves the blood of your network
    3. 3. Preface:
    4. 4. What is Social Engineering? <ul><ul><li>*Social: ( adjective 1 relating to society, its organization, or hierarchy. 2 needing companionship; suited to living in communities.) </li></ul></ul><ul><ul><li>*Engineering: (the branch of science and technology concerned with the design, building, and use of engines, machines, and structures.) </li></ul></ul><ul><ul><ul><ul><ul><li>*Taken from Oxford Dictionary... And then from Chris Nickerson ;) </li></ul></ul></ul></ul></ul>
    5. 5. <ul><li>Needed Skillset: </li></ul><ul><li>physical </li></ul><ul><li>Logical </li></ul><ul><li>Customer Preparation </li></ul><ul><li>theoretical models of attack </li></ul><ul><li>check the customer needs by his business </li></ul><ul><li>Contract -good fences make good neighbours! </li></ul>
    6. 6. <ul><li>Needed physical/psychical Skillset: </li></ul><ul><li>understanding of craftsmanship </li></ul><ul><li>ideal life experiences as electrician, telephone cable guy or computer mechanic </li></ul><ul><li>lock picking </li></ul><ul><li>in hostile environment Physical Security </li></ul><ul><li>good rhetoric </li></ul><ul><li>understanding of the person you approach </li></ul><ul><li>an understanding of human psychology </li></ul><ul><li>Neuro-Linguistic Programming (NLP) </li></ul><ul><li>ideal Hypnosis </li></ul>
    7. 7. Everyone talks about NLP, what is this? NLP is a communications model created in the early 70’s by John Grinder, David Gordon and Richard Bandler. The basis of their work are the analyses of the work of the therapists Fritz Perls, Virginia Satir and Milton H.Erickson. The N stands for the flow of Neurologic processes in the human brain The L stands for Linguistic, which is our capability to speak The P stands for Programming, which means the change of the “inner program” of a human
    8. 8. The Modeling: “ Modeling is the process of creating useful maps of human experiences. (abilities)” --David Gordon In this process you want to find out how your brain operates by analyzing the pattern of verbal and nonverbal communication. The outcome can be used for step by step guides to transfer skills from one person to another. Example: “Drawing on the Right Side of the Brain” --Betty Edwards
    9. 9. Example: An 8 year old girl with Tourette's &quot;copied&quot; the cover of the Junie B. Jones book as part of a book report.  http://thelastpsychiatrist.com/2011/10/how_to_draw_not_about_how_to_d.html
    10. 10. Example: An 8 year old girl with Tourette's &quot;copied&quot; the cover of the Junie B. Jones book as part of a book report.  http://thelastpsychiatrist.com/2011/10/how_to_draw_not_about_how_to_d.html
    11. 11. Why Modeling: Practical: correct problems and add abilities Evolutionary: Perceiving structure and systems Spiritual: open to the beauty of structure, preciousness of each person
    12. 12. Experiential Array: Array and Graphic by David Gordon
    13. 13. <ul><li>Understanding keywords and difference between attributes and states: </li></ul><ul><li>A human's brain can process about 100 trillion teraflops </li></ul><ul><li>Your sensors receive 10,000 bits/s </li></ul><ul><li>from this 10,000 bits, about 40 are being processed </li></ul><ul><li>This causes us to “make up” our very own version of this world. </li></ul>
    14. 14. <ul><li>How do we use this: </li></ul><ul><li>listen in conversations to keywords </li></ul><ul><li>like “stress” “freedom” “love” etc </li></ul><ul><li>find out the person's actual internal state vs perceived internal state </li></ul><ul><li>pay attention to micro expressions </li></ul><ul><li>understand the difference between a state and an attribute “he feels” vs “he has” </li></ul>
    15. 15. <ul><li>Convert Attributes into States: </li></ul><ul><li> try to generate and feel states for yourself </li></ul><ul><li> try to generate states from other people by using the “right” words </li></ul><ul><li> find out when these states are appropriate </li></ul><ul><li> find the right timing to use these states </li></ul><ul><li>Don’t forget: From the n-Mio Bit/s messages you get in, you can only deal with ±7 at one time </li></ul>
    16. 16. <ul><li>Cold Reading / What is your first impression? </li></ul><ul><li> Clothes - Uniform type </li></ul><ul><li> Body type </li></ul><ul><li> Gender/Age </li></ul><ul><li> Ethnicity </li></ul><ul><li> Manners/Discipline </li></ul><ul><li> Physical Markings </li></ul><ul><li> Smell </li></ul><ul><li> Teeth </li></ul><ul><li> Hands </li></ul><ul><li> Interaction </li></ul>
    17. 17. Micro Expressions: Based on the system which Dr.Friesen developed, we can divide about 1000 unique facial expressions which are exposed by the neurological connection between the emotions and the 43 muscles we have in the face. This can be used to find out if a person lies to you. One should not underestimate what you can see in the eyes. With a bit of training you can see if a person sees a video picture in the &quot;mind's eye&quot; (visual) or is listening to an internal recording (auditory), or if she/he is concentrating on feelings (kinaesthetic).
    18. 18. Micro Expressions: some charts from Dr. Lightman:
    19. 19. <ul><li>Intelligence Gathering before 1st customer meeting: </li></ul><ul><li>Internet search: </li></ul><ul><li>Maltego </li></ul><ul><li>GOOGLE!/LINKEDIN </li></ul><ul><li>theHarvester </li></ul><ul><li>BundesAnzeiger </li></ul><ul><li>http://www.onstrat.com/osint/ </li></ul><ul><li>whois </li></ul><ul><li>Social Media </li></ul><ul><li>Physical Recon </li></ul><ul><li>visit the place, i.e. as customer </li></ul><ul><li>building </li></ul><ul><li>video surveillance </li></ul><ul><li>entry systems </li></ul><ul><li>security/alarm systems </li></ul>
    20. 20. <ul><li>Meet the Client: </li></ul><ul><li>find out what his business is </li></ul><ul><li>find out about the company's hierarchy </li></ul><ul><li>customer relations </li></ul><ul><li>vendor relations </li></ul>
    21. 21. <ul><li>Threat Modeling: </li></ul><ul><li>assets (resources which can become targets) </li></ul><ul><li>threats </li></ul><ul><li>vulnerabilities </li></ul><ul><li>attacks </li></ul><ul><li>countermeasures </li></ul><ul><li>1. identify the security objectives </li></ul><ul><li>2. get an application overview </li></ul><ul><li>3. decompose the architecture </li></ul><ul><li>4. identify threats </li></ul><ul><li>5. identify vulnerabilities </li></ul>
    22. 22. <ul><li>Threat Modeling: </li></ul><ul><li>STRIDE ­ Model </li></ul><ul><li>S poofing Identity </li></ul><ul><li>T ampering with Data </li></ul><ul><li>R epudiation </li></ul><ul><li>I nformation Disclosure </li></ul><ul><li>D enial of Service </li></ul><ul><li>E levation of Privilege </li></ul>
    23. 23. <ul><li>Threat Modeling: </li></ul><ul><li>DREAD ­ Model </li></ul><ul><li>D amage Potential </li></ul><ul><li>R eproducibility </li></ul><ul><li>E xploitability </li></ul><ul><li>A ffected Users </li></ul><ul><li>D iscoverability </li></ul>
    24. 24. Threat Modeling:
    25. 25. <ul><li>The Assessment: </li></ul><ul><li>Storyboard </li></ul><ul><li>Team </li></ul><ul><li>Insertion point </li></ul><ul><li>Rally point </li></ul><ul><li>Hideout </li></ul><ul><li>Infiltration </li></ul><ul><li>Find & fetch the data </li></ul><ul><li>Exfiltrate the data </li></ul><ul><li>Passive/Active compromise </li></ul><ul><li>Backup plan </li></ul><ul><li>Writing report </li></ul><ul><li>Business impact analyses </li></ul><ul><li>Customer meeting </li></ul><ul><li>Customer trainings </li></ul>
    26. 26. <ul><li>Infiltration: </li></ul><ul><li>tailgating / piggybacking </li></ul><ul><li>steal fingerprints </li></ul><ul><li>use of RFID skimmer </li></ul><ul><li>Copy entry badges, i.e. with a Proxmark III </li></ul><ul><li>Car key skimmer </li></ul><ul><li>drop 32GB USB key </li></ul><ul><li>pick locks </li></ul><ul><li>entry as vendor </li></ul><ul><li>entry as client </li></ul>
    27. 27. Example Infiltration Hardware:
    28. 28. <ul><li>Finding and fetching data: </li></ul><ul><li>Printer </li></ul><ul><li>Spearphishing </li></ul><ul><li>Dumpster diving </li></ul><ul><li>0x41414141 </li></ul><ul><li>Keylogger </li></ul><ul><li>l0phtcrack </li></ul>
    29. 29. <ul><li>Exfiltrate Data: </li></ul><ul><li>USB key </li></ul><ul><li>printout in trash </li></ul><ul><li>over the net </li></ul><ul><li>Photo </li></ul><ul><li>GSM </li></ul><ul><li>Noise </li></ul><ul><li>i.e. http://cs.tau.ac.il/~tromer/acoustic/ </li></ul>
    30. 30. <ul><li>Active Compromise: </li></ul><ul><li>Alarm system </li></ul><ul><li>Video surveillance </li></ul><ul><li>Employee/Guard/Dog </li></ul><ul><li>IDS/IPS </li></ul>
    31. 31. <ul><li>Passive Compromise: </li></ul><ul><li>Employee has a hunch but can't grab it </li></ul><ul><li>Admin/User changes password </li></ul><ul><li>Your machine loses network </li></ul>
    32. 32. Thx for listening! See/hear me at: http://youtube.com/theAluc ...I guess

    ×