2025/09 3

Spring Boot 취약점 체크리스트 초안을 만들며

조직마다 개발을 할 때 애용하는 프레임워크가 있기 마련이다. 그런데 그런 프레임워크들에 대해서 취약점 진단을 할 때는 어떻게 해야 하는지 다소 어려움을 맞이하게 된다. 전자금융 체크리스트로 억지로 끼워 맞추면, WEB/WAS 항목을 적용할 수는 있겠으나, 실무와는 괴리감이 크다. 현재의 고객사는 Spring Boot를 애용하고 있고, 그래서 무언가 새로운 진단 항목을 만드는 것이 좋겠다는 생각이 들어 체크리스트를 만들어 보게 되었다. 개인적으로 새로운 기준을 들이밀 때 가장 중요한 것 중 하나는 담당자의 저항에 관한 것이다. '귀찮지만, 이 정도는 할 수 있지'라는 수준을 어림짐작하여 맞춰야 한다는 점이다. 너무 많은 진단 항목을 들이밀면 거부감이 커질 수밖에 없고, 보안이라는 것에 대해 반감만 커질 수..

기타 2025.09.29

조직 내 보안인식 제고를 위한 정보보호 퀴즈를 경험하며

현재 들어와 있는 고객사에서는 매달 정보보호의 날을 지정하여 임직원들의 정보보호 퀴즈를 독려하고 있다. 정답을 맞춘 사람 중 n명을 선정하여 소정의 상품을 전달하며 말이다. 7월, 8월, 9월까지 3번의 정보보호 퀴즈를 참여하며 개선사항에 대해 생각했는데, 문제와 개선점은 다음과 같다. 문제점1. 노션과 같이 모두가 공유 가능한 플랫폼에 정답을 '댓글'로 달게 함으로써, 임직원들이 문제를 제대로 보지도 않고 답을 다는 상황이 발생한다. 특히 이번 9월의 퀴즈를 보며 그걸 확신하게 되었다. 왜냐하면, 퀴즈 중 하나가 답이 분명 1번인데, 댓글에는 모두 3번이라고 도배되었기 때문이다. 이유는 첫번째 댓글을 단 사람이 3번이라고 적었기 때문이다. 아마 예측컨대, 초반에 퀴즈를 풀어 댓글을 다는 사람들 중 상당..

기타 2025.09.28

서버의 기술적 취약점 추가 항목 고찰

현재 금융권 프로젝트에서 관리체계 진단, 기술적 취약점 진단을 모두 수행하고 있는데, 참 코에 걸면 코걸이, 귀에 걸면 귀걸이 같은 상황을 자주 겪으며 회의감을 느끼곤 한다. 특히 기술적 진단이 그러한데, 점수에 지나치게 집착하는 현재의 국면에 변화가 오지 않는 한, 진단을 수행할 때마다 회의감을 느끼지 않을까 싶다. 그런데 관리적 진단이건, 기술적 진단이건, 수행을 하다 보면, 어느새 금보원에서 요구하는 기준을 '최소한'의 기준이 아닌, 최대한의 기준으로 받아들이는 경우를 항상 접하게 된다. 고객사 담당자도, 컨설턴트인 우리도 말이다. 하지만 본디 컨설팅은 보안 환경의 변화에 맞춰 한 발자국 더 나아가야 하고, 기술적 취약점 진단에서 조금 더 항목을 만들어 보자는 생각을 하게 되었다. 물론 너무 깊게 ..

기타 2025.09.07
728x90