Logs You Cannot Take Out

In one line

The real reason investigations slow down at a bank site is not technology but network separation and export control, and if you do not design your investigation method on the premise of those constraints, you throw away the whole first week.

Why this was needed

Trying to do things the way you did at another customer and getting stuck on the first day happens almost certainly at a bank.

"로그 좀 받아서 제 노트북에서 분석할게요"    → 반출 불가
"화면 캡처해서 슬랙에 올릴게요"              → 촬영·캡처 금지
"제 노트북 가져가서 붙일게요"                → 개인 기기 반입 불가
"인터넷에서 이 도구 받아서 쓰겠습니다"        → 업무망은 인터넷과 분리
"운영 DB 에 붙어서 조회해 볼게요"            → 운영계 직접 접근 불가

This is not that customer being fussy. They are controls required by the Electronic Financial Supervisory Regulations and related guidelines, and if they are not kept, the bank is sanctioned. It means this is not the kind of thing you can ask the contact to overlook "just once."

How it works

There are broadly four controls an FDE needs to know.

Network separation. The business network and the internet network are separated, physically or logically. From a business-network PC you cannot reach the external internet, and from an internet-network PC you cannot connect to production systems. So you cannot do "search and look it up" and "look at the system" at the same time. You end up working by alternating between two screens, and if you plan a schedule without knowing this, it takes twice what you expected.

Export control. Data inside the business network cannot go outside. If it must go out, it goes through an export approval procedure, and that procedure usually takes days. Not even a single log file is an exception.

Access control and log retention. Who looked up what and when is all recorded. Access to production data is usually approval-based, and there is no path to connect without approval. The retention period of access records is also fixed by regulation.

Account separation. The lookup account and the change account differ, and production and development accounts differ. Even if you want to fix something while investigating, you cannot with that account. This is not an inconvenience but a design.

What it looks like in the field

First, instead of bringing investigation results outside, you build the summary inside. Raw logs cannot go out, but an aggregate like "at what hour and minute, how many of which error" can. So an investigation at a bank site must be designed in the direction of building aggregates from the start. A plan to carry out the raw data whole and analyze it later does not hold.

Second, you make a list of what you need in advance and request it all at once. Whether it is export approval or access rights, each takes days, so if you request them one at a time while investigating, a week just goes by. The right answer is to cast "what this investigation needs" as widely as possible on the first day and submit it all at once. It is fine if some of it ends up unused.

Third, the time you spend borrowing the customer contact's screen is the real investigation time. In many cases we cannot connect directly, so we proceed beside the contact, saying "please type this query." That person's time is not our time, so it may be only an hour or two a day. If you do not write down beforehand what you will look at within that time, you can look at nothing.

Fourth, you must write in the report that you could not bring it out. "I could not check the logs, so I am estimating" and "I checked the logs and this is what came out" are conclusions of different reliability. If you write as if you had checked something you could not check because of the constraints, then when that conclusion turns out wrong, we have lied. Writing down the constraints is not an excuse but stating exactly what the conclusion rests on.

What to check in the next reading

It covers what to write and what not to write in a report when you have come to see personal information during an investigation.