One Article Review
| Source |  AlienVault Blog |
|---|---|
| Identifiant | 1197942 |
| Date de publication | 2019-07-10 13:00:00 (vue: 2019-07-10 17:00:41) |
| Titre | What is Chaos Engineering in penetration testing? |
| Texte |
Being proactive is the key to staying safe online, especially for businesses and organizations that operate websites and mobile applications. If you wait for threats to appear, then in most cases it is too late to defend against them. Many data breaches come about this way, with hackers uncovering security gaps that had gone previously undetected.
The average web developer wants to assume that their code and projects will always function in the intended manner. Reality is a lot messier than that and organizations need to expect the unexpected. For years, cybersecurity experts recommended a practice known as penetration testing (and still do), where internal users pose as hackers and look for exposed areas of servers, applications, and websites.
The next evolution of penetration testing is something that is known as Chaos Engineering. The theory is that the only way to keep online systems secure is by introducing random experiments to test overall stability. In this article, we'll dive more into Chaos Engineering and the ways it can be implemented effectively.
Origin of Chaos Engineering
The cloud computing movement has revolutionized the technology industry but also brought with it a larger degree of complexity. Gone are the days when companies would run a handful of Windows servers from their local office. Now organizations of all sizes are leveraging the power of the cloud by hosting their data, applications, and services in shared data centers.
Back in 2010, Netflix was one of the first businesses to build their entire product offering around a cloud-based infrastructure. They deployed their video streaming technology in data centers around the world in order to deliver content at a high speed and quality level. But what Netflix engineers realized was that they had little control over the back-end hardware they were using in the cloud. Thus, Chaos Engineering was born.
The first experiment that Netflix ran was called Chaos Monkey, and it had a simple purpose. The tool would randomly select a server node within the company's cloud platform and completely shut it down. The idea was to simulate the kind of random server failures that happen in real life. Netflix believed that the only way they could be prepared for hardware issues was to initiate some themselves.
Tools to use
IMAGE - [url=https://www.nagarro.com/hs-fs/hubfs/chaos-engineering.png?t=1533816015896&width=600&name=chaos-engineering.png]https://www.nagarro.com/hs-fs/hubfs/chaos-engineering.png?t=1533816015896&width=600&name=chaos-engineering.png[/url]
It's important not to rush into the practice of Chaos Engineering. If your experiments are not properly designed and planned, then the results can be disastrous and little helpful knowledge will be gained. Best practice is to nominate a small group of IT staff to lead the activities.
Every chaos experiment should begin with a hypothesis, where the team questions what might happen if their cloud-based platform experienced an issue or outage. Then a test should be designed with as small of a scope as possible in order to still provide helpful analysis.
One area where companies often need to focus their chaos experiments is in relation to |
| Envoyé | Oui |
| Condensat | /url 2010 able about activities activity add address against all also although always among amount analysis answer any anything appear application applications architects architecture architectures are area areas around article artificial assume assurance automate average avoiding back base based because before begin being believed benefits best better born bottlenecks bottom breaches break brought browser build businesses but called can cases centers challenging changes chaos chaotic client cloud code com/hs come comes companies company's completely complexity computing consequences content control could counterproductive countries crisis cyberattacks cybersecurity data days decision defend degree deliver dependencies deployed designed developer developers development differently disaster disastrous distributed dive done down drills due during effectively encrypts end engineering engineers entire environment environments especially even every everyday evolution example expect experienced experiment experimentation experiments experts exposed failure failures feasible fire firewall firm first focus from fs/hubfs/chaos function future gained gaps generally global goal goes gone good great group hackers had handful handle handling handy happen hardware has have heavy help helpful here high hosting how https://www human hypothesis idea identify image impact implemented important incident incoming industry inform information infrastructure initiate intelligence intended internal introducing issue issues it's its keep key kind knowledge known larger late latter lead learning level leveraging life likelihood limited limits line little live loads local location look looming lot machine made making manner many may messier might minimize mobile monitor monkey more most movement nagarro need negative negatively netflix network networking networks next node nominate not now offer offering office often one online only operate opportunity order organization organizations origin other outage outages outgoing over overall paired part participation penetration performance period philosophy piece planned planning platform png points pose possible potential power practice prepared previously private proactive problem process product production projects properly provide provided purpose push putting quality questions ran random randomly react real reality realized recommended recovery redundant regions relation require resources response result results revolutionized risk risks run running rush safe scaled scanning scope secure security see seem select server servers service services shared short should shut significant simple simply simulate sizes small smart software some something soon source speed stability staff stay staying streaming systems t=1533816015896&width=600&name=chaos team technology term test testing tests than that's them themselves then theoretical theory these thing threats thus time too tool tools traffic type typically uncover uncovering understand undetected unexpected unknown upfront url=https://www use useful users using value variables video virtual vital vpn vulnerabilities wait want wants way ways we'll weakness web website websites well what when where which who why will windows within without world would years your |
| Tags | Tool Guideline |
| Stories | |
| Notes | |
| 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.