Мерките към прокремълските пропагандни медии: деветият санкционен пакет на ЕС влезе в сила

Post Syndicated from nellyo original https://nellyo.wordpress.com/2023/02/02/restrictive_9/

 

След 2014  ЕС въвежда ограничителни мерки с оглед действията на Русия в Украйна.  Мерките стават известни като “санкционни пакети” на ЕС по повод Украйна.  Приети са девет санкционни пакета, четем и за   изготвяне  на десети пакет.

Мерките засягат различни области, включително медии. Съветът на ЕС (Съветът) взема решение с единодушие за приемането, подновяването или отмяната на ограничителните мерки (санкции) въз основа на законодателни предложения на върховния представител на ЕС. След като държавите — членки на ЕС, постигнат политическо споразумение, върховният представител/заместник-председател и Комисията изготвят необходимите правни актове под формата на решение на Съвета и придружаващ го регламент на Съвета, и ги представят на Съвета за приемане.

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

Повече за същността на ограничителните мерки – на сайта на ЕК.

1

Какви мерки

Мерките към пропагандните медии, свързани с Кремъл, са в следната разпоредба:

„Член 2е.
1. На операторите се забранява излъчването или предоставянето на възможност, улесняването или допринасяне по друг начин за излъчването на каквото и да е съдържание от юридическите лица, образуванията или органите, изброени в приложение XV, включително чрез предаване или разпространение чрез какъвто и да е способ, като кабел, сателит, телевизия през интернет протокол, доставчици на интернет услуги, платформи или приложения за споделяне на видеоклипове в интернет, независимо дали са нови или вече инсталирани.
2. Спира се срокът на действие на всички лицензии или разрешения за телевизионно и радиоразпръскване, издадени на юридическите лица, образуванията или органите, изброени в приложение XV, както и на всички споразумения за пренос и разпространение, сключени с посочените лица, образувания или органи.“
3. Забранява се рекламирането на продукти или услуги с всякакво съдържание, произведени или излъчени от юридическите лица, образуванията или органите, изброени в приложение XV, включително чрез предаване или разпространение чрез какъвто и да е способ, посочен в параграф 1.”

 

2

Кои медии

Първо за деветия, последен пакет: на 16 декември 2022 г. Съветът прие Регламент (ЕС) 2022/2474, с който беше изменен за пореден път  Регламент (ЕС) № 833/2014  на Съвета относно ограничителни мерки с оглед на действията на Русия, дестабилизиращи положението в Украйна, и – освен множество други мерки в различни отрасли. В отделно приложение бяха въведени ограничителни мерки за преустановяване на дейността по разпространение в Съюза или на разпространение, насочено към Съюза, на   медии по приложение V:

“Приложение V

В приложение XV към Регламент (ЕС) № 833/2014 се добавят следните образувания:

  1. NTV/NTV Mir
  2. Rossiya 1
  3. REN TV
  4. Pervyi Kanal“

Общият списък на медиите  в приложение XV към Регламент (ЕС) № 833/2014, вече включва:

  1. RT – Russia Today English
  2. RT – Russia Today UK
  3. RT – Russia Today Germany
  4. RT – Russia Today France
  5. RT- Russia Today Spanish
  6. Sputnik
  7. Rossiya RTR / RTR Planeta
  8. Rossiya 24 / Russia 24
  9. TV Centre International
  10. NTV/NTV Mir
  11. Rossiya 1
  12. REN TV
  13. Pervyi Kanal“

Освен  медиите по Приложение XV,  на ограничителни мерки подлежат и  образувания (предприятия, компании – вкл. медии), които не са посочени поименно в Приложение XV, но са  финансирани от лица в ограничителния списък.

Има съобщения, че  RT France   прекратява дейността си.

Докато се сложи край на агресията, доколкото са  съществена и пряка заплаха

Според Съвета на ЕС “тези медии са използвани от руското правителство като инструменти за манипулиране на информацията и насърчаване на дезинформацията относно нахлуването в Украйна, включително за пропаганда, с цел да се дестабилизират съседните на Русия държави, ЕС и неговите държави членки.”

В рециталите на Регламент (ЕС) 2022/2474 по-конкретно се казва следното:

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

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

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

Тези пропагандни дейности се осъществяват чрез редица медии под постоянния пряк или непряк контрол на ръководството на Руската федерация. Подобни действия представляват съществена и пряка заплаха за обществения ред и сигурност на Съюза. Тези медии имат ключова роля за пропагандирането на агресията срещу Украйна и за дестабилизирането на съседните на Украйна държави.

С оглед на сериозната обстановка и в отговор на действията на Русия, дестабилизиращи положението в Украйна, е необходимо в съответствие с основните права и свободи, признати в Хартата на основните права, по-специално в посоченото в член 11 от нея право на свобода на изразяване на мнение, включително на получаване и разпространяване на информация, да се въведат допълнителни ограничителни мерки за прекратяване на излъчването в Съюза от страна на такива медии, както и на излъчванията им, насочени към Съюза. Мерките следва да се запазят, докато се сложи край на агресията срещу Украйна и докато Руската федерация и свързаните с нея медии престанат да извършват пропагандни действия срещу Съюза и неговите държави членки.

В съответствие с основните права и свободи, признати в Хартата на основните права, и по-специално с признатите в членове 11, 16 и 17 от нея съответно право на свобода на изразяване на мнение, включително на получаване и разпространяване на информация, свобода на стопанска инициатива и право на собственост, тези мерки не пречат на тези медии и техния персонал да извършват в Съюза дейности, различни от излъчване, например проучвания и интервюта. По-специално тези мерки не променят задължението да се зачитат правата, свободите и принципите, посочени в член 6 от Договора за Европейския съюз, включително в Хартата на основните права, както и в конституциите на държавите членки, в рамките на съответното им приложно поле.”

4

Мерките от деветия пакет се прилагат от 1 февруари 2023

Последният регламент от декември 2022, съдържащ мерки към медии по повод агресията в Украйна,   предвижда   Съветът на ЕС да упражни изпълнителни правомощия с цел да реши, след разглеждане на съответните случаи, дали ограничителните мерки да започнат да се прилагат. Съгласно член 1, точка 19 от Регламент (ЕС) 2022/2474 приложимостта на тези мерки по отношение на една или няколко от тези медии зависи от приемането на актове за изпълнение от страна на Съвета. Без да съм запозната с конкретната аргументация за тези изпълнителни регламенти, мисля, че с тях се цели изпълнение на изискването за пропорционалност – защото Съветът е разгледал междувременно всеки т.нар. “съответен случай”.

На 30 януари 2023 в Официален вестник на ЕС е публикуван  Регламент за изпълнение (ЕС) 2023/180 от 27 януари 2023 година за прилагане на Регламент (ЕС) 2022/2474 за изменение на Регламент (ЕС) № 833/2014 относно ограничителни мерки с оглед на действията на Русия, дестабилизиращи положението в Украйна.

“След като разгледа съответните случаи, Съветът приема, че съответните мерки, посочени в член 2е от Регламент (ЕС) № 833/2014, следва да се прилагат от 1 февруари 2023 г. по отношение на всички образувания, посочени в приложение V към Регламент (ЕС) 2022/2474, и

ПРИЕ НАСТОЯЩИЯ РЕГЛАМЕНТ:

Член 1

Мерките, посочени в член 2е от Регламент (ЕС) № 833/2014, се прилагат, считано от 1 февруари 2023 г., по отношение на всички образувания, посочени в приложение V към Регламент (ЕС) 2022/2474.

Член 2

Настоящият регламент влиза в сила в деня след публикуването му в Официален вестник на Европейския съюз.

Настоящият регламент е задължителен в своята цялост и се прилага пряко във всички държави членки.”

5

“Регламентите се прилагат  пряко”

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

Ако беше така, нямаше да има    цял списък  закони, с които се приемат мерки за прилагане на регламенти, да дам пример само с GDP и Закона за защита на личните данни: § 1а.  Този закон предвижда мерки по прилагане на Регламент (ЕС) 2016/679 на Европейския парламент и на Съвета от 27 април 2016 г. относно защитата на физическите лица във връзка с обработването на лични данни и относно свободното движение на такива данни.

 
 
Смятам още, че е особено необходима  институционална реакция на компетентните органи, за да се информират хората защо на мястото на една програма се появява съобщение, че е спряна  – дори не пише на основание на кой регламент и за какво се отнася той.
 
Ако не ни информират институциите, които по закон прилагат правото на Европейския съюз, ще се намери кой да ни информира – и никой няма да е виновен, че има свободно място за заемане от анти-ЕС формации и агитки.
 
 
IMG_4883
 

 

Cloudflare’s handling of a bug in interpreting IPv4-mapped IPv6 addresses

Post Syndicated from Lucas Ferreira original https://blog.cloudflare.com/cloudflare-handling-bug-interpreting-ipv4-mapped-ipv6-addresses/

Cloudflare's handling of a bug in interpreting IPv4-mapped IPv6 addresses

Cloudflare's handling of a bug in interpreting IPv4-mapped IPv6 addresses

In November 2022, our bug bounty program received a critical and very interesting report. The report stated that certain types of DNS records could be used to bypass some of our network policies and connect to ports on the loopback address (e.g. 127.0.0.1) of our servers. This post will explain how we dealt with the report, how we fixed the bug, and the outcome of our internal investigation to see if the vulnerability had been previously exploited.

RFC 4291 defines ways to embed an IPv4 address into IPv6 addresses. One of the methods defined in the RFC is to use IPv4-mapped IPv6 addresses, that have the following format:

   |                80 bits               | 16 |      32 bits        |
   +--------------------------------------+--------------------------+
   |0000..............................0000|FFFF|    IPv4 address     |
   +--------------------------------------+----+---------------------+

In IPv6 notation, the corresponding mapping for 127.0.0.1 is ::ffff:127.0.0.1 (RFC 4038)

The researcher was able to use DNS entries based on mapped addresses to bypass some of our controls and access ports on the loopback address or non-routable IPs.

This vulnerability was reported on November 27 to our bug bounty program. Our Security Incident Response Team (SIRT) was contacted, and incident response activities began shortly after the report was filed. A hotpatch was deployed three hours later to prevent exploitation of the bug.

Date Time (UTC) Activity
27 November 2022 20:42 Initial report to Cloudflare’s bug bounty program
21:04 SIRT oncall is paged
21:15 SIRT manager on call starts working on the report
21:22 Incident declared and team is assembled and debugging starts
23:20 A hotfix is ready and deployment starts
23:47 Team confirms that the hotfix is deployed and working
23:58 Team investigates if other products are affected. Load Balancers and Spectrum are potential targets. Both products are found to be unaffected by the vulnerability.
28 November 2022 21:14 A permanent fix is ready
29 November 2022 21:34 Permanent fix is merged

Blocking exploitation

Immediately after the vulnerability was reported to our Bug Bounty program, the team began working to understand the issue and find ways to quickly block potential exploitation. It was determined that the fastest way to prevent exploitation would be to block the creation of the DNS records required to execute the attack.

The team then began to implement a patch to prevent the creation of DNS records that include IPv6 addresses that map loopback or RFC 1918 (internal) IPv4 addresses. The fix was fully deployed and confirmed three hours after the report was filed. We later realized that this change was insufficient because records hosted on external DNS servers could also be used in this attack.

The exploit

The exploit provided consisted of the following: a DNS entry, and a Cloudflare Worker. The DNS entry was an AAAA record pointing to ::ffff:127.0.0.1:

exploit.example.com AAAA ::ffff:127.0.0.1

The worker included the following code:

export default {
    async fetch(request) {
        const requestJson = await request.json()
        return fetch(requestJson.url, requestJson)
    }
}

The Worker was given a custom URL such as proxy.example.com.

With that setup, it was possible to make the worker attempt connections on the loopback interface of the server where it was running. The call would look like this:

curl https://proxy.example.com/json -d '{"url":"http://exploit.example.com:80/url_path"}'

The attack could then be scripted to attempt to connect to multiple ports on the server.

It was also found that a similar setup could be used with other IPv4 addresses to attempt connections into internal services. In this case, the DNS entry would look like:

exploit.example.com AAAA ::ffff:10.0.0.1

This exploit would allow an attacker to connect to services running on the loopback interface of the server. If the attacker was able to bypass the security and authentication mechanisms of a service, it could impact the confidentiality and integrity of data. For services running on other servers, the attacker could also use the worker to attempt connections and map services available over the network. As in most networks, Cloudflare’s network policies and ACLs must allow a few ports to be accessible. These ports would be accessible by an attacker using this exploit.

Investigation

We started an investigation to understand the root cause of the problem and created a proof-of-concept that allowed the team to debug the issue. At the same time, we started a parallel investigation to determine if the issue had been previously exploited.

It all happened when two bugs collided.

The first bug happened in our internal DNS system which is responsible for mapping hostnames to IP addresses of our customers’ origin servers (the DNS system). When the DNS system tried to answer a query for the DNS record from exploit.example.com, it serialized the IP as a string. The Golang net library used for DNS automatically converted the IP ::ffff:10.0.0.1 to string “10.0.0.1”. However, the DNS system still treated it as an IPv6 address. So a query response {ipv6: “10.0.0.1”} was returned.

The second bug was in our internal HTTP system (the proxy) which is responsible for forwarding HTTP traffic to customer’s origin servers. The bug happened in how the proxy validates this DNS response, {ipv6: “10.0.0.1”}. The proxy has two deny lists of IPs that are not allowed to be used, one for IPv4 and one for IPv6. These lists contain localhost IPs and private IPs. The bug was that the proxy system compared the address 10.0.0.1 against the IPv6 deny list because the address was in the “ipv6” section. Naturally the address didn’t match any entry in the deny list. So the address was allowed to be used as an origin IP address.

The second investigation team searched through the logs and found no evidence of previous exploitation of this vulnerability. The team also checked Cloudflare DNS for entries using IPv4-mapped IPv6 addresses and determined that all the existing entries had been used for testing purposes. As of now, there are no signs that this vulnerability could have been previously used against Cloudflare systems.

Remediating the vulnerability

To address this issue we implemented a fix in the proxy service to correctly use the deny list of the parsed address, not the deny list of the IP family the DNS API response claimed to be, to validate the IP address. We confirmed both in our test and production environments that the fix did prevent the issue from happening again.

Beyond maintaining a bug bounty program, we regularly perform internal security reviews and hire third-party firms to audit the software we develop. But it is through our bug bounty program that we receive some of the most interesting and creative reports. Each report has helped us improve the security of our services. We invite those that find a security issue in any of Cloudflare’s services to report it to us through HackerOne.

AIs as Computer Hackers

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/02/ais-as-computer-hackers.html

Hacker “Capture the Flag” has been a mainstay at hacker gatherings since the mid-1990s. It’s like the outdoor game, but played on computer networks. Teams of hackers defend their own computers while attacking other teams’. It’s a controlled setting for what computer hackers do in real life: finding and fixing vulnerabilities in their own systems and exploiting them in others’. It’s the software vulnerability lifecycle.

These days, dozens of teams from around the world compete in weekend-long marathon events held all over the world. People train for months. Winning is a big deal. If you’re into this sort of thing, it’s pretty much the most fun you can possibly have on the Internet without committing multiple felonies.

In 2016, DARPA ran a similarly styled event for artificial intelligence (AI). One hundred teams entered their systems into the Cyber Grand Challenge. After completing qualifying rounds, seven finalists competed at the DEFCON hacker convention in Las Vegas. The competition occurred in a specially designed test environment filled with custom software that had never been analyzed or tested. The AIs were given 10 hours to find vulnerabilities to exploit against the other AIs in the competition and to patch themselves against exploitation. A system called Mayhem, created by a team of Carnegie-Mellon computer security researchers, won. The researchers have since commercialized the technology, which is now busily defending networks for customers like the U.S. Department of Defense.

There was a traditional human–team capture-the-flag event at DEFCON that same year. Mayhem was invited to participate. It came in last overall, but it didn’t come in last in every category all of the time.

I figured it was only a matter of time. It would be the same story we’ve seen in so many other areas of AI: the games of chess and go, X-ray and disease diagnostics, writing fake news. AIs would improve every year because all of the core technologies are continually improving. Humans would largely stay the same because we remain humans even as our tools improve. Eventually, the AIs would routinely beat the humans. I guessed that it would take about a decade.

But now, five years later, I have no idea if that prediction is still on track. Inexplicably, DARPA never repeated the event. Research on the individual components of the software vulnerability lifecycle does continue. There’s an enormous amount of work being done on automatic vulnerability finding. Going through software code line by line is exactly the sort of tedious problem at which machine learning systems excel, if they can only be taught how to recognize a vulnerability. There is also work on automatic vulnerability exploitation and lots on automatic update and patching. Still, there is something uniquely powerful about a competition that puts all of the components together and tests them against others.

To see that in action, you have to go to China. Since 2017, China has held at least seven of these competitions—called Robot Hacking Games—many with multiple qualifying rounds. The first included one team each from the United States, Russia, and Ukraine. The rest have been Chinese only: teams from Chinese universities, teams from companies like Baidu and Tencent, teams from the military. Rules seem to vary. Sometimes human–AI hybrid teams compete.

Details of these events are few. They’re Chinese language only, which naturally limits what the West knows about them. I didn’t even know they existed until Dakota Cary, a research analyst at the Center for Security and Emerging Technology and a Chinese speaker, wrote a report about them a few months ago. And they’re increasingly hosted by the People’s Liberation Army, which presumably controls how much detail becomes public.

Some things we can infer. In 2016, none of the Cyber Grand Challenge teams used modern machine learning techniques. Certainly most of the Robot Hacking Games entrants are using them today. And the competitions encourage collaboration as well as competition between the teams. Presumably that accelerates advances in the field.

None of this is to say that real robot hackers are poised to attack us today, but I wish I could predict with some certainty when that day will come. In 2018, I wrote about how AI could change the attack/defense balance in cybersecurity. I said that it is impossible to know which side would benefit more but predicted that the technologies would benefit the defense more, at least in the short term. I wrote: “Defense is currently in a worse position than offense precisely because of the human components. Present-day attacks pit the relative advantages of computers and humans against the relative weaknesses of computers and humans. Computers moving into what are traditionally human areas will rebalance that equation.”

Unfortunately, it’s the People’s Liberation Army and not DARPA that will be the first to learn if I am right or wrong and how soon it matters.

This essay originally appeared in the January/February 2022 issue of IEEE Security & Privacy.

Blocking free API access to Twitter doesn’t stop abuse

Post Syndicated from Matthew Garrett original https://mjg59.dreamwidth.org/65647.html

In one week from now, Twitter will block free API access. This prevents anyone who has written interesting bot accounts, integrations, or tooling from accessing Twitter without paying for it. A whole number of fascinating accounts will cease functioning, people will no longer be able to use tools that interact with Twitter, and anyone using a free service to do things like find Twitter mutuals who have moved to Mastodon or to cross-post between Twitter and other services will be blocked.

There’s a cynical interpretation to this, which is that despite firing 75% of the workforce Twitter is still not profitable and Elon is desperate to not have Twitter go bust and also not to have to tank even more of his Tesla stock to achieve that. But let’s go with the less cynical interpretation, which is that API access to Twitter is something that enables bot accounts that make things worse for everyone. Except, well, why would a hostile bot account do that?

To interact with an API you generally need to present some sort of authentication token to the API to prove that you’re allowed to access it. It’s easy enough to restrict issuance of those tokens to people who pay for the service. But, uh, how do the apps work? They need to be able to communicate with the service to tell it to post tweets, retrieve them, and so on. And the simple answer to that is that they use some hardcoded authentication tokens. And while registering for an API token yourself identifies that you’re not using an official client, using the tokens embedded in the clients makes it look like you are. If you want to make it look like you’re a human, you’re already using tokens ripped out of the official clients.

The Twitter client API keys are widely known. Anyone who’s pretending to be a human is using those already and will be unaffected by the shutdown of the free API tier. Services like movetodon.org do get blocked. This isn’t an anti-abuse choice. It’s one that makes it harder to move to other services. It’s one that blocks a bunch of the integrations and accounts that bring value to the platform. It’s one that hurts people who follow the rules, without hurting the ones who don’t. This isn’t an anti-abuse choice, it’s about trying to consolidate control of the platform.

comment count unavailable comments

Какво се случва с електронната идентификация

Post Syndicated from Bozho original https://blog.bozho.net/blog/4004

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

Предисторията накратко: през 2016 г., с мое експертно участие, а подготвен и приет Закона за електронната идентификация. След това в много кратък срок (3-4 месеца) написахме и правилник за прилагане на закона, и съвместно с Информационно обслужване подготвихме техническа спецификация, по която МВР да проведе процедура за възлагане на обществена поръчка, с която да се изгради цялата софтуерна инфраструктура.

МВР обяви поръчката в началото на 2017 г. и след няколко странни и фиктивни жалби я прекрати в средата годината. Точно 1 година по-късно МВР обяви „голяма“ процедура за новите лични документи, като електронната идентификация беше включена в тази процедура като отделна дейност. Това, според мен, беше грешка и всички последващи събития го показват. Процедурата беше по особен ред по Закона за обществените поръчки със секретни елементи (заради личните документи), с няколко етапа, което доведе до това изпълнител да бъде избран чак през пролетта на 2020 г. За съжаление, методиката за оценка имаше една голяма недомислица, която позволяваше с висока цена по една дейност да се субсидира друга дейност с цел получаване на по-висока оценка (при прогнозна стойност за eID от около 19 милиона, избраният участник е оферирал около 80 милиона). Отчасти поради това, а и заради големия материален интерес, решението беше обжалвано от загубилия кандидат.

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

Първата ми задача беше да подготвим техническа спецификация и да приемем решение на Министерски съвет за конкретни срокове.. В периода от 2016 г. до 2022 г. смартфоните се развиха достатъчно, така че да са сигурен носител на криптографски ключове (или части от тях), така че да могат да се използват вместо отделен носител (лична карта, друга карта или четец-„флашка“). В поръчката на МВР такова мобилно приложение нямаше – беше загатнато като опция, при технологична възможност, след предложение от изпълнителя и одобрение от възложителя. Поради което това приложение и прилежащата инфраструктура не противоречаха на поръчката на МВР, която продължаваше да е „забила“. Има предвидено мобилно приложение с изцяло различен обхват – четец на лични документи по NFC, както е предвидено в Правилника за прилагане на Закона за електронна идентификация. В обновената спецификация на МВР от 2018 г. също има загатнато съхранение на криптографски ключове в мобилното устройството, но буквално в едни ред в скоби, което не е ясно какво ще произведе като резултат – напр. един проблем там е, че е заложено използване на мобилен номер, което увеличава рисковете за сигурността.

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

В законодателната програма на министерството (вкл. приета с решение на Министерски съвет за извършване на оценка на въздействието) бяхме приели изменение на Закона за електронната идентификация, за да „слеем“ двете системи. За съжаление, правителството беше свалено и тази инициатива спря. Все пак в проекта за изменения на Закона за електронното управление предвидихме изрична уредба на системата за електронна идентификация на министерството. Такава не е стриктно необходима, тъй като тези неща произтичат от Регламент на ЕС и изпълнителната власт има възможност да урежда различни средства за електронна идентификация. Уредбата в закон е по-скоро поради друга пречка, която МВР постави в последните седмици на мандата ни – че отказваше данни за българските документи за самоличност, които биха направили възможна отдалечената първоначална регистрация. Имам и парламентарен въпрос по темата няколко месеца по-късно. Това, в комбинация с предсрочните избори, по които Информационно обслужване има ангажимент по закон, забави дори спря разработването на приложението, както е видно от отговора на министъра на електронното управление по друг мой въпрос.

В края на декември, Съдът на ЕС взе решение, в съответствие с което ВАС решава делото в полза на избрания изпълнител и МВР сключва договор. Това е противно на очакванията на МВР и поставя въпроси за ефективността на съвместното съществуване на „старата“ система по проекта на МВР и новата на МЕУ (министерство на електронното управление). Именно поради това свиках среща в Народното събрание с МВР, МЕУ и Информационно обслужване, на която изразих моите притеснения и дадох конкретни идеи. Няколко дни след това изпратих официално искане за становище до двете министерства, на което все още нямам отговор.

След обсъждане с други парламентарни групи, подготвих и изменения на Закона за електронната идентификация, с които да се уреди сливането на двете системи в рамките на процедурата на МВР и включването на МЕУ като съвместен възложител. За съжаление Народното събрание приключва своя живот и мнозинството няма достатъчно мотивация да разгледа Закона за електронното управление и съответно да въведем тези изменения в другия закон. Това нежелание за уж консенсусен законопроект беше видно и по много други законопроекти, но тук дори е отчетено с гласуване, когато един късен следобед предложих заседанието да продължи до приемането на този законопроект, залата (с изключение на ДБ и ПП) гласува „против“ (или „въздържал се“), а законопроектът няколко седмици беше включван толкова назад в дневния ред, с ясното съзнание от определящите дневния ред, че до него няма да се стигне.

По същество – смятам, че МВР не трябва да е орган за електронна идентификация. През 2016 г. това беше единственият възможен орган, тъй като Държавна агенция „Електронно управление“ още не беше създадена. Министерството, надграждащо агенцията, се появи в нашето правителство в края на 2021 г. (на практика в началото на 2022). В момента именно то е най-подходящо за единствен орган за електронна идентификация, без това да пречи на процедурата на МВР. Разработеното от Информационно обслужване може да се прехвърли в МВР и да бъде довършено от избрания от МВР изпълнител, като след това всички системи бъдат прехвърлени на МЕУ, за да оперира системата.

В последните 6 месеца, основно заради гореспоменатия отказ на МВР да предостави достъп до данни, приложението не е напреднало и е замразено (затова и все още няма качен изходен код). Смятам, че този отказ е незаконосъобразен, но това в крайна сметка е и политическо решение. Занапред ще направя възможното да има ясна концепция как да се процедира с вече изградените функционалности и как да се слеят със системите на МВР, което според мен е правилният път напред. А прехвърлянето от МВР към МЕУ ще направим в следващия парламент.

Проактивността на нашето правителство по темата даде надежда, че в края на 2022 г. приложението (по подобие на естонското SmartID, холандското DigiD, датското MitID и украинското Diia), може да заработи и съответно много услуги да станат удобни и достъпни за гражданите и бизнеса. За съжаление тази проактивност отстъпи на административно безвремие, но това не е обвинение към някого, а обичайното състояние на нещата. За преодоляване на съпротивителните сили на административното безвремие е нужно политическо мнозинство, каквото служебният кабинет няма.

В следващите месец все пак има нужда от проактивност, за да се използва вече разработеното, за да се съкратят сроковете, предвидени в процедурата на МВР. Иначе ще е готово след година (по спомен за графика на поръчката на МВР) и ще продължим да пилеем време и да отлагаме ефективното електронно управление. Ще опитам да помагам по тази линия, за бъде постигната целта.

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

Материалът Какво се случва с електронната идентификация е публикуван за пръв път на БЛОГодаря.

Канада: IP-aдресите като лични данни

Post Syndicated from nellyo original https://nellyo.wordpress.com/2023/02/02/ip-13/

Върховният съд на Канада (ВКС) гледа делото Andrei Bykovets v. His Majesty the King (40269).

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

Първоинстанционният съд прилага теста за “оправдано очакване за поверителност” и стига до извода, че няма нарушение на Хартата.

Пред Апелативния съд жалбоподателят обръща внимание, че няма съдебен акт, на базата на който полицията да получи IP-адресите.  Позовава се на предходно решение на съда по делото R v Spencer , 2014 SCC 43,  според което полицията трябва да получи съдебно разрешение, преди да поиска от доставчик на интернет услуги (ISP) да идентифицира конкретен потребител, свързан с конкретен IP адрес.

Но в случая  R срещу Spencer  полицията е получила IP адрес и неговите   данни без съдебно разрешение, докато в този случай полицията е получила само IP адреси . Според някои съдии делото е неразличимо от R v Spencer  предвид потенциала на IP адрес да идентифицира едно лице. Ако един IP адрес сам по себе си не разкрива нищо, освен ако не е комбиниран с   данни за лицето, защо полицията се нуждае от заповед за достъп до него?  

Централната задача е балансирането на  полицейско разследване със защита на личния живот. Може ли полицията да изисква информация за IP адрес без съдебен акт? Върховният съд ще даде отговор.

За европейски контекст вж решение на Съда на ЕС по  дело C‑582/14 и GDPR, рецитал 30

За български контекст вж Становище на КЗЛД

 

На Путин ли е войната, или на руснаците? Данните говорят

Post Syndicated from Йоанна Елми original https://www.toest.bg/na-putin-li-e-voynata-ili-na-rusnatsite-dannite-govoryat/

„Обърнете внимание, че е възможно резултатите от изследвания по редица въпроси относно ситуацията в Украйна да се отклоняват от реалните настроения. Руснаците се боят да говорят на тази тема – наблюдава се увеличение на отказите за участие и спад в искреността на отговорите.“

На Путин ли е войната, или на руснаците? Данните говорят

Така са представени резултатите от изследване на нагласите спрямо инвазията в Украйна, проведено от руската комуникационна агенция Russian Field.

Почти година след началото на войната въпросът дали я води само Путин, или я подкрепя целият руски народ, продължава да разделя експертите. Изследване на Института Open Minds дава отговор, сравнявайки отворени с официални руски данни.

Според данните подкрепата за военните действия срещу Украйна зависи от тона на властта. Тази подкрепа обаче не означава готовност за мобилизация – едва около 30% от руснаците са готови лично да се включат във войната. По-голяма част от руското население (39%) би предпочела мирни преговори пред продължаване на конфликта. Анализ на дискусии в социалните мрежи сочи, че недоволството от управлението на Путин нараства.

В доклада на Open Minds са сравнени официални данни на Росстат, според които около 97 000 души са напуснали страната през първите шест месеца от началото на конфликта, с данни от Казахстан, Грузия и ЕС, които показват, че при обявяването на мобилизацията през септември 200 000 души са напуснали Русия в рамките на 9 дни. Ако сентенцията, че истината е някъде по средата, важи във време на война и пропаганда, то проучването на Open Minds със сигурност е стъпка в тази посока.

Зад желязната завеса на цензурата

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

Описаната методология подлага на критичен анализ информацията от руски социологически проучвания и официални данни, които се съпоставят и с други налични източници във и извън Русия, като по този начин се осигурява максимална обективност.

Цензурата в Русия е причина да липсват изцяло надеждни данни. Всеки, за когото се смята, че разпространява „невярна информация“ за войната, се наказва с глоба и затвор до 15 години. Критици на войната, като опозиционерите Иля Яшин и Владимир Кара-Мурза, бяха арестувани заради нарушение на новите закони, след чието въвеждане над 150 журналисти напуснаха страната.

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

Затова не е изненадващо, че само в рамките на година тревожността в руското общество е нараснала със 119%. Тази информация се потвърждава от медийни анализи, телефонни анкети и статистики за количеството лекарства за психични разстройства, продадени за последната година. Близо половината руснаци признават в местни проучвания, че събитията, свързани с Украйна, имат негативно влияние над психичното им здраве.

Вътрешната съпротива е възможна, но малко вероятна

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

По време на концерт на групата „Кис-Кис“ през май 2022 г. публиката скандира срещу войната. Любов Собол – юрист от екипа на Алексей Навални, който продължава да е затворник в колония, споделя видео от концерта с думите, че не всички руснаци подкрепят Путин. Въпреки цензурата руски културни дейци, като издателя Борис Куприянов и писателката Мария Степанова, публично заклеймяват войната и чертаят разграничителна линия между Путин и Русия. Имаше и изолирани протести, като този в Дагестан, където жители скандираха против войната и мобилизацията.


Критици, като академика Владислав Иноземцев, директор на Московския център за изследване на постиндустриалните науки, обаче смятат, че „Русия е Путин и Путин е Русия“. Сред често срещаните аргументи е липсата на вътрешна съпротива – щом руснаците не свалят режима и дори подкрепят инвазията, то не можем да виним само Путин. Данните, събрани от Open Minds, по-скоро подкрепят това становище, но обясняват защо апатията, обзела руското общество, не е задължително равна на подкрепа.

„Твърде вероятно е мнозинството руснаци да последват всякакви заповеди от политическите лидери. Нивата на подкрепа към руската агресия срещу Украйна остават високи. Не се наблюдават значителни промени в тези тенденции въпреки провалите на руската армия на бойното поле и проблемите, породени от частичната мобилизация“, казват авторите.

Профил на подкрепящите войната

С какво може да се обясни тази подкрепа? Първото предположение би било медийната пропаганда. Макар че все по-малко руснаци разчитат на телевизията като основен източник на информация – наблюдава се спад от близо 10% за последните две години, – стойностите на доверие и гледаемост остават високи.

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

Пропагандата не е единствената причина. Психологическите характеристики също играят роля в изразяването на подкрепа или опозиционни настроения към „специалната военна операция“, както е официалното название на инвазията в Русия, макар президентът Путин и подчинените му вече открито да говорят за война.

Две от хипотезите на изследователите – че хора, чиито качества попадат в т.нар. тъмна триада, и тези, които смятат, че НАТО е заплаха за Русия, биха имали високи нива на подкрепа – не се потвърждават. Проучването открива друга променлива, която дава предвидими и значителни резултати: безусловното подчинение. „Едно от ключовите убеждения на подкрепящите Путин е, че властта винаги е права просто защото е власт“, пишат авторите.

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

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

За руснаците по-важни са вътрешните проблеми

За повечето руснаци войната е пореден елемент от една така или иначе сурова реалност, към която са свикнали да се приспособяват. Наблюдава се спад в интереса към репортажите за войната и апатичност към темата.

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

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

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

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

Възможно е причината за липсата на масови протести и съпротива да е именно отсъствието на вяра у руснаците, че са способни да променят хода на руската политика. Освен твърдата подкрепа за войната, липсата на визия и идеи за алтернативно развитие на Русия също играят роля. Докладът на Open Minds показва, че когато се задава въпросът дали това е войната на Путин, или войната на руснаците, трябва да се вземат  предвид много вътрешни фактори – ако, разбира се, говорим с данни. Моралният дебат е далеч по-сложен. И аргументите, че войната е само на Путин или че всъщност е подкрепена от голямата част от руснаците, тепърва ще се градят.

Uptick in healthcare organizations experiencing targeted DDoS attacks

Post Syndicated from Cat Allen original https://blog.cloudflare.com/uptick-in-healthcare-organizations-experiencing-targeted-ddos-attacks/

Uptick in healthcare organizations experiencing targeted DDoS attacks

Healthcare in the crosshairs

Uptick in healthcare organizations experiencing targeted DDoS attacks

Over the past few days, Cloudflare, as well as other sources, have observed healthcare organizations targeted by a pro-Russian hacktivist group claiming to be Killnet. There has been an increase in the amount of healthcare organizations coming to us to help get out from under these types of attacks. Multiple healthcare organizations behind Cloudflare have also been targeted by HTTP DDoS attacks and Cloudflare has helped them successfully mitigate these attacks. The United States Department of Health and Human Services issued an Analyst Note detailing the threat of Killnet-related cyberattacks to the healthcare industry.

A rise in political tensions and escalation of the conflict in Ukraine are all factors that play into the current cybersecurity threat landscape. Unlike traditional warfare, the Internet has enabled and empowered groups of individuals to carry out targeted attacks regardless of their location or involvement. Distributed-denial-of-Service (DDoS) attacks have the unfortunate advantage of not requiring an intrusion or a foothold to be launched and have, unfortunately, become more accessible than ever before.

The attacks observed by the Cloudflare global network do not show a clear indication that they are originating from a single botnet and the attack methods and sources seem to vary. This could indicate the involvement of multiple threat actors acting on behalf of Killnet or it could indicate a more sophisticated, coordinated attack.

Cloudflare application services customers are protected against the attacks. Cloudflare systems have been automatically detecting and mitigating the attacks on behalf of our customers. Our team continues to monitor the situation closely and is prepared to deploy countermeasures, if needed.

As an extra precaution, customers in the Healthcare industry are advised to follow the mitigation recommendations in the “How to Prepare” section below.

Uptick in healthcare organizations experiencing targeted DDoS attacks
Uptick in healthcare organizations experiencing targeted DDoS attacks

Who is Killnet?

Killnet is a group of pro-Russian individuals that gather and communicate on a Telegram channel. The channel provides a space for pro-Russian sympathizers to volunteer their expertise by participating in cyberattacks against Western interests. Previously, in the fourth quarter of 2022, Killnet called to attack US airport websites.

Why DDoS attacks?

DDoS attacks, unlike ransomware, do not require an intrusion or foothold in the target network to be launched. Much like how physical addresses are publicly available via directories or for services like mail delivery, IP addresses and domain names are also publicly available. Unfortunately, this means that every domain name (layer 7) and every network that connects to the Internet (layers 3 & 4) must proactively prepare to defend against DDoS attacks. DDoS attacks are not new threats, but they have become larger, more sophisticated, and more frequent in recent years.

How to prepare

While Cloudflare’s systems have been automatically detecting and mitigating these DDoS attacks, we recommend additional precautionary measures to improve your security posture:

  1. Ensure all other DDoS Managed Rules are set to default settings (High sensitivity level and mitigation actions) for optimal DDoS activation
  2. Cloudflare Enterprise customers with Advanced DDoS should consider enabling Adaptive DDoS Protection, which mitigates traffic that deviates based on your traffic profiles
  3. Deploy firewall rules and rate-limiting rules to enforce a combined positive and negative security model. Reduce the traffic allowed to your website based on your known usage.
  4. Ensure your origin is not exposed to the public Internet (i.e. only enable access to Cloudflare IP addresses)
  5. Customers with access to Managed IP Lists should consider leveraging those lists in firewall rules
  6. Enable caching as much as possible to reduce the strain on your origin servers
  7. Enable DDoS alerting to improve your response time

Though attacks are launched by humans, they are carried out by bots. Defenders who do not leverage automated defenses are at a disadvantage. Cloudflare has helped, and will continue to help, our customers in the healthcare industry prepare for and respond to these attacks.

Under attack? We can help. Visit this webpage or call us at +1 (888) 99 FLARE

How Amazon Devices scaled and optimized real-time demand and supply forecasts using serverless analytics

Post Syndicated from Avinash Kolluri original https://aws.amazon.com/blogs/big-data/how-amazon-devices-scaled-and-optimized-real-time-demand-and-supply-forecasts-using-serverless-analytics/

Every day, Amazon devices process and analyze billions of transactions from global shipping, inventory, capacity, supply, sales, marketing, producers, and customer service teams. This data is used in procuring devices’ inventory to meet Amazon customers’ demands. With data volumes exhibiting a double-digit percentage growth rate year on year and the COVID pandemic disrupting global logistics in 2021, it became more critical to scale and generate near-real-time data.

This post shows you how we migrated to a serverless data lake built on AWS that consumes data automatically from multiple sources and different formats. Furthermore, it created further opportunities for our data scientists and engineers to use AI and machine learning (ML) services to continuously feed and analyze data.

Challenges and design concerns

Our legacy architecture primarily used Amazon Elastic Compute Cloud (Amazon EC2) to extract the data from various internal heterogeneous data sources and REST APIs with the combination of Amazon Simple Storage Service (Amazon S3) to load the data and Amazon Redshift for further analysis and generating the purchase orders.

We found this approach resulted in a few deficiencies and therefore drove improvements in the following areas:

  • Developer velocity – Due to the lack of unification and discovery of schema, which are primary reasons for runtime failures, developers often spent time dealing with operational and maintenance issues.
  • Scalability – Most of these datasets are shared across the globe. Therefore, we must meet the scaling limits while querying the data.
  • Minimal infrastructure maintenance – The current process spans multiple computes depending on the data source. Therefore, reducing infrastructure maintenance is critical.
  • Responsiveness to data source changes – Our current system gets data from various heterogeneous data stores and services. Any updates to those services takes months of developer cycles. The response times for these data sources are critical to our key stakeholders. Therefore, we must take a data-driven approach to select a high-performance architecture.
  • Storage and redundancy – Due to the heterogeneous data stores and models, it was challenging to store the different datasets from various business stakeholder teams. Therefore, having versioning along with incremental and differential data to compare will provide a remarkable ability to generate more optimized plans
  • Fugitive and accessibility – Due to the volatile nature of logistics, a few business stakeholder teams have a requirement to analyze the data on demand and generate the near-real-time optimal plan for the purchase orders. This introduces the need for both polling and pushing the data to access and analyze in near-real time.

Implementation strategy

Based on these requirements, we changed strategies and started analyzing each issue to identify the solution. Architecturally, we chose a serverless model, and the data lake architecture action line refers to all the architectural gaps and challenging features we determined were part of the improvements. From an operational standpoint, we designed a new shared responsibility model for data ingestion using AWS Glue instead of internal services (REST APIs) designed on Amazon EC2 to extract the data. We also used AWS Lambda for data processing. Then we chose Amazon Athena as our query service. To further optimize and improve the developer velocity for our data consumers, we added Amazon DynamoDB as a metadata store for different data sources landing in the data lake. These two decisions drove every design and implementation decision we made.

The following diagram illustrates the architecture

arch

In the following sections, we look at each component in the architecture in more detail as we move through the process flow.

AWS Glue for ETL

To meet customer demand while supporting the scale of new businesses’ data sources, it was critical for us to have a high degree of agility, scalability, and responsiveness in querying various data sources.

AWS Glue is a serverless data integration service that makes it easy for analytics users to discover, prepare, move, and integrate data from multiple sources. You can use it for analytics, ML, and application development. It also includes additional productivity and DataOps tooling for authoring, running jobs, and implementing business workflows.

With AWS Glue, you can discover and connect to more than 70 diverse data sources and manage your data in a centralized data catalog. You can visually create, run, and monitor extract, transform, and load (ETL) pipelines to load data into your data lakes. Also, you can immediately search and query cataloged data using Athena, Amazon EMR, and Amazon Redshift Spectrum.

AWS Glue made it easy for us to connect to the data in various data stores, edit and clean the data as needed, and load the data into an AWS-provisioned store for a unified view. AWS Glue jobs can be scheduled or called on demand to extract data from the client’s resource and from the data lake.

Some responsibilities of these jobs are as follows:

  • Extracting and converting a source entity to data entity
  • Enrich the data to contain year, month, and day for better cataloging and include a snapshot ID for better querying
  • Perform input validation and path generation for Amazon S3
  • Associate the accredited metadata based on the source system

Querying REST APIs from internal services is one of our core challenges, and considering the minimal infrastructure, we wanted to use them in this project. AWS Glue connectors assisted us in adhering to the requirement and goal. To query data from REST APIs and other data sources, we used PySpark and JDBC modules.

AWS Glue supports a wide variety of connection types. For more details, refer to Connection Types and Options for ETL in AWS Glue.

S3 bucket as landing zone

We used an S3 bucket as the immediate landing zone of the extracted data, which is further processed and optimized.

Lambda as AWS Glue ETL Trigger

We enabled S3 event notifications on the S3 bucket to trigger Lambda, which further partitions our data. The data is partitioned on InputDataSetName, Year, Month, and Date. Any query processor running on top of this data will scan only a subset of data for better cost and performance optimization. Our data can be stored in various formats, such as CSV, JSON, and Parquet.

The raw data isn’t ideal for most of our use cases to generate the optimal plan because it often has duplicates or incorrect data types. Most importantly, the data is in multiple formats, but we quickly modified the data and observed significant query performance gains from using the Parquet format. Here, we used one of the performance tips in Top 10 performance tuning tips for Amazon Athena.

AWS Glue jobs for ETL

We wanted better data segregation and accessibility, so we chose to have a different S3 bucket to improve performance further. We used the same AWS Glue jobs to further transform and load the data into the required S3 bucket and a portion of extracted metadata into DynamoDB.

DynamoDB as metadata store

Now that we have the data, various business stakeholders further consume it. This leaves us with two questions: which source data resides on the data lake and what version. We chose DynamoDB as our metadata store, which provides the latest details to the consumers to query the data effectively. Every dataset in our system is uniquely identified by snapshot ID, which we can search from our metadata store. Clients access this data store with an API’s.

Amazon S3 as data lake

For better data quality, we extracted the enriched data into another S3 bucket with the same AWS Glue job.

AWS Glue Crawler

Crawlers are the “secret sauce” that enables us to be responsive to schema changes. Throughout the process, we chose to make each step as schema-agnostic as possible, which allows any schema changes to flow through until they reach AWS Glue. With a crawler, we could maintain the agnostic changes happening to the schema. This helped us automatically crawl the data from Amazon S3 and generate the schema and tables.

AWS Glue Data Catalog

The Data Catalog helped us maintain the catalog as an index to the data’s location, schema, and runtime metrics in Amazon S3. Information in the Data Catalog is stored as metadata tables, where each table specifies a single data store.

Athena for SQL queries

Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. Athena is serverless, so there is no infrastructure to manage, and you pay only for the queries you run. We considered operational stability and increasing developer velocity as our key improvement factors.

We further optimized the process to query Athena so that users can plug in the values and the queries to get data out of Athena by creating the following:

  • An AWS Cloud Development Kit (AWS CDK) template to create Athena infrastructure and AWS Identity and Access Management (IAM) roles to access data lake S3 buckets and the Data Catalog from any account
  • A library so that client can provide an IAM role, query, data format, and output location to start an Athena query and get the status and result of the query run in the bucket of their choice.

To query Athena is a two-step process:

  • StartQueryExecution – This starts the query run and gets the run ID. Users can provide the output location where the output of the query will be stored.
  • GetQueryExecution – This gets the query status because the run is asynchronous. When successful, you can query the output in an S3 file or via API.

The helper method for starting the query run and getting the result would be in the library.

Data lake metadata service

This service is custom developed and interacts with DynamoDB to get the metadata (dataset name, snapshot ID, partition string, timestamp, and S3 link of the data) in the form of a REST API. When the schema is discovered, clients use Athena as their query processor to query the data.

Because all datasets have a snapshot ID are partitioned, the join query doesn’t result in a full table scan but only a partition scan on Amazon S3. We used Athena as our query processor because of its ease in not managing our query infrastructure. Later, if we feel we need something more, we can use either Redshift Spectrum or Amazon EMR.

Conclusion

Amazon Devices teams discovered significant value by moving to a data lake architecture using AWS Glue, which enabled multiple global business stakeholders to ingest data in more productive ways. This enabled the teams to generate the optimal plan to place purchase orders for devices by analyzing the different datasets in near-real time with appropriate business logic to solve the problems of the supply chain, demand, and forecast.

From an operational perspective, the investment has already started to pay off:

  • It standardized our ingestion, storage, and retrieval mechanisms, saving onboarding time. Before the implementation of this system, one dataset took 1 month to onboard. Due to our new architecture, we were able to onboard 15 new datasets in less than 2 months, which improved our agility by 70%.
  • It removed scaling bottlenecks, creating a homogeneous system that can quickly scale to thousands of runs.
  • The solution added schema and data quality validation before accepting any inputs and rejecting them if data quality violations are discovered.
  • It made it easy to retrieve datasets while supporting future simulations and back tester use cases requiring versioned inputs. This will make launching and testing models simpler.
  • The solution created a common infrastructure that can be easily extended to other teams across DIAL having similar issues with data ingestion, storage, and retrieval use cases.
  • Our operating costs have fallen by almost 90%.
  • This data lake can be accessed efficiently by our data scientists and engineers to perform other analytics and have a predictive approach as a future opportunity to generate accurate plans for the purchase orders.

The steps in this post can help you plan to build a similar modern data strategy using AWS-managed services to ingest data from different sources, automatically create metadata catalogs, share data seamlessly between the data lake and data warehouse, and create alerts in the event of an orchestrated data workflow failure.


About the authors

avinash_kolluriAvinash Kolluri is a Senior Solutions Architect at AWS. He works across Amazon Alexa and Devices to architect and design modern distributed solutions. His passion is to build cost-effective and highly scalable solutions on AWS. In his spare time, he enjoys cooking fusion recipes and traveling.

vipulVipul Verma is a Sr.Software Engineer at Amazon.com. He has been with Amazon since 2015,solving real-world challenges through technology that directly impact and improve the life of Amazon customers. In his spare time, he enjoys hiking.

Go 1.20 released

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

Version 1.20 of the Go language
has been released.

We’re particularly excited to launch a preview of profile-guided
optimization (PGO), which enables the compiler to perform
application- and workload-specific optimizations based on run-time
profile information. Providing a profile to go build enables the
compiler to speed up typical applications by around 3–4%, and we
expect future releases to benefit even more from PGO. Since this is
a preview release of PGO support, we encourage folks to try it out,
but there are still rough edges which may preclude production use.

Go 1.20 also includes a handful of language changes, many
improvements to tooling and the library, and better overall
performance.

[$] Convergence in the pip and conda worlds?

Post Syndicated from jake original https://lwn.net/Articles/921097/

The discussions about the world of Python packaging and the
problems caused by its disparate tools and incompatible ecosystems are
still ongoing. Last week, we looked at the
beginnings of the conversation
in mid-November, as the discussion
turned toward a possible convergence between two of the major
package-management players: pip and conda. There are numerous
barriers to bringing the two closer together, inertia not least, but the
advantages for users of both, as well as new users to come, could be
substantial.

XDR, the Beatles, and Blunt Instruments

Post Syndicated from Amy Hunt original https://blog.rapid7.com/2023/02/01/xdr-the-beatles-and-blunt-instruments/

XDR, the Beatles, and Blunt Instruments

Sometimes tools are blunt because there’s nothing else. Regarding economic controls for example, Fed Chair Jerome Powell said: “We have essentially interest rates, the balance sheet and forward guidance. They are famously blunt tools, they are not capable of surgical precision.”

Others are blunt because they’re new and these things take time. For example: stereos in the 1960s shook the floors with unrestrained subwoofers. Yes, it was the Beatles and Ringo Star on the drums, but still. It took years to refine this new technology to enhance the music instead of assaulting our senses.

Taking off shoes at the airport? Blunt.

Years later, Real ID and TSA Pre-Check®? Better.

Coming soon: Facial recognition and biometric screening, better still—after privacy concerns are addressed.  

Cybersecurity has used blunt tools, followed by far too many “better ones.” The average security team is now managing 76 tools, and spending more than half their time manually producing reports. The way out is a sharp tool to replace all these better ones—a resource that will actually get the job done. Start with our newly released 2023 XDR Buyer’s Guide.

XDR consolidation and precision has arrived, just know what to look for

Security programs succeed when they have a library of curated, high-fidelity detections backed by threat intelligence that they can trust out-of-the-box. Anything else is low performance guesswork.

Huge numbers of alerts that teams must review and triage can lead to missing high profile threats. Extended Detection and Response (XDR) solutions deliver tailored security alerts that are quantified and scored to improve signal-to-noise ratio and help catch threats early in the attack chain. XDR also eliminates context switching and ensures you have high context, correlated investigation details, blending relevant data from across different event sources into one, coherent picture.

XDR delivered: MDR

With Rapid7, XDR security can also be delivered to you as an end-to-end, turnkey service. Managed detection and response (MDR) can be a game changer, with always-on threat detection, incident validation, and response (such as threat containment). Some providers offer features like threat intelligence, human-led threat hunting, behavior analytics, automation, and more to your capabilities.

A good MDR provider will be 100% end-to-end responsible, however, it should also be an extension of your in-house team. Look for a provider that will freely share the XDR technology with your in-house operation, and work transparently. Your team should be able to observe your environment exactly as the MDR team does, do their own threat hunting, and more—whatever level of collaboration you’d like to see.

2023 is the year of consolidation and XDR. But no change, however awesome or overdue, is easy. We hope this XDR Buyer’s Guide helps.

XDR, the Beatles, and Blunt Instruments

C can be memory-safe

Post Syndicated from Robert Graham original https://blog.erratasec.com/2023/02/c-can-be-memory-safe.html

The idea of memory-safe languages is in the news lately. C/C++ is famous for being the world’s system language (that runs most things) but also infamous for being unsafe. Many want to solve this by hard-forking the world’s system code, either by changing C/C++ into something that’s memory-safe, or rewriting everything in Rust.

Forking is a foolish idea. The core principle of computer-science is that we need to live with legacy, not abandon it.

And there’s no need. Modern C compilers already have the ability to be memory-safe, we just need to make minor — and compatible — changes to turn it on. Instead of a hard-fork that abandons legacy system, this would be a soft-fork that enables memory-safety for new systems.

Consider the most recent memory-safety flaw in OpenSSL. They fixed it by first adding a memory-bounds, then putting every access to the memory behind a macro PUSHC() that checks the memory-bounds:

A better (but currently hypothetical) fix would be something like the following:

size_t maxsize CHK_SIZE(outptr) = out ? *outlen : 0;
This would link the memory-bounds maxsize with the memory outptr. The compiler can then be relied upon to do all the bounds checking to prevent buffer overflows, the rest of the code wouldn’t need to be changed.
An even better (and hypothetical) fix would be to change the function declaration like the following:
int ossl_a2ulabel(const char *in, char *out, size_t *outlen CHK_INOUT_SIZE(out));
That’s the intent anyway, that *outlen is the memory-bounds of out on input, and receives a shorter bounds on output.
This specific feature isn’t in compilers. But gcc and clang already have other similar features. They’ve only been halfway implemented. This feature would be relatively easy to add. I’m currently studying the code to see how I can add it myself. I could just mostly copy what’s done for the alloc_size attribute. But there’s a considerable learning curve, I’d rather just persuade an existing developer of gcc or clang to add the new attributes for me.
Once you give the programmer the ability to fix memory-safety problems like the solution above, you can then enable warnings for unsafe code. The compiler knew the above code was unsafe, but since there’s no practical way to fix it, it’s pointless nagging the programmer about it. With this new features comes warnings about failing to use it.
In other words, it becomes compiler-guided refactoring. Forking code is hard, refactoring is easy.
As the above function shows, the OpenSSL code is already somewhat memory safe, just based upon the flawed principle of relying upon diligent programmers. We need the compiler to enforce it. With such features, the gap is relative small, mostly just changing function parameter lists and data structures to link a pointer with its memory-bounds. The refactoring effort would be small, rather than a major rewrite.
This would be a soft-fork. The memory-bounds would work only when compiled with new compilers. The macro would be ignored on older systems. 
This memory-safety is a problem. The idea of abandoning C/C++ isn’t a solution. We already have the beginnings of a solution in modern gcc and clang compilers. We just need to extend that solution.

Amazon EMR launches support for Amazon EC2 C7g (Graviton3) instances to improve cost performance for Spark workloads by 7–13%

Post Syndicated from Al MS original https://aws.amazon.com/blogs/big-data/amazon-emr-launches-support-for-amazon-ec2-c7g-graviton3-instances-to-improve-cost-performance-for-spark-workloads-by-7-13/

Amazon EMR provides a managed service to easily run analytics applications using open-source frameworks such as Apache Spark, Hive, Presto, Trino, HBase, and Flink. The Amazon EMR runtime for Spark and Presto includes optimizations that provide over twice the performance improvements compared to open-source Apache Spark and Presto.

With Amazon EMR release 6.7, you can now use Amazon Elastic Compute Cloud (Amazon EC2) C7g instances, which use the AWS Graviton3 processors. These instances improve price-performance of running Spark workloads on Amazon EMR by 7.93–13.35% over previous generation instances, depending on the instance size. In this post, we describe how we estimated the price-performance benefit.

Amazon EMR runtime performance with EC2 C7g instances

We ran TPC-DS 3 TB benchmark queries on Amazon EMR 6.9 using the Amazon EMR runtime for Apache Spark (compatible with Apache Spark 3.3) with C7g instances. Data was stored in Amazon Simple Storage Service (Amazon S3), and results were compared to equivalent C6g clusters from the previous generation instance family. We measured performance improvements using the total query runtime and geometric mean of the query runtime across TPC-DS 3 TB benchmark queries.

Our results showed 13.65–18.73% improvement in total query runtime performance and 16.98–20.28% improvement in geometric mean on EMR clusters with C7g compared to equivalent EMR clusters with C6g instances, depending on the instance size. In comparing costs, we observed 7.93–13.35% reduction in cost on the EMR cluster with C7g compared to the equivalent with C6g, depending on the instance size. We did not benchmark the C6g xlarge instance because it didn’t have sufficient memory to run the queries.

The following table shows the results from running the TPC-DS 3 TB benchmark queries using Amazon EMR 6.9 compared to equivalent C7g and C6g instance EMR clusters.

Instance Size 16 XL 12 XL 8 XL 4 XL 2 XL
Total size of the cluster (1 leader + 5 core nodes) 6 6 6 6 6
Total query runtime on C6g (seconds) 2774.86205 2752.84429 3173.08086 5108.45489 8697.08117
Total query runtime on C7g (seconds) 2396.22799 2336.28224 2698.72928 4151.85869 7249.58148
Total query runtime improvement with C7g 13.65% 15.13% 14.95% 18.73% 16.64%
Geometric mean query runtime C6g (seconds) 22.2113 21.75459 23.38081 31.97192 45.41656
Geometric mean query runtime C7g (seconds) 18.43905 17.65898 19.01684 25.48695 37.43737
Geometric mean query runtime improvement with C7g 16.98% 18.83% 18.66% 20.28% 17.57%
EC2 C6g instance price ($ per hour) $2.1760 $1.6320 $1.0880 $0.5440 $0.2720
EMR C6g instance price ($ per hour) $0.5440 $0.4080 $0.2720 $0.1360 $0.0680
(EC2 + EMR) instance price ($ per hour) $2.7200 $2.0400 $1.3600 $0.6800 $0.3400
Cost of running on C6g ($ per instance) $2.09656 $1.55995 $1.19872 $0.96493 $0.82139
EC2 C7g instance price ($ per hour) $2.3200 $1.7400 $1.1600 $0.5800 $0.2900
EMR C7g price ($ per hour per instance) $0.5800 $0.4350 $0.2900 $0.1450 $0.0725
(EC2 + EMR) C7g instance price ($ per hour) $2.9000 $2.1750 $1.4500 $0.7250 $0.3625
Cost of running on C7g ($ per instance) $1.930290 $1.411500 $1.086990 $0.836140 $0.729990
Total cost reduction with C7g including performance improvement -7.93% -9.52% -9.32% -13.35% -11.13%

The following graph shows per-query improvements observed on C7g 2xlarge instances compared to equivalent C6g generations.

Benchmarking methodology

The benchmark used in this post is derived from the industry-standard TPC-DS benchmark, and uses queries from the Spark SQL Performance Tests GitHub repo with the following fixes applied.

We calculated TCO by multiplying cost per hour by number of instances in the cluster and time taken to run the queries on the cluster. We used on-demand pricing in the US East (N. Virginia) Region for all instances.

Conclusion

In this post, we described how we estimated the cost-performance benefit from using Amazon EMR with C7g instances compared to using equivalent previous generation instances. Using these new instances with Amazon EMR improves cost-performance by an additional 7–13%.


About the authors

AI MSAl MS is a product manager for Amazon EMR at Amazon Web Services.

Kyeonghyun Ryoo is a Software Development Engineer for EMR at Amazon Web Services. He primarily works on designing and building automation tools for internal teams and customers to maximize their productivity. Outside of work, he is a retired world champion in professional gaming who still enjoy playing video games.

Yuzhou Sun is a software development engineer for EMR at Amazon Web Services.

Steve Koonce is an Engineering Manager for EMR at Amazon Web Services.

TrenchBoot Anti Evil Maid for Qubes OS

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

The Qubes OS news site has a
detailed article
on work being done to ensure the integrity of the
system at boot time.

As you may know, traditional firmware security measures like UEFI
Secure Boot and measured boot, even with a Static Root of Trust
(SRT), may only sometimes be enough to ensure a completely secure
environment for your operating system. Compromised firmware may
allow for the injection of malicious software into your system,
making it difficult to detect. To overcome these limitations, many
silicon vendors have started implementing Dynamic Root of Trust
(DRT) technologies to establish a secure environment for operating
system launch and integrity measurements. We’re excited to take
advantage of these advancements through integration with the
TrenchBoot Project.

GitHub Availability Report: January 2023

Post Syndicated from Jakub Oleksy original https://github.blog/2023-02-01-github-availability-report-january-2023/

In January, we experienced two incidents. One that resulted in degraded performance for GitHub Packages and GitHub Pages, and another that impacted git users.

January 30 21:48 UTC (lasting 35 minutes)

Our service monitors detected degraded performance for GitHub Packages and GitHub Pages. Most requests to the container registry were failing and some GitHub Pages builds were also impacted. We determined this was caused by a backend change and mitigated by reverting that change.

Due to the recency of this incident, we are still investigating the contributing factors and will provide a more detailed update in next month’s report.

January 30 18:35 UTC (lasting 7 hours)

We upgraded our production Git binary with a recent version from upstream. The updates included a change to use an internal implementation of gzip when generating archives. This resulted in subtle changes to the contents of the “Download Source” links served by GitHub, leading to checksum mismatches. No content was changed.

After becoming aware of the impact to many communities, we rolled back the compression change to restore the previous behavior.

Similar to the above, we are still investigating the contributing factors of this incident, and will provide a more thorough update in next month’s report.


Please follow our status page for real-time updates on status changes. To learn more about what we’re working on, check out the GitHub Engineering Blog.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close