... En wie controleert dan weer dat deze broncode dezelfde versie is als die van de in gebruik genomen executables ?

Antwoord: los je op met functionele White box testen.
Met de executable introduceer je het issue van de vraag hoe weet je dat de compiler (welke en welke versie) wel de zelfde exécutable opleverd? Het blikveld op source compileren executable monolitisch is wel er ouderwets.
Met interpreters en de jit benadering moet je je afvragen of dat proces nog wel functioneert zoals zou moeten. Gebruik van dll's en ander dynamische interfaces hebben hun eigen vragen als api interface.

Kunnen de updates/upgrades hier ook worden bekeken, voordat ze vrijgegeven worden?

Verder klinkt het allemaal erg leuk, maar default werken met openstandaarden in MS-Office kunnen en/of willen ze nog steeds niet.

Huh ? En dat zou een oplossing zijn waarmee eventuele achterdeurtjes die ingebouwd zijn in de feitelijk gebruikte source (versus de source je bekeken hebt ) dan uitgesloten worden ?
Hoe stel je je dat voor, voor het formaat projecten waar Microsoft producten uit bestaan ?


Inderdaad kan het veel werk vergen om vanuit de source een bit-identieke versie van wat geleverd is te builden.
Dat vereist tenminste dezelfde versie compiler en build vlaggen, en uiteindelijk nog veel settings die overeen moeten komen met wat de build farm gebruikte . (ook timestamps komen terecht in executable formaten ).


Maar wat hebben JIT en interpreters nu te maken met de vraag of de source die de vendor je laat zien de werkelijke source is van waaruit het product gebouwd is ?

Je krijgt van de vendor object code (of misschien wel bytecode voor een of andere vm) die erg lastig analyseerbaar is .
De vendor heeft het geschreven in een veel beter leesbare taal - (en dat geldt ook voor de [j]vm) , en je wilt jezelf overtuigen dat wat je gekregen hebt aan object code afkomstig is van exact de leesbare source code die je hebt mogen reviewen.

Die achterdeurtjes in Cisco routers (linux based) zijn er ook. Pas nog enkele gedicht omdat code van de NSA tools gelekt is. Ook met linux software is de hoeveelheid code al lang zo dat het niet controleerbaar is.
De achterdeurtjes die in een chip gebakken zijn (verdenking richting huwaei) zul je niet zien net zo min als parallelle hardware systemen die in server ontwerpen vrij standaard zijn.

Een testprocedure kan nooit alles afdekken maar wel een beeld van de kwaliteit geven. (big data)
Voor de werkelijke informatie security afdekking in de operatie kom je toch uit bij ids en siem. Het is een activiteit.
dat steekproefsgewijs valideren (herhaald in perioden) zoals dat bij elke auditing werkt.

IDS intrusion detection systemen
SIEM Secuirtyt Information Event Monitoring.
Het zijn twee benaderingen die door OS beheerders met stokpaardjes tegengewerkt worden. (Noem het met telemetry Logging).

Je moet wel weten hoe met big data om te gaan en nuttig in te zetten. Dat is zinvoller dan met FUD bezig te zijn.
Ooit bezig geweest met dat soort troep dat door externe leveranciers verkeer ontworpen is. Dan ook nog tegen allerlei timing issues aan lopen. Tijdrovend en ondankbaar werk. Heb jij dat soort zaken ook in de professionele omgeving gedaan?

Als je wilt kan ik de typos er wel even uit halen. Was onderweg en zo'n smartphone is niet zo prettig werken. (done)

Krijg je er een pak "ghost writers" bij. Die heeft M$ ook nog bij drukte ingezet.

Lees over genesis van Microsoft code. "In den beginne was er dos en dos zweefde over de code en de compiler zag dat het goed was!". ;)

Even ernstig. Het is gesloten code. Wat te onderzoeken valt en wat niet, daarop heeft men geen zicht, als alles staat of valt met "trust". Het is opgebouwd als laag over laag over laag en belangrijk het houdt zich niet aan standaarden.

Ga er maar aanstaan. Analyseer en test. Neem liever een stel doorknede mensen van de chaos computer club. Doorgewinterde analisten, die bovendien code alles hebben proberen te laten doen wat mogelijk en niet mogelijk is en laat die erop los i.p.v. de Aziatische overheidsdienaren, die gehinderd worden door export restricties, monocultuur, gag orders en zo meer.

Men leeft daar, ik doel op Mainland China, in een M$ mono-cultuur - scan maar eens een Chinese website. Wedden dat je niet onder een asafaweb scan uitkomt. het merendeel is ASP wat de klok slaat.

China werkt wel meer als proeftuin voor het later bespelen van de westerse markt met de daar opgedane big brother trucjes.

Het werken naar de singulariteit en onder controle brengen van het Interweb gaat wel vreselijk snel de laatste tijd.
Dat moet gezegd. Wat denken de anderen hierover of is hun gevoelen?

Karma4, ik denk dat je best een hoop weet van procesmatige security , audits en dergelijke.
Maar houd je liever verre van commentaar op technische details, want daar laat je een heel groot gebrek aan kennis zien.
Wat je daarover debiteert doet erg afbreuk aan de waarde die gehecht kan worden aan je commentaar op het nut van tools en processen .

Wat je schreef over "whitebox testing" heb ik al becommentarieerd.

Dat je meent dat "Cisco routers" "Linux based" zijn is (bijna) totaal onjuist .
Nu moet ik een hele paragraaf besteden om uit te leggen hoever de vier woorden "Cisco routers (linux gebaseerd)" weg staan van de werkelijkheid :

Cisco routers draaien voor het overgrote deel "Cisco IOS" . Dat is een RT OS ontwikkeld door Cisco, stukken ouder dan Linux en op z'n best van heel ver weg verwant aan "iets Unix achtigs" . Nieuwere en high-end Cisco routers draaien op "IOS XR" , en totaal nieuw OS, waarvan de kernel QNX is - Een Unix achtige real time kernel, maar weer beslist geen Linux.
Het userland van IOS XR is volledig van Cisco zelf .
Dan is er "IOS XE" . Dit is de "bijna" caveat die ik moet gebruiken. Hier is de systeem kernel Linux, dat er hoofdzakelijk is om een stel asic drivers te laden en het "Cisco IOS" proces te draaien. Het "IOS proces" is hier userland, en dat is het deel wat alle interactie met de buitenwereld heeft (routing protocollen, ntp, telnet/ssh/ipsec etc etc - en dus het deel waarvan je zorgen moet hebben over vulnerabilities) .
De andere "bijna" caveat is Nexus OS (high end switches ) , wat z'n roots heeft in SAN-OS waarvan de OS kernel weer gebaseerd is op een real time linux . Maar ook hier is het userland wat interactie heeft met de buitenwereld een eigen ontwikkeling.
Ietwat verder weg van Cisco 'routers' heb je Cisco firewalls (Pix/ASA) - Ook die OSen zijn geen "Linux" . Ook geen IOS , de firewall lijn is ontwikkeld door een ander bedrijf dat later door Cisco werd overgenomen. De CLI is min of meer 'ios like' .

Maakt dit uit ?
Ik zeg ja -
Ten eerste omdat het percentage hard gestelde onjuiste beweringen dat iemand doet is voor mij ook een schatting geeft van
hoeveel waarde ik moet hechten aan beweringen over onderwerpen waar ik niet weet of het klopt.

En voor deze specifieke stelling - gegeven dat Cisco's OS'en erg weinig met Linux van doen hebben , kun je product alerts voor Linux niet als een voorspeller beschouwen van product alerts voor Cisco OSen - noch andersom.
Ja, beiden hebben wel eens bugs. En delen wellicht soms "referentiecode" voor sommige applicaties (ik meen dat ook Cisco's NTP implementatie z'n roots had in de bekende ntp.org code , bijvoorbeeld ).

De recent gepubliceerde vulnerability voor IPSec op Cisco routers staat dus los van eventuele vulnerabilities in Linux IPSec code .
De term 'achterdeur' is een oordeel wat hierin voor zo ver ik weet nog niet erg vaststaat - het impliceert een *bewust* geintroduceerde vulnerability, versus een bug .De nadrukkelijke smoking guns van de Juniper Netscreen firewalls ontbreken tot op heden bij de ASA en IOS alerts. Gegeven dat IKE een nogal complex protocol is, is een bug bepaald niet uit te sluiten .

Een code review/audit kan sommige klassen van security issues makkelijk aantonen die met testen vrijwel onvindbaar zijn.
Verder zal de bereidheid tot een code audit de klant vertrouwen geven - uiteindelijk wil de leverancier het product verkopen.
Je zult niet alles kunnen vinden . En verdedigen tegen een kwaadwillende leverancier van het kaliber "de compiler introduceert de backdoor" is vrijwel ondoenlijk.

Ja , IDS / SIEM zijn zeker nuttige technieken, en die moet je vooral niet nalaten. Ik wil ook zeker niet stellen dat als je maar de code geaudit hebt van een ding je verder operationeel nergens meer op hoeft te letten. Beslist niet .

Dergelijke controles zijn standaard onderdeel van een code review (anders heeft zo'n controle immers geen enkele zin)......

"Voor de werkelijke informatie security afdekking in de operatie kom je toch uit bin ids en siem."

LMFAO alsof een IDS je iets vertelt over zaken waarvoor je geen specifieke signatures hebt. Nee, je IDS zal je niet vertellen dat er een onbekende backdoor zit in je OS, in je netwerk apparatuur, en dergelijke. Met de IDS dek je op dit gebied helemaal niets af.

Als onderzoeker ben je "vogelvoer" als iemand met opzet een achterdeur in de code heeft gestopt, bijvoorbeeld een "easter egg".

Is dat met opzet gebeurd, dan kun je nog zo'n goede en ervaren onderzoeker er op los laten, het helpt totaal geen bal.

"Snake oil", je bent namelijk als ontwerper er niet bij geweest en hebt zelf niet gezien "hoe de beren broodjes smeren". Niemand bij zijn volle verstand zal dergelijke code als achterdeur-vrij willen bestempelen.

"Hi-hi-hi, ha-ha-ha, ik stond erbij en ik keek ernaar!".

Waarschijnlijk vindt men het niet. Alleen bij toeval bij geïsoleerd monitoren en bij het zien hoe de code afgehandeld wordt in een samenspel van werken met een geautomatiseerde tool en menselijk bekijken van de beveiligingsrisico architectuur,en dan nog is het vaak een kwestie van puur geluk hebben.

Er moeten duidelijke schema's gehanteerd worden voor het kijken naar de afhandeling van functies. Zonder de daadwerkelijke developers erbij heb je nog niets.

Probleem blijft namelijk het gebrek aan inzicht in de context beveiliging. Je blijft altijd testen met "signatures" en "rules" en krijgt "false positives" en wellicht ook "false negatives". Wat voor reguliere expressies stelt men op tenslotte voor applicatie afhandeling. Hoe gaat men om met het opzettelijk niet gedocumenteerde en daarvan heeft Micro$oft nogal wat in de mouw.

Wat men volgens mij wil bereiken met dergelijke onderzoeken is een commercieel afgedekte zaak door beveiligingsdeskundigen die goed op de hoogte zijn met de gebruikte tool(s) en methode(n) het onderzoek te laten fiatteren.

Puur "kunst voor de kunst" dus en om later als er toch weer wat gevonden wordt, de vermeende onschuld te kunnen blijven spelen.

Het blijft per slot van rekening "propriety"code en het wordt nooit volledig opengesteld. Nooit!

Daar zijn sommige belangen echt te groot voor. Voor mij nog is het toch weer meer "security through obscurity".

Werkelijk waar ? Kun je eens toelichten , hoe dat praktisch gedaan wordt ?

We zijn het allemaal wel eens *dat* je graag wilt controleren dat de code die je bekijkt ook de code is die gebruikt is om het product mee te bouwen, maar ik wil toch heel graag weten *hoe* dat gedaan wordt .

Het is heel wat lastiger dan "gewoon nog een keer met dezelfde compiler compileren" en dan denken dat het resultaat identiek zal zijn.