Recomendados
Mais conteúdo relacionado
Destaque
Semelhante a 28c3 version of "The engineering part of social engineering"
Semelhante a 28c3 version of "The engineering part of social engineering" (20)
Último
Último (20)
28c3 version of "The engineering part of social engineering"
- 1. The engineering part of social engineering or why just lying your way in don't get you anywhere. aluc#
- 2. I’m Aluc I’m a old hacker who loves the blood of your network
- 3. Preface:
- 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. 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. Example: An 8 year old girl with Tourette's "copied" 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. Example: An 8 year old girl with Tourette's "copied" 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. 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. Experiential Array: Array and Graphic by David Gordon
- 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 "mind's eye" (visual) or is listening to an internal recording (auditory), or if she/he is concentrating on feelings (kinaesthetic).
- 18. Micro Expressions: some charts from Dr. Lightman:
- 24. Threat Modeling:
- 32. Thx for listening! See/hear me at: http://youtube.com/theAluc ...I guess
Notas do Editor
- 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.