All the talks i saw about SE so far just showed which good SE's the speakers are. I try to do another approach, what if i get in and don't know what to do then. The talk is about the reconn. before the assessment, the different approaches of SE. Which techniques can one use, how to do a proper intel. and what is useful. How things work and more important why. Which skill set should one have before entering a engagement. And last but not least how do one counter a SE attack.
Preface:
Needed Skillset:
-physical (ie.NLP)
-logical Customer Preparation:
-theoretical models of attack
-check customer needs by his business
-Contract
Preparation & Reconnaissance:
-threat modeling
-physical
-logical
Project Planing:
-Storyboard
-the target
-infiltration
-fetching data/reaching the target
-exfiltrate
-backup plans
Infiltration:
Find & fetch the data:
Exfiltrate the data:
Writing report:
Business impact analyses:
customer meeting:
5. Needed physical/psychical Skillset:-understanding of craftsmanshipideal life experiences as electrician telephone cable Guy computer Mechanic-lock picking-in hostile environment Physical Security-good rhetoric-understanding of the person you approach-a understanding of human psychology-NLPideal Hypnosis
8. What is your first impression?-Cloths Civil/Uniform type -Body type-Gender-Ethnic-Manners/Discipline-Physical Markings-Smell-Teeth-Hands
9. Everyone talks about NLP what is this:NLP is a communications model Created in the early 70’s by John GrinderandRichard Bandler The basisoftheirworkaretheanalysesoftheworkofthetherapists Fritz Perls, Virginia Satir and Milton H. Erickson The N stands for the flow of Neurologic processes in the Human Brain The L stands linguistic what is our capability to speakThe P stands for programming what means the change of the “inner Program” of a Human
10. The Modeling: 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: “From the Basement to the Bedroom” a Pickup guide by Chris Nickerson
11. Understanding keywords and differ between Attributes and states:-A humans Brain can process about 100 trillion terraflops -Your sensors getting 10.000 bit/s -from this 10.000 bits are about 40 being processedThat makes us to “make up” our very own version of this world.
12. How do we use this: -listen in conversations to keywords like “stress” “freedom” “love” etc-find out in which state the person is vs his/her believing-pay attention to micro expressions -understand the difference between a state and a attribute “he feels” vs “he has”
13. 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 at 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)
15. Convert Attributes into States:-try to generate and feel states for yourself -try to generate Statesfrom other people by using the “right” words -find out when these states are appropriate - find the right timing to use these statesDon’t forget: From the 2Mio Bit/s messages you get in you can only deal with ±7 at one time
16. Intelligence Gathering before 1th customer meeting:internet search: -Maltego-theHarvester -BundesAnzeiger -http://www.onstrat.com/osint/-whois -Social Media visit the Place ie. As customer -building-video surveillance-entry systems -security/alarm systems
17. Meet the Client: -find out what his business is -find out about the companies hierarchy -customer relations-vendor relations
18. Treat Modeling: -asset (resources which can become targets) -threat-vulnerability -attack-countermeasures1. identify the security objectives2. get a application overview3. decompose the architecture4. identify threats 5. identify vulnerabilities
19. Treat Modeling: STRIDE Model -Spoofing Identity -Tampering with Data -Repudiation -Information Disclosure -Denial of Service -Elevation of Privilege
23. Infiltration: -tailgating / piggybacking -steal Fingerprint -use of RFID Skimmer -Copy entry badges ie. With a proxmark III -Car key skimmer -drop 32GB USB Key -pick Locks-entry as Vendor-entry as Client
1. Identifikation der „Assets“ bzw. SicherheitszieleAm 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 istes 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 ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier 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 herausstellenAn 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 findenDie 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. SicherheitszieleAm 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 istes 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 ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier 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 herausstellenAn 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 findenDie 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. SicherheitszieleAm 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 istes 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 ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier 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 herausstellenAn 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 findenDie 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. SicherheitszieleAm 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 istes 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 ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier 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 herausstellenAn 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 findenDie 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. SicherheitszieleAm 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 istes 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 ArchitekturEinfache Diagramme und Tabellen ergeben einen groben Überblick über die Softwarearchitektur. Wichtige Anwendungsfälle (engl. „usecases“) und verwendete Technologien bieten Charakteristika, welche helfen, Bedrohungen zu identifizieren.3. Dekomposition der ArchitekturHier 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 herausstellenAn 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 findenDie 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.