보안 회사의 프로그래머는 무엇을합니까?

나는 클라이언트 시스템의 보안에 관해 상담하는 보안 회사에 대해 들었습니다. 이 분야에서 내가 아는 사람들은 모두 네트워크 엔지니어이지만 프로그래머도 보안에 관여한다는 것을 알고 있습니다. 감사 / 컨설팅을 수행하는 보안 프로그래머는 실제로 무엇을합니까? 그들은 문자 그대로 사람들의 레거시 시스템의 모든 취약점을 찾기 위해 코드베이스를 통과합니까? 나는 그것이 그들이 한 일이라고 항상 가정했지만, 이것이 신뢰할 수 없을 것 같고 거짓된 보안 감각을 제공하는 것 이상을 수행하지 않는 것 같습니다. 참고 : 암호화 알고리즘을 작성하는 프로그래머 나 소프트웨어 보안 감사 / 컨설팅 관련 전문가 만 말하는 것은 아닙니다.

솔직히 우리는 코드베이스를 거치지 않고 우리를 위해 도구를 작성하려고합니다.

첫째, 이론. 보안은 소프트웨어 시스템의 요구 사항이므로 다른 요구 사항 (기능, 유용성, 접근성, 성능 등)과 마찬가지로 요구 사항 수집에서 배포 및 유지 관리에 이르기까지 소프트웨어 엔지니어링 워크 플로의 모든 단계에서 고려해야합니다. 실제로 이것은 가능하며 소프트웨어 프로젝트 팀이이를 수행하는 데 도움이되는 지침이 존재합니다. 주로 iOS 개발자와 함께 일하지만 "보안 개발 수명주기"에 대해 제가 가장 좋아하는 설명은 Microsoft Press 입니다.

이 모델에서는 사용자의 요구 사항을 도출하려고 할 때 응용 프로그램 보안이 시작됩니다. 우리는 때문에 쉬운 일이 아닙니다 그들의 보안 및 개인 정보 보호 문제 발견해야 할 우리가 전문가가 아닌 사용자가, 그리고 그들의 보안 요구 사항을 이해하는 곳 그들은 하드를 표현하는 찾을 수 있습니다. 또한 배포시 소프트웨어에 노출 될 위험과 수용 가능한 위험 수준을 찾아야합니다.

우리는 이러한 요구 사항을 고려하여 응용 프로그램을 설계합니다. 우리는 이러한 요구 사항을 충족시키고 코드 수준 보안 실수와 관련된 추가 위험을 피하기 위해 코드를 작성합니다. 우리는 보안 모델이 실제로 구축 한 것과 일치하는지 확인하기 위해 소프트웨어를 테스트 한 다음 디자인 할 때 환경에 대한 가정과 일치하는 방식으로 소프트웨어를 배포합니다. 마지막으로, 우리는 사용자가 보안 요구 사항과 일치하는 방식으로 소프트웨어를 작동하고 제시된 위험의 새로운 변화에 대응할 수 있도록 지원 및 유지 관리를 제공합니다.

좋아, 이론적으로는 너무나. 에서 연습 에 (A 비 기술적 인 방식이기는하지만) 아주 잘 설명되어 이유로 Geekonomics 주로 방식의 소프트웨어 회사 동기들이 때문에, 위의 물건의 대부분이 발생하지 않습니다 있습니다. 대신, 우리는 이것을 얻습니다. 개발자는 :

• 계약을 입찰 할 때 보안 담당자 또는 갤러리를 고용하여 보안을 "제공"한다는 사실을 보여줍니다.
• 소프트웨어를 작성하십시오.
• 릴리스 전에 소프트웨어를 검증하기 위해 보안 담당자 또는 전문가를 고용하여 2 단계에서 발생한 많은 문제를 해결하십시오.
• 배포 후 다른 모든 것을 패치하십시오.

사람들이 실제로 하는 대부분의 앱 보안은 버그를 찾는 것입니다. 이것은 실제로 영광스러운 코드 검토이지만이 검토가 찾고있는 버그 종류의 전문가 인 사람들이 수행하는 매우 집중된 코드 검토이므로 여전히 외부 도움을 얻는 데 가치가 있습니다. 물론 그것은 일반적인 테팅 규칙입니다. 항상 다른 사람이 그 일을하는 데 관여하지 않은 사람을 시험하도록하십시오.

위의 내용을 사실로 받아들이면 구매 결정을 내리는 사람들이 "유능한 보안 담당자"와 "많은 버그 찾기"를 동일시 할 가능성이 높습니다. 컴퓨터를 사용하여 작업을 수행하는 사람은 그렇지 않은 사람보다 더 많은 버그를 발견하게되므로 물론 정적 분석 도구에 크게 의존하고 특정 클라이언트의 특정 문제에 대한 코딩보다 도구를 확장하는 데 더 많은 시간을 소비하는 것을 목표로합니다. 그런 다음 앱 보안 담당자가 코드를 읽는 것보다 코드를 읽는 도구를 작성할 가능성이 높다는 결론을 내립니다.

** 경고 : 남은 것은 개인적인 의견과 추측입니다 **

현실이 깨졌습니다. 소프트웨어 보안 이론은 소프트웨어 시스템에 의존하는 위험을 식별하고 이에 대응하는 것에 관한 것이지만 실습은 가능한 많은 버그를 찾는 것에 관한 것입니다. 물론, 이는 여전히 위험을 줄이지 만 부작용으로 만 사용됩니다. 게임의 점수는 게임의 "승리"보다 덜 중요해 졌으므로 규칙이 더 쉽게이기도록 변경되었습니다.

소프트웨어 개발자로서 무엇을 할 수 있습니까? 원래 규칙에 따라 게임을하십시오. 보안의 중요성을 이해하고 베지 수족을 훈련시키는 팀원 (바람직하게는 계약자가 아니라 실제로 팀원보다 빠른 결과보다는 장기적인 결과를 제공하도록 동기 부여)을 찾습니다. 그 사람에게 내 대답의 시작 부분에 설명 된 엔드 투 엔드 보안을 제공하도록 팀을 지시 할 책임을 부여하십시오.

또한 그 사람에게을 따라갈 권한을 부여하십시오 . 설계에 보안 요구 사항이 명시되어 있지 않으면 수정해야합니다. 구현이 보안 요구 사항을 충족하지 않으면 릴리스해서는 안됩니다 . 보안 담당자가 판결을 할 수는 있지만 판결에 따라 행동해야합니다. 나는 이것이 "OMFG 보안이 가장 중요한 것"이라고 말하는 보안 전문가처럼 들릴지 모른다는 것을 알고 있지만, 그것은 내가 의미하는 것은 아닙니다. 제품이 기능성, 유용성 또는 성능 요구 사항을 충족하지 않으면 해당 기능을 해제해서는 안됩니다.

왜 그렇게 하시겠습니까? 더 저렴해야한다 : 우리는 결함을 수정하면 나중에 결함이 더 비싸지는 Code Complete 테이블을 보았을 것이다. 보안 결함도 결함입니다. 나는 게임의 실제 규칙이며, 대부분은 유지 보수에서 수정 된 요구 사항의 문제입니다. 저거 싸요?

좋아, 이제 무엇을 할 수 나는 고용에 대한 보안 건 그 얘기처럼? 글쎄요, 수정 된 규칙에 따라 경기를 거부 할 수도 있습니다. 개발자에게 위험을 줄이는 것이 중요하며, 모든 단계에서 수행 할 수 있으며, 그렇게하는 데 도움을 줄 수 있습니다.

작고 매우 큰 응용 프로그램, 환경, 시스템 등에 대해 15 년 동안 보안 보증 프로그램을 실행 한 이후에는 모든 것이 있습니다. 내 팀에는 항상 하드 코어 코더 인 사람이 몇 명있었습니다.

세부 수준에서 일부는 매우 심도있는 코드 검토로 귀결됩니다. 예를 들어 현재 수백만 개의 라인 코드베이스에서 작업하여 가능한 문제를 좁히는 도구를 사용하여 각 코드를 검토하고 있습니다. 분류.

(그런 다음 문제가 위험을 야기하지 않는 이유를 수정하거나 설명하기 위해 개발자에게 전달합니다.)

그러나 이것은 리스크 프로파일이 이러한 종류의 자원 집약적 작업을 수행하는 데 적합한 구체적인 참여입니다.

훨씬 더 표준적이고 훨씬 더 비용 효율적인 것은 조직의 위험 프로파일을 이해하고 하향식 위험에 초점을 맞추는 것입니다.

• 위험 식욕-비즈니스에 미치는 영향, 위협 모델링
• 거버넌스-규제 준수,보고 등
• 정책-거버넌스 프레임 워크가 효과적인지 확인
• 프로세스-기술 및 인간
• 표준-각 보안 제어에 대한 정의
• 구현-방법

프로그래밍 측면은 실제로 코드 검토 및 사용자 지정 침투 테스트를 통해 마지막 두 가지에만 적용됩니다. 일부 조직의 경우, 예를 들어 이미 광범위한 피어 검토를 거친 계층화 된 보안 제어 (다양한 암호화 유형)를 구현 한 경우 구현을 확인할 수 있지만 일반적으로 모든 항목을 다시 확인하지는 않습니다. 이전에 수행 된 코드

설계 및 / 또는 완성 된 프로젝트에 대한 공격 / 프리츠 / 예외 테스트 스위트를 실행하는 동안 모호한 방식으로 아키텍처 / 모범 사례를 논의하는 것보다 훨씬 더 나아간 적이 없습니다.

거의 모든 경우에, 그들이 시도하는 공격 벡터가 어떤 도구를 사용하는지와 기존 시스템에서 감사 중 하나가 통과 한 후에 공격이 수행되는 방식을 알 수 있습니다.

실제로 코드를 검사하고 검토 / 화이트 박스 테스트를 수행하는 데 시간이 걸리는 사람이 몇 명 있다고 생각하지만 아직 실제 상황에서는 발생하지 않았습니다.