'Snort 분석'을 연재하면서

Snort를 직접 운영하면서 발생한 로그를 분석해보는 게 IDS 등 보안장비 운영에 도움이 될 거란 생각에 Snort 설치 가이드를 작성했었다. 그런데 인터넷에 흔한 설치 가이드만으로는 별 도움이 되지 않을거란 생각에 Snort 분석 사례를 올리기 시작했다.

• Snort 룰을 관리해보자
• Snort 분석(DNS Request)
• Snort 분석(deleted.rules)
• Snort(multi source one db)
• Snort threshold 옵션 설명 정정
• Snort 분석(패킷 발생량 기반 탐지)
• Snort 분석(DNS excessive outbound NXDOMAIN replies)
• Snort 분석(WEB-MISC weblogic/tomcat .jsp view source attempt)
• Snort 분석(DELETED WEB-IIS header field buffer overflow attempt)
• Snort 분석(WEB-CLIENT Malformed PNG detected sRGB overflow attempt)
• Snort 분석(WEB-MISC Checkpoint Firewall-1 HTTP parsing format string vulnerability attempt)
• Snort 분석(OS-WINDOWS Microsoft Windows SMB Session Setup NTLMSSP unicode asn1 overflow attempt)

피드백이 없어서 도움이 됐는지는 잘 모르겠다. 피드백이 별로 없는 이유는 관심이 없어서일까?

이쯤에서 다시 한 번 목적을 분명히 해야겠다

Snort 분석 사례를 공유하는 이유는 처음부터 Snort를 강조하거나, 철 지난 보안 취약점을 알리기 위해서가 아니라 강력한 텍스트 처리 도구인 정규표현식을 알리기 위해서. (SQL과 엑셀의 유용함도 같이)

개발자에게 정말 좋은데, 참 좋은데...

'처음 시작하는 정규표현식(한빛미디어)' 표지 뒷면을 장식한 문장이지만, 컴퓨터가 처리하는 데이터의 대부분, 발생하는 로그의 대부분이 텍스트임을 감안했을 때 개발자는 물론이고 IT 종사자들 모두에게 두루두루 좋은 게 정규표현식이다.

수십 년째 다양한 컨셉 변화를 자랑하는 보안장비에서도 기반 기술인 패턴매칭의 효과를 극대화해주고, 로그 분석을 데이터 분석 수준으로 끌어올려주는 정규표현식.

하지만 의외로 많은 이들이 정규표현식을 낯설어한다는 사실을, 몇 번의 강의를 통해서 알게 됐다. 빅데이터가 유행하면서 R, 파이썬 등이 분석도구로 각광받는 상황에서도 정작 로그 필드 추출 등 분석 대상 데이터를 정의해주는 정규표현식에 대한 관심은 낮은 편.

스플렁크도 애용하는 정규표현식

책을 쓴 후 본격적인 룰 정확도 개선을 시도해보겠다는 목표를 가지고 새롭게 시작한 직장에서도 룰 정확도 개선에 대한 필요성을 느끼지 못하는 것은 둘째치고, 정규표현식에 능숙한 엔지니어를 찾기 힘들었다.

룰 정확도 개선을 성과로 인정하지 않는 분위기 덕분에 눈치 봐가며 없는 인력/시간을 업무에 배정해야 했고, 결과적으로 1년 동안 로그 분석 범위를 기존 대비 50% 높였지만 여전히 전체 범위의 반에도 미치지 못하는 상황.

그래도 후회는 없다. 룰 정확도 개선을 고민하고, 나름의 방법론을 정립한 후 진행했던 첫 번째 시도에서 유의미한 결과를 얻었으니까. 두 번째 기회가 온다면 더 나아지겠지. 대신 정규표현식에 능숙한 엔지니어가 더 많이 필요하다는 생각은 뚜렷해졌다.

그런데 사실 가장 중요한 건 

룰 정확도 개선 필요성의 공감대를 얻는 것. 이 부분에 대한 공감대를 얻지 못하면 정규표현식 할아버지가 와도 다 부질없는 일. 아무도 필요성을 느끼지 않는데 혼자서 중요하다고 떠들어봐야 나만 이상한 사람 될 뿐이고(..)

많은 보안장비들이 매뉴얼을 벗어나, 설치 이후에 필요한 활용 가이드를 제공하지 않는 이유 역시 별 거 없다. 장비 설치가 끝이 아닌 시작임에도 고객이 요구하지 않으니 필요성을 느끼지 못하고, 필요성을 못느끼니 경험이 쌓이지 않는다.

경험을 쌓은 이들도 조직이 자신의 경험을 필요로 하지 않는다는 사실에 당황하고, 결국 현실에 적응하기 시작한다. 경험이 쌓이지 못하고, 기껏 쌓인 경험조차 사장되는 상황.

필요성의 공감대 부재와 함께 매뉴얼을 매뉴얼에 그치게 만드는 또 하나의 이유는 기술자를 바라보는 독특한 시선이 아닐까 한다. 상하관계로만 접근하는 회사 문화 때문에 나이 먹고도 기술 붙잡고 있으면 불쌍하게 바라보는 시선?

본사를 방문하고 가장 놀란 건, 50세를 넘는 사람들이 거의 없다는 거예요. 전반적으로 사람들이 너무 어려요. 도대체 나이 든 사람들은 어디 갔냐고 물었더니, 지금 해고되서 치킨집을 하고 있다고 하더라고요. 이런 식으로 어떻게 노하우와 경험들이 어린 사람들에게 전수되겠어요?

살짝 치우쳐 보이기도 하지만 특히 IT 분야 종사자라면 외국인이 바라본 한국의 회사 문화에 대해서 대체로 수긍할 법한 대목이다.

누가 해도 같은 기술이란 인식이 노하우나 경험을 인정하지 않게 만들었을 것이다. 방법은 다름을 보여주는 수 밖에. 다름을 보여주면 그 때는 그 다름이 '돈이 되냐, 안 되냐'의 벽을 만나게 되겠지만(..)

공감대를 형성하려면 어떻게 해야 할까? 

'착각하는 CEO'에 이런 구절이 있다.

5%의 구성원이 나머지 95%를 견인할 수 있다 (102 페이지)

'변화의 5% 법칙'이라고 하는데 최종보스가 5%의 중간보스들 갈구는 거면 모를까, 별로 쉬워보이진 않는다. 그래도 방법은 동조자가 나올 때까지 근거를 보여주면서 계속 떠드는 것뿐인 듯.

내년부터는 정규표현식의 유용함을 알릴 수 있는 사례를 Snort에만 한정하지 않고 더 확대해볼 생각이다. 뭐가 있을까?

관련 글

• Snort 교육 안 하나요?