Semester
Nu har det varit semester sedan några dagar tillbaka så bloggen kommer att gå ner på sparlåga under sommaren. Det kanske dyker upp något om egyptisk hotellsäkerhet men förhoppningsvis inte. :-)
Ha en trevlig sommar och på återseende!
--
Stefan Pettersson
Ha en trevlig sommar och på återseende!
--
Stefan Pettersson
Drift
Idag var en av de där läskiga dagarna när man jobbar på drift, disaster recovery-övningar. Idag provade vi hur de viktiga servrarna klarade av ett plötsligt strömavbrott. Oavsett hur bra koll man (tror att man) har på hur tjänsterna på en server fungerar är det rätt nervöst att dra ut sladdarna när den är uppe i nästan två hundra dagar uptime... Naturligtvis gick det inte som planerat (det gör det aldrig):
Server- och nätverksdrift är relativt osexigt, vissa kallar det till och med "förvaltning" för att göra det ännu värre. Jag skulle dock argumentera för att det är under driftfasen som säkerhetsarbetet har störst betydelse. Tyvärr har det blivit modernt att, nästan uteslutande, problematisera applikationsutvecklingen och säga att det är där slagen kan vinnas i framtiden. Undertecknad inkluderad. Vi har nog rätt. På sikt. Men inte riktigt än.
Men egentligen är det ganska enkelt. Brandväggar, patchar, långa lösenord, övervakning, åtkomstkontroll, logghantering och alla andra grejer är det som håller oss flytande medan vi fortfarande lever med dåligt utvecklade system. Det är inte utvecklare som håller våra nätverk säkra. Inte än. Det är fortfarande driften som kan bära största vikten.
(Med reservation för dålig drift... naturligtvis.)
--
Stefan Pettersson
- 07:00-08:00 klipp strömmen till servrar, håll tummar
- 08:00-10:00 få tjänster att fungera igen innan någon märker något, tandgnisslan
- 10:00-12:00 lura ut hur man undviker problemen nästa gång, ljus i tunneln
- 12:00-18:00 ändra configs och uppdatera dokumentation, lite bättre än igår
Server- och nätverksdrift är relativt osexigt, vissa kallar det till och med "förvaltning" för att göra det ännu värre. Jag skulle dock argumentera för att det är under driftfasen som säkerhetsarbetet har störst betydelse. Tyvärr har det blivit modernt att, nästan uteslutande, problematisera applikationsutvecklingen och säga att det är där slagen kan vinnas i framtiden. Undertecknad inkluderad. Vi har nog rätt. På sikt. Men inte riktigt än.
Men egentligen är det ganska enkelt. Brandväggar, patchar, långa lösenord, övervakning, åtkomstkontroll, logghantering och alla andra grejer är det som håller oss flytande medan vi fortfarande lever med dåligt utvecklade system. Det är inte utvecklare som håller våra nätverk säkra. Inte än. Det är fortfarande driften som kan bära största vikten.
(Med reservation för dålig drift... naturligtvis.)
--
Stefan Pettersson
Databaskryptering
I mer eller mindre alla system som utvecklas nuförtiden ingår en databas. När säkerhet sedan kommer på tal i samband med utvecklingen kommer ofta också frågan; "borde vi kryptera databasen?". Svaret är (kanske som vanligt) att det beror på... Vem är det du skyddar dig emot och vad menar du egentligen med att "kryptera databasen"? Min uppfattning är att databaser lagrar data, vad innehållet är (utöver datatyp) ska vara egalt och är none of databasens business. På uppmaningen "ge mig kolumn k för de rader där kolumn l är lika med n" ska databasen bara returnera cellens värde, inte oroa sig över innehållet. Krypteringen av innehållet borde alltså skötas av den som förstår det, i vårt fall applikationen som lagrar data i databasen. Databasen själv ska inte ha något med krypteringen att göra.
Cryptography was invented to protect communications: data in motion. This is how cryptography was used throughout most of history, and this is how the militaries of the world developed the science. Alice was the sender, Bob the receiver, and Eve the eavesdropper. Even when cryptography was used to protect stored data -- data at rest -- it was viewed as a form of communication. In "Applied Cryptography," I described encrypting stored data in this way: "a stored message is a way for someone to communicate with himself through time." Data storage was just a subset of data communication.
Historically, the reason key management worked for stored data was that the key could be stored in a secure location: the human brain. [...] In a sense, the keys were stored in a "computer" that was not attached to any network. And there they were safe. [...] This whole model falls apart on the Internet. [...] Keys can no longer be stored in people's brains. They need to be stored on the same computer, or at least the network, that the data resides on. And that is much riskier.
Cryptography was invented to protect communications: data in motion. This is how cryptography was used throughout most of history, and this is how the militaries of the world developed the science. Alice was the sender, Bob the receiver, and Eve the eavesdropper. Even when cryptography was used to protect stored data -- data at rest -- it was viewed as a form of communication. In "Applied Cryptography," I described encrypting stored data in this way: "a stored message is a way for someone to communicate with himself through time." Data storage was just a subset of data communication.
Historically, the reason key management worked for stored data was that the key could be stored in a secure location: the human brain. [...] In a sense, the keys were stored in a "computer" that was not attached to any network. And there they were safe. [...] This whole model falls apart on the Internet. [...] Keys can no longer be stored in people's brains. They need to be stored on the same computer, or at least the network, that the data resides on. And that is much riskier.
Argumentet är alltså att det är meningslöst att kryptera databasen eftersom nyckeln ändå måste finnas på datorn ifråga. Jag tycker att det här är en för stor förenkling av situationen, man kan enkelt tänka sig en situation där en applikation måste lagra känsliga data i en databas där man inte har kontroll över databasen. Databasen kan skötas av någon DBA du inte litar på eller den kanske delas av applikationer som är sårbara för t ex SQL injection.
Men, om du krypterar data i applikationslagret innan du lämnar över det till databasen så behöver du inte lita på att den kan hålla dem hemliga. Dock så kvarstår Bruces poäng; om någon får tillgång till applikationslagret så är spelet tyvärr slut. Men så hade det ju varit om du låtit bli att kryptera också plus att databasen utgör en sårbarhet.
--
Stefan Pettersson
