[$] The first half of the 6.7 merge window

Post Syndicated from corbet original https://lwn.net/Articles/949294/

As of this writing, 9,842 non-merge changesets have found their way into
the mainline repository since the 6.7 merge window opened. Nearly a third
of those consist of the entire bcachefs development history but, even
discounting that, there has been a lot of material landing for the next
release. Read on for a summary of the most interesting changes pulled so
far in this development cycle.

How to use chaos engineering in incident response

Post Syndicated from Kevin Low original https://aws.amazon.com/blogs/security/how-to-use-chaos-engineering-in-incident-response/

Simulations, tests, and game days are critical parts of preparing and verifying incident response processes. Customers often face challenges getting started and building their incident response function as the applications they build become increasingly complex. In this post, we will introduce the concept of chaos engineering and how you can use it to accelerate your incident response preparation and testing processes.

Why chaos engineering?

Chaos engineering is a formalized approach that uses fault injection experiments to create real-world conditions needed to understand how your system will react to unknowns and build confidence in the system’s resiliency and security.

Modern applications can have multiple components, including web, API, application, and data persistence layers. To respond to potential security events, you must understand the failure scenarios across each component and their downstream impacts. One challenge is that creating incident response processes and playbooks for components in a silo doesn’t consider known unknowns—how these components interact with each other—and can’t reveal unknown unknowns such as second-order effects during a security event.

As an example, consider the personalization microservice shown in Figure 1.

The microservice relies on two Amazon Elastic Compute Cloud (Amazon EC2) instances that are deployed in an auto scaling group across two Availability Zones. An upstream data collection microservice sends data for the personalization microservice to process. In addition, a downstream website microservice takes the personalized data and displays it to customers.

Figure 1: Architecture of the personalization microservice

Figure 1: Architecture of the personalization microservice

Now imagine that unexpected activity occurred on an EC2 instance. The instance started to query a domain name that’s associated with cryptocurrency-related activity. A first set of unknowns already emerges:

  • Can your detective controls detect the activity on the instance?
  • How long do they take to do so?
  • How long does it take your security team to be notified?
  • Does the security team know what to do?
  • Does the notification have all the information that the team needs to respond?
  • Is there an existing automated response to other stakeholders?

Security professionals may not consider all of these questions when building and designing their threat detection and incident response capabilities.

In our example, Amazon GuardDuty is able to detect the unexpected activity and generates the CryptoCurrency:EC2/BitcoinTool.B!DNS finding within 15 minutes. The security team takes a snapshot for further forensics before the instance is isolated, as shown in Figure 2.

Figure 2: Architecture after GuardDuty detects unexpected activity and the security team isolates the EC2 instance

Figure 2: Architecture after GuardDuty detects unexpected activity and the security team isolates the EC2 instance

Although this might seem like an adequate response in isolation, it leads to more questions.

From a security perspective:

  • What other logs do we need for further investigation?
  • Do we know if the credentials need to be rotated and what impact that will have on the workload?
  • Should other parts of the system be replaced or restarted?

From an operational perspective:

  • Do any of the (manual or automated) incident response processes impact the performance of the workload?
  • Can the remaining instance handle the traffic before the auto scaling group creates another instance?
  • If there is increased latency or failure of the microservice, how will the data collection and website microservices react to it?

Creating detection and incident response plans in isolation doesn’t consider the second order effects that could have an impact on the integrity and availability of the system.

How can chaos engineering help?

Chaos engineering is a formalized process that can help solve this problem. It creates failure in a controlled environment with well-defined experiments to generate data on system behavior during a simulated event. You can use this data to improve incident response processes and make proactive changes that improve the security of your workloads. By using chaos engineering, developer and security teams can reveal additional unknowns and understand areas of opportunity to improve incident response processes and workload availability.

Chaos engineering has five phases—steady state, hypothesis, run experiment, verify, and improve—which we’ll discuss in more detail next.

Steady state 

The first phase involves an understanding of the behavior and configuration of the system under normal conditions. Instead of focusing on the internal attributes of the system, you should focus on an output metric or indicator that ties operational metrics and customer experience together. Including these output metrics in your hypothesis helps you collect data on security events and understand how these events and your response to them impact business outcomes.

Returning to our earlier example, this could be the latency when a user attempts to retrieve personalized information. This output is critical to the customer experience and relies on multiple operational metrics.

In addition, two key metrics in incident response are time to detect (TTD) and time to remediate (TTR). These metrics help capture how effectively your team has responded to the security event.

By defining your steady state, you can detect deviations from that state and determine if your system has fully returned to the known good state. You should identify the relevant metrics to measure your system and make these metrics simple for engineers to consume.

Using AWS, you can collect logs from the different services that you use in a workload, such as Amazon VPC Flow Logs, Amazon CloudWatch log groups, and AWS CloudTrail. For more details about the different log sources, see Logging strategies for security incident response.

Hypothesis

After you understand the steady state behavior, you can write a hypothesis about it. Security hypotheses can take the following form:

When _________ happens, ________ system will notify the team within _______ and the application’s metric _________ will remain at ________.

It can be challenging to decide what should happen. Chaos engineering recommends that you choose real-world events that are likely to occur and that will impact the user experience. Get your team to brainstorm. For security issues, this is an ideal time to use your threat model as the starting point for discussions. Starting with one of your identified threats and then running experiments based on that threat can help you test both your processes and automation.

After you’ve chosen your component, decide which variable to influence or what could happen in your complex system. For example, a misconfigured Amazon Simple Storage Service (Amazon S3) bucket or an open database port could lead to unintended exposure of customer data. A software flaw in your application could lead to the misuse of resources by an unauthorized user.

Here are a few examples of hypotheses:

  • If port 22 permits unrestricted access on a security group, AWS Config will detect it, run an automation to remove the security group rule, and notify the security team through Slack within 5 minutes, and the application’s latency will remain at 0.005 seconds.
  • If malware is run on an EC2 instance, Amazon GuardDuty will detect it within 15 minutes and notify the security team. Remediation playbooks will not affect the application’s error rate of 1 error for every thousand requests.

Design and run the experiment 

The next phase is to run the experiment. You don’t need to run experiments in production right away. A great place to get started with chaos engineering is the staging environment. One benefit of the AWS Cloud is that you can configure your staging environment to be identical to production. This increases the value of using an approach like chaos engineering before you get to production. By running experiments in staging, you can see how your system will likely react in production while earning trust within your organization.

As you gain confidence, you can begin running experiments in production. Because you configured staging to be identical to production, the risk of this transition is mitigated.

You can use AWS Fault Injection Simulator (FIS), our fully managed service for running fault injection experiments. FIS supports multiple fault injection actions, such as injecting API errors, restarting instances, running scripts on instances, disrupting network connectivity, and more. For the full list, see the FIS actions reference.

Although FIS doesn’t support security-related actions out of the box, you can use FIS to run AWS Systems Manager Automation documents that can run AWS APIs and scripts to simulate security events. To learn how to set up FIS to run a Systems Manager document that turns off bucket-level block public access for a randomly-selected S3 bucket, see the workshop Chaos Kitty – Gamifying Incident Response with Chaos Engineering. To learn how to set up FIS to run experiments that simulate events such as an RDP brute force event, lateral movement, cryptocurrency mining, and DNS data exfiltration, see the workshop Validating security guardrails with Chaos Engineering.

During this phase, you must understand the scope of impact of your experiment and work to minimize it. If an Amazon CloudWatch alarm goes into an alarm state, FIS can automatically stop the experiment. You should have a plan to return the environment to the steady state if the experiment has an unintended impact.

As you run your experiment, remember to document the key metrics and human responses, such as whether incident responders were confident, knew where to find the correct resources, or were aware of the escalation points.

Learn and verify 

The next step is to analyze and document the data to understand what happened. Lessons learned during the experiment are critical and should promote a culture of support instead of blame.

Here are some questions that you should address:

  1. What happened?
  2. What was the impact on our customers?
  3. What did we learn? Did we have enough information in the notification to investigate?
  4. What could have reduced our time to detect or time to remediate by 50 percent?
  5. Can we apply this to other similar systems?
  6. How can we improve our incident response processes?
  7. What human steps in the process can we automate?

Here are a few examples of things you might learn from your chaos engineering experiments:

  • After port 22 was opened, AWS Config detected the misconfigured security group within 2 minutes. However, the notification system was misconfigured, and the security team wasn’t notified. During the five minutes that port 22 was opened, the EC2 instance received 22 attempts to connect to it from unknown IP addresses.
  • After a cryptocurrency mining script was run on an EC2 instance, GuardDuty detected the activity, generated a finding within 10 minutes, and notified the security team.
  • The security team’s remediation actions—terminating the instance—led to increased application latency beyond the SLA of 0.05 seconds.

Improve and fix it

Use your learnings to improve the workload. It’s vital that you get leadership alignment and support to prioritize the remediation of findings from chaos experiments or other testing scenarios. Examples include improving incident response playbooks, creating new forms of automation, or creating preventative controls to prevent the event from happening. For more guidance on playbooks, see these sample incident response playbooks and the workshop Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake.

Preparation is important in incident response. As you improve your processes, run more experiments to collect additional data and continue to iteratively improve. Automate chaos experiments on new environments or applications with minimal user traffic before directing the majority of traffic to it. As you use chaos engineering approaches to prepare incident response processes, your detection and incident response capabilities should improve.

Conclusion

It’s vital to be prepared when a security event happens. In this blog post, you learned about the five phases of chaos engineering—steady state, hypothesis, design and run the experiment, learn and verify, and improve and fix—and how you can use them to accelerate your incident response preparation and testing processes. For more information on chaos engineering, see the following resources. Choose a workload and run an experiment on it to verify and improve your incident response processes today.

Additional resources

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Kevin Low

Kevin Low

Kevin is a Security Solutions Architect who helps customers of all sizes across ASEAN build securely. He is passionate about integrating resilience and security and has a keen interest in chaos engineering. Outside of work, he loves spending time with his wife and dog, a poodle called Noodle.

New York Increases Cybersecurity Rules for Financial Companies

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/11/new-york-increases-cybersecurity-rules-for-financial-companies.html

Another example of a large and influential state doing things the federal government won’t:

Boards of directors, or other senior committees, are charged with overseeing cybersecurity risk management, and must retain an appropriate level of expertise to understand cyber issues, the rules say. Directors must sign off on cybersecurity programs, and ensure that any security program has “sufficient resources” to function.

In a new addition, companies now face significant requirements related to ransom payments. Regulated firms must now report any payment made to hackers within 24 hours of that payment.

За съзиданието са нужни идеи; разрухата не изисква план. Разговор с Георги Гаврилов

Post Syndicated from original https://www.toest.bg/za-suzidanieto-sa-nuzhni-idei-razruhata-ne-iziskva-plan/

За съзиданието са нужни идеи; разрухата не изисква план. Разговор с Георги Гаврилов

Георги Гаврилов е роден на 15 юни 1991 г. в София. Следва специалност „Физика“ в СУ „Св. Климент Охридски“, а след това и магистратура „Физика на ядрото и елементарните частици“. Автор е на четири стихосбирки и множество публикации в електронното списание за литература „Кръстопът“, „Литературен вестник“, списанията „Море“,„Страница“, „Жената днес“, „Ах, Мария“, „Лик“ и др. Съставител е на сборника „Поезия срещу войната“ (Scribens, 2022), включващ в благотворителна инициатива текстове на 101 автори от България и чужбина в помощ на бежанците от Украйна. Стихове на Георги Гаврилов са преведени на турски, арабски, бенгалски, испански, френски, немски, английски и др. Георги е един от основателите на „Хралупата – пространство за литература и култура“ в София и част от издателство Scribens.

Докато вече привършвахме това интервю, настъпи израелският 9/11. На фона на апокалиптичната (в известен смисъл) поезия в най-новата ти книга как би коментирал последните събития от света?

Като нов стар очакван абсурд. Естествено, че нападението на „Хамас“ е военно престъпление, естествено, че е терористичен акт, естествено, че и за тях, и за всички е ясно, че действия от този род не са и няма как да бъдат от полза за някакъв положителен край на Палестинския въпрос. Напротив, ситуацията е доведена до състояние: едните трябва да изчезнат – като хора, като нация, като население. Не смятам, че каквото и да е от това може да бъде наречено свещено, оправдано и за доброто на света или на част от него. Последствията, както и причиняващият ги акт са във вреда на мира, човешкото и съхраняването на малкото останало от изчерпаемите ни психически сили. Още повече, не виждам никакво припокриване на идеалите на тези крайни религиозни фракции с мисленето на глобалния и конструктивен човек. Пътят към разрешаване на проблемите между Израел и Палестина може да е труден, но със сигурност не е този.

Да се върнем обаче на повода за този разговор – новата ти книга „Последният Буенос Айрес“ (изд. „Знаци“, 2023), която е своеобразен поетичен „Произход на видовете“, библейска и еволюционна история. Усещането обаче е, че се връщаме назад по стъпките на Сътворението, към апокалипсиса на първичния мрак, към последните мигове преди изригването на Помпей. Това ли се случва и как всъщност си представяш този апокалипсис?

Както и повечето неща, за които говорим през идеята за „събитие“, апокалипсисът не е събитие, а процес. Изучаваме историята чрез дати, часове и моменти, но това е единствено защото нямаме друга възможност за обхват на случилото се.

Войната в Украйна не започна на 24 февруари 2022 г. – тогава армията на Руската федерация навлезе в територията на Украйна; войната не започна и през 2014 г., когато незаконно беше анексиран Крим – това са само последните жалони от един дълъг път към настоящето. Можем да връщаме още и още назад и сигурно никога няма да е достатъчно рано, за да кажем, че днешното не е било възможно да се случи.

Вероятно по същия начин трябва да разсъждаваме за апокалипсиса: когато той бъде медийно обявен, няма да е изненада – той отдавна ще се е развивал, ще е придобивал образ. Това е засегнато в книгата като тема. Изкривената ни представа за тези големи „събития“ ни поставя в роля на очакващи нещо, което се случва междувременно и постепенно и ние вече сме част от него, предстои да разберем какъв магнитуд ще достигне.

Заглавието и имената на циклите в книгата ни дават много конкретна топография. Защо точно Буенос Айрес?

Шеговитият ми отговор би бил: „Защото звучи добре.“ Разбира се, не това е причината да се спра точно на този град. Историята на името му е обяснена посредством циклите. Градът е основан във времена на епидемии от малария (лош въздух), когато европейците са търсили нови места, които да населят и където въздухът да е чист. Връзката на блатата и застоялите водоеми с болестта е била миризмата, не комарите.

Буенос Айрес [на испански означава „хубав въздух“ или „добри ветрове“ – б.р.] е надежда за свободно дишане, за ново начало. Подобни места стават все по-малко. Конкретиката е ползвана в чисто художествен смисъл. Заглавието е метафора за нашето търсене на глътка въздух далеч от пандемии, войни и пълно капитулиране на междучовешките отношения.

Ако светът продължава „поради своята недостатъчност“, както пишеш, то тогава в какво би се състояло осъществяването му?

За природата той е във всеки момент съвършен, даже за Вселената. Ние живеем в моментната крайна точка на времето, което прави всичко в хармония с големите закони. За човека – обратно – осъществяването на света е винаги в следващата крачка.

Човекът изобретява идеята за бъдеще, за което Вселената няма понятие. Най-горещата година в историята, най-голямото земетресение, най-унищожителната атомна бомба, най-великите сред най-великите спортисти, писатели, държавници – тази гладиаторска надпревара, дори боравеща с понякога ужасяващи понятия, съблазнява съвременника да преживее нещо, което не фигурира в учебниците. Храним се с концепцията за феномен, който да осмисли поне статистически живота ни. Понякога този глад е надълбоко, срамен, прикрит, но го има в гена на човека. Само че всеки, който брои и измерва, е обречен, защото числата нямат край.

 „създаден за седем дни/и разрушен за миг“. Убеден ли си, че разрушението винаги е много по-бързо и по-скоротечно от съзиданието?

Съзиданието винаги е по-трудно, енергоемко и неустойчиво от разрухата, която, затворена в собственото си осмисляне, не може да бъде съкрушена. Съзиданието няма право на грешна стъпка, разрухата няма грешна стъпка за себе си. Това е смисълът на тези редове; дори и протичайки като процес, разрушението се нуждае от един кълн, докато светът трябва неуморно да възобновява своите милиарди отделни крехки греди. Съзиданието започва от нищото, нужни са му идеи, концепции, проби, докато разрухата винаги работи с вече готовото и нейната задача не изисква план.

Какво ще пише на надгробния камък на нашето съвремие, на собственото ти поколение?

Надявам се, че още не знаем, защото това би значело, че сме приключили с работата, с дейността си; че стореното е достатъчно, а не мисля, че е така. Напротив – точно в тези години, до които сме се довели, е необходимо да забравим за покоя на надгробния камък, а нека следващото поколение ни даде своята оценка за щетите и постиженията. Освен това, ако мислим в такава посока, мислим в посока на самоувековечаване – първия и най-страшен признак на много предишни поколения, които очевидно са грешили в преценката си. По-важно ми изглежда преди това да видим надгробния паметник на диктатурите и на него да пише „Стига толкова“.

Как се постига вечност, как всъщност я разбираш?

Още едно понятие, изобретено от нас. В езика ни има доста такива, те нямат реални примери, нямат наблюдаеми дефиниции. Вечността е родена от нас, но не е наша и ако се постига, ще се постигне в наше отсъствие, наличието ни не може да доведе до трайност. В литературен смисъл вечността има друго предназначение, понякога можем частично да я изпитаме, като мостра на парфюм, но с условието, че този парфюм не е наличен по друг начин. За един ден стига, ароматът се задържа.

А как, по думите ти, се „пресолява рана“?

Солта в раната е болка. Пресолената манджа има вкус само на сол и на нищо друго от съставките си. Опитите да изстискаме максимално много мъка от нещо водят до обезчувствяване. Човекът е приспособимо същество и бързо свиква с нови „нули“ на толеранса си към едно или друго. Пресоляването на раната е промяна в тази „нула“, което всякога води до нуждата от по-големи дози от същото за постигане на същия ефект. Наблюдавахме го по време на пандемията от коронавирус, наблюдаваме го и по време на войната в Украйна. 10, 100, 1000 смъртни случая първия път стряскат, втория път стряскат по-малко, на десетия път са просто очакваната част от новинарската емисия.

Повтаря ли се, или се пренаписва историята? И ако мислим за нея литературно – графоман плагиат ли е човечеството?

Ако всички хора имаха едновременно усещането, че са част от човечеството, нищо от това нямаше да се случва. Само че нашата „мрежа“ е по-скоро съставена от пунктири, отколкото от непрекъснати нишки. „Невидимото“ човечество за всеки един индивид се превръща в абстракция, към която не може да се присъедини. Тогава самостоятелният живот приема функцията на стотици изминали поколения, без да е възприел непреживяното по друг начин, освен като мит. Ако съществуваше пълно препредаване на действителното отминало, мрежата може би щеше да бъде много по-добре свързана. Историята се рестартира с всяко новородено. Нямаме една история, имаме осем милиарда паралелни истории.

Какво е способно да отдели човека от грешките/греховете му?

Собственият му опит, страданието и любовта, образованието и семейната култура. Нищо не може да те застрахова срещу грешки или грехове, но много излишни трагедии биха били избегнати, ако в процеса на подрастване се наблегне на подобни човекооформящи теми. Семейната, училищната и университетската среда са от първостепенно значение. В това отношение ми се струва, че тоталитарните и диктаторските страни се възползват много повече от достъпа си до младежта, докато страни, които държат на демокрацията и свободата, неглижират (може би и от страх от изпадане в пропаганда) тези аспекти.

Имаш ред стихотворения за войната и насилието, като със сигурност поводът за тях идва именно от последния мащабен военен конфликт в Украйна…

Да. Огромна част от стихотворенията са написани в първите месеци след началото ѝ, с нетипична за мен честота. Почти всяка нощ пишех ново стихотворение. Така се събраха над 200 страници във файл, които впоследствие редуцирах и от които останаха включените в книгата. „Старите“ в нея са много малко.

Начинът, по който ми повлия тази война, беше с учудващ и за мен магнитуд. Смятам, че преживяваме особени години, които ще оформят среднодалечното бъдеще на света, и наследниците на днешния ден ще се връщат към тях дълго време. Такива периоди изискват участие и по примера от Втората световна война променят хода на много неща, включително на изкуството. Колкото и ужасно да звучи, то се мобилизира и се преоткрива най-добре по време на хуманитарни кризи и нечовешки събития, от което не бива да изпитваме задоволство, а просто да си свършим работата. Най-истинската е много черна.

За съзиданието са нужни идеи; разрухата не изисква план. Разговор с Георги Гаврилов
© Ренета Бакалова

 „обесването на владимир владимирович путин“ е най-конкретният ти текст: стъпките към края на този съвременен кървав диктатор (един от всички други, които са споменати по-дискретно). Така ли – от собствената си ръка – приключват всички диктатори? Самотата ли е техният неизбежен край? 

Самотата не е само краят им, самотата ги води към този край, който е напълно заслужен, и ако не бъдат съдени от по-висша от човешката инстанция, даже се разминават леко. Вова Путин вече виси на собствената си пъпна връв, обесен и отдавна приключен. Очевидно махалото на трупа му трябва да направи още няколко кръга, преди да бъде официално заменен от следващия противник на човешкото (в случай че властта не се смени коренно) или от някой, който може да изкара Русия от блатото, в което с известно самозадоволство се вкопава.

Душата на редовия путинист носи в себе си неуспешната болка, това е особен тип полудушевно състояние, което се опитва да достигне до болезненост, но от крайния резултат не може да извлече нито поука, нито позитив, нито градивен смисъл за така или иначе обмъглената представа за каквото и да било бъдеще, по-далечно от днес.

 Стихотворението „мезозой“ е реплика на тринайсета глава от „Коринтяни“. Достоевски противопоставя абстрактната любов към „човечеството“ и хората въобще на тази към конкретния един ближен, която е много по-трудна и трудоемка… Ако оставим настрана интимността, способни ли сме днес на тази любов (питам и във връзка с раздвоените ни реакции към войната в Украйна и не само)? 

Способни сме на същото, на което сме били и преди тази война, и преди този век, и преди каквото е в тефтерите ни. Както интимната, така и общочовешката любов са състояния – не можеш да поддържаш в пълен интензитет нито едно от двете. Шансът на човека е в това, че рядко трябва да се проявява като човек. Истинските работни часове са много малко в рамките на един секулум.

Ако „свободата ни не е спасение“, къде тогава го виждаш?

Свободата съблазнява по много начини, без да обещава нищо, освен своята абстрактна дашност. Няма как това да бъде крайната точка в търсенето на спасение. Не и в християнския смисъл. Интересно е, че със забързването на всички процеси в света и със забързването на самия свят, много подобни въпроси започват да получават повече моментен, отколкото окончателен отговор. Някак константата се превръща в променлива и вероятно това е, което трябва да срещне нашето поколение във философски план. Фрагментизиране на смисъла. Бърза храна, бърза любов, бързо спасение. Нощувка и после отново същото.

и може би всичко
вече е казано
но не
за последен път

Накратко, можем ли да приемем това като най-лаконичното определение за литературния двигател?

 Да.

Ти самият си двигателят зад групата scribens/ARS, които издават едни от най-сериозните български гласове в поезията, докато твоите текстове излизат в друго издателство. Способен ли си да се отстраниш от самия себе си като поет, от собствената си стилистика, когато правиш подбор на новите ръкописи – или напротив, търсиш сродното, подобното? 

Нямам проблем да се отстраня от собствената си поетика, за да оценя чуждата. Мисля, че „витрината“ ни го доказва и го доказва с всяка следваща публикувана книга. Аз самият имам четири книги с поезия и те са напълно различни една от друга, всеки път ми е интересно да търся нови подходи и концепции, мога да слушам бритпоп или рап, а в следващия момент – класическа музика. С поезията е същото.

3 сутринта е часът, който се споменава непрекъснато в книгата. Какво ще се случи тогава?

3 сутринта е символ на времето, когато не би трябвало нищо да се променя. Лично аз винаги съм го възприемал като момент, в който светът спи, хората спят – добри, лоши, всякакви, – просто спят, денят е свършил, новините са се изчерпали и няма нищо повече. Ето това изгубено спокойствие на 3 сутринта ми липсва от известно време насам. Вече нямаме „час на нищото“ и това е изнервящо.

Обичам да будувам в 3 сутринта, да пуша и да знам, че всички глупаци, всички изроди и нещастници хъркат в този момент, но също така и всички други обикновени и необикновени, великолепни и съвършени същества са се оттеглили за няколко часа в леглата си и няма нищо друго и никой друг, който да промени нещо, преди слънцето да поднови играта. Това обаче вече не съществува.

Touring the Intel AI Playground – Inside the Intel Developer Cloud

Post Syndicated from Patrick Kennedy original https://www.servethehome.com/touring-the-intel-ai-playground-inside-the-intel-developer-cloud/

We tour Intel’s AI playground as we get inside the Intel Developer Cloud’s Oregon location to show hardware being made available to developers

The post Touring the Intel AI Playground – Inside the Intel Developer Cloud appeared first on ServeTheHome.

Approaches for migrating users to Amazon Cognito user pools

Post Syndicated from Edward Sun original https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools/

Update: An earlier version of this post was published on September 14, 2017, on the Front-End Web and Mobile Blog.

Amazon Cognito user pools offer a fully managed OpenID Connect (OIDC) identity provider so you can quickly add authentication and control access to your mobile app or web application. User pools scale to millions of users and add layers of additional features for security, identity federation, app integration, and customization of the user experience. Amazon Cognito is available in regions around the globe, processing over 100 billion authentications each month. You can take advantage of security features when using user pools in Cognito, such as email and phone number verification, multi-factor authentication, and advanced security features, such as compromised credentials detection, and adaptive authentications.

Many customers ask about the best way to migrate their existing users to Amazon Cognito user pools. In this blog post, we describe several different recommended approaches and provide step-by-step instructions on how to implement them.

Key considerations

The main consideration when migrating users across identity providers is maintaining a consistent end-user experience. Ideally, users can continue to use their existing passwords so that their experience is seamless. However, security best practices dictate that passwords should never be stored directly as cleartext in a user store. Instead, passwords are used to compute cryptographic hashes and verifiers that can later be used to verify submitted passwords. This means that you cannot securely export passwords in cleartext form from an existing user store and import them into a Cognito user pool. You might ask your users to choose a new password during the migration. Or, if you want to retain the existing passwords, you need to retain access to the existing hashes and verifiers, at least during the migration period.

A secondary consideration is the migration timeline. For example, do you need a faster migration timeline because your current identity store’s license is expiring? Or do you prefer a slow and steady migration because you are modernizing your current application, and it takes time to connect your existing systems to the new identity provider?

The following two methods define our recommended approaches for migrating existing users into a user pool:

  • Bulk user import – Export your existing users into a comma-separated (.csv) file, and then upload this .csv file to import users into a user pool. Your desired user attributes (except passwords) can be included and mapped to attributes in the target user pool. This approach requires users to reset their passwords when they sign in with Cognito. You can choose to migrate your existing user store entirely in a single import job or split users into multiple jobs for parallel or incremental processing.
  • Just-in-time user migration – Migrate users just in time into a Cognito user pool as they sign in to your mobile or web app. This approach allows users to retain their current passwords, because the migration process captures and verifies the password during the sign-in process, seamlessly migrating them to the Cognito user pool.

In the following sections, we describe the bulk user import and just-in-time user migration methods in more detail and then walk through the steps of each approach.

Bulk user import

You perform bulk import of users into an Amazon Cognito user pool by uploading a .csv file that contains user profile data, including usernames, email addresses, phone numbers, and other attributes. You can download a template .csv file for your user pool from Cognito, with a user schema structured in the template header.

Following is an example of performing bulk user import.

To create an import job

  1. Open the Cognito user pool console and select the target user pool for migration.
  2. On the Users tab, navigate to the Import users section, and choose Create import job.
    3. Figure 1: Create import job

    Figure 1: Create import job

  3. In the Create import job dialog box, download the template.csv file for user import.
  4. Export your existing user data from your existing user directory or store your data into the .csv file
  5. Match the user attribute types with column headings in the template. Each user must have an email address or a phone number that is marked as verified in the .csv file, in order to receive the password reset confirmation code.
    6. Figure 2: Configure import job

    Figure 2: Configure import job

  6. Go back to the Create import job dialog box (as shown in Figure 2) and do the following:
    1. Enter a Job name.
    2. Choose to Create a new IAM role or Use an existing IAM role. This role grants Amazon Cognito permission to write to Amazon CloudWatch Logs in your account, so that Cognito can provide logs for successful imports and errors for skipped or failed transactions.
    3. Upload the .csv file that you have prepared, and choose Create and start job.

Depending on the size of the .csv file, the job can run for minutes or hours, and you can follow the status from that same page in the Amazon Cognito console.

Figure 3: Check import job status

Figure 3: Check import job status

Cognito runs through the import job and imports users with a RESET_REQUIRED state. When users attempt to sign in, Cognito will return PasswordResetRequiredException from the sign-in API, and the app should direct the user into the ForgotPassword flow.

Figure 4: View imported user

Figure 4: View imported user

The bulk import approach can also be used continuously to incrementally import users. You can set up an Extract-Transform-Load (ETL) batch job process to extract incremental changes to your existing user directories, such as the new sign-ups on the existing systems before you switch over to a Cognito user pool. Your batch job will transform the changes into a .csv file to map user attribute schemas, and load the .csv file as a Cognito import job through the CreateUserImportJob CLI or SDK operation. Then start the import job through the StartUserImportJob CLI or SDK operation. For more information, see Importing users into user pools in the Amazon Cognito Developer Guide.

Just-in-time user migration

The just-in-time (JIT) user migration method involves first attempting to sign in the user through the Amazon Cognito user pool. Then, if the user doesn’t exist in the Cognito user pool, Cognito calls your Migrate User Lambda trigger and sends the username and password to the Lambda trigger to sign the user in through the existing user store. If successful, the Migrate User Lambda trigger will also fetch user attributes and return them to Cognito. Then Cognito silently creates the user in the user pool with user attributes, as well as salts and password verifiers from the user-provided password. With the Migrate User Lambda trigger, your client app can start to use the Cognito user pool to sign in users who have already been migrated, and continue migrating users who are signing in for the first time towards the user pool. This just-in-time migration approach helps to create a seamless authentication experience for your users.

Cognito, by default, uses the USER_SRP_AUTH authentication flow with the Secure Remote Password (SRP) protocol. This flow doesn’t involve sending the password across the network, but rather allows the client to exchange a cryptographic proof with the Cognito service to prove the client’s knowledge of the password. For JIT user migration, Cognito needs to verify the username and password against the existing user store. Therefore, you need to enable a different Cognito authentication flow. You can choose to use either the USER_PASSWORD_AUTH flow for client-side authentication or the ADMIN_USER_PASSWORD_AUTH flow for server-side authentication. This will allow the password to be sent to Cognito over an encrypted TLS connection, and allow Cognito to pass the information to the Lambda function to perform user authentication against the original user store.

This JIT approach might not be compatible with existing identity providers that have multi-factor authentication (MFA) enabled, because the Lambda function cannot support multiple rounds of challenges. If the existing identity provider requires MFA, you might consider the alternative JIT migration approach discussed later in this blog post.

Figure 5 illustrates the steps for the JIT sign-in flow. The mobile or web app first tries to sign in the user in the user pool. If the user isn’t already in the user pool, Cognito handles user authentication and invokes the Migrate User Lambda trigger to migrate the user. This flow keeps the logic in the app simple and allows the app to use the Amazon Cognito SDK to sign in users in the standard way. The migration logic takes place in the Lambda function in the backend.

Figure 5: JIT migration user authentication flow

Figure 5: JIT migration user authentication flow

The flow in Figure 5 starts in the mobile or web app, which attempts to sign in the user by using the AWS SDK. If the user doesn’t exist in the user pool, the migration attempt starts. Cognito calls the Migrate User Lambda trigger with triggerSource set to UserMigration_Authentication, and passes the user’s username and password in the request in order to attempt to migrate the user.

This approach also works in the forgot password flow shown in Figure 6, where the user has forgotten their password and hasn’t been migrated yet. In this case, once the user makes a “Forgot Password” request, your mobile or web app will send a forgot password request to Cognito. Cognito invokes your Migrate User Lambda trigger with triggerSource set to UserMigration_ForgotPassword, and passes the username in the request in order to attempt user lookup, migrate the user profile, and facilitate the password reset process.

Figure 6: JIT migration forgot password flow

Figure 6: JIT migration forgot password flow

Just-in-time user migration sample code

In this section, we show sample source codes for a Migrate User Lambda trigger overall structure. We will fill in the commented sections with additional code, shown later in the section. When you set up your own Lambda function, configure a Lambda execution role to grant permissions for CloudWatch logs.

const handler = async (event) => {
    if (event.triggerSource == "UserMigration_Authentication") {
        //***********************************************************************
        // Attempt to sign in the user or verify the password with existing identity store
        // (shown in the Section A – Migrate User of this post)
        //***********************************************************************
    }
    else if (event.triggerSource == "UserMigration_ForgotPassword") {
       //***********************************************************************
       // Attempt to look up the user in your existing identity store
       // (shown in the section B – Forget Password of this post)
       //***********************************************************************
    }
    return event;
};
export { handler };

In the migration flow, the Lambda trigger will sign in the user and verify the user’s password in the existing user store. That may involve a sign-in attempt against your existing user store or a check of the password against a stored hash. You need to customize this step based on your existing setup. You can also create a function to fetch user attributes that you want to migrate. If your existing user store conforms to the OIDC specification, you can parse the ID Token claims to retrieve the user’s attributes. The following example shows how to set the username and attributes for the migrated user.

// Section A – Migrate User
if (event.triggerSource == "UserMigration_Authentication") {
// Attempt to sign in the user or verify the password with the existing user store.
// Add an authenticateUser() functionbased on your existing user store setup. 
    const user = await authenticateUser(event.userName, event.request.password);
    if (user) {
        // Migrating user attributes from the source user store. You can migrate additional attributes as needed.
        event.response.userAttributes = {
            // Setting username and email address
            username: event.userName,
            email: user.emailAddress,
            email_verified: "true",
        };
        // Setting user status to CONFIRMED to autoconfirm users so they can sign in to the user pool
        event.response.finalUserStatus = "CONFIRMED";
        // Setting messageAction to SUPPRESS to decline to send the welcome message that Cognito usually sends to new users
        event.response.messageAction = "SUPPRESS";
        }
    }

The user is now migrated from the existing user store to the user pool, as well as the user’s attributes. Users will also be redirected to your application with the authorization code or JSON Web Tokens, depending on the OAuth 2.0 grant types you configured in the user pool.

Let’s look at the forgot password flow. Your Lambda function calls the existing user store and migrates other attributes in the user’s profile first, and then Lambda sets user attributes in the response to the Cognito user pool. Cognito initiates the ForgotPassword flow and sends a confirmation code to the user to confirm the password reset process. The user needs to have a verified email address or phone number migrated from the existing user store to receive the forgot password confirmation code. The following sample code demonstrates how to complete the ForgotPassword flow.

// Section B – Forgot Password
else if (event.triggerSource == "UserMigration_ForgotPassword") {
        // Look up the user in your existing user store service.  
		// Add a lookupUser() function based on your existing user store setup. 
        const lookupResult = await lookupUser(event.userName);
        if (lookupResult) {
            // Setting user attributes from the source user store
            event.response.userAttributes = {
                username: event.userName,
                // Required to set verified communication to receive password recovery code
                email: lookupResult.emailAddress,
                email_verified: "true",
            };
            event.response.finalUserStatus = "RESET_REQUIRED";
            event.response.messageAction = "SUPPRESS";
        }
    }

Just-in-time user migration – alternative approach

Using the Migrate User Lambda trigger, we showed the JIT migration approach where the app switches to use the Cognito user pool at the beginning of the migration period, to interface with the user for signing in and migrating them from the existing user store. An alternative JIT approach is to maintain the existing systems and user store, but to silently create each user in the Cognito user pool in a backend process as users sign in, then switch over to use Cognito after enough users have been migrated.

Figure 7: JIT migration alternative approach with backend process

Figure 7: JIT migration alternative approach with backend process

Figure 7 shows this alternative approach in depth. When an end user signs in successfully in your mobile or web app, the backend migration process is initiated. This backend process first calls the Cognito admin API operation, AdminCreateUser, to create users and map user attributes in the destination user pool. The user will be created with a temporary password and be placed in FORCE_CHANGE_PASSWORD status. If you capture the user password during the sign-in process, you can also migrate the password by setting it permanently for the newly created user in the Cognito user pool using the AdminSetUserPassword API operation. This operation will also set the user status to CONFIRMED to allow the user to sign in to Cognito using the existing password.

Following is a code example for the AdminCreateUser function using the AWS SDK for JavaScript.

var params = {
    MessageAction: "SUPPRESS",
    UserAttributes: [{
        Name: "name",
        Value: "Nikki Wolf"
    },
    {
        Name: "email",
        Value: "[email protected]"
    },
    {
        Name: "email_verified",
        Value: "True"
    }
    ],
    UserPoolId: "us-east-1_EXAMPLE",
    Username: "nikki_wolf"
};
const cognito = new CognitoIdentityProviderClient();
const createUserCommand  = new AdminCreateUserCommand(params);
await cognito.send (createUserCommand);

The following is a code example for the AdminSetUserPassword function.

var params = {
    UserPoolId: 'us-east-1_EXAMPLE' ,
    Username: 'nikki_wolf' ,
    Password: 'ExamplePassword1$' ,
    Permanent: true
};
const cognito = new CognitoIdentityProviderClient();
const setUserPasswordCommand = new AdminSetUserPasswordCommand(params);
await cognito.send(setUserPasswordCommand);

This alternative approach does not require the app to update its authentication codebase until a majority of users are migrated, but you need to propagate user attribute changes and new user signups from the existing systems to Cognito. If you are capturing and migrating passwords, you should also build a similar logic to capture password changes in existing systems and set the new password in the user pool to keep it synchronized until you perform a full switchover from the existing identity store to the Cognito user pool.

Summary and best practices

In this post, we described our two recommended approaches for migrating users into an Amazon Cognito user pool. You can decide which approach is best suited for your use case. The bulk method is simpler to implement, but it doesn’t preserve user passwords like the just-in-time migration does. The just-in-time migration is transparent to users and mitigates the potential attrition of users that can occur when users need to reset their passwords.

You could also consider a hybrid approach, where you first apply JIT migration as users are actively signing in to your app, and perform bulk import for the remaining less-active users. This hybrid approach helps provide a good experience for your active user communities, while being able to decommission existing user stores in a manageable timeline because you don’t need to wait for every user to sign in and be migrated through JIT migration.

We hope you can use these explanations and code samples to set up the most suitable approach for your migration project.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.

Want more AWS Security news? Follow us on Twitter.

Edward Sun

Edward Sun

Edward is a Security Specialist Solutions Architect focused on identity and access management. He loves helping customers throughout their cloud transformation journey with architecture design, security best practices, migration, and cost optimizations. Outside of work, Edward enjoys hiking, golfing, and cheering for his alma mater, the Georgia Bulldogs.

Orchestrating dependent file uploads with AWS Step Functions

Post Syndicated from Benjamin Smith original https://aws.amazon.com/blogs/compute/orchestrating-dependent-file-uploads-with-aws-step-functions/

This post is written by Nelson Assis, Enterprise Support Lead, Serverless and Jevon Liburd, Technical Account Manager, Serverless

Amazon S3 is an object storage service that many customers use for file storage. With the use of Amazon S3 Event Notifications or Amazon EventBridge customers can create workloads with event-driven architecture (EDA). This architecture responds to events produced when changes occur to objects in S3 buckets.

EDA involves asynchronous communication between system components. This serves to decouple the components allowing each component to be autonomous.

Some scenarios may introduce coupling in the architecture due to dependency between events. This blog post presents a common example of this coupling and how it can be handled using AWS Step Functions.

Overview

In this example, an organization has two distributed autonomous teams, the Sales team and the Warehouse team. Each team is responsible for uploading a monthly data file to an S3 bucket so it can be processed.

The files generate events when they are uploaded, initiating downstream processes. The processing of the Warehouse file cleans the data and joins it with data from the Shipping team. The processing of the Sales file correlates the data with the combined Warehouse and Shipping data. This enables analysts to perform forecasting and gain other insights.

For this correlation to happen, the Warehouse file must be processed before the Sales file. As the two teams are autonomous, there is no coordination among the teams. This means that the files can be uploaded at any time with no assurance that the Warehouse file is processed before the Sales file.

For scenarios like these, the Aggregator pattern can be used. The pattern collects and stores the events, and triggers a new event based on the combined events. In the described scenario, the combined events are the processed Warehouse file and the uploaded Sales file.

The requirements of the aggregator pattern are:

  1. Correlation – A way to group the related events. This is fulfilled by a unique identifier in the file name.
  2. Event aggregator – A stateful store for the events.
  3. Completion check and trigger – A condition when the combined events have been received and a way to publish the resulting event.

Architecture overview

The architecture uses the following AWS services:

  1. File upload: The Sales and Warehouse teams upload their respective files to S3.
  2. EventBridge: The ObjectCreated event is sent to EventBridge where there is a rule with a target of the main workflow.
  3. Main state machine: This state machine orchestrates the aggregator operations and the processing of the files. It encapsulates the workflows for each file to separate the aggregator logic from the files’ workflow logic.
  4. File parser and correlation: The business logic to identify the file and its type is run in this Lambda function.
  5. Stateful store: A DynamoDB table stores information about the file such as the name, type, and processing status. The state machine reads from and writes to the DynamoDB table. Task tokens are also stored in this table.
  6. File processing: Depending on the file type and any pre-conditions, state machines corresponding to the file type are run. These state machines contain the logic to process the specific file.
  7. Task Token & Callback: The task token is generated when the dependent file tries to be processed before the independent file. The Step Functions “Wait for a Callback” pattern continues the execution of the dependent file after the independent file is processed.

Walkthrough

You need the following prerequisites:

  • AWS CLI and AWS SAM CLI installed.
  • An AWS account.
  • Sufficient permissions to manage the AWS resources.
  • Git installed.

To deploy the example, follow the instructions in the GitHub repo.

This walkthrough shows what happens if the dependent file (Sales file) is uploaded before the independent one (Warehouse file).

  1. The workflow starts with the uploading of the Sales file to the dedicated Sales S3 bucket. The example uses separate S3 buckets for the two files as it assumes that the Sales and Warehouse teams are distributed and autonomous. You can find sample files in the code repository.
  2. Uploading the file to S3 sends an event to EventBridge, which the aggregator state machine acts on. The event pattern used in the EventBridge rule is: 
    {
  "detail-type": ["Object Created"],
  "source": ["aws.s3"],
  "detail": {
    "bucket": {
      "name": ["sales-mfu-eda-09092023", "warehouse-mfu-eda-09092023"]
    },
    "reason": ["PutObject"]
  }
}
  3. The aggregator state machine starts by invoking the file parser Lambda function. This function parses the file type and uses the identifier to correlate the files. In this example, the name of the file contains the file type and the correlation identifier (the year_month). To use other ways of representing the file type and correlation identifier, you can modify this function to parse that information.
  4. The next step in the state machine inserts a record for the event in the event aggregator DynamoDB table. The table has a composite primary key with the correlation identifier as the partition key and the file type as the sort key. The processing status of the file is tracked to give feedback on the state of the workflow.
  5. Based on the file type, the state machine determines which branch to follow. In the example, the Sales branch is run. The state machine tries to get the status of the (dependent) Warehouse file from DynamoDB using the correlation identifier. Using the result of this query, the state machine determines if the corresponding Warehouse file has already been processed.
  6. Since the Warehouse file is not processed yet, the waitForTaskToken integration pattern is used. The state machine waits at this step and creates a task token, which the external services use to trigger the state machine to continue its execution. The Sales record in the DynamoDB table is updated with the Task Token.
  7. Navigate to the S3 console and upload the sample Warehouse file to the Warehouse S3 bucket. This invokes a new instance of the Step Functions workflow, which flows through the other branch after the file type choice step. In this branch, the Warehouse state machine is run and the processing status of the file is updated in DynamoDB.

When the status of the Warehouse file is changed to “Completed”, the Warehouse state machine checks DynamoDB for a pending Sales file. If there is one, it retrieves the task token and calls the SendTaskSuccess method. This triggers the Sales state machine, which is in a waiting state to continue. The Sales state machine is started and the processing status is updated.

Conclusion

This blog post shows how to handle file dependencies in event driven architectures. You can customize the sample provided in the code repository for your own use case.

This solution is specific to file dependencies in event driven architectures. For more information on solving event dependencies and aggregators read the blog post: Moving to event-driven architectures with serverless event aggregators.

To learn more about event driven architectures, visit the event driven architecture section on Serverless Land.

Има ли право Палестина на литература?

Post Syndicated from Йоанна Елми original https://www.toest.bg/ima-li-pravo-palestina-na-literatura/

Има ли право Палестина на литература?

„Литпром“: диалог през литературата“, четем на едноименния сайт на германската асоциация на професионалисти в сферата на издателския бизнес, журналистиката, литературните науки и критиката.

Следващо съобщение, малко по-долу: 

Поради войната, започната от „Хамас“, причинила страдание на милиони израелци и палестинци, организаторът „Литпром“ реши да отмени церемонията по връчване на наградата „ЛиБературпрайс“ […] 

Носителката на въпросната награда? Адания Шибли, палестинска писателка, чиято дискусия в рамките на Франкфуртския панаир на книгата също бе отменена („Литпром“ се финансира частично от германското правителство, Франкфуртския панаир на книгата и други организации). 

Първото прессъобщение на „Литпром“ от 13 октомври гласеше, че авторката сама е изявила желание събитията да не се състоят. Но по-късно Шибли отрече и заяви, че ако възможността ѝ е била предоставена, е щяла да се възползва и да инициира разговор за ролята на литературата във време на жестокости и болка. Следват протестни писма от издателите на Шибли в САЩ и Великобритания, както и отворено писмо срещу решението, подписано от над 350 писатели, редактори, литературни агенти и издатели, сред които нобелистите Абдулразак Гурна, Ани Ерно и Олга Токарчук, авторите Колм Тойбин, Олга Равн и други.

След отмяната на събитията британският издател на Адания Шибли предостави книгата за свободно теглене в рамките на дните на Франкфуртския панаир

„Същият панаир, който отмени церемонията на Шибли, беше критикуван за включването на крайнодясното издателство Antaios, както и за гостуването на членове на „Алтернатива за Германия“ (AfD), написа в есе босненската писателка Лана Басташич. 

Докато артисти и писатели биват заглушавани заради предполагаем антисемитизъм, истинският неонацизъм се завръща с крайнодесните AfD, които печелят местни избори, a опитни политици обмислят варианти за сделки с тях.

Разговор за ролята на литературата и конфликта между Израел и Палестина нямаше. Но се появиха задължителните лагери „за“ и „против“, безпочвени обвинения в антисемитизъм, истински антисемитизъм, също толкова истинска омраза към палестинците… Решението на Франкфуртския панаир е още по-интересно в контекста на провелия се преди шест месеца Книжен панаир в Лайпциг, на който голямата награда получи руската писателка Мария Степанова (украинската общност, а и други протестираха това решение). Никой не сметна за нужно да „търси други формати“ за награждаването на Степанова, която не живее в Русия, но пише на руски и е рускиня. Необходима ли е отмяната на Шибли? И какви глобални тенденции биха могли да обяснят това решение? 

Кой се страхува от Адания Шибли? 

Родена в Палестина през 1974 г., Шибли живее между Йерусалим и Берлин, говори шест езика и е авторка на романи, пиеси, разкази и есета. Преподава философия и културология в Бирзейтския университет в Палестина.

Награденият ѝ в Германия роман Minor Detail („Незначителен детайл“*) не е преведен на български. Действието в него се развива през лятото на 1949-та, година след т.нар. Накба, или Палестинската катастрофа, когато са унищожени около 500 палестински села, а над 700 000 палестинци са принудени да напуснат домовете си. Катастрофата е следствие от сложни събития в контекста на Плана на ООН за разделяне на териториите на Палестина.

Има ли право Палестина на литература?
Адания Шибли в интервю с Арнон Грюнберг. Източник: YouTube

„Незначителен детайл“ се основава на истински случай – историята на млада бедуинка, изнасилена от израелски военни. Читателят прекарва няколко горещи дни през 1949 г. с войниците, които „прочистват“ пустинята от арабите. Другата сюжетна линия е в настоящето, където героиня на име Рамала търси исторически сведения за престъплението. Чрез двете линии пред читателя се разкрива абсурдният свят на болка без начало и край, без смисъл, неизбежна. Всъщност болката е такава, каквато е и в живия живот.

Да го пишем ли това (сега)? 

Адания Шибли не е маргинален глас, не е пропагандаторка, не поддържа терористи. Във Великобритания романът ѝ се издава от независимото издателство „Фицкаралдо“, чиито автори печелят Нобеловата награда вече няколко поредни години. През 2020 г. книгата е финалист за престижната американска Национална литературна награда, а през 2021 г. е в дългия списък за Международния „Букър“. Получава признание от критиците на New York Review of Books, Guardian, New York Times, Words Without Borders и редица други издания. 

Друг роман на Шибли разглежда събитията по време на Гражданската война в Ливан, свързани с убийствата на палестински бежанци и ливански шиити в Сабра и Шатила. Действието се развива през 1982 г. в Бейрут, тогава окупиран от Израел. Книгата We Are All Equally Far from Love („Всички сме еднакво далеч от любовта“) пък изследва ограниченията на живота под окупация, физическата и психическата клаустрофобия, емоционалната парализа. „Когато човек живее на място, което му се струва като наказание за неизвършено престъпление, от много ранна възраст започва да си задава трудни въпроси относно простички идеи като справедливост – или нейното отсъствие“, казва Шибли пред LitHub. 

Спомням си как два пъти ме разпитваха членове на израелското разузнаване, които искаха да знаят за какво пиша. Когато казах, че са истории за нещастна любов, те изгубиха всякакъв интерес към мен.

Няма книга, няма проблем 

Франкфуртският панаир на книгата е най-големият панаир по брой представени издатели. Смятан е за най-важният книжен панаир в света. Не е преувеличено да се каже, че това е литературен макет на света. Тази година „Литпром“ дава наградата на Шибли заради „безкомпромисно написаната ѝ творба, която разказва за силата на границите и за онова, което жестоките конфликти причиняват и правят с хората“. След 7 октомври обаче Израел, Палестина и светът осъмнаха различни. Адания Шибли ли е виновна за това? Справедливо ли е „наказанието“ нейният глас да бъде погълнат от взривовете на бомбите на „Хамас“ и Израел? 

Има ли право Палестина на литература?
Щандове на Франкфуртския панаир, снимка от 2016 г. Източник: Wikimedia

„Добрата литература ни показва сложността на живота, който не може да влезе в тесни идеологически рамки, било то леви или десни. И обратното – слабата литература следва идеологически схеми и не се различава особено от манифест“, коментира случая за „Тоест“ писателят и журналист Димитър Кенаров. 

Точно тук е и трагедията в днешно време – може би в което и да било време. Хората, които мислят по-сложно за живота (независимо дали се занимават с писане, или с нещо друго), не са особено популярни.

В есето си „Крахът“ от февруари 1936 г. Франсис Скот Фицджералд пише, че „проверка за един първокласен ум е умението едновременно да държиш в съзнанието си две противостоящи идеи и въпреки това да не изгубиш способността си да действаш“ (превод от английски Рада Шарланджиева). Всъщност „Крахът“ се занимава с разпадите – както големите исторически, така и вътрешните разпади. Двата процеса, разбира се, са взаимносвързани. 

А XXI в. е време на разпади: разпадат се обществата ни, демокрациите ни, способността ни да общуваме; пандемията разби на пух и прах увереността, че сме победили смъртта и че можем да предскажем бъдещето; разпадна се и идеята, че Студената война или която и да е война има еднозначен край… Разпада се и планетата. Какво друго във време на разпади, ако не литература, тоест разговор, съпреживяване? Пълната противоположност, разбира се – война. 

„Циничното възползване от ужасите, причинени от насилието на „Хамас“, за да се обявят всички палестински гласове за нелегитимни, е част от кампания за ограничаване на пространството за емпатия, мисъл, дебат и истина“, коментира журналистката Урсула Линдзи, покриваща теми, свързани с Близкия изток, в свое есе за Washington Post. Но тенденцията за „отмяна“ на литературата не принадлежи на Франкфурт. Тя е естествен рефлекс, придобит след поне десетилетие публична реактивност. 

В книгата си Professing Criticism: Essays on the Organization of Literary Study („Професия критик: есета върху организацията на литературната наука“) Джон Гилъри, американски литературен критик и професор в Нюйоркския университет, разглежда идеологическите борби и културните войни около литературния канон – например кои автори трябва да се четат и кои да се забранят, защото например от определена гледна точка са расисти, евгеници и т.н. 

В западните метрополиси борбата за многообразие в учебния план се оказа много по-лесна от реалното осигуряване на многообразие сред учениците и още по-лесна от налагането на многообразие в университетските среди и администрации. Западната „висока култура“ стана лесната битка на движението за деколонизация. 

Изливаме гнева си от неспособността да поправим несправедливостите и неравенствата в настоящето върху мъртвите автори, разсъждава Гилъри. Но ако литературата (на миналото), която не отговаря на нечии морални стандарти в настоящето, наистина бъде премахната, спряна от изучаване, забранена, заглушена – нима това няма да доведе до изкривена представа за историята, а оттам и за реалността? Не би ли се случило същото и с изтриването на палестинските, руските гласове? Не на онези, които насърчават насилието (тук не става въпрос за пропаганда, а за литература), а които изговарят травмите, довели до него, и то отвътре? 

„Тези, които проблематизират черно-белите идеологически модели (свобода–робство, цивилизация–варварство, Европа–Азия, Украйна–Русия, Израел–Палестина), се оказват в доста сложна ситуация. Никой не обича сложните неща“, смята и Кенаров. 

Към тази сложност се стреми Гилъри, който пише: 

Искаме студентите ни да се интересуват от другостта, включително от хора, които са различни от тях, но и нещо повече – искаме да се интересуват от цели светове другост и непреодолими различия. 

В американската среда, която влияе върху целия западен свят, амбицията на Гилъри и амбивалентността на Фицджералд са подложени на изпитание. Трудно е да се мисли сложно в свят на политика на идентичностите, където човек не е изграден от истории, а е еднолинеен сюжет, който се развива или не според определени критерии. И който може да бъде прекъснат, редактиран и дори изтрит от публичното пространство. Подобни тенденции се наблюдават както в левия, така и в десния политически спектър.

Има ли право Палестина на литература?
Снимка: Michael Dziedzic / Unsplash

Без литература няма разговор

Това не е експертен анализ по въпроса Израел–Палестина. Социалните мрежи превръщат привилиегированите да живеят далеч от света на жестоките конфликти, в които реална смърт застига истински хора, в кризисни запалянковци, заемащи една или друга страна, викащи за една или друга смърт, понякога единствено в името на това да бъдат чути гласовете им. Про- или антиваксър? Консервативен или либерален? Комунист или фашист? Русофил или русофоб? Кой заслужава да умре повече – палестинец или израелец? Страшно е, когато светът се преживява в бинарности. Страшно е и другото – когато изберем моралния релативизъм: в него няма зло, което да заслужава осъждане. 

Това е текст за литературата, която – когато е добра – помага да преодолеем всичко: политиката, хюбриса, пропагандата, говорещите глави, социалните мрежи и първосигналното, мненията, фоновия шум… За да се върнем към съществените, съвсем реални проблеми. Към човешкото. Защото ако сме способни да зачеркнем цели групи хора (а и тяхната литература, техния разговор), вече сме загубили частица от човечността си. Така се продължава и цикълът на жестокост. Литературата остава сред редките антидоти срещу тези отрови, както казва Милан Кундера.

Романът е пространство, в което моралното порицание временно се отменя. Тази отмяна не означава, че на романa му липсва морал; именно тя е неговата моралност. Моралността, която застава срещу неизкоренимия човешки навик да съдим светкавично, непрестанно и всички; да съдим, преди да сме разбрали, както и в отсъствието на разбиране. От гледната точка на мъдростта на романа тази трескава готовност да се съди е най-омразната глупост, най-гибелното зло. Не че романистът изцяло отрича, че моралната присъда е легитимна. Той просто отказва да я постави в романа. 

А че романът на Шибли е литература, която приканва към разговор, доказват множеството международни признания. Включително от хората, които „отмениха“ писателката. Именно заради тази отмяна, заради страха от нещо неопределено, нямахме шанс да чуем разговора за Израел–Палестина през литературата. Но предстоят няколко участия на Шибли, които може би ще ни дадат другите истории на Палестина – не на терора и вендетата; не на западняците, за които това е поредната криза, която ще преживеят в риалити формата на социалните мрежи и с която ще смажат стрелките на моралния си компас в съответните посоки, разбира се, на всеослушание; а на хората, които живеят тази история. Които са направени от тази история. Които единствени могат да я разкажат. И единствени имат силата да я променят.

Независимо дали авторите избират да говорят за определени събития, или да стоят встрани от тях, добрата литература се занимава с много просто нещо: животът (човешки, но не само) като основна ценност, казва Димитър Кенаров. „Литературата може да бъде всякаква, дори в най-ужасните моменти от историята. Важното е изкуството да бъде смело и свободно, независимо какъв подход или тема ще избере. Адорно казва, че не може да има поезия след Аушвиц, но всъщност поезия е имало и ще има винаги.“

В интервю за New York Times, публикувано ден преди завършването на този текст, израелският писател Едгар Керет каза някои от нещата, които изредихме и тук: за бинарния свят, за хляба и зрелищата, за болката, която е захапала опашката си. 

Преди доста време написах есе за New York Times, в което казах, че не харесвам етикетите „про-Израел“ или „про-Палестина“ […] Тоест ако си „про-Израел“, значи си за бомбардирането на деца в Газа? Идеята ми е, че реалността е сложна, и за мен най-важна е отговорността към човека. Когато виждам как хората гледат ужасната трагедия, разиграваща се тук, все едно е надпревара кой ще излезе по-голяма жертва, в която подкрепяш единия отбор и не ти пука за другия, емпатията става много, много избирателна. Виждаш само едната болка. Отказваш да видиш другата. 

Превърнала ли се е реалността в арената на Колизея? А социалните мрежи – в скамейките, от които осъждаме чуждите борби и решаваме кой е достоен да говори, да живее и кой не? Отменянето на легитимни гласове не разплита възлите в реалността, дори напротив. Защото в тази реалност хората не са аватари – те кървят, умират, губят близки, мразят и убиват съвсем наистина. Когато откажем да проведем трудния разговор, оставаме само с насилието. Защото времената на криза не търпят вакуум. Думи винаги трябват. Въпросът е кой говори. На кого позволяваме? От чие име? А как слушаме? От това зависи най-малкото дали ще останем хора.

*Всички преводи в текста са на авторката Йоанна Елми, освен там, където е изрично посочено друго.

The collective thoughts of the interwebz