20P by carnoxen 13일전 | ★ favorite | 댓글 8개

제품 자체에 있어

메모리에 안전하지 않는 언어(C, C++ 등)

가급적 메모리에 안전한 단어를 쓰고, 그러지 않은 기존 프로그램은 2025년 말까지 점진적으로 대체해야 합니다.

SQL 명령문 직접 실행

매개변수화된 쿼리, 미리 정의된 명령문이나 ORM을 쓰세요.

운영체제 명령 직접 실행

사용자가 입력할 내용이 명령 자체가 아니어야 합니다. 명령을 바로 실행하는 대신 내장된 라이브러리 함수를 사용하거나 입력에 영문/숫자/밑줄만 허용하게 만들어야 합니다.

너무 유명한 비밀번호 사용

아래와 같은 방법으로 가급적 피하게 만들어야 합니다.

  • 처음부터 고유의 암호를 제공합니다.
  • 설치 중 사용자가 강력한 암호를 생성하도록 요구합니다.
  • MFA처럼 암호에 시간 제한을 설정합니다.
  • 확실한 자격을 얻기 위한 물리적 접근을 요구합니다.
  • 캠페인을 벌이거나 기존보다 안전한 인증 방식으로 전환합니다.

알려진 취약점 방치

해당 페이지에 나와 있는 취약점은 "모두" 방지되어야 합니다. 새로운 취약점이 보고될 경우 이를 적시에 해결하고, 해결된 버전을 업데이트하지 않는 사용자에게 경고를 줘야 합니다.

취약점이 있는 오픈 소스 라이브러리

사용하고 있는 라이브러리에 책임감 있게 해당 사항을 알리고 기여해야 합니다. 다음과 같은 조치도 포함합니다.

  • SBOM 작성: 소프트웨어가 어떤 라이브러리를 사용하는지 보여줍니다.
  • 의존하는 오픈 소스 라이브러리에 적용할 사안
    • 보안 검사를 실시합니다.
    • 지속적이고, 잘 보호되고, 잘 유지보수하고 있는 질 좋은 프로젝트를 선택합니다. 이런 보안 원칙을 지키는 것도 좋습니다.
    • 잘 알려진 취약점이 있는지 꾸준히 조사해야 합니다.
    • 복사본을 제조업체가 미리 가지고 있어야 하고, 검증되지 않은 곳에서 업데이트하지 말아야 합니다.
  • 새로운 주요 버전으로 업데이트하거나 보안 패치를 받는 비용을 감안해야 합니다.
    만약 취약점이 제품에 영향을 끼치지 않을 경우, 그 취약점이 왜 영향을 끼치지 않는지 공개적으로 알려야합니다.

취약점이 있거나 알려지지 않은 암호화 알고리즘(TLS 1.0/1.1, DES, MD5 등)

최신 알고리즘을 사용해야 합니다. 추가로 NIST의 지침에 따라 표준화된 양자 암호화 알고리즘도 준비해야 합니다.

소스 코드에 들어 있는 비밀 키

비밀 관리자(Secret Manager)를 이용해 프로그램이 비밀 키를 안전하게 검색할 수 있게 만들어야 합니다. 또한 소스 코드에 비밀 키가 있는지 검사해야 합니다.

보안 기능에 있어

MFA 미지원(패스키만 지원하는 것도 포함)

응급실 의료기기같이 지연되면 위험한 것을 제외하고, 기본적으로 MFA를 직접 만들거나 외부 인증기를 사용하도록 해야 합니다. 이를 관리자에게 요구해야 하며, 관리자는 조직 내 사용자에게 이를 요구해야 합니다.

침입 증거 미제공

  • 매우 기초적인 기능으로서, 설정의 변경이나 조회, 로그인 이력, 정보 접근과 관련된 로그를 생성해야 합니다.
  • 클라우드 제공사의 경우, 추가 비용 없이 최소 6개월 동안 이러한 로그를 보관, 사용자가 볼 수 있도록 만들어야 합니다.

조직 프로세스 및 정책에 있어

CVE 미발행

치명적이거나 큰 영향을 줄 수 있는 취약점은 즉시 공개되어야 합니다.

취약점 공개 방식(VDP) 미공개

다음과 같은 정책을 공개해야 합니다.

  • 일반 대중의 테스트 승인
  • 선의의 노력을 기울이는 사람에 대해 법적 조치하지 않을 것을 약속
  • 보고할 수 있는 명확한 채널
  • CVD(Coordinated Vulnerability Disclosure) 모범 사례 및 국제 표준
    보고된 취약점을 적시에, 위험도 순으로 수정해야 합니다.

(온 프레미스의 경우) 불명확한 지원 기간

명확하게 지원 기간을 전달하고, 그 기간 동안 보안 업데이트를 제공해야 합니다.


이런 지침을 바라보는 여러 입장을 봐 왔지만

  1. 이런 건 기본 아니야? 이걸 누가 안 지켜?
  2. 당연히 지키지 (일부 항목 예외 처리)
  3. 원칙인 건 알지. 근데 그거 하나하나 언제 다 맞추고 지켜.
  4. 그거 아무 쓸모 없어. 보안 그렇게 챙겨 놔도 어차피 뚫리는데?

이렇게 의견이 갈리더라구요.

이쪽 일을 하기에 마음은 1번인데 현업 일하면서 3,4번 입장을 가지신 분들이
강경할 때마다 매번 마음이 꺾입니다. 2번 정도만 되어도 좋을텐데 말이죠.

다시 ORM쓰지 말자는 이야기가돌던데..

ORM 대신 Prepared Statement를 쓰면됩니다.

뭐든 원칙은 있죠 지키기 어려울뿐...

보안은, 아차하는 순간,,! (이라는걸 군대에서 본것같은데)

좋아요 찬성해요
사용자가 강력한 암호를 생성하도록 요구 != 특수문자, 영어대소문자, 숫자 반드시 포함
그냥 길이 적당히 길기만 해도 강력한 암호입니다.