5 년 전 벨기에 은행은이 환상적인 TV 광고를 만들기 위해 함께 모여 꽤 구체적인 개인 및 금융 정보를 알고있는 매우 재능있는 천체 인 데이브의 이야기를 공유했습니다. 그것은 효과적으로 그들의 전체 인생을 온라인으로 찾을 수 있다는 사실에 대 한 소비자의 수백만 참여 하 고 모든 사람을 경계 하도록 격려.

비디오를 살펴보면 2012년보다 오늘날 훨씬 더 관련성이 높다는 것을 알게 될 것이며, 그 결과는 훨씬 더 무서운 결과를 알 수 있습니다.

사이버 보안 교육이 지루한 슬라이드쇼 교육, 억압적인 규칙 및 누군가가 항상 하지 말아야 할 것을 말하는 C-suite 및 직원에게 큰 골칫거리라고 생각한다면 이 비디오를 창의적인 영감을 얻을 수 있는 좋은 시기가 될 수 있습니다.

비디오를 시청하고, 인적 자원 및 커뮤니케이션 팀과 공유하고, 정보 보안을 다시 재미있게 만드는 데 도움을 요청하십시오!

사이버 보안 분야에서 C-suite를 교육하든 JAVA 또는 C# 보안 코딩 기술을 개발자에게 도움을 주든 창의성, 게임화 및 재미를 위한 장소가 있습니다.

사이버 보안 분야에서 C-suite를 교육하든 JAVA 또는 C# 보안 코딩 기술을 개발자에게 도움을 주든 창의성, 게임화 및 재미를 위한 장소가 있습니다.

개발자가 JavaScript에서 코딩할 때 사이트 간 스크립팅 오류를 작성하고 해당 결함을 생성한 지 몇 분 이내에 이를 감지할 수 있는 경우 수정하는 데 몇 분 또는 몇 초밖에 필요하지 않을 수 있습니다.

2주 후에 수동 테스터가 결함이 발견되면 결함 추적 시스템에 입력될 것입니다. 그것은 분류 될 것입니다. 다른 사람의 버그 대기열에 넣을 것입니다.

신원 확인이 지연되면 원래 컨텍스트에서 조사해야 하며 개발 속도가 느려질 것입니다. 지금, 당신은 잠재적으로 같은 결함을 해결하기 위해 시간의 시간을 이야기하고있습니다. 10배 또는 100배 더 많은 시간이 걸린다.

나는 크리스 와이소팔 (CTO, 베라 코드)에 동의 할 수 없었다 오라일리 보안 팟 캐스트와 그의 최근 팟 캐스트에서 그는 왜 왼쪽으로 보안을 이동하는 이유를 설명 (개발 라이프 사이클의 시작에 개발자에게) 속도와 속도를 유지하기 위해 민첩한 환경에서 핵심입니다.

IDE 플러그인, 스캐너를 사용하고 기본 보안 기술(위생)을 갖도록 교육함으로써 개발자가 쉽게 보안을 강화해야 합니다. 조직은 모든 변경 사항을 검증하는 보안 전문가 또는 중앙 집중화 보안 팀에만 의존해서는 안 됩니다.

우리의 전형적인 보안 modus operandi깨진 (전문가에 전화!) 우리는 민첩한 체질을 유지하면서 품질을 유지하기 위해 개발 팀에 보안을 통합해야합니다.

https://www.oreilly.com/ideas/chris-wysopal-on-a-shared-responsibility-model-for-developers-and-defenders

나는 보고 기쁘다 Secure Code Warrior 긍정적인 보강 및 게임 기반 요소를 사용하여 회사 내에서 행동의 변화를 제공하는 방법에 대한 유일한 생각은 아닙니다.

WSJ의 이 기사는 사이버 보안 인식이 더 효과적이며 교육이 끔찍하지 않거나 지루하거나 반복적이거나 쓸모가 없을 때 직원에게 더 큰 영향을 미친다고 강조했습니다. 과거에는 사이버 보안 교육은 일반적으로 기술적이고 심층적인 자료를 제공했지만 직원과 붙어있는 핵심 메시지를 전달하는 방법에 대해 별로 생각하지 않은 보안 전문가에 의해 전달되었습니다.

그러나, 점점 더, 확실히 우리가 함께 일하는 고객과 함께, 나는 조직이 지금 마케팅 및 커뮤니케이션 팀과 변경 관리자를 포함하는 방법을 보고있다, 뿐만 아니라 콘텐츠에 디지털 애니메이션을 사용하고 이벤트와 도전을 실행하여 사이버 보안 교육을 더 재미있고 매력적으로 만들기 위해. 주기 보안 위협이 해마다 증가함에 따라 보안 인식 및 직원 교육은 조직에서 만들 수 있는 가장 중요한 투자입니다.

긍정적 인 강화 캠페인은 종종 위험한 행동을 수정하는 가장 좋은 방법 중 하나이지만 기업 세계에서 "확실히 이상값"이라고 Sedova 씨는 말합니다.

https://www.wsj.com/articles/a-better-way-to-teach-cybersecurity-to-workers-1505700120

졸업생이든 베테랑이든 모든 개발자가 물어봐야 할 질문이 있습니다. 그리고 대답은 중요합니다. 그것은 당신이 소프트웨어 엔지니어링에서 얼마나 성공할 것인지에 직접적인 영향을 미칠 것이기 때문에 민첩한 세계에서 더욱 중요해졌습니다. 그리고 당신은 당신에게 다음 고용주에게 얼마나 가치가있을 것입니다.

그것은 백만 달러의 질문입니다. 사실, 그것은 수백만 달러의 질문입니다!

안전하게 코딩할 수 있도록 도와주고 있습니까?

데이터 유출의 평균 비용은 이제 USD $ 3.6M에 서있다. 올해 회사가 위반될 확률은 4명 중 1명입니다. 이러한 사실을 감안할 때, 나는 개발자가 자신의 DNA에 내장 된 안전한 코딩 및 보안의 능력으로 대학을 졸업하지 않는 많은 좌절을 공유.  

왜? 소프트웨어 엔지니어링은 여전히 비교적 젊은 직업입니다. 사람들에게 코드를 신속하게 빌드하고 우아하고 기능적으로 만드는 방법을 가르치는 데 중점을 두었지만 코드를 안전하게 만드는 데 매우 제한적이었습니다. 방법론, 기술, 언어 및 기회의 변화 속도는 이러한 핵심 기술 격차를 악화시킬 뿐입니다.

우리는 학술 시스템을 신속하게 변경하지 않을 것이므로 개발자와 회사 모두 개발자가 직장에서 안전한 코딩 기술을 배워야한다고 기대해야합니다. 일부 직업에서는 실수를 함으로써 배울 수 있지만 다른 직업에게는 선택사항이 아닙니다. 사이버 보안도 마찬가지입니다.

사실은 우리가 작업 개발자 보안 교육도 잘하지 않은 것을 보여줍니다. 세계의 주요 보안 위반의 대부분은 해커가 컴퓨터 네트워크에서 권한을 얻을 수 있도록 코딩 오류로 인해 귀중한 데이터에 액세스하고 수확 할 수 있습니다. 버라이존 데이터 유출 조사 보고서 (DBIR) 2017,모든 위반의 30 %가 직접 웹 응용 프로그램 보안의 약점에 의해 발생하고이 결론은 2013 년부터 DBIR 보고서에서 일관되게되어 있음을 보여줍니다.

2017년 8월에 발표된 2017 년 글로벌 DevSecOps 기술 설문 조사는 우리가 이미 알고 있는 것을 확인했습니다: DevOps 전문가의 65%는 IT 에 진입할 때 DevSecOps에 대한 지식을 갖는 것이 매우 중요하다고 생각하지만, 70%는 오늘날의 DevSecOps 세계에서 성공하기 위해 공식적인 교육을 통해 필요한 교육을 받지 못하고 있다고 생각합니다.

설문조사에 참여한 채용 관리자의 약 40%는 가장 어려운 직원이 보안 테스트에 대한 충분한 지식을 갖춘 다목적 하이엔드 개발자라고 답했습니다. 응답자의 70%는 자신이 받은 보안 교육이 현재 직책에 적합하지 않다고 답했습니다. 실제로 4% 미만이 기회를 제공한다고 답했습니다.

저는 거의 10년 동안 전문 화이트햇 해커팀과 함께 일하면서 이 것을 직접 보았습니다. 비극적인 규칙으로 우리는 대기업, 신생 기업 및 정부 부서에 침입했습니다. 항상 동일한 약점을 찾는.

이것이 개발자가 고용 될 때 목소리를 높여야하는 이유입니다. 예비 고용주가 개발자 보안 교육을 진지하게 받아들이지 않는 경우 어떤 종류의 회사에 가입을 고려하고 있는지 생각해 보아야 합니다.

두 번째 질문은 그들이 그것을 제공 할 계획입니다. 그것은 실습 및 대화 형 될 것인가? 슬라이드웨어, 비디오, 클릭 가능한 애니메이션 또는 추상 토론을 사용하는 취약점에 대한 개발자 보안 교육은 코딩에 직접 도움이 되지 않을 수 있습니다. 최신 취약점을 지속적으로 최신 상태로 유지할 수 있습니까? 당신이 배울 수있는 보안 길드 또는 커뮤니티가 있습니까? 도움이 필요한 경우 다시 떨어질 수 있는 보안 메이븐이 있습니까?

보안 코딩 기술에 대한 약속은 특정 코딩 프레임워크에서 실무 적 과제를 통해 지속적인 학습이 필요하며 여러 시나리오에서 다양한 취약점에 직면해야 합니다. 한 예제를 통해 SQL 주입에 대해 배울 수 없습니다. 이러한 위험한 코딩 패턴을 인식하는 방법을 배우도록 다양한 유형의 여러 예제에 노출해야 합니다.

고객 중 한 명은 개발자가 2개월 동안 매일 하나의 챌린지(5분)를 해야 했습니다. 교육 기간 전후에 기술을 테스트하고 수백 명의 개발자 그룹을 통해 보안 코딩 기능이 60% 증가하는 것을 관찰했습니다. 즉, 수명 주기 후반에 보안 버그를 찾고 해결하는 데 소요되는 리소스가 줄어들고 장기적인 비용을 절감할 수 있습니다. 즉, 해커는 코드를 사용하여 회사의 데이터를 손상하지 않습니다.

IDC 연구에 따르면 2014년에는 전 세계에서 1,100만 명의 전문 개발자가 있었습니다. 2015년 Burning Glass는 코딩 기술이 필요한 700만 개의 직업이 있으며 프로그래밍 작업이 시장보다 평균 12% 빠르게 성장하고 있음을 발견했습니다.

거기 밖으로 소프트웨어 작업의 많음이 있다. 따라서 보안, 보안 및 고객의 보안을 관리하기 위해 최선을 다하고 있는 고용주를 선택하십시오.  확장하여, 당신에 투자하는 회사를 선택했다.

졸업생이든 베테랑이든 모든 개발자가 물어봐야 할 질문이 있습니다. 그리고 대답은 중요합니다. 그것은 당신이 소프트웨어 엔지니어링에서 얼마나 성공할 것인지에 직접적인 영향을 미칠 것이기 때문에 민첩한 세계에서 더욱 중요해졌습니다. 그리고 당신은 당신에게 다음 고용주에게 얼마나 가치가있을 것입니다.

그것은 백만 달러의 질문입니다. 사실, 그것은 수백만 달러의 질문입니다!

안전하게 코딩할 수 있도록 도와주고 있습니까?

지난 주 나는 우리의 보안 코딩 지침을 최신 상태로 가지고 자바 봄의 취약점을 연구했다. 나는 우리의 플랫폼에서 기존의 도전을 겪고 있었고 JSP 페이지에 URL 매개 변수를 표시하여 XSS에서 몇 가지를 발견했다. 잘못된 코드 예제는 다음과 유사한 것으로 보입니다.

   <input type="text" name="username" value="${param.username}">

올바른 솔루션은 URL 매개 변수를 완전히 제거하는 것이었고 설명은 URL 매개 변수를 벗어나올바른 방법도 안전하다는 것을 언급합니다.

이제 내 임무는 개발자에게 명확하고 보안 코드를 작성하는 동안 가능한 한 적게 제한하는 방식으로 보안 코딩 지침을 공식화하는 것입니다. 이 경우 개발자가 의도한 기능을 유지하고 URL 매개 변수를 벗어나 안전하게 수행하도록 권장하는 것이 좋습니다. 이렇게 하면 코드에 더 이상 XSS 취약점이 포함되어 있지 않습니다. 위의 예제는 다음과 같이 보호할 수 있습니다.

   <input type="text" name="username" value="${fn:escapeXml(param.username)}">

그리고 이것은 며칠 동안 우리의 안전한 코딩 지침이었다, 나는 표현 언어 주입에 OWASP 페이지에우연히 발견 할 때까지 . 이 페이지에서는 원격 코드 실행을 포함하여 몇 가지 심각한 영향을 미치면 SpEL(스프링 표현식 언어)이 주입을 위해 악용될 수 있는 방법을 설명합니다. 보안 코딩 지침을 준수하는 코드가 이 취약점의 영향을 받을 수 있는 경우가 있는지 파악하는 것은 저에게 달려 있습니다. 그래서 SpEL 표현을 평가하기 위해 빠른 테스트 응용 프로그램을 작성하고 Xml이 빠져나가지 않고 입력을 테스트하여 잡히지 않을 몇 가지 시나리오를 찾을 수 있는지 확인했습니다. 그리고 내가 한, XmlEscape에 의해 잡힌 문자를 포함하지 않는 악의적 인 표현이있다. 나는 당신이 여기에서찾을 수있는 우리의 github에 작업 데모를 게시 .

그리고 물론 나는 지금 읽는 우리의 보안 코딩 지침을 업데이트 : "표시하거나 스프링 표현 언어 (SpEL)를 사용하여 URL 매개 변수를 평가하지 마십시오."

공격자가 응용 프로그램 서버에서 기능을 수정하고 호출할 수 있습니다. - 데이터 및 기능에 대한 무단 액세스뿐만 아니라 계정 납치 및 원격 코드 실행. - 성공적인 공격의 기밀성 및 무결성 우려.

https://www.owasp.org/index.php/Expression_Language_Injection

Equifax 웹 사이트에서 2016년에 확인된 보안 문제는 아직 해결되지 않았습니다. 문제를 식별하는 한 단계이지만 문제를 해결하는 것이 더 큰 과제입니다. 코드로 돌아가 컨텍스트를 이해하고 문제를 해결하는 데 시간과 기술이 필요합니다.

Equifax의 개발자들은 많은 스트레스를 받았고 알려진 많은 취약점이 해결되지 않았습니다. 불행히도 행동의 부족은 이제 최악의 응답을했다.

보안은 처음부터 구워져야 하며 개발자는 알려진 취약점 작성을 최소화하기 위해 기술, 교육 및 IDE 도구가 필요합니다. 식별된 문제를 해결하기 위해서는 특정 언어와 프레임워크 지식이 필요합니다. XSS 문제 해결에 대한 일반적인 원칙은 동일하게 유지되지만 실제 구현은 기본 프레임워크에 따라 달라집니다.

스트럿스의 XSS 문제를 해결하는 방법에 대한 대화형 교육을 수행하려면 다음 을 확인하십시오 https://portal.securecodewarrior.com/#/simple-flow/web/xss/reflected/java/struts

앞으로 건너 뛰기 2016 및 보안 연구원은 주요 Equifax 웹 사이트에서 크로스 사이트 스크립팅 (XSS)으로 알려진 일반적인 취약점을 발견, 이름 x0rz로 가는 연구원의 트윗에 따르면. 이러한 XSS 버그는 공격자가 Equifax 고객에게 특별히 만들어진 링크를 보낼 수 있게 하고, 대상이 클릭하고 사이트에 로그인하면 사용자 이름과 암호를 해커에게 공개할 수 있습니다.

https://www.forbes.com/sites/thomasbrewster/2017/09/08/equifax-data-breach-history/#552ab1c9677c

지난 주, 그것은 Equifax 데이터 유출 뒤에 가능한 원인은 아파치 스트럿스 REST 플러그인의 취약점이었다보고되었다. 이전 버전의 플러그인은 XStream 처리기와 함께 XML 페이로드를 처리하는 데 사용할 때 원격 코드 실행 공격에 취약합니다. 원인은 잘 알려진 취약점 유형인 신뢰할 수 없는 데이터의 직렬화입니다. CVE-2017-9805로공식적으로 인정된 이 취약점은 9월 5일 스트럿스 버전 2.5.13에서 아파치에 의해 패치되었습니다. 그런 다음 아파치 스트럿스 문서에 발표되고 명확하게 문서화되었습니다.

단순히 최신 스트럿스 버전으로 업그레이드하면이 공격으로부터 응용 프로그램을 보호 할 수 있습니다, 그래서 왜 회사는 즉시 업그레이드하지 않습니다? 직렬화 취약점의 문제는 악용중인 루틴이 응용 프로그램 코드가 의존하는 루틴인 경우가 많다는 것입니다. 이 경우 새 스트럿 패치를 적용하면 취약점에 대한 설명서에 "사용 가능한 클래스에 적용된 기본 제한으로 인해 일부 REST 작업이 작동을 중지할 수 있습니다"라고 언급하는 경우 일부 부작용이 있을 수 있습니다. 응용 프로그램이 Struts의 최신 버전에서 계속 작업하는 데 시간이 걸릴 가능성이 높습니다.

그러나 해커는 게시된 취약점을 악용하기 시작하는 데 많은 시간이 필요하지 않으며 이미 일부 악용이 게시된것을 볼 수 있습니다. 메타스플로이트 모듈이 9월 8일에 추가되었으며, 아파치가 취약점을 패치한 지 3일 후입니다. 패치를 연기하는 것은 분명히 좋은 생각이 아닙니다!

해결책은 아파치가 제안한 해결 방법을 구현하는 것이며, 이는 짧은 시간 내에 이루어질 수 있습니다. 이 해결 방법을 적용하거나 자동으로 적용하는 구성 가능한 코딩 지침이 있는 보안 도구는 이 프로세스의 속도를 크게 높일 수 있습니다.

신뢰할 수 없는 데이터의 직렬화가 포함된 코드를 식별하고 보호하는 방법에 대해 자세히 알고 싶습니까? Secure Code Warrior 명확한 설명과 교육 도전에대한 포털 .

이 취약점은 스트럿스가 이러한 종류의 데이터를 구문 분석하고 Java 프로그래밍 언어로 해석할 수 있는 정보로 변환하는 방법과 관련이 있습니다. 취약점이 성공적으로 악용되면 이러한 데이터 내부에 악성 코드를 숨기고 스트럿스가 취약점을 변환하려고 할 때 실행할 수 있습니다.

https://qz.com/1073221/the-hackers-who-broke-into-equifax-exploited-a-nine-year-old-security-flaw/

새로운 라이브러리를 배우거나 팀 전체에서 합의된 관행을 공유하는 데 어려움 중 하나는 예제를 문서화하고 만드는 것입니다.

종종 작은 예제 프로젝트를 만들지만 실제 코드로 작업할 때는 프로젝트를 열지 않습니다.

저는 종종 예제 나 온라인 예제에 연결하고 필요할 때 더 많은 설명을 위해 URL로 갈 수있는 능력이 좋을 것이라고 생각했습니다.

Java를 사용하면 참조 주석을 가질 수 있는 JavaDoc 주석이 있습니다.

/**
 * @see <a href="https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations">Junit 5 Annotation docs</a>
 */

3자 라이브러리에서 이와 같은 JavaDoc은 IntelliJ의 빠른 문서 기능을 사용하여 보다 자세한 예제에 액세스할 수 있기 때문에 큰 도움이 됩니다.

그러나 우리 모두는 댓글이 코드만큼 자주 업데이트되지 않으며 웹 상태 유지 관리는 종종 라이브러리 유지 관리에서 분리되고 때로는 다른 팀에서 완전히 수행된다는 것을 알고 있습니다.

어떻게 Sensei 도움이

Sensei 라이브러리 주석 및 방법에 맞게 위키 또는 타사 자습서 사이트에서 긴 양식 문서에 대한 링크를 제공할 수 있습니다.

예를 들어 JUnit의 @Test 기조를 사용하고 있습니다.

JavaDoc은 매우 상세하며 빠른 설명서 보기에서는 이 노칭을 사용하는 방법을 설명합니다.

그러나 웹 사이트의 공식 문서는 종종 읽기 쉽고 더 많은 예제가 있습니다.

팀이 권장 자습서 집합을 갖는 라이브러리 학습을 시작하면 매우 유용할 수 있습니다.

Sensei URL을 여는 데 사용할 수 있는 goto 액션을 통해 외부 사이트와 팀으로서 유용하게 찾을 수 있는 문서의 예제에 연결할 수 있습니다.

고토 URL 구현

이를 구현하려면 주이트에서 @Test 기조와 일치하는 검색을 만들 것입니다.

search:
   annotation:
    owner:
      method: {}
    type: "org.junit.jupiter.api.Test"

그리고 유용하다고 생각되는 각 URL에 대해 goto 작업을 추가합니다.

예를 들어.

• https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations
• https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods

아래 예제에서는 브라우저에서 두 URL을 동시에 여는 단일 Action JUnit 주석(학습)을 만듭니다.

사용 가능한 픽스:
- 이름 : "JUnit 주석에 대해 알아보기"
작업:
- 고토 :
유형: "URL"
값: "https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations"=
- 고토 :
유형: "URL"
값: "https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods"

그리고 Alt+Enter를 사용하여 IntelliJ에서 활성화하면 문서로 이동하도록 선택할 수 있는 컨텍스트 메뉴가 표시됩니다.

여러 작업

각 URL 이나 튜토리얼alt+enter Quick Fix 팝업 메뉴에 자체 옵션이 있도록 여러 작업을 선택할 수 있습니다.

예를 들어 @Parameterized 어노피의 경우 공식 문서 및 온라인 예제 코드 집합에 연결할 수 있습니다.

• https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests
• https://github.com/eviltester/junitexamples/blob/master/src/test/java/parameterized/junit5/InitialExampleTest.java

나는 단순히 부기법을 만들 것입니다 :

search:
  annotation:
    owner:
      method: {}
    type: "org.junit.jupiter.params.ParameterizedTest"

그리고 내가 유용하다고 식별 된 사이트에 링크 :

사용 가능한 픽스:
- 이름 : "JUnit 주석 (학습)"
작업:
- 고토 :
유형: "URL"
값: "https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations"
- 이름 : "JUnit 테스트는 무엇입니까? (배우기)"
작업:
- 고토 :
유형: "URL"
값: "https://junit.org/junit5/docs/current/user-guide/#writing-tests-classes-and-methods"

그런 다음 두 링크가 팝업 대화 상자에 표시됩니다.

누가 혜택을 받을 것인가?

특히 팀을 이끌고 새로운 라이브러리를 채택할 때 라이브러리를 사용하고 학습할 때 이 유용한 것을 발견했을 것입니다.

또한 라이브러리의 채택이나 라이브러리의 새로운 기능을 통해 사람들을 안내하는 데 도움이 되는 표준 문서 레시피 집합을 만들어 라이브러리를 만드는 팀에게도 도움이 될 수 있습니다.

코드 유지 관리 및 문서 유지 관리가 다른 팀에서 수행하는 경우에 특히 유용합니다.

설치할 수 있습니다. Sensei '플러그인을 > 특시'를 사용하여 IntelliJ 내에서 (그냥 검색 " sensei 보안 코드").

이 블로그 게시물의 모든 코드는 주니예제 모듈의 Github에 있습니다. https://github.com/SecureCodeWarrior/ sensei -블로그 예

다시 한번, Equifax 해킹의 근본 원인은 웹 앱 취약점입니다. 이러한 유형의 취약점은 10년 이상 있었지만 오늘날에도 여전히 관련성이 있습니다. 각 개발자는 코드를 개발하는 동안 교육 및 실시간 지침을 통해 처음부터 이러한 문제를 도입하지 않도록 하는 도구를 제공해야 합니다.

Equifax는 7 월 29 일에 위반을 발견했다고 말했다. "범죄자는 특정 파일에 대한 액세스를 얻기 위해 미국 웹 사이트 응용 프로그램 취약점을 악용,"회사는 말했다.

더 보기: 신용 보고 회사인 equifax-says-cybersecurity-사고-잠재적으로 영향을 미칠 수 있는-1억 4,300만 명의 미국-소비자