One Article Review
| Source |  Cyber Skills |
|---|---|
| Identifiant | 8517443 |
| Date de publication | 2022-02-10 00:00:00 (vue: 2024-06-13 20:13:29) |
| Titre | Cyber Security & # 8211;Une guerre de Troie où nous gagnons Cyber Security – A Trojan War where we win |
| Texte | Written by Dr. Anila Mjeda, Cyber Skills Lecturer In Ancient Greek literature, Troy is portrayed as a powerful kingdom of the Heroic Age. Troy\'s ability to withstand battles and attacks was due to the strength of its walls which, legend has it, were built by Greek gods, Poseidon and Apollo. This was all the more evident when Troy \'fell\' after it\'s supposed, impenetrable outer perimeter, got breached. This lesson from Greek Mythology echoes ever true in today\'s software systems. Our Cyber Security mechanisms must be approached in a manner called \'Defence-in-depth”, where a number of defence mechanisms are layered to offer better protection to the system. (Imagine the medieval castles\' layers of fine battlements, towers, and \'high\' and \'steep\' walls.) What is most vital in Cyber Security, is the inner most layer of a strong, defence-in-depth. This layer should start with secure coding which is a concept we call \'Shifting Left\'. Shifting Left Shifting left, in essence means incorporating security at the beginning of a project, such as data collecting, and incorporating security activities in each of the stages of the software development lifecycle. The shifting left metaphor stems from the fact that people whose native language is written from left to right, tend to perceive left (think of the outmost left on a page) as the place where one begins their work. As a developer, will your application need to handle credit card data? Will the users of your application be allowed to upload their own files to the system, and which third-party components will you be using in the system? These are but a fraction of the security considerations to be analysed from the beginning of any project. Today\'s software systems are inherently interconnected, and we cannot simply draw up the bridge and defend our systems medieval style. Software systems use libraries, APIs, microservices and in general a variety of components that translate to an end-product. There are complex dependencies, many of which to third-party software. Furthermore, modern approaches such as Continuous Integration / Continuous Deployment (CI/CD) pipelines, Infrastructure as Code (IaC), Security as Code (SaC), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) push more functionality into the software domain. This blurring of the boundaries means that security is not the job of only the security professionals and calls for the development team to play a crucial role in it. Software developers are talented and inventive creators and as cyber-attacks increase in numbers and severity, it is vital they collaborate closely with the security professionals and get the proper training to interweave security into their creations. While proper training of developers is the real answer to prevent vulnerabilities creeping up into our apps, if I were to start from one element, it would be the mentality of Zero-Trust. While I do not recommend it as a mentality for life, I do very much recommend it in all thing\'s cybersecurity. The Zero-Trust concept extends from infrastructure to software. In fact, one aspect of our software which if we do right, would solve most of our security woes is zero-trusting all inputs. Zero-Trust Your Inputs Language purists might forgive this conversion of zero-trust into a verb, on the grounds that placing no trust on all inputs (even when they come from your own system), would help us mitigate most of our security troubles. You may be asking, “Why don\'t we just do it then, and “solve” security once and for all?”. Part of the difficulty relies on identifying every single input. Did we identify all the cloud workflows that can trigger our serverless functions? Are there any unforeseen ways into our database (Hello injection vulnerabilities)? Can an attacker give instructions to the server and resultantly gain access they should not have (Server-Side Request Forgery (SSRF) vulnerabilities)? Can our web-based system be commandeered to attack our legitimate users (Cross Site Scripting (XSS) v |
| Notes | ★★ |
| Envoyé | Oui |
| Condensat | ability about access activities additionally after age all allowed analysed ancient anila answer any apis apollo application approached approaches apps architecture are asking aspect attack attacker attacks based battlements battles beginning begins below: better blurring boundaries box breached bridge brief built but call called calls can cannot card castles certificate ci/cd closely cloud code coding collaborate collecting come commandeered complex components concept considerations continuous conversion courses creations creators credit creeping cross crucial cyber cybersecurity data database defence defend dependencies deployment depth depth” developer developers development did difficulty digital domain don draw due each echoes element encoding encourage end escaping essence even ever every evident explanations extends fact fallen fell files fine flexibly forgery forgive fraction from functionality functions furthermore gain general get give given gods good got greek grounds handle handling has have hello help heroic high iaas iac identify identifying imagine impenetrable incorporating increase industry infrastructure inherently injection inner input inputs instructions integration interconnected interweave inventive its job journey just kingdom language layer layered layers learn lecturer left legend legends legitimate lesson libraries life lifecycle literature long make manner many may means mechanisms medieval mentality metaphor microservices might mitigate mjeda modern more most much must mythology native need network not number numbers offer once one only open operations outer outmost output owasp own paas pace page part party pathways: people perceive perimeter pipelines place placing platform play port portrayed poseidon possible powerful prevent product professionals project proper protection purists push real recommend relies request resultantly right role sac scripting secure security server serverless service several severity shifting should side simply single site skill skills software solve ssrf stages standard start started starting steep stems strength strong strongly style such supposed system systems talented team tend text then these thing think third today towers training translate trigger trojan troubles troy true trust trusting unforeseen upload use users using validating validation variety verb very vital vulnerabilities walls war way ways web what when where which whitelisting whose will win withstand woes work workflows would written xss your zero “solve” “why |
| Tags | Vulnerability Cloud |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.