Avsnittet: 184 – Martin Mazur om DevSecOps
Inspelat: 2022-10-24 (publicerat 2022-10-30)
Deltagare: Mattias Jadesköld och Martin Mazur.
Detta avsnitt är ett samarbete med tretton37.

Lyssna på avsnittet – DevSecOps

Medan du lyssnar

Då jag var frånvarande, är det som att lyssna på vilken annan podd som helst och det är en märklig upplevelse när det är en podd jag normalt är med i. Ämnet är DevSecOps och Martin är intressant att lyssna på och jag gillar hans metafor om att kasta över väggen. Alltså avdelningar som skickar programvaror och uppdrag mellan varandra utan att egentligen prata med varandra. Det är så det varit och Martin förklarar varför det är en så dålig idé. Håller 100% med på hans resonemang.

Det liknar väldigt mycket de föreläsningar jag och Mattias gjort tidigare på t.ex. Netnods säkerhetsdagar 2019 och hos Nordlo Borås. Det finns liksom ingen ”säkerhetsavdelning” längre på de flesta ställen. Så alla måste bära säkerheten och alla måste prata med varandra. Säkerheten måste vara med i alla delar av processen. Alltså det vi kalar DevSecOps.

Behöver vi pentestare?

Hans diskussion av pentester håller jag med om i stora drag, men jag vill ge min egen syn på det hela. Martin säger att pentester bara är ett certifikat på att någon utestående kollat och godkänt produktion. Han säger att man lika gärna kan göra testerna själva med Burp Suite. Jag håller med i att man ska ”pentesta sig själv”, men…

Ett pentest är ett sista kvalitétsarbete innan man går i produktion. Jag anser att pentester är avgörande och nödvändiga för att kunna gå i produktion. Men om man inte testat själv internt, gjort kodgranskningar och som Martin påpekar haft arkitekteterna med från början, ja då kommer pentestrapporten bli trist att läsa.

Sen är pentestare inte någon kör Burp suite och skickar över vad de hittat. Jag jobbar mycket med Burp suite som pentestare och kan säga att automattesterna är väldigt bra, men ändå lätt missar uppenbara fel. Den kan inte heller hitta logik-fel, då detta kräver att man mappar upp flödena inom programmet i huvudet. Själv är jag väl en sorts DevSecOps, när jag jobbar normalt.

DevSecOps vs pentestare

Som pentestare vill jag hitta vägar in mer än något annat, så jag använder Burp för att hitta ”points of interests”. Dessa användbara i ett senare skede, medan man kör testerna kan man då förbereda manuella tester av dessa ömma punkter. Dessa gör jag genom att testa om det till exempel finns någon SQL-backend att bråka med eller varför inte en XSS (Cross-site scripting) ? Men jag måste också sätta mig in i hur applikationen fungerar och försöka ändra dessa för att se om jag kan hitta några vägar in.

Ur verkligheten:

• Ett API ger rabatter på priserna om man är Britt- eller Dansk. Vad händer om jag skickar in dessa landskoder när jag är inloggad som en Svensk?
• Ett system skickar mail till den som glömt sitt lösenord. Kan jag skicka 3000 var mail till andra personer?
• Ett system skickar över priserna till webbläsaren. Vad händer om jag ändrar dem och skickar tillbaka dem? Kan jag köpa en Boeing 747 för en dollar?
• Ett system verkar ta emot data utanför headers. Kan jag prata med mailservern? Vet DevSecOps-snubben om att jag gör det?
• En endpoint på ett API kan användas för att slå upp sin IMEI-kod (unikt id på en mobiltelefon) till telefonen. Kan jag få veta någon annnas genom att mata in kända telefonnummer? Kan jag få veta Ulf Christerssons?
• Ett system hindrar dig för att sätta betyg med stjärnor mer än en gång per låt. Vad händer om du klickar som en dåre på alla stjärnorna, så att 5-10 anrop kommer till backend-systemet samtidigt. Full disclosure, detta var ett riktigt misstag gjort av mig i en av mina utvecklingsprojekt.
• Ett order-API kontrollerar din identitet innan den ger dig data, medan du får tala om vilken grupp du tillför. Vad händer om jag tar ändrar värdet ”Group”:”Customers” till ”Group”:”Administrators” ?

Burp kommer aldrig kunna testa sådana här saker. Det krävs en tänkande människa som planerar, medan han läser loggarna från Burp, Zap, Commix, Dirbuster eller Metasploit.

Länkar – DevSecOps

• Digitala val?
• Ökad säkerhet kräver kulturförändring
• Nordlo

Felaktigheter

• Inget att rapportera denna gång. Kommentera gärna om ni inte håller med om hittar fel i något vi sagt.

Inlägget #184 – Martin Mazur om DevSecOps dök först upp på IT-säkerhetspodden.

Avsnittet: 150 – Att arbeta med MITRE ATT&CK
Inspelat: 2021-01-21 (publicerat 2022-01-23)
Deltagare: Mattias Jadesköld och Erik Zalitis
Detta avsnitt är ett samarbete med Nordlo.

Lyssna på avsnittet – Mitre

Medan du lyssnar

När man lär sig pentesta från början, får man nästan alltid lära sig enligt den där ”tratten” som börjar brett och ospecifikt med att försöka förstå målet och sedan blir allt mer specifikt när man väljer hur man ska slå till.

Och denna ”tratt” har vi nämnt ett antal gånger med början i avsnittet om ”Kill chain”. Först, förstå att sidan har många intressant ämnen. Men denna gång går vi igenom hackarens väg in med guiderna som Mitre publicerat, medan vi försöker få till en kedja av händelser som slutar där hackaren vill vara. Det är viktigt att veta att en bra hackare har ett mål och således inte låter sig distraheras av vad han eller hon ser på vägen. Moderna attackerare vet exakt vad de vill ha ut med attacken.

Varje steg finns i guiden, som går att grotta sig ner i, men vi pratar om dem på en hög nivå och exakt vad de kan tänkas betyda i verkligheten. De är:

• Reconnaissance
• Resource Development
• Initial Access
• Execution Persistence
• Privilege Escalation
• Defense Evasion Credential
• Access Discovery
• Lateral Movement
• Collection
• Command and Control
• Exfiltration
• Impact

Mitre är en ”bläckfisk” till en organisation som har ett förflutet som knuten till Amerikanska militären och då främst flyget, medan den idag är mer av en allmännyttig kunskapsspridare. Dock är det viktigt att inse att den är inriktad på attacker, därför kan man tro att den är till för den som vill lära sig pentesta. Så är det givetvis, men försvararen har mycket att hämta ändå. Med andra ord, det är viktigt att kunna se in i huvudet på attackeraren även för den som inte vet hur man gör attackerna.

Länkar – Mitre

• Nordlo
• Mitre Corporation på Wiki
• Hur man kommer igång med deras guider
• Snowdens Rubiks cube

Felaktigheter

• Inget att rapportera denna gång. Kommentera gärna om ni inte håller med om hittar fel i något vi sagt.

Inlägget #150 – Att arbeta med MITRE ATT&CK dök först upp på IT-säkerhetspodden.

Avsnittet: 131 – Grey hat hackers
Inspelat: 2021-08-18 (publicerat 2021-08-29)
Deltagare:  Mattias Jadesköld, Erik Zalitis

Lyssna på avsnittet

Medan du lyssnar

Vi börjar med att snacka hattfärger och skämta om den onde, den gode och den fule.

Scenario ett: jag hittar en sårbarhet i en webbsida och uppmärksammar ägaren om problemet

Klassiskt white hat. Inget tvivel om saken. Absolut ingen grey hat eller black hat.

Scenario två: jag hittar en sårbarhet i en webbsida, men publicerar sårbarheten direkt till omvärlden.

White hat, trots vad man kan tro.

Här har jag valt att tolka det som en sårbarhet i en produkt som webbsidan använder som till exempel WordPress. Man kan givetvis diskutera lämpligheten av att publicera information om en sårbarhet som finns på en specifik sida direkt till alla utan att ge ägaren chansen att rätta felet.

Att inte vänta med att sprida informationen kallas för full disclosure.

Scenario tre: jag hittar en sårbarhet och meddelar ägaren, men kräver pengar för att fixa den eller meddela den

Här svävar jag mellan grey hat och black hat men landar tillsist i black hat. Det är underförstått i sådana här scenarion att om ägaren inte betalar, kommer sårbarheten säljas eller publiceras.

Scenario fyra: Khalil hittade sårbarhet på Facebook, men de accepterade inte att det var en sådan. Han svarade med att utnyttja den och klottra på Mark Zuckerbergs vägg

Inget problem här: grey hat. Det är visserligen menat för att visa att det är på riktigt, men hade gick för långt. Han borde ha publicerat den enligt ”Full disclosure”.

Scenario fem: Goatse security läcker ut personuppgifter på folk hos kunder AT&T utan att sälja dem eller hot

Hattfärgen är svart, då den skadar oskyldiga. Hade de läckt ofarlig information (om det nu finns någon sådan!), hade det varit gråare skalor.

Sen har vi mr. Raymonds kommentar om hackers vs crackers.

Kom ihåg att en ”hacker” enligt honom är en duktig utvecklare som skapar coola hårdvaror och mjukvaror och att de som vi idag kallar ”hackers” förr i tiden kallades crackers.

If you want to be a hacker, keep reading. If you want to be a cracker, go read the alt.2600 newsgroup and get ready to do five to ten in the slammer after finding out you aren’t as smart as you think you are. And that’s all I’m going to say about crackers.

Eric S. Raymond

.. och sist ut, de nya hattarna, enligt en IT-säkerhetstidning vid namn ”Infosec Insights”. Vi är skeptiska…

Red hat
En white hat som går för långt. IBM vill nog helst inte att man använder denna hattfärg, då de äger företaget med samma namn. Mer grey hat än ”red” och kan lätt sortera under ”hacktivism” istället.

Blue hat
Hackar för att hämnas. Black hat om du frågar mig.

Green hat
Oerfaren hackare, men inte en skript kiddie.

Slutligen vill jag kommentera att hattarna är en filosofisk/etisk diskussion som saknar koppling till all form av legalitet. Alltså, oavsett hattfärgen kan en hackare vara olaglig eller laglig.

Länkar – grey hat

• Grundläggande definitioner av olika hatt-färger inom IT-säkerhet.
• Mer grundläggande om vår älskade och hatade hattar.
• Khalil Shreatehs fadäs mot Facebook.
• Intressant diskussion om Grey hats.
• Goatse security och Weev.
• Erik S. Raymonds ”How to become a hacker”.

Felaktigheter – grey hat

• Inget att rapportera denna gång. Kommentera gärna om ni inte håller med om hittar fel i något vi sagt.

Inlägget #131 – Grey hat hackers dök först upp på IT-säkerhetspodden.

Episode: #117 – Pentest och ekonomi (eng)
Recorded: 2021-03-26 (published 2021-03-28)
Participants: Erik Zalitis and Simon Roe (Outpost24)
This episode is brought to you by SIG Security.

Listen to the episode

Things to ponder while listening

This text and the podcast is in English as mr Roe is a native English speaker.

So where to begin? I will assume you know what penetration testing means. Instead I will try to interpret Simon’s ideas and counter them with my own. I agree with much of what he says, but have some other experiences on some occasions.

Simon likes to talk about the future of pentesting by comparing it to Netflix. Instead of a lengthy negotiation of terms and prices, only to be told ”we will be able to start in eight weeks”, it should be a formalized process and little waiting times. This will mean that recurrent testing with short intervals can be done.

A common process is that you tell the customer that this is a 10 hour test or we need 40 hours. Simon rather tells you that this is what you get for x hours. He also believes that the customer should be able to see the tentative finding as the test runs and then fix them and ask the tester to retest within the tests original time frame.

Let’s first talk about where I agree with him:

The tests must be more formalized. Pentesting used to be long winded negotiation and suffer from some ”rockstar hacker” mentality. The testers were seen as super talented hackers that could warrant the exorbitant pricing. This is thankfully over now. The prices of testing is slowly decreasing as it should and there are many frameworks for testing available. Simon may talk about a Netflix (”Click to order”) approach, but for me it looks more like the ”order a new server by calling the customer manager” as opposed to the modern ”click a button to provision a new server on Amazon AWS”. I’m 100% with Simon here.

The reports and status should be available on a portal. This can make the process of delivering the bad news more secure, so the company gets the report and not some opportunistic hackers. The portal must have very heavy security and also feature automatic destruction of data and multifactor authentication not to say auditing.

Where I have other views on the matter

He wants to publish results on the portal as the test proceeds and also let the tester re-test (as I wrote previously). This is not something I would do. The rationale is that test must be allowed to finish before analysis can be done. Also, remember, we have a limited amount of testing hours. Retesting within those will consume time from completing the principal attacks properly. Also, I believe it will not give the customer a chance to understand the underlying problems before fixing them.

Then when it comes to the negotiation of the time frame, I see it a little bit differently.

I believe the correct approach to decide a time frame for testing is:

1. Get the size of the environment to be tested.
2. Build attack scenarios (e.g. Unauthenticated attack followed by a authenticated attack against…)
3. Decide knowledge profile (White/Gray/Black hat)
4. Decide location (e.g. On premises, over VPN or from the Internet)
5. Decide the type of attacks (e.g. injections, buffer overruns, but not DDOS)
6. Calculate a reasonable amount of time for the planned attack given the factors above
7. If the customer wants to shorten the suggested time frame, it’s not a problem, but will yield less results.

This means, the test can be properly defined and accepted.

To sum it up, I like the idea of optimizing the pentesting procedures in order to make it behave like any other service you purchase and believe that Simon’s ideas are a good way to step in exactly that direction.

But what about going even further? I have an idea too:

Create a governing body for pentesting that oversees the process. It should be voluntary for testing companies to join, but can be used to prove that ”we’re a part of the international ethical hacker congress” (or whatever such an organization may be called). Part of the organisation can be making sure testers work, plan, attack, report and negiotiate jobs in a very similar way. The may create tools, procedures and provide a things like templates for reports and automatic data exports so reports from different testing companies can be loaded into an application to compare and summarize them. Some may think that ISC2 or ECCouncil could do this, but I think a large scope is needed for this.

Links

• SIG Security
• Outpost24
• Simon Roe – Product Manager at Outpost24

Errata

• None at this time. Please comment below if you find something that needs correction.

Inlägget #117 – Pentests and the economy (In English) dök först upp på IT-säkerhetspodden.

Avsnittet: #109 – Hur arbetet blir proaktivt
Inspelat: 2021-01-29 (publicerat 2021-01-31)
Deltagare: Erik Zalitis, och Mattias Jadesköld

Lyssna på avsnittet

Att fundera på medan du lyssnar

Man skulle faktiskt kunna säga att detta avsnitt är en fortsättning på det om Insider-hoten, då det diskuterar på en mer konceptuell nivå hur problemen kan lösa genom att uppnå ett proaktivt beteende istället för att reagera i ren panik som vanligt.

Vi kommer tillbaka till ämnena ”skapa en säkerhetskultur” och ”kunna upptäcka hot”. Men denna gång hör det till en mycket bredare blick över hur ett företag eller organisation ska kunna försvara sig.

Så… Proaktivitet kan väldigt enkelt ses som två beteenden:

• Nostradamus-läget, där man försöker förutspå attacker.
• Reagera-snabbt-läget, där man reagerar på indikatorer på att något på gång innan attacken egentligt börjar lyckas. Denna Proaktivitet är dock även en form av reaktivitet, dock inte på fullbordat faktum. Tänk dig mer som att gå till doktorn för att få veta om det där konstiga födelsemärket är farligt eller inte.

Förresten, en triljon är en etta med 18 nollor efter sig. Alltså 10¹⁸. Nu vet du mer en vad jag gjorde när jag spelade in avsnittet.

Din verktygslåda

Threat hunting

”Pentestning med silkesvantarna på” eller kanske ”etisk hackning med vapnen säkrade”. Man tittar på miljön som en hackare och försöker förstå hur långt en sådan skulle kunna ta sig om det vore på riktigt. Detta är något de flesta i IT-säkerhetsbranschen gjort när de går igenom det som ska installeras. Men här sker det mer systematiskt och man går då igenom allting steg för steg.

En kund skulle kunna be konsulten gå igenom miljön och svara på hur långt en Ransomware-attack skulle kunna gå.

Ethisk hacking (Pentester)

Kan en konsult bryta sig in? Och hur långt kommer denne? Ibland kanske man inte kan ta sig hela vägen, men dock göra miljön otillgänglig eller radera information. Kanske är ett total övertagande i sig inte heller det värsta som kan hända, utan det är när organisationens data kopieras av hackarna och därför läcks. Detta är ganska garanterat att ske som en effekt av ett totalt övertagande, men det behöver inte gå så långt för att känsligt data ska bli tillgängligt för hackarna. Så även mindre attacker som inte ”når hela vägen” kan vara förödande. Många attacker mot klienter bygger faktiskt på att INTE ta över systemet, eftersom data kan nås av den användaren som är inloggad och då kan även hackaren göra det. På det sättet är det lättare att inte skapa larm i övervakningen men fortfarande få tillgång till datat. Case in point ”Living of the land” där man använder program och funktioner som redan finns på datorn och oftast nöjer sig med att köra dem med den inloggade användarens rättigheter.

Så ett pentest är nödvändigt för att kunna stänga alla vägar som går att hitta. Jag säger att med tillräckligt med tid, kan en pentestare ”ta sig in”. Detta borde kanske klargöras lite. ”Ta sig in” är ordmässigt ett totalt övertagande, men jag vill faktiskt även inkludera att man läcker data, gör systemet otillgängligt eller kan ändra data utan rättigheter i detta begrepp.

Pentestaren bryter sig in och dokumenterar hur detta gick till.

Bygga en säkerhetskultur

En repetition från avsnittet om Insiders men ”kulturskapande” är överlägset att bara utbilda folk som sedan glömmer allt. Skapa en medvetenhet där alla kollektivt minns, skyddar och förutsäger attacker. Grupptryck har en negativ klang, som det väl förtjänar, men att använda det för att skapa ett ”På den här arbetsplatsen gör vi inte såhär”-tänkande kan istället tvinga fram ett säkerhetsmedvetet beteende.

DISA (digital informationssäkerhetsutbildning för alla)

Så hur börjar man bygga denna kultur? Prova DISA – en sentida variant av ECDL, men fokuserande på säkert beteende istället för att lära ut hur man använder sin dator (vilket idag är ganska överspelat).

MSB ligger bakom DISA, som har en mycket bra ”frågesport”-funktion där du kan testa hur du beter dig i riktiga situationer. Det är hygglig trivialt, men inte så mycket menat att lära folk självklarheter som att faktiskt se till att dessa tankar finns fräscht i minnet.

En mycket användbar strategi för alla typer av organisationer som inte har egna motsvarigheter.

Omvärldsbevakning

Två saker: du måste veta vad som händer i det stora och du måste veta vad som händer nära dig. När dig är både i din bransch, ditt fysiska område, med dina konkurrenter och hur attacker och försvar utvecklas.

Definition av ”omvärlden”: (substantiv) INTE DU!

Det vill säga allt du inte har direkt kontroll över. Larvig definition? Definitivt inte. Tänk på detta när du bygger din proaktiva säkerhet.

Errata

• Inget att rapportera denna gång. Kommentera gärna om ni inte håller med om något vi sagt.

Länkar

”Frågesport” a’ la DISA:
https://webbutbildning.msb.se/utb/DISA/

En inledning tilll Proaktivt försvar:
https://blog.morphisec.com/what-is-proactive-cyber-defense

Olika taktiker för detta:
https://www.entrustsolutions.com/2020/11/13/proactive-vs-reactive-cyber-security/

Jag ger inte mycket för denna artikel. Det refererar till en undersökning som finns på en Casino-site:
https://chiefexecutive.net/almost-90-cyber-attacks-caused-human-error-behavior/

Homer Simpson vet hur det är med statistik (Vilket jag ironiskt nog felciterar i avsnittet):
https://www.youtube.com/watch?v=sm7ArKlzHSM

Simpsons paradox har inget att göra med Homer, men är ett läskigt bevis på hur man kan misslyckas med att tolka statistik:
https://www.youtube.com/watch/ebEkn-BiW5k

Hur definierar man omvärldsbevakning?
https://www.informationssakerhet.se/metodstodet/analysera/#omv%C3%A4rldsanalys

Inlägget Show Notes för #109 – Hur arbetet blir proaktivt dök först upp på IT-säkerhetspodden.

Några tankar
Avsnittet är i någon form en fristående fortsättning på våra avsnitt om Etisk hackning och Cyber Kill chain. En del av ämnena togs upp redan där, men i detta avsnitt fördjupar vi diskussionen om svårigheterna man möte när man testar system.

Denna gång försöker vi också fundera på vad som bör ingå i en bra rapport:

• Ska ha en sammanfattning (Executive summary) med övergripande risk.
• Lista alla mål som man kommit överens om.
• Lista alla sätt det gick att ta sig in.
• Ranka sårbarheter enligt något system som är enkelt att överblicka.
• Föreslå förbättringar och lösningar.
• Rapporten anpassas i omfång och detaljnivå efter uppdragets storlek och karaktär.

Allmänt om pentester, SDLC och när man gör tester

Pentester sker normalt i samband utrullningen av ett nytt system eller i samband med utrullningen av en ny version av ett system.

Testerna simulerar attacker och dokumenterar allting som upptäckts “på vägen”.

Pentester utföres alltid av en oberoende granskare.

Vår lista på de nio vanligaste felen som görs vid pentester:

1 – Att inte förstå avgränsningarna I uppdraget
2 – Att inte prioritera riskerna
3 – Att använda fel verktyg
4 – Att göra en dålig rapport
5 – Att bara ”kryssa för boxar” istället för att ge kreativiteten en chans.
6 – Att skada produktionssytem
7 – Att använda gammal teknik och ha gammal kunskap
8 – Att inte göra återkommande tester
9 – Att kunden inte genomför förbättringarna som föreslås.

Inlägget Show notes för #72 – Nio fel dök först upp på IT-säkerhetspodden.