📚 지식 노트

피싱과 사회공학: 기술 대신 사람을 속인다

암호가 아무리 튼튼해도 사용자가 비밀번호를 직접 건네면 소용이 없다. 사회공학(social engineering)은 시스템의 약점 대신 사람의 신뢰, 두려움, 서두름을 이용해 정보를 얻거나 행동을 끌어내는 공격이다. 그중 가장 흔한 것이 피싱(phishing)으로, 믿을 만한 기관이나 사람인 척 메시지를 보내 가짜 로그인 화면으로 이끌거나 악성 첨부 파일을 열게 한다.

수법은 달라도 신호는 비슷하다. 보낸 주소가 진짜와 한두 글자 다르고, 시간 압박을 걸고, 평소라면 묻지 않을 비밀번호나 인증번호를 요구한다. 링크의 보이는 글자와 실제 목적지가 다르고, 예상하지 못한 첨부 파일이 붙어 있다. 미국 CISA의 Recognize and Report Phishing과 영국 NCSC의 Phishing attacks: defending your organisation이 이 신호와 조직 차원의 방어를 정리한다.

가장 좋은 대응은 메시지 안의 링크와 전화번호를 쓰지 않는 습관이다. 의심스러우면 즐겨찾기나 직접 입력한 주소로 들어가 확인하고, 전화는 공식 번호로 다시 건다. 한 사람의 눈에만 기대지 않도록 조직은 메일 필터, 신고 버튼, 송금 전 이중 확인 절차를 함께 둔다. 기술 쪽에서는 피싱에 강한 인증이 결정적이다. 패스키는 등록한 사이트의 도메인에만 응답하므로 가짜 사이트에서는 아예 동작하지 않는다(인증과 인가 노트).

흔한 오해 몇 가지.

• "주소창에 자물쇠가 있으니 진짜 사이트다": 자물쇠는 그 도메인과의 통신이 암호화됐다는 뜻일 뿐이다. 피싱 사이트도 자기 도메인의 인증서를 쉽게 받는다(네트워크 보안 노트의 인증서 절).
• "문자 인증번호(OTP)를 켰으니 피싱은 괜찮다": 가짜 사이트가 입력받은 비밀번호와 인증번호를 그 자리에서 진짜 사이트로 넘기면 로그인이 그대로 된다. 전화로 "본인 확인"이라며 인증번호를 묻는 수법도 같은 원리다. 인증번호는 누구에게도 불러 주지 않고, 피싱에 버티는 것은 패스키와 보안 키뿐이다(다중 인증 절).
• "보낸 사람 이름이 맞으니 믿어도 된다": 표시 이름은 아무나 정한다. 메일 서버가 보낸 도메인을 확인하는 SPF·DKIM·DMARC는 이메일 노트에 있고, 그래도 계좌 변경 같은 요청은 다른 경로로 다시 확인한다.

비밀번호 관리자와 패스키

사람이 수십 개 사이트의 서로 다른 긴 비밀번호를 기억하기는 어렵다. 그래서 하나를 여러 곳에 돌려 쓰게 되고, 공격자는 바로 그 습관을 노린다. 어느 한 사이트에서 유출된 아이디와 비밀번호 목록을 다른 사이트에 그대로 넣어 보는 크리덴셜 스터핑(credential stuffing)이다. 피해 사이트가 아무리 잘 지켜도, 사용자가 다른 곳에서 같은 비밀번호를 썼다면 막을 수 없다.

비밀번호 관리자(password manager)는 사이트마다 길고 무작위인 비밀번호를 만들어 암호화해 보관하고, 사용자는 관리자를 여는 마스터 비밀번호 하나만 기억한다. 덤으로 피싱도 막는다. 자동 채우기는 저장한 도메인과 지금 주소가 같을 때만 동작하므로, 비슷하게 생긴 가짜 사이트에서는 비밀번호가 채워지지 않는다. 그때 손으로 복사해 넣지 않는 것이 요령이다. 마스터 비밀번호는 길게 만들고, 관리자 계정 자체에 다중 인증을 건다. CISA의 Use Strong Passwords와 Turn On MFA가 일반 사용자용 안내다.

패스키(FIDO Alliance)는 비밀번호 자체를 없애는 방향이다. 기기 안의 개인키가 사이트가 보낸 도전값에 서명하고, 사용자는 지문이나 화면 잠금으로 그 서명을 허락한다. 동작 원리는 인증과 인가 노트의 패스키 절에, 서명 자체는 암호 노트에 있다.

백업과 랜섬웨어 대비: 3-2-1 규칙

랜섬웨어(ransomware)는 파일을 암호화해 쓸 수 없게 만든 뒤 풀어 주는 대가를 요구하는 악성 프로그램이다. 요즘은 암호화하기 전에 데이터를 빼내 두고 공개하겠다고 다시 협박하는 이중 협박도 흔하다. 돈을 내도 복구된다는 보장은 없다. 그래서 대비의 중심은 언제든 깨끗한 상태로 되돌릴 수 있는 백업이다.

오래 쓰인 기준이 3-2-1 규칙이다. 데이터 복사본을 세 벌 두고, 그중 둘은 서로 다른 종류의 매체에, 하나는 다른 장소에 둔다. 디스크 하나의 고장, 같은 기종의 동시 고장, 화재나 도난을 각각 견디게 하는 셈이다. CISA의 Data Backup Options가 이 규칙과 매체별 장단점을 정리한다.

랜섬웨어는 연결된 드라이브와 공유 폴더까지 함께 암호화하므로, 늘 꽂혀 있는 백업 디스크는 원본과 같이 당한다. 적어도 한 벌은 평소 끊어 두는 오프라인 사본이거나, 정해진 기간 동안 지우거나 고칠 수 없는 변경 불가(immutable) 저장소여야 한다. 클라우드 동기화는 백업이 아니라는 점도 기억한다. 원본이 암호화되거나 지워지면 동기화는 그 변화도 성실히 옮긴다. 이전 버전을 보관하는 기능이 있어야 백업 구실을 한다.

마지막은 복원 연습이다. 백업이 실제로 되돌려지는지, 얼마나 걸리는지 미리 해 보지 않으면 사고 당일에 처음 알게 된다. CISA의 #StopRansomware Guide는 오프라인·암호화 백업 유지와 정기 복원 시험을 대비 항목의 앞자리에 둔다. 국내에서는 한국인터넷진흥원(KISA)이 운영하는 보호나라에 침해사고를 신고하고, 118 전화로 해킹 상담을 받을 수 있다.

패치: 알려진 구멍부터 막는다

실제 침해의 상당수는 새로 발견된 기법이 아니라 이미 고친 지 오래된 취약점에서 나온다. 패치가 공개되면 변경 내용이 곧 어디가 약했는지 알려 주는 단서가 되므로, 공개 직후부터 공격 시도가 늘어난다. 패치가 나온 날부터 내가 적용한 날까지가 알려진 취약점에 노출된 기간이고, 패치 관리는 이 기간을 줄이는 일이다.

• 운영체제, 브라우저, 앱은 자동 업데이트를 켠다. 브라우저는 다시 시작해야 적용되는 경우가 많다(CISA: Update Software).
• 조직에서는 우선순위가 필요하다. CISA의 Known Exploited Vulnerabilities 목록은 실제 공격에 쓰인 것으로 확인된 취약점을 모아, 점수만 높은 것보다 먼저 고칠 곳을 알려 준다.
• 공유기, 프린터, 카메라 같은 기기의 펌웨어도 소프트웨어다. 지원이 끝난(end of life) 제품은 더 이상 패치가 나오지 않으므로 교체를 계획한다.
• 라이브러리 같은 의존성의 업데이트는 시스템·소프트웨어 보안 노트의 공급망 절에서 다룬다.

사고 대응: 터지기 전에 정해 두는 순서

예방이 언젠가 실패한다는 전제에서 보안 사고(incident)가 났을 때 누가 무엇을 할지를 미리 정해 두는 것이 사고 대응(incident response)이다. 미국 NIST의 지침 SP 800-61 Rev. 2(2012)가 정리한 네 단계 생애주기가 오랫동안 기준으로 쓰였다.

2025년에 나온 SP 800-61 Rev. 3은 Rev. 2를 대신하며, 사고 대응을 따로 떼지 않고 NIST 사이버보안 프레임워크(CSF) 2.0의 여섯 기능(거버넌스, 식별, 보호, 탐지, 대응, 복구) 전체에 걸친 위험 관리의 일부로 다시 묶었다. 단계 이름은 달라졌지만, 준비하고 알아채고 막고 되돌리고 배우는 흐름은 같다.

보안 관제: SOC, SIEM, EDR, SOAR

앞 절의 탐지·분석을 날마다 맡는 조직이 SOC(Security Operations Center, 보안 관제 센터)다. 한국에서는 흔히 "관제"라 부르고, 전문 업체에 맡기는 원격 관제도 많다. SOC가 쓰는 도구 이름은 비슷해서 헷갈리기 쉬운데, 흐름으로 보면 단순하다. 여러 곳의 기록을 모으고, 서로 엮어 의미 있는 경보로 만들고, 사람이 판단하고, 정해 둔 절차대로 대응한다.

SIEM의 바탕은 로그 관리이고, 무엇을 얼마나 모으고 보관할지는 미국 NIST의 SP 800-92가 정리한다. 로그를 모으는 파이프라인 자체는 관측성 노트와 같은 기술이다. 관제가 흔히 무너지는 곳은 두 군데다. 경보가 너무 많아 진짜를 놓치는 경보 피로(alert fatigue), 그리고 기록은 모으는데 아무도 보지 않는 상태로, 후자는 OWASP Top 10의 보안 로깅·경보 실패(A09)와 같다. 무엇을 탐지해야 하는지는 실제 공격 기법을 단계별로 정리한 MITRE ATT&CK에 탐지 규칙을 맞춰 보며 빈 곳을 찾는 방식이 널리 쓰인다.

취약점 진단, 모의 해킹, 레드팀, 버그 바운티

공격자보다 먼저 구멍을 찾는 일도 이름이 여럿이다. 넓이와 깊이, 누가 하는지가 다르고, 보통 서로를 대신하지 않고 함께 쓴다. 시험을 계획하고 결과를 다루는 기술 지침으로는 NIST의 SP 800-115가 오래 쓰였다.

• "스캐너가 이상 없다니 안전하다"는 오해다. 자동 도구는 알려진 모양을 잘 찾지만, 남의 주문을 보는 권한 확인 누락(IDOR)이나 업무 흐름의 허점 같은 논리 결함은 거의 못 찾는다.
• 모든 시험은 서면 허락과 범위가 먼저다. 허락 없이 남의 시스템을 시험하면 의도와 상관없이 불법이 될 수 있고, 버그 바운티도 공개된 범위 안에서만 보호받는다.
• 찾은 것은 다음 절의 공개 절차와 이어진다. 남의 제품에서 찾았다면 제조사에 먼저 알린다.

책임 있는 공개와 CVE·CVSS

취약점을 찾은 사람이 바로 세상에 알리면 패치가 나오기 전까지 모든 사용자가 위험해진다. 반대로 영영 알리지 않으면 고쳐지지 않는다. 조율된 공개(coordinated vulnerability disclosure, 흔히 책임 있는 공개)는 먼저 제조사에만 비공개로 알리고, 고칠 시간을 준 뒤 정해진 날에 함께 공개하는 관행이다. 기한은 흔히 수십 일에서 90일 안팎으로 잡고, 제조사가 응답하지 않으면 발견자가 기한 뒤에 공개하기도 한다. 발견자와 제조사 양쪽이 지킬 점은 OWASP의 Vulnerability Disclosure Cheat Sheet가 정리한다. 공개 정책과 버그 바운티(bug bounty)는 허락된 범위 안의 조사를 보호해 주는 약속이기도 하므로, 범위 밖 시스템을 건드리지 않는 것이 전제다.

공개된 취약점에는 CVE(Common Vulnerabilities and Exposures) 번호가 붙는다. 형식은 CVE-연도-일련번호이고, 제조사나 보안 기관 같은 CVE 번호 발급 기관(CNA)이 발급한다. 번호 자체는 이름표일 뿐이지만, 덕분에 권고문, 스캐너, 패치 목록이 같은 취약점을 한 이름으로 가리킨다.

심각도는 FIRST가 관리하는 CVSS(Common Vulnerability Scoring System)로 0.0~10.0 점수를 매긴다. 원격에서 되는지, 로그인이 필요한지, 사용자의 행동이 필요한지, 기밀성·무결성·가용성에 어떤 영향을 주는지 같은 항목을 조합해 계산한다. 2023년에 나온 CVSS v4.0도 점수 구간 이름은 이전과 같다.

점수는 취약점 자체의 심각도이지 우리 조직의 위험이 아니다. 내부망에만 있는 9.8점보다 인터넷에 열린 서버의 7.5점이, 그리고 실제 공격에 쓰이고 있는 취약점이 더 급할 수 있다. 그래서 점수와 함께 노출 여부, 실제 악용 여부(앞 절의 KEV 목록)를 같이 본다. FIRST의 EPSS(Exploit Prediction Scoring System)는 공개된 CVE마다 앞으로 30일 안에 실제로 악용될 확률을 0~1로 추정해 날마다 내놓는다. CVSS는 얼마나 심각한가, EPSS는 얼마나 쓰일 것 같은가, KEV는 이미 쓰였는가를 답하므로 셋을 함께 보면 고칠 순서가 분명해진다.

security.txt: 신고받을 창구를 밝혀 둔다

선의의 발견자가 가장 먼저 막히는 곳은 누구에게 알려야 하는지다. RFC 9116(2022)이 정한 security.txt는 사이트의 /.well-known/security.txt 경로에 보안 연락처와 정책을 적어 두는 작은 글 파일이다. 사람과 도구가 같은 자리에서 찾을 수 있도록 위치와 형식을 정해 둔 것이다.

• Contact는 여러 줄 둘 수 있고 이메일, 웹 양식 주소, 전화번호를 쓴다. 개인 메일보다 담당 팀의 공용 주소가 낫다.
• Expires가 지난 파일은 믿지 않는다는 뜻이므로 갱신을 일정에 넣는다.
• Policy에는 신고 범위, 허락하는 조사, 응답 기한 같은 공개 정책을 링크하고, Acknowledgments로 감사 명단을 걸 수 있다.
• 파일에 OpenPGP 서명을 붙여 위조를 막을 수 있고, securitytxt.org에서 형식에 맞는 파일을 만들어 볼 수 있다.

security.txt는 받는 쪽의 준비다. 파일을 올려 두었다면 그 주소로 온 신고를 누가 언제 읽고 답할지까지 앞 절의 사고 대응 절차에 넣어야 창구가 실제로 열린다.

인증 제도: ISMS와 ISMS-P

한국에서 회사의 "보안 인증"이라 하면 대개 ISMS와 ISMS-P를 가리킨다. 둘 다 조직이 보안과 개인정보 보호의 관리 체계를 세워 실제로 운영하는지 심사해 인증하는 제도다. 2018년부터 하나의 관리체계로 묶여 운영되지만 인증서는 여전히 둘로 나뉜다(바이라인네트워크의 ISMS-P 해설, 2025년 11월 기준).

흔한 오해는 "인증을 받았으니 해킹당하지 않는다"다. 인증은 심사한 때에 관리 체계가 갖춰져 있었다는 확인이다. 인증 범위 밖의 시스템, 심사 뒤에 생긴 패치 누락, 문서는 맞지만 실제 설정이 틀린 경우는 걸러지지 않는다. 인증 기업의 큰 사고가 잇따르자 정부는 2025년에 중대한 결함이 드러나면 인증을 취소하고 다시 심사하는 등 사후 점검을 강화하겠다고 밝혔다. 국제적으로는 정보보호 관리체계 표준인 ISO/IEC 27001이 비슷한 자리에 있다. 개인정보 보호법 자체는 개인정보 노트, 공공·금융권의 망분리 규제는 네트워크 보안 노트에 있다.