Code de sécurité Insight

“탭”과 “하이재킹”의 조합인 탭재킹이 바로 그 의미입니다.공격자가 사용자의 탭을 하이재킹하고 의도치 않은 일을 하도록 속이는 공격입니다.그러면 어떻게 작동하고 어떻게 방지할 수 있을까요?

화면 오버레이로 이야기를 시작하겠습니다.화면 오버레이 또는 구글에서 부르는 것처럼 TYPE_APPLICATION_OVERLAY 유형을 사용하는 창. 이러한 창은 다른 앱 위에 그려지는 창으로 대개 화면의 일부만 가립니다.이는 앱에서 새 권한을 요청할 때 자주 사용됩니다 (아래 예제 이미지 참조).

이 기능은 정말 멋지고 재미있습니다. 점점 더 많은 앱에서 이 기능을 사용하기 시작했습니다. 아래 스크린샷처럼 Facebook의 채팅 풍선이나 화면 구석에 있는 Google 지도 내비게이션을 생각해 보세요.

그러나 이러한 오버레이에는 몇 가지 보안 위험이 따릅니다.활성화된 화면 오버레이는 탭 소리를 들을 수 있는데, 그렇지 않으면 페이스북이 우리가 버블을 탭하거나 드래그했다는 것을 어떻게 알 수 있을까요?이렇게 하면 앱이 사용자를 염탐하고 잠재적으로 비밀번호와 신용카드 데이터를 훔칠 수 있습니다.

한 걸음 더 나아가 탭재킹이라는 용어의 유래가 바로 여기에 있습니다. 오버레이는 다른 앱 위에 사용자를 속여 다양한 작업을 수행하도록 유도할 수 있습니다.사용자는 자신이 오버레이와 상호작용하고 있다고 생각하지만 실제로는 탭이 기본 앱에서 작업을 수행하기도 합니다.이렇게 하면 오버레이가 사용자를 속여 특정 권한을 활성화하거나 일부 위험한 설정을 변경할 수 있습니다 (아래 설명 참조). 오래된 유튜브 비디오.

위의 데모 영상은 2010년에 유튜브에 업로드된 것이므로 이전 버전의 Android에서 진행되었습니다.하지만 이 공격은 오늘날에도 여전히 유효합니다. 취약성이 있습니다 Nougat 및 Marshmallow와 같은 최신 버전의 Android에서 탭재킹을 허용하는 기능이 밝혀졌습니다.

그럼 어떻게 할 수 있을까요?사용자로서 이러한 오버레이의 결과를 이해하고 오버레이를 사용하는 앱을 알아두는 것이 중요합니다.API 레벨 23 (Android 6.0 마시멜로) 부터 이 권한은 다음과 같은 권한이 되었습니다. 사용자가 명시적으로 권한을 부여해야 합니다..하지만, 그걸로 남아요 안드로이드의 50%사용자는 여전히 취약합니다.'다른 앱 위에 표시' 아래의 설정에서 어떤 앱이 이 권한을 사용하는지 여전히 확인할 수 있습니다.

개발자로서 사용자의 행동이 사용자의 충분한 지식과 동의를 얻어 수행되도록 하는 것은 우리의 책임입니다.Android는 뷰에 바로 이러한 작업을 수행할 수 있는 설정을 제공합니다. 가려진 경우 터치를 필터링합니다. 이 기능이 활성화되면 프레임워크는 뷰 창이 다른 보이는 창으로 인해 가려질 때마다 수신된 터치를 버립니다.아주 간단합니다. 다음과 같이 설정하세요. 가려진 경우 터치 필터링 true로 설정하면 앱이 탭재킹으로부터 안전합니다.

행운을 빕니다. 다음 주에 만나요!

때로는 권한 요청 승인, 구매 또는 광고 클릭과 같은 작업이 사용자의 완전한 지식과 동의를 얻어 수행되고 있는지 애플리케이션이 확인할 수 있어야 하는 경우가 있습니다.안타깝게도 악성 애플리케이션은 뷰의 의도된 목적을 숨기고 자신도 모르는 사이에 사용자가 이러한 작업을 수행하도록 속이려 할 수 있습니다.

https://developer.android.com/reference/android/view/View.html

Publié à l'origine sur le DevSecCon Blog.

Ayant été des deux côtés de la barrière, je ne connais que trop bien les tensions qui peuvent surgir entre l'équipe de développement et les spécialistes de l'AppSec lorsqu'il s'agit de faire respecter les meilleures pratiques en matière de sécurité.

C'est difficile ; en fin de compte, la principale priorité d'un développeur est de fournir des fonctionnalités logicielles. Elles doivent être belles, fonctionnelles et contribuer à mettre en valeur la puissance de l'application. Avec les pratiques de développement agile généralement en vigueur de nos jours, ces fonctionnalités doivent être réalisées dans des délais stricts... et la sécurité est rarement en tête de liste des préoccupations avec tant d'autres enjeux.

La sécurité est considérée comme le domaine de l'équipe AppSec, qui a la tâche peu enviable d'analyser le code (ou pire : de l'examiner manuellement, ligne par ligne) et de signaler à l'équipe de développement que son code n'est pas sûr ou même qu'il est totalement inutilisable. Ce sont des bâtons dans la boue qui démolissent leur bon travail, freinent l'innovation et créent généralement des maux de tête pour les développeurs. En fin de compte, de nombreux problèmes de sécurité sont assez simples à résoudre : une seule ligne de code peut renforcer une porte dérobée vulnérable en quelques minutes.

Mais voilà le problème. La "sécurité" étant tellement synonyme d'expérience négative, les développeurs ne s'y intéressent tout simplement pas autant qu'ils le devraient. Les correctifs d'une seule ligne ne se produisent pas : après tout, les responsables de l'AppSec rencontrent continuellement les mêmes problèmes. Il doit être assez exaspérant pour eux de continuer à signaler des failles d'injection SQL, plus de vingt ans après que nous les ayons découvertes pour la première fois (et leur correction ultérieure).

Ce que nous avons fait jusqu'à présent n'est pas aussi efficace que nous l'espérions. Nous devons nous concentrer sur la réparation du pont entre les développeurs et les spécialistes de l'AppSec, en nous efforçant d'instaurer une culture positive de la sécurité dans laquelle les développeurs reçoivent les outils et la formation nécessaires pour avoir un impact réel dans ce domaine.

Qui sait ? Ils pourraient même en tomber amoureux comme je l'ai fait !

La sécurité positive est le moyen le plus rapide et le plus facile d'améliorer la sécurité des applications.

et non, il ne s'agit pas de résultats intangibles. Il s'agit d'un ingrédient absolument vital dans la recette du succès du codage sécurisé.

Les développeurs détiennent la clé de l'amélioration de la sécurité dès le début de la production, en écrivant un code sécurisé dès le départ. En créant une culture de sécurité positive et en suscitant l'intérêt des développeurs pour la sécurité des applications, les vulnérabilités courantes peuvent être éliminées avant même qu'elles n'atteignent le stade de l'analyse ou de l'examen manuel du code dans le cadre de l'AppSec land.

Il est trente fois plus coûteux de corriger les vulnérabilités d'un code déjà validé. Trouver une formation qui joue sur les points forts des développeurs, suscite leur intérêt et fonctionne réellement est un grand pas en avant dans la réduction des coûts futurs pour l'identification et la correction de ces vulnérabilités récurrentes.

Des initiatives positives, axées sur les développeurs, favorisent une bonne culture de la sécurité.

Lorsque tout le monde est d'accord avec les meilleures pratiques en matière de sécurité, une culture positive de la sécurité est un sous-produit heureux et vital.

Des initiatives positives et évolutives axées sur les développeurs favorisent une bonne culture de la sécurité. Il est essentiel de faire appel à l'esprit créatif et à la capacité de résolution de problèmes des développeurs pour les convaincre, et de veiller à ce que les nouvelles recrues puissent rapidement se familiariser avec les attentes de l'équipe en matière de sécurité. N'hésitez pas à nous contacter pour obtenir un aperçu de l'évolution de la relation entre les développeurs et la sécurité, ainsi que des idées pour mettre en place un programme de sensibilisation à la sécurité efficace au sein de votre propre organisation.

La suppression de fichiers sur un système informatique est une opération délicate. Tout le monde, même votre mère, a déjà supprimé un fichier de trop et a été heureux de le retrouver dans la corbeille et de pouvoir le récupérer.

Dans les systèmes informatiques, les données sont représentées par une séquence de bits. Cela signifie que le système doit tenir une comptabilité au sein du système de fichiers pour savoir quels bits représentent quel fichier. Parmi ces informations figurent la taille du fichier, la date de sa dernière modification, son propriétaire, les autorisations d'accès, etc. Ces données comptables sont stockées séparément du contenu du fichier.

En général, lorsqu'un fichier est supprimé, rien ne se passe au niveau des bits représentant le fichier, mais les données comptables sont modifiées de manière à ce que le système sache que cette partie de l'espace de stockage n'a plus de sens et peut être réutilisée. Jusqu'à ce qu'un autre fichier soit enregistré à cet emplacement et que les bits de cet emplacement soient écrasés, vous pouvez souvent encore récupérer les données qui ont été enregistrées. Cela permet non seulement d'accélérer la suppression des fichiers, mais c'est aussi souvent une fonction utile pour annuler la suppression.

Cette approche présente toutefois des inconvénients. Lorsqu'une application sur un système informatique traite des informations sensibles, elle enregistre ces données quelque part sur le système de fichiers. À un moment donné, lorsque les informations ne sont plus nécessaires, ces données peuvent être supprimées. Si aucune précaution supplémentaire n'est prise, ces données peuvent encore être récupérées, même si l'intention du développeur était que toutes les données soient supprimées.

La manière la plus simple d'effacer complètement ces données est de réécrire le contenu du fichier avec des données aléatoires (parfois même plusieurs fois). Il existe plusieurs méthodes de suppression sécurisée des fichiers, qui varient selon les types de stockage et les systèmes de fichiers, comme la méthode Gutmann. Toutefois, pour une utilisation quotidienne, ces méthodes sont un peu excessives et vous pouvez simplement réécrire les données vous-même.

Mais attention ! N'utilisez pas de zéros ou d'autres données à faible entropie. De nombreux systèmes de fichiers peuvent optimiser l'écriture de tels fichiers épars et laisser une partie du contenu original. Il est recommandé de générer des données aléatoires sûres pour écraser l'ensemble du contenu du fichier avant de supprimer le fichier lui-même.

La rémanence des données est la représentation physique résiduelle des données qui ont été effacées d'une manière ou d'une autre. Après l'effacement d'un support de stockage, certaines caractéristiques physiques peuvent permettre de reconstituer les données.

https://fas.org/irp/nsa/rainbow/tg025-2.htm

사이버 위협의 수가 계속 증가함에 따라 조직은 보안, 실용성 및 속도 사이에서 매일 균형을 유지하며 프로세스의 위험에 노출되고 있습니다.보안 코딩에 대한 새로운 접근 방식이 필요하므로 Secure Code Warrior는 Evans Data Corp. 와 협력하여 보안 코딩, 보안 코드 관행 및 보안 운영에 대한 개발자의 태도에 대한 주요 연구를 수행했습니다 (백서 다운로드) 이리).

이 보고서에서 밝혀진 바에 따르면 '구식' 반응적 사고가 여전히 지배적이지만, 개발자 자신을 1차 방어선으로 만드는 보다 능동적인 솔루션이 필요하다는 인식이 높아지고 있습니다.

보안 코딩 관행의 채택에 대한 모든 탐구는 구현에 관련된 사람, 이에 대한 인식, 구현 능력에 대한 이해에서 시작해야 합니다.그러면 가장 중요한 수수께끼가 생깁니다. 어떻게 하면 처음부터 더 안전하게 코딩하고 품질 좋은 코드를 자신 있게 더 빠르게 출시할 수 있을까요?

보안 코딩 — 우리는 지금 어디에 있으며, 무엇을 바꿔야 할까요? 다운로드 이제 인포그래픽 '휴먼 엘리먼트'가 나왔습니다.

현재 관점 — 사후 대응적 vs. 사전

개발자와 개발 관리자에게 보안 코딩과 관련된 활동에 대해 질문했을 때 가장 많이 받은 세 가지 응답은 다음과 같습니다.

• 배포된 애플리케이션에서 스캐닝 도구 사용
• 코드의 취약점을 수동으로 검토합니다.
• 취약점으로부터 보호되는 소프트웨어를 개발하는 적극적이고 지속적인 사례.

보시다시피 상위 3개 응답 중 2개는 여전히 반응형 접근 방식에 초점을 맞췄습니다. 첫 번째는 도구 (스캐너) 에 의존하고 두 번째는 수동 검사를 수행하는 개발자 (예: 사람) 에 관한 것입니다.

동시에, 후보에 오른 세 가지 활동 중 두 가지는 인적 요소에 의존합니다.이는 보안에 대한 인간의 문제라는 인식이 커지고 있다는 것을 의미합니다.하지만 후보에 오른 모든 활동 중에서 가장 눈에 띄는 것은 인적 요소를 파악한 3위입니다. 애초에 취약점으로부터 보호되는 소프트웨어를 작성할 때.이는 SDLC의 시작부터 소프트웨어에 보안을 적용하는 사전 예방적이고 예방적인 접근 방식인 처음부터 처음부터 시작하는 방식으로의 전환을 잘 보여줍니다.

SDLC의 보안은 어디에 적합할까요?

개발자와 개발 관리자에게 SDLC에 통합되는 보안 코드 관행이 어디에 있는지 물으면 의견이 다릅니다. 전체 개발 프로세스에 보안 코딩이 통합되어 있다고 생각하는 관리자는 55% 인 반면, 개발자의 43% 만이 보안 코딩이 전체 개발 프로세스에 통합되어 있다고 생각합니다.이러한 차이는 SDLC 내에서 이 두 그룹의 역할이 서로 다르기 때문일 수 있습니다.경영진은 일반적으로 실제 코딩 작업에 덜 관여하고 높은 수준의 관점을 갖는 경향이 있는 반면, 개발자는 기본 사항에 더 신경을 쓸 수 있습니다.

그러나 전반적인 보안 및 코드 품질 관점에서 볼 때 놀라운 점은 개발자의 13% 와 관리자의 10% 만이 SDLC 시작 직후인 설계 단계 내에 보안 코드 프랙티스를 통합해야 한다고 답했다는 것입니다.이는 실현되지 않은 거대한 기회입니다.IBM의 연구에 따르면 출시 후 코드의 취약점을 처음 발견하여 해결하는 것보다 30배 더 많은 비용이 든다고 합니다.1 이는 개발자가 처음부터 더 안전하게 코딩할 수 있도록 지원하는 새로운 사전 예방적이고 사람이 주도하는 소프트웨어 보안 방어에 대한 강력한 인센티브입니다.소프트웨어 보안은 툴링에만 의존해서는 해결할 수 없습니다. 인적 요소를 고려해야 하기 때문입니다.

인간적 요소는 준비되어 있는가?

설문 조사에 참여한 개발자 중 97% 는 보안 코딩에 대한 충분한 교육을 받았다고 생각했으며 95% 는 보안 코딩 교육이 자신의 경력에 유용했다는 데 동의했습니다.하지만 이러한 주장을 액면 그대로 받아들이기 전에 먼저 다음과 같은 질문을 던져야 합니다. 코드 취약점이 여전히 만연해 있는 이유는 무엇일까요?보안 코드 전문 지식에 대한 개발자의 주장은 인간의 자존심에 불과할까요?증거들은 분명 이러한 방향을 가리키고 있습니다.설문에 응한 개발자 중 88% 이상이 시큐어 코딩을 배우기 어렵다고 답했고, 개발 관리자의 91% 는 시큐어 코딩 프랙티스를 구현하기 어렵다고 인정했습니다.보안 코드 구현과 관련된 개인적인 주요 관심사를 묻는 질문에, 개발자의 28% 는 학습 과정이 어렵다고 답한 반면 24% 는 학습 과정이 지루하다고 답했습니다.이는 개발자 교육을 개선해야 한다는 사실을 일깨워줍니다.

인간 요소에는 무엇이 필요합니까?

'도전적인' 요인을 극복하기 위해, 가치 있는 보안 교육을 위해서는 개발자가 단계별로 보안 코딩 기술을 구축할 수 있도록 지원하는 '스캐폴딩' 프로세스가 필요합니다.관련성을 극대화하고 즉각적인 적용 가능성을 높이려면 매일 사용하는 특정 언어, 즉 프레임워크로 교육을 진행해야 합니다.

'지루함' 요인을 극복하기 위해, 보안 코드 교육은 실습 방식으로 제공되어야 합니다. 이는 시대에 뒤떨어진 강의실이나 '이 비디오를 시청하세요' 모델보다 개발자에게 훨씬 더 매력적인 것으로 입증되었습니다.여기에는 개발자가 안전한 환경에서 때때로 위험한 보안 문제를 해결할 수 있는 실시간 시뮬레이션이 포함되어야 합니다.개발자에게 작업 시 코드의 취약점을 찾아 수정하는 방법을 알려주고 보안 코딩을 일상 업무의 일부로 활용하는 방법을 알려주는 것이 목표여야 합니다.또 다른 주요 지원 요소는 IDE 내부 린팅 및 코칭입니다. 이를 통해 개발자는 코드를 작성하면서 지속적으로 학습하고 기술을 향상시켜 취약점을 예방하고 제거할 수 있습니다.

개발자에게 이 새로운 수준의 개발자 중심 도구 및 교육을 제공하는 방법을 알고 싶다면 데모 예약 지금.

또한 할 수 있습니다 사본 다운로드 백서의 대응에서 예방으로의 전환: 애플리케이션 보안의 변화하는 모습.

‍

사이버 공격은 의심할 여지 없이 증가하고 있습니다.Verizon 2021 데이터 침해 조사 보고서에 따르면 위협 환경은 다음과 같습니다. 오늘은 더 위험해 그 어느 때보다.규모를 막론하고 조직은 공격 대상을 노리는 위협 행위자로부터 더 많은 공격과 더 높은 수준의 정교함을 경험하고 있습니다.그리고 공격자의 성공률도 치솟고 있습니다.

가장 최근의 공격을 분석하면 사이버 방어에 대한 전례 없는 공세 속에서 해커들이 사용하는 가장 일반적인 취약점과 기술을 발견할 수 있습니다.오픈 웹 애플리케이션 보안 프로젝트 (OWASP) 를 만든 공격과 같이 가장 널리 사용되는 공격 중 일부 2021년 10대 보안 위험 및 취약성, 자격 증명을 도용하거나 기타 침해하는 행위와 관련이 있습니다.그리고 보안 연구에 따르면 Akamai가 실시한 결과, 압도적 다수 (거의 75%) 가 API가 보유한 자격 증명을 직접 대상으로 했습니다.

API의 증가와 파멸 가능성

거의 모든 조직의 네트워크에서 API라고 불리는 애플리케이션 프로그래밍 인터페이스가 증가하고 있는 것은 놀라운 일이 아닙니다.이들은 대부분의 기업, 조직 및 정부 기관의 온프레미스 자산 기능을 빠르게 인수하고 있는 대부분의 클라우드 기반 서비스의 핵심 구성 요소입니다.요즘에는 클라우드가 없으면 어떤 종류의 비즈니스나 작업도 거의 수행할 수 없습니다. 특히 공공을 대상으로 하는 비즈니스는 더욱 그렇습니다.즉, API는 모든 네트워크에서 상당히 많은 서비스를 하나로 묶는 역할을 할 것입니다.

API의 놀라운 점은 네트워크 리소스 할당 측면에서 API가 대부분 작고 눈에 거슬리지 않는다는 것입니다.그리고 거의 모든 작업을 수행할 수 있을 정도로 완전히 유연합니다.API의 핵심은 특정 프로그램을 제어하거나 관리하도록 맞춤화된 개별 소프트웨어입니다.호스트 운영 체제, 애플리케이션 또는 서비스의 데이터 액세스와 같은 매우 특정한 기능을 수행하는 데 활용할 수 있습니다.

안타깝게도 API가 매력적인 타겟이 되는 이유는 바로 이와 동일한 유연성과 규모가 작고 보안 팀에서 간과하는 경우가 많기 때문입니다.대부분의 API는 개발자가 완전한 유연성을 고려하여 설계하므로, 예를 들어 관리 중인 핵심 프로그램이 수정되거나 변경되더라도 계속 작동할 수 있습니다.그리고 표준도 거의 없습니다.눈송이와 마찬가지로 많은 API는 특정 네트워크에서 단일 프로그램으로 특정 기능을 제공하도록 만들어졌다는 점에서 독특합니다.보안에 대해 잘 모르거나 특별히 보안에 집중하지 않는 개발자가 코딩한 것이라면 얼마든지 만들 수 있고 또 그럴 가능성이 높습니다. 취약성이 있습니다 공격자가 찾아서 악용할 수 있습니다.

안타깝게도 문제는 빠르게 해결되지 않고 있습니다.가트너에 따르면 2022년이 되면 API와 관련된 취약성 모든 사이버 보안 범주에서 가장 빈번한 공격 벡터가 될 것입니다.

공격자가 API를 손상시키려는 주요 이유는 API가 수행하는 특정 기능을 넘겨받기 위해서가 아니라 API와 관련된 자격 증명을 훔치기 위해서입니다.API의 가장 큰 문제점 중 하나는 취약점이 무성할 뿐만 아니라 취약성이 자주 발생한다는 것입니다. 지나치게 허가됨 핵심 기능과 관련하여간단히 말해서, 대부분의 API는 네트워크에서 관리자 수준에 가까운 액세스 권한을 가집니다.공격자가 제어 권한을 얻으면 해당 권한을 사용하여 네트워크에 더 심층적이고 실질적인 침입을 시도할 수 있는 경우가 많습니다.또한 API에는 공격자가 리디렉션하는 모든 작업을 수행할 수 있는 권한이 있기 때문에 Access-All-Area VIP 백스테이지 패스 덕분에 API가 규칙을 위반하지 않기 때문에 공격자의 행위가 기존의 사이버 보안 모니터링을 우회하는 경우가 많습니다.

조직이 주의를 기울이지 않으면 네트워크와 클라우드 내에서 API가 증가하여 공격자의 표적이 될 경우 큰 문제가 발생할 수도 있습니다.

API 방어

API의 상황은 점점 더 위험해지고 있지만 절망적이지는 않습니다.움직임을 통한 많은 노력이 필요합니다. 데브섹옵스처럼 개발자가 보안을 더 잘 인식할 수 있도록 돕고 개발에서 테스트 및 배포에 이르는 소프트웨어 생성의 모든 측면에 보안 및 모범 사례를 적용할 수 있도록 합니다.2022년 이후까지 API 악용 추세를 극복하고자 하는 모든 조직에게는 이러한 교육의 일부로 API 보안을 포함하는 것이 매우 중요할 것입니다.

그렇긴 하지만 API 보안 측면에서 지금 바로 구현할 수 있는 몇 가지 정말 좋은 모범 사례가 있습니다.

첫 번째는 모든 API에 엄격한 ID 제어를 포함하는 것입니다.권한을 할당할 때는 이들을 거의 인간 사용자와 비슷하게 생각해야 합니다.API는 특정 기능만 수행하도록 설계되었으므로 공격자가 API를 침해할 경우 어떤 일이 발생할 수 있는지 생각해 보아야 합니다.역할 기반 액세스 제어를 사용해 보세요.궁극적으로는 API와 사용자에게 제로 트러스트 원칙을 적용하는 것이 가장 좋지만, 이는 긴 여정인 경우가 많습니다.올바른 ID 관리부터 시작하는 것이 좋습니다.해당 프로그램에 API를 포함시키기만 하면 됩니다.

또한 API가 수행하는 다양한 호출을 최대한 엄격하게 제어해야 합니다.이러한 호출을 매우 컨텍스트 중심적인 요청으로 제한하면 공격자가 악의적인 목적으로 요청을 수정하기가 훨씬 더 어려워집니다.초기 API가 무엇을 찾고 무엇을 무시해야 하는지 정확히 알고 있는 다른 API를 고도로 상황에 맞게 호출하여 API를 계층화할 수도 있습니다.이는 위협 행위자가 해당 체인 내에서 API를 악용하고 손상시킬 수 있는 경우에도 해당 위협 행위자가 이용할 수 있는 기능을 제한하는 효과적인 방법이 될 수 있습니다.

API에 대한 위협은 확실히 압도적으로 보일 수 있습니다.하지만 모범 사례를 구현하는 동시에 보안 챔피언이 된 개발자를 지원하고 보상하면 상황이 훨씬 덜 절망적으로 느껴질 수 있습니다.충분한 교육과 연습만 있으면 작지만 필수적인 API 도구 중 하나를 손상시키더라도 공격자가 기동할 여지를 거의 주지 않는 강력한 보안 프로그램을 만들 수 있습니다.

En tant que professionnel de la sécurité des applications, il vous incombe de garantir la cybersécurité des applications de votre organisation. Cependant, vous n'êtes pas responsable de l'écriture du code sur lequel l'application fonctionne. Ce sont les ingénieurs de l'équipe de développement qui s'en chargent. Comment pouvez-vous donc vous assurer qu'ils développent ces systèmes en gardant la sécurité à l'esprit ? 

Il est très probable que vous fassiez certaines des choses suivantes, voire toutes : 

• Examiner l'ensemble du code pour détecter les failles de sécurité et les signaler à l'équipe de développement pour qu'elle les corrige. 
• Appliquer un processus strict d'évaluation par les pairs tout au long du cycle de développement sécurisé. 
• Faire réaliser régulièrement des tests d'application assessment/de pénétration par des équipes de sécurité internes ou externes.
• Mettre en place des outils d'analyse pour détecter les vulnérabilités.
  

Il s'agit là d'excellentes pratiques, mais elles sont également coûteuses et reviennent à prendre une série d'antibiotiques chaque fois que vous tombez malade. Non seulement le coût est élevé, mais les médicaments perdent de leur efficacité et peuvent affaiblir votre système immunitaire au fil du temps. 

Comment s'assurer que le code livré par les développeurs est écrit de manière sécurisée ? 

Au-delà du codage sécurisé, réfléchissez d'abord à la manière dont les gens apprennent. La plupart d'entre nous sont des apprenants visuels et nous apprenons par la pratique. Or, la formation au codage sécurisé est souvent proposée comme une activité "à cocher" et n'est pas pertinente pour le travail quotidien d'un développeur. Elle est conçue pour prouver que les développeurs ont suivi une formation à la sécurité, souvent pour se conformer aux normes de l'industrie, et non pour que les développeurs retiennent réellement ces connaissances, et encore moins pour qu'ils apprécient le processus d'apprentissage. 

Les humains ont également tendance à apprendre en commettant des erreurs, comme le fait notre système immunitaire. Les cellules T se souviennent des agents pathogènes qu'elles ont rencontrés et éradiqués avec succès dans le passé, de sorte qu'elles peuvent se protéger contre eux à l'avenir. C'est exactement le rôle que les développeurs devraient jouer dans votre SDLC sécurisé .

Il n'est pas réaliste d'attendre d'eux qu'ils ne fassent pas d'erreurs, mais vous pouvez les préparer de manière à ce qu'ils soient capables de reconnaître les schémas de codage qui se traduiront par des vulnérabilités en matière de sécurité à l'avenir. 

C'est également ainsi qu'un processus robuste d'évaluation par les pairs devient si puissant. Ce n'est pas parce qu'un développeur ne remarque pas une faille de sécurité qu'un autre ne le fera pas. Et plus l'équipe de développement est bien formée, plus les vulnérabilités sont susceptibles d'être détectées et de ne jamais atteindre la production. 

Les vulnérabilités des logiciels sont comme des agents pathogènes

Les vulnérabilités des logiciels sont comme des agents pathogènes, en ce sens qu'il faut s'en souvenir pour les combattre. Dans le cas des agents pathogènes, notre système immunitaire doit souvent être exposé plusieurs fois avant de se souvenir de la manière de les combattre et d'éviter une maladie grave, voire pire. 

Une cyberattaque réussie à partir d'un logiciel vulnérable peut gravement paralyser ou tuer une organisation. Mais si les développeurs sont d'abord confrontés aux vulnérabilités des logiciels dans un environnement contrôlé, ils peuvent s'efforcer de s'immuniser contre les menaces en renforçant et en pratiquant régulièrement leurs connaissances et leurs compétences en matière de codage sécurisé. 

Exposer les développeurs aux failles de sécurité dans un environnement contrôlé

Nous ne pouvons jamais nous protéger totalement contre les maladies, mais il y a des choses que nous pouvons faire pour renforcer notre système immunitaire et rester en aussi bonne santé que possible. L'exercice physique régulier, une alimentation saine et un sommeil suffisant font partie des choix de vie généralement associés à un système immunitaire fort. Mais toutes ces choses demandent un peu d'effort et doivent être continues. Faire du jogging tous les jours pendant une semaine ou arrêter de boire pendant un mois ne changera pas grand-chose à votre état de santé général. Il n'est pas non plus conseillé de courir un 10 km le premier jour où l'on se met à la course à pied. Nous devons d'abord exposer notre cœur et nos muscles à l'exercice. Nous savons également qu'il faut expérimenter un peu avant de trouver un bon équilibre pour notre corps, des aliments sains et des exercices que nous aimons.

Il en va de même pour le développement de logiciels sécurisés. L'apprentissage se fait avec le temps et la pratique, et les développeurs ont besoin de la même formation continue pour renforcer régulièrement leurs compétences en matière de codage sécurisé. De plus, le développement de logiciels évolue et s'adapte en permanence, ce qui signifie que les vulnérabilités évoluent également. C'est pourquoi un simple cours de formation ne suffit pas. Les développeurs ont besoin d'une formation continue régulière afin d'être suffisamment familiarisés avec les menaces potentielles pour être correctement équipés pour s'en défendre. 

Viser l'immunité collective au sein de l'équipe de développement

Une seule personne ne peut pas prévenir tous les problèmes de sécurité. C'est une bonne chose d'avoir des champions de la sécurité dans l'équipe, mais pour obtenir la meilleure protection, plus il y a de personnes qui ont appris à connaître les vulnérabilités en matière de sécurité et à les prévenir, plus votre organisation a de chances de les prévenir. Encore une fois, ce n'est pas très différent de la façon dont le système immunitaire a différents types de cellules T pour différents objectifs. Chaque développeur fait partie d'une équipe qui assure la sécurité. S'ils sont habilités à prendre des responsabilités, à bien faire leur travail et même à aimer le faire, vous pouvez alors créer une immunité collective contre les cybermenaces au sein de l'équipe de développement.

Gardez la sécurité à l'esprit grâce à une exposition répétée

Notre cerveau apprend de la même manière que notre système immunitaire. Le psychologue allemand Hermann Ebbinghaus a été un pionnier dans le domaine de la mémoire et de l'apprentissage. Il en a déduit que l'apprentissage doit se faire dans la durée et au cours de multiples sessions d'apprentissage. À l'école, on ne s'attend jamais à ce que nous conservions de nouvelles connaissances après la première introduction. L'information nous est d'abord présentée, puis nous la pratiquons avec des conseils, puis nous la pratiquons seuls. Et même lorsque nous les avons suffisamment bien assimilées pour réussir un examen, les informations ont tendance à être oubliées peu de temps après si nous n'utilisons pas régulièrement les connaissances que nous avons consacré du temps et des efforts à apprendre. Combien d'entre nous peuvent affirmer qu'ils se souviennent du français qu'ils ont appris au lycée ?

Dès lors, comment croire qu'une seule journée passée à regarder des diapositives et à écouter quelqu'un parler de sécurité permettra aux développeurs présents de coder de manière plus sûre ?

Les schémas de vulnérabilités récurrentes nous montrent que cela ne fonctionne tout simplement pas. 

Comment parvenir à une immunité de développement sécurisée ?

La réponse se trouve dans notre nature. Notre corps et notre esprit fonctionnent de la même manière et apportent de belles solutions aux problèmes, à condition de travailler avec eux et non contre eux. 

Pour garantir la sécurité de vos applications, vous devez commencer par former les développeurs à l'écriture de codes sécurisés. Sinon, l'AppSec continuera à passer tout son temps à examiner l'ensemble du code à la recherche de failles de sécurité et à rapporter les mêmes vulnérabilités récurrentes au développement pour qu'elles soient rapidement corrigées sans que rien n'ait été appris. Et l'on recommence pour la prochaine version.

Répétons-le donc.

Si vous collaborez avec vos responsables du développement pour y parvenir, vous ne vous contenterez pas de mettre en œuvre un SDLC sécurisé et de cocher la case de l'exigence de formation à la sécurité pour la conformité, vous aurez un impact réel sur le processus de développement. Pour couronner le tout, l'AppSec ne rencontrera plus de vulnérabilités répétées et ne les signalera plus aux équipes de développement, et les développeurs passeront moins de temps à les corriger. Cela signifie qu'ils pourront consacrer plus de temps à la création et à l'amélioration des logiciels extraordinaires qui rendent notre monde meilleur. 

Prêt à renforcer les compétences de votre équipe de développement ? Réservez une démonstration avec nous.

Bien que cela puisse sembler contre-intuitif pour toute personne travaillant en dehors du développement de logiciels, de nombreux professionnels employés dans la sécurité des applications au fil des ans ont travaillé dans ces rôles critiques avec peu ou pas d'expérience en programmation. Ces professionnels de l'AppSec font partie de l'équipe chargée de veiller à ce qu'aucune vulnérabilité ne se glisse dans les applications qui sont devenues l'élément vital de nombreuses industries et organisations, et pourtant, peu d'entre eux peuvent directement évaluer ou corriger le code eux-mêmes. 

Au lieu de venir d'une formation en codage, de nombreux professionnels de la sécurité abordent leur rôle du point de vue des connaissances clés sur les vecteurs d'attaque, les menaces, les exploits et les risques commerciaux ; ils ont une vision limitée du code. Si tous les gourous de l'AppSec n'ont pas les mêmes compétences, la journée type de beaucoup d'entre eux consiste à travailler avec des réviseurs de code et des outils d'analyse pour s'assurer que les programmes et les systèmes sont sécurisés conformément aux normes de l'organisation ou aux cadres sectoriels et gouvernementaux pertinents. Ils rédigent ensuite des rapports sur leurs conclusions et renvoient des informations sur le vecteur d'attaque susceptible de casser le code. Il appartient alors aux développeurs d'apporter les corrections nécessaires, même si cela perturbe le travail en cours.

Si la situation a évolué de la sorte, c'est parce que la logique qui a prévalu au fil des ans était que le travail de protection des réseaux et des applications était si vaste qu'il n'était pas logique d'attendre de chaque personne travaillant dans le domaine de la cybersécurité qu'elle remplisse toutes les fonctions. Les compétences en matière de codage profond étaient laissées aux développeurs, et la capacité à écrire ou à modifier du code plus loin dans le pipeline de développement n'était guère valorisée.

Cet état d'esprit est en train de changer rapidement, et cela représente une opportunité unique pour les développeurs de faire le saut lucratif et de changer de carrière dans l'AppSec. Tous les développeurs ne voudront pas embrasser le soi-disant côté obscur, et beaucoup de développeurs n'ont pas d'opinion particulièrement positive sur les équipes AppSec. Mais pour ceux qui le souhaitent, il n'y a jamais eu de meilleur moment pour saisir cet anneau de laiton de plus en plus tentant.

DevSecOps est au cœur de presque tous les secteurs d'activité

L'un des facteurs les plus importants pour accroître la valeur des programmeurs et des développeurs sensibilisés à la sécurité dans toute organisation est l'adoption quasi universelle de pratiques de développement plus agiles comme DevSecOps. Lorsque le développement, la sécurité et les opérations sont combinés, la cybersécurité devient une responsabilité partagée intégrée dans le développement d'un nouveau logiciel de bout en bout. Dans cet environnement, la capacité à coder est de plus en plus considérée comme un atout précieux pour tous, et c'est particulièrement vrai pour les ingénieurs qui comprennent aussi intrinsèquement la sécurité.

Un professionnel de l'AppSec qui comprend non seulement la cybersécurité à un haut niveau, mais aussi le code qui permet à tout de fonctionner, est intrinsèquement plus précieux pour une organisation que quelqu'un dont les connaissances sont concentrées sur la théorie. La capacité à découvrir et à évaluer rapidement les vulnérabilités trouvées dans le code, puis à atténuer ces problèmes, est au cœur de la raison pour laquelle DevSecOps connaît une telle popularité.

Les développeurs travaillant dans l'AppSec apportent également un autre avantage important à toute organisation qui les emploie. Comme ils viennent du côté du développement, il leur est facile de parler de sécurité et de vulnérabilités avec les développeurs. Il leur est également beaucoup plus facile de devenir des coachs pour les équipes de développement, en les aidant à devenir de meilleurs codeurs. Avec le temps, ils pourraient même être en mesure d'éliminer le stigmate du "côté obscur" de l'AppSec et d'aider à unifier les équipes de développement de logiciels au sein d'une organisation.

La pénurie de compétences en cybersécurité s'aggrave

Shakespeare a dit que c'est un vent mauvais qui ne fait de bien à personne. Ce qu'il voulait dire, c'est que même la situation la plus sombre profite probablement à quelqu'un. La pénurie de compétences en cybersécurité en est un excellent exemple.

La pénurie de personnel se fait sentir de manière aiguë presque partout. Dans une enquête récente menée par le Center for Strategic and International Studies, 82 % des décideurs informatiques ont déclaré que leur organisation souffrait d'une pénurie de compétences en matière de cybersécurité, et 71 % ont déclaré que cette pénurie avait entraîné des dommages directs et mesurables pour leur organisation. Pour mieux comprendre cette crise, le rapport souligne que rien qu'aux États-Unis, il y aura plus de 520 000 emplois non pourvus dans le domaine de la cybersécurité en 2020, alors qu'il n'y en a que 940 000 qui sont employés.

La pénurie de personnel dans le domaine de la cybersécurité est une mauvaise nouvelle pour les organisations qui tentent de protéger leur infrastructure, leurs activités et leurs données contre un paysage de menaces de plus en plus dangereux. Mais elle constitue une bonne opportunité pour les développeurs qui cherchent à se lancer dans l'AppSec et la sécurité. Il y a de fortes chances que des postes en cybersécurité et en AppSec soient disponibles presque partout. Et comme les postes en cybersécurité prennent en moyenne 21 % plus de temps à pourvoir ces jours-ci, les salaires augmentent dans tous les domaines.

Passer à l'AppSec

Il n'y a peut-être jamais eu de meilleur moment pour que les développeurs fassent le saut lucratif vers le côté ensoleillé de la sécurité. Les développeurs sensibilisés à la sécurité ne sont plus considérés comme un simple élément d'une méthode de sécurité palliative, mais remplissent au contraire un rôle à part entière et respecté de défenseurs de la cybersécurité. Cela est particulièrement vrai pour les organisations qui ont adopté DevSecOps et d'autres méthodologies de développement plus agiles. Et la pénurie de talents en cybersécurité signifie que des postes sont disponibles dans presque toutes les entreprises, agences gouvernementales ou organisations. Ceux qui possèdent les bonnes compétences peuvent choisir où ils veulent travailler.

Le passage à l'AppSec n'est peut-être pas fait pour tout le monde, et bien sûr, la plupart des développeurs resteront concentrés sur la création de fonctionnalités étonnantes. Mais pour ceux qui envisagent de faire le saut, investir dans une formation en sécurité pour compléter leurs compétences de codage existantes peut ouvrir de nombreuses portes. Les meilleurs spécialistes de l'AppSec sont issus de l'ingénierie, parce qu'ils comprennent profondément la technologie et ont de l'empathie pour les difficultés de leurs collègues développeurs. DevSecOps signifie que tout le monde est désormais responsable de la sécurité, alors pourquoi ne pas profiter de la pénurie actuelle de compétences critiques pour faire évoluer votre carrière vers la sécurité des applications ? Il n'y a jamais eu de meilleur moment pour prendre une décision positive pour vous-même, votre famille et votre carrière.

부채널 공격은 해커가 알고리즘의 이론적 약점이나 소프트웨어 코드의 버그가 아니라 소프트웨어 시스템의 물리적 구현에서 정보를 수집할 수 있는 경우입니다.

이를 더 명확하게 하기 위해 제가 사용하고 싶은 예는 사용자 이름을 열거하는 방법입니다.사용자 이름 열거가 무엇인지, 왜 나쁜지 알고 싶으시면 저희 웹사이트를 방문하셔서 비디오 설명 또는 챌린지 플레이하기 코드에서 식별할 수 있는지 확인하십시오.

이제 부채널 공격을 통해 사용자 이름을 열거하는 방법을 이해하려면 최신 웹 애플리케이션에서 비밀번호가 어떻게 처리되는지 (또는 적어도 처리해야 하는지) 어느 정도 이해해야 합니다.좋은 웹 애플리케이션은 사용자의 비밀번호를 모르기 때문에 어디에도 비밀번호를 저장하거나 저장하지 않습니다.그렇다면 입력한 내용이 정확한지, 실제로 암호인지 어떻게 알 수 있을까요?음, 비밀번호는 해시되어 있습니다.

해싱 함수는 한 방향으로 수행하기 쉽지만 (계산 비용이 다소 많이 들지만) 되돌리기는 매우 어려운 수학 연산입니다. 좋은 해싱 알고리즘의 경우 입력에 따라 출력이 고유합니다.웹 사이트에 등록하면 암호 자체가 아니라 해시가 안전하게 저장됩니다.즉, 로그인할 때마다 웹 애플리케이션은 입력 내용을 해시하고 해시된 결과를 저장된 해시와 비교합니다.에 대해 자세히 알아보려면 보안 암호 저장, 저희 플랫폼에서 하실 수 있습니다.

컴퓨터에서 해싱 입력은 시간이 오래 걸리며 개발자는 사용자가 원활한 경험을 할 수 있도록 항상 작성하는 모든 내용을 최적화하려고 합니다.프로그램 속도를 높이는 한 가지 방법은 필요하지 않을 때는 해싱을 건너뛰는 것입니다.예를 들어 사용자 이름이 존재하지 않아 비밀번호를 확인할 필요가 없는 경우 사용자에게 즉시 응답할 수 있습니다.이렇게 하면 암호를 해싱하는 느린 계산 과정을 건너뛸 수 있습니다.사용자 이름이 정확하면 암호 입력을 해시하고 저장된 해시와 비교합니다.

이 시점에서 문제가 발생할 수 있는 부분이 어디인지 짐작하셨을 것입니다.실제로는 해싱이 몇 밀리초밖에 걸리지 않지만 해커는 이렇게 추가된 지연 시간을 이용해 자신이 입력한 사용자 이름이 정확한지 아닌지를 알아낼 수 있습니다. 잘못된 사용자 이름은 해싱이 수행되지 않았기 때문에 응답 속도가 약간 빨라지기 때문입니다.이러한 유형의 부채널 공격을 타이밍 공격이라고 하는데, 이는 서로 다른 비기능적 요구 사항이 서로 어떻게 대응할 수 있는지를 보여주는 좋은 예입니다.때로는 코드의 속도와 보안을 동시에 유지할 수 없습니다.

따라서 암호가 완벽하게 처리되고 표시되는 메시지가 일반적이며 암호나 사용자 이름이 올바르지 않은지 여부를 알려주지 않더라도 시스템은 여전히 취약합니다.해결책은 간단합니다. 항상 암호를 해시하거나 해시하는 데 걸리는 시간만큼 답장 전송을 지연시키십시오.

공격자는 획득한 정보를 사용하여 시스템의 사용자 목록을 얻을 수 있습니다.이 정보는 무차별 대입 공격 또는 기본 사용자 이름/암호 공격 등을 통해 웹 애플리케이션을 공격하는 데 사용될 수 있습니다.

https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)

개발자 보안 기술의 중요성은 2022년 Gartner 소프트웨어 엔지니어링 분야의 쿨 벤더 (Cool Vendors) 에서 강조되었습니다. 여기에서 전체 보고서를 읽어보세요.

시큐어 코드 워리어는 네 가지 중 하나로 인정받았습니다. '소프트웨어 엔지니어링의 멋진 공급업체: 개발자 생산성 향상', 가트너 지음.Gartner에 따르면 “쿨 벤더의 정의는 혁신적이고 영향력이 있거나 흥미로운 기술 또는 서비스를 제공하는 소규모 회사”입니다.쿨 벤더의 세 가지 요소는 다음과 같습니다.

혁신적 — 사용자가 이전에는 할 수 없었던 작업을 수행할 수 있습니다.

영향력 있는 — 기술 자체뿐만 아니라 비즈니스에 영향을 미쳤거나 영향을 미칠 것입니다.

흥미롭다 — 지난 6개월 동안 Gartner의 관심을 끌었습니다.

보고서에 요약된 바와 같이, “소프트웨어 엔지니어는 복잡한 코드 환경을 탐색하고 생산성을 유지하면서 구축하는 시스템의 보안을 개선하는 데 어려움을 겪고 있습니다.이 멋진 공급업체는 소프트웨어 엔지니어링 리더가 개발자 생산성을 높이고 보안 위험을 완화하는 데 도움이 되는 혁신적인 솔루션을 제공합니다.”

상장 기업으로는 유일하게 개발자 중심 보안에 초점을 맞추고 있습니다. 이러한 표창은 개발자들이 올바른 보안 기술과 상황에 맞는 도구를 갖추고 기술을 빠르게 학습, 구축 및 적용하여 보안 코드를 빠르게 제공하여 소프트웨어 보안 개선을 위한 보안 코드를 빠르게 제공할 수 있도록 하는 당사의 전략에 대한 증거입니다.

좌익 전환의 장점은 한동안 찬사를 받았지만 많은 조직은 여전히 소프트웨어 개발 라이프사이클의 시작 단계에서 보안을 고려하기 위해 고군분투하고 있습니다.당사의 최근 '개발자 주도 보안 설문조사 현황' 보안 코딩 방식을 채택할 때 극복해야 할 가장 큰 장애물은 시간 부족이라고 강조했으며, 이는 최근 Gartner 보고서에도 반영되어 있습니다.숙련된 엔지니어가 크게 부족하고 방대하고 복잡한 코드 리포지토리와 오픈 소스 소프트웨어로 구성된 런타임 스택의 절반 이상이 결합되어 개발자들은 기존 코드를 유지 관리할 시간이 거의 없습니다. 보안을 보장해도 상관없습니다.

Secure Code Warrior의 솔루션은 소프트웨어 보안을 보장하는 동시에 생산성을 향상시켜야 할 필요성에 의해 주도됩니다.앞서 언급한 설문조사에서 보안 코딩 방식을 채택할 시간이 부족하다고 언급했음에도 응답자의 76% 는 보안 코딩에 대한 좋은 교육이 실제로 가능하다는 데 동의했습니다. 생산성 향상 보안 티켓이 적고 관리 작업이 재작업도 필요하죠.적절한 보안 기술과 도구를 갖추면 개발자 팀은 위험을 쉽게 완화하고 혁신적인 특징과 기능을 갖춘 안전하고 우수한 코드를 신속하게 출시할 수 있습니다.

Secure Code Warrior뿐만 아니라 보안 기술을 갖춘 개발자가 사이버 보안에서 수행할 수 있는 중요한 역할을 강조해 주신 Gartner에 감사드립니다.
‍

액세스 소프트웨어 엔지니어링 분야의 Gartner 우수 공급업체: 개발자 생산성 향상 지금 신고하세요.

‍