My experience and how I learned how to quick-scope environments started like much of cybersecurity, with methods I learned related to physical security from an unorthodox place – my time working at a Goodwill store. I worked as a “media processor” pricing and selling records, books, CDs and general mixed media. Besides learning that people in North Florida surprisingly really love Yanni, I also learned about theft prevention. My best records and books were often stolen while I was off.
I would review the cameras and see that there were huge blind spots in my store, with the biggest being in my section. So, I re-designed the section so that my best merchandise would have surveillance and if I had too much put them on displays scattered around the store with good foot traffic and camera coverage. I made sure I understood where people walked and where the entrances and exits were and what path you would take if you were trying to sneak out. I also learned how to “teleport” around the store. I knew where the blind spots were so I would step out of view in one room and appear in another.
That is the same mindset you have to have when scoping a system from a compliance perspective.
1) Define the perimeter. The first thing you have to do is define the perimeter. In the example case, we had a back room where we processed the goods. I deemed the back room with the unprocessed goods out of scope since I was worried about my processed goods being stolen and insider threat was not my main concern. You would also want to do the same for your system. Audit and compliance are continuous processes. You have to start with the where the risk is, such as the critical systems, and expand out to the peripheral systems. Confirm your internal identity management services like active directory, your production environments, cloud backup services, workstations/endpoints, and confirm any peripheral systems. While peripheral systems are not the main focus, we'll still want to take them into account.
2) Know the entrances, know the exits. Next, we have to check the entrances and exits. If you track the flow of traffic, you understand the processes and systems that are critical to access control. I usually check this by confirming the onboarding and offboarding processes and by going through what equipment, applications, accounts are required for users. If access requirements are different per role or department, you will want to follow up as needed. If you have outside user types such as vendor accounts for partners or customer accounts, you should go through the onboarding and offboarding process for those users as well.
3) Monitor and find the blind spots. Once you know how people come in and leave, you need to figure out how to track them while they are in the building or system. On the operation side, I usually ask about the annual training and performance evaluation processes (as this helps identify more systems as well as helps you catch unique cases and contractors). On the technical side, you would review audit logging capabilities. Critical actions and all events within production should be trackable and retained. Ask where alerts are sent and to whom. This is an important question in audit. This is also why we confirm the perimeter and know our entrances and exits first because now we have to understand our peripheral systems. Do you have a SIEM? Do you need a SIEM? Are you comfortable with the amount of user actions not being tracked in peripheral systems? In the end with peripheral systems, secondary logging may be needed but at the bare minimum you will probably want to know when people enter this blind spot and when they leave.
4) Now we think about data. People are much easier to track and think about than data. Data, be it PII, ePHI, or CUI, feels ethereal in the abstract. Unless someone is physically walking out with a server in hand it can be hard to envision how or where someone might exfiltrate the system with your data. Start at the beginning, and for your datapoints, think about the perimeter, think about how it enters and leaves the system, and then think about how it is processed and monitored. Find the gaps and fill them.
This is a quick thought experiment but is a great method I have used and taught for years. The same principles can be used for code changes, tracking confidential data, simple system scoping and troubleshooting, and more. I hope it comes in handy. And please don’t steal from your local stores!
