En vanlig idé som ofta tas som självklar sanning är att människan kan lära av historien och att läsa om historia realiserar det meningsfullt (och får vi anta förutsätts mätas i effekt av elevernas resultat i provskrivningar resp. ex. hur många exemplar av en doktorsavhandling någon egentligen läser och/eller betalar för utanför biblioteken).
Eftersom sådant belastar vår gemensamma budget om än numera väsentligt mindre än för några år sedan kanske värt att fundera lite över. Vi kan tycka oss se en begränsning i att tiden, energin och/eller kostnaden för att realisera lärdomar oavsett om det handlar att inse dem, reealisera motmedel eller oavsett kostnad egentligen bara kommer ner till att man ska bry sig nog att titta efter.
Nedan ser vi att mysql loggat lösenord (markerat svart) i sin historik-fil. Vanligt problem längre tillbaka allmänt för unix-systemens historik-kontroll. Där var självklart utmaningen större för att komma ifrån problemet eftersom alla möjliga applikationer, kommandon m.m. slurpas in i historik-filerna om de skrivs från en skal-tolk. Mysql åtminstone inte tycks lära av historien eller vara särskilt engagerad i frågan.
Aktuellt filnamn för kommando-historik klipptes ut från längre ner i emacs-fönstret för att spara utrymme: .mysql_history
Problemet här är kanske inte just att lösenord till mysql loggas ner med filaccess ej avspeglande rättigheterna till själva databasens filer. Det är endast ett problem om lösningar som mysql i sig själva bibehåller sådan säkerhet att de inte måste kapslas in. Jag har inte någon uppdaterad bild av vad som gäller där men det skulle förvåna mig ordentligt om vanlig sund standard på drift-kritiska system är att installera mysql och liknande off-line, göra stor manuell konfiguration av säkerhet och bäst kapsla in dem (och antagligen gärna kört lokalt underliggande behov när möjligt hellre än att efterlikna mer krävande lösningar och system där databas-servrar behöver separeras när ej nödvändigt).
Problemet är att det säkert inte sällan är samma lösenord som loggas som användar-kontot (kanske dedikterat rent av för att hantera diverse "server-tjänster" som databas, webbserver (data- och presentation layer nedan för the business layer - tillsammans the cake och bland kompetens-experter levererande till inköpande företag the sweet cake när riktigt komplexa och gigantiskt affärskritiska relativt leveransförmåga resp. budget internt behöver byggas om - som vi mer coola dataarbetare kallar det).
Vidare numera som jag lärde första gången testande Ubuntu finns den vanliga och ofta tror jag utmärkta lösningen att använda sudo hellre än att kasta upp under-processer till tolkar med root-rättigheter. Nackdelen när vi är på server-system är ju dock att incitamentet och upplevt behov att använda separat lösenord och användarnamn reduceras. Så inte otroligt kan lösenord vi kan starta upp processer med allmän root-rättighet fastna i dessa logg-filer.
Varande mycket begränsad i min erfarenhet av databaer relativt katalogtjänster som X.500 och LDAP var det som konsekvens av att jag lärt av historien som gjorde att jag upptäckte det. Min hemkatalog är en av potentiella junk-punkter jag rutinmässigt kontrollerade efter okänd post-skit som konsekvens av att installerat MediaWiki, Semantic-Wiki, Mysql m.m. För mig dock ett debug-lösenord utan andra möjligheter lokalt (och ej det aktuellt för databasen vid tidpunkten när det upptäcktes: det riktiga lösenordet får ni gärna försöka att tortera mig till att bekänna - det kan ej lyckas då mina relaterade minnesfunktioner korrekt säkerhetsmässigt går garbage för sådant här vid hög stress i direkt omedelbar tid och här dessutom ett helt nytt lösenord).
Information relaterat att stänga ner denna loggningsfunktion finns hos Mysql.com:
Korrekt metodik när vi skapar värde genom att lära av historien är dock att inte använda leverantörernas informationskällor primärt - eller åtminstone inte ensamt före driftsättning - utan att söka vad känt från fler informationskällor. Längre bakåt var som sista - försök ta det sista kanske ej med konfigurations-anvisningar, patchar m.m. - kontroll Bugtraq bra men vilken tjänst eller diskussionspunkt motsvarande snabb idag avstår jag från att rekommendera då jag ej använt dem tillräckligt på några år för att bedöma det. Vanligt räcker dock någon jämförbar diskussionstjänst för att komplettera leverantör resp. sammanfattande anvisningar från andra informationspunkter (ex. för en av de mest långsamma men istället tydligare och med känt varumärke: Cert.org - eller varför inte dess syster Auscert (Mysql sökning) som av och till genom åren överraskat lite som bra läspunkt.
CERT är dock en acceptabel och för många troligt praktiskt fungerande tjänst för mer grundläggande och pedagogiskt lättarbetade instruktioner och informationsmeddelanden för säkerhetsdefekter d.v.s. kanske oftare en god punkt för kompletterande information om ex. Mysql förutom en eller flera snabbt och bredare informativa tjänster (jfr Bugtraq diskussioner). Ett exempel på vad de utvecklar och/eller rekommenderar varierat är:
Vilken jag väljer att komplettera (prospekterande: gissande att den ej berör det) att verksamhetssystemen i större organisationer alt. när hög säkerhet är en faktor bör:
- Bedöma händelsen att en realiserad källa till ex. informationsläckage faktiskt är den korrekta.
- Och kärnan här:
- Ej uteslutande relaterat att felaktig identifikation av läckan gjorts.
- Utan också inkluderande mest "extremt" att hela konceptet som sådant är påhittat.
Större organisationer håller "alltid" på med en samma koncept som verkar - och ofta är - väldigt bra som idé men där som grundregel gäller att större organisation - därmed oftare större projekt - kommer med högre komplexitet och fler projektrelaterade problem. Det gäller självklart också säkerhetsfunktionerna men där inte sällan problem som sådana kan bli mindre märkbara.
Hanterande säkerhet på en mer abstrakt-nivå eller i samarbetsmöten med andra större organisationer är därför en sund utgångspunkt att oavsett hur smarta idéer de har ska vi utgå från att det är defunkt och läcker, och om de läckt att ev. koncept de kanske betar andra läckor med genomtänkt gjort för att i sig ej läcka, är vad vi ska anta också defunkt med totalt ökad risk om komplexitet totalt ej reducerats genom förenklingar i övrigt.
Eller som ex. två på problem vi kan se denna skeptisim krävs för när säkerhetsfunktionen i sig är korrupt och kanske via initiativ ej lätt noterade i egentligt ursprung drar igång något stort system både för att göra annat svårare att se resp. dölja sig själva genom annat indikerat.
Jag är ex. på flera sätt inte direkt övertygad om hela det här Manning-konceptet också om jag heller inte kan påstå att jag inte tror på "det" eller "dennes existens" "historiskt sedan födsel". Men som på Seotaktik.com diskuterat innan han blev känd, därefter följt där en tid, och senare mer kontinuerligt här ett par år ej direkt relaterat just Mannings och den magiska PDA'n tillsammans med any soldier can access it all in storage effecient files men konceptet att saker kanske läcker spridande problem påverkande också risker och problem troligt de flesta kan acceptera reella och moraliskt viktiga att hantera oavsett hur man ser på USA's problem eller problem att hantera där (jfr ex. en krönika publicerad i Aftonbladets tryckta tidning i dag där skribenten åtminstone i rubrik och första rader funderade kanske lite mer positivt om Manning borde ha fredspris och viktigare mer centralt utanför rubrik-optimering att personer som läcker information oavsett hur moraliskt korrekta de själva eller kanske ens dom dominerande befolkningslagren menar - där jag ej är övertygad om att just Manning är aktuell där men vanligare relaterat företag spridande gifter orsakande flera hundra cancer-fall i U-land) som att USA ex. kan tänkas ha information om personer engagerade långsiktigt demokrati-arbete i sina system som del av ex. samarbeten aggrergerande data eller del av deras "omvärldsbevakning i det mer dolda" och i sin tur läcker iväg till Iran, Kina eller vad nu aktuellt.
I allt om man hör till vad tvingande eller filosofiskt energi-effektivt får man ju i sådant åtminstone reflektera över risken att man själv kanske medverkande till ett i så fall realiserat problem fogging annat eller ge idé om en stor honeypot man ej kan relatera eller borra för förståelse rörande vilka risker den löser, orsakar eller döljer.
Och tänkande i risker föga troliga men potentiellt "logg-förstörande" i events ej enkla eller självklara att se för att spara undan eller ens göra det är jag inte så där självklart rekommenderande eller tyckande att Wikileaks-ledaren (minns ej namnet) gör helt fil i att sitta på ambassaden. Fodrar verkligen mycket mer information än jag har eller vet är känt för att kunna bedöma ens i närheten av seriöst om ex. ett direkt hot mot hans liv är tänkbart här eller i annat land oskyddad.
Oavsett hur, var, när enligt vems bias, motivation och primacy effect vad jag ej aktivt bevakar ens nyhetshändelser för. Jag tror dock säkert att andra gör det åtminstone i mer allmänt koncept. Vi ska generellt förstå att stora organisationer ej är små elit-styrkor tränade för att göra ett fåtal moment rätt och snabbt (och lite omvänt från det gärna sätta föreställningarna om NSA i perspektiv av föga känt om deras effektivitet att bedöma från och vad känt allmänt för gigantiska organisationer i värde-skapande relativt pengar).
