Wprowadzenie
Tematem numer jeden, niemalże w każdym moim projekcie, jest model biznesowy i tajemnica przedsiębiorstwa. Z perspektywy lat muszę powiedzieć, że to fobia wielu (jak nie większości) przedsiębiorców i nie tylko przedsiębiorców. Nie dlatego, że chcą coś chronić, ale dlatego co i jak chronią. Nie raz już pisałem, że firmy nie raz, najpierw podpisują z dostawcami rozwiązań i konsultantami umowy o poufności, a potem wyzbywają praw do swojego know-how na ich rzecz:
W branży inżynierii oprogramowania dość powszechna jest sytuacja, gdy programista jest także projektantem, innymi słowy programista ma pełnię praw autorskich do kodu jaki tworzy a jego klient żadnych mimo, że jest inwestorem!1
Dzisiaj drugi problem czyli bezpieczeństwo informacji a nie raz i całej firmy.
Na początek coś z zakres teorii informacji:
Zasada Kerckhoffs’a to jedna z podstawowych reguł współczesnej kryptografii. Została sformułowana pod koniec XIX wieku przez holenderskiego kryptologa Augusta Kerckhoffs’a (ur. 19 stycznia 1835, zm. 9 sierpnia 1903). Zasada ta mówi, że system kryptograficzny powinien być bezpieczny nawet wtedy, gdy są znane wszystkie szczegóły jego działania oprócz sekretnego klucza. […]
- System powinien być, jeśli nie teoretycznie, to w praktyce nie do złamania.
- Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów korespondentom.
- Klucz powinien być możliwy do zapamiętania bez notowania i łatwy do zmienienia.
- Kryptogramy powinny być możliwe do przesłania drogą telegraficzną.
- Aparatura i dokumenty powinny być możliwe do przeniesienia i obsłużenia przez jedną osobę.
- System powinien być prosty ? nie wymagający znajomości wielu reguł ani nie obciążający zbytnio umysłu.
Właśnie druga z tych reguł nosi obecnie nazwę zasady Kerckhoffs’a.
[…]Ideę zasady Kerckhoffs’a wyraża również przypisywane Claude’owi Shannon’owi powiedzenie “Wróg zna system” (ang. The enemy knows the system), znane pod nazwą Maksymy Shannona (ang. Shannon’s maxim).2
Zasadę tę, jako kryterium, można łatwo poszerzyć, usuwając ostatnie słowo do postaci:
Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów.
Na rynku mamy dwa przeciwstawne w pewnym sensie (o tym dalej) pojęcia: patent oraz know-how, dodać należało by do tego zestawu pojęcie prawo autorskie osobiste i majątkowe.
O bezpieczeństwie biznesowym
Na początek klasycznie kluczowe definicje:
know-how: rozumiane jest jako pakiet nieopatentowanych informacji praktycznych, wynikających z doświadczenia i badań, które są:
1. niejawne (nie są powszechnie znane lub łatwo dostępne);
2. istotne (ważne i użyteczne z punktu widzenia wytwarzania Know-how: ochrona tajemnicy przedsiębiorstwa).bezpieczeństwo: stan niezagrożenia (s.j.p.)
tajemnica: sekret; też: nieujawnianie czegoś (s.j.p.)
patent: dokument przyznający jakiejś osobie lub firmie wyłączne prawo do czerpania korzyści z wynalazku; też: to prawo (s.j.p.)
informacja: to, co powiedziano lub napisano o kimś lub o czymś, także zakomunikowanie czegoś (s.j.p.)
utwór: każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci, niezależnie od wartości, przeznaczenia i sposobu wyrażenia (Ustawa)
Dla zapewnienia i sprawdzenia jednoznaczności tego tekstu zbudujmy model pojęciowy (taksonomia i syntaktyka pojęć, przypominam, że nie korzystamy w takich analizach a ontologii, poniższy diagram to nie ontologia):
Warto tu zwrócić uwagę na to, że pojęcie opis patentu pojawia się w taksonomii indywidualizmu treści jak i jej dostępności. Innymi słowy opis patentu jest zarówno utworem jak i treścią nie będącą tajemnicą.
I teraz pytanie: co należy chronić i dlaczego? To zależy…
Patent to monopol, jednak fakty pokazują, że monopole trzeba samemu egzekwować, co nie zawsze jest ekonomicznie uzasadnione, przy założeniu że koszty ochrony patentu nie powinny przekroczyć korzyści z jego posiadania. I nie mam tu na myśli tylko opłat dla Urzędu patentowego, a potencjalne stałe koszty ochrony z tytułu wytaczanych pozwów cywilnych za łamanie praw patentowych. Rynek pokazuje, że nie raz ochronę patentową można zastąpić ochroną z tytułu praw autorskich (treść opisu jakiegoś rozwiązania to utwór, patrz diagram powyżej) np. wzory przemysłowe, tym bardziej że są rzeczy których nie można opatentować, ale można opisać i chronić właśnie jako utwór (np. logikę oprogramowania).
Know-how
Know-how to kolejny ciekawy obszar, bo wymagający bardzo często ochrony. Patent z zasady jest treścią jawną, podawaną do publicznej wiadomości. Jeżeli ktoś uzna, że jego know-how stanowi o jego przewadze a nie chce czynić z niego patentu, to ma dwa wyjścia: (1) utrzymywać know-how na poziomie trudnym do naśladowania, to się nazywa utrzymywanie bariery wejścia (patrz analiza pięciu sił Portera), albo (2) utrzymywać know-how w tajemnicy przed konkurencją. To kluczowy prawdziwy powód podpisywania umów o zachowaniu poufności (drugi to prawo regulujące dostęp do informacji w spółkach giełdowych).
I teraz jeszcze raz cytowana na początku zasada:
Projekt systemu nie powinien wymagać jego tajności, a ewentualne jego ujawnienie nie powinno przysparzać kłopotów.
I to jest ideał (idealizacja) do prowadzenia analiz. Punktem wyjścia w projekcie powinna być analiza sprawdzająca czy faktycznie ujawnienie danej informacji przynosi szkodę a jeżeli tak, to dlaczego. Dalej: jeżeli know-how stanowi sobą określony mechanizm i jego ujawnienie przynosi szkodę, to faktycznie należy go – jego opis – chronić. Jak? Przede wszystkim taki, precyzyjny, opis musi w ogóle powstać. Jeżeli z jakiegoś powodu nie może być przedmiotem patentu, to pozostaje prawo autorskie. A skoro tak, to: (1) posiadaczem prawa majątkowego do opisu know-how powinien być ten, kto chroni swoje know-how, (2) jeżeli oprogramowanie ma realizować mechanizm stanowiący know-how, to dostawca (wykonawca) tego oprogramowania nie powinien mieć żadnych praw do tego know-how, o ile tylko faktycznie stanowi ono o przewadze na rynku.
Ideał jest taki jak zasada powyżej, wniosek zaś jest taki, że jeżeli o przewadze rynkowej stanowi tajemnica, jej bezpieczeństwo staje się kluczowe. A jak chronić tajemnicę czyli informacje? W ten sam sposób: system opisujący bezpieczeństwo informacji opisuje się procedurami i procesami :), a te właśnie (dokumenty opisujące procesy), zgodnie z zasadą opisaną na początku, nie powinny wymagać ochrony…
Warto na koniec dodać, że na gruncie ustawy o zwalczaniu nieuczciwej konkurencji know-how nabywane przez pracowników IT podlega obowiązkowi ochrony tajemnicy przedsiębiorstwa, który od dnia 4 września 2018 r. został określony jako bezterminowy…
Na zakończenie
Bardzo często jestem pytany o różnicę pomiędzy chronionym utworem a chronionym know-how. Popatrzmy na poniższą mapkę, znaną z książki (i gier) Wyspa Skarbów:
Otóż mapka ta jest chroniona prawem autorskim jako obraz graficzny. Jeżeli prawdą zaś jest, że treść mapki zawiera wiedzę o tym jak dotrzeć do skarbu, to wiedza ta stanowi know-how piratów i jest trzymana w tajemnicy. Tak więc mapka ta jest utworem niosącym wiedzę o know-how. :). Wystarczająco precyzyjny projekt architektury i logiki działania oprogramowania jest także utworem, niosącym wiedzę o know-how.
A teraz popatrzcie Państwo na swoje umowy z dostawcami oprogramowania… i miejcie ograniczone zaufanie do prawników firm dostawców oprogramowania 🙂
Dodatek: bezpieczeństwo systemowe znane także jako bezpieczeństwo proceduralne
Klasycznym jego przykładem jest uwierzytelnienie dwuskładnikowe (2FA) czy potwierdzanie double opt-in (model procesu). Nawiązując do Zasady Kerckhoffs’a, bezpieczeństwo (metody i narzędzia) nie powinny być tajne (bezpieczeństwo przez zaciemnienie), gdyż wtedy “jedno ujawnienie” niszczy to bezpieczeństwo. Zarówno procedury 2FA jak i opt-in (to tylko dwa z wielu przykładów) nie są tajemnicą, a mimo to nikt nie powie, że ich stosowanie jest niebezpieczne.
Testowanie bezpieczeństwa informacji powinno się odbywać na poziomie procesów biznesowych i procedur. Jeżeli tu istnieją “luki” to żadna technologia szyfrowania i systemy haseł niczego nie zmienia na lepsze ale niewątpliwie podniosą koszty.
