어제에 이은 포스팅입니다.
너무 길어서 세 번에 나눠 기제합니다.
Lessons Learned from Five Years of Building More Secure Software
Written by Michael Howard
5년 동안 더 안전한 소프트웨어를 구축하면서 얻은 교훈
The software industry, or more accurately the software quality industry, is fixated on getting the code right. I really don’t have a problem with that, but many security vulnerabilities are not coding issues at all. Many are design issues.
소프트웨어 업계, 더 정확히 말해 소프트웨어 품질 업계는 올바른 코드를 작성하는 데 집중하고 있습니다. 필자는 이에 대해 이의는 없지만 상당수의 보안 취약점은 코딩과는 전혀 관계가 없습니다. 많은 보안 취약점의 원인은 설계 문제입니다.
이렇게 쉼표가 많은 문장도 ‘주어와 동사, 목적어’만 찾으면 쉬워진다.
주어는 ‘The software industry or ~industry,’이고 동사는 ‘is’, ‘fixated on’은 ‘~에 집착한’의 숙어다. ‘소프트웨어 업계는/~에 집착한다/~를 시키는데/코드/바르게’를 재배치하면 ‘소프트웨어 업계는 코드를 바르게 만드는 데 집착한다’이다.
여기서 숙어 ‘not ~ at all’은 ‘결코 ~가 아니다’라는 의미로 기억해 두자.
위협 모델링은 제품의 설계 취약점을 식별하고 완화하는 데 도움이 되는 분석 기술입니다. 공격 취약 영역 분석은 소프트웨어 제품에서 신뢰할 수 없는 사용자(로컬이든 원격이든)에게 노출되는 부분에 집중합니다. 공격 취약 영역이 넓은 제품은 좁은 제품에 비해 더 많은 코드가 신뢰할 수 없는 사용자에게 노출됩니다.
주어는 ‘Threat Modeling’이고 동사는 ‘is’, 그 이하는 주어와 동격인 ‘보어’다.
단, 보어 ‘an analysis technique’ 뒤의 ‘that’은 앞을 꾸며 주는 형용 사절이다. 형용사절은 ‘~하는’으로 해석한다.
‘위협 모델링/이다/분석기술/~하는/식별하다/완화하다/설계 취약점/제품 안의’를 재배치하면 ‘위협 모델링은 제품 안의 설계 취약점을 식별하고 완화하는 분석기술이다’가 된다.
The first priority is old code because old code is far more likely to have more security vulnerabilities than newer code. Threats are constantly evolving. Old code?even code built just a few years ago?was built when the threats were different than they are today. Furthermore, the techniques used to build old code lack the latest defensive techniques and best practices.
첫 번째 우선순위는 오래된 코드입니다. 오래된 코드는 최신 코드에 비해 보안 취약점이 더 많을 가능성이 훨씬 높기 때문입니다. 위협은 끊임없이 진화합니다. 오래된 코드(불과 몇 년 전에 작성된 코드까지 포함)는 현재와 다른 위협 상황에서 작성되었습니다. 또한 오래된 코드를 작성하는 데 사용된 기술에는 최신 방어 기법과 최적의 방법이 적용되어 있지 않습니다.
첫 문장에서는 ‘be likely to ~할 것 같은’과 ‘far more 훨씬 많은’만 기억하면 문제없다.
마지막 문장에서, 주어는 the techniques이고 여기처럼 동사가 여러 개 나온 경우에, 동사 하나는 명사를 꾸며주는 역할을 할 수 있다는 걸 염두에 두자.
즉, ‘used’와 ‘lack’ 중에 ‘used’가 앞서 나온 ‘techniques’를 꾸며 준다. ‘그 기술/사용했었던/작성하다/오래된 코드//부족하다/최신의 방어 기술/그리고/최적의 방법’을 재배치하되 동사 앞까지를 먼저 해석한다.
‘오래된 코드를 작성한 그 기술’이 주어 부분이고 ‘최신의 방어기술과 최적의 방법’이 부족하다’가 동사와 목적어 부분이 된다.
‘비활성화 시켜라/삭제하라/지원 중단하라’인데 명령어가 일의 순서대로 나열된 것이므로 의역하면 ‘비활성화 시킨 후 삭제하고 지원 중단을 하는 순서를 따르라’정도 되겠다.
In the past, I have been highly critical of tools. Actually, not of the tools themselves, but of the over-reliance some developers have on tools.
예전에 필자는 도구에 대해 상당히 비판적이었습니다. 정확히 말하자면 도구 자체가 아니라 일부 개발자들의 도구에 대한 지나친 의존에 대해서지요.
가끔 멋지고 간결한 문장을 만들기 위해 단어를 많이 생략한 탓에 이해하기 어려운 문장을 만나게 된다.
위의 경우가 그렇다. 원래 두 번째 문장은 다음과 같다.
(I have been highly critical) not of the tools themselves, but of the over-reliance (that) some developers have on tools.
Not A but B 문장으로 ‘A가 아니라 B다’라는 뜻이다.
즉, 나는 도구 자체(themselves)에 매우 비판적인 게 아니라 몇몇 개발자들이 개발 툴에 대해(on) 가지고 있는(여기까지가 that 절 이하 형용사절) 지나친 의존(over-reliance)에 대해 비판적이다.
필자가 말하는 도구란 정적 코드 분석, 이진 분석을 비롯해 보안 취약점을 발견하는 데 도움이 되는 것들입니다. 세월이 흐르면서 필자는 이러한 자세를 누그러뜨렸습니다.
If you have a lot of code?say, over a million lines?it becomes very hard to review all that code by hand. Tools are handy because they can analyze great swaths of code rapidly.
코드의 분량이 많다면, 예컨대 백만 줄 분량의 코드라면 모든 코드를 직접 검토하기란 매우 어려운 일입니다. 도구는 많은 양의 코드를 신속하게 분석할 수 있다는 측면에서 유용합니다.
● 영어 원문 페이지 : http://msdn2.microsoft.com/en-us/magazine/cc163310.aspx#S1
● 한글 원문 페이지 : http://msdn2.microsoft.com/ko-kr/magazine/cc163310.aspx
기영모 helenjoh1@dreamwiz.com｜기술과 영어를 공부하는 모임이다. 개발자와 마케터가 함께 모여 기술과 영어를 교환하여 공부하는 모임으로 현재 MSDN magazine과 그 때 그 때 관심 있는 영역의 아티클을 공부하고 있다.