일부 보안팀에서 오류 대응에 대해 “개 오바”를 떠는 이유

혹시 여러분, 소프트웨어 보안가이드 읽어보신적 있습니까?

한번 훑어보라고 링크 던져 드리겠습니다.

제가 알기론 2021년 판이 최신으로 알고 있습니다.

음… 갑자기 어떤 제 댓글이 추천수 많길래 보니까. 네… 오류 관련 내용이었군요.

그리고 눈에 띄는 오류 관련 하소연 글도 여기서 봤고요.

저도 당해본 바 있으니 공감되면서도 보안팀의 저 개오바질 좀 적당히 했으면 좋겠지만 들어 먹을리가요.

어쨌든, 제가 왜 글을 썼는지 본론으로 들어가죠.

Stack Trace를 로그에서조차 남기지 마라?

보안가이드에서는 하필 ASP.NET 웹 상의 스택 추척 노출 예시를 들었기 때문에 저는 여러분에게 가장 친숙하고도 모자라 질릴만한 예시 하나 들고 왔습니다.

네? 위 화면 뭐냐고요? 신선한 뉴비군요. 아래 톰캣 보이시죠? 기본 오류 페이지입니다.

어쨌든, 보안가이드에서는 이런 식으로 서비스할 때 사용자에게 이런 오류페이지를 노출하면 해커가 프로그램 구조 판단에 용이하다는 등 어쩌구저쩌구 하면서 노출하면 안된다고 명시되어 있습니다. 제가 준 가이드 PDF 126페이지요.

그럼 이 스택 추적 내역을 로그에서조차 남기지 마라는 가이드는 어딨냐고요? 찾아보세요. 없습니다. 보안 가이드에서는 저런 언급 한 적 없어요.

근데 몇몇 업체에서는 심지어 로그에서조차 스택 추적을 남기지 말라고 합니다. 이유도 가관이죠. 해커가 로그를 보면 프로그램 구조 파악이 쉽다고…

그리고, 로그에 못 남기면 문제가 발생했을 때 어떻게 추적하고 문제를 수정할까요? 대체 어떻게? 가뜩이나 개발환경 운영환경 다른데?

애초에 서버 털리는 것부터 재앙인데 대체 왜 이런 이상한 가이드가 나왔냐고요?

근거는… 없습니다. 자료 없습니다. 정부에서 제시한 가이드에서조차도 없습니다.

그리고 이런 개 오바를 떨어서 나온 결과물이 바로

민원 서류 올스톱 대란... 뭐가 문제인지 파악도 못한 행안부

이런 어이없는 시스템 장애 기사죠.

지하철 타거나 사람 많은 거리 가보면 “예수믿고 천국갑시다” 이렇게 소리지르면서 가는 행인 가끔 보이시죠?

그 행인하고 저런 말 하는 보안 담당자하고 동급이라는 얘기 하고 싶었습니다.

어떤 곳은 로그에 남기지도 못하니 DB에 남기는 건 뭐라 안하니 DB에 남기는 곳도 봤고,

어떤곳은 로그 나오는 것 자체를 금기시하는 곳도 봤습니다. 다행히도 제가 소속된 사업부가 아닌 게 천만다행이죠.

네 맞아요. 보안은 Zero trust, 아무것도 믿지 않는 것이 정상입니다. 어느 누구도 믿어서는 안 되죠.

하지만 이게 과하면, 오히려 보안 사고가 일어나는 것도 알아야 하지만, 보안은 과도해도 모자르다는 삐뚤어진 생각 가지신 분 몇몇 있습니다.

보안은 막는 것이 아닙니다. 무작정 막는게 능사가 아닙니다.

지금 보안 실태를 군대로 치면 그냥 문 없는 벽에서 들락날락하려면 벽타고 오르내려서 출입을 해야 한다는 뜻이 됩니다.

지금 한국의 보안 실태를 보면, 진짜 보안은 해커가 합니다.

가짜 보안들이 그저 막기만 합니다. 중요한 건, 그렇게 무작정 막는건 잘~ 하면서 구멍이 꼭 있어요. 알고도 안막죠.

직원들은 벽타고 출입해야 하지만 임원들은 전용 출입구가 화사~하게 있습니다. (보안프로그램 모두 예외 정책)

저커버그가 자기 노트북 보안스티커 붙인 거 보이시죠? 기업의 수장부터 저렇게 보안을 지키지만 한국에서는 절대 불가능한 일인 거 저는 알고 있거든요.

왜인지 더 쓰다가는 문제가 되니 말을 아끼겠습니다.

어쨌든, 이게 대한민국 보안의 현실입니다.

아직도 버그바운티? 고소당하지 않는 게 다행이라고 생각하면 됩니다.

이게 대한민국 보안 실태입니다.

대기업도 예외는 아닙니다.

정부기관도 얄짤 없습니다.

어자피 털리면 북한한테 털렸다 징징대면 면책되니까요.

털려도 책임자는 책임 안져도 되지만, 책임은 개발한 당사자가 져야 하죠.

그러니 보안팀들이 저렇게 안일하게 대응하는 거고요.

보안사고 일어나는 거 보면 보안팀 잘못 없다? 절대 그런 일은 있을 수가 없습니다.