Biznes elektroniczny zawdzięcza swoje początki rozwojowi niedrogich komputerów; temu również zawdzięcza swoje problemy z bezpieczeństwem. Komputery przypadkowo naruszają prawo Bauera: „Powierzchowne komplikacje mogą dawać fałszywe poczucie bezpieczeństwa”. Komputery są z natury bardzo złe z punktu widzenia bezpieczeństwa. Są niezwykle elastyczni, a elastyczność bardzo utrudnia prowadzenie policji. Są one złożone i nie jest łatwo przeanalizować, w jaki sposób niewłaściwe użycie systemu może zostać wykorzystane do obejścia standardowych kontroli. Komputery komunikują się teraz na rozległych obszarach, w środowisku otwartym dla każdego, przy użyciu protokołów, które w zasadzie zakładają dobrą wiarę w imieniu współpracujących systemów. Założenia „dobrej wiary” są śmiertelne dla dobrego bezpieczeństwa i prawdopodobnie musimy dodać, że ponieważ większość pracowników komputerowych myśli i działa w dobrej wierze, sami reprezentują jedną z największych słabości. Aby pomóc w legalnym użytkowaniu, komputery zostały celowo zaprojektowane tak, aby usunąć złożoność ich działania przed ich użytkownikami i programistami aplikacji, którzy nie muszą patrzeć na niektóre z bardziej podstawowych składników systemu. Dlatego w większości przypadków rozsądne jest modelowanie systemu komputerowego, jak pokazano na rysunku.
Częściej robi się rysowanie modelu jako zestawu warstw poziomych, gdzie użytkownik ma dostęp tylko do górnej warstwy „aplikacji”, ale tutaj bardziej żywe jest spojrzenie na to, jak szukanie dostępu do pomieszczeń w budynku. Gdy użytkownik uzyska dostęp do pierwszego „pokoju” systemu, wszystkie inne jego wymagania są prowadzone w oderwaniu od nich, w głębszych zakamarkach. Negocjacje między „pokojami” zapewniają odpowiednie interfejsy, które ukrywają szczegółowe działanie bardziej podstawowego oprogramowania. Podobne podejście stosuje się do tworzenia aplikacji, w którym projektant aplikacji nie musi znać szczegółów wewnętrznych pomieszczeń, a także może sprawić, że aplikacje będą przenośne na wielu platformach sprzętowych i programowych. Niestety, oprócz tego, że jest wygodną metaforą wyjaśniającą projekt systemu „w dobrej wierze”, zapewnia on również zbyt wygodny obraz, gdy próbujemy narysować analogię z bezpieczeństwem fizycznym, które stopniowo ogranicza dostęp do krytycznych zasobów za pomocą kontroli i władze na każdych drzwiach, gdy ktoś wchodzi do środka. Nie jest to jednak prawdziwy obraz. Rzeczywistość jest bliższa tej z Rysunku
Najpierw musimy zdać sobie sprawę, że użytkownik nie uzyskuje dostępu do systemu przez jakiś abstrakcyjny „port aplikacji”, połączenie jest rzeczywiste, fizyczne i bardzo głęboko w sercu systemu. W jaki sposób sprzęt „rozpoznaje” użytkownika, na przykład, jeszcze zanim zaczniemy dyskutować o hasłach i szyfrowaniu? W końcu, jak widzimy, istnieje tunel, który przedziera się przez nasz dogodnie podzielony model: wszystkie systemy mają funkcje administracyjne i usługowe, których tak naprawdę nie można umieścić w jednym „pomieszczeniu”. Co ma powstrzymać użytkownika przed udawaniem, że sprzęt jest konsolą systemową? Co zrobić, jeśli użytkownik może uzyskać dostęp do uprawnień administratora systemu administracyjnego, nawet jeśli tylko raz? Należy również pamiętać, że same aplikacje mogą nie działać w odosobnieniu. Albo rozmawiając mniej więcej bezpośrednio ze sobą, albo przez dowolne pomieszczenia (warstwy) w modelu, mogą tworzyć efekty, które nie były zamierzone przez poszczególnych twórców aplikacji. Przykłady tego zobaczymy później. Duży problem z systemami komputerowymi polega na tym, że legalny model projektowy może być podzielony na sekcje, ale nielegalny napastnik może zaatakować system w dowolnym momencie