All posts by Bozho

Вярно с електронно подписания оригинал

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

Много хора споделят тази снимка: „Вярно с електронно подписания оригинал“.

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

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

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

Обаче… правилните подходи са други:

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

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

Ще продължава да има хипотези на разпечатване на е-документи, но те не трябва да бъдат в администрацията. Може в някоя фирма така да предпочитат или да са нужни за пред друга държава, където не ги приемат електронно. Но това са изключения.

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

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

COVID-19 и личната отговорност

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

Като гледаме данните, нещата с COVID-19 вече са извън контрол. Вече сме на нивата, на които Италия затвори всичко на 8-ми март, но положителен резултат имаше след няколко седмици.

Тук заведенията са пълни, училищата са отворени, а някои болници вече изнемогват; лекари напускат. Много е вероятно само след 10 дни да сме в ситуацията на Чехия (където учебната година започва на 1-ви септември).

На този фон правителството не прави нищо. То не се ползва с доверие, което да му позволи да наложи мерки, а въвеждането на непопулярни мерки толкова скоро преди изборите изисква смелост, каквато не мисля, че управляващите имат, колкото и да въртяха рефрена, че е нужно да са на власт заради кризата.

Българските власти не контролират спазването на ограниченията, не тестват достатъчно, не проследяват адекватно контакти на болни. Не въвеждат онлайн обучение поне за тези над 16г, както други държави.

На този фон, това, което имаме, е личната отговорност и личния пример.

Да носим маски, да ограничим контактите си, ходенето по заведения.

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

Не всеки може да си позволи да си наложи ограничения и затова е важно тези, които можем, да го направим. Важно е и проактивно да докладваме контактите си, ако сме болни, дори да не ни питат (защото често не питат).

Дали такава реакция не е прекалена? Не мисля. Но дори да е, попада в категорията „управление на риска“.

Това може да продължи цяла зима и трябва да се подготвим психически. От сега.

Материалът COVID-19 и личната отговорност е публикуван за пръв път на БЛОГодаря.

Discovering an OSSEC/Wazuh Encryption Issue

Post Syndicated from Bozho original https://techblog.bozho.net/discovering-an-ossec-wazuh-encryption-issue/

I’m trying to get the Wazuh agent (a fork of OSSEC, one of the most popular open source security tools, used for intrusion detection) to talk to our custom backend (namely, our LogSentinel SIEM Collector) to allow us to reuse the powerful Wazuh/OSSEC functionalities for customers that want to install an agent on each endpoint rather than just one collector that “agentlessly” reaches out to multiple sources.

But even though there’s a good documentation on the message format and encryption, I couldn’t get to successfully decrypt the messages. (I’ll refer to both Wazuh and OSSEC, as the functionality is almost identical in both, with the distinction that Wazuh added AES support in addition to blowfish)

That lead me to a two-day investigation on possible reasons. The first side-discovery was the undocumented OpenSSL auto-padding of keys and IVs described in my previous article. Then it lead me to actually writing C code (an copying the relevant Wazuh/OSSEC pieces) in order to debug the issue. With Wazuh/OSSEC I was generating one ciphertext and with Java and openssl CLI – a different one.

I made sure the key, key size, IV and mode (CBC) are identical. That they are equally padded and that OpenSSL’s EVP API is correctly used. All of that was confirmed and yet there was a mismatch, and therefore I could not decrypt the Wazuh/OSSEC message on the other end.

After discovering the 0-padding, I also discovered a mistake in the documentation, which used a static IV of FEDCA9876543210 rather than the one found in the code, where the 0 preceded 9 – FEDCA0987654321. But that didn’t fix the issue either, only got me one step closer.

A side-note here on IVs – Wazuh/OSSEC is using a static IV, which is a bad practice. The issue is reported 5 years ago, but is minor, because they are using some additional randomness per message that remediates the use of a static IV; it’s just not idiomatic to do it that way and may have unexpected side-effects.

So, after debugging the C code, I got to a simple code that could be used to reproduce the issue and asked a question on Stackoverflow. 5 minutes after posting the question I found another, related question that had the answer – using hex strings like that in C doesn’t work. Instead, they should be encoded: char *iv = (char *)"\xFE\xDC\xBA\x09\x87\x65\x43\x21\x00\x00\x00\x00\x00\x00\x00\x00";. So, the value is not the bytes corresponding to the hex string, but the ASCII codes of each character in the hex string. I validated that in the receiving Java end with this code:

This has an implication on the documentation, as well as on the whole scheme as well. Because the Wazuh/OSSEC AES key is: MD5(password) + MD5(MD5(agentName) + MD5(agentID)){0, 15}, the 2nd part is practically discarded, because the MD5(password) is 32 characters (= 32 ASCII codes/bytes), which is the length of the AES key. This makes the key derived from a significantly smaller pool of options – the permutations of 16 bytes, rather than of 256 bytes.

I raised an issue with Wazuh. Although this can be seen as a vulnerability (due to the reduced key space), it’s rather minor from security point of view, and as communication is mostly happening within the corporate network, I don’t think it has to be privately reported and fixed immediately.

Yet, I made a recommendation for introducing an additional configuration option to allow to transition to the updated protocol without causing backward compatibility issues. In fact, I’d go further and recommend using TLS/DTLS rather than a home-grown, AES-based scheme. Mutual authentication can be achieved through TLS mutual authentication rather than through a shared secret.

It’s satisfying to discover issues in popular software, especially when they are not written in your “native” programming language. And as a rule of thumb – encodings often cause problems, so we should be extra careful with them.

The post Discovering an OSSEC/Wazuh Encryption Issue appeared first on Bozho's tech blog.

OpenSSL Key and IV Padding

Post Syndicated from Bozho original https://techblog.bozho.net/openssl-key-and-iv-padding/

OpenSSL is an omnipresent tool when it comes to encryption. While in Java we are used to the native Java implementations of cryptographic primitives, most other languages rely on OpenSSL.

Yesterday I was investigating the encryption used by one open source tool written in C, and two things looked strange: they were using a 192 bit key for AES 256, and they were using a 64-bit IV (initialization vector) instead of the required 128 bits (in fact, it was even a 56-bit IV).

But somehow, magically, OpenSSL didn’t complain the way my Java implementation did, and encryption worked. So, I figured, OpenSSL is doing some padding of the key and IV. But what? Is it prepending zeroes, is it appending zeroes, is it doing PKCS padding or ISO/IEC 7816-4 padding, or any of the other alternatives. I had to know if I wanted to make my Java counterpart supply the correct key and IV.

It was straightforward to test with the following commands:

# First generate the ciphertext by encrypting input.dat which contains "testtesttesttesttesttest"
$ openssl enc -aes-256-cbc -nosalt -e -a -A -in input.dat -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321' -out input-test.enc

# Then test decryption with the same key and IV
$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321'
testtesttesttesttesttest

# Then test decryption with different paddings
$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA9876543210'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c760' -iv 'FEDCBA987654321'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '7c07f68ea8494b2f8b9fea297119350d78708afa69c1c76000' -iv 'FEDCBA987654321'
testtesttesttesttesttest

$ openssl enc -aes-256-cbc -nosalt -d -a -A -in input-test.enc -K '07c07f68ea8494b2f8b9fea297119350d78708afa69c1c76' -iv 'FEDCBA987654321'
bad decrypt

So, OpenSSL is padding keys and IVs with zeroes until they meet the expected size. Note that if -aes-192-cbc is used instead of -aes-256-cbc, decryption will fail, because OpenSSL will pad it with fewer zeroes and so the key will be different.

Not an unexpected behavaior, but I’d prefer it to report incorrect key sizes rather than “do magic”, especially when it’s not easy to find exactly what magic it’s doing. I couldn’t find it documented, and the comments to this SO question hint in the same direction. In fact, for plaintext padding, OpenSSL uses PKCS padding (which is documented), so it’s extra confusing that it’s using zero-padding here.

In any case, follow the advice from the stackoverflow answer and don’t rely on this padding – always provide the key and IV in the right size.

The post OpenSSL Key and IV Padding appeared first on Bozho's tech blog.

Как да разкараме печатите от медицинските изследвания за прием в ясла

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

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

Ще коментирам обаче изследванията, и по-точно – удостоверяването на тяхната автентичност. Направихме всички изследвания, разпечатахме резултата от сайта на лабораторията, и ги занесохме заедно с другите документи. Само че – проблем. Трябвало да имат печати. Жена ми се разходи до лабораторията, сложиха ѝ един печат, обаче и това не беше достатъчно – трябвало да има втори, правоъгълен печат. Не можело да го приемат без него. Винаги бил така. А правоъгълният печат го имало само в централата на лабораторията – в другия край на града.

Попитах кой и защо го изисква – оказа се РЗИ (Столичната регионална здравна инспекция). Проведох около 15 разговора с 5-6 различни хора в РЗИ, изчетох приложимата нормативна уредба (Наредба 26, Наредба 3, и общо взето заключих три неща:

  • Това не е работа на никого. Може би на инспекторите.
  • Няма нормативно основание за изискване на печати
  • Могат да глобят яслата, ако няма печати, защото „разбира се, че ще ви върнат, като нямате печат“

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

Така че предприех следните мерки:

  • Писмо до Министерство на здравеопазването с предложения за нормативно уреждане на автентичността на медицински изследвания
  • Писмо до РЗИ да прекратят незаконосъобразните си практики
  • Писмо до Столична община, да установи ясни изисквания към детските ясли относно реквизитите на документи, които изискват

Целта е да има законосъобразни правила, директорите на яслите и инспекторите на РЗИ да знаят какви са правилата, а не да си ги измислят на място или да правят „както винаги са правили“, без да има нормативно основание за това.

Писмата до РЗИ и Столична община са скучни, но ще приложа писмото до Министерство на образованието, защото там са реалните предложения за промяна. Както сподели един от хората в РЗИ, съществува проблем с фалшиви изследвания, и „декларациите не работят“ (на моето предложение да спазват административнопроцесуалния кодекс и да приемат декларация за истинност на изследванията):

Чл. 43. Административният орган не може да откаже приемане на писмена декларация, с която се установяват факти и обстоятелства, за които специален закон не предвижда доказване по определен начин или с определени средства. [..]

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

Уважаеми г-н Министър,

Във връзка с неписано правило Столичната РЗИ да изисква два различни печата върху изследвания за приемане на деца (по реда на чл. 20 от Наредба 26 от 18.11.2008 за устройството на дейността на детските ясли и детските кухни и здравните изисквания към тях), и отчитайки:
1. Голямото неудобство за родители в това да бъдат куриери на администрацията и в 21-ви век да обикалят за различни видове печати, особено в контекста на пандемия.
2. Риска от предоставяне на фалшиви изследвания
3. Факта, че повечето лаборатории имат онлайн системи за предоставяне на резултатите от изследвания
4. Усилията за въвеждане на електронно здравеопазване

бих искал да предложа следното изменение на Наредба 26:

В чл. 20 се създават нови алинеи 3-5:
(3) Автентичността на изследванията по ал. 1, т.3-5 се удостоверява от лабораторията, извършила изследването, по един от следните начини:
1. чрез възможност за проверка с телефонно обаждане на база на уникален идентификатор на изследването. Телефон за контакт и номер на изследването трябва да са посочени в документа с резултатите.
2. чрез предоставяне от страна на родителите на данни за достъп до онлайн система за проверка на резултата
3. чрез електронен печат на лабораторията върху електронен документ с резултатите, по смисъла на Регламент (ЕС) № 910/2014 на Европейския парламент и на Съвета от 23 юли 2014 г. относно електронната идентификация и удостоверителните услуги при електронни трансакции на вътрешния пазар и за отмяна на Директива 1999/93/ЕО (ОВ, L 257/73 от 28 август 2014 г.)
3.
(4) Резултатите от изследванията по ал. 1, т.3-5 се приемат на хартиен носител и по електронен път, на адрес на електронна поща или чрез системата за сигурно електронно връчване по смисъла на § 1, т. 31 от допълнителните разпоредби на Закона за електронното управление.
(5) Резултатите от изследванията по ал. 1, т.3-5 се съхраняват за срок от 12 месеца, след което се унищожават.

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

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

С уважение,
Божидар Божанов

В по-общ смисъл, за цялата драма с печатите преди време бях подготвил изменение на Административнопроцесуалния кодекс, с която да се забрани изискването на печати:

„§ 1а. (1) Във връзка с административното обслужване на гражданите и юридическите лица административните органи, лицата, осъществяващи публични функции, и организациите, предоставящи обществени услуги не могат да изискват полагане на печат върху документ на хартиен носител за удостоверяване на авторството.
(2) Авторството на документ по ал. 1 се удостоверява от неговия издател чрез саморъчен подпис. Документът съдържа информация за имената на лицето, което го е издало, качеството и длъжността, в които действа, както и основанието на неговата представителна власт.
(3) Органите, лицата и организациите по ал. 1 не могат да отказват приемане на документ от граждани и юридически поради липса на поставен печат.
(4) За неизпълнение на задълженията по ал. 1 и 3 на отговорните длъжностни лица се налага административнонаказателна санкция по чл. 305 от Административнопроцесуалния кодекс.“

(Следват изменения на двайсетина закона, които в момента изискват печат под някаква форма, които ще ви спестя, – такъв законопроект Демократична България ще може да внесе в парламента след няколко месеца.)

Защо се занимавам с нещо толкова дребно? Нали вече записахме детето, повече едва ли ще имаме тоя проблем?

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

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

ElasticSearch Multitenancy With Routing

Post Syndicated from Bozho original https://techblog.bozho.net/elasticsearch-multitenancy-with-routing/

Elasticsearch is great, but optimizing it for high load is always tricky. This won’t be yet another “Tips and tricks for optimizing Elasticsearch” article – there are many great ones out there. I’m going to focus on one narrow use-case – multitenant systems, i.e. those that support multiple customers/users (tenants).

You can build a multitenant search engine in three different ways:

  • Cluster per tenant – this is the hardest to manage and requires a lot of devops automation. Depending on the types of customers it may be worth it to completely isolate them, but that’s rarely the case
  • Index per tenant – this can be fine initially, and requires little additional coding (you just parameterize the “index” parameter in the URL of the queries), but it’s likely to cause problems as the customer base grows. Also, supporting consistent mappings and settings across indexes may be trickier than it sounds (e.g. some may reject an update and others may not depending on what’s indexed). Moving data to colder indexes also becomes more complex.
  • Tenant-based routing – this means you put everything in one cluster but you configure your search routing to be tenant-specific, which allows you to logically isolate data within a single index.

The last one seems to be the preferred option in general. What is routing? The Elasticsearch blog has a good overview and documentation. The idea lies in the way Elasticsearch handles indexing and searching – it splits data into shards (each shard is a separate Lucene index and can be replicated on more than one node). A shard is a logical grouping within a single Elasticsearch node. When no custom routing is used, and an index request comes, the ID is used to determine which shard is going to be used to store the data. However, during search, Elasticsearch doesn’t know which shards have the data, so it has ask multiple shards and gather the results. Related to that, there’s the newly introduced adaptive replica selection, where the proper shard replica is selected intelligently, rather than using round-robin.

Custom routing allows you to specify a routing value when indexing a document and then a search can be directed only to the shard that has the same routing value. For example, at LogSentinel when we index a log entry, we use the data source id (applicationId) for routing. So each application (data source) that generates logs has a separate identifier which allows us to query only that data source’s shard. That way, even though we may have a thousand clients with a hundred data sources each, a query will be precisely targeted to where the data for that particular customer’s data source lies.

This is key for horizontally scaling multitenant applications. When there’s terabytes of data and billions of documents, many shards will be needed (in order to avoid large and heavy shards that cause performance issues). Finding data in this haystack requires the ability to know where to look.

Note that you can (and probably should) make routing required in these cases – each indexed document must be required to have a routing key, otherwise an implementation oversight may lead to a slow index.

Using custom routing you are practically turning one large Elasticsearch cluster into smaller sections, logically separated based on meaningful identifiers. In our case, it is not a userId/customerId, but one level deeper – there are multiple shards per customer, but depending on the use-case, it can be one shard per customer, using the userId/customerId. Using more than one shard per customer may complicate things a little – for example having too many shards per customer may require searches that span too many shards, but that’s not necessarily worse than not using routing.

There are some caveats – the isolation of customer data has to be handled in the application layer (whereas for the first two approaches data is segregated operationally). If there’s an application bug or lack of proper access checks, one user can query data from other users’ shards by specifying their routing key. It’s the role of the application in front of Elasticsearch to only allow queries with routing keys belonging to the currently authenticated user.

There are cases when the first two approaches to multitenancy are viable (e.g. a few very large customers), but in general the routing approach is the most scalable one.

The post ElasticSearch Multitenancy With Routing appeared first on Bozho's tech blog.

Is It Really Two-Factor Authentication?

Post Syndicated from Bozho original https://techblog.bozho.net/is-it-really-two-factor-authentication/

Terminology-wise, there is a clear distinction between two-factor authentication (multi-factor authentication) and two-step verification (authentication), as this article explains. 2FA/MFA is authentication using more than one factors, i.e. “something you know” (password), “something you have” (token, card) and “something you are” (biometrics). Two-step verification is basically using two passwords – one permanent and another one that is short-lived and one-time.

At least that’s the theory. In practice it’s more complicated to say which authentication methods belongs to which category (“something you X”). Let me illustrate that with a few emamples:

  • An OTP hardware token is considered “something you have”. But it uses a shared symmetric secret with the server so that both can generate the same code at the same time (if using TOTP), or the same sequence. This means the secret is effectively “something you know”, because someone may steal it from the server, even though the hardware token is protected. Unless, of course, the server stores the shared secret in an HSM and does the OTP comparison on the HSM itself (some support that). And there’s still a theoretical possibility for the keys to leak prior to being stored on hardware. So is a hardware token “something you have” or “something you know”? For practical purposes it can be considered “something you have”
  • Smartphone OTP is often not considered as secure as a hardware token, but it should be, due to the secure storage of modern phones. The secret is shared once during enrollment (usually with on-screen scanning), so it should be “something you have” as much as a hardware token
  • SMS is not considered secure and often given as an example for 2-step verification, because it’s just another password. While that’s true, this is because of a particular SS7 vulnerability (allowing the interception of mobile communication). If mobile communication standards were secure, the SIM card would be tied to the number and only the SIM card holder would be able to receive the message, making it “something you have”. But with the known vulnerabilities, it is “something you know”, and that something is actually the phone number.
  • Fingerprint scanners represent “something you are”. And in most devices they are built in a way that the scanner authenticates to the phone (being cryptographically bound to the CPU) while transmitting the fingerprint data, so you can’t just intercept the bytes transferred and then replay them. That’s the theory; it’s not publicly documented how it’s implemented. But if it were not so, then “something you are” is “something you have” – a sequence of bytes representing your fingerprint scan, and that can leak. This is precisely why biometric identification should only be done locally, on the phone, without any server interaction – you can’t make sure the server is receiving sensor-scanned data or captured and replayed data. That said, biometric factors are tied to the proper implementation of the authenticating smartphone application – if your, say, banking application needs a fingerprint scan to run, a malicious actor should not be able to bypass that by stealing shared credentials (userIDs, secrets) and do API calls to your service. So to the server there’s no “something you are”. It’s always “something that the client-side application has verified that you are, if implemented properly”
  • A digital signature (via a smartcard or yubikey or even a smartphone with secure hardware storage for private keys) is “something you have” – it works by signing one-time challenges, sent by the server and verifying that the signature has been created by the private key associated with the previously enrolled public key. Knowing the public key gives you nothing, because of how public-key cryptography works. There’s no shared secret and no intermediary whose data flow can be intercepted. A private key is still “something you know”, but by putting it in hardware it becomes “something you have”, i.e. a true second factor. Of course, until someone finds out that the random generation of primes used for generating the private key has been broken and you can derive the private key form the public key (as happened recently with one vendor).

There isn’t an obvious boundary between theoretical and practical. “Something you are” and “something you have” can eventually be turned into “something you know” (or “something someone stores”). Some theoretical attacks can become very practical overnight.

I’d suggest we stick to calling everything “two-factor authentication”, because it’s more important to have mass understanding of the usefulness of the technique than to nitpick on the terminology. 2FA does not solve phishing, unfortunately, but it solves leaked credentials, which is good enough and everyone should have some form of it. Even SMS is better than nothing (obviously, for high-profile systems, digital signatures is the way to go).

The post Is It Really Two-Factor Authentication? appeared first on Bozho's tech blog.

Хронология на липсващата електронна идентификация

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

Електронна идентификация (по-конкретно националната схема за електронна идентификация), която е и кокошката, и яйцето на електронното управление, все още я няма. Ето кратка хронология:

  1. В края на 2016 г. е готово всичко – има закон, правилник, осигурено европейско финансиране, техническа спецификация и документация по ЗОП (Закона за обществените поръчки).
  2. Процедурата е пусната… и спряна в края на лятото на 2017 г (в следствие на няколко фалшиви обжалвания пред КЗК от фирми, чиято дейност няма нищо общо с поръчката).
  3. Август 2018 (1г по-късно) електронната идентификация е пусната като част от голямата поръчка за личните карти.
  4. Поради избора на усложнена процедура свързана с класифицирането на части от поръчката (на две стъпки – одобрение на кандидати, и след това поръчка), изпълнител е избран в края на април тази година. Към момента доколкото знам тече процедура по обжалване на решението.
  5. Очаква се до края на годината (ако обжалванията паднат) да бъде сключен договор с изпълнителя и той да започне работа
  6. Сроковете за eID по спомен са около 18 месеца, т.е. в края на 2022 г. ще имаме система. Чиято спецификация е писана 6 години и половина по-рано и вече не е напълно актуална (напр. вече е достатъчно сигурно да се записва частен ключ в мобилен телефон с Android или iOS; през 2016 г. не беше).

Защо е толкова важна електронната идентификация (за която съм писал доста)? Дългият отговор е в тази 40-минутна презентация от 2016г. Краткият отговор е: защото гражданите нямат налично и удобно средство да се идентифицират онлайн пред държавата. Електронните подписи, които в преходния период (удължен от „2 години“ на „докато стане“) трябва да вършат тази работа имат редица проблеми.

Първо – те са средство за подписване, не за идентификация и като такива нямат възможността в реално време да предоставят актуална информация за лицето извън записаната в удостоверението. Няма нужда да имаме саморъчен подпис, за да покажем на държавата (или дори на частни субекти) кои сме в онлайн среда. Трябва ни „виртуална лична карта“, която обаче не може да се копира и фалшифицира. Електронни услуги за физически лица могат и трябва да се ползват само с идентификация, с малки изключения.

Второ – струват пари и поради това (без значение колко са евтини), не може да се постигне масовост сред гражданите. Така дори да има е-услуги, хората няма с какво да ги ползват. Пример – опашките пред НОИ през март, след като НОИ пусна доста услуги онлайн, но хората трябваше да се наредят, за да си вземат ПИК. При електронната идентификация положението е „апетитът идва с яденето“. И трябва критична маса хора просто да разполагат със средството за идентификация в джоба си, за да потеглят нещата. Примери за това много, като любимият ми е Естония срещу Финландия. Естония дава на всички безплатна електронна идентификация, Финландия я прави опционална и платена. 15 години по-късно Естония „изнася“ електронно управление за Финландия, които изостават значително (опростявам историята, но е горе-долу така).

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

Без електронна идентификация, всяка електронна услуга има много малка аудитория, което се потвърждава и от данните – извън услугите на НАП, които НАП активно промотира заедно със своя ПИК, използването на почти всички останали е минимално и доста неудобно.

Защо не е станало още? Всички политически решения по пътя от 2017 досега са лоши – спиране на отделната процедура; обединяване с голяма поръчка без реална нужда от това; засекретяване и избор на утежнена процедура; процедура, която не е разделена на лотове, позволяващи различни изпълнители; бавене.

Така при напълно готова документация и финансиране, цял мандат не стига дори да се започне работа по най-ключовата система за електронното управление. Всички останали институции (вкл. ЦИК за пилотното дистанционно електронно гласуване) пък се оправдават „ами тя е в МВР системата, ние нищо не можем да направим“.

Та така за управленския капацитет, визията и стратегическите проекти за модернизация на страната. Кой щял да дойде след оставката.. ‘де да знам, дано някой, дето да може за един мандат поне договор да сключи.

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

Наръчник за правилно протестиране

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

Протестите са хубаво нещо по принцип, обаче… тия точно не! Сега ще ви обясня как е правилно да се протестира, така че всички да са доволни.

Правилно протестиращият не иска просто оставка, защото така не е достатъчно ясно какво точно иска. Правилно протестиращият трябва да си носи в джоба лист А4 със законодателни изменения, които преди това е синхронизирал с всички останали на площада. Иначе за какво протестира?

Правилно протестиращият, обаче, трябва да протестира и срещу всичко останало и да има много точен отговор на въпроса къде е бил, когато нещо друго е станало.

Правилно протестиращият трябва да каже кой ще дойде след оставката. Нали е там с много хора – да съберат пари за социология и да имат готов отговор. После изборите ще са проформа.

Правилно протестиращият не е организиран или организатор, но трябва да е подал заявление за протест, да е част от многохилядна тълпа (иначе няма смисъл) и да отговаря в социалните мрежи защо други хора протестират неправилно.

Правилно протестиращият няма предварително подготвен плакат, защото това значи, че някой му плаща. Най-вероятно някой олигарх, то кой друг има пари у нас.

Правилно протестиращият не пие бира. Бира се пие само на маса, а не като тия пропадняци на крак. Това е признак на много ниска култура и липса на национално самосъзнание.

Правилно протестиращият протестира стриктно извън работно време. Противното би значело, че е безработен лентяй.

Правилно протестиращият знае как е било на протестите 90-та година и знае как се прави. Но в същото време трябва да е млад, за да може премиерът да каже една хубава дума за него.

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

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

Правилно протестиращият не прави пърформанси. Не свири на пиано, не се облича театрално, не прави флашмобове. С пърформанси властта няма да падне!

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

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

Правилно протестиращият не се намира в радиус от 100 метра с някой неправилно протестиращ, защото носи отговорност за действията му.

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

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

Общо взето, правилно протестиращият трябва да отиде в 18:30 пред някоя сграда, да поздрави полицията, да надуе свирка десетина пъти, да викне „Оставка“, да си тръгне към 21 ч., преди да са дошли провокаторите, а на другия ден да напише писмо на управляващите какви точно промени иска. Всичко друго е напълно недопустимо и дискредитира и омаскарява иначе легитимния граждански протест, който всички бихме подкрепили!

Жалко, че толкова много хора протестират неправилно. Ако следваха този наръчник, властта нямаше да е паднала, но щеше да е по-добре – щеше да е чула протестиращите! Представям си го така – след получаване на исканията на протестиращите се прави междуведомствена работна група, която да предложи нормативни изменения, по които да бъде постигнат консенсус в легитимно избраното Народно събрание! Чувал съм, че така работят развитите западни демокрации, към които се стремим.

Пък и защо да пада легитимно избрана власт? Никакви корупционни скандали, зависимости на премиера, нарушаване на законови и етични стандарти, не могат да са достатъчен аргумент срещу демократично избрана власт. Милион и двеста хиляди избиратели са казали, че искат тези управляващи да дават поръчки и влияние на Пеевски, Доган и други обръчи и да пратят правилните хора във ВСС, които да изберат Гешев. Тези хора на площада са по-малко от милион и двеста хиляди!

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

Bulk vs Individual Compression

Post Syndicated from Bozho original https://techblog.bozho.net/bulk-vs-individual-compression/

I’d like to share something very brief and very obvious – that compression works better with large amounts of data. That is, if you have to compress 100 sentences you’d better compress them in bulk rather than once sentence at a time. Let me illustrate that:

public static void main(String[] args) throws Exception {
    List<String> sentences = new ArrayList<>();
    for (int i = 0; i < 100; i ++) {
        StringBuilder sentence = new StringBuilder();
        for (int j = 0; j < 100; j ++) { 
          sentence.append(RandomStringUtils.randomAlphabetic(10)).append(" "); 
        } 
        sentences.add(sentence.toString()); 
    } 
    byte[] compressed = compress(StringUtils.join(sentences, ". ")); 
    System.out.println(compressed.length); 
    System.out.println(sentences.stream().collect(Collectors.summingInt(sentence -> compress(sentence).length)));
}

The compress method is using commons-compress to easily generate results for multiple compression algorithms:

public static byte[] compress(String str) {
   if (str == null || str.length() == 0) {
       return new byte[0];
   }
   ByteArrayOutputStream out = new ByteArrayOutputStream();
   try (CompressorOutputStream gzip = new CompressorStreamFactory()
           .createCompressorOutputStream(CompressorStreamFactory.GZIP, out)) {
       gzip.write(str.getBytes("UTF-8"));
       gzip.close();
       return out.toByteArray();
   } catch (Exception ex) {
       throw new RuntimeException(ex);
   }
}

The results are as follows, in bytes (note that there’s some randomness, so algorithms are not directly comparable):

AlgorithmBulkIndividual
GZIP659010596
LZ4_FRAMED921410900
BZIP2666312451

Why is that an obvious result? Because of the way most compression algorithms work – they look for patterns in the raw data and create a map of those patterns (a very rough description).

How is that useful? In big data scenarios where the underlying store supports per-record compression (e.g. a database or search engine), you may save a significant amount of disk space if you bundle multiple records into one stored/indexed record.

This is not a generically useful advice, though. You should check the particular datastore implementation. For example MS SQL Server supports both row and page compression. Cassandra does compression on an SSTable level, so it may not matter how you structure your rows. Certainly, if storing data in files, storing it in one file and compressing it is more efficient than compressing multiple files separately.

Disk space is cheap so playing with data bundling and compression may be seen as premature optimization. But in systems that operate on large datasets it’s a decision that can save you a lot of storage costs.

The post Bulk vs Individual Compression appeared first on Bozho's tech blog.

Making Sense of the Information Security Landscape

Post Syndicated from Bozho original https://techblog.bozho.net/making-sense-of-the-information-security-landscape/

There are hundreds of different information security solutions out there and choosing which one to pick can be hard. Usually decisions are driven by recommendations, vendor familiarity, successful upsells, compliance needs, etc. I’d like to share my understanding of the security landscape by providing one-line descriptions of each of the different categories of products.

Note that these categories are not strictly defined sometimes and they may overlap. They may have evolved over time and a certain category can include several products from legacy categories. The explanations will be slightly simplified. For a generalization and summary, skip the list and go to the next paragraph. This post aims to summarize a lot of Gertner and Forester reports, as well as product data sheets, combined with some real world observations and to bring this to a technical level, rather than broad business-focused capabilities. I’ll split them in several groups, though they may be overlapping.

Monitoring and auditing

  • SIEM (Security Information and Event Management) – collects logs from all possible sources (applications, OSs, network appliances) and raises alarms if there are anomalies
  • IDS (Intrusion Detection System) – listening to network packets and finding malicious signatures or statistical anomalies. There are multiple ways to listen to the traffic: proxy, port mirroring, network tap, host-based interface listener. Deep packet inspection is sometimes involved, which requires sniffing TLS at the host or terminating it at a proxy in order to be able to inspect encrypted communication (especially for TLS 1.3), effectively doing an MITM “attack” on the organization users.
  • IPS (Intrusion Prevention System) – basically a marketing upgrade of IDS with the added option to “block” traffic rather than just “report” the intrusion.
  • UEBA (User and Entity Behavior Analytics) – a system that listens to system activity (via logs and/or directly monitoring endpoints for user and system activity, including via screen capture) that tries to identify user behavior patterns (as well as system component behavior patterns) and report on any anomalies and changes in the pattern, also classifying users as less or more “risky”. Recently UEBA has been part of next-gen SIEMs
  • SUBA (Security user Behavior Analytics) – same as UEBA, but named so after the purpose (security) rather than the entities monitored. Used by Forester (whereas UEBA is used by Gartner)
  • DAM (Database Activity Monitoring) – tools that monitor and log database queries and configuration changes, looking for suspicious patterns and potentially blocking them based on policies. Implemented via proxy or agents installed at the host
  • DAP (Database Audit and Protection) – based on DAM, but with added features for content classification (similar to DLPs), vulnerability detection and more clever behavior analysis (e.g. through UEBA)
  • FIM (File Integrity Monitoring) – usually a feature of other tools, FIM is constantly monitoring files for potentially suspicious changes
  • SOC (Security Operations Center) – this is more of an organizational unit that employs multiple tools (usually a SIEM, DLP, CASB) to fully handle the security of an organization.

Access proxies

  • CASB (Cloud Access Security Broker) – a proxy (usually) that organizations go through when connecting to cloud services that allow them to enforce security policies and detect anomalies, e.g. regarding authentication and authorization, input and retrieval of sensitive data. CASBs may involve additional encryption options for the data being used.
  • CSG (Cloud Security Gateway) – effectively the same as CASB
  • SWG (Secure Web Gateway) – a proxy for accessing the web, includes filtering malicious websites, filtering potentially malicious downloads, limiting uploads
  • SASE (Secure Access Service Edge) – like CASB/CSG, but also providing additional bundled functionalities like a Firewall, SWG, VPN, DNS management, etc.

Firewalls

  • WAF (Web Application Firewall) – a firewall (working as a reverse proxy) that you put in front of web applications to protect them from typical web vulnerabilities that may not be addressed by the application developer – SQL injections, XSS, CSRF, etc.
  • NF (Network Firewall) – the typical firewall that allows you to allow or block traffic based on protocol, port, source/destination
  • NGFW (Next Generation Firewall) – a firewall that combines both network firewall, (web) application firewall and providing analysis of the traffic thus detecting potential anomalies/intrusions/data exfiltration

Data protection

  • DLP (Data Leak Prevention / Data Loss Prevention) – that’s a broad category of tools that aim at preventing data loss – mostly accidental, but sometimes malicious as well. Sometimes involves installing an agent in each machine, in other case it’s proxy-based. Many other solutions provide DLP functionality, like IPS/IDS, WAFs, CASBs, but DLPs are focused on inspecting user activities (including via UEBA/SUBA), network traffic (including via SWGs), communication (most often email) and publicly facing storage (e.g. FTP, S3), that may lead to leaking data. DLPs include discovering sensitive data in structured (databases) and unstructured (office documents) data. Other DLP features are encryption of data at rest and tokenization of sensitive data.
  • ILDP (Information Leak Detection and Prevention) – same as DLP
  • IPC (Information Protection and Control) – same as DLP
  • EPS (Extrusion Prevention System) – same as DLP, focused on monitoring outbound traffic for exfiltration attempts
  • CMF (Content Monitoring and Filtering) – part of DLP. May overlap with SWG functionalities.
  • CIP (Critical Information Protection) – part of DLP, focused on critical information, e.g. through encryption and tokenization
  • CDP (Continuous Data Protection) – basically incremental/real-time backup management, with retention settings and possibly encryption

Vulnerability testing

  • RASP (Runtime Application Self-protection) – tools (usually in the form of libraries that are included in the application runtime) that monitor in real-time the application usage and can block certain actions (at binary level) or even shut down the application if a cyber attack is detected.
  • IASTInteractive Application Security Testing – Similar to RASP, the subtle difference being that IASP is usually used in pre-production environments while RASP is used in production
  • SAST (Static Application Security Testing) – tools that scan application source code for vulnerabilities
  • DAST (Dynamic Application Security Testing) – tools that scans web applications for vulnerabilities through their exposed HTTP endpoints
  • VA (Vulnerability assessment) – a process helped by many tools (including those above, and more) for finding, assessing and eliminating vulnerabilities

Identity and access

  • IAM (Identity and Access Management) – products that allow organizations to centralize authentication and enrollment of their users, providing single-sign-on capabilities, centralized monitoring authentication activity, applying access policies (e.g. working hours), enforcing 2FA, etc.
  • SSO – the ability to use the same credentials for logging into multiple (preferably all) applications in an organization.
  • WAM (Web Access Management) – the “older” version of IAM, lacking flexibility and some features like centralized user enrollment/provisioning
  • PAM (Privileged access management) – managing credentials of privileged users (e.g. system administrators). Instead of having admin credentials stored in local password managers (or worse – sticky notes or files on the desktop), credentials are stored in a centralized, protected vault and “released” for use only after a certain approval process for executing a given admin task, in some cases monitoring and logging the executed activities. The PAM handles regular password changes. It basically acts as a proxy (though not necessarily in the network sense) between a privileged user and a system that requires elevated privileges.

Endpoint protection

  • AV (Anti-Virus) – the good old antivirus software that gets malicious software signatures form a centrally managed blacklist and blocks programs that match those signatures
  • NGAV (Next Generation Anti-Virus) – going beyond signature matching, NGAV looks for suspicious activities (e.g. filesystem, memory, registry access/modification) and uses policies and rules to block such activity even from previously unknown and not yet blacklisted programs. Machine learning is usually said to be employed, but in many cases that’s mostly marketing.
  • EPP (Endpoint Protection Platform) – includes NGAV as well as a management layer that allows centrally provisioning and managing policies, reporting and workflows for remediation
  • EDR (Endpoint Detection and Response) – using an agent to collect endpoint (device) data, centralize it, combine it with network logs and analyze that in order to detect malicious activity. After suspected malicious activity is detected, allow centralized response, including blocking/shutting down/etc. Compared to NGAV, EDR makes use of the data across the organization, while NGAV usually focuses on individual machines, but that’s not universally true
  • ATP (Advanced threat protection) – same as EDR
  • ATD (Advanced threat detection) – same as above, with just monitoring and analytics capabilities

Coordination and automation

  • UTM (Unified Threat Management) – combining multiple monitoring and prevention tools in one suite (antivirus/NGAV/EDR), DLP, Firewalls, VPNs, etc. The benefit being that you purchase one thing rather than finding your way through the jungle described above. At least that’s on paper; in reality you still get different modules, sometimes not even properly integrated with each other.
  • SOAR (Security Orchestration, Automation and Response) – tools for centralizing security alerts and configuring automated actions in response. Alert fatigue is a real thing with many false positives generated by tools like SIEMs/DLPs/EDRs. Reducing those false alarms is often harder than just scripting the way they are handled. SOAR provides that – it ingests alerts and allows you to use pre-built or custom response “cookbooks” that include checking data (e.g. whether an IP is in some blacklist, are there attachments of certain content type in a flagged email, whether an employee is on holiday, etc.), creating tickets and alerting via multiple channels (email/sms/other type of push)
  • TIP (Threat Intelligence Platform) – threat intelligence is often part of other solutions like SIEMs, EDRs and DLPs and involves collecting information (intelligence) about certain resources like IP addresses, domain names, certificates. When these items are discovered in the collected logs, the TIP can enrich the event with what it knows about the given item and even act in order to block a request, if a threat threshold is reached. In short – scanning public and private databases to find information about malicious actors and their assets.

Email

  • SEG (Secure email gateway) – a proxy for all incoming and outgoing email that scans them for malicious attachments, potential phishing and in some cases data exfiltration attempts.
  • MFT (Managed File Transfer) – a tool that allows sharing files securely with someone by replacing attachments. Shared files can be tracked, monitored, audited and scanned for vulnerabilities, and access can be cut once the files was downloaded by the recipient, reducing the risk of data leaks.

DDoS

  • DDoS mitigation/protection – services that hide your actual IP in an attempt to block malicious DDoS traffic before it reaches your network (when it’s too late). They usually rely on large global networks an data centers (called “scrubbing centers”) to send clean traffic to your servers.

Compliance

  • GRC (Governance, Risk and Compliance) – a management tool for handling all the policies, audits, risk assessments, workflows and reports regarding different aspects of compliance, including security compliance
  • IRM – allegedly, philosophically different and more modern and advanced, in reality – the same as GRC with some additional monitoring features

So let’s summarize the ways that all of these solutions work:

  • Monitoring logs and other events
  • Inspecting incoming traffic and finding malicious activities
  • Inspecting outgoing traffic and applying policies
  • Application vulnerability detection
  • Automating certain aspects of the alerting, investigation and response handling

Monitoring (which is central to most tools) is usually done via proxies, port mirroring, network taps or host-based interface listeners, each having its pros and cons. Enforcement is almost always done via proxies. Bypassing these proxies should not be possible, but for cloud services you can’t really block access if the service is accessed outside your corporate environment (unless the SaaS provider has an IP whitelist feature).

In most cases, even though machine learning/AI is advertised as “the new thing”, tools make decisions based on configured policies (rules). Organizations are drowned in complex policies that they should keep up to date and syncrhonize across tools. Policy management, especially given there’s no indsutry standard for how policies should be defined, is a huge burden. In theory, it gives flexibility and should be there, in practice it may lead to a messy and hard to manage environment.

Monitoring is universally seen as the way to receive actionable intelligence from systems. This is much messier in reality than in demos and often leads to systems being left unmonitored and alerts being ignored. Alert fatigue, which follows from the complexity of policy management, is a bug problem in information security. SOAR is a way to remedy that but it sounds like a band-aid on a broken process rather than a true solution – false alarms should be reduced rather than being closed quasi-automatically. If handling an alert is automatable, then tha tool that generates it should be able to know it’s not a real problem.

The complexity of the security landscape is obviously huge – product categories are defined based on multiple criteria – what problem they solve, how they solve it, or to what extent they solve it. Is a SIEM also a DLP if it uses UEBA to block certain traffic (next-gen SIEMs may be able to invoke blocking actions even if requiring another system to carry it out). Is a DLP a CASB if it does encryption of data that’s stored in cloud services? Should you have an EPP and a SIEM, if the EPP gives you good enough overview of the events being logged in your infrastructure? Is a CASB a WAF for SaaS? Is a SIEM a DAM if it supports native database audit logs? You can’t answer these questions at a category level, you have to look at particular products and how well they implement a certain feature.

Can you have a unified proxy (THE proxy) that monitors everything incoming and outgoing and collects that data, acting as WAF, DLP, SIEM, CASB, SEG? Can you have just one agent that is both a EDR, and a DLP? Well, certainly categories like SASE and UTM go in that direction, trying to ease the decision making process.

I think it’s most important to start from the attack targets, rather than from the means to get there or from the means to prevent getting there. Unfortunately, enterprise security is often driven by “I need to have this type of product”. This leads to semi-abandoned and partially configured tools for which organizations pay millions. Because there is never enough people to be able to go into the intricate details of yet another security soluion, and organizations rely on consultants to set things up.

I don’t have solutions to the problems stated above, but I hope I’ve given a good overview of the landscape. And I think we should focus less on “security products” and more on “security techniques” and on people that can implement them. You don’t have a billion dollar corporation to sell you a silver bullet (which you can’t fire). You need traind experts. That’s hard. There aren’t enough of them. And the security team is often undervalued in the enterprise. Yes, cybersecurity is very important, but I’m not sure whether this will ever get enough visibility and be prioritized over purely business goals. And maybe it shouldn’t, if risk is properly calculated.

All the products above are ways to buy some feeling of security. If used properly and in the right combination, it can be more than a feeling. But too often a feeling is just good enough.

The post Making Sense of the Information Security Landscape appeared first on Bozho's tech blog.

Как МРРБ, ГРАО и КЗЛД спират електронното управление

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

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

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

Правилният начин, обаче, е системата за класиране в детски градини и ясли автоматично да проверява настоящия/постоянния адрес на родителите и да изчислява точките за класиране спрямо това. Само че ГД ГРАО (Главна дирекция Гражданска регистрация и административно обслужване към МРРБ), която е първичен администратор на данните за постоянен и настоящ адрес, не е на това мнение.

Спорът стига до Комисията за защита на личните данни, която на 26-ти май тази година излиза със становище по казуса. Становището се чете трудно и не е ясно какво казва дори за хора с опит в материята. На практика казва, че ГРАО трябва да предоставя данни само ако другата страна вече има тези данни (т.е. събрала ги е от гражданите). И че това не може да се случва автоматично.

Регистрите на ЕСГРАОН са в основата на електронното управление. На практика всяка услуга минава през достъп до регистъра на населението. Когато се идентифицирате електронно (със средство за електронна идентификация, каквото в момента временно е и квалифицираният електронен подпис), по вашето ЕГН трябва да се извлекат автоматично данни, необходими за дадена услуга. Така казват и Закона за електронното управление, и Административнопроцесуалният кодекс.

Обаче на практика ГРАО и КЗЛД ни казват, че не позволяват да има истинско електронно управление, защото дори да има нормативно основание за обработване на данните, това не може да става автоматизирано.

Аргументите са също трудни за четене като заключението. Реално, с оглед защита на данните, наистина безконтролен достъп до ЕСГРАОН е проблем. Само че решението не е да се забрани. Решението включва няколко компонента. Базовият е задължителната одитна следа, показваща кой и на какво основание е достъпвал данни. В естонския пример това е ключово за да ограничи злоупотреби.

Но най-важният компонент е регистрите на ЕСГРАОН да бъдат обновени, за да поддържат гъвкави автоматизирани заявки и за да бъдат стабилни при увеличено натоварване. Какво би значело това в конкретния случай с детските градини – за да се установи дали един родител отговаря или не на критерий. На общината не ѝ е нужно да знае нечий адрес. Да, общината е тази, която регистрира гражданите на съответния адрес, така че от една страна е абсурдно да няма достъп до тези данни, но с оглед минимизиране на рисковете това трябва да става само при нужда. Та, общината има нужда да знае дали адресът на родителите е в съответния район. Това може да установи като попита (автоматизирано) ГРАО: „адресът на гражданин с ЕГН XXXXXX попада ли в район YYYYY“. И ГРАО да върне „да“ или „не“, което е достатъчно за изчисляване на точките.

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

За съжаление, от 2016 г., когато е приета пътната карта, ГД ГРАО и МРРБ на практика не са направили нищо за нов регистър, на практика спирайки ефективното развитие на електронното управление. Това увъртяно становище на КЗЛД, макар донякъде философски правилно, не посочва практически решения, които да са в духа на GDPR и чрез които да се изпълнят изискванията на ЗЕУ и АПК.

Това можем да го отдадем на спор между администрации – от една страна Държавна агенция „Електронно управление“ и Столична община, от друга МРРБ/ГРАО и КЗЛД. И да ги оставим да си спорят вечно, като ГРАО да продъжава да отказва достъп на всеки, който иска да автоматизира административното си обслужване (без да натовари администрацията си с ръчно ровене).

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

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

„Я кажи за Буджака“

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

Росенец стана символ много бързо. И концентрира толкова много прожекторите върху Доган, ДПС, Пеевски и връзките им с националната и местната власт на ГЕРБ, че властта (явната и тайната) трябваше да отговори някак комуникационно. А най-добрата защита е атаката.

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

Всяко лято от 33 години съм в Черноморец (имам роднини тук) и виждам как се застроява крайбрежието. Не бях доволен, когато едни скали, на които ходехме, станаха недостъпни сред поредния строеж. Къщите, буквално висящи от скалите винаги са повдигали въпроси. Така че проблем със строителството по крайбрежието има, тъй като философията на закона, а и на конституцията е, че крайбрежието е на всички и никой няма право да си го присвоява или ограничава. По същия начин най-вероятно се чувстват много хора, което направи Росенец още по-силен символ, но което дава сила и на другите примери.

След като темата с Буджака стигна до националните медии, при почти всяко повдигане на темата с Росенец, се появяваше някой да каже „а я кажи за Буджака“. Журналисти на СКАТ (на Валери Симеонов) пък бяха пратени на Росенец да питат Христо Иванов един въпрос – за Буджака. А неговият отговор, че не е запознат, беше използван за да подсили опорната точка за „двойния аршин“.

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

Реших да проверя пък какво толкова има на Буджака. Отворих Google maps (сателитните снимки и street view), кадастъра (зареди 20-тина лева за справки), новинарските публикации, снимките и репортажите. За малко да отида на място, да разгледам. Казах си – добре, ако наистина има проблем, трябва някак да го адресираме, а не да го избягваме. Представях си как някоя ограда е затворила нещо и трябва да се бутне, представих си аналогична на ситуацията в Черноморец, където можеш да видиш скалите, но не можеш вече да стигнеш до тях.

Обаче реалността се оказа друга. Първо, имот на Прокопиев не блокира нито път, нито достъп до плаж. Преди две години в съседство друг бизнесмен всъщност е ограничил частично достъпа, както отбелязва в тази статия Флагман. След преглед в кадастъра, репортажа на Канал 3 и използваната след това снимка в Tribune (също проправителствен) осъзнах, че те дори не знаят кой е имотът на Прокопиев. Този, който показват (и който проверих първо) е на адвокат и е далеч от този на Прокопиев.

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

Но въпреки реалността беше построен перфектният „фалшив двойник“ на Росенец, който беше раздухана в синхрон от всички медии както на сараите, така и на властта (Канал3, Нова, СКАТ, Вести, Дарик, Tribune и др.) и който ще продължава да отеква по фейсбук коментари и спорове на маса – „защо Христо Иванов не отиде на Буджака. Защо има двоен стандарт“. А двойният стандарт дразни хората. Прави нещата да изглеждат неистински. Това е опит Росенец и сараите да се принизят до обикновено нарушение, каквото всички други правят.

Христо Иванов не е ДНСК, прокуратура или община. Той не геодезист, инспектор, архитект, за да ходи да мери отстояния, ширина на пътеки, да сравнява ПУП-ове и да бута огради. Акцията на Росенец показа силно и нагледно това, което журналисти бяха разкривали преди това – как община, НСО и няколко министерства са плюли на закона и обществения интерес, за да се обособи един анклав на почетния председател.

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

Няма добър отговор на „Я кажи за Буджака“. Защото това не е истински въпрос, аргумент или молба. Това е стандартна пропагандна тактика и логическа заблуда. Опит не само да се дискредитира един политик и една партия, а да се омаловажат и прикрият зависимостите, които Росенец освети.

Но ето, казах за Буджака. Ще кажа и за цялото черноморие. ЗУЧК гласи:

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

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

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

Трябва да си говорим. Защото държавата е завладяна.

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

Протестът е много важен. И колкото повече хора участват в него, толкова по-силна е тезата, че властта е прекрачила граници, които не се прекрачват.

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

Има и такива, на които тази форма на гражданско участие не им харесва, не обичат да са в тълпа, без значение колко са недоволни.

И това е окей.

Има такива, които дори ще са критични към едно или друго нещо. На които са им затворили автобусната спирка, които не могат да отидат с колата на работа, или които се налага да закъснеят за работа, за да заведат детето си на градина. И те могат да са недоволни и критични, като същевременно подкрепят исканията на протеста.

И това е окей.

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

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

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

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

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

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

И ако искаме да не им мине номера, трябва да си говорим. Спокойно, приятелски и незабравяйки причината за всичко това – превзетата ни държава.

Encryption Overview [Webinar]

Post Syndicated from Bozho original https://techblog.bozho.net/encryption-overview-webinar/

“Encryption” has turned into a buzzword, especially after privacy standards and regulation vaguely mention it and vendors rush to provide “encryption”. But what does it mean in practice? I did a webinar (hosted by my company, LogSentinel) to explain the various aspects and pitfalls of encryption.

You can register to watch the webinar here, or view it embedded below:

And here are the slides:

Of course, encryption is a huge topic, worth a whole course, rather than just a webinar, but I hope I’m providing good starting points. The interesting technique that we employ in our company is “searchable encryption” which allows to have encrypted data and still search in it. There are many more very nice (and sometimes niche) applications of encryption and cryptography in general, as Bruce Schneier mentions in his recent interview. These applications can solve very specific problems with information security and privacy that we face today. We only need to make them mainstream or at least increase awareness.

The post Encryption Overview [Webinar] appeared first on Bozho's tech blog.

Разсъждения по парламентарните процедури

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

Тези дни имаше много хора, които не разбираха как така има повече гласували, отколкото регистрирани в парламента.

И запознатите побързаха да обяснят как това било нормално и такава била процедурата. И това е вярно. Броят регистрирани няма общо с гласуващите. Регистрацията е за кворума, гласуването е отделно.

Но тази процедура ходи по ръба на идеята на Конституцията:

Чл. 81. (1) Народното събрание открива заседанията си и приема своите актове, когато присъстват повече от половината народни представители.
(2) Народното събрание приема законите и другите актове с мнозинство повече от половината от присъстващите народни представители, освен когато Конституцията изисква друго мнозинство.

Само че ПОДНС (правилникът на НС) разделя процеса на две – регистрация и гласуване. И води именно до такива привидно куриозни ситуации:

  • 130 регистрирани, 180 гласували (депутати, които гласуват в някое важно гласуване не са се регистрирали в началото, защото няма нужда от тях за кворума)
  • 130 регистрирани, 80 гласували (депутатите са се регистрирали, но са отишли до кафето или да си говорят с някого в кулоарите и не са гласували)

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

Народното събрание е приело, че това не е така. Присъствието се регистрира веднъж, в началото на заседанието. Това не е било така до 2013 г, когато проверка на кворума се е изаършвала (автоматично) преди всяко гласуване. Вероятно това е така заради проблемите на БСП и ДПС с кворума тогава.

Дали новата практика е конституционна не мога да кажа (само Конституционният съд може), но това води до такива странности с бройките. Според мен трябва броят регистрирани да е равен на броя гласували за всяко гласуване. Ако си гласувал, присъстваш, ако не си гласувал, не присъстваш. А това че си някъде в сградата или че си бил сутринта и после си с тръгнал, не значи, че трябва да се считаш там. Мисля, че това е и духът на конституционната норма.

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

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

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

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

Blockchainizing Existing Databases

Post Syndicated from Bozho original https://techblog.bozho.net/blockchainizing-existing-databases/

Blockchain has been a buzzword for the past several years and it hasn’t lived to its promises (yet). The value proposition usually includes vague claims about trust and unmodifiability, but rarely that has brought demonstrable improvement to existing processes.

There are dozens of blockchain projects, networks, protocols, “standards”, and all of them can in some way help you solve either data integrity issues (guarantee that data has not been tampered with) or multi-party trust issues (several companies participating in one process shouldn’t have to trust each other in order to have automated cross-organization business processes).

However, deploying and integrating a separate blockchain solution is usually a large project in itself and especially in the COVID-19 crisis likely gets postponed because of the questionable return on investment.

But for the enterprise, blockchain is largely a shared database. Sharing data with other participants in a given business process in a secure way that doesn’t allow any of the participants to cheat. And this can be achieved not by adding a whole new blockchain infrastructure that would in turn integrate with existing systems (which in many cases can’t be integrated easily because they don’t have APIs), but by “blockchainizing” the existing database.

Ideally, what I’m describing should be a project itself, which is either deployed alongside the database, or as part of an application. And what it can do is as follows:

  • Select tables and columns to share with other participants – obviously only parts of the database should be shared with others
  • Define shared data model and data transformations – sometimes data has to be transformed, or masked, in order to meet regulatory or privacy requirements. Certainly, the databases of participants will differ and they have to be aligned to a common model.
  • Track inserts, updates and deletes, sign them and send them to the peers
  • Manage a PKI with a private key shared with the rest of the participants (or some of them)
  • Generate merkle trees based on the “transactions” (inserts, updates and deletes) and expose them to be verified regularly by the peers
  • Provide an admin dashboard to view various aspects of the system – activity, status of peers, configuration options

Effectively, that’s also an integration effort. Defining shared data models and transformations. It also involves setting up some piece of software that does the “blockchaining” and communication with peers. But since the goal is usually to have a shared database, it makes sense to go directly at the database level, rather than providing an append-only key-value store which is then queried in order to fill the actual database.

Can such an approach be just a configuration option for existing solutions like Openchain, Hyperledger, Corda? It could be – allowing them to stream changes directly to and from an existing database in a predefined fashion.

This post is in the “random ideas” category, things that I’ve thought about could be implemented, but never found the time to do so. I think blockchain should be taken to the ground and viewed as an infrastructure components. Much like enabling database encryption or adding another data source to an ESB for the sake of integrating two systems. Because the business case for blockchain is usually this – integrate several systems and don’t allow them to cheat. I think this can be achieved by plugging at the database level for the systems integrated.

The post Blockchainizing Existing Databases appeared first on Bozho's tech blog.

Защо Росенец?

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

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

Искам да се опитам да обясня какво е Росенец, какво не е Росенец и защо Росенец.

Първо, три неща, които Росенец не е. Росенец не е етнически конфликт, както намекна премиерът и както повтарят свинските медии. Христо Иванов в изявление пред боянските сараи на Доган вчера подчерта, че без значение от етнос и религия, българските граждани искат законът да важи еднакво за всички. И е безотговорно и опасно да се твърди, че протестът има етнически характер, само защото е насочен срещу ДПС. Росенец не е и сценарий срещу влизането в европейския банков съюз и чакалнята за еврозоната, както премиерът се опита съзнателно да заблуди обществото. Няма как да бъде, при положение, че Демократична България от самото си създаване е твърдо „за“ бързото влизане в двете. Росенец не е и „предизборен пиар“, дори само заради хронологичната отдалеченост на парламентарните избори – напролет догодина.

Росенец, обаче, е поне три неща.

Първо, Росенец е символ. На завладяната държава. Място, където кулминира цялото беззаконие, което всички усещат, но трудно може да бъде описано без дълги юридически разсъждения. Плажът и морето, които по закон (и дори по Конституция) са държавна собственост, са на практика присвоени от някой, който е над закона. Че този някой е Доган, няма значение. Днес е Доган, утре е Пеевски, а вдругиден някой друг. Символът се допълва от това, че този някой бива пазен от държавата, с пари от данъците ни, без никаква логична причина за това, а на база на една вратичка, вкарана в закона от депутат от управляващата партия, но със сигурност не измислена от него. Един плаж успява някак да символизира беззаконието по-добре от всяка политическа реч, от всяко съдебно дело.

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

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

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

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

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

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

Няколко електронни препоръки към банките

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

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

Пример за първото са нотариуси, частни съдебни изпълнители и като цяло – лица, на които държавата чрез закон е възложила някакви функции. Обществените услуги са малко по-разтегливи, но законът изрежда следните: „образователни, здравни, водоснабдителни, канализационни, топлоснабдителни, електроснабдителни, газоснабдителни, телекомуникационни, пощенски, банкови, финансови и удостоверителни“. Банковите и удостоверителните бяха добавени изрично с измененията в закона през 2016г, но логически винаги са попадали там. Най-вече, защото банките в много случаи участват или в процеса по предоставяне на административни услуги, или изискват (понякога по силата на закон) данни и обстоятелства, които са резултат от административни услуги (удостоверения, например).

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

  • Автоматично извличане на данни от първични администратори – банките понякога искат предоставяне на данни от страна на гражданите за ползване на някоя услуга, като например удостоверение за семейно положение, удостоверение за наследници, декларация по ЗМИП, дори до преди известно време и актуално състояние. Банките могат, а и е редно, да извличат тези данни от първичните администратори, дали през публичен интерфейс, както е с Търговския регистър, дали през системата за междурегистров обмен RegiX. Банките имат право на това, като доставчик на обществени услуги, и би било много добре да спрат да искат неща. Няколко пъти съм обяснявал на банкови служители, че не могат да искат от мен да предоставям или декларирам данни, които са вписани в Търговския регистър, и че дори подлежат на глоба. Когато се извличат такива данни, задължително трябва да е ясно кой е служителят и системата и за какво се ползват, за да се избегнат злоупотреби. RegiX пази одитна следа на всички такива действия именно с тази цел. Автоматичното извличане на такива данни може да стане и през електронното банкиране (или други онлайн услуги), след като гражданите успешно се идентифицират през националната схема за електронна идентификация (която все още я няма) или през системата за е-автентикация. Същият подход може да се ползва и при KYC (know your customer) процедури – няма нужда клиентът да си описва всичките данни, при положение, че по номер на лична карта могат да се извлекат от регистъра на МВР.
  • Приемане на електронни документи – интеграцията с първични регистри е дълго усилие и отнема време. Но приемането на електронни документи, издадени от администрацията, е законово задължение. За съжаление има много оплаквания, че някоя банка не е приела електронно-подписано удостоверение и е накарала човека да отиде да си го вземе от администрацията с „мокър печат“. Банката е длъжна да приеме електронния документ, тъй като той е валидно обективиран индивидуален административен акт. Администрацията с триста зора е електронизирала дадена услуга, предоставила е електронен документ на гражданина, обаче се оказва, че той не му върши работа, защото някакви вътрешни правила някъде искат мокър печат – това не е приемливо, не е и законно, и намалява интереса и ползването на и без това рядко използваните електронни административни услуги
  • Автоматично обновяване на фирмени профили – фирмите си откриват сметки, след това се случват промени (сменен управител, сменена форма на дружеството и др.) Банките могат (и трябва) да се абонират за промените в Търговския регистър (към момента става с получаване на един XML файл с всички промени за деня) и да обновяват вътрешните си бази данни, вместо да искат от клиентите да го правят. Това от една страна спестява усилия на клиентите, а от друга – спестява главоболия при смяна на управител. Старият управител все още има достъп до електронното банкиране и може да нарежда преводи, а новият може и да не се сети веднага да отиде и да обнови данните в банката (или в банките, защото често фирмите имат сметки в повече от една банка).
  • Използване на електронен печат в е-банкирането – документите, удостоверяващи извършено плащане, са нужни на много места – понякога неправомерно (администрацията знае, че е получила пари, няма нужда, а и право, да иска „бележка“), понякога правомерно – например, при увеличаване на капитал на дружество се изисква доказване, че капиталът е внесен. Електронните банкирания е добре да могат да поставят електронен печат (по смисъла на Регламент (ЕС) 910/2014) върху платежните, така че те да могат да бъдат ползвани в електронен вид. В момента трябва да отидеш до банката и там да ти сложат печат. В някои случаи трябва сам да си носиш разпечатаното платежно, защото те нямат достъп. Електронният печат би решил този проблем, удостоверявайки от името на титуляра на печата – банката – че това платежно е истинско и непроменено.
  • Избягване на еднократни пароли за подписване на преводи – това е сложна и дълга тема, но в общия случай 6-цифрени кодове не дават т.нар. non-repudiation, т.е. свойството на електронните подписи, според което авторът не може да се отрече от извършеното действие. Тъй като те обикновено разчитат на споделен криптографски ключ, а в случай на sms дори цялата информация е при банката, то служител на банката, имащ достъп до ключа, може да нареди превод от името на клиента. На теория, но това е достатъчно за оспорване на транзакции (да, със „з“). Да, на база на други фактори, като IP адреси в логове, сметка на получателя и др. може да се подкрепи едно или друго твърдение, но злонамерен клиент може да маскира следите си достатъчно добре и да твърди, че банката, имайки достъп до споделения криптографски ключ, е наредила превода вместо него. Как да стане по-сигурно – приложенията, които банките ползват, могат да ползват асиметрична криптография, така че подписването да става с ключ, с който банката не разполага. Детайлите тук са много важни и сложни, така че няма да се спиран на тях, но е нещо, за което е добре да се помисли и да се отчетат рисковете.
  • Автоматизиране на процесите по ЗМИП – Законът за мерките срещу изпиране на пари (който е следствие от европейска директива), предвижда възможност за електронна комуникация между банките и ДАНС. Наскоро се появи казус, свързан с тегленето на пари от Васил Божков, тъй като ДАНС отричаше да е получавал уведомление. Няма да навлизам в спецификите на ЗМИП, но тъй като електронната комуникация е само възможност, но не и задължение, практиките са различни и понякога дори включват ръчни процеси. Автоматизирането на процесите по докладване на транзакции по ЗМИП няма общо с електронното управление или удобството за гражданите, но би спестило ситуации, като споменатата преди малко. Тук, разбира се, зависи и от ДАНС какво точно ще приемат.

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

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

Seven Legacy Integration Patterns

Post Syndicated from Bozho original https://techblog.bozho.net/seven-legacy-integration-patterns/

If we have to integrate two (or more) systems nowadays, we know – we either use an API or, more rarely, some message queue.

Unfortunately, many systems in the world do not support API integration. And many more a being created as we speak, that don’t have APIs. So when you inevitably have to integrate with them, you are left with imperfect choices to make. Below are seven patterns to integrate with legacy systems (or not-so-legacy systems that are built in legacy ways).

Initially I wanted to use “bad integration patterns”. But if you don’t have other options, they are not bad – they are inevitable. What’s bad is that fact that so many systems continue to be built without integration in mind.

I’ve seen all of these, on more than one occasion. And I’ve heard many more stories about them. Unfortunately, they are not the exception (fortunately, they are also not the rule, at least not anymore).

  1. Files on FTP – one application uploads files (XML, CSV, other) to an FTP (or other shared resources) and the other ones reads them via a scheduled job, parses them and optionally spits a response – either in the same FTP, or via email. Sharing files like that is certainly not ideal in terms of integration – you don’t get real-time status of your request, and other aspects are trickier to get right – versioning, high availability, authentication, security, traceability (audit trail).
  2. Shared database – two applications sharing the same database may sound like a recipe for disaster, but it’s not uncommon to see it in the wild. If you are lucky, one application will be read-only. But breaking changes to the database structure and security concerns are major issues. You can only use this type of integration is you expose your database directly to another application, which you normally don’t want to do.
  3. Full daily dump – instead of sharing an active database, some organizations do a full dump of their data every day or week and provide to to the other party for import. Obvious data privacy issues exist with that, as it’s a bad idea to have full dumps of your data flying around (in some cases on DVDs or portable HDDs), in addition to everything mention below – versioning, authentication, etc.
  4. Scraping – when an app has no API, it’s still possible to extract data from it or push data to it – via the user interface. With web applications that’s easier, as they “speak” HTML and HTTP. With desktop apps, screen scraping has emerged as an option. The so-called RPA software (Robotic process automation) relies on all types of scraping to integrate legacy systems. It’s very fragile and requires complicated (and sometimes expensive) tooling to get right. Not to mention the security aspect, which requires storing credentials in non-hashed form somewhere in order to let the scraper login.
  5. Email – when the sending or receiving system don’t support other forms of integration, email comes as a last resort. If you can trigger something by connecting a mailbox or if an email is produced after some event happens in the sending system, this may be all you need to integrate. Obviously, email is a very bad means of integration – it’s unstructured, it can fail for many reasons, and it’s just not meant for software integration. You can attach structured data, if you want to get extra inventive, but if you can get both ends to support the same format, you can probably get them extended to support proper APIs.
  6. Adapters – you can develop a custom module that has access to the underlying database, but exposes a proper API. That’s an almost acceptable solution, as you can have a properly written (sort-of) microservice independent of the original application and other system won’t know they are integrating with a legacy piece of software. It’s tricky to get it right in some cases, however, as you have to understand well the state space of the database. Read-only is easy, writing is much harder or next to impossible.
  7. Paper – no, I’m not making this up. There are cases where one organizations prints some data and then the other organization (or department) receives the paper documents (by mail or otherwise) and inputs them in their system. Expensive projects exist out there that aim to remove the paper component and introduce actual integration, as paper-based input is error-prone and slow. The few legitimate scenarios for a paper-based step is when you need an extra security and the paper trail, combined with the fact that paper is effectively airgapped, may give you that. But even then it shouldn’t be the only transport layer.

If you need to do any of the above, it’s usually because at least one of the system is stuck and can’t be upgraded. It’s either too legacy to touch, or the vendor is gone, or adding an API is “not on their roadmap” and would be too expensive.

If you are building a system, always provide an API. Some other system will have to integrate with it, sooner or later. It’s not sustainable to build close systems and delay the integration question for when it’s needed. Assume it’s always needed.

Fancy ESBs may be able to patch things quickly with one of the approaches above and integrate the “unintegratable”, but heavy reliance on an ESB is an indicator of too many legacy or low-quality systems.

But simply having an API doesn’t cut it either. If you don’t support versioning and backward-compatible APIs, you’ll be in an even more fragile state, as you’ll be breaking existing integrations as you progress.

Enterprise integration is tricky. But, as with many things in software, it’s best handled in the applications that we build. If we build them right, things are much easier. Otherwise, organizations have to revert to the legacy approaches mentioned above and introduce complexity, fragility, security and privacy risks and a general feeling of low-quality that has to be supported by increasingly unhappy people.

The post Seven Legacy Integration Patterns appeared first on Bozho's tech blog.