Coolest Projects Global 2022: Celebrating young tech creators & creative ideas

Post Syndicated from original https://www.raspberrypi.org/blog/coolest-projects-2022-celebration-favourites/

Congratulations to the thousands of creators from 46 countries who participated in Coolest Projects Global 2022. Their projects awed and inspired us. Yesterday STEM advocate and television host Fig O’Reilly helped us celebrate each and every one of these creators in our online event. Check out the gallery to see all the amazing projects.

During the celebration, Fig also revealed which projects were picked by the special judges as their favourites from among the 2092 projects in this year’s showcase gallery. Let’s meet the special judges and check out their picks!

Ruth Amos’s favourites

Ruth Amos is an inventor, entrepreneur, and EduTuber. She co-founded the #GirlsWithDrills movement and ‘Kids Invent Stuff’, a YouTube channel where 5- to 11-year-olds see their invention ideas become reality with the help of engineers.

Here are Ruth’s favourites:

  • The Hardware project Oura, made by Angelina and Catherine in the United States. Oura is an indoor air quality monitoring device that is tailorable, portable, and inexpensive. Ruth especially liked this project because she saw “[s]ome great prototyping and use of data.”
  • The Games project Egg Dog, made by Oakley and Alex from a Code Club in Australia. In the game, players explore for collectibles and fight off enemies as they try to find the exit for the next level. Ruth said that Egg Dog was a “[r]eally fun game, they obviously learnt a lot in the process of making the game.”
  • The Web project AllerG, made by Noah from a CoderDojo in the United States. AllerG is an accessible and crowdsourced database of menu allergens for people with food allergies. Ruth said, “The whole project was very well thought out”.
  • The Mobile Apps project EcoSnap, made by Uma and Bella in the United States. EcoSnap serves as an all-in-one toolkit for anyone hoping to help the environment. Ruth said, “You really thought about the user and changing perceptions.”
  • The Scratch project Trash-Collector, made by Rajan in the United Kingdom. In Rajan’s game, players take on the role of a scuba diver who needs to collect trash in the ocean. Ruth said, “I can’t wait to see more levels; it’s quite addictive!”
  • The Advanced Programming project Climate Change Detector, made by Arnav from a CoderDojo in India. The project is a data dashboard and platform to track pollution. Ruth said, “I love that you can change parameters and see the effect that would have.”

Shawn Brown’s favourites

Shawn Brown is an award-winning engineer, designer, and YouTuber. He’s also a practical pioneer for neurodiversity and innovation — raising awareness of learning differences and promoting science, engineering, and invention to young people. Together with Ruth, Shawn co-runs the YouTube channel ‘Kids Invent Stuff.’

Here are Shawn’s favourites:

  • The Hardware project Flow On the Go, made by Donal from a Code Club in the United Kingdom. Flow On the Go is a COVID-19 lateral flow test holder with a built-in camera that takes a picture of the test results after 15 minutes and sends a photo of the results via email. Shawn said, “I’ve absolutely been late for things before because I forgot to leave time to do a lateral flow test and your invention totally solves that problem in a really clever and effective way.”
  • The Games project Iron Defence, made by James in the United Kingdom. Iron Defence is a tower defence game where players defend against waves of enemies in a steampunk-themed assault. Shawn said, “Amazing work on seizing the opportunity to learn a new coding language”.
  • The Web project School Management System, made by Nebyu Daniel in Ethiopia. The project is a system used to store centralised data for a school. Shawn said, “The level of detail and the amount of different areas you’ve considered is really impressive!”
  • The Mobile Apps project RecyBuddy, made by Ryan in the United States. RecyBuddy is designed to assist and teach recycling to all ages. Shawn said, “I love how you’ve considered and implemented three distinct input options, giving the application a really high level of accessibility for users of a wide range of abilities and ages.”
  • The Scratch project Learning Is Fun, made by Mihir Ram in India. Mihir’s project is about making learning about science and the environment more enjoyable. Shawn said, “I got pretty addicted to playing Garbage Mania, and the timing was perfect to make it just stressful enough to have to think and grab the item in the right bin in time before you miss it!”
  • The Advanced Programming project Dog Smell Training Device, made by Roland in the United Kingdom. Roland’s project is designed to train dogs to identify different smells. Shawn said, “Well done on starting with achievable bitesize parts and then building it up from there”.

Richa Shrivastava’s favourites

Richa Shrivastava is the Director of Maker’s Asylum. It is India’s first community makerspace that fosters innovation through purpose-based learning, based on the United Nations Sustainable Development Goals.

Here are Richa’s favourites:

  • The Hardware project EleVoc, made by Chinmayi in India. Chinmayi’s device determines the proximity and behaviour of elephants by classifying their vocalisations. Richa said, “I personally loved the project because it addressed a problem statement that you do not see in cities but is common in villages and forest areas where humans and animals inhabit together.”
  • The Games project Runaway Nose, made by Harshit from a CoderDojo in Ireland. Harshit’s game uses facial recognition and players have to think (and act!) fast to score points. Richa said, “I have never played anything like this before and I can see that it can be really addictive.”
  • The Web project Our Planet, Our Impact, made by Amaury from a CoderDojo in Belgium. This multilingual website calculates the user’s environmental footprint. Richa chose this project because “the calculators were a really cool way to really bring out the impact of plastic waste that we create!”
  • The Mobile Apps project Watey, made by Yuuka, Akari, Otowa, and Lila from a CoderDojo in Japan. Watey helps families to save water easily and enjoyably. Richa said, “I loved the element of family bonding and competition that could motivate people to use water with scarcity.”
  • The Scratch project Nature’s Savior Bilgin, made by Çağatay and Mert from a Code Club in Turkey. It’s a game to teach players about the environment. Richa said, “I personally really loved the fact that the project was focussed on the environment and also problems that we see in real life almost every other day.”
  • The Advanced Programming project Jarvis, made by Siddhant in India. Jarvis is a personal assistant. Richa said, “I always wanted a personal Jarvis and this was so cool to see!” 

Elaine Atherton’s favourites

Elaine Atherton is Director of Scratch Education Collaborative. Elaine was first introduced to Scratch as an instructional coach while working with teachers in North Carolina. “It was amazing to see the kids so excited about what they were creating. I wanted to help them transfer that same energy to designing, making, and sharing other things, too — I wanted them to stretch their creativity.”

Here are Elaine’s favourites:

  • The Hardware project CubeSpeedee Timer, made by Tom from a CoderDojo in the United Kingdom. Tom’s project is a DIY timing device for solving puzzle cubes. Elaine said the project was “fun, playful, creative, and challenging!”
  • The Games project Ninjas, made by Jaiden and Eli from a Code Club in Australia. Ninjas is an open-world action-adventure game. Elaine said, “The transitions between the different worlds are really cool”.
  • The Web project Ubex Site Creator, made by Menagi from a Code Club in Romania. Ubex makes it easy for anyone to create their own website. Elaine said, “It is clear to see how you thought about how to use your passion for coding to create something for your peers.”
  • The Mobile Apps project Green Nature For You, made by Iana and Cristina in Moldova. The app lets users report when trash cans are full. Elaine said, “[Y]ou thoughtfully consider accessibility and access needs of those who may use it”.
  • The Scratch project Fun Relaxing Project, made by Konstantin from a CoderDojo in Bulgaria. Konstantin’s game is to help players relax while watching beautiful geometric shapes and colours. Elaine said, “The colors and patterns are truly relaxing”. 
  • The Advanced Programming project DeepFusion, made by Justin in the United States. DeepFusion is a web app that provides a graphical method for creating, training, and testing neural networks. Elaine said, “Your presentation is funny, thoughtful, and clever.”

Broadcom Coding with Commitment recognition

Broadcom Foundation has partnered with us for Coolest Projects Global to encourage young people who are solving problems that impact their communities. Their projects could relate to health, sanitation, energy, climate change, or other challenges set out in the United Nations Sustainable Development Goals. Broadcom Coding with Commitment illuminates how coding is a language, skill set, and invaluable tool for college and careers.

The Broadcom Coding with Commitment recognition goes to A Guide to Climate Change, a website created by Sabrina in the United Kingdom. Sabrina’s site not only provides vital information about the effects of climate change, but also gives users a visual to show how important it is to lower our carbon footprint. Congratulations to Sabrina for using her coding skills to give people a guide to understanding climate change in an easily digestible and stylish project webpage.

Sabrina’s project, A Guide to Climate Change

And there’s so much more to celebrate!

You can explore all the young tech creators’ projects — games, hardware builds, Scratch projects, mobile apps, websites, and more — in our showcase gallery now.

Find YOUR favourite project

All creators who are taking part this year can now log into their Coolest Projects accounts to:

  1. Find personalised feedback on their project
  2. Request their limited-edition Coolest Projects swag

The support of our Coolest Projects Global sponsors has enabled us to make this year’s online showcase the inspiring experience it is for the young people taking part. We want to say a big thank you to all of them!

The post Coolest Projects Global 2022: Celebrating young tech creators & creative ideas appeared first on Raspberry Pi.

4 Strategies to Help Your Cybersecurity Budget Work Harder

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/06/17/4-strategies-to-help-your-cybersecurity-budget-work-harder/

4 Strategies to Help Your Cybersecurity Budget Work Harder

The digital economy is being disrupted by data. An estimated 79 zettabytes of data was created and consumed in 2021— a staggering amount that is reshaping how we do business. But as the volume and value of data increases, so does the motivation for hackers to steal it. As such, cybersecurity is a growing concern for organisations across all industries, and budget requests are increasing as a result.

But if we’re spending more, why are organisations still getting hacked at an increasing rate?

In the first webinar of Cybersecurity Series: Hackers ‘re Gonna Hack, Jason Hart, Chief Technology Officer, EMEA, Rapid7, shared his experience on why executives need to reconsider their current operating model and ensure their cybersecurity budgets are working as hard as possible.

84% of our webinar audience agreed that doubling their cybersecurity budget would not halve the risk or impact for their business.

Cybersecurity departments are finding it extremely challenging to justify increases to their budget when they are not seen as directly contributing to revenue. There was also a time when cyber insurance was regarded as a safeguard and magic wand to protect us from risks. But now, these providers are placing more onus on organisations to ensure preventative measures are in place, including risk assessment, controls, and cybersecurity operations.

In an ever-evolving landscape, it is essential to take a step back and consider how you can improve your approach. The key question remains, “How do you do more with less?” You can’t protect everything – you need to understand what matters most and be able to manage, mitigate, and transfer risks by working with a range of stakeholders throughout your organisation. Here are four strategies that can help.

1. Embrace the evolution of profit and loss for cybersecurity

A profit-and-loss framework for cybersecurity enables organisations to identify their current level of risk, prioritise their efforts based on those risks, and then set benchmarks for improvements over time. The goal is to create an environment where you can proactively manage your cybersecurity risks rather than reactively mitigate them after they’ve occurred.

61% of our audience agreed they need to approach cybersecurity from a profit-and-loss perspective.

2. Become situation-aware

Awareness is the ability to look at all the information available, recognise what’s important, and act accordingly. It’s a skill that can be learned, practised, and improved over time.

You can’t fix what you don’t know, so it’s essential to have a clear understanding of the risks in your organisation and those that might arise in the future. We believe there are three levels of awareness:

  • Situation awareness: When an organisation understands the critical (people, data and process) and operational elements for executing information security strategy.
  • Situation ignorance: When organisations assume everything is OK without considering the impact of people, data, and processes. They may be implementing security control and awareness training, but there is no straightforward process. The strategy does not align to risk reduction and mitigation, and budgets continue to increase.
  • Situation arrogance: Organisations that continue to spend huge amounts of budget, while still getting compromised and breached. They might consider people, data, and process, but they fail to act.

57% of our audience believed they were situation-aware. 31% percent said they were situation-ignorant, and 11% felt their organisations were situation-arrogant.

Try to identify your organisation’s cyber maturity to make improvements. To test impact and likelihood, ask your peers – in the event of a breach, what data would you be most concerned about if hackers applied ransomware to it? To test risk versus control effectiveness, consider where that data is located. When understanding impact and level of risk, find out what business functions would be affected.

3. Adapt or become irrelevant

Cybersecurity operations should be tailored to your organisation’s unique needs; there’s no one-size-fits-all approach. The move away from traditional operation models to a more targeted one requires a strong foundation for transformation and change. This includes:

  • Culture
  • Process
  • Measurement
  • Resources
  • Accountability
  • Automation

Only 27% of our audience believed they have the foundations for a targeted operations model to carry over to cybersecurity.

4. Implement protection-level agreements

To eradicate and remove a critical vulnerability, you might need to reboot, consider patch management, or bring systems down. This can be hard to assign a value, but it will inevitably increase your budget.

For example, to reduce a critical vulnerability, the average annual cost for the business is £1 million per year. But what if we set up a protection-level agreement (PLA) so that any critical vulnerabilities are eradicated and managed within 30 days? That would reduce operational costs to approximately £250,000 per year.

But what if you are hacked on day 25? That isn’t not a control failure – it results from a business decision that has been agreed upon. PLAs enable you to track and monitor threat activity so the business and leadership team can understand why you were breached. The approach also highlights gaps in your foundation, enabling you to address them before they become serious problems. For example, it might highlight potential challenges in handoff, process, or accountability. Additionally, a PLA is a language your stakeholders understand.

Everyone is on the same journey

Each stakeholder in your organisation is at a different stage of their journey. They have different expectations about how cybersecurity will impact them or their department. They also have different levels of technical knowledge. When planning communications, consider these differences to get them on board with your vision, working with them to ensure everyone’s expectations can be met.

Register for Part 2 Cybersecurity: Hackers ‘re Gonna Hack to find out more about getting your executive team on board. Jason Hart, Chief Technology Officer, EMEA, Rapid7, will show you how to implement new ideas to build your target operating model to drive effectiveness and change.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Неразрушимо полифоничните Балкани. Разговор с Капка Касабова

Post Syndicated from Джорджа Спадони original https://toest.bg/kapka-kassabova-interview-giorgia-spadoni/

Наскоро книгата „Към езерото“ на Капка Касабова излезе на италиански в превод на Анна Ловизоло за издателство Crocetti Editore. По този повод Джорджа Спадони разговаря с писателката за „балканската идентичност“, за предразсъдъците на Запада спрямо Изтока и за ролята на езика и малките разкази в лекуването на травмите и разделенията. Разговорът първоначално е публикуван в италианския сайт Meridiano 13, а специално за читателите на „Тоест“ е преведен на български от авторката на интервюто.

Както в „Граница“, така и в „Към езерото“ читателят е свидетел на сблъсъка между два паралелни наратива: големия исторически разказ и индивидуалните истории на персонажите. Западната страна на Адриатическо море познава „войнствеността“ на Балканския полуостров – вероятно най-широко разпространеният предразсъдък за тези земи. Може ли малкият разказ да помогне за изграждането на нов образ на Балканския полуостров? Съществува ли „балканска идентичност“ според Вас?

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

„Към езерото“ изследва това, което наричам „тирания на идентичността“ – натиска да се определиш като едно или друго. Ако избереш грешния вариант, ще бъдеш наказан от семейството, националната догма и самата история. Този процес често започва още в детството – с макиавелския въпрос на кварталните клюкари: „Кого обичаш повече – мама или татко, баба или мама?“. Този въпрос придава политическа стойност на лоялността и замисълът му е да разединява. Така започва войната. Войната отвън започва с малки вътрешни разделения.

„Ти чия си?“, питат охридчаните, когато си на гости и имаш балкански вид. С други думи – към кое семейство принадлежиш, за да можем да те поставим в йерархичен контекст. Това, разбира се, е най-патриархалният въпрос. Дори не е въпрос, а твърдение, което гласи: ти не се броиш за индивид. Тиранията във всичките ѝ форми – политическа, семейна, като болест и лудост – и начините ни да се освободим от нея: това се оформя като основна тема в книгата. Една тирания, от която страдат балканските народи, е етикетирането на мястото като полуостров на войните. Големите войни на XX век на Балканите всъщност са имперски войни, чужди, внесени отвън. По това време е измислена думата „балканизация“ – през 1917 г. в САЩ.

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

Не мога да си спомня кой беше казал, че Балканите са единственият край в Европа, където всичко може да се случи по всяко време. Това също е част от нашата органична, домашно отгледана балканска идентичност. И е част от географията. Тази изключителна психогеография, която ме кара да се връщам отново и отново към Южните Балкани. Някаква част от дивата природа все още е жива на Балканите. Това, което ми даде сили да пропътувам този път, бяха самите езера и планини, тяхното величие и мистерия. А дивото на Земята и в човешките души е под смъртна заплаха. Докато се боричкаме в дребнавите си игри на идентичност и водим безумните си войни, Земята остава нашият едничък и истински дом. И единственият начин да изследваме истинската идентичност, истинския дом, истинската си същност е чрез интимно вслушване и вглеждане. Надолу по кривите пътища на човешкото сърце, далеч от смазващите монолити на властта.

В интервю пред Марин Бодаков през декември 2020 г. описвате отношенията между България и Северна Македония – и между балканските държави като цяло – като травма, причинена от границите. А в книгата си „Към езерото“ пишете: „Идентичността като оръжие на тиранията: ето в това се превръща с времето Mакедонският въпрос.“ Травмите и границите все още ли играят важна роля в изграждането на националната и индивидуалната идентичност на полуострова? Травмата, границите и идентичността неразривно свързани ли са?

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

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

В същото интервю казвате, че „най-опасните и трудно преодолими граници са в главите на хората“. Разширявайки перспективата от Балканския полуостров към целия европейски континент, усещали ли сте присъствието на някаква граница, която все още разделя западната част от Източния блок? Съществува ли все още такъв „блок“ в западноевропейските глави?

Съществува, да. До ден днешен Западна Европа проектира своята тъмна сянка върху Изтока и особено върху Балканите. В психологията това се нарича проекция –  когато не си се справил с вътрешните си демони и ги пренасяш върху някой друг. Едно изречение се повтаря в моята книга: „По-лесно е сянката да пада върху другите, не върху нас.“ Виждаме го в личните отношения, в семействата и между народите. Тази проекция е продукт на желязната завеса, която произведе невежество, разделение и липса на любознателност и истина. Вместо тях от двете страни на завесата се установи практика на тайни, клишета и лъжи. Тази отровна практика е все още сред нас.

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

При едно от пътешествията – глава „Воят“ – преминавам в гръцката страна на Преспанското езеро, където в продължение на няколко дни с мой приятел, Ник, който е македонски австралиец, обикаляме призрачни села в търсене на ехото на Гражданската война в Гърция. Тоест в търсене на ехото на собствените ни семейни съдби. Още една война като Югославската, която остава отхвърлена и непозната в Европа. Ето защо сега в Украйна има война. Аз не съм изненадана и хората на Балканите не са изненадани. Шокирани и потресени – да. Руските агресори са улеснени от безнаказаността на агресорите в Югославия. Но този път за европейците е по-трудно да отрекат, че това ще промени нещата за всички нас. Вече не е възможно да се скрием от собствената си колективна сянка. Тя е вече пред вратата ни.

В предговора на „Към езерото“ пишете: „Балканите като цяло представляват сложна цивилизационна тъкан, по която местните разчитат, а външните проектират различни – и понякога взаимно противоречиви – версии на действителността.“ Как Вашата „изгодна“ позиция на емигрант от български произход се отразява на събирането на източници и на процеса на писане? Какво означава да се разкрие пред западната публика тази така пренебрегната част от Европа? 

Езикът играе важна роля в това.

Пиша, за да се уча. Прекарах две години от живота си около езерата, защото исках да разбера нещо – нещо интимно и дълбоко, без значение какво ще ми струва. Четох много, но исках да разбера това, което не може да се разбере от книгите. Поради тази причина аз се впускам в пътуване само ако съм сигурна, че то ще задълбочи познанието ми за хората. Цената може да бъде висока в личен план, но дарът на разбирането е безценен. Да продължа да откривам Балканите в цялата им сложна красота и мъка означава да разбера вътрешната си география и това, което представлява самият живот.

Има и танц на близостта и разстоянието. За да мога да съм истински близка с хората и местата в книгите си, трябва да имам място, където да се възстановя – далече от тях. Самият факт, че от 30 години живея далеч от България и Балканите и че пиша на английски, ми дава умерения емоционален климат, от който имам нужда, преди да навляза в психологическите лабиринти на моето семейство, моята родина, моите горчиви, обичани, безгранични Балкани. Охридската ми баба Анастасия казваше: „Балканите, това сме ние.“ Тоест цялото човечество.

Почти всички Ваши книги са издадени в България, но въпреки че владеете перфектно и английски, и български, Вие решавате да не се занимавате с превода на творбите си. Как се отнасяте към тези два езика? Равни ли са, или ги използвате по различен начин?

Създаването на книгите ми е физически и емоционален акт, не само интелектуален. Аз обитавам книгите си. Като писател, който основава работата си на непосредствения опит, прекарвам много време извън зоната си на комфорт. Това е моят начин да се уча: трупам впечатления на терен, а после ги пренасям на страницата – мястото на истинското осъзнаване. За мен страницата е продължение на пресичането на езерото с Танас, който е израснал като политически затворник в Албания; на планинския преход с моя водач Анджело, с когото почти се бих в окопите на Първата световна война; на вечерите с братовчедите ми; на извървяното от сродни пътешественици преди мен. Все пак оттук е минавала Via Egnatia, която е превърнала езерата в нервен център на римския свят, а по-късно – на славянското, християнското и ислямското просвещение. Гласовете на тези пътешественици също са в книгата: на Едуард Лиър, на Едит Дърам.

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

Всеки, с когото разговарям в „Граница“ и „Към езерото“, общува с мен на български, на някакъв регионален диалект или славянски език. Това е свързващото – и ключовото – в балканските ми книги. Дори в Гърция, Турция и Албания, където английският ми беше от помощ, българският беше определящ. За българското издание се връщам към бележките си, където са уловени автентичните гласове и диалекти на хората. Обичам до безкрай този празник на цветове и гласове. Напомня ми колко неразрушимо полифонични са Балканите. Ето защо искам да запазя това богатство завинаги, слушайки и пишейки нашите истории толкова дълго, колкото мога.

Заглавна снимка: Скалната църква на остров Мали град, Преспа, Албания © Личен архив на Капка Касабова

Източник

Build an Apache Iceberg data lake using Amazon Athena, Amazon EMR, and AWS Glue

Post Syndicated from Kishore Dhamodaran original https://aws.amazon.com/blogs/big-data/build-an-apache-iceberg-data-lake-using-amazon-athena-amazon-emr-and-aws-glue/

Most businesses store their critical data in a data lake, where you can bring data from various sources to a centralized storage. The data is processed by specialized big data compute engines, such as Amazon Athena for interactive queries, Amazon EMR for Apache Spark applications, Amazon SageMaker for machine learning, and Amazon QuickSight for data visualization.

Apache Iceberg is an open-source table format for data stored in data lakes. It is optimized for data access patterns in Amazon Simple Storage Service (Amazon S3) cloud object storage. Iceberg helps data engineers tackle complex challenges in data lakes such as managing continuously evolving datasets while maintaining query performance. Iceberg allows you to do the following:

  • Maintain transactional consistency where files can be added, removed, or modified atomically with full read isolation and multiple concurrent writes
  • Implement full schema evolution to process safe table schema updates as the table data evolves
  • Organize tables into flexible partition layouts with partition evolution, enabling updates to partition schemes as queries and data volume changes without relying on physical directories
  • Perform row-level update and delete operations to satisfy new regulatory requirements such as the General Data Protection Regulation (GDPR)
  • Provide versioned tables and support time travel queries to query historical data and verify changes between updates
  • Roll back tables to prior versions to return tables to a known good state in case of any issues

In 2021, AWS teams contributed the Apache Iceberg integration with the AWS Glue Data Catalog to open source, which enables you to use open-source compute engines like Apache Spark with Iceberg on AWS Glue. In 2022, Amazon Athena announced support of Iceberg and Amazon EMR added support of Iceberg starting with version 6.5.0.

In this post, we show you how to use Amazon EMR Spark to create an Iceberg table, load sample books review data, and use Athena to query, perform schema evolution, row-level update and delete, and time travel, all coordinated through the AWS Glue Data Catalog.

Solution overview

We use the Amazon Customer Reviews public dataset as our source data. The dataset contains data files in Apache Parquet format on Amazon S3. We load all the book-related Amazon review data as an Iceberg table to demonstrate the advantages of using the Iceberg table format on top of raw Parquet files. The following diagram illustrates our solution architecture.

Architecture that shows the flow from Amazon EMR loading data into Amazon S3, and queried by Amazon Athena through AWS Glue Data Catalog.

To set up and test this solution, we complete the following high-level steps:

  1. Create an S3 bucket.
  2. Create an EMR cluster.
  3. Create an EMR notebook.
  4. Configure a Spark session.
  5. Load data into the Iceberg table.
  6. Query the data in Athena.
  7. Perform a row-level update in Athena.
  8. Perform a schema evolution in Athena.
  9. Perform time travel in Athena.
  10. Consume Iceberg data across Amazon EMR and Athena.

Prerequisites

To follow along with this walkthrough, you must have the following:

  • An AWS Account with a role that has sufficient access to provision the required resources.

Create an S3 bucket

To create an S3 bucket that holds your Iceberg data, complete the following steps:

  1. On the Amazon S3 console, choose Buckets in the navigation pane.
  2. Choose Create bucket.
  3. For Bucket name, enter a name (for this post, we enter aws-lake-house-iceberg-blog-demo).

Because S3 bucket names are globally unique, choose a different name when you create your bucket.

  1. For AWS Region, choose your preferred Region (for this post, we use us-east-1).

Create a new Amazon S3 bucket. Choose us-east-1 as region

  1. Complete the remaining steps to create your bucket.
  2. If this is the first time that you’re using Athena to run queries, create another globally unique S3 bucket to hold your Athena query output.

Create an EMR cluster

Now we’re ready to start an EMR cluster to run Iceberg jobs using Spark.

  1. On the Amazon EMR console, choose Create cluster.
  2. Choose Advanced options.
  3. For Software Configuration, choose your Amazon EMR release version.

Iceberg requires release 6.5.0 and above.

  1. Select JupyterEnterpriseGateway and Spark as the software to install.
  2. For Edit software settings, select Enter configuration and enter [{"classification":"iceberg-defaults","properties":{"iceberg.enabled":true}}].
  3. Leave other settings at their default and choose Next.

Choose Amazon EMR release 6.6.0 and JupyterEnterpriseGateway and Spark. Enter configuration information.

  1. You can change the hardware used by the Amazon EMR cluster in this step. In this demo, we use the default setting.
  2. Choose Next.
  3. For Cluster name, enter Iceberg Spark Cluster.
  4. Leave the remaining settings unchanged and choose Next.

Provide Iceberg Spark Cluster as the Cluster name

  1. You can configure security settings such as adding an EC2 key pair to access your EMR cluster locally. In this demo, we use the default setting.
  2. Choose Create cluster.

You’re redirected to the cluster detail page, where you wait for the EMR cluster to transition from Starting to Waiting.

Create an EMR notebook

When the cluster is active and in the Waiting state, we’re ready to run Spark programs in the cluster. For this demo, we use an EMR notebook to run Spark commands.

  1. On the Amazon EMR console, choose Notebooks in the navigation pane.
  2. Choose Create notebook.
  3. For Notebook name, enter a name (for this post, we enter iceberg-spark-notebook).
  4. For Cluster, select Choose an existing cluster and choose Iceberg Spark Cluster.
  5. For AWS service role, choose Create a new role to create EMR_Notebook_DefaultRole or choose a different role to access resources in the notebook.
  6. Choose Create notebook.

Create an Amazon EMR notebook. Use EMR_Notebooks_DefaultRole

You’re redirected to the notebook detail page.

  1. Choose Open in JupyterLab next to your notebook.
  2. Choose to create a new notebook.
  3. Under Notebook, choose Spark.

Choose Spark from the options provided in the Launcher

Configure a Spark session

In your notebook, run the following code:

%%configure -f
{
  "conf": {
    "spark.sql.catalog.demo": "org.apache.iceberg.spark.SparkCatalog",
    "spark.sql.catalog.demo.catalog-impl": "org.apache.iceberg.aws.glue.GlueCatalog",
    "spark.sql.catalog.demo.warehouse": "s3://<your-iceberg-blog-demo-bucket>",
    "spark.sql.extensions":"org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"
  }
}

This sets the following Spark session configurations:

  • spark.sql.catalog.demo – Registers a Spark catalog named demo, which uses the Iceberg Spark catalog plugin
  • spark.sql.catalog.demo.catalog-impl – The demo Spark catalog uses AWS Glue as the physical catalog to store Iceberg database and table information
  • spark.sql.catalog.demo.warehouse – The demo Spark catalog stores all Iceberg metadata and data files under the root path s3://<your-iceberg-blog-demo-bucket>
  • spark.sql.extensions – Adds support to Iceberg Spark SQL extensions, which allows you to run Iceberg Spark procedures and some Iceberg-only SQL commands (you use this in a later step)

Load data into the Iceberg table

In our Spark session, run the following commands to load data:

// create a database in AWS Glue named reviews if not exist
spark.sql("CREATE DATABASE IF NOT EXISTS demo.reviews")

// load reviews related to books
val book_reviews_location = "s3://amazon-reviews-pds/parquet/product_category=Books/*.parquet"
val book_reviews = spark.read.parquet(book_reviews_location)

// write book reviews data to an Iceberg v2 table
book_reviews.writeTo("demo.reviews.book_reviews").tableProperty("format-version", "2").createOrReplace()

Iceberg format v2 is needed to support row-level updates and deletes. See Format Versioning for more details.

It may take up to 15 minutes for the commands to complete. When it’s complete, you should be able to see the table on the AWS Glue console, under the reviews database, with the table_type property shown as ICEBERG.

Shows the table properties for book_reviews table

The table schema is inferred from the source Parquet data files. You can also create the table with a specific schema before loading data using Spark SQL, Athena SQL, or Iceberg Java and Python SDKs.

Query in Athena

Navigate to the Athena console and choose Query editor. If this is your first time using the Athena query editor, you need to configure to use the S3 bucket you created earlier to store the query results.

The table book_reviews is available for querying. Run the following query:

SELECT * FROM reviews.book_reviews LIMIT 5;

The following screenshot shows the first five records from the table being displayed.

Amazon Athena query the first 5 rows and show the results

Perform a row-level update in Athena

In the next few steps, let’s focus on a record in the table with review ID RZDVOUQG1GBG7. Currently, it has no total votes when we run the following query:

SELECT total_votes FROM reviews.book_reviews 
WHERE review_id = 'RZDVOUQG1GBG7'

Query total_votes for a particular review which shows a value of 0

Let’s update the total_votes value to 2 using the following query:

UPDATE reviews.book_reviews
SET total_votes = 2
WHERE review_id = 'RZDVOUQG1GBG7'

Update query to set the total_votes for the previous review_id to 2

After your update command runs successfully, run the below query and note the updated result showing a total of two votes:

SELECT total_votes FROM reviews.book_reviews
WHERE review_id = 'RZDVOUQG1GBG7'

Athena enforces ACID transaction guarantee for all the write operations against an Iceberg table. This is done through the Iceberg format’s optimistic locking specification. When concurrent attempts are made to update the same record, a commit conflict occurs. In this scenario, Athena displays a transaction conflict error, as shown in the following screenshot.

Concurrent updates causes a failure. This shows the TRANSACTION_CONFLICT error during this scenario.

Delete queries work in a similar way; see DELETE for more details.

Perform a schema evolution in Athena

Suppose the review suddenly goes viral and gets 10 billion votes:

UPDATE reviews.book_reviews
SET total_votes = 10000000000
WHERE review_id = 'RZDVOUQG1GBG7'

Based on the AWS Glue table information, the total_votes is an integer column. If you try to update a value of 10 billion, which is greater than the maximum allowed integer value, you get an error reporting a type mismatch.

Updating to a very large value greater than maximum allowed integer value results in an error

Iceberg supports most schema evolution features as metadata-only operations, which don’t require a table rewrite. This includes add, drop, rename, reorder column, and promote column types. To solve this issue, you can change the integer column total_votes to a BIGINT type by running the following DDL:

ALTER TABLE reviews.book_reviews
CHANGE COLUMN total_votes total_votes BIGINT;

You can now update the value successfully:

UPDATE reviews.book_reviews
SET total_votes = 10000000000
WHERE review_id = 'RZDVOUQG1GBG7'

Querying the record now gives us the expected result in BIGINT:

SELECT total_votes FROM reviews.book_reviews
WHERE review_id = 'RZDVOUQG1GBG7'

Perform time travel in Athena

In Iceberg, the transaction history is retained, and each transaction commit creates a new version. You can perform time travel to look at a historical version of a table. In Athena, you can use the following syntax to travel to a time that is after when the first version was committed:

SELECT total_votes FROM reviews.book_reviews
FOR SYSTEM_TIME AS OF localtimestamp + interval '-20' minute
WHERE review_id = 'RZDVOUQG1GBG7'

Query an earlier snapshot using time travel feature

Consume Iceberg data across Amazon EMR and Athena

One of the most important features of a data lake is for different systems to seamlessly work together through the Iceberg open-source protocol. After all the operations are performed in Athena, let’s go back to Amazon EMR and confirm that Amazon EMR Spark can consume the updated data.

First, run the same Spark SQL and see if you get the same result for the review used in the example:

val select_votes = """SELECT total_votes FROM demo.reviews.book_reviews
WHERE review_id = 'RZDVOUQG1GBG7'"""

spark.sql(select_votes).show()

Spark shows 10 billion total votes for the review.

Shows the latest value of total_votes when querying using the Amazon EMR notebook

Check the transaction history of the operation in Athena through Spark Iceberg’s history system table:

val select_history = "SELECT * FROM demo.reviews.book_reviews.history"

spark.sql(select_history).show()

This shows three transactions corresponding to the two updates you ran in Athena.

Shows snapshots corresponding to the two updates you ran in Athena

Iceberg offers a variety of Spark procedures to optimize the table. For example, you can run an expire_snapshots procedure to remove old snapshots, and free up storage space in Amazon S3:

import java.util.Calendar
import java.text.SimpleDateFormat

val now = Calendar.getInstance().getTime()
val form = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss")
val now_formatted = form.format(now.getTime())
val procedure = s"""CALL demo.system.expire_snapshots(
  table => 'reviews.book_reviews',
  older_than => TIMESTAMP '$now_formatted',
  retain_last => 1)"""

spark.sql(procedure)

Note that, after running this procedure, time travel can no longer be performed against expired snapshots.

Examine the history system table again and notice that it shows you only the most recent snapshot.

Running the following query in Athena results in an error “No table snapshot found before timestamp…” as older snapshots were deleted, and you are no longer able to time travel to the older snapshot:

SELECT total_votes FROM reviews.book_reviews
FOR SYSTEM_TIME AS OF localtimestamp + interval '-20' minute
WHERE review_id = 'RZDVOUQG1GBG7'

Clean up

To avoid incurring ongoing costs, complete the following steps to clean up your resources:

  1. Run the following code in your notebook to drop the AWS Glue table and database:
// DROP the table 
spark.sql("DROP TABLE demo.reviews.book_reviews") 
// DROP the database 
spark.sql("DROP DATABASE demo.reviews")
  1. On the Amazon EMR console, choose Notebooks in the navigation pane.
  2. Select the notebook iceberg-spark-notebook and choose Delete.
  3. Choose Clusters in the navigation pane.
  4. Select the cluster Iceberg Spark Cluster and choose Terminate.
  5. Delete the S3 buckets and any other resources that you created as part of the prerequisites for this post.

Conclusion

In this post, we showed you an example of using Amazon S3, AWS Glue, Amazon EMR, and Athena to build an Iceberg data lake on AWS. An Iceberg table can seamlessly work across two popular compute engines, and you can take advantage of both to design your customized data production and consumption use cases.

With AWS Glue, Amazon EMR, and Athena, you can already use many features through AWS integrations, such as SageMaker Athena integration for machine learning, or QuickSight Athena integration for dashboard and reporting. AWS Glue also offers the Iceberg connector, which you can use to author and run Iceberg data pipelines.

In addition, Iceberg supports a variety of other open-source compute engines that you can choose from. For example, you can use Apache Flink on Amazon EMR for streaming and change data capture (CDC) use cases. The strong transaction guarantee and efficient row-level update, delete, time travel, and schema evolution experience offered by Iceberg offers a sound foundation and infinite possibilities for users to unlock the power of big data.

About the Authors

Kishore Dhamodaran is a Senior Solutions Architect at AWS. Kishore helps strategic customers with their cloud enterprise strategy and migration journey, leveraging his years of industry and cloud experience.

Jack Ye is a software engineer of the Athena Data Lake and Storage team. He is an Apache Iceberg Committer and PMC member.

Mohit Mehta is a Principal Architect at AWS with expertise in AI/ML and data analytics. He holds 12 AWS certifications and is passionate about helping customers implement cloud enterprise strategies for digital transformation. In his free time, he trains for marathons and plans hikes across major peaks around the world.

Giovanni Matteo Fumarola is the Engineering Manager of the Athena Data Lake and Storage team. He is an Apache Hadoop Committer and PMC member. He has been focusing in the big data analytics space since 2013.

Jared Keating is a Senior Cloud Consultant with AWS Professional Services. Jared assists customers with their cloud infrastructure, compliance, and automation requirements, drawing from his 20+ years of IT experience.

CVE-2022-27511: Citrix ADM Remote Device Takeover

Post Syndicated from Erick Galinkin original https://blog.rapid7.com/2022/06/16/cve-2022-27511-citrix-adm-remote-device-takeover/

CVE-2022-27511: Citrix ADM Remote Device Takeover

On Monday, June 14, 2022, Citrix published an advisory on CVE-2022-27511, a critical improper access control vulnerability affecting their Application Delivery Management (ADM) product.

A remote, unauthenticated attacker can leverage CVE-2022-27511 to reset administrator credentials to the default value at the next reboot. This allows the attacker to use SSH and the default administrator credentials to access the affected management console. The vulnerability has been patched in Citrix ADM 13.1-21.53 and ADM 13.0-85.19 and should be applied as soon as possible. Versions of Citrix ADM before 13.0 and 13.1 are end of life, so Citrix will not make patches available for these versions. Users still on version 12.x are encouraged to upgrade to a supported version.

At the time of this writing, no exploitation has been observed, and no exploits have been made publicly available. However, given the nature of the vulnerability and the footprint of Citrix ADM, we anticipate that exploitation will happen as soon as an exploit is made available.

Mitigation guidance

Citrix ADM customers should upgrade their versions of both ADM server and agents as soon as possible. Citrix notes in their advisory that they strongly recommend that network traffic to the Citrix ADM’s IP address be segmented, either physically or logically, from standard network traffic.

Rapid7 customers

We are investigating the feasibility of a vulnerability check for InsightVM and Nexpose customers.

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

AWS HITRUST CSF certification is available for customer inheritance

Post Syndicated from Sonali Vaidya original https://aws.amazon.com/blogs/security/aws-hitrust-csf-certification-is-available-for-customer-inheritance/

As an Amazon Web Services (AWS) customer, you don’t have to assess the controls that you inherit from the AWS HITRUST Validated Assessment Questionnaire, because AWS already has completed HITRUST assessment using version 9.4 in 2021. You can deploy your environments onto AWS and inherit our HITRUST CSF certification, provided that you use only in-scope services and apply the controls detailed on the HITRUST website.

HITRUST certification allows you to tailor your security control baselines to a variety of factors—including, but not limited to, regulatory requirements and organization type. HITRUST CSF has been widely adopted by leading organizations in a variety of industries as part of their approach to security and privacy. Visit the HITRUST website for more information.

Have you submitted HITRUST Inheritance Program requests to AWS, but haven’t received a response yet? Understand why …

The HITRUST MyCSF manual provides step-by-step instructions for completing the HITRUST Inheritance process. It’s a simple four-step process, as follows:

  1. You create the Inheritance request in the HITRUST MyCSF tool.
  2. You submit the request to AWS.
  3. AWS will either approve or reject the Inheritance request based on the AWS HITRUST Shared Responsibility Matrix.
  4. Finally, you can apply all approved Inheritance requests to your HITRUST Compliance Assessment.

Unless a request is submitted to AWS, we will not be able to approve it. If a prolonged period of time has gone by and you haven’t received a response from AWS, most likely you created the request but didn’t submit it to AWS.

We are committed to helping you achieve and maintain the highest standard of security and compliance. As always, we value your feedback and questions. Feel free to contact the team through AWS Compliance Contact Us. If you have feedback about this post, submit comments in the Comments section below.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Sonali Vaidya

Sonali leads multiple AWS global compliance programs, including HITRUST, ISO 27001, ISO 27017, ISO 27018, ISO 27701, ISO 9001, and CSA STAR. Sonali has over 20 years of experience in information security and privacy management and holds multiple certifications, such as CISSP, C-GDPR|P, CCSK, CEH, CISA, PCIP, and Lead Auditor for ISO 27001 and ISO 22301.

Security Is Shifting in a Cloud-Native World: Insights From RSAC 2022

Post Syndicated from Jesse Mack original https://blog.rapid7.com/2022/06/16/security-is-shifting-in-a-cloud-native-world-insights-from-rsac-2022/

Security Is Shifting in a Cloud-Native World: Insights From RSAC 2022

The cloud has become the default for IT infrastructure and resource delivery, allowing an unprecedented level of speed and flexibility for development and production pipelines. This helps organizations compete and innovate in a fast-paced business environment. But as the cloud becomes more ingrained, the ephemeral nature of cloud infrastructure is presenting new challenges for security teams.

Several talks by our Rapid7 presenters at this year’s RSA Conference touched on this theme. Here’s a closer look at what our RSAC 2022 presenters had to say about adapting security processes to a cloud-native world.

A complex picture

As Lee Weiner, SVP Cloud Security and Chief Innovation Officer, pointed out in his RSA briefing, “Context Is King: The Future of Cloud Security,” cloud adoption is not only increasing — it’s growing more complex. Many organizations are bringing on multiple cloud vendors to meet a variety of different needs. One report estimates that a whopping 89% of companies that have adopted the cloud have chosen a multicloud approach.

This model is so popular because of the flexibility it offers organizations to utilize the right technology, in the right cloud environment, at the right cost — a key advantage in a today’s marketplace.

“Over the last decade or so, many organizations have been going through a transformation to put themselves in a position to use the scale and speed of the cloud as a strategic business advantage,” Jane Man, Director of Product Management for VRM, said in her RSA Lounge presentation, “Adapting Your Vulnerability Management Program for Cloud-Native Environments.”

While DevOps teams can move more quickly than ever before with this model, security pros face a more complex set of questions than with traditional infrastructure, Lee noted. How many of our instances are exposed to known vulnerabilities? Do they have property identity and access management (IAM) controls established? What levels of access do those permissions actually grant users in our key applications?

New infrastructure, new demands

The core components of vulnerability management remain the same in cloud environments, Jane said in her talk. Security teams must:

  • Get visibility into all assets, resources, and services
  • Assess, prioritize, and remediate risks
  • Communicate the organization’s security and compliance posture to management

But because of the ephemeral nature of the cloud, the way teams go about completing these requirements is shifting.

“Running a scheduled scan, waiting for it to complete and then handing a report to IT doesn’t work when instances may be spinning up and down on a daily or hourly basis,” she said.

In his presentation, Lee expressed optimism that the cloud itself may help provide the new methods we need for cloud-native security.

“Because of the way cloud infrastructure is built and deployed, there’s a real opportunity to answer these questions far faster, far more efficiently, far more effectively than we could with traditional infrastructure,” he said.

Calling for context

For Lee, the goal is to enable secure adoption of cloud technologies so companies can accelerate and innovate at scale. But there’s a key element needed to achieve this vision: context.

What often prevents teams from fully understanding the context around their security data is the fact that it is siloed, and the lack of integration between disparate systems requires a high level of manual effort to put the pieces together. To really get a clear picture of risk, security teams need to be able to bring their data together with context from each layer of the environment.

But what does context actually look like in practice, and how do you achieve it? Jane laid out a few key strategies for understanding the context around security data in your cloud environment.

  • Broaden your scope: Set up your VM processes so that you can detect more than just vulnerabilities in the cloud — you want to be able to see misconfigurations and issues with IAM permissions, too.
  • Understand the environment: When you identify a vulnerable instance, identify if it is publicly accessible and what its business application is — this will help you determine the scope of the vulnerability.
  • Catch early: Aim to find and fix vulnerabilities in production or pre-production by shifting security left, earlier in the development cycle.

4 best practices for context-driven cloud security

Once you’re able to better understand the context around security data in your environment, how do you fit those insights into a holistic cloud security strategy? For Lee, this comes down to four key components that make up the framework for cloud-native security.

1. Visibility and findings

You can’t secure what you can’t see — so the first step in this process is to take a full inventory of your attack surface. With different kinds of cloud resources in place and providers releasing new services frequently, understanding the security posture of these pieces of your infrastructure is critical. This includes understanding not just vulnerabilities and misconfigurations but also access, permissions, and identities.

“Understanding the layer from the infrastructure to the workload to the identity can provide a lot of confidence,” Lee said.

2. Contextual prioritization

Not everything you discover in this inventory will be of equal importance, and treating it all the same way just isn’t practical or feasible. The vast amount of data that companies collect today can easily overwhelm security analysts — and this is where context really comes in.

With integrated visibility across your cloud infrastructure, you can make smarter decisions about what risks to prioritize. Then, you can assign ownership to resource owners and help them understand how those priorities were identified, improving transparency and promoting trust.

3. Prevent and automate

The cloud is built with automation in mind through Infrastructure as Code — and this plays a key role in security. Automation can help boost efficiency by minimizing the time it takes to detect, remediate, or contain threats. A shift-left strategy can also help with prevention by building security into deployment pipelines, so production teams can identify vulnerabilities earlier.

Jane echoed this sentiment in her talk, recommending that companies “automate to enable — but not force — remediation” and use tagging to drive remediation of vulnerabilities found running in production.

4. Runtime monitoring

The next step is to continually monitor the environment for vulnerabilities and threat activity — and as you might have guessed, monitoring looks a little different in the cloud. For Lee, it’s about leveraging the increased number of signals to understand if there’s any drift away from the way the service was originally configured.

He also recommended using behavioral analysis to detect threat activity and setting up purpose-built detections that are specific to cloud infrastructure. This will help ensure the security operations center (SOC) has the most relevant information possible, so they can perform more effective investigations.

Lee stressed that in order to carry out the core components of cloud security and achieve the outcomes companies are looking for, having an integrated ecosystem is absolutely essential. This will help prevent data from becoming siloed, enable security pros to obtain that ever-important context around their data, and let teams collaborate with less friction.

Looking for more insights on how to adapt your security program to a cloud-native world? Check out Lee’s presentation on demand, or watch our replays of Rapid7 speakers’ sessions from RSAC 2022.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Resize Amazon Redshift from DC2 to RA3 with minimal or no downtime

Post Syndicated from Soujanya Konka original https://aws.amazon.com/blogs/big-data/resize-amazon-redshift-from-dc2-to-ra3-with-minimal-or-no-downtime/

Amazon Redshift is a popular cloud data warehouse that allows you to process exabytes of data across your data warehouse, operational database, and data lake using standard SQL. Amazon Redshift offers different node types like DC2 (dense compute) and RA3, which you can use for your different workloads and use cases. For more information about the benefits of migrating from DS2 to RA3, refer to Scale your cloud data warehouse and reduce costs with the new Amazon Redshift RA3 nodes with managed storage and Amazon Redshift Benchmarking: Comparison of RA3 vs. DS2 Instance Types.

Many customers use DC2 nodes for their compute-intensive workloads. It’s natural to scale with your growing workload, namely separating compute from storage so they’re right-sized as per your needs. RA3 nodes with managed storage enable you to optimize your data warehouse by scaling and paying for compute and managed storage independently. Amazon Redshift managed storage uses large, high-performance SSDs in each RA3 node for fast local storage and Amazon S3 for longer-term durable storage. If the data in a node grows beyond the size of the large local SSDs, Amazon Redshift managed storage automatically offloads that data to Amazon S3. RA3 nodes keep track of the frequency of access for each data block and cache the hottest blocks. If the blocks aren’t cached, the large networking bandwidth and precise storing techniques return the data in sub-seconds. Also, if you’re looking for features like cross-cluster data sharing and cross-Availability Zone cluster relocation, these are a few of the reasons for migrating to RA3. Many customers on DC2 have benefitted from migrating to RA3 to serve their growing performance requirements and business use cases.

As a first step of the migration, we always recommend finding the correct load of your system and determining the number of RA3 nodes that will meet your workload and give you the best cost-performance benefit. For this evaluation, you can use the simple Replay tool to conduct a what-if analysis and evaluate how your workload performs in different scenarios. For example, you can use the tool to benchmark your actual workload on a new instance type like RA3, evaluate a new feature, or assess different cluster configurations. To choose the right cluster type, you can compare different node types for your workload and choose the right configuration of RA3 with the Simple Replay utility.

Once you know the cluster type and nodes, the next question is how to migrate your current workload to RA3 with minimum downtime or without disrupting your current workload. In this post, we describe an approach to do this with minimum downtime.

Resizing an Amazon Redshift cluster

There are three ways to resize or migrate an Amazon Redshift cluster from DC2 to RA3 :

  • Elastic resize – If it’s available as an option, use elastic resize to change the node type, number of nodes, or both. Note that when you only change the number of nodes, the queries are temporarily paused and connections are kept open. An elastic resize can take between 10–15 minutes. During a resize operation, the cluster is read-only.
  • Classic resize – Use classic resize to change the node type, number of nodes, or both. Choose this option when you’re resizing to a configuration that isn’t available through elastic resize. A resize operation can take 2 hours or more, or last up to several days depending on your data size. During the resize operation, the source cluster is read-only.
  • Snapshot, restore, and resize – To keep your cluster available during a classic resize, make a copy of the existing cluster, then resize the new cluster. If data is written to the source cluster after a snapshot is taken, the data must be manually copied over after the migration is complete.

Checkpoints for resize

When a cluster is resized using elastic resize with the same node type, the operation doesn’t create a new cluster. As a result, the operation completes quickly. In case of resize, there could be one or more challenges causing the delay in resize:

  • Data volumes – The time required to complete a classic resize or a snapshot and restore operation might vary, depending on factors like the workload on the source cluster, the number and volume of tables being transformed, how evenly data is distributed across the compute nodes and slices, and the node configuration in the source and target clusters.
  • Snapshots – Automated snapshots are automatically deleted when their retention period expires, when you disable automated snapshots, or when you delete a cluster. If you want to keep an automated snapshot, you can copy it to a manual snapshot. You can take a manual snapshot of the cluster before the migration, which is used for resize operations, but it may not include live data from the time the snapshot was captured.
  • Cluster unavailable during resize – It’s critical to know roughly how long the resize will take. To do so, you can try creating a cluster from the snapshot in a test account. However, this only gives a ballpark idea because resize times can vary, especially if you intend to query your cluster during the resize. If the cluster is live almost all the time with minimal or zero non-business hours, a resize can be a challenge because the cluster can’t upsert live data and serve read requests on this data during this window.
  • Cluster endpoint retention – Elastic resize and cluster resize allow you to change the node type, number of nodes, or both, but the endpoint is retained. With snapshot resize, a new cluster endpoint is created, which may require a change in your application to replace the endpoint.
  • Reconciliation – Validate the target cluster data with the source to make sure migration was completed without data loss and ensure data quality. Reconciliation at the table level isn’t sufficient, you need to ensure records have also been copied from the source. You can run a matching record count check followed by data validation using checksum for accuracy of data.

Solution overview

The steps to prepare for migration are as follows:

  1. Take a snapshot of the existing production Amazon Redshift cluster running on DC2.
  2. Create another Amazon Simple Storage Service (Amazon S3) bucket, where AWS Glue writes the curated data in parallel.
  3. Use the snapshot to create an RA3 cluster.
  4. Configure AWS Database Migration Service (AWS DMS) to load data from the migrated bucket to Amazon S3.
  5. After you confirm that the data is synced between the two clusters (DC and RA3) and all other downstream applications, stop the DC cluster and change the endpoint of your dependent downstream application to the newly created RA3 cluster.

Following is the current architecture depicting a live workload.

In this solution, data comes from three source systems and are written into a raw S3 bucket:

  • Change data capture (CDC) from an RDS instance via AWS DMS (1 in the preceding diagram)
  • Events captured via an external API (2)
  • CSV files from an external source copied to the raw bucket (3)

These sources don’t have a pattern or an interval of pushing new data.

Every few minutes, the ingested data is picked up by an S3 event trigger to run an AWS Glue workflow (4 in the preceding diagram). It provides an orchestration layer to manage and run jobs and crawlers. This workflow includes a crawler (5) that updates the metadata schema and partitions of the dataset to the AWS Glue Data Catalog. Then the crawler triggers an AWS Glue job that writes the curated data to the S3 curated bucket. From there, another AWS Glue job uploads data into Amazon Redshift (6).

In this scenario, if your workload is critical and you can’t afford a long downtime, then you need to plan your migration accordingly.

Dual write and transient data curation pipeline

As a first step of the migration, you need a parallel data process pipeline as the AWS Glue job, which writes the data into the curated S3 bucket. Create another S3 bucket and name it migrated-curated-bucket and modify the AWS Glue transform job. You can also replicate another transform job to write data to a new reserve S3 bucket in parallel.

In this scenario, live data ingestion occurs every 30 minutes. When an iteration of the extract, transform, and load (ETL) job is complete, this triggers a manual snapshot of the Amazon Redshift cluster. After the snapshot is captured, a new Amazon Redshift cluster is created using that snapshot. Cluster creation time can vary depending on the snapshot volume.

If snapshot creation takes more than 30 minutes, then the ETL job should be stopped, and resume after the snapshot creation is complete. For example, if the ETL job is triggered at 8:00 AM and finishes at 8:10 AM, then snapshot creation starts at 8:10 AM. If it finishes by 8:30 AM (the next ETL job will run at 8:30 AM as per the half-hour interval), then the ETL process continues according to the schedule. Otherwise, the job stops, and resumes after the snapshot completion.

Now we use the snapshot to launch a new RA3 redshift cluster. The process doesn’t pause the existing ETL pipeline, rather it starts writing curated data in parallel to the reserve S3 bucket. The following diagram illustrates this updated workflow.

At this point, the existing cluster is still live and continues to process the live workload. Even if creation of the Amazon Redshift cluster takes time (owing to the huge volume of data), you should still be covered. The curated data in the S3 bucket acts as a staging reserve, and this data should be loaded into the RA3 cluster after its cluster is launched.

Backfill the new RA3 cluster with missing data

After the RA3 cluster has been launched, you need to playback the captured live data from the reserve S3 bucket to the newly created cluster. Playback is only for the duration of the snapshot capture to the current timestamp. With this process, you’re trying to bring the RA3 cluster in sync with the existing live DC2 cluster.

You need to configure an AWS DMS migration task with the reserve S3 bucket as the source endpoint and the newly created RA3 cluster as the target endpoint.

AWS DMS captures ongoing changes to the target data store. This process is called ongoing replication or change data capture (CDC). AWS DMS uses this process when replicating ongoing changes from a source data store. This process works by collecting changes to the database logs using the database engine’s native API. The following diagram illustrates this workflow.

Reconciliation and cutover

Data reconciliation is the process of verification of data between source and target. In this process, target data is compared with source data to ensure that the data is transferred completely without any alterations. To ensure reliability in the pipeline and the data processed, you should create an end-to-end reconciliation report. This report verifies the percentage of matching tables, columns, and data records. It also identifies missing records, missing values, incorrect values, badly formatted values, and duplicated records.

You can define the reconciliation process to check whether both clusters are running in sync. For that you can create simple Python scripts or shell scripts to query the source and target clusters, fetch the results, and compare.

Cutover is the final step of migration, and involves switching the existing cluster with the newly launched cluster. At this point, the clusters are running in parallel. Next, you validate that the downstream data consumption flows are up to date. Verify the reconciliation metrics from the DC2 and RA3 clusters such that table updates are in sync.

You can keep dual write while you switch from the migration data pipeline. If you discover any issues after cutting over, you can switch back to the old data pipeline, which is the source of truth until cutover. In this case, cutover involves updating the DC2 cluster endpoint to the new RA3 cluster endpoint in the application. Make sure to identify a relatively quiet window during  the day to update the endpoint. To keep the same endpoint for your applications and users, you can rename the new RA3 cluster with the same name as the original DC2 cluster. To rename the cluster, modify the cluster in the Amazon Redshift console or ModifyCluster API operation. For more information, see Renaming clusters or ModifyCluster API operation in the Amazon Redshift API Reference.

Up to this point, AWS DMS is continuing to update RA3. After you cut over to RA3, the DC2 cluster is no longer live and you can stop the AWS DMS replication job to RA3. Pause the last snapshot. Delete the reserve S3 bucket and AWS DMS resources used for RA3 load.

Conclusion

In this post, we presented an approach to migrate an existing Amazon Redshift cluster with minimal to no data loss, which also allows the cluster to serve both read and write operations during the resize window. Elastic resize is a quick way to resize your cluster to maintain the same number of slices in the target cluster. Slice mapping reduces the time required to resize a cluster. If you choose a resize configuration that isn’t available on elastic resize, you can choose classic resize or perform a snapshot, restore, and resize.

To learn more about what’s new with RA3 instances, refer to Amazon Redshift RA3 instances with managed storage. Amazon Redshift delivers better price performance and at the same time helps you keep your costs predictable. Amazon Redshift Serverless automatically provisions and scales the data warehouse capacity to deliver high performance for demanding and unpredictable workloads, and you pay only for the resources you use. This provides greater flexibility to choose either or both based on custom requirements. After you’ve made your choice, try the hands-on labs on Amazon Redshift.

About the Authors

Soujanya Konka is a Solutions Architect and Analytics specialist at AWS, focused on helping customers build their ideas on cloud. Expertise in design and implementation of business information systems and Data warehousing solutions. Before joining AWS, Soujanya has had stints with companies such as HSBC, Cognizant.

Dipayan Sarkar is a Specialist Solutions Architect for Analytics at AWS, where he helps customers to modernise their data platform using AWS Analytics services. He works with customer to design and build analytics solutions enabling business to make data-driven decisions.

The 2022 Backup Survey: 54% Report Data Loss With Only 10% Backing Up Daily

Post Syndicated from original https://www.backblaze.com/blog/the-2022-backup-survey-54-report-data-loss-with-only-10-backing-up-daily/

Every June, for Backup Awareness Month, we work with The Harris Poll to gauge the state of backups in the U.S. This is the 14th year of that survey, where we ask simply: “How often do you back up all the data on your computer?”

On occasion, we’ll throw some additional questions into the mix as well, and this year we focused on the confusion we often see between sync and backup services, along with respondents’ history of data loss. The backup frequency results of this year’s survey show that trends are holding pretty steady, but the rest of the results…very interesting!

First Things First: Are YOU Backing Up?

If you’re not backing up, start now and increase the stats for 2023.
 
➔ Sign Up Today

How Backup Frequency Is Trending in 2022

When looking solely at backup frequency, the results are mostly neutral this year when compared to 2021. We see a slight 1% increase in computer owners that are backing up on a yearly basis, but that same 1% decrease in those that are backing up daily. The rest of the results were pretty consistent from year to year.

The main issue we’re seeing here is that the number of computer owners who have never backed up their computer appears to have stopped decreasing, meaning that about 20% of people are still at risk of losing all of their data in the event of a computer crash or loss.

Results are among computer owners.

Some people aren’t into reading charts, so we also have this handy table:

Results are among computer owners.

If you’re not a fan of tables, but do like pie, here’s a comparison of the 2022 data compared to when we first started in 2008:


It’s nice to see the mix changing so much over time, especially with the “never” category fading. While the number of daily backups is still not anywhere close to where we’d like it, the data indicates that:

Overall, computer owners are backing up more frequently than a decade ago. However, as our astute readers know, the longer you go without creating a backup, the more data you are prone to losing should disaster strike.

Who’s “Best” at Backing Up?

Last year, we pored through the data to try and build a “profile” of the person who was most likely to be a “backer upper,” which we had defined as a person who owns a computer and backs it up at least once a day. What we found is that we were looking for:

  • A woman between 35-44 years of age (21% likely to back up versus 9% of those 18-34 and 6% of those 55-64)…
  • Who lives in the Western United States (17% more likely to back up vs. the South and Midwest at 9% and 7%, respectively)…
  • With a household income of over $100K (13% likely to back up their data versus those households of $50K-$74.9K which are at 6%).

Has that changed over the last year? Well, in 2022, the data suggest no statistically significant deviations that we can pull out, so maybe that’s good news across the spectrum?

Is Confusion a Cause for Concern?

While the number of people backing up at least once is good, we think there might still be some confusion in the world about how exactly they are backing up their data and what is getting backed up. We wanted to dive a bit deeper. When looking at the Americans who own a computer:

  • 80% backed up all the data on that computer at least once.
    • 41% of those folks fully back it up once a month or more often.
  • 57% who have ever backed up use a “cloud-based” system as their primary backup.
  • 12% of computer owners use a cloud backup service like Backblaze as their primary backup, and among those who do:
    • 52% say their service automatically backs up all the data on their computer.
    • 25% say it backs up only the data they select with no limitations.
    • 9% say it backs up only the data they select but with some limits.
    • 3% marked “other” and more concerningly…
    • 10% are not sure at all.

    With 57% of computer owners using “the cloud” to back up their data, but only 12% of those using a cloud backup service, we’re left to wonder, what are the others using? In many cases, it’s a cloud drive or cloud sync service which may not actually be performing basic automated backup tasks.

    Refresher: Backup vs. Sync

    We’ve often discussed the differences between sync and backup—how both of them are useful tools, but very different. While sync services are great for collaborating on and sharing data, they are not true backup services in that they’re typically not automated, and don’t provide the same level of protection as dedicated backup services can. And, be careful about only having data in one location—44% lost access to their data when a shared or synced drive was deleted. For more information, read our cloud backup vs. cloud sync blog post!

    Even of those using a proper cloud backup solution, 48% may not be backing up all their data, and 10% of folks aren’t sure at all what their cloud backup service is doing. Yikes.

    We then asked those who use one of the listed backups (i.e., “the cloud,” external hard drive, or NAS) about their confidence level that the service they use is set up to protect all the data on their computer, and 61% of people were not very confident. The numbers are broken down below:

    • 39% were very confident.
    • 48% were somewhat confident.
    • 13% were not at all or not very confident.

    That’s not a ton of confidence, and maybe now is a good time to remind folks to check their backups and to test a restore!

    Why Is Backing Up Important?

    This year’s survey results continue to show us that having a good backup strategy in place, whether for a business or an individual, is a great way to mitigate against different data disasters. Especially when you consider that of Americans who own a computer:

    • 67% report accidentally deleting something.
    • 54% report having lost data.
    • 53% were affected by a security incident.
    • 48% had an external hard drive crash.
      • 21% of those crashes have happened in the last year.
    • 44% lost access to their data when a shared drive or synced drive was deleted.

    External hard drives are a great local backup method, and we recommend them when we discuss having a 3-2-1 backup strategy, but as our own Hard Drive Stats indicate, even in our professional environment, they do fail. And with 48% of computer owners reporting that they experienced a similar failure on their home device, it underscores the importance of having an off-site backup like Backblaze, just in case.

    With over half of computer owners reporting a security incident as well and ransomware on the rise, there’s never been a more appropriate time to start backing up your computer. At Backblaze, we’re on a mission to make storing and using your data astonishingly easy, and we invite you to give our services a try!

    Survey Method:
    This year’s survey was conducted online within the United States by The Harris Poll on behalf of Backblaze from May 19-23, 2022, among 2,068 adults ages 18+, among whom 1,861 own a computer. The sampling precision of Harris online polls is measured by using a Bayesian credible interval. For this study, the sample data is accurate to within +2.8 percentage points using a 95% confidence level.

    Prior year’s surveys were conducted online by The Harris Poll on behalf of Backblaze among U.S. adults ages 18+ who own a computer in May 12-14, 2021 (n=1,870); June 1-3, 2020 (n=1,913); June 6-10, 2019 (n=1,858); June 5-7, 2018 (n=1,871); May 19-23, 2017 (n=1,954); May 13-17, 2016 (n=1,920); May 15-19, 2015 (n=2,009); June 2-4, 2014 (n=1,991); June 13–17, 2013 (n=1,952); May 31–June 4, 2012 (n=2,176); June 28–30, 2011 (n=2,209); June 3–7, 2010 (n=2,051); May 13–14, 2009 (n=2,154); and May 27–29, 2008 (n=2,723).

    For complete survey methodologies, including weighting variables and subgroup sample sizes, please contact Backblaze.

    The post The 2022 Backup Survey: 54% Report Data Loss With Only 10% Backing Up Daily appeared first on Backblaze Blog | Cloud Storage & Cloud Backup.

    [$] Fedora, FFmpeg, Firefox, Flatpak, and Fusion

    Post Syndicated from original https://lwn.net/Articles/897793/

    Fedora’s objective to become the desktop Linux distribution of choice has
    long been hampered by Red Hat’s risk-averse legal department, which
    strictly limits the type of software that Fedora can ship. Specifically,
    anything that might be encumbered by patents is off-limits, with the result
    that much of the media that users might find on the net is unplayable. This
    situation has improved over the years as the result of a lot of work within
    the Fedora project, but it still puts Fedora at a disadvantage relative to
    some other distributions. A recent
    discussion on video support, though, shines a light on how some surprising
    legal reasoning may be providing a way out of this problem; that way
    may not be pleasing to all involved, however.

    New Report Shows What Data Is Most at Risk to (and Prized by) Ransomware Attackers

    Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/06/16/new-report-shows-what-data-is-most-at-risk-to-and-prized-by-ransomware-attackers/

    New Report Shows What Data Is Most at Risk to (and Prized by) Ransomware Attackers

    Ransomware is one of the most pressing and diabolical threats faced by cybersecurity teams today. Gaining access to a network and holding that data for ransom has caused billions in losses across nearly every industry and around the world. It has stopped critical infrastructure like healthcare services in its tracks, putting the lives and livelihoods of many at risk.

    In recent years, threat actors have upped the ante by using “double extortion” as a way to inflict maximum pain on an organization. Through this method, not only are threat actors holding data hostage for money – they also threaten to release that data (either publicly or for sale on dark web outlets) to extract even more money from companies.

    At Rapid7, we often say that when it comes to ransomware, we may all be targets, but we don’t all have to be victims. We have means and tools to mitigate the impact of ransomware — and one of the most important assets we have on our side is data about ransomware attackers themselves.

    Reports about trends in ransomware are pretty common these days. But what isn’t common is information about what kinds of data threat actors prefer to collect and release.

    A new report from Rapid7’s Paul Prudhomme uses proprietary data collection tools to analyze the disclosure layer of double-extortion ransomware attacks. He identified the types of data attackers initially disclose to coerce victims into paying ransom, determining trends across industry, and released it in a first-of-its-kind analysis.

    “Pain Points: Ransomware Data Disclosure Trends” reveals a story of how ransomware attackers think, what they value, and how they approach applying the most pressure on victims to get them to pay.

    The report looks at all ransomware data disclosure incidents reported to customers through our Threat Command threat intelligence platform (TIP). It also incorporates threat intelligence coverage and Rapid7’s institutional knowledge of ransomware threat actors.

    From this, we were able to determine:

    • The most common types of data attackers disclosed in some of the most highly affected industries, and how they differ
    • How leaked data differs by threat actor group and target industry
    • The current state of the ransomware market share among threat actors, and how that has changed over time

    Finance, pharma, and healthcare

    Overall, trends in ransomware data disclosures pertaining to double extortion varied slightly, except in a few key verticals: pharmaceuticals, financial services, and healthcare. In general, financial data was leaked most often (63%), followed by customer/patient data (48%).

    However, in the financial services sector, customer data was leaked most of all, rather than financial data from the firms themselves. Some 82% of disclosures linked to the financial services sector were of customer data. Internal company financial data, which was the most exposed data in the overall sample, made up just 50% of data disclosures in the financial services sector. Employees’ personally identifiable information (PII) and HR data were more prevalent, at 59%.

    In the healthcare and pharmaceutical sectors, internal financial data was leaked some 71% of the time, more than any other industry — even the financial services sector itself. Customer/patient data also appeared with high frequency, having been released in 58% of disclosures from the combined sectors.

    One thing that stood out about the pharmaceutical industry was the prevalence of threat actors to release intellectual property (IP) files. In the overall sample, just 12% of disclosures included IP files, but in the pharma industry, 43% of all disclosures included IP. This is likely due to the high value placed on research and development within this industry.

    The state of ransomware actors

    One of the more interesting results of the analysis was a clearer understanding of the state of ransomware threat actors. It’s always critical to know your enemy, and with this analysis, we can pinpoint the evolution of ransomware groups, what data the individual groups value for initial disclosures, and their prevalence in the “market.”

    For instance, between April and December 2020, the now-defunct Maze Ransomware group was responsible for 30%. This “market share” was only slightly lower than that of the next two most prevalent groups combined (REvil/Sodinokibi at 19% and Conti at 14%). However, the demise of Maze in November of 2020 saw many smaller actors stepping in to take its place. Conti and REvil/Sodinokibi swapped places respectively (19% and 15%), barely making up for the shortfall left by Maze. The top five groups in 2021 made up just 56% of all attacks with a variety of smaller, lesser-known groups being responsible for the rest.

    Recommendations for security operations

    While there is no silver bullet to the ransomware problem, there are silver linings in the form of best practices that can help to protect against ransomware threat actors and minimize the damage, should they strike. This report offers several that are aimed around double extortion, including:

    • Going beyond backing up data and including strong encryption and network segmentation
    • Prioritizing certain types of data for extra protection, particularly for those in fields where threat actors seek out that data in particular to put the hammer to those organizations the hardest
    • Understanding that certain industries are going to be targets of certain types of leaks and ensuring that customers, partners, and employees understand the heightened risk of disclosures of those types of data and to be prepared for them

    To get more insights and view some (well redacted) real-world examples of data breaches, check out the full paper.

    Additional reading:

    NEVER MISS A BLOG

    Get the latest stories, expertise, and news about security today.

    Security updates for Thursday

    Post Syndicated from original https://lwn.net/Articles/898121/

    Security updates have been issued by Fedora (containerd, golang-github-containerd-cni, golang-github-containernetworking-cni, golang-x-sys, kernel, and qt5-qtbase), Oracle (kernel, kernel-container, microcode_ctl, subversion:1.14, and xz), Red Hat (.NET 6.0, .NET Core 3.1, cups, and xz), Scientific Linux (xz), SUSE (caddy, chromium, librecad, libredwg, varnish, and webkit2gtk3), and Ubuntu (bluez).

    Attacking the Performance of Machine Learning Systems

    Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2022/06/attacking-the-performance-of-machine-learning-systems.html

    Interesting research: “Sponge Examples: Energy-Latency Attacks on Neural Networks“:

    Abstract: The high energy costs of neural network training and inference led to the use of acceleration hardware such as GPUs and TPUs. While such devices enable us to train large-scale neural networks in datacenters and deploy them on edge devices, their designers’ focus so far is on average-case performance. In this work, we introduce a novel threat vector against neural networks whose energy consumption or decision latency are critical. We show how adversaries can exploit carefully-crafted sponge examples, which are inputs designed to maximise energy consumption and latency, to drive machine learning (ML) systems towards their worst-case performance. Sponge examples are, to our knowledge, the first denial-of-service attack against the ML components of such systems. We mount two variants of our sponge attack on a wide range of state-of-the-art neural network models, and find that language models are surprisingly vulnerable. Sponge examples frequently increase both latency and energy consumption of these models by a factor of 30×. Extensive experiments show that our new attack is effective across different hardware platforms (CPU, GPU and an ASIC simulator) on a wide range of different language tasks. On vision tasks, we show that sponge examples can be produced and a latency degradation observed, but the effect is less pronounced. To demonstrate the effectiveness of sponge examples in the real world, we mount an attack against Microsoft Azure’s translator and show an increase of response time from 1ms to 6s (6000×). We conclude by proposing a defense strategy: shifting the analysis of energy consumption in hardware from an average-case to a worst-case perspective.

    Attackers were able to degrade the performance so much, and force the system to waste so many cycles, that some hardware would shut down due to overheating. Definitely a “novel threat vector.”

    The collective thoughts of the interwebz