All posts by Bozho

Near Real-Time Indexing With ElasticSearch

Post Syndicated from Bozho original

Choosing your indexing strategy is hard. The Elasticsearch documentation does have some general recommendations, and there are some tips from other companies, but it also depends on the particular usecase. In the typical scenario you have a database as the source of truth, and you have an index that makes things searchable. And you can have the following strategies:

  • Index as data comes – you insert in the database and index at the same time. It makes sense if there isn’t too much data; otherwise indexing becomes very inefficient.
  • Store in database, index with scheduled job – this is probably the most common approach and is also easy to implement. However, it can have issues if there’s a lot of data to index, as it has to be precisely fetched with (from, to) criteria from the database, and your index lags behind the actual data with the number of seconds (or minutes) between scheduled job runs
  • Push to a message queue and write an indexing consumer – you can run something like RabbitMQ and have multiple consumers that poll data and index it. This is not straightforward to implement because you have to poll multiple items in order to leverage batch indexing, and then only mark them as consumed upon successful batch execution – somewhat transactional behaviour.
  • Queue items in memory and flush them regularly – this may be good and efficient, but you may lose data if a node dies, so you have to have some sort of healthcheck based on the data in the database
  • Hybrid – do a combination of the above; for example if you need to enrich the raw data and update the index at a later stage, you can queue items in memory and then use “store in database, index with scheduled job” to update the index and fill in any missing item. Or you can index as some parts of the data come, and use another strategy for the more active types of data

We have recently decided to implement the “queue in memory” approach (in combination with another one, as we have to do some scheduled post-processing anyway). And the first attempt was to use a class provided by the Elasticsearch client – the BulkProcessor. The logic is clear – accumulate index requests in memory and flush them to Elasticsearch in batches either if a certain limit is reached, or at a fixed time interval. So at most every X seconds and at most at every Y records there will be a batch index request. That achieves near real-time indexing without putting too much stress on Elasticsearch. It also allows multiple bulk indexing requests at the same time, as per Elasticsearch recommendations.

However, we are using the REST API (via Jest) which is not supported by the BulkProcessor. We tried to plug a REST indexing logic instead of the current native one, and although it almost worked, in the process we noticed something worrying – the internalAdd method, which gets invoked every time an index request is added to the bulk, is synchronized. Which means threads will block, waiting for each other to add stuff to the bulk. This sounded suboptimal and risky for production environments, so we went for a separate implementation. It can be seen here – ESBulkProcessor.

It allows for multiple threads to flush to Elasticsearch simultaneously, but only one thread (using a lock) to consume from the queue in order to form the batches. Since this is a fast operation, it’s fine to have it serialized. And not because the concurrent queue can’t handle multiple threads reading from it – it can; but reaching the condition for forming the bulk by multiple threads at the same time will result in several small batches rather than one big one, hence the need for only one consumer at a time. This is not a huge problem so the lock can be removed. But it’s important to note it’s not blocking.

This has been in production for a while now and doesn’t seem to have any issues. I will report any changes if there are such due to increased load or edge cases.

It’s important to reiterate the issue if this is the only indexing logic – your application node may fail and you may end up with missing data in Elasticsearch. We are not in that scenario, and I’m not sure which is the best approach to remedy it – be it to do a partial reindex of recent data in case of a failed server, or a batch process the checks if there aren’t mismatches between the database and the index. Of course, we should also say that you may not always have a database – sometimes Elasticsearch is all you have for data storage, and in that case some sort of queue persistence is needed.

The ultimate goal is to have a near real-time indexing as users will expect to see their data as soon as possible, while at the same time not overwhelming the Elasticsearch cluster.

The topic of “what’s the best way to index data” is huge and I hope I’ve clarified it at least a little bit and that our contribution makes sense for other scenarios as well.

The post Near Real-Time Indexing With ElasticSearch appeared first on Bozho's tech blog.

Забраната на Airbnb – аналогови хора в дигиталния свят

Post Syndicated from Bozho original

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

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

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

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

Само че тия правила са от преди минимум 20 години, като начин ма мислене поне. Табели, тарифи, категории – все неща, които имат за цел да гарантират удобство на клиента, но не са единствения начин за това – Airbnb дава други начини за гарантиране на това удобство.

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

  • интегриране на Airbnb със системите на НАП за автоматично изпращане на данни за получените плащания. Така данъци няма да могат да се укриват. Естония направи така с Uber – „върза“ ги с API на данъчните.
  • олекотяване на режимите за хотелите, къщите за гости и другите места за настаняване. Всичко да може да става онлайн, за да може усилието да си регистрираш апартамента в Airbnb да е съизмеримо с това да си го регистрираш в Министерство на туризма. А ако сме особено амбициозни, Министерство на туризма да даде API (програмен интерфейс), през който Airbnb автоматично да регистрира обявените места за настаняване, с някакви смятани за важни параметри – тоалетни/бани, квадратура, асансьор, пушене, които така или иначе са важните неща за клиента, а не че нещо е 3 или 4 звезди. Ако МТ пусне такъв интерфейс, ще видим, че за няколко месеца и хотелиерските софтуери ще започнат да го ползват и да обявяват местата си там

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

Хората ползват Airbnb не защото искат да бягат от правилата, а защото правилата са неадекватни и начинът на комуникация с институциите е неудобен и тромав. Публикуването на обява в Airbnb е не толкова просто, но удобно и предсказуемо занимание. Ако отворим сайта на Министерство на туризма, виждаме това. Списък с новини в CMS-а на сайта, като всяка препраща към страница със стена от текст и няколко формуляра в doc или pdf, които да разпечатаме и занесем в общината и/или министерството. Еми, не, мерси.

(Знам, че преди време Ангелкова обяви, че всички електронни услуги са достъпни и с eID от един частен доставчик, но за 10 минути търсене не ги открих. Знаейки за една малко известна система – портала за е-форми, все пак ги намерих, но и там са под формата попълване на PDF и изпращането му по електронен път – все пак е нещо, но много далеч от потребителското изживяване на Airbnb)/

Дигиталната трансформация понякога изисква малко мисъл и малко усилия, но аналоговите човечета предпочитат просто да сложат хикса и да кажат „интернет – лош; хора в интернет – лоши“.

A Technical Guide to CCPA

Post Syndicated from Bozho original

CCPA, or the California Consumer Privacy Act, is the upcoming “small GDPR” that is applied for all companies that have users from California (i.e. it has extraterritorial application). It is not as massive as GDPR, but you may want to follow its general recommendations.

A few years ago I wrote a technical GDPR guide. Now I’d like to do the same with CCPA. GDPR is much more prescriptive on the fact that you should protect users’ data, whereas CCPA seems to be mainly concerned with the rights of the users – to be informed, to opt out of having their data sold, and to be forgotten. That focus is mainly because other laws in California and the US have provisions about protecting confidentiality of data and data breaches; in that regard GDPR is a more holistic piece of legislation, whereas CCPA covers mostly the aspect of users’ rights (or “consumers”, which is the term used in CCPA). I’ll use “user” as it’s the term more often use in technical discussions.

I’ll list below some important points from CCPA – this is not an exhaustive list of requirements to a software system, but aims to highlight some important bits. And, obviously, I’m not a lawyer, but I’ve been doing data protection consultations and products (like SentinelDB) for the past several years, so I’m qualified to talk about the technical side of privacy regulations.

  • Right of access – you should be able to export (in a human-readable format, and preferable in machine-readable as well) all the data that you have collected about an individual. Their account details, their orders, their preferences, their posts and comments, etc.
  • Deletion – you should delete any data you hold about the user. Exceptions apply, of course, including data used for prevention of fraud, other legal reasons, needed for debugging, necessary to complete the business requirement, or anything that the user can reasonably expect. From a technical perspective, this means you most likely have to delete what’s in your database, but other places where you have personal data, like logs or analytics, can be skipped (provided you don’t use it to reconstruct user profiles, of course)
  • Notify 3rd party providers that received data from you – when data deletion is requested, you have to somehow send notifications to wherever you’ve sent personal data. This can be a SaaS like Mailchimp, Salesforce or Hubspot, or it can be someone you sold the data (apparently that’s a major thing in CCPA). So ideally you should know where data has been sent and invoke APIs for forgetting it. Fortunately, most of these companies are already compliant with GDPR anyway, so they have these endpoints exposed. You just have to add the logic. If your company sells data by posting dumps to S3 or sending Excel sheets via email, you have a bigger problem as you have to keep track of those activities and send unstructured requests (e.g. emails).
  • Data lineage – this is not spelled out as a requirement, but it follows from multiple articles, including the one for deletion as well as the one for disclosing who data was sent to and where did data came from in your system (in order to know if you can re-sell it, among other things). In order to avoid buying expensive data lineage solutions, you can either have a spreadsheet (in case of simpler processes), or come up with a meaningful way to tag your data. For example, using a separate table with columns (ID, table, sourceType, sourceId, sourceDetails), where ID and table identify a record of personal data in your database, sourceType is the way you have ingested the data (e.g. API call, S3, email) and the ID is the identifier that you can use to track how it came in your system – API key, S3 bucket name, email “from”, or even company registration ID (data might still be sent around flash drives, I guess). Similar table for the outgoing data (with targetType and targetId). It’s a simplified implementation but it might work in cases where a spreadsheet would be too cumbersome to take care of.
  • Age restriction – if you’ve had the opportunity to know the age of a person whose data you have, you should check it. That means not to ignore the age or data of birth field when you import data from 3rd parties, and also to politely ask users about their age. You can’t sell that data, so you need to know which records are automatically opted out. If you never ever sell data, well, it’s still a good idea to keep it (per GDPR)
  • Don’t discriminate if users have used their privacy rights – that’s more of a business requirement, but as technical people we should know that we are not allowed to have logic based on users having used their CCPA (or GDPR) rights. From a data organization perspective, I’d put rights requests in a separate database than the actual data to make it harder to fulfill such requirements. You can’t just do a SQL query to check if someone should get a better price, you should do cross system integration and that might dissuade product owners from breaking the law; furthermore it will be a good sign in case of audits.
  • “Do Not Sell My Personal Information” – this should be on the homepage if you have to comply with CCPA. It’s a bit of a harsh requirement, but it should take users to a form where they can opt out of having their data sold. As mentioned in a previous point, this could be a different system to hold users’ CCPA preferences. It might be easier to just have a set of columns in the users’ table, of course.
  • Identifying users is an important aspect. CCPA speaks about “verifiable requests”. So if someone drops you an email “I want my data deleted”, you should be able to confirm it’s really them. In an online system that can be a button in the user profile (for opting out, for deletion, or for data access) – if they know the password, it’s fairly certain it’s them. However, in some cases, users don’t have accounts in the system. In that case there should be other ways to identify them. SSN sounds like one, and although it’s a terrible things to use for authentication, with the lack of universal digital identity, especially in the US, it’s hard not to use it at least as part of the identifying information. But it can’t be the only thing – it’s not a password, it’s an identifier. So users sharing their SSN (if you have it), their phone or address, passport or driving license might be some data points to collect for identifying them. Note that once you collect that data, you can’t use it for other purposes, even if you are tempted to. CCPA requires also a toll-free phone support, which is hardly applicable to non-US companies even though they have customers in California, but it poses the question of identifying people online based on real-world data rather than account credentials. And please don’t ask users about their passwords over the phone; just initiate a request on their behalf in the system and direct them to login and confirm it. There should be additional guidelines for identifying users as per 1798.185(a)(7).
  • Deidentification and aggregate consumer information – aggregated information, e.g. statistics, is not personal data, unless you are able to extract personal data based on it (e.g. the statistics is split per town and age and you have only two users in a given town, you can easily see who is who). Aggregated data is differentiate from deidentified data, which is data that has its identifiers removed. Simply removing identifiers, though, might again not be sufficient to deidentify data – based on several other data points, like IP address (+ logs), physical address (+ snail mail history), phone (+ phone book), one can be uniquely identified. If you can’t reasonably identify a person based on a set of data, it can be considered deidentified. Do make the mental exercise of thinking how to deidentify your data, as then it’s much easier to share it (or sell it) to third parties. Probably nobody minds being part of an aggregated statistics sold to someone, or an anonymized account used for trend analysis.
  • Pseudonymization is a measure to be taken in many scenarios to protect data. CCPA mentions it particularly in research context, but I’d support a generic pseudonymization functionality. That means replacing the identifying information with a pseudonym, that’s not reversible unless a secret piece of data is used. Think of it (and you can do that quite literally) as encrypting the identifier(s) with a secret key to form the pseudonym. You can then give that data to third parties to work with it (e.g. to do market segmentation) and then give it back to you. You can then decrypt the pseudonyms and fill the obtained market segment(s) into your own database. The 3rd party doesn’t get personal information, but you still get the relevant data
  • Audit trail is not explicitly stated as a requirement, but since you have the obligation to handle users requests and track the use of their data in and outside of your system, it’s a good idea to have a form of audit trail – who did what with which data; who handled a particular user request; how was the user identified in order to perform the request, etc.

As CCPA is not concerned with data confidentiality requirements, I won’t repeat my GDPR advice about using encryption whenever possible (notably, for backups), or about internal security measures for authentication.

CCPA is focused on the rights of your users and you should be able to handle them (and track how you handled them). You can have manual and spreadsheet based processes if you are not too big, and you should definitely check with your legal team if and to what extent CCPA applies to your company. But if you have implemented the GDPR data subject rights, it’s likely that you are already compliant with CCPA in terms of the overall system architecture, except for a few minor details.

The post A Technical Guide to CCPA appeared first on Bozho's tech blog.

Какво пък толкова – 2026 г.

Post Syndicated from Bozho original

Годината е 2026. Текат дискусии по избора на нов главен прокурор. Единственото предложение е Делян Пеевски.

За малка част от обществото темата е важна – правомощията на главния прокурор и структурата на са непроменени от 91г насам, а злоупотребите на предишните главни прокурори са известни на тази малка част от обществото.

Организират се протести. Протестът около ВСС е малък, като в по-слънчевите сутрини се събират около 500-600 души, в т.ч. Йоло Денев. Разбира се, има организиран контрапротест, на който са докарани нищо неподозиращи хора за по 50 лева.

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

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

„Дясното“ поне от известно време е обединено, но все не успява да достигне до масовия избирател и остава със 7-8% на парламентарни избори, което му дава възможността да е заглушен от фоновия шум дразнител.

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

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

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

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

Някой пише меланхолична статия за това колко зле ще са нещата след още седем години.

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

Филчев, Цацаров и Гешев дават по две-три дълги интервюта в национален ефир, в които обясняват за професионалните и етичните качества на Пеевски. В две трети от интервютата атакуват опозицията.

Няколко дни след гласуването във ВСС президентът Борисов подписва указа за назначаване на Пеевски и заявява пред медиите „ами те прокурорите си го избраха, явно има качества. А Христо Иванов като е толкова против, да не я беше предлагал тая реформа“.

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

Обществените поръчки си текат към „наши хора“, посредствеността във властта е константа, ежемесечните скандали в следствие на микс от корупция и некадърност са нормална част от пейзажа. Пеевски е уредил да усвои поръчки покрай АЕЦ Белене и Южен Поток, които някак все още не са истински започнати, но „стратегически важни“ и поглъщат по някой консултантски милион.

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

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

Електронни документи – имат ли почва у нас?

Post Syndicated from Bozho original

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

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

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

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

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

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

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

Restoring Cassandra Priam Backup With sstableloader

Post Syndicated from Bozho original

I’ve previously written about setting up Cassandra and Priam for backup and cluster management. The example that I gave for backup restore there, however, is not applicable in every situation – it may not work on a completely separate cluster, for example. Or in case of partial restore to just one table, rather than the whole database.

In such cases you may choose to do a restore using the sstableloader utility. It has a straightforward syntax:

sudo sstableloader -d, -ts /etc/cassandra/conf/truststore.jks \
   -ks /etc/cassandra/conf/node.jks -f /etc/cassandra/conf/cassandra.yaml  \

If you look at your Priam-generated backup, it looks like you can just copy the files (e.g. via s3 aws cp on AWS) for the particular tables and sstableloader import them. There’s a catch, however. In order to save space, Priam is using Snappy to compress all of the files. So if you try to feed them to any Cassandra utility, it will complain that they are corrupted.

So you have to decompress them before using sstableloader or anything else. But how? Well, Priam offers a service for that – you call it by passing the absolute path to a compressed file and the absolute path to where the uncompressed should be placed and it does the simple job of streaming the original through a decompressor. For decompressing an entire backup, I’ve written a python script. It assumes a certain structure, but you can parameterize it to make it more flexible. Here’s the code (excuse my non-idiomatic Python, I’m only using it for simple scripting):

#! /usr/bin/env python
# python script used to pass each backup file through the decompression facility of Priam (using Snappy)
# so that it can be used with sstableloader for restore
import os
import requests

rootdir = '/home/ec2-user/backup'
target = '/home/ec2-user/keyspace'

for subdir, dirs, files in os.walk(rootdir):
    for file in files:
        fullpath = os.path.join(subdir, file)
        parent = os.path.join(fullpath, os.pardir)
        table = os.path.basename(os.path.abspath(parent))
        targetdir = target + "/" + table + "/"
        if not os.path.exists(targetdir):

        url = 'http://localhost:8080/Priam/REST/v1/cassadmin/decompress?in=' + fullpath + '&out=' + target + "/" + table + "/" + file

Now you have decompressed backup files that you can restore using sstableloader. It may take some time if you have a lot of data, and you should not run the restore at the same time a snapshot backup is performed, as it may fail (was warned by the documentation)

As a general note here, it’s very important to have backups but it’s much more important to be able to restore from them. A backup is useless if you don’t have a restore procedure. And simply having the tools available (e.g. Priam) doesn’t mean you can a restore procedure ready to execute. You should be doing test restores on active staging data as well as full restores on an empty, newly formed cluster, as there are different restore scenarios.

The post Restoring Cassandra Priam Backup With sstableloader appeared first on Bozho's tech blog.

Кратък анализ на местните избори

Post Syndicated from Bozho original

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

1. Безсмислено и неадекватно да се хвърлят обвинения във всички посоки относно местните избори. Никой не печели и никой няма да си промени мнението.

2. Бакалските сметки не работят. Игнатов + Бонев не е по-голямо от Манолова. Ако Бонев беше кандидат на ДБ, много от тези 80% от неговите избиратели, които не са симпатизанти на ДБ (според екзит пола), нямаше да гласуват. Същото щеше да е и ако беше подкрепен независим – медиите щяха да побързат да го асоциират с ДБ и де факто да е наш кандидат с друг номер, а атаките срещу него в по-свинските медии щяха да са като към „кандидата на Сорос“, каквито заявки даде ПИК в началото.

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

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

5. Демократична България постигна добър резултат. Знам, че много хора го определят като пълен провал, но това е най-добрият резултат на демократичната общност за последните 12 години – има най-голяма група в общинския съвет (12 души) и кандидатът за кмет е получил най-висок процент от гласовете. Да, това не е победа, но е важна стъпка в правилната посока. Защото този път в общинския съвет няма да има политическите опортюнисти влезли под флага на поредното дясно обединение, които след няколко месеца ще почнат да гласуват заедно с ГЕРБ. Има хора, които тепърва влизат в политиката с ентусиазъм да правят правилните неща. Казвам го, защото ги познавам. А тази неделя ще видим колко от 10-те балотажа за районни кметове ще бъдат спечелени.

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

Следват парламентарните избори и Демократична България трябва да продължи работата, защото такава има много.

Електронни обществени поръчки – хронология на липсата

Post Syndicated from Bozho original

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

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

Но в следствие на директивата на ЕС за обществените поръчки, би трябвало дс има национална централизирана система за електронни обществени поръчки – електронно обявяване, кандидатстване, отваряне на оферти и т.н.

Да разгледаме, обаче, хронологията на събитията:

2014г: ЕС приема директива за задължителна централизирана платформа за обществени поръчки във всяка държава-членка, срок за транспиниране 19 април 2016. Срокът за въвеждане на е-обществените поръчки е 18 октомври 2018.

2016г. (март) проектът за електронни обществени поръчки е добавен в пътната карта за електронно управление като приоритетен (добавен с мое участие през септември 2015, но приет от МС март 2016). С това на практика се осигурява и финансиране за проекта по Оперативна програма „Добро управление“ (не автоматично, разбира се, но прави проекта финансируем без допълнително одобрение)

2016г: (15 април) Българският парламент приема новия Закон за обществени поръчки, като срокът за електронните обществени поръчки е юни 2017г.

2016г стартира процедурата за система за обществени поръчки, но КЗК я „порязва“

2017г процедурата за електронна система за обществени поръчки стартира наново

2017г: парламентът се сеща, че тая няма да я бъде, и отлага влизането в сила за 18 октовмри 2018, т.е. крайният срок по директива

2018г: парламентът се сеща, че и тая няма да я бъде, и изтрива изцяло члена, като прави нов, в който срокът вече е 1 ноември 2019г.

2019г: системата за електронни обществени поръчки е пусната, но още не е готова и липсват важни функционалности. Например липсват отворени данни, макар да е задължително и по закон, и по задание, и по критерии на оперативната програма, по която е финансиран проектът. (Заб: С колегите в АОП отворихме данните от старата система за няколко часа работа)

2019г, октомври: Менда Стоянова (ГЕРБ) внася между първо и второ четене изменения чрез преходни и заключителни разпоредби в нямащ нищо общо закон (Закона за пазарите и финансовите инструменти), в който въвежда правната иновация – Министерски съвет да определя от кога влиза в сила законът за конкретните институции. На практика казва „когато стане – тогава“.

Всички тия законодателни странности са вероятно за да не е очевидно, че от 1 година сме нарушение на директивата, приета 2014г. За 5 години (а и повече, защото тя се готви по-отдавна) въвеждането на електронни обществени поръчки се оказа невъзможно.

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

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

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

Заключения няма да правя, те са ясни.

Blockchain Overview – Types, Use-Cases, Security and Usability [slides]

Post Syndicated from Bozho original

This week I have a talk on a meetup about blockchain beyond the hype – its actual implementation issues and proper use-cases.

The slides can be found here:

The main takeaways are:

  • Think of blockchain in specifics, not in high-level “magic”
  • Tamper-evident data structures are cool, you should be familiar with them – merkle trees, hash chains, etc. They are useful for other things as well, e.g. certificate transparency
  • Blockchain and its cryptography is perfect for protecting data integrity, which is part of the CIA triad of information security
  • Many proposed use-cases can be solved with centralized solutions + trusted timestamps instead
  • Usability is a major issue when it comes to wider adoption

As with anything in technology – use the right tool for the job, as no solution solves every problem.

The post Blockchain Overview – Types, Use-Cases, Security and Usability [slides] appeared first on Bozho's tech blog.

Защо е важен главният прокурор

Post Syndicated from Bozho original

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

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

Появяват се тук-там странни защитници на Гешев (и Цацаров), според които прокуратурата си работи чу-дес-но, щото, видите ли, били арестували разни съмнителни бизнесмени (наречени малко пресилено „олигарси“). Това, че прокуратурата от време на време обвинява някой престъпник и даже накрая той влиза в затвора, е супер. Все пак – това ѝ е работата.

Причината обаче да се слагат хора като Гешев и Цацаров на тия постове е не това кого са обвинили успешно, а четири други неща:

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

Та, да оставим Минюстайковци, Баневи и подобни. Не за тях става дума тук.

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

На Христо Иванов беше проверяван за обществена поръчка за поддръжка на климатици. До обвинение не се стигна, защото щеше да е прекалено абсурдно. Даниел Митов и Христо Ангеличин бяха обвинени, за неизгодни самолетни билети за нуждите на министерството и за неизгодна сделка с телефонни централи. Обвиненията се разпаднаха в съда, разбира се.

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

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

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

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

The Personal Data Store Pattern

Post Syndicated from Bozho original

With the recent trend towards data protection and privacy, as well as the requirements of data protection regulations like GDPR and CCPA, some organizations are trying to reorganize their personal data so that it has a higher level of protection.

One path that I’ve seen organizations take is to apply the (what I call) “Personal data store” pattern. That is, to extract all personal data from existing systems and store it in a single place, where it’s accessible via APIs (or in some cases directly through the database). The personal data store is well guarded, audited, has proper audit trail and anomaly detection, and offers privacy-preserving features.

It makes sense to focus one’s data protection efforts predominantly in one place rather than scatter it across dozens of systems. Of course it’s far from trivial to migrate so much data from legacy systems to a new module and then upgrade them to still be able to request and use it when needed. That’s why in some cases the pattern is applied only to sensitive data – medical, biometric, credit cards, etc.

For the sake of completeness, there’s something else called “personal data stores” and it means an architecture where the users themselves store their own data in order to be in control. While this is nice in theory, in practice very few users have the capacity to do so, and while I admire the Solid project, for example, I don’t think it is viable pattern for many organizations, as in many cases users don’t directly interact with the company, but the company still processes large amounts of their personal data.

So, the personal data store pattern is an architectural approach to personal data protection. It can be implemented as a “personal data microservice”, with CRUD operations on predefined data entities, an external service can be used (e.g. SentinelDB, a project of mine), or it can just be a centralized database that has some proxy in front of it to control the access patterns. You an imagine it as externalizing your application’s “users” table and its related tables.

It sounds a little bit like a data warehouse for personal data, but the major difference is that it’s used for operational data, rather than (just) analysis and reporting. All (or most) of your other applications/microservices interact constantly with the personal data store whenever they need to access or update (or “forget”) personal data.

Some of the main features of such a personal data store, the combination of which protect against data breaches, in my view, include:

  • Easy to use interface (e.g. RESTful web services or simply SQL) – systems that integrate with the personal data store should be built in a way that a simple DAO layer implementation gets swapped and then data that was previously accessed form a local database is now obtained from the personal data store. This is not always easy, as ORM technologies add a layer of complexity.
  • High level of general security – servers protected with 2FA, access control, segregated networks, restricted physical access, firewalls, intrusion prevention systems, etc. The good things is that it’s easier to apply all the best practices applied to a single system instead of applying it (and keeping it that way) to every system.
  • Encryption – but not just “data at rest” encryption; especially sensitive data can and should be encrypted with well protected and rotated keys. That way the “honest but curious” admin won’t be able to extract anything form the underlying database
  • Audit trail – all infosec and data protection standards and regulations focus on accountability and traceability. There should not be a way to extract or modify personal data without leaving a trace (and ideally, that trace should be protected as well)
  • Anomaly detection – checking if there is something strange/anomalous in the data access patterns. Such strange access patterns can mean a data breach is happening, and the personal data store can actively block it. There is a lot of software out there that does anomaly detection on network traffic, but it’s much better if the rules (or machine learning) are domain-specific. “Monitor for increased traffic to those servers” is one thing, but it’s much better to be able to say “monitor for out-of-the ordinary accesses to personal data of such and such kind”
  • Pseudonymization – many systems that need the personal data don’t actually need to know who it is about. That includes marketing, including outsourcing to 3rd parties, reporting functionalities, etc. So the personal data store can return data that does not allow a person do be identified, but a pseudo-ID instead. That way, when updates are made back to the personal data store, they can still refer to a particular person, via the pseudonymous ID, but the application that extracted the data in the first place doesn’t get to know who the data was about. This is useful in scenarios where data has to be (temporarily or not) stored in a database that lies outside the personal datastore.
  • Authentication – if the company offers user authentication, this can be done via the personal data store. Passwords, two-factor authentication secrets and other means of authentication are personal data, and an important one as well. An organization may use a single-sign-on internally (e.g. Active Directory), but it doesn’t make sense to put customers there, too, so they are usually stored in a database. During authentication, the personal data store accepts all necessary credentials (username, password, 2FA code), and return a token to be used for subsequent calls or to be used a a session cookie token.
  • GDPR (or CCPA or similar) functionalities – e.g. export of all data about a person, forgetting a person. That’s an often overlooked problem, but “give me all data about me that you have” is an enormous issue with large companies that have dozens of systems. It’s next to impossible to extract the data in a sensible way from all the systems. Tracking all these requests is itself a requirement, so the personal data store can keep track of them to present to auditors if needed.

That’s all easier said than done. In organizations that have already many systems working alongside and processing personal data, migration can be costly. So it’s a good idea to introduce it as early as possible, and have a plan (even if it lasts for years) to move at least sensitive personal data to the well protected silo. This silo is a data engineering effort, a system refactoring effort and an organizational effort. The benefits, though, are reduced long-term cost and reduced risks for data breaches and non-compliance.

The post The Personal Data Store Pattern appeared first on Bozho's tech blog.

Без фалшиви дилеми на първи тур

Post Syndicated from Bozho original

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

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

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

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

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

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

Шансовете на един кандидат, разбира се, са фактор при вземането на решения. Ако харесваш някого, но социологията го отчита под 1%, а второто ти предпочитание е с 10%, то по-високият шанс може да надделее над предпочитанията, ако те не са чак толкова силни. Този тип разсъждения са минус на всяка система, в която избирателят трябва да направи точно един избор. Има и алтернативни системи (тази или тази), в които избирателят подрежда кандидатите по реда, в който ги предпочита, което отразява доста по-точно нагласите. Тези системи също не са перфектни и при тях съществуват определени видове тактически гласувания, но така или иначе у нас те не са популярни.

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

Remote Log Collection on Windows

Post Syndicated from Bozho original

Every organization needs to collect logs from multiple sources in order to put them in either a log collector or SIEM (or a dedicated audit trail solution). And there are two options for that – using an agent and agentless.

Using an agent is easy – you install a piece of software on each machine that generates logs and it forwards them wherever needed. This is however not preferred by many organizations as it complicates things – upgrading to new versions, keeping track of dozens of configurations, and potentially impacting performance of the target machines.

So some organizations prefer to collect logs remotely, or use standard tooling, already present on the target machine. For Linux that’s typically syslog, where forwarding is configured. Logs can also be read remotely via SCP/SSH.

However, on Windows things are less straightforward. You need to access the Windows Event Log facility remotely, but there is barely a single place that describes all the required steps. This blogpost comes close, but I’d like to provide the full steps, as there are many, many things that one may miss. It is a best practice to use a non-admin, service account for that and you have to give multiple permissions to allow reading the event logs remotely.

There are also multiple ways to read the logs remotely:

  • Through the Event Viewer UI – it’s the simplest to get right, as only one domain group is required for access
  • Through Win32 native API calls (and DCOM) – i.e. EvtOpenSession and the related methods
  • Through PowerShell Get-WinEvent (Get-EventLog is a legacy cmdlet that doesn’t support remoting)
  • Through WMI directly (e.g. this or this. To be honest, I don’t know whether the native calls and the powershell commands don’t use WMI and/or CIM underneath as well – probably.

So, in order to get these options running, the following configurations have to be done:

  1. Allow the necessary network connections to the target machines (through network rules and firewall rules, if applicable)
  2. Go to Windows Firewall -> Inbound rules and enable the rules regarding “Remote log management”
  3. Create a service account and configure it in the remote collector. The other option is to have an account on the collector machine that is given the proper access, so that you can use the integrated AD authentication
  4. Add the account to the following domain groups: Event log readers, Distributed COM users. The linked article above mentions “Remote management users” as well, but that’s optional if you just want to read the logs
  5. Give the “Manage auditing and security log” privilege to the service account through group policies (GPO) or via “local security policy”. Find it under User Rights Assignment > Manage auditing and security log
  6. Give WMI access – open “wmimgmt” -> right click -> properties > Security -> Advanced and allow the service account to “Execute Methods”, “Provider Write”, “Enable Account”, “Remote Enable”. To be honest, I’m not sure exactly which folder that should be applied to, and applying it to the root may be too wide, so you’d have to experiment
  7. Give registry permissions: Regedit -> Local machine -> System\CurrentControlSet\Services\eventlog\Security -> right click -> permissions and add the service account. According to the linked post you also have to modify a particular registry entry, but that’s not required just for reading the log. This step is probably the most bizarre and unexpected one.
  8. Make sure you have DCOM rights. This comes automatically wit the DCOM group, but double check via DCOMCnfg -> right click -> COM security
  9. Grant permissions for the service account on c:\windows\system32\winevt. This step is not required for “simple” reading of the logs, but I’ve seen it in various places, so in some scenarios you might need to check it
  10. Make sure the application or service that is reading the logs remotely has sufficient permissions – it can usually run with admin privileges, because it’s on a separate, dedicated machine.
  11. Restart services – that is optional, but can be done just in case: Restart “Windows Remote Management (WS-Management)” and “Windows Event Log” on the target machine

As you can see, there are many things that you can miss, and there isn’t a single place in any documentation to list those steps (though there are good guides like this that go in a slightly different direction).

I can’t but make a high-level observation here – the need to do everything above is an example of how security measures can “explode” and become really hard to manage. There are many service, groups, privileges, policies, inbound rules and whatnot, instead of just “Allow remote log reading for this user”. I know it’s inherently complex, but maybe security products should make things simpler by providing recipes for typical scenarios. Following guides in some blog is definitely worse than running a predefined set of commands. And running the “Allow remote access to event log” recipe would do just what you need. Of course, knowing which recipe to run and how to parameterize it would require specific knowledge, but you can’t do security without trained experts.

The post Remote Log Collection on Windows appeared first on Bozho's tech blog.

Административно престъпление

Post Syndicated from Bozho original

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

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

Та какво става, когато нарушиш закона? Зависи от много неща. Но те са разделени в групи:

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

Това, което най-често се случва на средностатистически човек са административни нарушения. Чувал съм твърдения, как ако не си платиш глобата за административно нарушение, в един момент ставаш престъпник – това не е така. Престъпление е само ако укриваш данъци в големи размери. Държавата има други начини да си събира задълженията – запори, възбрани, чрез държавни съдебни изпълнители. Обратното обаче е възможно – съдът да освободи някого от наказателна отговорност и да наложи административна санкция (чл. 78а от НК).

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

ОтговорностКъде са описани нарушенията?Къде е описан редът за налагане?Кой инициира процеса?Изпълнение без участие на съд?
НаказателнаНаказателен кодексНаказателно-процесуален кодексПрокуратурата или частен тъжителНе
АдминистративнонаказателнаГлава „Административнонаказателни разпоредби“ (или подобна) във всеки законЗакон за административните нарушения и наказанияНаказващият административен орган, определен със законаДа
Гражданска и имущественаГраждански процесуален кодексВсяко физическо или юридическо лицеНе
ДисциплинарнаКодекс на труда, Закон за държавния служител, трудови договориКодекс на труда, Закон за държавния служителРаботодателДа

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

Надявам се съм направил разбираема и коректна систематизация.

Cybersecurity Is Very Important

Post Syndicated from Bozho original

A few months ago an essay titled “Cybersecurity is not very important” appeared. The essay is well written and interesting but I’d like to argue against its main point.

And that is actually hard – the essay has many good points, and although it has a contrarian feel, it actually isn’t saying anything outrageous. But I still don’t agree with the conclusion. I suggest reading it (or skimming it) first before continuing here, although this article is generally self-sufficient.

I agree with many things in the essay, most importantly that there is no 100% protection and it’s all about minimizing the risk. I also agree that cybersecurity is a complex set of measures that span not only the digital world, but he physical one as well. And I agree that even though after watching a few videos from DEF CON, BlackHat or CCC, one feels that everything is fundamentally broken and going to live in the mountains is the only sane strategy to survive an impending digital apocalypse, this is not the case – we have a somewhat okayish level of protection for the more important parts of the digital world. Certainly exploitable, but not trivially so.

There are, though, a few main claims that I’d like to address:

  • There has not been any catastrophic cybersecurity event – the author claims that the fact that there was no digital Pearl Harbor or 9/11 suggests that we’ve been investing just the right amount of effort in cybersecurity. I don’t think that’s a fair comparison. Catastrophic events like that cost human lives as an immediate result of a physical action. No digital event can cause immediate loss of human life. However, it can cause indirect loss of human life, and it probably has already – take a famous data breach in an extramarital affair dating site – do we know how much people were killed in Pakistan or Saudi Arabia because infidelity (or homosexuality) was exposed? How many people died because hospitals were victims of ransomware? How many people died when the Ukranian power grid was attacked, leaving 20% of of Kyiv without power and therefore without heat, light or emergency care? What about the (luckily unsuccessful) attempt to sabotage a Saudi Arabia petro-chemical plant and cause an explosion? There are many more of these events, and they are already a reality. There are no visible explosions yet, which would make it easier to compare them to Pearl Harbor or 9/11, but they are serious and deadly nonetheless. And while natural disasters, road incidents and other issues claim more victims, there isn’t a trivial way to calculate the “return of life on investment”. And isn’t a secure charity for improving hurricane protection in third world nations better than one that gets hacked and all of its funds get stolen?
  • People have not adopted easy security measures because they were minor inconveniences – for example 2-factor authentication has been around for ages, but only recently we began using it. That is true, of course, but the reason for that might not be that it has been mostly fine to not have 2FA so far, but that society hasn’t yet realized the risks. Humans are very bad at intuitively judging risk, especially when they don’t have enough information. Now that we have more information, we are slightly better at estimating that, yes, adding a second factor is important for some systems. Security measures get adopted when we realize the risk, not only when there is more of it. Another reason people have not adopted cybersecurity measures is that they don’t know about them. Because the area is relatively recent, expertise is rare. This discrepancy between the ubiquity of information technology and the lacks of technical expertise (not to mention security expertise) has been an issue for a long time.
  • The digital world plays too small a role in our world when we put things in perspective – humans play a small role in the world if you put them in a big enough perspective, that doesn’t mean we are not important. And the digital world is playing an increasingly important role in our world – we can’t that easily continue to claim that cybersecurity is not important. And overall, the claim that so far everything has been (almost) smooth sailing can’t be transformed into the argument that it is going to be the same, only with gradual improvement over time. If IT is playing an exponentially more important role (and it is), then our focus on information security can’t grow linearly. I know you can’t plot these things on a graph without looking stupid, but you get the gist.
  • We have managed to muddle through without too much focus on cybersecurity – yes, we have. But we will find it increasingly harder to do so. Also, we have successfully muddled through many eras of human history because we have done things wrong (For example the Maya civilization collapsed partly because they handled the the environment wrong). Generally, the fact that something hasn’t gone terribly wrong is a bad argument that we are doing fine. Systemic issues get even more entrenched while on the surface it may look like we are successfully muddling through. I’m not saying that is certainly the case for cybersecurity, but it might very well be.

While arguing with the author’s point is an interesting task, it doesn’t directly prove the point that cybersecurity is indeed important.

First, we don’t have good comparisons of estimates of the cost – to the economy and to human life – of investment in cybersecurity as opposed to other areas, so I don’t think we can claim cybersecurity is not important. There are, for example, estimates of the cost of a data breach, and it averages several million dollars. If you directly and indirectly lose several million dollars with a likelihood of 30% (according to multiple reports), I guess you should invest a few hundred thousands.

Second, it is harder to internalize the risk of incidents in the digital world compared to those in the physical world. While generally bad at evaluating risk, I think the indirection that the digital world brings, contributes negatively to our ability to make risk-based decisions. The complexity of the software complicates things even further – even technical people can’t always imagine the whole complexity of the systems they are working with. So we may not feel cybersecurity is important even though facts and figures show otherwise.

But for me the most important reason for the importance of cybersecurity is that we are currently laying a shaky foundation for our future world. Legacy software, legacy protocols and legacy standards are extremely hard to get rid of once they are ubiquitous. And if they are insecure by design, because they are not built with security in mind, there is no way that software that relies on them can be secure.

If we don’t get cybersecurity right soon, everything that relies on the foundations that we build today will be broken. And no, you can’t simply replace your current set of systems with new, more secure ones. Organizations are stuck with old systems not because they don’t want to get new and better ones, but because it’s hard to do that – it involves migration, user training, making sure all edge cases are covered, informing customers, etc. Protocols and standards are even hard to change – see how long it took for TLS 1.3 to come along, for example. But network standards still have vulnerabilities that don’t have good mitigation (or didn’t have until recently) – take an SS7 attack on a mobile network, or ARP spoofing, or BGP hijacking.

If we don’t agree that cybersecurity is very important, future technology will be based on an insecure layer that it will try to fix with clumsy abstractions. And then at some point everything may collapse, at a moment when we are so dependent on it, that the collapse will be a major disruption in he way humanity operates. That may sound futuristic, but with technology you have no option but to be futuristic. We must build systems today that will withstand the test of time. And this is already very hard – maybe because we didn’t think cybersecurity is important enough.

I’m not saying we should pour millions into cybersecurity starting tomorrow. But I’d be happy to see a security mindset in everyone that works with technology as well as in everyone that takes decisions that involve technology. Not paranoid, but security conscious. Not “100% secure or bust”, but taking all known protection measures.

Cybersecurity is important. And it will be even more important in he upcoming decades.

The post Cybersecurity Is Very Important appeared first on Bozho's tech blog.

Киберсигурна работа

Post Syndicated from Bozho original

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

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

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

Както стана ясно от теча в НАП, а и от редица пробиви напоследък, нивото на киберсигурност е ниско. (Някои пробиви не стават публично достояние, но можем да питаме govcert-а, звеното за реакция при киберинциденти, колко сигнала за уязвимости е приел). За да имаме пълна картина колко зле са нещата, трябва да един пълен одит на сигурността на всички системи. Но той най-вероятно ще ни каже това, което вече знаем – че нивото е ниско.

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

  • Системите са уязвими по две причини. Първата е, че по принцип е трудно да се поддържат сигурни системи. Дори да е била сигурна в един момент, нещата се променят, оттриват се неизвестни досега уязвимости на компоненти, от които зависи самата система. Затова проактивно обновяване, следене за уязвимости и комбинация от много други мерки са начинът да има по-сигурни системи, но дори това невинаги е достатъчно. Втората причина е, че системите в държавата с много ниско качество (в общия случай). Пишат ги фирми с не особено кадърни хора (защото и малкото кадърни по темата са отишли на по-високи заплати другаде, където не се разчита на обществени поръчки), приемат ги хора, които нямат идея какво приемат, и няма кой да следи този процес да бъде по-адекватен. Дори да има наредби, шаблони и хипотетични санкции, просто няма хора. Наскоро имаше система, разработвана по шаблона за задание. Дори като никога беше спазен закона и кодът беше отворен. И какво имаше там – SQL инжекция. Поправена след съответния сигнал (нагледен пример за ползите кодът да е отворен), но най-базовата грешка при работа с база данни, за която изрично има предупреждение в заданието, беше допусната. В 13 от последните 15 години тези наредби и шаблони ги е нямало, а системите, които се ползват, са на толкова.
  • Кой може да злоупотреби с това – всеки. Причините са няколко. Комерсиални – напр. е полезно за една компания да има данните от Национална база данни „Население“; геополитически – някои държави не одобряват определени решения, които нашата е взела или предстои да вземе, и съответно включват киберарсенала си; „някои хора просто искат да гледат как света гори“ – хакване заради самото хакване и заради деструктивния ефект. Първите могат да разчитат не на експлоатиране на уязвимости, а на корумпирани вътрешни хора, чрез които да източат данните – това също е част от киберсигурността, която включва както външни, така и вътрешни „атаки“.
  • Може да се направи много – да се прилага по-стриктно нормативната уредба, да се използват различни механизми за привличане на по-компетентни хора (вкл. с по-високо заплащане), да се обучават по-активно хората в публичния сектор, да се затегнат вътрешните механизми за контрол на достъпа на служители. Имаше предложения за по-големи наказания в Наказателния кодекс, но според мен това няма да работи – хакерите или не познават НК и той не ги спира, или си мислят, че си прикриват следите достатъчно добре, че да са неоткриваеми. Или и двете.

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

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

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

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

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

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

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

Може ли България да е киберсигурна и дългосрочно киберустойчива? Може, разбира се – задачата е решима. Но не изглежда реалистично в близко бъдеще, защото дори да започнем веднага, при мащаба на публичния сектор и натрупаните системни проблеми, резултати може да има едва след 3-4 години. А дотогава – двайсетгодишни хакери, руски агенти или просто хора, които „имат човек“ някъде, могат да правят (почти) каквото си искат.

Protecting JavaScript Files (From Magecart-Style Attacks)

Post Syndicated from Bozho original

Most web pages now consist of multiple JavaScript files that are included in various ways (via >script< or in some more dynamic fashion, bundled and minified or not). But since these scripts interact with everything on the page, they can be a security risk.

And Magecart showcased that risk – the group attacked multiple websites, including British Airways and Ticketmaster, and stole a few hundred thousand credit card numbers.

It is a simple attack where attacker inserts a malicious javascript snippet into a trusted javascript file, collects credit card details entered into payment forms and sends them to an attacker-owned website. Obviously, the easy part is writing the malicious javascript; the hard part is getting it on the target website.

Many websites rely on externally hosted assets (including scripts) – be it a CDN, or a dedicated asset server (as in the case of British Airways). These externally hosted assets may be vulnerable in several ways:

  • Asset servers may be less protected than the actual server, because they are just static assets, what could go wrong?
  • Credentials to access CDN configuration may be leaked which can lead to an attacker replacing the original source scripts with their own
  • Man-in-the-middle attacks are possible if the asset server is misconfigured (e.g. allowing TLS downgrade attack)
  • The external service (e.g. CND) that was previously trusted can go rogue – that’s unlikely with big providers, but smaller and cheaper ones are less predictable

Once the attackers have replaced the script, they are silently collecting data until they are caught. And this can be a long time.

So how to protect against those attacks? A typical advice is to introduce a content security policy, which will allow scripts from untrusted domains to be executed. This is a good idea, but doesn’t help in the scenario where a trusted domain is compromised. There are several main approaches, and I’ll summarize them below:

  • Subresource integrity – this is a browser feature that lets you specify the hash of a script file and validates that hash when the page loads. If it doesn’t match the hash of the actually loaded script, the script is blocked. This sounds great, but has several practical implications. First, it means you need to complicate your build pipeline so that it calculates the hashes of minified and bundled resources and inject those hashes in the page templates. It’s a tedious process, but it’s doable. Then there are the dynamically loaded scripts where you can’t use this feature, and there are the browsers that don’t support it fully (Edge, IE and Safari on mobile). And finally, if you don’t have a good build pipeline (which many small websites don’t), a very small legitimate change in the script can break your entire website.
  • Don’t use external services – that sounds straightforward but it isn’t always. CDNs exist for a reason and optimize your site loading speeds and therefore ranking, internal policies may require using a dedicated asset server, sometimes plugins (e.g. for WordPress) may fetch external resources. An exception to this rule is allowed if you somehow sandbox the third party script (e.g. via iframe as explained in the link above)
  • Secure all external servers properly – if you can do that, that’s great – upgrade the supported cipher suites, monitor for 0days, use only highly trusted CDNs. Regardless of anything, you should obviously always strive to do that. But it requires expertise and resources, which may not be available to every company and every team.

There is one more scenario that may sound strange – if an attacker hacks into your main application server(s), they can replace the scripts with whatever they want. It sounds strange at first, because if they have access to the server, it’s game over anyway. But it’s not always full access with RCE – might be a limited access. Credit card numbers are usually not stored in plain text in the database, so having access to the application server may not mean you have access to the credit card numbers. And changing the custom backend code to collect the data is much more unpredictable and time-consuming than just replacing the scripts with malicious ones. None of the options above protect against that (as in this case the attacker may be able to change the expected hash for the subresource integrity check)

Because of the limitations of the above approaches, at my company we decided to provide a tool to monitor your website for such attacks. It’s called (short for Script Sentinel) and is currently in early beta. It’s mainly targeted at small website owners who can’t get any of the above 3 points, but can be used for sophisticated websites as well.

What it does is straightforward – it scans a given URL, extracts all scripts from it (even the dynamic ones), and starts monitoring them for changes with periodic requests. If it discovers a change, it notifies the website owner so that they can react.

This means that the attacker may have a few minutes to collect data, but time is an important factor here – this is not a “SELECT *” data breach; it relies on customers using the website. So a few minutes minimizes the damage. And it doesn’t break your website (I guess we can have a script to include that blocks the page if scriptinel has found discrepancies). It also doesn’t require changes in the build process to include hashes. Of course, such a reactive approach is not perfect, especially if there is nobody to react, but monitoring is a good idea regardless of whether other approaches are used.

There is the issue of protected pages and pages that are not directly accessible via a GET request – e.g. a payment page. For that you can enter your javascript files individually, rather than having the tool scan the page. We can add a more sophisticated user journey scan, with specifying credentials and steps to reach the protected pages, but for now that seems unnecessary.

How does it solve the “main server compromised” problem? Well, nothing solves that perfectly, as the attacker can do changes that serve the legitimate version of the script to your monitoring servers (identifying them by IP) and the modified scripts to everyone else. This can be done on the compromised external asset servers as well (though not with leaked CDN credentials). However this implies the attacker knows that Scriptinel is used, knows the IP addresses of our scanners, and has gained sufficient control to server different versions based on IP. This raises the bar significantly, and can even be made impossible to pull off if we regularly change the IP addresses in a significantly large IP range.

Such functionality may be available in some enterprise security suites, though I’m not aware of it (if it exists somewhere, please let me know).

Overall, the problem is niche, but tough, and not solving it can lead to serious data breaches even if your database is perfectly protected. Scriptinel is a simple to use, good enough solution (and one that’s arguably better than the other options).

Good information security is the right combination of knowledge, implementation of best practices and tools to help you with that. And I maybe Scriptinel is one such tool.

The post Protecting JavaScript Files (From Magecart-Style Attacks) appeared first on Bozho's tech blog.

Let’s Annotate Our Methods With The Features They Implement

Post Syndicated from Bozho original

Writing software consists of very little actual “writing”, and much more thinking, designing, reading, “digging”, analyzing, debugging, refactoring, aligning and meeting others.

The reading and digging part is where you try to understand what has been implemented before, why it has been implemented, and how it works. In larger projects it becomes increasingly hard to find what is happening and why – there are so many classes that interfere, and so many methods participate in implementing a particular feature.

That’s probably because there is a mismatch between the programming units (classes, methods) and the business logic units (features). Product owners want a “password reset” feature, and they don’t care if it’s done using framework configuration, custom code split in three classes, or one monolithic controller method that does that job.

This mismatch is partially addressed by the so called BDD (behaviour driven development), as business people can define scenarios in a formalized language (although they rarely do, it’s still up to the QAs or developers to write the tests). But having your tests organized around features and behaviours doesn’t mean the code is, and BDD doesn’t help in making your way through the codebase in search of why and how something is implemented.

Another issue is linking a piece of code to the issue tracking system. Source control conventions and hooks allow for setting the issue tracker number as part of the commit, and then when browsing the code, you can annotate the file and see the issue number. However, due the the many changes, even a very strict team will end up methods that are related to multiple issues and you can’t easily tell which is the proper one.

Yet another issue with the lack of a “feature” unit in programming languages is that you can’t trivially reuse existing projects to start a new one. We’ve all been there – you have a similar project and you want to get a skeleton to get thing running faster. And while there are many tools to help that (Spring Boot, Spring Roo, and other scaffolding utilities), they can rarely deliver what you need – you always have to tweak something, delete something, customize some configuration, as defaults are almost never practical.

And I have a simple proposal that will help with the issues above. As with any complex problem, simple ideas don’t solve everything, but are at least a step forward.

The proposal is in the title – let’s annotate our methods with the features they implement. Let’s have @Feature(name = "Forgotten password", issueTrackerCode="PROJ-123"). A method can implement multiple features, but that is generally discouraged by best practices (e.g. the single responsibility principle). The granularity of “feature” is something that has to be determined by each team and is the tricky part – sometimes an epic describes a feature, sometimes individual stories or even subtasks do. A definition of a feature should be agreed upon and every new team member should be told what to do and how to interpret it.

There is of course a lot of complexity, e.g. for generic methods like DAO methods, utility methods, or methods that are reused in too many places. But they also represent features, it’s just that these features are horizontal. “Data access layer” is a feature – a more technical one indeed, but it counts, and maybe deserves a story in the issue tracker.

Your features can actually be listed in one or several enums, grouped by type – business, horizontal, performance, etc. That way you can even compose features – e.g. account creation contains the logic itself, database access, a security layer.

How does such a proposal help?

  • Consciousnesses about the single responsibility of methods and that code should be readable
  • Provides a rationale for the existence of each method. Even if a proper comment is missing, the annotation will put a method (or a class) in context
  • Helps navigating code and fixing issues (if you can see all places where a feature is implemented, you are more likely to spot an issue)
  • Allows tools to analyze your features – amount, complexity, how chaotic a feature is spread across the code base, test coverage per feature, etc.
  • Allows tools to use existing projects for scaffolding for new ones – you specify the features you want to have, and they are automatically copied

At this point I’m supposed to give a link to a GitHub project for a feature annotation library. But it doesn’t make sense to have a single-annotation project. It can easily be part of guava or something similar Or can be manually created in each project. The complex part – the tools that will do the scanning and analysis, deserve separate projects, but unfortunately I don’t have time to write one.

But even without the tools, the concept of annotating methods with their high-level features is I think a useful one. Instead of trying to deduce why is this method here and what requirements does it have to implement (and were all necessary tests written at the time), such an annotation can come handy.

The post Let’s Annotate Our Methods With The Features They Implement appeared first on Bozho's tech blog.

Либра – новата криптовалута на Фейсбук

Post Syndicated from Bozho original

Фейсбук обяви, че през 2020 ще пусне своя криптовалута. Само по себе си пускането на криптовалута е тривиално, но когато го направи компания с милиардна пазарна капитализация, и то подкрепена от още десетина такива, заявката става сериозна.

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

Пред това, обаче, има няколко предизвикателства и не е ясно дали Фейсбук ще може да ги преодолее:

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

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

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

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

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

На трето място са оперативните проблеми, които често са камъчетата, преобръщащи каруцата. За да получи някакво количество Либра „монети“, потребителят трябва да обмени пари в съществуваща валута. Това при криптовалутите става чрез борси, които приемат плащания с банкови преводи и кредитни карти. Но заявеният първоначален пазар на Либра е третия свят, където много хора нямат достъп до банкови услуги. Много анализатори очакват Фейсбук да сключи договори с местни мобилни оператори и зареждането на Либра сметката да става през гише на мобилен оператор, или дори с предплатена карта. Дали този модел ще проработи навсякъде и дали мобилните оператор няма да реализират конкурентна услуга за електронни пари, предстои да разберем.

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

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

(Статията е публикувана първоначално в сп. Мениджър)

Обобщение на теча на данни в НАП

Post Syndicated from Bozho original

Много се изговори и изписа по повод „НАПЛийкс“. Аз успях да се включа в какафонията с няколко телефонни интервюта и едно телевизионно. Но в такъв формат, дори да е по-дълго, не може да се изложи всичко в структуриран и систематизиран вид. Затова ще опитам тук.


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

По информация на хора, които са разгледали данните, вътре има ЕГН-та, три имена и осигурителни доходи на милиони граждани, номера на лични карти, както и данъчни декларации, граждански договори, а също и данни от други инстутуции – Агенция по заетостта, Агенция Митници, Агенция за социално подпомагане. Има данни за чуждестранни юридически лица, и любопитни данни, като напр. файл, озаглавен QneQnev.

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

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


Няма официална информация как е станал пробивът, но на няколко места излезе слух, че е т.нар. SQL инжекция. Това звучи правдоподобно, така че ще коментирам него. SQL инжекциите са сред най-простите уязвимости – хакерът вкарва специално подготвен текст в дадена поле и получава контрол над базата данни, защото разработчикът не е „почистил“ входните данни (и не използва т.нар. prepared statements). Ако например искаме да използваме формата за вход в системата, то можем да допуснем, че проверката на потребителското име и паролата би изглеждало така: SELECT * FROM users WHERE username={params.username} AND password={transform(params.password)}. (transform, защото паролите никога не трябва да се пазят в явен вид).

Това е псевдо-код, с който виждаме, че параметрите, подадени от потребителя се „залепят“ за заявка, която се изпълнява към базата. Е, ако хакерът вместо потребителско име попълни друга валидна заявка в полето, тя ще се изпълни. Напр. след въвеждане, заявката би изглеждала така: SELECT * FROM users WHERE username=1;CREATE PROCEDURE exfiltrate …;–AND password=…. Създадената процедура може да бъде с произволен код, който да обхожда всички бази данни и техните таблици и да ги изпраща към определен IP адрес.

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


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

Длъжностите в администрацията са разписани в т.нар. Класификатор на длъжностите в администрацията. До 2016-та там нямаше ИТ длъжности (ИТ кадри бяха наемани на общи експертни позиции). Тогава предложихме изменение на класификатора, така че да включим ИТ длъжности и то на максималните възможни нива на заплащане за съответния опит. Това, разбира се, пак е много под пазарните заплати, но е някаква стъпка.

Паралелно това, с измененията в Закона за електронното управление направихме две неща. По-маловажното беше, че създадохме опция Държавна агенция „Електронно управление“ да създаде програма за привличане на експерти от частния сектор, които краткосрочно да помагат за ИТ услугите на държавата. Нещо, което и аз правех тогава, но в мащаб. Нещо подобно на американските 18F/USDS. Това, излишно е да казвам, не се случва вече 3-та година.

По-важното беше създаването със закон на Държавно предприятие „Единен системен оператор“. Идеята му е да може да дава пазарни ИТ заплати, като предоставя определени услуги на държавната администрация – технически задания, проектен контрол, тестове, в т.ч. за уязвимости, управление на поддръжката на инфраструктурата, консултиране на ключови проекти, спешни мерки по „закърпване“ на проблеми, и др. Това предприятие също 3-та година е блокирано и не се случва. Изпълнителната власт и Горанов в т.ч. като че ли осъзнаха нуждата от нещо такова след срива на Търговския регистър миналата година, но явно просветлението е било краткотрайно. И това не сме си го измислили ние – BRZ (Австрия) и GDS (Великобритания) са едни от примерите за подобни структури в Европа.

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

Информационна сигурност

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

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

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


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

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

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

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


Какви мерки могат да се вземат на този етап. Краткосрочните: спиране на уязвимата услуга (вече направено), пълен одит на сигурността на всички системи не само в системата на Министерство на финансите, ами в цялата държава. Проверка дали всички информационни системи са включени в одита на Държавна агенция „Електронно управление“ и последователната им автоматизирана проверка за уязвимости.

Средносрочните са провеждане на обучения на всички служител в ИТ дирекциите за информационна сигурност и защита на данните и запознаване с приложимата нормативна уредба, ама не само като членове и алинеи, а и какво стои зад нея. Евентуално сертифициране на всички първостепенни и второстепенни разпоредители по ISO 27001 (стандарт за информационна сигурност).

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

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


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

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

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


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

Дали заловеният наистiна е извършител ще реши съдът. ГДБОП трябва да събере доказателства и от тях да следва еднозначно, че той е извършителят. Дали намереният файл, в който се съдържа името му е истински или не – не можем да кажем. Има много варианти, в които е истински. И такива, в които не е.

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

Дали хакерът е „магьосник“, обаче, е сравнително ясно – не е. Злоупотреба с SQL инжекция може да направи почти всеки. Ако е оставил да бъде открит, значи не си е покрил добре следите.

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


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

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

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

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