Imagine you’re hosting a large conference at a hotel.
You’ve carefully planned the event,
inviting speakers, clients, and key industry figures. You provide your attendees with access to
a conference app, where they can interact with the content, book meetings, and access
sensitive event schedules. On the first day of the conference, everything seems fine.
However, later in the day, attendees start reporting that some of the app’s features aren’t
working, and some of the important meeting information is visible to people who shouldn’t
have access to it. (authorization issue / authentication issue) + (app is not working) - assess
more (tests before deployment 8.29+ seperation of env 8.31 + test info 8.33)
Upon further investigation, it turns out that the system was designed similarly to how the
conference was set up — with all rooms and sessions accessible without barriers or checks.
(least privilege) The app was not secured properly, and certain areas that should have been
locked were instead open to anyone with the link. (access restriction -8.3 & 8.5) The mistake
was that, during the setup, the organizers forgot to lock specific conference areas and didn’t
set up proper credentials for sensitive meeting rooms. Worse still, the hotel’s Wi-Fi network
was used for everything, with no separation between the public and private areas of the
conference. (network segregation -8.22)
Now, consider this scenario happening to a tech company hosting its own digital platform —
a breach in the system’s security because of misconfigured internal services (configuration
management- 8.9) , improper network practices, and a lack of boundaries between different
systems. The company’s platform, which should only have been accessible by authorized
users, became vulnerable to exploitation due to overlooked network security practices.
(management of tech vulnerabilities- 8.8)