레드 티밍Red Teaming

지키는 눈과 뚫는 눈은 다르게 봐요

만든 사람은 자기가 그린 흐름을 따라 확인해요. 이 버튼을 누르면 이렇게 되고, 이 요청이 오면 이렇게 막힌다는 순서대로요. 그런데 문제가 되는 자리는 대개 그 순서 바깥에 있어요. 아무도 그렇게 쓸 거라고 생각하지 않은 방식이 통로가 돼요.

뚫는 쪽 눈은 순서를 무시하고 봐요. 여기서 저기로 건너뛰면 어떻게 되는지, 두 기능을 이상한 순서로 붙이면 어떻게 되는지, 아주 긴 대화 끝에서는 어떻게 되는지 물어요. 같은 시스템인데 보이는 것이 달라져요.

그래서 레드 티밍은 만든 사람이 스스로 하는 점검과 따로 둬요. 만든 사람도 참여하지만, 설계를 모르는 사람과 배경이 다른 사람이 섞여야 서로 다른 구멍이 나와요.

범위를 먼저 정하고 시작해요

시작하기 전에 합의해 두는 것들이 있어요. 어느 시스템까지 대상인지, 실제 사용자의 자료를 건드려도 되는지, 어디까지 확인하고 멈출지, 찾은 내용을 누구에게 어떻게 알릴지예요. 집을 돌아보되 문을 부수지는 않는 것과 같아요.

기록도 함께 정해요. 무엇을 시도했고 어떤 조건에서 통했는지 적어 두지 않으면 고치는 쪽이 재현하지 못해요. 우연히 한 번 통한 것인지 안정적으로 통하는 것인지도 여러 번 시도해 봐야 갈려요.

이 합의가 없으면 점검이 사고가 돼요. 범위를 적어 두는 일이 절차의 형식이 아니라 안전 장치인 이유예요.

무엇을 넘어 보는지

넘어 보는 자리는 보안 한 가지가 아니에요. 규칙 밖의 답이 나오는지, 사용자나 회사의 정보가 답에 섞여 나가는지, 확인되지 않은 내용을 자신 있게 말하는지, 읽어 온 자료에 숨은 지시를 그대로 따르는지, 집단에 따라 결과가 갈리는지, 쥐여 준 도구를 엉뚱하게 쓰는지를 함께 봐요.

자리마다 필요한 사람이 달라요. 말의 결을 보는 데는 언어와 문화를 아는 사람이, 도구 오용을 보는 데는 그 시스템을 아는 사람이 필요해요. 한 팀이 전부 볼 수 없어서 여러 배경을 섞어요.

사람이 손으로 하는 방식과 많은 시도를 자동으로 만들어 돌리는 방식을 함께 써요. 자동 쪽은 넓게 훑고, 사람 쪽은 자동이 떠올리지 못하는 각도를 찾아요.

결과는 고칠 목록이에요

점검이 끝나면 나오는 것은 뚫린 사례의 모음이에요. 여기서 중요한 건 개수가 아니라 종류예요. 비슷한 사례가 백 개 나온 것보다 서로 다른 종류가 열 개 나온 쪽이 더 넓게 본 점검이에요.

각 사례는 고치는 쪽으로 넘어가요. 어떤 것은 검사 규칙으로, 어떤 것은 학습 자료로, 어떤 것은 기능을 아예 빼는 결정으로 이어져요. 고친 사례는 다음 점검에서 다시 확인하는 목록에 들어가요. 한 번 막힌 자리가 다른 곳을 고치다 다시 열리는 일이 흔하기 때문이에요.

한 번으로 끝나지 않아요

모델을 갈아 끼우거나, 새 기능을 붙이거나, 참고하는 자료를 바꾸면 이전 점검의 결론은 다시 확인해야 해요. 집을 한 번 손봤다고 해서 다음 해에 다시 돌아보지 않아도 되는 게 아닌 것과 같아요.

그리고 아무리 돌아도 전부 확인할 수는 없어요. 점검의 목표는 구멍을 0으로 만드는 게 아니라, 남은 위험이 어느 정도인지 알고 내보내는 거예요. 모른 채로 내보내는 것과 알고 내보내는 것은 아주 다른 상태예요.