소프트웨어가 그 어느 때보다 강력한 힘을 발휘하는 지금, 개발자와 보안 담당자의 사이를 좁히는 것이 관건이다. 하지만 둘 사이가 너무 벌어져 봉합이 쉽지 않다. 둘에게만 맡겨서는 안 된다.
[보안뉴스 문가용 기자] 보안과 개발은 ‘절친’이라고 하기에는 무리가 있는 관계를 유지하고 있다. 물론 이는 누구의 잘못도 아니다. 다만 여태까지 해왔던 일의 방식 때문에 어쩔 수가 없었을 뿐이다. 보안 인력들이 가장 우선시 하는 건 조직을 위협하는 요소들을 파악해 위험을 최소화하는 것이다. 개발자들이 가장 우선시 하는 건 더 많은 기능을 더 빨리 배포하는 것이다. 게다가 두 그룹은 항상 별개로 일해 왔기 때문에 서로를 이해하기가 더 어려웠다.
하지만 이것이 자연스럽게 형성된 관계라고 해서 방치해서는 안 된다. 이 관계가 유지되면 보안 팀에게 자꾸 개발자들이 혼나면서 ‘공포의 문화’가 형성되기 때문이다. 위축된 개발자는 제대로 자기 능력을 발휘하지 못한다. 자기 능력을 발휘못할 뿐 아니라 보안 수칙도 잘 못 지키게 된다. 보안을 IT 담당자만이 아니라 모두의 몫으로 인지하게 하는 문화가 필요하다. 시스코의 웬디 네이더(Wendy Nather)는 “보안은 엔지니어링의 산물처럼 태어나 규정으로서 적용되는 게 아니라, 문화로서 모두의 마음 밑바탕에 심겨져야 하는 것”이라고 표현한다.
그러려면 개발자들에게 어떻게 접근해야 하는가? 개발자들이 만든 오류들이나 구멍들의 개수를 세서 성적을 매길 것이 아니라, 그런 구멍들을 얼마나 빨리 발견하고 고치는 지에 따라 평가를 해야 한다. 그 누구도 애플리케이션이 해킹 도구로 전락하는 걸 원하지 않는다. 애플리케이션을 만든 사람인 개발자는 더 그렇다. 조금만 접근법을 달리 하면 그들 안에 내재된 보안 욕구를 불러일으킬 수 있다. 그렇게 된다면 보안과 개발이 하나로 부드럽게 합쳐질 수 있게 된다.
접근하기 쉬운 보안
개발자들에게 가장 끔찍한 것 중 하나는 한창 프로젝트를 진행하는 중에 보안 담당자들로부터 25페이지짜리 애플리케이션 검토 결과 보고서와 보안 제언서를 받는 것이다. 이런 문서들은 이해하기도 어렵고, 심지어 이거 다 읽고 반영하다가 워크플로우가 심하게 흐트러지거나 심지어 마비되기도 한다. 왜? 보안 담당자들에게 익숙한 언어로 - 그리고 개발자들에게는 낯선 언어로 - 작성되어 있기 때문이다.
보안 팀이 개발자들에게 “비승인 노출 및 조작으로부터 인증기를 보호해야 한다”는 제안을 했다고 하자. 평범한 개발자들 중 이 말을 제대로 이해하는 사람은 의외로 찾기 힘들다. 아무리 중요한 내용이어도 이해를 못하면 구현되지 않는다. 그러면 인증 장치가 취약한 채로 개발이 완료된다. 정말로 애플리케이션이 안전해지길 원한다면 개발자가 알아들을 수 있는 말을 해야 한다. 다시 말하지만 개발자들도 자신들이 만든 애플리케이션이 안전하고 튼튼하기를 원하는 사람들이다.
곧바로 행동에 옮길 수 있는 보안
개발자들이 쉽게 이해할 수 있는 보안이라는 건 시작에 불과하다. 이제 이해를 하기 시작한 개발자들이 일어나 행동을 취할 수 있도록 해야 한다. 개발자들이 행동을 빨리 해 주어서 취약점이 빨리 발견되고 빨리 해결되면 보안 담당자들도 편해진다. 그러니 뭘 고쳐야 할지 지적하는 선에서 소통을 끝내서는 안 된다. 어떤 식으로 고쳐야 하는지까지도 다뤄 주어야 한다. 보안을 제대로 이해하고 있는 개발자는 그리 많지 않다. 특히 발견된 보안 문제점들을 해결하는 방법까지 잘 아는 사람은 거의 없다. 똑같이 IT 기술과 장비를 다룬다고는 하지만 전혀 다른 부류들이라는 걸 기억해야 한다.
개발자들은 잔소리로 조종할 수 있는 사람들이 전혀 아니다. 보안 담당자가 발견한 모든 문제들을 하나하나 자세하게 세부적으로 설명할 필요가 없다. 보다 정확히 말하면 ‘그게 왜 문제가 되는가’에 대해서는 그리 길게 설명하지 않아도 된다. 그렇다고 ‘고치는 방법은 알아서 연구해’라고 하는 것도 좋은 결과를 낳지 않는다. 그저 보안 담당자가 어떤 문제를 해결하고 싶은지만 알리면 된다. 매 사안마다 보안 강좌를 하지 않아야 하고, 개발자들이 즉각 작업에 착수할 수 있게 하는 깔끔 담백한 제안이 중요하다.
자동화 된 보안
깔끔하게 설명했고, 개발자가 빠르게 움직이도록 격려까지 했다. 그러면 됐을까? 더 속도를 높일 방법은 없을까? 하나 있는데, 바로 ‘자동화’ 기술이다. 재미있는 게, 보안과 개발 사이의 마찰이 일어나는 많은 이유들 중 하나가 바로 이 ‘자동화’ 때문이다. 개발자들은 각종 자동화 기술을 여기 저기 도입해 사용하는데, 보안은 여전히 수동의 관습이 진하게 남아 있어서 서로가 더욱 동떨어진 것처럼 느껴진다. 위에서 언급한 25페이지짜리 워드 문서도 그런 맥락에서 개발자들을 더 어렵게 만든다.
각종 자동화 기술을 탑재한 개발의 속도를 보안도 맞춰야 한다. 워드 문서를 작성하고, 그것을 같은 속도로 읽기를 바라는 것은 개발자들에게 원시적으로 느껴지기만 할 뿐이다. 보안에도 자동화가 어느 정도 도입되어야 한다는 건데, 사실 이건 조금 까다로울 수 있는 문제다. 시간을 들이고, 시장 조사도 하고, 자동화 기술을 현행 업무 프로세스에 도입했을 때의 문제점들을 파악하는 등의 노력을 기울여야 한다. 보안도 어느 정도 자동화가 되고, 개발과 속도가 맞춰진다면 둘은 견제가 아니라 도움을 주고받을 것이다.
올바른 타이밍의 보안
개발의 생애주기와 워크플로우에 있어서 보안은 언제 개입되는 게 가장 좋을까? 시작부터다. 시작에 가까우면 가까울수록 개발되는 애플리케이션이나 서비스는 안전해진다. 개발자들의 사기라는 측면에서도 마찬가지다. 기껏 개발을 다 해놓았더니 한 달 있다가 보안 점검표가 나오고, 그래서 다시 재작업을 하는 것처럼 짜증나는 상황이 없다. 무슨 말이냐면 개발자들에게 보안 제안을 하는 ‘타이밍’도 매우 중요한 요소라는 것이다. 이는 사실 보안 팀만의 문제가 아니라 회사 전체의 개발 플로우와 순서와도 깊은 연관성이 있다.
공포의 문화, 더 이상 허용해선 안 돼
결국 개발과 보안을 친해지게 하려면 조직 전체가 바뀌어야 한다. 개발 따로, 보안 따로, 각자가 잘 하는 걸 각자가 알아서, 서로를 터치하지 않은 채 잘하기를 기대하는 현재까지의 문화를 유지하는 것으로는 둘을 하나로 뭉치게 할 수 없다. 자동화 기술까지 도입함으로써 속도라는 면에서도 견줄 만하며, 서로가 서로의 업무 프로세스에 깊이 관여되도록(서로 통합되도록) 해야 한다. 개발 프로세스의 현대화를 꾀해야 한다는 뜻이다.
구멍에 따른 점수 삭감 제도를, 해결을 통한 점수 상승 제도로 바꾸는 것도 중요하다. 실수하지 않기에 급급하고 위축된 개발자들을 만드는 게 아니라, 실수하더라도 얼른 해결함으로써 당당할 수 있는 개발자들을 육성하는 게 기업 차원에서도 큰 도움이 된다. 그런 문화의 변혁을 보안 담당자들이 주도해야 한다. 그렇지 않으면 보안은 예전처럼 다시 뒷전이 될 테니까 말이다.
글 : 옴 비아스(Om Vyas), CPO, oak9
[국제부 문가용 기자(globoan@boannews.com)]
[보안뉴스 문가용 기자] 보안과 개발은 ‘절친’이라고 하기에는 무리가 있는 관계를 유지하고 있다. 물론 이는 누구의 잘못도 아니다. 다만 여태까지 해왔던 일의 방식 때문에 어쩔 수가 없었을 뿐이다. 보안 인력들이 가장 우선시 하는 건 조직을 위협하는 요소들을 파악해 위험을 최소화하는 것이다. 개발자들이 가장 우선시 하는 건 더 많은 기능을 더 빨리 배포하는 것이다. 게다가 두 그룹은 항상 별개로 일해 왔기 때문에 서로를 이해하기가 더 어려웠다.
[이미지 = utoimage]
하지만 이것이 자연스럽게 형성된 관계라고 해서 방치해서는 안 된다. 이 관계가 유지되면 보안 팀에게 자꾸 개발자들이 혼나면서 ‘공포의 문화’가 형성되기 때문이다. 위축된 개발자는 제대로 자기 능력을 발휘하지 못한다. 자기 능력을 발휘못할 뿐 아니라 보안 수칙도 잘 못 지키게 된다. 보안을 IT 담당자만이 아니라 모두의 몫으로 인지하게 하는 문화가 필요하다. 시스코의 웬디 네이더(Wendy Nather)는 “보안은 엔지니어링의 산물처럼 태어나 규정으로서 적용되는 게 아니라, 문화로서 모두의 마음 밑바탕에 심겨져야 하는 것”이라고 표현한다.
그러려면 개발자들에게 어떻게 접근해야 하는가? 개발자들이 만든 오류들이나 구멍들의 개수를 세서 성적을 매길 것이 아니라, 그런 구멍들을 얼마나 빨리 발견하고 고치는 지에 따라 평가를 해야 한다. 그 누구도 애플리케이션이 해킹 도구로 전락하는 걸 원하지 않는다. 애플리케이션을 만든 사람인 개발자는 더 그렇다. 조금만 접근법을 달리 하면 그들 안에 내재된 보안 욕구를 불러일으킬 수 있다. 그렇게 된다면 보안과 개발이 하나로 부드럽게 합쳐질 수 있게 된다.
접근하기 쉬운 보안
개발자들에게 가장 끔찍한 것 중 하나는 한창 프로젝트를 진행하는 중에 보안 담당자들로부터 25페이지짜리 애플리케이션 검토 결과 보고서와 보안 제언서를 받는 것이다. 이런 문서들은 이해하기도 어렵고, 심지어 이거 다 읽고 반영하다가 워크플로우가 심하게 흐트러지거나 심지어 마비되기도 한다. 왜? 보안 담당자들에게 익숙한 언어로 - 그리고 개발자들에게는 낯선 언어로 - 작성되어 있기 때문이다.
보안 팀이 개발자들에게 “비승인 노출 및 조작으로부터 인증기를 보호해야 한다”는 제안을 했다고 하자. 평범한 개발자들 중 이 말을 제대로 이해하는 사람은 의외로 찾기 힘들다. 아무리 중요한 내용이어도 이해를 못하면 구현되지 않는다. 그러면 인증 장치가 취약한 채로 개발이 완료된다. 정말로 애플리케이션이 안전해지길 원한다면 개발자가 알아들을 수 있는 말을 해야 한다. 다시 말하지만 개발자들도 자신들이 만든 애플리케이션이 안전하고 튼튼하기를 원하는 사람들이다.
곧바로 행동에 옮길 수 있는 보안
개발자들이 쉽게 이해할 수 있는 보안이라는 건 시작에 불과하다. 이제 이해를 하기 시작한 개발자들이 일어나 행동을 취할 수 있도록 해야 한다. 개발자들이 행동을 빨리 해 주어서 취약점이 빨리 발견되고 빨리 해결되면 보안 담당자들도 편해진다. 그러니 뭘 고쳐야 할지 지적하는 선에서 소통을 끝내서는 안 된다. 어떤 식으로 고쳐야 하는지까지도 다뤄 주어야 한다. 보안을 제대로 이해하고 있는 개발자는 그리 많지 않다. 특히 발견된 보안 문제점들을 해결하는 방법까지 잘 아는 사람은 거의 없다. 똑같이 IT 기술과 장비를 다룬다고는 하지만 전혀 다른 부류들이라는 걸 기억해야 한다.
개발자들은 잔소리로 조종할 수 있는 사람들이 전혀 아니다. 보안 담당자가 발견한 모든 문제들을 하나하나 자세하게 세부적으로 설명할 필요가 없다. 보다 정확히 말하면 ‘그게 왜 문제가 되는가’에 대해서는 그리 길게 설명하지 않아도 된다. 그렇다고 ‘고치는 방법은 알아서 연구해’라고 하는 것도 좋은 결과를 낳지 않는다. 그저 보안 담당자가 어떤 문제를 해결하고 싶은지만 알리면 된다. 매 사안마다 보안 강좌를 하지 않아야 하고, 개발자들이 즉각 작업에 착수할 수 있게 하는 깔끔 담백한 제안이 중요하다.
자동화 된 보안
깔끔하게 설명했고, 개발자가 빠르게 움직이도록 격려까지 했다. 그러면 됐을까? 더 속도를 높일 방법은 없을까? 하나 있는데, 바로 ‘자동화’ 기술이다. 재미있는 게, 보안과 개발 사이의 마찰이 일어나는 많은 이유들 중 하나가 바로 이 ‘자동화’ 때문이다. 개발자들은 각종 자동화 기술을 여기 저기 도입해 사용하는데, 보안은 여전히 수동의 관습이 진하게 남아 있어서 서로가 더욱 동떨어진 것처럼 느껴진다. 위에서 언급한 25페이지짜리 워드 문서도 그런 맥락에서 개발자들을 더 어렵게 만든다.
각종 자동화 기술을 탑재한 개발의 속도를 보안도 맞춰야 한다. 워드 문서를 작성하고, 그것을 같은 속도로 읽기를 바라는 것은 개발자들에게 원시적으로 느껴지기만 할 뿐이다. 보안에도 자동화가 어느 정도 도입되어야 한다는 건데, 사실 이건 조금 까다로울 수 있는 문제다. 시간을 들이고, 시장 조사도 하고, 자동화 기술을 현행 업무 프로세스에 도입했을 때의 문제점들을 파악하는 등의 노력을 기울여야 한다. 보안도 어느 정도 자동화가 되고, 개발과 속도가 맞춰진다면 둘은 견제가 아니라 도움을 주고받을 것이다.
올바른 타이밍의 보안
개발의 생애주기와 워크플로우에 있어서 보안은 언제 개입되는 게 가장 좋을까? 시작부터다. 시작에 가까우면 가까울수록 개발되는 애플리케이션이나 서비스는 안전해진다. 개발자들의 사기라는 측면에서도 마찬가지다. 기껏 개발을 다 해놓았더니 한 달 있다가 보안 점검표가 나오고, 그래서 다시 재작업을 하는 것처럼 짜증나는 상황이 없다. 무슨 말이냐면 개발자들에게 보안 제안을 하는 ‘타이밍’도 매우 중요한 요소라는 것이다. 이는 사실 보안 팀만의 문제가 아니라 회사 전체의 개발 플로우와 순서와도 깊은 연관성이 있다.
공포의 문화, 더 이상 허용해선 안 돼
결국 개발과 보안을 친해지게 하려면 조직 전체가 바뀌어야 한다. 개발 따로, 보안 따로, 각자가 잘 하는 걸 각자가 알아서, 서로를 터치하지 않은 채 잘하기를 기대하는 현재까지의 문화를 유지하는 것으로는 둘을 하나로 뭉치게 할 수 없다. 자동화 기술까지 도입함으로써 속도라는 면에서도 견줄 만하며, 서로가 서로의 업무 프로세스에 깊이 관여되도록(서로 통합되도록) 해야 한다. 개발 프로세스의 현대화를 꾀해야 한다는 뜻이다.
구멍에 따른 점수 삭감 제도를, 해결을 통한 점수 상승 제도로 바꾸는 것도 중요하다. 실수하지 않기에 급급하고 위축된 개발자들을 만드는 게 아니라, 실수하더라도 얼른 해결함으로써 당당할 수 있는 개발자들을 육성하는 게 기업 차원에서도 큰 도움이 된다. 그런 문화의 변혁을 보안 담당자들이 주도해야 한다. 그렇지 않으면 보안은 예전처럼 다시 뒷전이 될 테니까 말이다.
글 : 옴 비아스(Om Vyas), CPO, oak9
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-24] 
.jpg)
.jpg)
