it-swarm.com.de

Wie schützen große Unternehmen ihren Quellcode?

Ich habe kürzlich die kanonische Antwort von unseres Ursine-Overlords auf die Frage gelesen, wie Wie Zertifizierungsstellen speichern ihre privaten Root-Schlüssel?

Ich musste mich dann nur noch fragen:
Wie schützen große Unternehmen (z. B. Microsoft, Apple, ...) ihren wertvollen Quellcode?

Insbesondere habe ich mich gefragt, wie sie ihren Quellcode vor Diebstahl, vor böswilligen externen Änderungen und vor böswilligen Insider-basierten Änderungen schützen.

Die erste Unterfrage wurde bereits (etwas) in CodeExpress 'Antwort auf beantwortet. So verhindern Sie, dass private Daten außerhalb der Organisation offengelegt werden .

Die Begründung für die Fragen ist einfach:

  • Wenn der Quellcode gestohlen würde, a) würde das Unternehmen (zumindest teilweise) daran gehindert, ihn zu verkaufen, und b) wäre das Produkt dem Risiko einer auf Quellcode basierenden Angriffssuche ausgesetzt. Stellen Sie sich vor, was passieren würde, wenn der Windows- oder iOS-Quellcode gestohlen würde.
  • Wenn der Code von böswilligen externen Angreifern geändert wird, können geheime Hintertüren hinzugefügt werden, die katastrophal sein können. Dies ist, was in letzter Zeit mit Juniper passiert ist, wo die Koordinaten des zweiten DUAL_EC_DRBG Punkt wurden in ihrer Quelle ersetzt.
  • Wenn der Code von einem internen Angreifer (z. B. einem Apple iOS-Ingenieur?)) Geändert würde, könnte diese Person durch den Verkauf dieser Hintertüren viel Geld verdienen und das Produkt ernsthaft gefährden, wenn er geändert wird Version Schiffe.

Bitte lassen Sie sich keine "Gesetze" und "Verträge" einfallen. Dies sind zwar wirksame Maßnahmen gegen Diebstahl und Änderung, aber sie funktionieren sicherlich nicht so gut wie technische Abwehrmaßnahmen und werden aggressive Angreifer nicht aufhalten (d. H. andere Regierungsbehörden).

76
SEJPM

Zunächst möchte ich sagen, dass nur weil ein Unternehmen groß ist, die Sicherheit nicht besser ist.

Trotzdem möchte ich erwähnen, dass nach einer Sicherheitsarbeit in einer großen Anzahl von Fortune 500-Unternehmen, einschließlich vieler Marken, mit denen die meisten Menschen vertraut sind, derzeit 60-70% von ihnen dies nicht tun so wie du denkst, dass sie es tun sollten. Einige gewähren sogar Hunderten von Drittunternehmen auf der ganzen Welt vollen Zugriff, um von ihrer Codebasis abzurufen, schreiben jedoch nicht unbedingt darauf.

Einige verwenden mehrere private Github-Repositorys für separate Projekte mit aktivierter Zwei-Faktor-Authentifizierung und strenger Kontrolle darüber, wem sie ebenfalls Zugriff gewähren, und haben einen Prozess, um den Zugriff schnell zu widerrufen, wenn jemand das Unternehmen verlässt.

Einige andere nehmen den Schutz von Dingen sehr ernst, deshalb tun sie alles im eigenen Haus und verwenden das, was für viele andere Unternehmen wie ein übermäßiges Maß an Sicherheitskontrolle und Mitarbeiterüberwachung aussehen würde. Diese Unternehmen verwenden Lösungen wie DLP-Tools (Data Loss Prevention), um die Codeexfiltration, den internen VPN-Zugriff auf stark gehärtete Umgebungen nur für die Entwicklung mit einer Menge traditioneller Sicherheitskontrollen und -überwachung sowie in einigen Fällen die vollständige Paketerfassung aller zu überwachen Verkehr in der Umgebung, in der der Code gespeichert ist. Ab 2015 ist diese Situation jedoch immer noch sehr selten.

Etwas, das von Interesse sein könnte und das mir immer ungewöhnlich erschien, ist, dass die Finanzindustrie, insbesondere die Banken, eine weitaus schlechtere Sicherheit haben als man denkt und dass die Pharmaindustrie viel besser ist als andere Branchen, einschließlich vieler Verteidigungsunternehmen. Es gibt einige Branchen, die in Bezug auf Sicherheit absolut schrecklich sind. Ich erwähne dies, weil es eine andere Dynamik gibt: Es sind nicht nur große Unternehmen im Vergleich zu kleinen, ein großer Teil davon hat mit der Organisationskultur zu tun.

Um Ihre Frage zu beantworten, möchte ich darauf hinweisen, dass das gesamte Unternehmen diese Entscheidungen trifft und nicht die Sicherheitsteams. Wenn die Sicherheitsteams für alles verantwortlich wären oder sogar über alle laufenden Projekte Bescheid wüssten, würden die Dinge wahrscheinlich nicht so aussehen wie heute.

Sie sollten jedoch bedenken, dass die meisten großen Unternehmen öffentlich gehandelt werden und sich aus einer Reihe von Gründen eher mit kurzfristigen Gewinnen, der Einhaltung von Quartalszahlen und dem Wettbewerb um Marktanteile gegen ihre anderen großen Wettbewerber als mit Sicherheitsrisiken befassen , selbst wenn die Risiken ihr Geschäft effektiv zerstören könnten. Denken Sie also daran, wenn Sie die folgenden Antworten lesen.

  • Wenn der Quellcode gestohlen wurde:

    ein. Die meisten würden sich nicht darum kümmern und es würde fast keine Auswirkungen auf ihre Marke oder ihren Umsatz haben. Denken Sie daran, dass der Code selbst in vielen Fällen nicht den Wert eines Unternehmensangebots speichert. Wenn jemand anderes eine Kopie der Windows 10-Quelle erhalten hat, kann er nicht plötzlich ein Unternehmen gründen, das ein Windows 10-Klon-Betriebssystem verkauft, und es unterstützen. Der Code selbst ist nur ein Teil der verkauften Lösung.

    b. Wäre das Produkt dadurch einem höheren Risiko ausgesetzt? ja absolut.

  • Externe Änderung: Ja, aber dies ist schwieriger und leichter zu erfassen. Da die meisten Unternehmen dies jedoch nicht ernsthaft überwachen, ist es sehr wahrscheinlich, dass dies vielen großen Unternehmen passiert ist, insbesondere wenn der Zugriff auf ihre Software durch die Hintertür für andere Nationalstaaten von erheblichem Wert ist. Dies passiert wahrscheinlich viel häufiger als die Leute denken.

  • Interner Angreifer: Je nachdem, wie klug der Angreifer war, wird dies möglicherweise nie bemerkt oder kann als unauffälliger Programmierfehler angesehen werden. Außerhalb von Hintergrundüberprüfungen und Verhaltensüberwachung gibt es nicht viel, was dies verhindern kann, aber hoffentlich würden einige Tools zur Analyse des Quellcodes dies erkennen und das Team zwingen, es zu korrigieren. Dies ist ein besonders schwieriger Angriff, gegen den sich einige Unternehmen nicht in andere Länder auslagern und ihre Entwickler umfassend überprüfen. Statische Quellcode-Analysetools werden immer besser, aber es wird immer eine Lücke zwischen dem, was sie erkennen können und dem, was getan werden kann, geben.

Kurz gesagt, die Löcher werden immer vor den Korrekturen herauskommen, sodass die Behandlung der meisten Sicherheitsprobleme zu einem Wettlauf gegen die Zeit wird. Sicherheitstools helfen Ihnen dabei, Zeit zu sparen, aber Sie werden nie "perfekte" Sicherheit haben, und wenn Sie sich dieser nähern, kann dies zeitlich sehr teuer werden (Verlangsamung der Entwickler oder viel mehr Arbeitsstunden an einem anderen Ort).

Nur weil ein Unternehmen groß ist, heißt das noch lange nicht, dass es eine gute Sicherheit hat. Ich habe einige kleine Unternehmen mit viel besserer Sicherheit als ihre größeren Konkurrenten gesehen, und ich denke, dass dies zunehmend der Fall sein wird, da kleinere Unternehmen, die ihre Sicherheit ernst nehmen wollen, keine massiven Maßnahmen ergreifen müssen organisatorische Änderungen, bei denen größere Unternehmen aufgrund der Übergangskosten gezwungen sein werden, sich an die bisherige Vorgehensweise zu halten.

Noch wichtiger ist, dass es für ein neues Unternehmen (jeder Größe, insbesondere aber kleinerer Unternehmen) einfacher ist, die Sicherheit stark in seine Kernkultur zu integrieren, als ihre aktuellen/alten Kulturen wie ältere Unternehmen ändern zu müssen. Möglicherweise gibt es jetzt sogar die Möglichkeit, dem weniger sicheren Produkt Marktanteile abzunehmen, indem eine sehr sichere Version davon erstellt wird. Ebenso denke ich, dass Ihre Frage aus einem ganz anderen Grund wichtig ist: Sicherheit steckt noch in den Kinderschuhen, daher brauchen wir bessere Lösungen in Bereichen wie dem Code-Management, in denen es viel Raum für Verbesserungen gibt.

66
Trey Blalock

Haftungsausschluss : Ich arbeite für ein sehr großes Unternehmen, das in diesem Bereich gute Arbeit leistet, aber meine Antwort ist meine persönliche Meinung und gibt keinen Hinweis auf meine Position oder Richtlinien des Arbeitgebers.

Zunächst einmal, wie Sie Code vor dem Durchsickern schützen können:

  • Netzwerksicherheit: Dies ist offensichtlich - wenn chinesische Hacker Anmeldeinformationen in Ihre internen Systeme erhalten, greifen sie zu Ihrem Quellcode (wenn nicht) anderer Grund als die Tatsache, dass der Quellcode ihnen sagt, wohin sie als nächstes gehen sollen). Grundlegende Computersicherheit muss also eine "Selbstverständlichkeit" sein.
  • Zugriffskontrolle: Benötigt Ihre Empfangsdame Zugriff auf Ihr Code-Repository? Wahrscheinlich nicht. Begrenzen Sie Ihre Belichtung.
  • Seien Sie wählerisch bei der Einstellung und pflegen Sie ein gesundes Arbeitsumfeld: DLP-Maßnahmen wie das Scannen ausgehender E-Mails sind theoretisch geschickt, aber wenn Ihr Ingenieur klug genug ist, dies zu tun Sie sind klug genug, um herauszufinden, wie Sie Ihre DLP-Maßnahmen umgehen können. Ihre Mitarbeiter sollten keinen Grund haben Ihren Quellcode zu verlieren. Wenn sie das tun, haben Sie etwas schrecklich, schrecklich falsch gemacht.
  • Überwachen Sie Ihr Netzwerk: Dies ist eine Erweiterung der Antwort "Netzwerksicherheit", jedoch mit dem Schwerpunkt "Prävention digitaler Verluste". Wenn Sie einen plötzlichen Anstieg des DNS-Verkehrs feststellen, wird Ihr Quellcode möglicherweise von einem Angreifer herausgefiltert. OK, fragen Sie sich jetzt, ob Sie überhaupt wissen würden, wenn der DNS-Verkehr von Ihrem Netzwerk plötzlich ansteigen würde. Wahrscheinlich nicht.
  • Behandeln Sie mobile Geräte anders: Telefone und Laptops gehen verloren wirklich oft. Sie werden auch oft gestohlen wirklich. Sie sollten niemals vertrauliche Informationen (einschließlich Quellcode, Kundendaten und Geschäftsgeheimnisse) auf Mobilgeräten speichern. Ernsthaft. Noch nie. Das bedeutet nicht, dass Sie keine mobilen Geräte verwenden können, um auf den Quellcode zuzugreifen und ihn zu bearbeiten. Wenn jedoch ein Laptop verloren geht, sollten Sie in der Lage sein, den Zugriff eines Laptops auf vertrauliche Daten aus der Ferne zu widerrufen. In der Regel bedeutet dies, dass Code und Dokumente "in der Cloud" (siehe c9.io, koding.com, Google Docs usw.) mit der richtigen Authentifizierung und all dem bearbeitet werden. Dies kann mit oder ohne Vertrauen eines Dritten erfolgen, je nachdem, wie viel Arbeit Sie investieren möchten. Wenn Ihre Lösung 2-Faktor nicht unterstützt, wählen Sie eine andere Lösung aus. Sie möchten reduzieren Ihre Exposition mit dieser Maßnahme, nicht erhöhen es.

Zweitens, wie Sie Änderungen an bösartigem Code verhindern können. Es gibt wirklich nur eine Antwort auf diese Frage: Änderungskontrolle.

Für jedes Codezeichen in Ihrem Repository müssen Sie genau wissen, wer diesen Code wann hinzugefügt (oder gelöscht) hat. Dies ist so einfach Die heutige Technologie, bei der es fast schwieriger ist, Änderungsverfolgung einzurichten, nicht. Wenn Sie Git oder Mercurial oder ein bescheiden verwendbares Versionsverwaltungssystem verwenden, erhalten Sie Änderungsverfolgung und verlassen sich stark darauf.

Um die Vertrauenswürdigkeit ein wenig zu erhöhen, möchte ich hinzufügen, dass jede Änderung an Ihrem Repository von mindestens einer anderen Person außer dem vom Autor eingereichten abgemeldet werden muss die Veränderung. Tools wie Gerrit können dies einfach machen. Viele Zertifizierungssysteme erfordern ohnehin Codeüberprüfungen. Wenn Sie diese Überprüfungen zum Zeitpunkt des Eincheckens erzwingen, können böswillige Akteure nicht alleine handeln, um schlechten Code in Ihr Repo zu bringen. Dies verhindert, dass schlecht geschriebener Code festgeschrieben wird, und stellt sicher, dass mindestens 2 Die Leute verstehen jede eingereichte Änderung.

31
tylerl

Es werden Maßnahmen getroffen, um das versehentliche Einfügen von problematischem Code, auch bekannt als Bugs, zu verhindern. Einige davon helfen auch gegen das absichtliche Einfügen von problematischem Code.

  • Wenn ein Entwickler Code in das Repository übertragen möchte, muss ein anderer Entwickler diese Zusammenführungsanforderung untersuchen. Möglicherweise muss der zweite Entwickler dem ersten Entwickler erklären, was der neue Code bewirkt. Das bedeutet, jede Zeile durchzugehen.
  • Wenn der Code verwirrend aussieht, wird er möglicherweise als schlechter Stil abgelehnt und kann nicht gewartet werden.
  • Code verfügt über automatisierte Unit- und Integrationstests. Wenn es keinen Test für eine bestimmte Codezeile gibt, fragen sich die Leute. Es müsste also einen Test geben, ob die Hintertür funktioniert, oder eine Art Verschleierung.
  • Wenn eine neue Version der Software erstellt wird, prüfen Entwickler und Qualitätssicherung, welche Commits Teil des Builds sind und warum. Jedes Commit muss einen dokumentierten Zweck haben.
  • Software wird mithilfe automatisierter Skripte erstellt und bereitgestellt. Dies dient nicht nur der Sicherheit, sondern auch der Vereinfachung der Arbeitsbelastung.

Natürlich beruhen solche Maßnahmen auf der Ehrlichkeit und dem guten Willen aller Teilnehmer. Jemand mit Administratorzugriff auf den Build-Server oder das Repository kann viel Chaos anrichten. Andererseits benötigen gewöhnliche Programmierer diese Art von Zugriff nicht.

3
o.m.

In meiner (großen) Firma verwenden unsere Laptops alle verschlüsselte Festplatten. Wir verwenden ein Tool namens Digital Guardian, das alle Dateiübertragungen /--Uploads überwacht und USB-Anschlüsse zum Schreiben von Dateien blockiert. Jeder, der eine Ausnahme benötigt, muss ein hardwareverschlüsseltes USB-Laufwerk verwenden (um den Zugriff auf die Dateien zu verhindern, falls das Laufwerk verloren geht oder gestohlen wird). Solche Ausnahmen sind vorübergehend und man muss die zu schreibenden (protokollierten) Dateien begründen. Digital Guardian verhindert das Senden der meisten Arten von Anhängen an externe E-Mail-Adressen. Jeder interne Dateiaustausch erfolgt über webbasierte Ordner mit Zugriffskontrolle und einem Prüfpfad darüber, wer auf was zugegriffen hat. Dies bedeutet, dass das Teilen von Dateien "für geschäftliche Anforderungen" ziemlich nahtlos ist und alles andere schwierig ist.

Das System ist nicht narrensicher und hat Auswirkungen auf die Bandbreite. Allein die Auditing-Tools haben jedoch mehrere Instanzen von Mitarbeitern (häufig Mitarbeiter, die das Unternehmen verlassen wollten) festgestellt, die versucht haben, Quellcode-/Designdokumente usw. Zu übernehmen Zumindest stoppen wir einige dieser Versuche.

Und für den Fall, dass jemand der Meinung ist, dass https-Uploads "unsichtbar" sind: Der gesamte externe Webdatenverkehr wird von einem Proxy in der Cloud verarbeitet, der ein MITM-Zertifikat zur Überprüfung des https-Datenverkehrs verwendet. Es ist zweifellos möglich, diese Maßnahmen zu umgehen - es gibt viele kluge Mitarbeiter -, aber manchmal reicht es aus, um Ihr Ziel schwerer zu machen als das der anderen.

2
Floris

Dies ist eine knifflige Frage, und da ich noch nie in dieser Branche gearbeitet habe, könnte meine Idee theoretisch oder sehr unpraktisch sein.

Was ist, wenn Mitarbeiter in niedriger Hirarchie nur kleine Teile des Quellcodes erhalten? Das Explorer.exe-Team benötigt nur Zugriff auf den Quellcode der Explorer.exe. Dies würde es schwieriger machen, den Quellcode von innen zu stehlen, da Sie sich an höheren Positionen befinden müssten, um Einblick in mehr Teile des Quellcodes zu erhalten.

Sicher, Sie benötigen eine gute Dokumentation zu allen Teilen, die das Team möglicherweise benötigt, aber nicht sehen kann. Auch das Debuggen würde schwieriger werden, da Sie vorkomilierten Quellcode mit dem frisch kompilierten aus dem Explorer.exe-Team zusammenführen müssten. Möglicherweise gibt es einen Kompilierungsserver, der den gesamten Quellcode enthält und Vollversionen des Produkts kompilieren kann, selbst für diejenigen, die nur einen kleinen Teil bearbeitet haben. (Weil sie ihre Änderungen testen müssen) Dieser Server weiß auch, wer Zugriff auf welche Teile des Codes hat.

Ich weiß nicht, ob dies ein praktischer Ansatz ist oder ob es wirklich in der Branche passiert oder nicht. Es ist nur ein Konzept, das meiner Meinung nach sinnvoll wäre, um den Diebstahl von Quellcode zu verhindern.

1
BlueWizard