Previous   Next   Top   Detailed TOC         Last Update: 16 Jun 2000

21 부록 C: 참고자료

• 21.0 참고자료 목록 및 사본
• 21.1 보안 정보: 어디에서 얻을 수 있나?
  • 바쁜 사람들을 위한 속성 가이드!
  • 연락처 & 링크:
    • 바이러스
    • 대응팀
    • 보안 전반
    • 벤더
    • 방화벽
    • 보안 해킹
    • 언더그라운드
    • 기타
• 21.2 보안 조직
  • FIRST (Forum of Incident Response and Security Teams)
    • CERT
    • 유럽 비상대응팀
    • AUSCERT
    • NASIRC (NASA Response Team)
    • CIAC (U.S. department of energy (DOE) Response Team) (June'96)
  • 프랑스 조직 (TBD)
  • 미국 조직 / 기관
• 21.3 인터넷 해킹 그룹
• 21.4 보안 조직
  • 미국 표준: The Rainbow Books
  • The TCSEC "Orange Book"
    • 소개
    • Contacts
    • 2.0 DIVISION C: DISCRETIONARY PROTECTION 임의적 보호
  • The ITSEC - "European Orange Book"
    • 개요
    • ITSEC 도입부 인용문
    • Contacts
    • Example functionality class F-DX
  • ITSEM (extracts)
  • TTAP
  • Common Criteria 1.0

21.0 관련 자료 목록과 사본

다음 문서들은 로컬로 복사되어 있다:

당신의 시스템이 침입자에 의해 함락된다면 What if your Machines are Compromised by an Intruder Christopher Klaus of Internet Security Systems, Inc. <iss@iss.net>	compromise_faq.html
Tik-110.501 네트웍 보안에 대한 세미나 실용적인 암호시스템과 강도 Practical Cryptosystems and their Strength Janne Frosen Department of Computer Science Helsinki University of Technology Janne.Frosen@hut.fi     2.11.1995	CryptoAlgoStrength.html
보안평가 기준 ITSEC ITSEM TCSEC / Orange Book Common criteria (old version)	itsec.htm itsem.html tcsec.html commoncriteria.html
보안 메일링 리스트 FAQ, ISS	security_lists.html
Sniffer FAQ, ISS	sniff.html
암호화기술과 관련된 정책 리뷰 Review of Policy relating to Encryption Technologies (The Walsh Report) Dec.1998 이 파일은 이 보고서의 완전한 단일문서 버전이다. 원본 URL: http://www.efa.org.au/Issues/Crypto/Walsh/index.htm	walsh.zip
암호와 자유 1999 - 암호화정책에 대한 국제적 연구 Cryptography and Liberty 1999 - An International Survey of Encryption Policy 이것은 내가 알고 있는 국제 암호 정책 개론 중 가장 훌륭하다.	crytpo1999.htm.zip www2.epic.org/reports/crypto1999.html
프로그래밍 유닉스 프로그래밍 팁, SunWorld. Code Signing: how-to	swol-unix-programming.html Doc_CodeSigning.html
시스템 관리 인터넷 웹서버: best practices	webserver_practices.html
이 모든 보안 문제에서 인권을 잊지 말도록 하자..... 특히 프라이버시 측면에서 Don't forget human rights in all of this security stuff..... especially privacy aspects.	humanrights.html

21.1 보안 정보: 어디에서 얻을 수 있나?

참고 절에서 책 목록을 구할 수 있다.

이 절은 인터넷 참고자료를 많이 포함하고 있고, 거기다 보안 조직에 대한 설명과 이들에 의한 보안 권고문들이 발표되는 곳을 소개한다.
인터넷은 계속해서 변화하고 있으므로, 나열된 링크들 중 몇몇은 더이상 유효하지 않을 수도 있다. 이런 경우, 야후 나 알타비스타 같은 검색엔진을 이용하여 정보를 찾도록 한다 (아래 참조).

21.1.1 바쁜 사람들을 위한 속성 가이드!

• 인터넷에서 보안 정보 검색: 여기로 가본다.
  www.SecurityPortal.com 또는  www.SecurityFocus.com  또는  www.securitysearch.net ,
  the COAST archive coast.cs.purdue.edu/coast/coast.html, www.sans.org,  FIRST.
• 특정 정보에 대해 인터넷에 대한 전체 검색을 하려면 일반 검색 엔진으로 간다.

Yahoo: www.yahoo.com          Alta Visa: www.altavista.com
Lycos: www.lycos.com           Google:     www.google.com

• 가장 가까운 FIRST 메일링 리스트에 등록한다 (www.first.org 참조).
• CERT, CIAC 권고문들을 살펴보고 (아래 제목들 참조) 어떤 취약점들이 있는지에 대해 감을 잡는다.
• 이 책의 각 장은 관련 참고자료 목록을 가지고 있다.

21.1.2 Contacts: 이메일 리스트, 대응팀, 벤더, 패치 소스

바이러스 Contacts (oldish):

뉴스 그룹: comp.virus PC Viruses
PC 바이러스 정보 mailto:listserv%lehiibm1.bitnet@mitvma.mit.edu
body= "SUB VIRUS-L myname@my.domain"
NCSA ftp://ftp.ncsa.com/pub/virus/WildList
매크로 바이러스 목록ftp://ftp.informatik.uni-hamburg.de/pub/virus/macro/

대응팀 연락처:

FIRST mailto:first-sec@first.org
http://www.first.org [FIRST 홈페이지]

SWITCH CERT 스위스 mailto:cert-staff@switch.ch
CERT mailto:cert-advisory-request@cert.org *추천*
CERT 도구 mailto:cert-tools-request@cert.org
ftp://cert.org/pub/cert_advisories
다른 유럽 팀들: 다음 절 참조.
호주 CERT http://www.auscert.org.au/ [최신정보가 빠르다.]

CIAC mailto:ciac-listproc@llnl.gov subject=
"subscribe CIAC-ANNOUNCE Boran, Sean MY_PHONE_NR"
"subscribe CIAC-NOTES Boran, Sean MY_PHONE_NR"
"subscribe SPI-ANNOUNCE Boran, Sean MY_PHONE_NR"
"subscribe SPI -NOTES Boran, Sean MY_PHONE_NR"

보안 전반:

Risks forum mailto:risks-request@csl.sri.com
Best of Security (bos) mailto:majordomo@suburbia.net
보안 메일링 리스트 (local copy)
SANS 네트웍 보안 요약 Network Security Digest  mailto:sans@clark.net
     body='subscribe Network Security Digest your name'

뉴스그룹 보안일반 news://comp.security.misc
                    기술의 해악 Evils of technology news://comp.risks
                    보안 공시 Security Announcements news://comp.security.announce

ftp://ftp.switch.ch/mirror/security [스위스의 괜찮은 것들]
http://coast.cs.purdue.edu/homes/spaf/spafs_hotlist.html [Spafford 의 링크 색인: 아주 좋음]
http://www.tezcat.com/web/security/security_http.html [수많은 네트웍/유닉스 페이지들에 대한 색인]

http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html [WWW 서버 보안]
http://www.primus.com/staff/paulp/cgi-security [깨진 링크] [WWW cgi 스크립트 보안]
http://hoohoo.ncsa.uiuc.edu/cgi/security.html [위와 같음]
IIS 보안 설정 support.microsoft.com/support/kb/articles/Q229/6/94.asp

벤더 연락처 / 패치 소스:

유닉스 보안 mailto:security@cpd.com [확인 안됨]

Sun:
Sun "고객 경고 시스템 Customer Warning System" 보안 경고 mailto:security-alert@sun.com , subject="subscribe CWS myname@my.company.domain", Tel. +1 415 688-9081
Sun sysadmin mailto:sun-managers-request@eecs.nwu.edu
           body="add myname@my.domain"
보안 공시 sunsolve.sun.com/sunsolve/secbulletins
Sun & 자바 보안   www.sun.com/security/index.html    
Solaris 뉴스그룹 news://comp.unix.solaris     java.Sun.com/security
패치
   공개  sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
   패치 sunsolve.sun.ch/pub-cgi/us/secbul.pl  
   스위스 sunsolve.sun.ch   Contract patches sunsolve.sun.ch/private-cgi/us/patchpage.pl    
   패치 다운로드 도구 WGET sunsite.auc.dk/ftp/pub/infosystems/wget/
   PatchDiag 도구 sunsolve.sun.ch/sunsolve/patchdiag

Sun용 컴파일된 프리웨어   www.sunfreeware.com
Solaris 가이드 색인:  www.solarisguide.com
Sunworld sunwhere index of resources www.sunworld.com/sunworldonline/sunwhere.html
Jean Chouanard의 Solaris 강화 패키지 ftp://ftp.parc.xerox.com/pub/jean/solins/solins.html
Jens Vockler의 Solaris TCP/IP 스택 튜닝을 위한 스크립트 (성능, 보안에 뛰어나고 ndd를 배우는 데 좋음) http://www.rvs.uni-hannover.de/people/voeckler/tune/EN/tune.html.

HP:
Hewlett Packard mailto:security-alert@hp.com
HP 보안 리스트 mailto:support@support.mayfield.hp.com body="subscribe security_info"
HP-UX sysadmin mailto:majordome@cv.ruu.nl body="subscribe hpux-admin"
HP-UX 뉴스그룹 news://comp.sys.hp.hpux

DEC:
mailto:rich.boren@cxo.mts.dec.com , Tel. +1 719 592-4689
OSF/1 sysadmin mailto:majordomo@ornl.gov body="subscribe alpha-osf-managers"
http://www.service.digital.com/html/patch_service.html

BSDI sysadmin bsdi-users-request@bsdi.com
SCO: security-alert@sco.com
Santa Cruz Operation ftp://ftp.sco.com/SLS
Linux: 리눅스 비상대응팀:
http://bach.cis.temple.edu/linux/linux-security/Linux-Alerts/
www.redhat.com www.suse.com
OpenBSD: www.openbsd.org

SGI/IRIX:
이메일 mailto:security-alert@sgi.com , Tel. +1 800 800-4SGI
패치: SGI의 보안 권고문 및 패치는 ftp://sgigate.sgi.com 나 미러사이트 ftp.sgi.com 의 디렉토리 Security or Patches 에서 ftp 로 구할 수 있다.

위 패치와 관련된 이슈는, mailto:cse-security-alert@csd.sgi.com을 참조. 새로운 이슈는, mailto:security-alert@sgi.com 로 이메일.

뉴스그룹 뉴스://comp.sys.sgi.bugs (IRIX bugs).

IBM/AIX:
http://www.ers.ibm.com/tech-info
mailto:nrt@watson.ibm.com , Tel. +1 800 237-5511
ftp://software.watson.ibm.com/pub/aix3 [몇몇 AIX 보안 패치]
http://service.software.ibm.com/pbin-usa/fixdist.pl
http://service.software.ibm.com/aixsupport
http://www.ibm.com/security [보안 제품 & 서비스]

Microsoft/Windows NT:
NT 보안 이슈 mailto:request-ntsecurity@iss.net
NTBugtraq mailto:listserv@listserv.ntbugtraq.com body= "SUB NTBUGTRAQ Your Name"
www.securityfocus.com
ISS의 NT 보안   mailto:request-ntsecurity@iss.net body="subscribe ntsecurity"
NT, Explorer 보안 www.ntsecurity.net              *recommended*
Microsoft 보안 mailto:security@microsoft.com       www.microsoft.com/security
www.somarsoft.com/contents.htm [NT 보안]
www.iea.com/~daler/nt/faq/toc.html [NT 자주 묻는 질문들]

Cisco
www.cisco.com/warp/public/707/advisory.html
기사 다양한 라우터 패스워드 메카니즘 & 취약점 설명

방화벽:

방화벽 Firewalls mailto:majordomo@greatcircle.com "subscribe firewalls"
요약도 있음.

보안 해킹 (완전 공개) 그룹:

8lgm(8 Little Green Men): mailto:majordomo@8lgm.org body="subscribe 8lgm"    www.8lgm.org
Avalon mailto:mcpheea@cadvision.com

Bug track discussion list mailto:bugtraq-request@fc.net
http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html

컴퓨터 언더그라운드:

다음을 언더그라운드 사이트 에 대한 링크 목록 견본으로, 이를 보면 인터넷 해커들이 어떤 생각을 하고 어떤 정보로부터 시작할지에 대한 생각이 들 것이다.

www.insecure.org    다른 것보다도 nmap의 홈
www.nessus.org      흥미로운 스캐너
www.rootshell.com  도구 모음
www.l0pht.com  NT 패스워드 크래킹 & NFR 플러그인

www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html alt.2600/#hack FAQ intro.
scitsc.wlv.ac.uk/~cs6171/hack/index.html Unix /net /hack page
scitsc.wlv.ac.uk/~cs6171/phrack/phrackindex.html Phrack
mailto:phrack@well.sf.ca.us Phrack
www.unix.geek.net/~arny Unix /net /hack page 미국 미러사이트
www.paranoia.com/~coldfire/index.html Cold Fire's Web Page
www.2600.com  2600 Magazine
www-personal.engin.umich.edu/~jgotts/underground.html The Internet Underground
bush.cs.tamu.edu/~erich/alt.cp.faq.html alt.cyberpunk FAQ 목록
mailto:tk0jut2@mvs.cso.niu.edu Computer Underground Digest
www.wiretrip.net/rfp/2/index.asp Rain.Forest.Puppy

www.dbnet.ece.ntua.gr/~george/security/ Hawk의 보안 링크
www.hideaway.net/security_links.html Hideaway.Net - 보안 링크
www.secure.cybercomm.nl/index2.html 안전한 사이버통신

기타:

www.scit.wlv.ac.uk/rfc/index.html                    HTML 형식의 RFCs
www.technotronic.com/tcpudp.html                  tcp, udp 및 서비스 목록 설명
www.isi.edu/in-notes/iana/assignments/port-numbers   IANA 포트번호 목록
www-arc.com/sara   SARA - satan 같은 스캐너
www.wwdsi.com/saint SAINT 스캐너
www.nessus.org NESSUS 스캐너
www.SecuriTeam.com 별로 안좋다.

tycho.usno.navy.mil The Official Source of Time for the Department of Defense and the Standard of Time for the United States

21.2 보안 조직

21.2.1 FIRST (Forum of Incident Response and Security Teams)

FIRST는 사고 예방, 사고에 대한 신속한 대응을 위한 협력을 조장하고 회원들 및 광범위한 공동체간의 정보공유를 목적으로 하는 국제 조직들 (정부 & 민간 분야 모두) 의 연합이다. 더 자세한 사항은 이들의 WWW 페이지에서 찾거나 www.first.org 이메일 mailto:first-sec@first.org로 연락하면 된다. 일반적으로 사용자들은, FIRST 가 전세계 보안관리자를 위한 메일링 리스트를 운영하게 하기보다는, 가장 가까운 FIRST 에 연락하고 이들의 메일링리스트에 가입해야 한다!

FIRST 는 30개가 넘는 회원수를 가진다 (1995년 11월 기준). 가장 영향력있는 회원들은 (저자의 소견으로) CERT, AUSCERT, DFN-CERT, CIAC 이다. 이 그룹들은 다음 절들에서 훨씬 상세하게 설명된다.

대부분의 FIRST 회원들은 PGP를 써서 이메일에 서명하고 패치 파일의 무결성 검사에 MD5 를 사용하므로, 이들 두 유틸리티를 가지고 있을 것을 권고한다.

21.2.1.1 CERT

CERT 는, 인터넷 웜 사건동안 보여진 필요성에 부응하여 미 국방 고등연구 프로젝트 기관 (US Defence Advanced Research Projects Agency, DARPA) 에 의해 1988년 11월 만들어진 컴퓨터 비상 대응팀 (Computer Emergency Response Team) 이다. CERT 설립취지는 인터넷 공동체와 협력하여 인터넷 호스트 관련 컴퓨터 보안 사건 대응을 촉진하고, 공동체의 컴퓨터 보안 인식을 높이기 위한 순향적 (proactive) 조치를 취하고, 기존 시스템들의 보안 개선을 목표로 하는 연구를 수행하는 것이다.

Computer Emergency Response Team (CERT)
mailto:cert@cert.org (통신은 DES 나 PGP 로 암호화 할 것을 권장)
Tel. +1 412 268-7090

CERT 권고문은 주로 유닉스& VMS 관리자들에게 흥미있는 것들이지만, NT도 있고, 윈도우나 Mac은 거의 없다 (아래 CIAC 참조).
CERT 는 1988년 웹 페이지를 전면 개편했으며, 지나간 CERT 권고문을 HTML 형식으로 구할 수 있고, 또 많은 것들이 있다 www.cert.org. 이 범위까지는 이 절이 조금 중복된다 (1999).

ftp://ftp.cert.org/pub/cert_advisories/ [색인은 01-README 파일에]
ftp://ftp.cert.org/pub/cert_summaries/
ftp://ftp.cert.org/pub/cert_bulletins/
ftp://ftp.cert.org/pub/tech_tips/packet_filtering
ftp://ftp.cert.org/pub/tech_tips/UNIX_configuration_guidelines
ftp://info.cert.org/pub/tools/
ftp://info.cert.org/pub/tech_tips/security_tools
ftp://info.cert.org/pub/incident_reporting_form
ftp://info.cert.org/pub/whois_how_to
ftp://info.cert.org/pub/FIRST/first-contacts

An 인터넷 상의 보안 사고 분석 1989-1995

아래는 완전한 권고문 목록이다:

• 1991년에서 1995년 사이의 15-20개로부터 1996년 권고문긔 숫자가 27로 늘어났다. 1997은 아마 훨씬 더 활동적일 것이다.
• Sendmail 은 항상 그래왔듯이 문제다.
• 대부분의 유닉스 벤더들이 무제를 가지고 있으며, 한둘에 국한된 것이 아니다.
• 대부분의 문제들은 버퍼 초과와 더렵혀진 환경변수 사용에 기인한다.
• 알려진 취약점들을 이용하는 자동화된 공격 도구들이 인터넷에서 무료로 입수가능하다. 공격을 시작하는데 더이상 기교있는 해커가 필요하지 않다.

벤더 공시:

Cert 요약:

21.2.1.2 유럽 비상대응팀

SIRCE (유럽 전체)

유럽 전반의 시험적 대응팀은 1997에 시작한다. 시험 프로젝트는 최대 30 개월간 지속될 것이고, 그 이후에는 SIRCE (Security Incident Response Co-ordination for Europe) 가 영구적으로 운영될 것이다. 시험프로젝트는 UKERNA-DANTE 에 의해 실현될 예정이다.. UKERNA 는 영국의 국립 연구소 네트워킹 조직이고 DANTE는 유럽의 네트웍 연구 비영리 조직이다.

SWITCH-CERT (스위스)

스위스의 Swiss Academic and Research Network CERT 는 스위스 시스템 관리자들을 위한 보안정보의 중심지를 제공한다. SWITCH-CERT 는 FIRST 회원 및 특정 해킹 그룹들로부터의 모든 권고문들에 대해 회원들에게 정보를 알린다. 스위스의 관리자들은 SWITCH-CERT 메일링 리스트 가입을 적극 추천한다. Contact cert-staff@switch.ch.

DFN-CERT (독일)

German Federal Networks CERT 는 독일의 보안 activity들을 정리한다. Email dfncert@cert.dfn.de , tel. +49 040 5494-2262.

Italy: cert-it@dsi.unimi.it
네덜란드: cert-nl@surfnet.nl
잉글랜드: cert@ja.net

21.2.1.3 AUSCERT

Australian CERT 는 지리적으로 떨어져 있지만, 때때로 새로운 보안 문제나 그들의 솔루션 또는 작업에 대해 권고할 때 가장 빠르다.

http://www.auscert.org.au/information/advisories.html 도 참조한다.
Email: auscert@auscert.org
Tel: +61 7 3365 4417

21.2.1.4 NASIRC (NASA 대응팀)

NASA 팀은 NASA 사용자들에게만 지원을 제공하지만, 발견된 취약점들을 FIRST 회원들에게 발표한다.

http://nasirc.nasa.gov
ftp://nasirc.nasa.gov
Tel. +1 800 762-7472

21.2.1.5 CIAC (미국 에너지성 [Department of Energy, DOE] 대응팀) ('96 년 6월)

CIAC (Computer Incident Advisory Capability)은 미 에너지성 (DOE)과 미 국립 보건원 (National Institute for Health, NIH) 을 위한 컴퓨터 보안 대응팀이다. CIAC는 FIRST의 창단멤버이다.

Tel. +1 510 422-8193
Email: ciac@llnl.gov

이전 CIAC 공지, 안티바이러스 소프트웨어 및 기타 정보들을 http://ciac.llnl.gov 또는 ftp://ciac.llnl.gov 에서 구할 수 있다 . 네 개의 셀프 가입 메일링 리스트들이 있지만 (아래 참조), 가장 가까운 FIRST 에서 CIAC의 모든 권고문을 이송해주므로 CIAC에 직접 가입할 필요는 거의 없다.

ciac-listproc@llnl.gov 로 본문에 다음 중 하나 (또는 그 이상)의 행을 포함시켜 이메일을 보낸다:
subscribe CIAC-ANNOUNCE MYNAME, MYFORENAME MY_PHONE_NR
subscribe CIAC-NOTES MYNAME, MYFORENAME MY_PHONE_NR
subscribe SPI-ANNOUNCE MYNAME, MYFORENAME MY_PHONE_NR
subscribe SPI -NOTES MYNAME, MYFORENAME MY_PHONE_NR

CIAC 은 다음 형태로 정보를 제공한다:

1. Tools: 도스, 유닉스 & 매킨토시용 다양한 도구들을 다운로드할 수 있다.
2. Notes: 현재 보안 문제점들을 상세히 설명하는 정기 보고서가 나온다. 1996년 6월에는 Notes 1, 2, 94-03a, 94-04c, 94-05d, 95-06 에서 95-12 그리고 96-01 을 구할 수 있었다.
3. Bulletins: 이 문서들을 특정한 문제점들을 강조한다. 현재 (95년 12월 20일) CIAC Bulletins 목록은 그룹 A-G로 나뉘어, A 는 1989 그리고 G 1995/96이다 (개략적으로):

21.2.2 프랑스 조직 (TBD)

Clusis (TBD)

21.2.3 미 조직 / 기관

NSA (National Security Agency, 국가 안보국)
NSA 는 TCSEC과 관련 Rainbow books를 개발했다. 이들은 국방성 (DOD)의 일원으로서, 강력한 정보조직으로 더 잘 알려져 있다.

NIST (National Institute of Standards and Technology, 국립 표준기술연구소)
NIST 는 Rainbow books 와 기타 다른 보안 소책자들을 배포한다. 이들은 NSA와 매우 긴밀하게 일한다 (NSA의 일부분인가?)
TBD: 최소 보안 기능적 요구사항 Minimum Security Functional Requirement (MSFR)

NIST, Computer Security Labs,
Gaithersburg, Maryland 20899, USA
Tel. 301-975-2000

NCSC (National Computer Security Center, 국립 컴퓨터 보안 센터)
NSA의 일원으로, TCSEC 표준에 따라 IT 제품들을 평가한다. Rainbow books 의 원래 출판자들이다.

NCSC
9800 Savage Road, Fort Meade, Maryland 20755,
Tel. 301-859-4371

NCSA (National Computer Security Association, 국립 컴퓨터 보안 협회)
(정부 후원의) NCSA 는 교육, 컨퍼런스, 뉴스레터 등 다양한 IT 서비스를 제공하고 바이러스 사건들을 꽤 긴밀하게 추적하는 독립 조직이다. 이들은 최근 방화벽과 인터넷 사이트 인증을 시작했다. NCSA 는 또한 워싱턴에서 보안 관련 이슈들의 통과운동(lobby)을 하기도 한다.
미국 외 회사들에 대한 연간 회원비는 $175- 정도 한다.
이들의 "정보전" 컨퍼런스가 괜찮다.

NSCA 10 S. Courthouse Ave.,
Carlisle, Pennsylvania 17013, USA
Tel. 717-258-1816

COAST (Computer Operations, Audit and Security Technology)
Purdue 대학에 있는 COAST 는 보안 연구의 중심지이다.
http://www.coast.cs.purdue.edu.

21.3 인터넷 해킹 그룹

이 그룹들은 발견된 보안홀들에 대해 상세 정보를 만들어 낸다. 어떤 경우에는, 그 홀을 이용할 수 있는 예제 코드들도 발표된다. CERT 에서 이들 그룹이 발표한 권고문들을 발표하는데 6개월정도 걸릴 ?가 많으므로, 보안이 자신에게 높은 중요성을 띠고 있다면 이들의 메일링 리스트에 가입하도록 한다.

8lgm (8 Little Green Men / 8 Legged Groove Machine)
이 이메일 리스트에 가입하려면 (추천), body="subscribe 8lgm" 으로 하여 majordomo@8lgm.org로 이메일을 보낸다. http://www.8lgm.org 도 참조한다. 다음음 WWW 사이트에 언급된 사항이다:

[8LGM] 은 시스템 관리자들이 자신의 시스템들을 고칠 수 있게 하기 위해, 이 정보들을 선의로 제공한다. 하지만 [8LGM] 은 어떤 목적으로든 이 정보의 사용을 지지하지는 않는다.

권고문 목록 (1997년 2월):

ASR (Avalon Security Research)
최근 ('95년 11월) 스스로를 "Avalon Security Research" 라고 부르는 새로운 그룹이 보안 홀과 이용방법 에 대한 기사들을 인터넷에 올리기 시작했다. ASR 해킹 그룹은 자기들이 발견해낸 보안 홀들의 정보를 발표한다. 이들은 자기들을 다음과 같이 설명한다:

ASR 은 아무렇게나 조직된 비영리 그룹이다. 우리는 지금까지 약 4년간 단속적으로 함께 일해왔다. 최근 우리는 우리의 연구를 발표하기로 결정했다. 이 결정은 수많은 요인에 근거한 것이었다. 우선 우리는 컴퓨터 보안이 이제는 아마 어느때보다도 거대한 인터넷 공동체의 가장 중요한 협동이라는 것을 깨달았다. 실정이 이러하므로 우리는 모든 카드가 테이블 위에 놓여져야 한다고 생각한다. 우리에게 이것은 완전한 공개적 태도에 대한 강력한 지지를 뜻한다.... 그리고 exploits만 아니라 다양한 특성의 보안 감사 도구들을 발표할 계획도...

메일링리스트에 가입하려면, mcphee@cadvision.com 에게 메일을 보낸다.
아래는 96년 2월 12일 발표된 버그와 활용 스크립트 목록이다.

• Nov.'95: UNIX: Use of rpc.nfsd to chmod any directory on the system.
  => Fix/workaround: none available.
• Dec.'95: splitvt() bug. Root access may be gained easily by normal users.
  => Fix/workaround: See CIAC advisory G-08.
• 1996.1: rpc.nfsd bug found on Linux & SunOS. Root access may be gained easily.
  => Fix/workaround: It is not needed. Remove pr_start() function or fix the binary (a script is available from facq@u-bordeaux.fr).

21.4 보안 표준

이 절은 좀 오래되고, 대부분이 온라인으로 구할 수 있기 때문에 덜 유용하다 (처음 시작할 때는 1996년도가 아니었다). 관련 표준들의 최신 Acrobat 사본은 www.itsec.gov.uk 을 한번 보기 바란다.

21.4.1 미국 표준: The Rainbow Books (로컬 목록)

Rainbow books 는 표지 색깔로 유명한 IT 보안 문서 시리즈이다. 가장 잘 알려진 것은 TCSEC 즉 Orange Book 이다 (다음 절 참조). 다음은 이 책들과 색깔, DoD 참조 번호 및 제목에 대한 목록이다. 완전한 목록을 만들려고 애썼지만, 한 두 권의 책이 빠졌을 수 있다. 목록의 처음 세 책들이 제일 괜찮다.

Orange Book DoD 5200.28-STD DoD TCSEC (Trusted Computer System Evaluation Criteria)
신뢰되는 컴퓨터 시스템 평가 기준 Green Book CSC-STD-002-85 Department of Defense Password Management Guideline
국방성 패스워드 관리지침
Yellow Book CSC-STD-003-85 Computer Security Requirements -- Guidance for Applying TCSEC in Specific Environments
컴퓨터 보안 요구사항 -- 특정 환경에서 TCSEC 적용에 대한 가이드

Yellow Book CSC-STD-004-85 Technical Rationale Behind the above document.
위 문서들에 대한 기술적 정당성
Tan Book NCSC-TG-001 A Guide to Understanding Audit in Trusted Systems
신뢰되는 시스템들에서 감사의 이해에 대한 안내서
Bright Blue Book NCSC-TG-002 Trusted Product Evaluation - A Guide for Vendors
신뢰되는 제품 평가 - 벤더를 위한 안내서
Light Blue Book NCSC-TG-002-85 PC Security Considerations
PC 보안 고려사항
Neon Orange Book NCSC-TG-003 Understanding Discretionary Access Control in Trusted Systems
신뢰되는 시스템에서 임의적 접근통제에 대한 이해
Teal Green Book NCSC-TG-004 Glossary of Computer Security Terms
컴퓨터 보안 용어 해설
Red Book NCSC-TG-005 Trusted Network Interpretation of the TCSEC
TCSEC의 신뢰되는 네트웍 해석
Orange Book NCSC-TG-006 Understanding Configuration Management in Trusted Systems
신뢰되는 시스템에서 구성관리 이해
Burgundy Book NCSC-TG-007 Understanding Design Documentation in Trusted Systems
신뢰되는 시스템에서 설계문서화에 대한 이해
Dark Lavender Book NCSC-TG-008 Understanding Trusted Distribution in Trusted Systems
신뢰되는 시스템에서 신뢰되는 분산에 대한 이해
Venice Blue Book NCSC-TG-009 Computer Security Subsystem Interpretation of the TCSEC
TCSEC의 컴퓨터 보안 서브시스템 해석
Aqua Book NCSC-TG-010 Understanding Security Modelling in Trusted Systems
신뢰되는 시스템에서 보안 모델링 이해
Dark Red Book NCSC-TG-011 Trusted Network Interpretation Environments Guideline - Guidance for Applying the Trusted Network Interpretation
신뢰되는 네트웍 해석 환경 지침 - 신뢰되는 네트웍 해석의 적용에 대한 안내서
Pink Book NCSC-TG-013 Rating Maintenance Phase -- Program Document
평가등급 유지 단계 -- 프로그램 문서화
Purple Book NCSC-TG-014 Guidelines for Formal Verification Systems
공식 검증 시스템을 위한 지침
Brown Book NCSC-TG-015 Understanding Trusted Facility Management
신뢰되는 설비관리 이해
Yellow-Green Book NCSC-TG-016 Guidelines for Writing Trusted Facility Manuals
신뢰되는 설비 매뉴얼 작성을 위한 지침
Light Blue NCSC-TG-017 Understanding Identification and Authentication in Trusted Systems
신뢰되는 시스템에서의 식별과 인증에 대한 이해
Light Blue Book NCSC-TG-018 A Guide to Understanding Object Reuse in Trusted Systems
신뢰되는 시스템에서 객체 재사용의 이해에 대한 가이드
Blue Book NCSC-TG-019 Trusted Product Evaluation Questionnaire
신뢰되는 제품 평가 질의서
Gray Book NCSC-TG-020A Trusted Unix Working Group (TRUSIX) Rationale for Selecting
신뢰되는 유닉스 작업 그룹의 선정근거

Access Control List Features for the Unix System
유닉스 시스템을 위한 접근통제목록 기능
Lavender Book NCSC-TG-021 Trusted Data Base Management System Interpretation of TCSEC
TCSEC의 신뢰되는 데이타베이스 관리 시스템 해석
Yellow Book NCSC-TG-022 A Guide to Understanding Trusted Recovery in Trusted Systems
신뢰되는 시스템에서 신뢰되는 복구의 이해에 대한 가이드
Bright Orange Book NCSC-TG-023 Understanding Security Testing and Test Documentation in Trusted Systems
신뢰되는 시스템에서 보안 테스팅과 테스트 문서 이해
Purple Book NCSC-TG-024 (Volume 1/4) A Guide to Procurement of Trusted Systems: An Introduction to Procurement Initiators on Computer Security Requirements
신뢰되는 시스템 구매 가이드: 구매 발기인들을 위한 컴퓨터 보안요구사항 소개
Purple Book NCSC-TG-024 (Volume 2/4) A Guide to Procurement of Trusted Systems: Language for RFP Specifications and Statements of Work - An Aid to Procurement initiators.
신뢰되는 시스템 구매 가이드: RFP 사양과 작업 보고서를 위한 언어 - 구매 발기인들을 위한 도움
Purple Book NCSC-TG-024 (Volume 3/4) A Guide to Procurement of Trusted Systems: Computer Security Contract Data Requirements List and Data Item Description Tutorial
신뢰되는 시스템 구매 가이드: 컴퓨터 보안 계약 데이타 요구사항 목록 및 데이타 항목 설명 지도서
Purple Book NCSC-TG-024 (Volume 4/4) A Guide to Procurement of Trusted Systems: How to Evaluate a Bidder's Proposal Document - An Aid to Procurement Initiators and Contractors
신뢰되는 시스템 구매 가이드: 입찰자의 제안서 평가 방법 - 구매 발기인과 계약자들을 위한 도움
Green Book NCSC-TG-025 Understanding Data Remanence in Automated Information Systems
자동화된 정보시스템에서의 잔류 데이타 이해
Hot Peach Book NCSC-TG-026 Writing the Security Features User's Guide for Trusted Systems
신뢰되는 시스템을 위한 보안 기능 사용자 설명서 작성하기
Turquoise Book NCSC-TG-027 A Guide to Understanding Information System Security Officer Responsibilities for Automated Information Systems
자동화된 정보시스템에 대한 정보시스템 보안 책임자의 의무에 대한 이해를 위한 가이드
Violet Book NCSC-TG-028 Assessing Controlled Access Protection
통제된 접근 보호 평가하기
Blue Book NCSC-TG-029 Introduction to Certification and Accreditation
보증과 인가/신임장에 대한 소개
Light Pink Book NCSC-TG-030 A Guide to Understanding Covert Channel Analysis of Trusted Systems
신뢰되는 시스템의 비밀채널 분석 이해를 위한 가이드

21.4.2 The TCSEC "Orange Book" (로컬 사본, 또는 UK ITSEC) 참조

21.4.2.1 도입

1983년, 미 국방성 (DoD)은 (사실은 국립 컴퓨터 보안 센터 National Computer Security Centre[1]), TCSEC 즉 오렌지북의 첫번째 버전을 발표하였다 (오렌지색 표지를 따라서 명명된). 1985 년 더 한층 갱신되어 표준으로 발행되었다 (DOD5200.28-STD). 오렌지북은 컴퓨터 시스템들의 보안을 평가하기 위한 지침을 규정한다. 기타 다른 많은 관련 표준들도 작성되어, "레인보우 시리즈" 로 알려져 있다.

• 시스템은 4개의 계층적 그룹 A, B (B1, B2, B3), C (C1, C2), D 로 나뉜다. 등급 A 시스템들이 가장 안전하고 등급 D 시스템들은 다른 어떤 등급들의 기준도 만족하지 못하는 것들이다.
• 각 등급을 위한 요구사항들은 다음 범주로 나뉜다: 보안 정책, 표시(marking), 식병, 책임추적성 (accountability), 보증(assurance) 및 계속적 보호
• C와 B 등급 시스템들간의 주된 차이점은 접근통제 영역에 있다. C2에서는, 누가 자기 객체에 접근할 수 있고, 어느 정도까지 할 수 있는지를 객체 소유주가 결정한다 (이것은 DAC - 임의적 접근통제 Discretionary Access Control 알려져 있다). B 에서는, 객체들이 소유주에 상관없이 보안 등급을 가지고 있다 - 그래서 사용자가 "비밀" 로 표시된 객체의 사본을 받으면, 사용자는 이 객체의 등급을 변경하거나 "비밀" 객체에 접근할 수 있게 명시되지 않은 다른이들에게 줄 수 없다 (이것은 MAC - 강제적 접근통제 Mandatory Access Control 으로 알려져 있다). B 등급 시스템들은 MAC을 구현하기 위해 "데이타 라벨링"이 필요하다.
• NSA 가 시스템을 평가하고 (가령) C2 등급을 부여했다면, 평가제품목록 Evaluated Products List (EPL) 에 오르게 된다. 시스템은 어떤 조건 하에서 어떤 레벨로 평가되는데, 그 조건이 실제로 보통의 일상적인 시스템 사용을 반영하는 것은 아니다.
• C2 등급의 상용시스템은 드물지 않으며, B등급 시스템은 드물고 주로 군 분야에서 쓰인다.
• TCSEC의 핵심 개념은 TCB(Trusted Computing Base, 신뢰되는 컴퓨터 기반)의 사상이다. TCB는 다음을 제공해야 한다: TCB에 대한 방해로부터의 보호, 주소공간 분리, 신뢰되는 경로, 최소특권(least-privilege)의 원칙, 운영의 연속성.
• TCSEC에 따라 평가된 상용 운영체제 요약을 "운영체제 개론" 장에서 찾아볼 수 있다.
  

21.4.2.2 Contacts

Infosec Awareness Office [문서 주문]
+1 (410) 766-8729

Government Printing Office [정보보호 시스템 & 보안 카탈로그 주문]
+1 (202) 512-1800

Evaluations Office
+1 (410) 859-4458

다음은 C1과 C2에 관해 오렌지북에서 직접 발췌해온 것이다:

21.4.2.3 2.0 DIVISION C: DISCRETIONARY PROTECTION

이 부문에 있는 등급들은 임의적 (알아야할 필요,need-to-know) 보호를 제공하며, 감사 능력을 포함하고 있어, 주체 및 이들이 시작한 조작들에 대한 책임추적성을 제공한다.

등급 (C1): 임의적 보안 보호 DISCRETIONARY SECURITY PROTECTION
등급 (C1) 시스템의 Trusted Computing Base (TCB) 는 사용자와 데이타의 분리를 제공함으로써 명목상으로 임의적 보안 요구사항을 만족시킨다. 이것은 개인별로 접근 제한을 둘 수 있는 어떤 형태의 믿을만한 통제를 포함한다, 즉 표면상으로 사용자들이 프로젝트나 개인 정보를 보호하고, 다른 사용자들이 우연히 자기 데이타를 읽거나 파괴하지 못하도록 할 수 있게 하는데 적당하다. 등급 (C1) 환경은 동일한 민감성 수준의 데이타를 처리하는 협력 사용자들로 예상된다. 다음은 등급 (C1)에 할당된 시스템들에 대한 최소 요구사항이다:

2.1.1 보안 정책
2.1.1.1 임의적 접근통제: TCB 는 ADP 시스템의 지정된 사용자들과 지정된 객체들(즉 파일 및 프로그램들) 간의 접근을 정의하고 통제해야 한다. 적용 메카니즘은 사용자들이, 그러한 객체들의 공유를 지정된 개인이나 정의된 그룹 또는 둘다에 따라 규정하고 통제할 수 있도록 해주어야 한다.
2.1.2 책임추적성 Accountability
2.1.2.1 식별과 인증: TCB는 사용자에게, TCB의 중재를 받도록 되어 있는 다른 어떤 조작의 수행을 시작하기 전에, 사용자를 TCB에게 식별시킬 것을 요구해야 한다. 더 나아가, TCB는 보호되는 메카니즘을 사용하여 (e.g., 패스워드) 사용자의 신원을 인증해야 한다. TCB는 인증 데이타를 보호하여 어떠한 비인가 사용자에 의해서도 접근되지 않도록 해야 한다.
2.1.3 보증
2.1.3.1 기능상의 보증
2.1.3.1.1 시스템 구조: TCB는 외부의 간섭이나 참견(e.g., 코드나 데이타구조 변경에 의한) 으로부터 TCB를 보호하는, 자신을 위한 도메인을 유지해야 한다. TCB에 의해 통제되는 자원들은 ADP 시스템내의 주체 및 객체들의 정의된 서브셋일 수 있다.
2.1.3.1.2 시스템 무결성: TCB의 현장 하드웨어 및 펌웨어 요소들의 올바른 동작을 주기적으로 확증하는 데 쓸 수 있는 하드웨어 및/또는 소프트웨어 기능들이 제공되어야 한다.
2.1.3.2 라이프 사이클 보증
2.1.3.2.1보안 테스팅: ADP 시스템의 보안 메카니즘은 테스트되어 시스템 문서에서 주장하는 대로 동작하는 것이 확인되어야 한다. 테스팅은 비인가 사용자가 TCB의 보안 보호 메카니즘을 우회하거나 이길수 있는 명백한 방법이 없다는 것을 확실히 하도록 수행되어야 한다 (보안 테스팅 지침 참조).
2.1.4 문서
2.1.4.1 보안 기능 사용자 가이드: 사용자 문서 중 하나의 요약, 장, 또는 매뉴얼은 TCB 에서 제공하는 보호 메카니즘들, 이들의 사용에 대한 지침, 그리고 이들이 서로 어떻게 상호작용하는지를 설명해야 한다.
2.1.4.2 신뢰되는 설비 매뉴얼: ADP 시스템 관리자를 위한 매뉴얼은 안전한 설비를 운영할 때 통제되어야 할 기능 및 특권에 대한 주의사항을 표시해야 한다.
2.1.4.3 테스트 문서: 시스템 개발자는 보안 메카니즘이 어떻게 테스트되었는지와 보안 메카니즘의 기능적 테스팅 결과를 보여주는 테스트 계획과 테스트 절차를 서술하는 문서를 평가자에게 제공해야 한다.
2.1.4.4 설계문서: 제작자의 보호에 대한 방침(철학)과 이 방침이 TCB로 어떻게 변환되었는지에 대해 설명하는 문서가 있어야 한다. TCB가 별개의 모듈들로 이루어져 있다면, 이 모듈들간의 인터페이스가 서술되어야 한다.

CLASS (C2):CONTROLLED ACCESS PROTECTION
이 등급에 있는 시스템들은, 로그인 절차, 보안관련 이벤트 감사, 그리고 자원 고립을 통해 사용자들이 개별적으로 자기 행위에 대해 책임이 있게 하여, (C1) 시스템들보다 세밀한 임의적 접근 통제를 제공한다. 다음은 등급 (C2)를 부여받은 시스템들에 대한 최소 요구사항이다:

2.2.1 보안 정책
2.2.1.1 임의적 접근통제:TCB 는 ADP 시스템의 지정된 사용자들과 지정된 객체들(즉 파일 및 프로그램들) 간의 접근을 정의하고 통제해야 한다. 적용 메카니즘은 사용자들이, 그러한 객체들의 공유를 지정된 개인이나 정의된 그룹 또는 둘다에 따라 규정하고 통제할 수 있도록 해주어야 하고, 접근권한의 전달, 보급을 제한할 수 있는 통제를 제공해야 한다. 임의적 접근 통제 메카니즘은, 명백한 사용자 행위에 의해서나 디?트에 의해, 객체를 비인가 접근으로부터 보호해야 한다. 이런 접근통제들은 단일 사용자 단위에 대해서까지 접근에 포함시키거나 배제시킬 수 있어야 한다. 아직 접근허가를 가지고 있지 않은 사용자에 대한 객체 접근 허가는 인가된 사용자에 의해서만 부여되어야 한다.
2.2.1.2 객체 재사용: 저장 객체에 포함된 정보에 대한 모든 인가는 TCB의 비사용 저장객체 풀로부터 주체에게 초기 부여, 할당 또는 재할당되기 전에 철회되어야 한다. 이전 주체의 조작에 의해 만들어진, 암호화된 정보를 포함한 어떠한 정보도, 시스템으로 다시 해제되었던 객체로의 접근을 얻는 어떤 주체에 의해서도 이용될 수 있어서는 안된다.
2.2.2 책임추적성
2.2.2.1 식별과 인증: TCB는 사용자에게, TCB의 중재를 받도록 되어 있는 다른 어떤 조작의 수행을 시작하기 전에, 사용자를 TCB에게 식별시킬 것을 요구해야 한다. 더 나아가, TCB는 보호되는 메카니즘을 사용하여 (e.g., 패스워드) 사용자의 신원을 인증해야 한다. TCB는 인증 데이타를 보호하여 어떠한 비인가 사용자에 의해서도 접근되지 않도록 해야 한다. TCB는 각 개별 ADP 시스템 사용자를 유일하게 식별할 수 있는 능력을 제공함으로써 개인별 책임추적성을 적용해야 한다. TCB는 또한 이 신원과 그 개인에 의한 모든 감사가능한 조작들을 연관시킬 수 있는 능력을 제공해야 한다.
2.2.2.2 감사: TCB는 자기가 보호하는 객체들에 대한 접근의 감사증적을 생성, 유지, 그리고 변조나 비인가접근 또는 파괴로부터 보호할 수 있어야 한다. 감사 데이타는 이에 대한 읽기 접근이 감사 데이타에 대한 인가를 받은 사람들로만 제한될 수 있도록 TCB에 의해 보호되어야 한다.
TCB 는 다음 유형의 이벤트들을 기록할 수 있어야 한다: 식별 및 인증 메카니즘의 사용, 사용자의 주소 공간에 객체를 도입 (e.g., 파일열기, initiation), 객체의 삭제, 그리고 컴퓨터 운영자와 시스템 관리자 및/또는 시스템 보안 책임자들에 의한 조작(행위), 그리고 기타 보안 관련 이벤트들.
기록되는 각 이벤트에 대해, 감사 기록은 다음을 식별해야 한다: 이벤트의 날짜시간, 사용자, 이벤트 유형, 그리고 이벤트의 성공/실패여부.
식별/인증 이벤트들에 대해서는 요청의 발원지 (e.g., 단말 ID)가 감사 기록에 포함되어야 한다. 사용자의 주소 공간에 객체를 도입하는 이벤트 및 객체 삭제 이벤트에 대해 감사기록은 객체이름을 포함해야 한다. ADP 시스템 관리자는 개별 신원에 근거하여 어느 사용자든 하나 또는 그 이상의 사용자 조작(행위)을 선택적으로 감사할 수 있어야 한다.
2.2.3 보증
2.2.3.1 기능상의 보증
2.2.3.1.1 시스템 구조: TCB는 외부의 간섭이나 참견(e.g., 코드나 데이타구조 변경에 의한) 으로부터 TCB를 보호하는, 자신을 위한 도메인을 유지해야 한다. TCB에 의해 통제되는 자원들은 ADP 시스템내의 주체 및 객체들의 정의된 서브셋일 수 있다. TCB는 보호되어야 할 자원들을 격리시켜 이들이 접근통제와 감사 요구사항에 종속되도록 해야 한다.
2.2.3.1.2 시스템 무결성: TCB의 현장 하드웨어 및 펌웨어 요소들의 올바른 동작을 주기적으로 확증하는 데 쓸 수 있는 하드웨어 및/또는 소프트웨어 기능들이 제공되어야 한다.
2.2.3.2 라이프 사이클 보증
2.2.3.2.1 보안 테스팅: ADP 시스템의 보안 메카니즘은 테스트되어 시스템 문서에서 주장하는 대로 동작하는 것이 확인되어야 한다. 테스팅은 비인가 사용자가 TCB의 보안 보호 메카니즘을 우회하거나 이길수 있는 명백한 방법이 없다는 것을 확실히 하도록 수행되어야 한다. 테스팅은 또한 자원 격리를 위반하도록 할 수 있거나, 감사 또는 인증 데이타에 대한 비인가 접근을 허용할 수 있는 명백한 결함을 찾는 일도 포함해야 한다 (보안 테스팅 지침 참조).
2.2.4 문서
2.2.4.1 보안 기능 사용자 가이드: 사용자 문서 중 하나의 요약, 장, 또는 매뉴얼은 TCB 에서 제공하는 보호 메카니즘들, 이들의 사용에 대한 지침, 그리고 이들이 서로 어떻게 상호작용하는지를 설명해야 한다.
2.2.4.2 신뢰되는 설비 매뉴얼: ADP 시스템 관리자를 위한 매뉴얼은 안전한 설비를 운영할 때 통제되어야 할 기능 및 특권에 대한 주의사항을 표시해야 한다. 감사 파일을 검사하고 유지하기 위한 절차와 감사 이벤트 각각의 유형에 대한 상세 감사 레코드 구조가 주어져야 한다.
2.2.4.3 테스트 문서: 시스템 개발자는 보안 메카니즘이 어떻게 테스트되었는지와 보안 메카니즘의 기능적 테스팅 결과를 보여주는 테스트 계획과 테스트 절차를 서술하는 문서를 평가자에게 제공해야 한다.
2.2.4.4 설계문서: 제작자의 보호에 대한 방침(철학)과 이 방침이 TCB로 어떻게 변환되었는지에 대해 설명하는 문서가 있어야 한다. TCB가 별개의 모듈들로 이루어져 있다면, 이 모듈들간의 인터페이스가 서술되어야 한다.

21.4.3 The ITSEC - "European Orange Book"(로컬 사본, 또는 UK ITSEC 참조)

21.4.3.1 개론

ITSEC (Information Technology Security Evaluation Criteria) 은 프랑스, 독일, 네덜란드, 영국에서 만든 조화된 평가기준의 집합이다. 이것은 1995년 4월 EU (유럽 공동체) 에의해 모든 회원국들을 위한 표준으로 채택되었다. ITSEC에 따라 평가된 상용 운영체제에 대한 요약을 "운영체제 개론" 장에서 찾아볼 수 있다. ITSEM [itsem] 은 ITSEC을 사용하는 데 대한 안내서이다 - 다음 절에서 서술한다.

제품이나 시스템 (여기서부터는 TOE 라고 한다 : target of Evaluation 평가대상) 이 ITSEC에 따라 평가될 때:

• 보안명세는 (보안 목표 라고 함) Sponsor (보증책임자?)에 의해 정의된다. 이는 보안 목적(objectives, TOE가 달성하고자 하는 보안에 대한 기여), 위협, 보안 적용 기능, 그리고 보안 메카니즘을 정의한다. 보안 목표(target)도 역시 예제 기능성 등급의 하나가 될 수 있다.
• TOE 는 보안 목표에 대해 평가된다. 보증 (Assurance)은 TOE가 제공하는 보안의 레벨에 대한 신용이다. 이것은 유효성 (TOE가 공격이나 사고에 견딜 수 있고 관리자/사용자가 아는 상태에서 TOE가 안전하지 않게 구성될 것 같지 않음) 과 정확성 (보안을 적용하는 기능이 구현되었는가?) 으로 규정된다.
  • 유효성 기준: Construction (적합성/기능의 묶음, 메카니즘의 강도, 구조 취약성 평가) 및 Operation (사용의 용이성, 운영/기능상 취약성 평가).
  • 정확성 기준: Construction (개발 프로세스/환경) 및 operation (운영 문서/환경).
• 결과물은 "보증 보고서 Certification Report" 와 "평가 기술보고서 Evaluation Technical Report" 이다.
  ITSEC은 보안 기능성과 보증을 분리한다. 보증레벨은 E1에서 E6 까지 있다. 보증 레벨이 높을수록, 기재된 보안 기능성이 정확하게 서술된대로 동작하며 공격에 견딘다는 것을 더 확신할 수 있다.

ITSEC 은 TCSEC 등급에 대응되는 기능성 등급 표본 F-C1, C2, B1, B2, B3 를 정의하고, 네트워킹을 포함하고 있어 관심을 끄는 IN, AV, DI, DC 및 DX 의 새로운 등급을 정의한다. 이 등급들은 표준 보안 기능의 집합을 서술한다. ITSEC 과 TCSEC은 아래와 같이 대응된다:

ITSEC TCSEC
E1, F-C1 == C1
E2, F-C2 == C2
E3, F-B1 == B1
E4, F-B2 == B2
E5, F-B3 == B3
E6, F-B3 == A1

ITSEC 은 TCSEC 에 추가하여 다음의 기능성 등급들을 정의한다:

IN 이 등급은 데이타 & 프로그램에 대한 높은 무결성이 요구되는 시스템을 위한 것이다.
AV 이 등급은 높은 가용성 기능을 가지는 시스템을 위한 것이다.
DI 이 등급은 데이타 전송에 대해 높은 무결성이 요구되는 시스템을 위한 것이다.
DC 이 등급은 데이타 전송에 대해 높은 기밀성이 요구되는 시스템을 위한 것이다.
DX 이 등급은 데이타 전송에 대해 높은 무결성 & 기밀성이 요구되는 시스템을 위한 것이다.

ITSEC 은 다음 표제들 아래 요구사항이 분석될 것을 제안한다: 책임추적성 Accountability, 식별 및 인증 Identification & Authentication, 감사 Audit, 객체 재사용 Object Reuse, 접근통제 Access Control, 정확성 Accuracy, 데이타 교환 Data Exchange 및 서비스 신뢰성 Reliability of Service. 메카니즘이나 대응책의 강도는 기본 basic, 중간 medium 또는 높음 high 으로 규정된다.

간략히 하기 위해 여기에는 TCSEC에 없는 새로운 리뷰 기준이 포함된 등급 F-DX 만 설명한다.

21.4.3.2 ITSEC 도입부분으로부터의 발췌

다음 ITSEC의 대대적인 국제 버전 1.2가, 발행일로부터 2년의 잠정기간동안 평가 및 인가 계획에서의 사용에 대해 (비공식) EC 자문그룹인 SOG-IS (Senior Officials Group - Information Systems Security) 의 승인을 얻어 발행되었다. 습득된 실제 경험은 이 기간의 종반에 ITSEC을 재검토하고 더 심도있게 개발하는데 이용될 것이다. 덧붙여, 한층 더한 국제적 조화로부터 나올 고려사항들도 염두에 둘 것이다.

0.1 겨우 40년을 지나오는 동안, 정보기술(IT)은 조직사회의 거의 모든 부분에서 중요하고, 또 대개 필수적인, 역할을 수행하게 되었다. 결과적으로, 보안은 정보기술의 필수적인 측면이 되었다.

0.2 이런 상황에서, IT 보안이 의미하는 것은,
- 기밀설 - 정보의 인가되지 않은 공개 방지;
- 무결성 - 정보의 인가되지 않은 변조 방지;
- 가용성 - 정보나 자원에 대한 인가되지 않은 제지를 방지.
0.3 IT시스템이나 제품은 기밀성, 무결성, 그리고 가용성 유지를 위한 각자의 요구사항을 가지고 있을 것이다. 이 요구사항들을 만족하려면, 예를 들어 접근통제, 감사, 그리고 에러 복구같은 분야를 담당하는 수많은 기술적 보안 수단 (이 문서에서 지칭하는 바에 의하면 보안 적용 기능) 을 구현해야한다. 이 기능들에 대해 알맞은 신뢰가 필요하다: 이 문서에서 이것은 보증이라는 말로 칭한다, 그것이 보안적용 기능의 정확성에 대한 신뢰이건 (개발과 운영적 관점 모두에서) 또는 그런 기능들의 유효성에 대한 신뢰이건.
0.4 시스템의 사용자들은 자기들이 사용하고 있는 시스템의 보안에 대한 확신이 필요하다. 이들은 또한 구매를 생각중인 IT 제품들의 보안 능력들을 비교할 척도가 필요하다. 사용자들이 문제의 시스템 및 제품들의 제조업자나 벤더의 말에 의존할 수도 있겠지만, 또는 스스로 테스트를 해볼 수도 있겠지만, 많은 사용자들은 독립적인 단체에 의한 어떤 형태의 공정한 평가를 선호할 것 같다. 시스템이나 제품에 대한 그런 평가는 객관적이고 잘 정의된 보안 평가 기준 및 평가가 적절하게 수행되었음을 입증하는 보증체의 존재를 필요로 한다. 시스템 보안 목표는 문제의 시스템을 사용하는 사람의 개별적인 필요성에 특정할 것이고, 반면 제품 보안 목표는, 이를 만족하는 제품이, 비슷하지만 꼭 동일하지는 않은 보안 요구사항을 가지는 많은 시스템들에 통합될 수 있도록, 보다 일반적일 것이다.
0.5 시스템에 대해서, 이의 보안 능력에 대한 평가는, 개개의 환경안에서 사용을 위해 IT 시스템을 받아들이는 것에 대한 보다 공식적인 절차의 일부로 볼 수 있다. 인정 Accreditation 이라는 말이 종종 이 절차를 기술하는 데 쓰인다. 시스템이 의도하는 목적에 맞는 것으로 보일 수 있기 위해서는 여러가지 고려할 요소들이 필요하다: 시스템이 제공하는 보안에 대한 보증, 보안에 대한 경영진의 책임에 대한 확인, 관련 기술 및 법/규범 요구사항 준수, 그리고 시스템 환경내에 제공되는 다른 비기술적 보안방책들의 적합성에 대한 확신이 필요하다. 이 문서에 포함된 기준들은 주로 기술적인 보안방책과 관계가 있지만, 인사, 물리적 및 절차적 보안을 위한 안전한 운영 절차와 같은 일부 비기술적 측면들도 다룬다 (그러나 이들이 기술적 보안방책들에 닿을 때만).
0.6 IT 보안 평가 기준 개발에 대해 많은 작업이 이전에 있었다, 비록 관련 국가나 단체들의 특정한 요구사항에 따라 약간 다른 목적들을 가지고 있지만. 이들 중 가장 중요한 것은, 그리고 여러가지 면에서 다른 개발들에 대한 선구자는, Trusted Computer System Evaluation Criteria [TCSEC] 이었으며, 통상적으로 TCSEC 또는 "오렌지북" 으로 알려져 있고, 미 국방성에서 출판하고 제품 평가에 이용된다. 다른나라들도, 대부분 유럽 국가들인데, IT 보안 평가에 상당한 경험을 가지고 있고 자체적인 IT 보안 기준을 개발했다. 영국에서는 정부용으로 개발된 CESG Memorandum Number 3 [CESG3], 상용 IT 보안 제품을 위한 통상산업부 제안 "Green Book" [DTIEC]이 여기 포함된다. 독일에서는 독일 정보 보안국에서 1989년 자체 기준 초판을 발행하였으며[ZSIEC], 같은 시기에 프랑스에서도 기준이 개발되고 있었는데, 소위 "Blue-White-Red Book"이다 [SCSSI].
0.7 이 분야에서 작업이 진행되고, 아직도 해야할 것들이 많이 남아 있는 것을 보고, 프랑스, 독일, 네덜란드 그리고 영국에서는 이 작업이 협력적인 방향으로 접근되어야 하고, 공통되고 조화된 IT 보안기준이 나와야 한다는 것을 인지했다.
조화시키는 데에는 세 가지 이유가 있다:
a) 여러 나라에서 많은 경험들이 모아졌고, 그 경험을 바탕으로 함께 구축함으로써 얻을 수 있는 것이 많았다;
b) 업계에서는 서로 다른 나라들에서 서로 다른 보안 기준을 원하지 않았다;
c) 나라들 간에, 그리고 민간, 정부 및 방위 응용에서조차도 기본 개념과 접근법은 동일했다.
0.8 따라서 여러 나라들의 선도를 바탕으로 구축하여, 이미 시행되었던 특징들을 취해 이들이 일관되고 체계적으로 균형을 이루도록 하기로 결정되었다. 기존 작업, 가장 중요하게는 미국 TCSEC, 과의 최대의 적응성과 호환성이 이 프로세스에서 부단한 고려사항이었다. 비록 처음에는 이 작업이 기존 기준들을 조화시키는 데 그칠 것이라고 생각되었으나, 때때로 이미 존재하는 것을 확장하는 것이 필요할 때가 있었다.

21.4.3.3 Contacts

EU Commission of the European Communities
Directorate XII/F SOG-IS Secretariat
Rue De la Loi 200
B-1049 Brussels, Belgium

Germany Bundesamt f? Sicherheit in der Informatik
Am Nippenkreuz 19, D-5300 Bonn
+49-228-9582.111 General Number
+49-228-9582.129 Certification information
+49-228-9582.141 Documentation

Netherlands Netherlands National Comsec Agency
Bezuidenhoutseweg 67
P.O. Box 200061, NL-2500 EB The Hague

France Service Central de la S?urit?des Syst?es d'Information
Division Information et Syst?es
18 Rue du Docteur Zamenhof, F-92131 Issy les Moulineaux

UK Head of the Certification Body
UK IT Security Evaluation and Certification Scheme
P.O. Box 152, Cheltenham, GB-GL52 5UF
+41-1242-238739 ext. 5103
cbsec@itsec.gov.uk
http://www.itsec.gov.uk

21.4.3.4 표본 기능성 등급 F-DX

목적
A.100 표본 기능성 등급 F-DX 는 교환될 정보의 기밀성과 무결성에 대한 요구가 높은 네트웍을 위한 것이다. 예를 들면, 민감한 정보가 안전하지 않은 네트웍을 통해 (에를들면 공중망) 교환되어야 하는 경우가 될 수 있다.

식별과 인증
A.101 TOE는 사용자를 유일하게 식별하고 인증해야 한다. 이 식별과 인증은 TOE와 사용자간의 다른 모든 상호작용에 앞서 일어나야 한다. 다른 상호작용들은 성공적인 식별과 인증 이후에만 가능해야 한다. 인증정보는 인가된 사용자에 의한 리뷰나 변경을 위해서만 접근될 수 있는 방법으로 저장되어야 한다. 모든 상호작용에 대해 TOE는 사용자의 신원을 입증할 수 있어야 한다.

A.102 사용자 데이타를 교환하기 전에 통신 상대 개체 (컴퓨터, 프로세스 또는 사용자) 는 유일하게 식별 및 인증되어야 한다. 사용자 데이타는 식별 및 인증이 성공적으로 완수된 이후에만 교환되어야 한다. 데이타를 받으면 데이타의 발신자를 유일하게 식별하고 인증할 수 있어야 한다. 모든 인증정보는 비인가 접근과 위조로부터 보호되어야 한다.

책임추적성
A.103 TOE는 다음 각 이벤트들에 대해 필요한 데이타와 함께 이벤트를 로그할 수 있는, 책임(추적성) 요소를 포함하고 있어야 한다:
a) 식별 및 인증 메카니즘의 사용:
필요한 데이타: 날짜; 시간; 식별 및 인증의 개시자; 식별될 주체의 이름; 행위의 성공 또는 실패 여부.
b) 데이타 교환에서 식별된 에러:
필요한 데이타: 날짜; 시간; 데이타 교환에서 통신 당사자들; 에러 유형; 시도된 교정의 성공이나 실패여부.
c) 연결 설정:
필요한 데이타: 날짜; 시간; 개시자의 사용자 신원; 통신 상대 개체 이름(컴퓨터, 프로세스 또는 사용자); 설정 파라미터 (달라진다면).
d) 특수한 데이타 교환 트랜잭션:
필요한 데이타: 날짜; 시간; 송신자의 사용자 신원; 수신자의 사용자 신원; 통신된 사용자 정보; 데이타 수신 날짜 및 시간.
A.104 비인가 사용자는 책임 데이타에 접근이 허용되지 말아야 한다. 하나 또는 그 이상 사용자의 행위에 대해 선택적으로 책임을 기록할 수 있어야 한다. 책임 파일들을 검사하고 유지하는 도구가 있어야 하고 문서화되어야 한다. 이 도구들은 하나 또는 그 이상 사용자의 행위들이 선택적으로 식별될 수 있도록 해주어야 한다. 책임 기록의 구조가 완벽하게 서술되어야 한다.

감사
A.105 감사 목적으로 책임 파일을 검사할 도구들이 존재하고 문서화 되어야 한다. 이 도구들은 하나 또는 그 이상 사용자의 행위가 선택적으로 식별될 수 있도록 해주어야 한다.

데이타 교환

접근 통제
A.106 인가받지 않은 해독에 이용될수 있는 이전에 전송된 모든 정보는, 직무를 수행하기 위해 절대적으로 이 데이타에 접근할 수 있어야 하는 사람만 접근할 수 있게 보호되어야 한다.

데이타 기밀성
A.107 TOE는 통신채널의 넓은 부분에 걸친 수신자에 대해 기밀성을 보장하는 종단간(end-to-end) 암호화의 수단을 제공해야 한다. 아울러, 지정된 데이타 통신 링크에 대한 트래픽 흐름 기밀성도 보장되어야 한다.

데이타 무결성
A.108 TOE는 사용자 데이타와 책임 데이타의 비인가 조작과 데이타의 비인가 재생이 확실히 에러로 판명되도록 설계되어야 한다.

21.4.4 ITSEM (발췌) (로컬 사본, 또는 UK ITSEC 참조)

..........

0.1 장 소개
0.1.5 IT 보안 평가 매뉴얼 (IT Security Evaluation Manual, ITSEM) 은 ITSEC 버전 1.2 를 바탕으로 하여, 평가 대상(TOE)이 이 기준에 따라 어떻게 평가되어야 하는지를 서술한다. ITSEM의 명시된 목적은 ITSEC을 보완하는 조화된 평가 방법 세트가 존재하도록 하기 위한 것이다.

0.1.6 ITSEM 은 기술적인 문서로, 주로 평가 파트너들 (일차적으로 평가자이지만 발기자와 보증자도) 을 겨냥한 것이지만, 벤더나 개발자, 시스템 인정자와 사용자들에게도 관심의 대상이다. 여기에는 평가 방법들에 대한 충분한 세부사항과 다양한 환경에서 수행되는 평가의 기술적 등가치를 입증할 수 있게 하는 절차들이 포함되어 있다. 문서는 무료로 얻을 수 있다. ITSEM은 민간과 정부 분야에서 수행되는 평가 모두에 적용된다.
..........
0.1 장 소개
자산, 위협, 위험, 신뢰 및 대응책
0.1.1 정보기술(IT)은 효과적인 사업 및 국가업무 수행에 필수적인 것이 되었고, IT 사용의 영향을 받는 개인들의 사무에서도 점점 중요해지고 있다. 정보는 어떤 사람의 업무나 사무를 진척시키기 위해 얻어지고 보호되어야 하는 어떤 것이며, 따라서 자산으로 간주되어야 한다. 그러한 자산의 중요성은 보통 위협의 징후로부터 파생되어 결과로서 일어나는 손해로 표현된다. 손해는 정보의 폭로, 부적절한 변조, 파괴 또는 오용에 의해 직접적으로나 간접적으로 야기될 수 있다. 위험은 예상되는 손해와 나타나는 위협의 가능성의 크기에 따라 증가한다.
0.1.2 IT 시스템에서 정보는 자산에 나쁜 영향을 미치는 위협으로부터 보호되어야 한다. 위협은 고의적이거나 (e.g. 공격) 의도되지 않을 것일 수 있다 (e.g. 실수나 고장).
0.1.3 위험을 줄이기 위해, 특정한 대응책이 선정될 것이다. 이 대응책들은 특성상 물리적, 인사적, 절차적 또는 기술적일 수 있다. 기술적 대응책 또는 IT 대응책 은 IT 시스템의 보안 적용 기능과 메카니즘이다; 비 기술적 대응책 또는 비 IT 대응책 은 물리적, 인사적, 그리고 절차적 대응책들이다. ITSEC 평가는 주로 기술적 대응책과 관계된다.
0.1.4 IT 시스템의 일차 보안 목표는 연관된 위험을 관련 조직이 수용할 수 있는 수준으로 줄이는 것이다. 이것은 IT 시스템의 보안 기능 및 특징들에 의해 달성될 수 있다.
0.1.5 IT 시스템이 제공하는 보안에 대해 적용될 신뢰를 보증이라고 말한다. 보증이 클수록, 시스템이 잔존위험을 수용가능한 수준으로 유지하며 위협으로부터 자산을 보호할 것이라는데 대한 확신(신뢰)도 커진다.
0.1.6 ITSEC 평가 등급이 높고 메카니즘의 강도가 강할수록, 사용자는 IT 시스템이나 제품에 내재된 대응책에 대해 더 큰 확신을 가질 수 있다. 사용자에게 필요한 평가 등급은 알려진 잔존위험의 수용가능한 수준에 달려 있으며 구체적인 개별 상황에 대한 위협 및 위험 분석에 의해서만 결정될 수 있다. 보안과 비용은 균형을 이루어야 한다. 평가등급이 높아짐에 따라 개발 및 평가 비용이 증가할 가능성이 많으므로, 더 높은 평가 등급 제품이나 시스템은 대개 더 비쌀 것이다. 예를들어 환경 파라미터의 함수로 평가등급을 결정하는 방법에 대한 안내가 [GISA2]에 주어져 있다. ITSEM 2부에 언급된 국가 조직들로부터 특정한 조언을 구할 수도 있다.

..........
보안 평가
6.4.11 완벽하게 안전한 실제 IT 시스템을 만드는 것은 불가능하다. 이것은 IT 시스템의 복잡성과, 대응해야 하는 위협의 다양성 때문이다.
6.4.12 그러나, 컴퓨터 시스템의 보안에 대한 어느정도의 확신을 제공하는 것은 가능하다. 선호되는 접근법은 독립적 기관이 (IT 보안 평가 기관, ITSEF 이라고 불림) 시스템 설계와 문서화를 상세히 검사하여 보안 취약점을 찾는 것이다. 시스템이 이용될 수 있는 보안 취약점을 가지고 있지 않은 것으로 판명되면, 시스템은 평가를 통과하게 된다; 아니면 실패한다.
6.4.13 시스템이 보안 평가를 통과하면, 이는 어느 정도의 보안을 제공할 법 하지만, 다음과 같은 이유들 때문에 완전히 안전하다고 할 수는 없다:
a) 평가자가 얻을 수 있는 정보의 수준때문에, 평가자가 발견하지 못한 취약점이 존재할 수 있다;
b) 시스템이 안전하지 못하게 사용, 운영, 관리 또는 구성될 수 있다;
c) 그 환경에서의 어떤 위협들이 보안 목표에 포함되지 않았을 수 있다.
6.4.14 따라서, 평가된 시스템은 조직의 보안을 유지하는데 하나의 역할을 담당하는 것으로 보아야 하지만, 보안에 대한 모든 책임을 지는 것은 아니다. 모든 유형의 사용자들이 여전히 담당할 부분이 있다.
..........

21.4.5 TTAP

다음은 FIST WWW 페이지로부터 발췌한 것이다:

TTAP (신뢰기술 평가 프로그램 Trust Technology Assessment Program) 는 상용 기성제품 (COTS)에 대한 신뢰 등급을 상용화하기 위한 국가 안보국(NSA) 과 국립 표준기술 연구소(NIST)의 합작품이다. National Voluntary Laboratory Accreditation Program (NVLAP) 의 후원아래, TTAP 는 상용 평가 기관을 설립, 승인, 감독할 것이며, 초기에는 TCSEC B1및 그 이하 신뢰 수준의 기능과 보증을 가지는 제품들에 초점을 맞춘다.

최초의 TTAP 워크샵은 1996년 봄에 있을 것이다. 사용자가 "보안 등급"에 따라 운영체제를 선택할 수 있게 하기 위해 TTAP가 어떤 일을 할 지 지켜보는 일이 흥미로웅 것이다.

21.4.6 Common Criteria 1.0 (옛날 V1 로컬 사본, 또는 보다 새로운 V2는 UK ITSEC참조)

다음 설명은 NIST ( http://csrl.ncsl.nist.gov/nistpubs/cc ) 로부터 가져온 것이다:

1985 년 미국은 TCSEC (Trusted Computer Security Evaluation Criteria 또는 Orange book) 이라는 보안 평가 기준 세트를 만들었다. 이러한 기준은 특정한 보안 기능성을 필요로 하며 정의된 특정 환경 세트에 적합한 몇개의 등급을 제공하였다 (C1, C2, B1, B2, B3, A1). 이 TCSEC 이후, 유럽국가들이 ITSEC (IT Security Evaluation Criteria)을 만들고, 캐나다는 CTCPEC을, 그리고 마지막으로 미국에서 연방 기준을 만들었다. 이 기준들이 서로 호환되지 않으므로, 이 모든 기준들을 Common Criteria (또는 단순히 CC)라는 새로운 하나의 보안 평가 기준 세트로 조화시키기로 결정되었다.

Common Criteria 의 주된 목적은 모든 IT 보안 제품들에 대해 사용될 수 있는 보안 평가 기준 세트를 제공하자는 것이다. 동시에 이것은 제품에 대해 바랄 수 있는, 가능한 보안 요구사항들의 멋지고 간략한 세트를 제공한다.
Common Criteria 는 아직 완성되지 않았다. 현재는 Common Criteria for Information Technology Security (CC) version 1.0, January 31, 1996 이 대중 리뷰와 의견 수렴중이다. 리뷰와 시험 평가에 따라 CC는 계속 정해지지 않을 수 있다. 목표는 ISO가 Common Criteria 를 국제 표준으로 받아들이는 것이며, 이미 ISO에 제출하였다.
ISO/IEC/JTC1/SC27/WG3 "Evaluation Criteria for IT Security" 는 전세계적인 표준 기준을 1998까지 만들 목표를 가지고 있다.

각주:
[1] 확실히 NCSC 는 웹이 있지만 시스템을 평가하는 NSA 부문은 없다?have now a Web presence, but not the NSA division which evaluates systems.

                 Previous     Next      Top   Detailed TOC      Last Update: 16 Jun 2000