All posts by Bozho

Audit Trail Overview

Post Syndicated from Bozho original

As part of my current project (secure audit trail) I decided to make a survey about the use of audit trail “in the wild”.

I haven’t written in details about this project of mine (unlike with some other projects). Mostly because it’s commercial and I don’t want to use my blog as a direct promotion channel (though I am doing that at the moment, ironically). But the aim of this post is to shed some light on how audit trail is used.

The survey can be found here. The questions are basically: does your current project have audit trail functionality, and if yes, is it protected from tampering. If not – do you think you should have such functionality.

The results are interesting (although with only around 50 respondents)

So more than half of the systems (on which respondents are working) don’t have audit trail. While audit trail is recommended by information security and related standards, it may not find place in the “busy schedule” of a software project, even though it’s fairly easy to provide a trivial implementation (e.g. I’ve written how to quickly setup one with Hibernate and Spring)

A trivial implementation might do in many cases but if the audit log is critical (e.g. access to sensitive data, performing financial operations etc.), then relying on a trivial implementation might not be enough. In other words – if the sysadmin can access the database and delete or modify the audit trail, then it doesn’t serve much purpose. Hence the next question – how is the audit trail protected from tampering:

And apparently, from the less than 50% of projects with audit trail, around 50% don’t have technical guarantees that the audit trail can’t be tampered with. My guess is it’s more, because people have different understanding of what technical measures are sufficient. E.g. someone may think that digitally signing your log files (or log records) is sufficient, but in fact it isn’t, as whole files (or records) can be deleted (or fully replaced) without a way to detect that. Timestamping can help (and a good audit trail solution should have that), but it doesn’t guarantee the order of events or prevent a malicious actor from deleting or inserting fake ones. And if timestamping is done on a log file level, then any not-yet-timestamped log file is vulnerable to manipulation.

I’ve written about event logs before and their two flavours – event sourcing and audit trail. An event log can effectively be considered audit trail, but you’d need additional security to avoid the problems mentioned above.

So, let’s see what would various levels of security and usefulness of audit logs look like. There are many papers on the topic (e.g. this and this), and they often go into the intricate details of how logging should be implemented. I’ll try to give an overview of the approaches:

  • Regular logs – rely on regular INFO log statements in the production logs to look for hints of what has happened. This may be okay, but is harder to look for evidence (as there is non-auditable data in those log files as well), and it’s not very secure – usually logs are collected (e.g. with graylog) and whoever has access to the log collector’s database (or search engine in the case of Graylog), can manipulate the data and not be caught
  • Designated audit trail – whether it’s stored in the database or in logs files. It has the proper business-event level granularity, but again doesn’t prevent or detect tampering. With lower risk systems that may is perfectly okay.
  • Timestamped logs – whether it’s log files or (harder to implement) database records. Timestamping is good, but if it’s not an external service, a malicious actor can get access to the local timestamping service and issue fake timestamps to either re-timestamp tampered files. Even if the timestamping is not compromised, whole entries can be deleted. The fact that they are missing can sometimes be deduced based on other factors (e.g. hour of rotation), but regularly verifying that is extra effort and may not always be feasible.
  • Hash chaining – each entry (or sequence of log files) could be chained (just as blockchain transactions) – the next one having the hash of the previous one. This is a good solution (whether it’s local, external or 3rd party), but it has the risk of someone modifying or deleting a record, getting your entire chain and re-hashing it. All the checks will pass, but the data will not be correct
  • Hash chaining with anchoring – the head of the chain (the hash of the last entry/block) could be “anchored” to an external service that is outside the capabilities of a malicious actor. Ideally, a public blockchain, alternatively – paper, a public service (twitter), email, etc. That way a malicious actor can’t just rehash the whole chain, because any check against the external service would fail.
  • WORM storage (write once, ready many). You could send your audit logs almost directly to WORM storage, where it’s impossible to replace data. However, that is not ideal, as WORM storage can be slow and expensive. For example AWS Glacier has rather big retrieval times and searching through recent data makes it impractical. It’s actually cheaper than S3, for example, and you can have expiration policies. But having to support your own WORM storage is expensive. It is a good idea to eventually send the logs to WORM storage, but “fresh” audit trail should probably not be “archived” so that it’s searchable and some actionable insight can be gained from it.
  • All-in-one – applying all of the above “just in case” may be unnecessary for every project out there, but that’s what I decided to do at LogSentinel. Business-event granularity with timestamping, hash chaining, anchoring, and eventually putting to WORM storage – I think that provides both security guarantees and flexibility.

I hope the overview is useful and the results from the survey shed some light on how this aspect of information security is underestimated.

The post Audit Trail Overview appeared first on Bozho's tech blog.

Всички са маскари?

Post Syndicated from Bozho original

Вчера се обяви политическото обединение Демократична България – с Да, България, ДСБ и Зелените. И като част от екипа, обявен като алтернатива на управлението, ще си позволя да напиша първия ми фокусирано партиен блогпост от изборите миналата година досега.

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

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

У доста хора има осезаем негативизъм към това обединение. Всеки със своята причина, с която не мога да споря. но този негативизъм кулминира в крайно множество твърдения за обединението и за партиите в него, които твърдения мога да опитам да оспоря. И целта не е да кажа „аха! не сте прави да не ни харесвате“ (защото това е субективно и всеки има право да не харесва каквото си иска), а по-скоро да допълня картината, която всеки има за политическия пейзаж. Ще разгледам 10 твърдения/коментара, които са преобладаващи. И не за да влизам в „обяснителен режим“, а за да вляза в своеобразен диалог с по-скептичните.

Обединяватe се само за да минете 4-процентовата бариера

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

Има и друг аспект – откакто се учреди Да, България имаме един „стъклен таван“, изразяващ се в „абе, харесваме ви, ама ще влезете ли?“ (чувал съм го на няколко срещи с потенциални избиратели). Та, надяваме се с това обединение да счупим този стъклен таван, т.е. тези, които биха ни подкрепили, да го направят. Социолозите да кажат.

Късно е либе за китка / защо чак сега

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

Оставете жълтите павета и ходете из страната

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

Леви сте, не сте десни!

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

Ама Зелените са леви!

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

Поредното механично обединение без смисъл

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

Сорос, Америка за България и Прокопиев ви финансират!

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

Защо не говорите за (проблем Х, който за мен е важен)

Говорим по много проблеми, имаме много позиции. Но най-вероятно това не стига до вас, отчасти заради наши грешки, отчасти защото извън няколко онлайн издания, отразяването ни по медиите е силно ограничено (канят всякакви алкохолици в националните медии, но отменят участие на Христо Иванов, например). Ясно е, че това е средата, в която работим и трябва да се съобразяваме с нея. Което включва фокусиране в няколко по-ключови теми, а не разпиляването в много теми, така че много хора да припознаят своя проблем.

Само говорите, а нищо не правите

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

Със стари к*рви, нов бардак!

Кой е стара к*рва бе?? 🙂 А сериозно – в лицата, обявени днес има някои познати (с по един-два мандата в парламента, например), и доста непознати на широката публика. Така че това е по-скоро клише по инерция, отколкото базирано на някакви обективни факти. Естествено, че трябва да има хора с опит и естествено, че има много нови лица.

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

А иначе, всички са маскари, то е ясно.

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

Post Syndicated from Bozho original

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

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

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

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

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

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

Де факто всичко правя онлайн. Тогава какво се оплакваме, че няма електронно управление?

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

Да, декларирам си данъците, ама да се оправиш с данъчната декларация на НАП е близо до ракетна наука. Като си платих осигуровките, на следващия ден се генерираха стотинки лихва, дето пак трябваше да ги платя и пак да се генерират. Удостоверението за липса на задължение го заявих електронно, но го получих в най-близкия офис на НАП, а не в този по постоянен адрес, и то само защото проведох 10 минутен разговор със служителка, която накрая капитулира и призна, че са в нарушение на закона и предложи да ми го прати до близък до мен офис. Постоянния си адрес успях да го сменя само защото знам за конкретен бъг в електронните услуги на Столична община и мога да го заобиколя. Личната си карта получих, но не пишеше къде трябва да отида да я получа, а като отидох най-накрая на правилното място, опрях до фразата „не ви трябва да ви давам удостоверение, системата го е проверила автоматично, аз съм я внедрявал и съм писал закона“. Декларацията ми по ЗПУКИ мина през една итерация с фразата „това не е истински електронен подпис“. А за повечето изредени неща ми трябва квалифициран електронен подпис, за който плащам 10-15 лева годишно, и който и аз понякога се затруднявам да подкарам в правилния браузър с правилната версия на Java.

Т.е. нещата ги има, ама не съвсем. Работят, ама трябва да инвестираш време да разбереш как работят. И това не е окей. Но какво може да се направи?

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

Има обаче едно нещо, което със сигурност е отключващ фактор – електронната идентификация. Ако няма лесно и удобно средство да се идентифицираме онлайн и да заявяваме услуги, ще ги ползваме шепа хора. (И счетоводителите и юристите, на които им се налага). Но след Закона за електронната идентификация нищо не се е случило. В 2017-та новите лични карти с е-идентификация не станаха, бяха отложени за 2018-та, ама Капитал тези дни писа, че нещата отиват към 2020-та. Масово и достъпно средство не е само личната карта, но знаейки, че тя така или иначе идва, няма смисъл да се инвестира в нещо друго. Т.е. ще си останем с КЕП още известно време. Появяват се частни схеми (в България и Европа), които обаче най-вероятно също ще са платени, а и не е ясно дали ще поддържат подписване на заявления (ЗЕУ допуска подписване с усъвършенстван електронен подпис, но ифраструктурата за е-идентификация, предвидена от ЕС, не предвижда всички схеми да могат да се ползват и за подпис; дори напротив).

Второто нещо е т.нар. UX (User Experience). Това не значи просто потребителския интерфейс да е удобен – значи процесите зад този интерфейс да са оптимизирани и удобни. Не в рамките на процеса по заявяване да минаваш през 4 стъпки и 2 имейла, защото така било според вътрешна наредба от 96-та (#truestory). UX-ът е причината никой (дори хора с КЕП) да не използват услугите. Защото в UX-а влиза и това гражданите да знаят, че има такива услуги. Кога последно Столична община ви каза, че има електронни услуги? Никога. Доскоро бяха скрити на сайта дотолкова, че и аз не можех да ги открия. Тестове с реални потребители въведохме като задължително изискване както в наредба, така и в условия за финансиране. Само че ако и изпълнителят, и възложителят не знаят какво е UX, то ще бъде отчетено като изпълнено и пак ще получим някоя деветдесетарска грозотия.

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

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

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

User Authentication Best Practices Checklist

Post Syndicated from Bozho original

User authentication is the functionality that every web application shared. We should have perfected that a long time ago, having implemented it so many times. And yet there are so many mistakes made all the time.

Part of the reason for that is that the list of things that can go wrong is long. You can store passwords incorrectly, you can have a vulnerably password reset functionality, you can expose your session to a CSRF attack, your session can be hijacked, etc. So I’ll try to compile a list of best practices regarding user authentication. OWASP top 10 is always something you should read, every year. But that might not be enough.

So, let’s start. I’ll try to be concise, but I’ll include as much of the related pitfalls as I can cover – e.g. what could go wrong with the user session after they login:

  • Store passwords with bcrypt/scrypt/PBKDF2. No MD5 or SHA, as they are not good for password storing. Long salt (per user) is mandatory (the aforementioned algorithms have it built in). If you don’t and someone gets hold of your database, they’ll be able to extract the passwords of all your users. And then try these passwords on other websites.
  • Use HTTPS. Period. (Otherwise user credentials can leak through unprotected networks). Force HTTPS if user opens a plain-text version.
  • Mark cookies as secure. Makes cookie theft harder.
  • Use CSRF protection (e.g. CSRF one-time tokens that are verified with each request). Frameworks have such functionality built-in.
  • Disallow framing (X-Frame-Options: DENY). Otherwise your website may be included in another website in a hidden iframe and “abused” through javascript.
  • Have a same-origin policy
  • Logout – let your users logout by deleting all cookies and invalidating the session. This makes usage of shared computers safer (yes, users should ideally use private browsing sessions, but not all of them are that savvy)
  • Session expiry – don’t have forever-lasting sessions. If the user closes your website, their session should expire after a while. “A while” may still be a big number depending on the service provided. For ajax-heavy website you can have regular ajax-polling that keeps the session alive while the page stays open.
  • Remember me – implementing “remember me” (on this machine) functionality is actually hard due to the risks of a stolen persistent cookie. Spring-security uses this approach, which I think should be followed if you wish to implement more persistent logins.
  • Forgotten password flow – the forgotten password flow should rely on sending a one-time (or expiring) link to the user and asking for a new password when it’s opened. 0Auth explain it in this post and Postmark gives some best pracitces. How the link is formed is a separate discussion and there are several approaches. Store a password-reset token in the user profile table and then send it as parameter in the link. Or do not store anything in the database, but send a few params: userId:expiresTimestamp:hmac(userId+expiresTimestamp). That way you have expiring links (rather than one-time links). The HMAC relies on a secret key, so the links can’t be spoofed. It seems there’s no consensus, as the OWASP guide has a bit different approach
  • One-time login links – this is an option used by Slack, which sends one-time login links instead of asking users for passwords. It relies on the fact that your email is well guarded and you have access to it all the time. If your service is not accessed to often, you can have that approach instead of (rather than in addition to) passwords.
  • Limit login attempts – brute-force through a web UI should not be possible; therefore you should block login attempts if they become too many. One approach is to just block them based on IP. The other one is to block them based on account attempted. (Spring example here). Which one is better – I don’t know. Both can actually be combined. Instead of fully blocking the attempts, you may add a captcha after, say, the 5th attempt. But don’t add the captcha for the first attempt – it is bad user experience.
  • Don’t leak information through error messages – you shouldn’t allow attackers to figure out if an email is registered or not. If an email is not found, upon login report just “Incorrect credentials”. On passwords reset, it may be something like “If your email is registered, you should have received a password reset email”. This is often at odds with usability – people don’t often remember the email they used to register, and the ability to check a number of them before getting in might be important. So this rule is not absolute, though it’s desirable, especially for more critical systems.
  • Make sure you use JWT only if it’s really necessary and be careful of the pitfalls.
  • Consider using a 3rd party authentication – OpenID Connect, OAuth by Google/Facebook/Twitter (but be careful with OAuth flaws as well). There’s an associated risk with relying on a 3rd party identity provider, and you still have to manage cookies, logout, etc., but some of the authentication aspects are simplified.
  • For high-risk or sensitive applications use 2-factor authentication. There’s a caveat with Google Authenticator though – if you lose your phone, you lose your accounts (unless there’s a manual process to restore it). That’s why Authy seems like a good solution for storing 2FA keys.

I’m sure I’m missing something. And you see it’s complicated. Sadly we’re still at the point where the most common functionality – authenticating users – is so tricky and cumbersome, that you almost always get at least some of it wrong.

The post User Authentication Best Practices Checklist appeared first on Bozho's tech blog.

Tracking Cookies and GDPR

Post Syndicated from Bozho original

GDPR is the new data protection regulation, as you probably already know. I’ve given a detailed practical advice for what it means for developers (and product owners). However, there’s one thing missing there – cookies. The elephant in the room.

Previously I’ve stated that cookies are subject to another piece of legislation – the ePrivacy directive, which is getting updated and its new version will be in force a few years from now. And while that’s technically correct, cookies seem to be affected by GDPR as well. In a way I’ve underestimated that effect.

When you do a Google search on “GDPR cookies”, you’ll pretty quickly realize that a) there’s not too much information and b) there’s not much technical understanding of the issue.

What appears to be the consensus is that GDPR does change the way cookies are handled. More specifically – tracking cookies. Here’s recital 30:

(30) Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.

How tracking cookies work – a 3rd party (usually an ad network) gives you a code snippet that you place on your website, for example to display ads. That code snippet, however, calls “home” (makes a request to the 3rd party domain). If the 3rd party has previously been used on your computer, it has created a cookie. In the example of Facebook, they have the cookie with your Facebook identifier because you’ve logged in to Facebook. So this cookie (with your identifier) is sent with the request. The request also contains all the details from the page. In effect, you are uniquely identified by an identifier (in the case of Facebook and Google – fully identified, rather than some random anonymous identifier as with other ad networks).

Your behaviour on the website is personal data. It gets associated with your identifier, which in turn is associated with your profile. And all of that is personal data. Who is responsible for collecting the website behaviour data, i.e. who is the “controller”? Is it Facebook (or any other 3rd party) that technically does the collection? No, it’s the website owner, as the behaviour data is obtained on their website, and they have put the tracking piece of code there. So they bear responsibility.

What’s the responsibility? So far it boiled down to displaying the useless “we use cookies” warning that nobody cares about. And the current (old) ePrivacy directive and its interpretations says that this is enough – if the users actions can unambiguously mean that they are fine with cookies – i.e. if they continue to use the website after seeing the warning – then you’re fine. This is no longer true from a GDPR perspective – you are collecting user data and you have to have a lawful ground for processing.

For the data collected by tracking cookies you have two options – “consent” and “legitimate interest”. Legitimate interest will be hard to prove – it is not something that a user reasonably expects, it is not necessary for you to provide the service. If your lawyers can get that option to fly, good for them, but I’m not convinced regulators will be happy with that.

The other option is “consent”. You have to ask your users explicitly – that means “with a checkbox” – to let you use tracking cookies. That has two serious implications – from technical and usability point of view.

  • The technical issue is that the data is sent via 3rd party code as soon as the page loads and before the user can give their consent. And that’s already a violation. You can, of course, have the 3rd party code be dynamically inserted only after the user gives consent, but that will require some fiddling with javascript and might not always work depending on the provider. And you’d have to support opt-out at any time (which would in turn disable the 3rd party snippet). It would require actual coding, rather than just copy-pasting a snippet.
  • The usability aspect is the bigger issue – while you could neatly tuck a cookie warning at the bottom, you’d now have to have a serious, “stop the world” popup that asks for consent if you want anyone to click it. You can, of course, just add a checkbox to the existing cookie warning, but don’t expect anyone to click it.

These aspects pose a significant questions: is it worth it to have tracking cookies? Is developing new functionality worth it, is interrupting the user worth it, and is implementing new functionality just so that users never clicks a hidden checkbox worth it? Especially given that Firefox now blocks all tracking cookies and possibly other browsers will follow?

That by itself is an interesting topic – Firefox has basically implemented the most strict form of requirements of the upcoming ePrivacy directive update (that would turn it into an ePrivacy regulation). Other browsers will have to follow, even though Google may not be happy to block their own tracking cookies. I hope other browsers follow Firefox in tracking protection and the issue will be gone automatically.

To me it seems that it will be increasingly not worthy to have tracking cookies on your website. They add regulatory obligations for you and give you very little benefit (yes, you could track engagement from ads, but you can do that in other ways, arguably by less additional code than supporting the cookie consents). And yes, the cookie consent will be “outsourced” to browsers after the ePrivacy regulation is passed, but we can’t be sure at the moment whether there won’t be technical whack-a-mole between browsers and advertisers and whether you wouldn’t still need additional effort to have dynamic consent for tracking cookies. (For example there are reported issues that Firefox used to make Facebook login fail if tracking protection is enabled. Which could be a simple bug, or could become a strategy by big vendors in the future to force browsers into a less strict tracking protection).

Okay, we’ve decided it’s not worth it managing tracking cookies. But do you have a choice as a website owner? Can you stop your ad network from using them? (Remember – you are liable if users’ data is collected by visiting your website). And currently the answer is no – you can’t disable that. You can’t have “just the ads”. This is part of the “deal” – you get money for the ads you place, but you participate in a big “surveillance” network. Users have a way to opt out (e.g. Google AdWords gives them that option). You, as a website owner, don’t.

Facebook has a recommendations page that says “you take care of getting the consent”. But for example the “like button” plugin doesn’t have an option to not send any data to Facebook.

And sometimes you don’t want to serve ads, just track user behaviour and measure conversion. But even if you ask for consent for that and conditionally insert the plugin/snippet, do you actually know what data it sends? And what it’s used for? Because you have to know in order to inform your users. “Do you agree to use tracking cookies that Facebook has inserted in order to collect data about your behaviour on our website” doesn’t sound compelling.

So, what to do? The easiest thing is just not to use any 3rd party ad-related plugins. But that’s obviously not an option, as ad revenue is important, especially in the publishing industry. I don’t have a good answer, apart from “Regulators should pressure ad networks to provide opt-outs and clearly document their data usage”. They have to do that under GDPR, and while website owners are responsible for their users’ data, the ad networks that are in the role of processors in this case (as you delegate the data collection for your visitors to them) also have obligation to assist you in fulfilling your obligations. So ask Facebook – what should I do with your tracking cookies? And when the regulator comes after a privacy-aware customer files a complaint, you could prove that you’ve tried.

The ethical debate whether it’s wrong to collect data about peoples’ behaviour without their informed consent is an easy one. And that’s why I don’t put blame on the regulators – they are putting the ethical consensus in law. It gets more complicated if not allowing tracking means some internet services are no longer profitable and therefore can’t exist. Can we have the cake and eat it too?

The post Tracking Cookies and GDPR appeared first on Bozho's tech blog.

Setting Up Cassandra With Priam

Post Syndicated from Bozho original

I’ve previously explained how to setup Cassandra in AWS. The described setup works, but in some cases it may not be sufficient. E.g. it doesn’t give you an easy way to make and restore backups, and adding new nodes relies on a custom python script that randomly selects a seed.

So now I’m going to explain how to setup Priam, a Cassandra helper tool by Netflix.

My main reason for setting it up is the backup/restore functionality that it offers. All other ways to do backups are very tedious, and Priam happens to have implemented the important bits – the snapshotting and the incremental backups.

Priam is a bit tricky to get running, though. The setup guide is not too detailed and not easy to find (it’s the last, not immediately visible item in the wiki). First, it has one branch per Cassandra version, so you have to checkout the proper branch and build it. I immediately hit an issue there, as their naming doesn’t allow eclipse to import the gradle project. Within 24 hours I reported 3 issues, which isn’t ideal. Priam doesn’t support dynamic SimpleDB names, and doesn’t let you override bundled properties via the command line. I hope there aren’t bigger issues. The ones that I encountered, I fixed and made a pull request.

What does the setup look like?

  • Append a javaagent to the JVM options
  • Run the Priam web
  • It automatically replaces most of cassandra.yaml, including the seed provider (i.e. how does the node find other nodes in the cluster)
  • Run Cassandra
  • It fetches seed information (which is stored in AWS SimpleDB) and connects to a cluster

I decided to run the war file with a standalone jetty runner, rather than installing tomcat. In terms of shell scripts, the core bits look like that (in addition to the shell script in the original post that is run on initialization of the node):

# Get the Priam war file and jar file
aws s3 cp s3://$BUCKET_NAME/priam-web-3.12.0-SNAPSHOT.war ~/
aws s3 cp s3://$BUCKET_NAME/priam-cass-extensions-3.12.0-SNAPSHOT.jar /usr/share/cassandra/lib/priam-cass-extensions.jar
# Set the Priam agent
echo "-javaagent:/usr/share/cassandra/lib/priam-cass-extensions.jar" >> /etc/cassandra/conf/jvm.options

# Download jetty-runner to be able to run the Priam war file from the command line
nohup java -Dpriam.clustername=LogSentinelCluster -Dpriam.sdb.instanceIdentity.region=$EC2_REGION -Dpriam.s3.bucket=$BACKUP_BUCKET \
-Dpriam.sdb.instanceidentity.domain=$INSTANCE_IDENTITY_DOMAIN$PROPERTIES_DOMAIN \
-Dpriam.client.sslEnabled=true -Dpriam.internodeEncryption=all -Dpriam.rpc.server.type=sync \
-Dpriam.partitioner=org.apache.cassandra.dht.Murmur3Partitioner -Dpriam.backup.retention.days=7 \
-Dpriam.backup.hour=$BACKUP_HOUR -Dpriam.vnodes.numTokens=256 -Dpriam.thrift.enabled=false \
-jar jetty-runner-9.4.8.v20171121.jar --path /Priam ~/priam-web-3.12.0-SNAPSHOT.war &

while ! echo exit | nc $BIND_IP 8080; do sleep 10; done

echo "Started Priam web package"

service cassandra start
chkconfig cassandra on

while ! echo exit | nc $BIND_IP 9042; do sleep 10; done

BACKUP_BUCKET, PROPERTIES_DOMAIN and INSTANCE_DOMAIN are supplied via a CloudFormation script (as we can’t know the exact names in advance – especially for SimpleDB). Note that these properties won’t work in the main repo – I added them in my pull request.

In order for that to work, you need to have the two SimpleDB domains created (e.g. by CloudFormation). It is possible that you could replace SimpleDB with some other data storage (and not rely on AWS), but that’s out of scope for now.

The result of running Priam would be that you have your Cassandra nodes in SimpleDB (you can browse it using this chrome extension as AWS doesn’t offer any UI) and, of course, backups will be automatically created in the backup S3 Bucket.

You can then restore a backup by logging to each node and executing:

curl http://localhost:8080/Priam/REST/v1/restore?daterange=201803180000,201803191200&region=eu-west-1&keyspaces=your_keyspace

You specify the time range for the restore. Still not ideal, as one would hope to have a one-click restore, but much better than rolling out your own backup & restore infrastructure.

One very important note here – vnodes are not supported. My original cluster had a default of 256 vnodes per machine and now it has just 1, because Priam doesn’t support anything other than 1. That’s a pity, since vnodes are the recommended way to setup Cassandra. Apparently Netflix don’t use those, however. There’s a work-in-progress branch for that that was abandoned 5 years ago. Fortunately, there’s a fresh pull request with Vnode support that can be used in conjunction with my pull request from this branch.

Priam replaces some Cassandra defaults with other values so you might want to compare your current setup and the newly generated cassandra.yaml. Overall it doesn’t feel super-production ready, but apparently it is, as Netflix is using it in production.

The post Setting Up Cassandra With Priam appeared first on Bozho's tech blog.

Технологиите изпреварват политиките?

Post Syndicated from Bozho original

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

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

Това изоставане има три аспекта. Първият се отнася до вече съществуващи бизнес модели и практики, които биват променяни с развитието на технологиите. Пример за това са таксиметровите и хотелиерските услуги. Uber и Airbnb не са били възможни преди 10-15 години. И съответно законодателството в тези сфери не ги допуска като възможност – такситата трябва да имат таксиметров апарат и да бъдат жълти, а хотелите трябва да са категоризирани и да отговарят на определени изисквания. Новите технологии позволяват създаването на репутационни системи (например за таксита или хотели), базирани на оценката на потребителите, а не на това какво смята държавата. Съответно законодателството изостава от реалностите и трябва да наваксва.

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

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

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

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

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

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

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

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

Using JWT For Sessions

Post Syndicated from Bozho original

The topic has been discussed many times, on hacker news, reddit, blogs. And the consensus is – DON’T USE JWT (for user sessions).

And I largely agree with the criticism of typical arguments for the JWT, the typical “but I can make it work…” explanations and the flaws of the JWT standard..

I won’t repeat everything here, so please go and read those articles. You can really shoot yourself in the foot with JWT, it’s complex to get to know it well and it has little benefits for most of the usecases. I guess for API calls it makes sense, especially if you reuse the same API in a single-page application and for your RESTful clients, but I’ll focus on the user session usecase.

Having all this criticism, I’ve gone against what the articles above recommend, and use JWT, navigating through their arguments and claiming I’m in a sweet spot. I can very well be wrong.

I store the user ID in a JWT token stored as a cookie. Not local storage, as that’s problematic. Not the whole state, as I don’t need that may lead to problems (pointed out in the linked articles). In fact, I don’t have any session state apart from the user data, which I think is a good practice.

What I want to avoid in my setup is sharing sessions across nodes. And this is a very compelling reason to not use the session mechanism of your web server/framework. No, you don’t need to have millions of users in order to need your application to run on more than one node. In fact, it should almost always run on (at least) two nodes, because nodes die and you don’t want downtime. Sticky sessions at the load balancer are a solution to that problem but you are just outsourcing the centralized session storage to the load balancer (and some load balancers might not support it). Shared session cache (e.g. memcached, elasticache, hazelcast) is also an option, and many web servers (at least in Java) support pluggable session replication mechanisms, but that introduces another component to the archtecture, another part of the stack to be supported and that can possibly break. It is not necessarily bad, but if there’s a simple way to avoid it, I’d go for it.

In order to avoid shared session storage, you need either the whole session state to be passed in the request/response cycle (as cookie, request parameter, header), or to receive a userId and load the user from the database or a cache. As we’ve learned, the former might be a bad choice. Despite that fact that frameworks like ASP.NET and JSF dump the whole state in the HTML of the page, it doesn’t intuitively sound good.

As for the latter – you may say “ok, if you are going to load the user from the database on every request this is going to be slow and if you use a cache, then why not use the cache for the sessions themselves?”. Well, the cache can be local. Remember we have just a few application nodes. Each node can have a local, in-memory cache for the currently active users. The fact that all nodes will have the same user loaded (after a few requests are routed to them by the load balancer in a round-robin fashion) is not important, as that cache is small. But you won’t have to take any care for replicating it across nodes, taking care of new nodes coming and going from the cluster, dealing with network issues between the nodes, etc. Each application node will be an island not caring about any other application node.

So here goes my first objection to the linked articles – just storing the user identifier in a JWT token is not pointless, as it saves you from session replication.

What about the criticism for the JWT standard and the security implications of its cryptography? Entirely correct, it’s easy to shoot yourself in the foot. That’s why I’m using JWT only with MAC, and only with a particular algorithm that I verify upon receiving the token, thus (allegedly) avoiding all the pitfalls. In all fairness, I’m willing to use the alternative proposed in one of the articles – PASETO – but it doesn’t have a Java library and it will take some time implementing one (might do in the future). To summarize – if there was another easy to use way for authenticated encryption of cookies, I’d use it.

So I’m basically using JWT in “PASETO-mode”, with only one operation and only one algorithm. And that should be fine as a general approach – the article doesn’t criticize the idea of having a user identifier in a token (and a stateless application node), it criticizes the complexity and vulnerabilities of the standard. This is sort of my second objection – “Don’t use JWT” is widely understood to mean “Don’t use tokens”, where that is not the case.

Have I introduced some vulnerability in my strive for architectural simplicity and lack of shared state? I hope not.

The post Using JWT For Sessions appeared first on Bozho's tech blog.

Накратко за киберсигурността

Post Syndicated from Bozho original

През уикенда се проведе събитие в рамките на „Български манифест за Европа“ на тема „Европейски съюз за отбрана и сигурност и неговите черноморски измерения“

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

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

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

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

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

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

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

Критика към анализа на ЦИК за електронното гласуване

Post Syndicated from Bozho original

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

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

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

Чиповете в картите (на естонците) са пробити и това компрометира гласуването

Да, имаше много неприятен бъг в един модел чипове на Infineon, който на практика позволява да се постави електронен подпис (което включва подаване на глас) от ваше име без вие да разберете. Няколко детайла, обаче:

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

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

„Франция прекрати електронното гласуване“

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

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

Но да преминем към анализа на ЦИК. Там има доста точки, които са или силно дискусионни, или неаргументирани или необосновани. Не казвам, че това е нарочно или злонамерено. Можем да го разгледаме донякъде като консервативно – а институция като ЦИК трябва да е консервативна. Приемам като своя грешка, че не съм се включил по-рано в експертните дискусии и ще опитам да изпратя критиката си до членовете на ЦИК, така че да се намери най-доброто решение.

Ето някои откъси от доклада:

В същото време дистанционното електронно гласуване, макар и удобно за потребителя (user friendly), изисква специфични компютърни умения. За разлика от останалите електронни услуги, при електронното гласуване има допълнителни стъпки, свързани с гарантиране на сигурността

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

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

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

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

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

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

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

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

С квалифициран електронен подпис, обаче, разполагат сравнително малко на брой граждани

Тук това „обаче“ подсказва за една несигурност в предходното становище. „Обаче“ значи, че в предното изречение е казано, че квалифицираният електронен подпис е допустим, „обаче“, има сравнително малко хора, които имат такъв. Така или иначе липсва точна бройка и не е ясно дали тази оценка е била „на око“ или реално са попитали Комисията за регулиране на съобщенията за тази информация. Аз бих попитал КРС, но по интуиция бройката на подписите би трябвало да е поне 40-50 хиляди. Напълно достатъчно за провеждане както на експерименти, така и на първите няколко избора. Убеден съм, също така, че доставчиците на електронни подписи биха издавали безплатни такива с ограничен срок на действие. Гласуването с КЕП наистина не следва да бъде универсално решение, но за спазване на сроковете в кодекса (т.е. европейски избори 2019) е напълно достатъчно.

Реализацията на проект „Изграждане и внедряване на система за дистанционно електронно гласуване“ [..] проект „Развитие на пилотната система за електронна идентификация и внедряване в продуктивен режим“ [..] и проект “Реализиране на ЦАИС „Гражданска регистрация“ и ЦАИС „Адресен регистър“ [..] трябва да се разглеждат в съвкупност и дейностите по тях да се синхронизират, защото са взаимно свързани. Ако се разглеждат и се развиват поотделно, няма да се получи единна, работеща система. Ето защо в дейност 2 на проекта с бенефициент ДАЕУ и партньор ЦИК е заложено, че системата за дистанционно електронно гласуване трябва да е синхронизирана с националната система за електронна идентификация и Национална база данни „Население“, съответно с ЦАИС „Гражданска регистрация“

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

Системата за дистанционно електронно гласуване на Естония е сертифицирана от частна международна компания – KPMG. Тъй като произвеждането на избори като база на демокрацията е и елемент на националната сигурност ЦИК счита, че въвеждането на повсеместно дистанционно електронно гласуване не би било надеждно при липса на държавен орган или организация, която да гарантира сигурността на системата в съответствие с изискванията на закона

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

В последната точка от анализа си ЦИК предават на практика думите на проф. Константинов, които адресирах по-горе.

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

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

Adding Visible Electronic Signatures To PDFs

Post Syndicated from Bozho original

I’m aware this is going to be a very niche topic. Electronically signing PDFs is far from a mainstream usecase. However, I’ll write it for two reasons – first, I think it will be very useful for those few who actually need it, and second, I think it will become more and more common as the eIDAS regulation gain popularity – it basically says that electronic signatures are recognized everywhere in Europe (now, it’s not exactly true, because of some boring legal details, but anyway).

So, what is the usecase – first, you have to electronically sign the PDF with an a digital signature (the legal term is “electronic signature”, so I’ll use them interchangeably, although they don’t fully match – e.g. any electronic data applied to other data can be seen as an electronic signature, where a digital signature is the PKI-based signature).

Second, you may want to actually display the signature on the pages, rather than have the PDF reader recognize it and show it in some side-panel. Why is that? Because people are used to seeing signatures on pages and some may insist on having the signature visible (true story – I’ve got a comment that a detached signature “is not a REAL electronic signature, because it’s not visible on the page”).

Now, notice that I wrote “pages”, on “page”. Yes, an electronic document doesn’t have pages – it’s a stream of bytes. So having the signature just on the last page is okay. But, again, people are used to signing all pages, so they’d prefer the electronic signature to be visible on all pages.

And that makes the task tricky – PDF is good with having a digital signature box on the last page, but having multiple such boxes doesn’t work well. Therefore one has to add other types of annotations that look like a signature box and when clicked open the signature panel (just like an actual signature box).

I have to introduce here DSS – a wonderful set of components by the European Commission that can be used to sign and validate all sorts of electronic signatures. It’s open source, you can use at any way you like. Deploy the demo application, use only the libraries, whatever. It includes the signing functionality out of the box – just check the PAdESService or the PDFBoxSignatureService. It even includes the option to visualize the signature once (on a particular page).

However, it doesn’t have the option to show “stamps” (images) on multiple pages. Which is why I forked it and implemented the functionality. Most of my changes are in the PDFBoxSignatureService in the loadAndStampDocument(..) method. If you want to use that functionality you can just build a jar from my fork and use it (by passing the appropriate SignatureImageParameters to PAdESSErvice.sign(..) to define how the signature will look like).

Why is this needed in the first place? Because when a document is signed, you cannot modify it anymore, as you will change the hash. However, PDFs have incremental updates which allow appending to the document and thus having a newer version without modifying anything in the original version. That way the signature is still valid (the originally signed content is not modified), but new stuff is added. In our case, this new stuff is some “annotations”, which represent an image and a clickable area that opens the signature panel (in Adobe Reader at least). And while they are added before the signature box is added, if there are more than one signer, then the 2nd signer’s annotations are added after the first signature.

Sadly, PDFBox doesn’t support that out of the box. Well, it almost does – the piece of code below looks hacky, and it took a while to figure what exactly should be called and when, but it works with just a single reflection call:

    for (PDPage page : pdDocument.getPages()) {
        // reset existing annotations (needed in order to have the stamps added)
    // reset document outline (needed in order to have the stamps added)
    List<PDAnnotation> annotations = addStamps(pdDocument, parameters);
    setDocumentId(parameters, pdDocument);
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    try (COSWriter writer = new COSWriter(baos, new RandomAccessBuffer(pdfBytes))) {
        // force-add the annotations (wouldn't be saved in incremental updates otherwise)
        annotations.forEach(ann -> addObjectToWrite(writer, ann.getCOSObject()));
        // technically the same as saveIncremental but with more control
    pdDocument = PDDocument.load(baos.toByteArray());

private void addObjectToWrite(COSWriter writer, COSDictionary cosObject) {
    // the COSWriter does not expose the addObjectToWrite method, so we need reflection to add the annotations
    try {
        Method method = writer.getClass().getDeclaredMethod("addObjectToWrite", COSBase.class);
        method.invoke(writer, cosObject);
    } catch (Exception ex) {
        throw new RuntimeException(ex);

What it does is – loads the original PDF, clears some internal catalogs, adds the annotations (images) to all pages, and then “force-add the annotations” because they “wouldn’t be saved in incremental updates otherwise”. I hope PDFBox make this a little more straightforward, but for the time being this works, and it doesn’t invalidate the existing signatures.

I hope that this posts introduces you to:

  • the existence of legally binding electronic signatures
  • the existence of the DSS utilities
  • the PAdES standard for PDF signing
  • how to place more than just one signature box in a PDF document

And I hope this article becomes more and more popular over time, as more and more businesses realize they could make use of electronic signatures.

The post Adding Visible Electronic Signatures To PDFs appeared first on Bozho's tech blog.

Integration With Zapier

Post Syndicated from Bozho original

Integration is boring. And also inevitable. But I won’t be writing about enterprise integration patterns. Instead, I’ll explain how to create an app for integration with Zapier.

What is Zapier? It is a service that allows you tо connect two (or more) otherwise unconnected services via their APIs (or protocols). You can do stuff like “Create a Trello task from an Evernote note”, “publish new RSS items to Facebook”, “append new emails to a spreadsheet”, “post approaching calendar meeting to Slack”, “Save big email attachments to Dropbox”, “tweet all instagrams above a certain likes threshold”, and so on. In fact, it looks to cover mostly the same usecases as another famous service that I really like – IFTTT (if this then that), with my favourite use-case “Get a notification when the international space station passes over your house”. And all of those interactions can be configured via a UI.

Now that’s good for end users but what does it have to do with software development and integration? Zapier (unlike IFTTT, unfortunately), allows custom 3rd party services to be included. So if you have a service of your own, you can create an “app” and allow users to integrate your service with all the other 3rd party services. IFTTT offers a way to invoke web endpoints (including RESTful services), but it doesn’t allow setting headers, so that makes it quite limited for actual APIs.

In this post I’ll briefly explain how to write a custom Zapier app and then will discuss where services like Zapier stand from an architecture perspective.

The thing that I needed it for – to be able to integrate LogSentinel with any of the third parties available through Zapier, i.e. to store audit logs for events that happen in all those 3rd party systems. So how do I do that? There’s a tutorial that makes it look simple. And it is, with a few catches.

First, there are two tutorials – one in GitHub and one on Zapier’s website. And they differ slightly, which becomes tricky in some cases.

I initially followed the GitHub tutorial and had my build fail. It claimed the zapier platform dependency is missing. After I compared it with the example apps, I found out there’s a caret in front of the zapier platform dependency. Removing it just yielded another error – that my node version should be exactly 6.10.2. Why?

The Zapier CLI requires you have exactly version 6.10.2 installed. You’ll see errors and will be unable to proceed otherwise.

It appears that they are using AWS Lambda which is stuck on Node 6.10.2 (actually – it’s 6.10.3 when you check). The current major release is 8, so minus points for choosing … javascript for a command-line tool and for building sandboxed apps. Maybe other decisions had their downsides as well, I won’t be speculating. Maybe it’s just my dislike for dynamic languages.

So, after you make sure you have the correct old version on node, you call zapier init and make sure there are no carets, npm install and then zapier test. So far so good, you have a dummy app. Now how do you make a RESTful call to your service?

Zapier splits the programmable entities in two – “triggers” and “creates”. A trigger is the event that triggers the whole app, an a “create” is what happens as a result. In my case, my app doesn’t publish any triggers, it only accepts input, so I won’t be mentioning triggers (though they seem easy). You configure all of the elements in index.js (e.g. this one):

const log = require('./creates/log');
creates: {
    [log.key]: log,

The log.js file itself is the interesting bit – there you specify all the parameters that should be passed to your API call, as well as making the API call itself:

const log = (z, bundle) => {
  const responsePromise = z.request({
    method: 'POST',
    url: `${bundle.inputData.actorId}/${bundle.inputData.action}`,
    body: bundle.inputData.details,
	headers: {
		'Accept': 'application/json'
  return responsePromise
    .then(response => JSON.parse(response.content));

module.exports = {
  key: 'log-entry',
  noun: 'Log entry',

  display: {
    label: 'Log',
    description: 'Log an audit trail entry'

  operation: {
    inputFields: [
      {key: 'actorId', label:'ActorID', required: true},
      {key: 'action', label:'Action', required: true},
      {key: 'details', label:'Details', required: false}
    perform: log

You can pass the input parameters to your API call, and it’s as simple as that. The user can then specify which parameters from the source (“trigger”) should be mapped to each of your parameters. In an example zap, I used an email trigger and passed the sender as actorId, the sibject as “action” and the body of the email as details.

There’s one more thing – authentication. Authentication can be done in many ways. Some services offer OAuth, others – HTTP Basic or other custom forms of authentication. There is a section in the documentation about all the options. In my case it was (almost) an HTTP Basic auth. My initial thought was to just supply the credentials as parameters (which you just hardcode rather than map to trigger parameters). That may work, but it’s not the canonical way. You should configure “authentication”, as it triggers a friendly UI for the user.

You include authentication.js (which has the fields your authentication requires) and then pre-process requests by adding a header (in index.js):

const authentication = require('./authentication');

const includeAuthHeaders = (request, z, bundle) => {
  if (bundle.authData.organizationId) {
	request.headers = request.headers || {};
	request.headers['Application-Id'] = bundle.authData.applicationId
	const basicHash = Buffer(`${bundle.authData.organizationId}:${bundle.authData.apiSecret}`).toString('base64');
	request.headers['Authorization'] = `Basic ${basicHash}`;
  return request;

const App = {
  // This is just shorthand to reference the installed dependencies you have. Zapier will
  // need to know these before we can upload
  version: require('./package.json').version,
  platformVersion: require('zapier-platform-core').version,
  authentication: authentication,
  // beforeRequest & afterResponse are optional hooks into the provided HTTP client
  beforeRequest: [

And then you zapier push your app and you can test it. It doesn’t automatically go live, as you have to invite people to try it and use it first, but in many cases that’s sufficient (i.e. using Zapier when doing integration with a particular client)

Can Zapier can be used for any integration problem? Unlikely – it’s pretty limited and simple, but that’s also a strength. You can, in half a day, make your service integrate with thousands of others for the most typical use-cases. And not that although it’s meant for integrating public services rather than for enterprise integration (where you make multiple internal systems talk to each other), as an increasing number of systems rely on 3rd party services, it could find home in an enterprise system, replacing some functions of an ESB.

Effectively, such services (Zapier, IFTTT) are “Simple ESB-as-a-service”. You go to a UI, fill a bunch of fields, and you get systems talking to each other without touching the systems themselves. I’m not a big fan of ESBs, mostly because they become harder to support with time. But minimalist, external ones might be applicable in certain situations. And while such services are primarily aimed at end users, they could be a useful bit in an enterprise architecture that relies on 3rd party services.

Whether it could process the required load, whether an organization is willing to let its data flow through a 3rd party provider (which may store the intermediate parameters), is a question that should be answered in a case by cases basis. I wouldn’t recommend it as a general solution, but it’s certainly an option to consider.

The post Integration With Zapier appeared first on Bozho's tech blog.

Визия за електронно бъдеще

Post Syndicated from Bozho original

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

  • Електронно гражданство – това естонците вече го имат, а в заданието за системата за електронна идентификация бяхме заложили гъвкавост в идентификаторите – в момента са само ЕГН и ЛНЧ, но ако законодателството позволи на произволни чужди граждани да се издава електронна идентичност, това да бъде възможно и със съществуващата система. Това би позволило на чужденци да откриват фирми, да плащат данъци и да развиват дигитален бизнес без да са стъпвали в страната.
  • Гъвкава електронна идентификация – в момента електронната идентификация се предвижда на носител (смарткарта). Това не е най-удобното решение, но за желаните нива на сигурност е горе-долу единствената опция. Но след 5-6 години мобилните телефони, а и други преносими устройства ще имат, надявам се, същото ниво на сигурност (в момента са възможни хибридни схеми със split key между телефон + HSM, но да не влизаме в подробности.)
  • Пълен контрол на гражданите върху данните им – всеки да може да определя кой има достъп до данните му, да вижда кога са четени – не само в публичния сектор но и в частния. Това технологично изглежда трудно, но за публичния сектор е напълно постижимо, а за частния – с развитието на криптографията се надявам да има как да управляваме данните си без да се налага да правим „крипто-шаманизми“, които са трудни дори за напреднали.
  • Всички системи да имат програмни интерфейси и да си „говорят“. Това вече е заложено като изискване, но ще стане реалност най-рано след 4-5 години. Това ще превърне системите на държавата (а и не само) в лего-блокчета, от които и държавата, и бизнесът ще могат да сглобяват нови приложения.
  • Единен портал за граждани – и това е заложено като „първа версия“ в системата за електронна идентификация, но в неговата пълнота би изглеждало така – влизате (с електронната си идентичност) в портала и там виждате всички данни за себе си, всички данъци и такси, които дължите (и история на тяхното плащане), срокове, в които да извършите някакви задължения или препоръчителни действия (технически прегледи, гражданска отговорност, смяна на лична карта, записване на дете в детска градина или училище, профилактични медицински прегледи) и всичко това да може да се направи с един бутон – „плати данъци“, „записи дете в детска градина Х“, „поднови гражданска отговорност“, „запази си час за личния лекар“ и т.н. Някои от нещата може да стават и автоматично и само да получаваме известия, че са станали. Това разбира се би изисквало оптимизиране или изграждане наново на стотици процеси, но е постижимо.
  • Хартия в администрацията и в отношенията между бизнеса и гражданите – само в тоалетната. Това е шега на естонците, но колкото по-малко хартия размотаваме напред-назад, толкова по-добре. И не само заради спасените гори, а защото това би значело, че всичко можем да свършим в движение, отдалечено, лесно и бързо.

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

  • Автоматична оценка на въздействието на законодателството – всеки закон или наредба в момента трябва да бъде приеман само след като е оценено въздействието му (напр. върху бизнеса). Това обаче далеч не се прави винаги. Според мен може да бъде автоматизирано до голяма степен – ако всички данни на държавата са налични в голямо хранилище и поддържани и класифицирани прилежно, а текстът на законопроектите не се твори „на колянце“, а следват адекватен, електронизиран и прозрачен процес, то той ще може да бъде анализиран машинно и съпоставян с данните, като така ще може по време на писането да е ясно какви аспекти засяга. Разбира се, това няма как да е пълно (освен ако изкуственият интелект не напредне драматично), но поне ще можем да имаме частична картина.
  • Изкуствен интелект за идентифициране на проблемни сфери – следейки гореспоменатите данни за дълги периоди от време, изкуствен интелект ще може да вдига „червени флагчета“ за проблемни сфери – ако раждаемостта намалява 7-8 години поред, значи може би е нужна политика, която да адресира проблема; ако чуждите инвестиции намаляват, значи е нужна политика по привличането им; ако броят на деца, оставащи извън детски градини расте, значи спешно трябва политика по осигуряването на такива (стимул за частни; ускорено строене на общински и др.); ако въздухът е мръсен за продължителен период… и т.н, и т.н. И всеки управляващ (министър/кмет) да има едно табло, на което да вижда проблемите сфери подредени по риск и приоритетност.
  • Система за идентифициране на корупция – в предложения проект за анализ на корупционния риск в пътната карта е залегнало автоматичен анализ, но той не е проактивен – на база на хранилището за данни може да се идентифицира корупция много по-ефективно.

Има обаче и много други аспекти на дигитализацията:

  • Пряко гражданско участие – не само електронно дистанционно гласуване и електронни референдуми, а възможност за активно участие във вземането на решения. Не смятам, че представителната демокрация е лоша и че пряката непременно ще реши всички проблеми, но със сигурност повече възможности за електронно гражданско участие (напр. в гласувания в парламентарни комисии; в изготвяне на законопроекти и др.) биха значели по-демократично-осъзнатео общество.
  • Дигитална грамотност (e-literacy) – в момента България е на последните място в Европа по дигитална грамотност. Не ползваме възможностите, които новите технологии предоставят, не се ориентираме в интернет-лабиринта, вярваме на фалшиви новини, не умеем да комунимираме онлайн и т.н. Това всичко може и трябва да се подобри, за да не изоставаме и да не ставаме по-бедни поради това си изоставане. Политика на министерство на образованието е необходима, но не достатъчна. Трябва електронното ограмотяване да се случва на всички нива, във всички възрасти. И не просто „как да ползваме компютър, за да се обаждаме на децата в чужбина“. А дори да можем да програмираме прости програми, ако щете. Защото това би повишило ефективността ни многократно, без значение от професията.
  • ИТ индустрията да премине отвъд аутсорсинга. Отвъд това да изпълнява тривиални (но времеемки) задачи на големи компании. Имаме потенциала да решаваме световни и местни проблеми и поне някой от е-гигантите на бъдещето да бъде тук. Да, за това е нужно не само технологична експертиза и предприемчивост, а и инвеститорска екосистема, но напредваме в това отношение.
  • Реален единен цифров пазар в Европа (а защо не и Европа+САЩ+други държави). В момента регулациите в различните европейски държави са толкова различни, че ако един бизнес иска да продава навсякъде, трябва да си наема юристи във всяка държава (образно казано). Опитите на настоящата комисия не бяха достатъчни и много сфери останаха или нехармонизирани, или хармонизирани проформа (напр. директивата за авторското право, за която ще пиша скоро, няма изгледи да постигне желания ефект). Дали европейските регламенти и директиви ще премахват местни особености или ще ги хармонизират между нациите, резултатът трябва да е един – единствената разлика между България, Франция, Естоняи и Испания да бъде езикът на потребителския интерфейс. А той би трябвало да бъде превеждан машинно в следващите 5-6 години.
  • Позволяване на реална споделена икономика чрез умни и гъвкави регулации и дерегулации – не твърдя, че Uber и AirBNB „са бъдещето“, но и такива и по-децентрализирани модели на предоставяне на услуги трябва да бъдат допустими, а не „по ръба на закона“. Схемите за репутация на шофьори, хотели, ресторанти и какво ли още не не трябва да са държавен монопол – държавата трябва да ги делегира на технологично по-адекватните.

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

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

GDPR for Developers [presentation]

Post Syndicated from Bozho original

On a recent meetup in Amsterdam I talked about GDPR from a technical point of view, effectively turning my “GDPR – a practical guide for developers” article into a talk.

You can see the slides here:

If you’re interested, you can also join a webinar on the same topic, organized by AxonIQ, where I will join Frans Vanbuul. You can find more information about the webinar here.

The interesting thing that I can share after the meetup and after meeting with potential clients is that everyone (maybe unsurprisingly) has a very specific question that doesn’t get an immediate answer even after you follow the general guidelines. That is maybe a problem on the Regulation’s side, as it has not brought sufficient clarity to businesses.

As I said during the presentation – in technology we’re used with binary questions. In law and legal compliance an answer is somewhere on a scale between 1 and 10. “Do I have to encrypt my data at rest”? Well, I guess yes, but in terms of compliance I’d say “6 out of 10”, as it is not strict, depends on the multiple people’s interpretation of the sensitivity of the data and on other factors like access control.

So the communication between legal and technical people is key to understand what exactly implementation changes are needed.

The post GDPR for Developers [presentation] appeared first on Bozho's tech blog.

When You Have A Blockchain, Everything Looks Like a Nail

Post Syndicated from Bozho original

Blockchain, AI, big data, NoSQL, microservices, single page applications, cloud, SOA. What do these have in common? They have been or are hyped. At some point they were “the big thing” du jour. Everyone was investigating the possibility of using them, everyone was talking about them, there were meetups, conferences, articles on Hacker news and reddit. There are more examples, of course (which is the javascript framework this month?) but I’ll focus my examples on those above.

Another thing they have in common is that they are useful. All of them have some pretty good applications that are definitely worth the time and investment.

Yet another thing they have in common is that they are far from universally applicable. I’ve argued that monoliths are often still the better approach and that microservices introduce too much complexity for the average project. Big Data is something very few organizations actually have; AI/machine learning can help a wide variety of problems, but it is just a tool in a toolbox, not the solution to all problems. Single page applications are great for, yeah, applications, but most websites are still websites, not feature-rich frontends – you don’t need an SPA for every type of website. NoSQL has solved niche issues, and issues of scale that few companies have had, but nothing beats a good old relational database for the typical project out there. “The cloud” is not always where you want your software to be; and SOA just means everything (ESBs, direct integrations, even microservices, according to some). And the blockchain – it seems to be having limited success beyond cryptocurrencies.

And finally, another trait many of them share is that the hype has settled down. Only yesterday I read an article about the “death of the microservices madness”. I don’t see nearly as many new NoSQL databases as a few years ago, some of the projects that have been popular have faded. SOA and “the cloud” are already “boring”, and we’ve realized we don’t actually have big data if it fits in an Excel spreadsheet. SPAs and AI are still high in popularity, but we are getting a good understanding as a community why and when they are useful.

But it seems that nuanced reality has never stopped us from hyping a particular technology or approach. And maybe that’s okay in order to get a promising, though niche, technology, the spotlight and let it shine in the particular usecases where it fits.

But countless projects have and will suffer from our collective inability to filter through these hypes. I’d bet millions of developer hours have been wasted in trying to use the above technologies where they just didn’t fit. It’s like that scene from Idiocracy where a guy tries to fit a rectangular figure into a circular hole.

And the new one is not “the blockchain”. I won’t repeat my rant, but in summary – it doesn’t solve many of the problems companies are trying to solve with it right now just because it’s cool. Or at least it doesn’t solve them better than existing solutions. Many pilots will be carried out, many hours will be wasted in figuring out why that thing doesn’t work. A few of those projects will be a good fit and will actually bring value.

Do you need to reach multi-party consensus for the data you store? Can all stakeholder support the infrastructure to run their node(s)? Do they have the staff to administer the node(s)? Do you need to execute distributed application code on the data? Won’t it be easier to just deploy RESTful APIs and integrate the parties through that? Do you need to store all the data, or just parts of it, to guarantee data integrity?

“If you have is a hammer, everything looks like a nail” as the famous saying goes. In the software industry we repeatedly find new and cool hammers and then try to hit as many nails as we can. But only few of them are actual nails. The rest remain ugly, hard to support, “who was the idiot that wrote this” and “I wasn’t here when the decisions were made” types of projects.

I don’t have the illusion that we will calm down and skip the next hypes. Especially if adding the hyped word to your company raises your stock price. But if there’s one thing I’d like people to ask themselves when choosing a technology stack, it is “do we really need that to solve our problems?”.

If the answer is really “yes”, then great, go ahead and deploy the multi-organization permissioned blockchain, or fork Ethereum, or whatever. If not, you can still do a project a home that you can safely abandon. And if you need some pilot project to figure out whether the new piece of technology would be beneficial – go ahead and try it. But have a baseline – the fact that it somehow worked doesn’t mean it’s better than old, tested models of doing the same thing.

The post When You Have A Blockchain, Everything Looks Like a Nail appeared first on Bozho's tech blog.

Fix Your Crawler

Post Syndicated from Bozho original

Every now and then I open the admin panel of my blog hosting and ban a few IPs (after I’ve tried messaging their abuse email, if I find one). It is always IPs that are generating tons of requests (and traffic) – most likely running some home-made crawler. In some cases the IPs belong to an actual service that captures and provides content, in other cases it’s just a scraper for unknown reasons.

I don’t want to ban IPs, especially because that same IP may be reassigned to a legitimate user (or network) in the future. But they are increasing my hosting usage, which in turn leads to the hosting provider suggesting an upgrade in the plan. And this is not about me, I’m just an example – tons of requests to millions of sites are … useless.

My advice (and plea) is this – please fix your crawlers. Or scrapers. Or whatever you prefer to call that thing that programmatically goes on websites and gets their content.

How? First, reuse an existing crawler. No need to make something new (unless there’s a very specific use-case). A good intro and comparison can be seen here.

Second, make your crawler “polite” (the “politeness” property in the article above). Here’s a good overview on how to be polite, including respect for robots.txt. Existing implementations most likely have politeness options, but you may have to configure them.

Here I’d suggest another option – set a dynamic crawl rate per website that depends on how often the content is updated. My blog updates 3 times a month – no need to crawl it more than once or twice a day. TechCrunch updates many times a day; it’s probably a good idea to crawl it way more often. I don’t have a formula, but you can come up with one that ends up crawling different sites with periods between 2 minutes and 1 day.

Third, don’t “scrape” the content if a better protocol is supported. Many content websites have RSS – use that instead of the HTML of the page. If not, make use of sitemaps. If the WebSub protocol gains traction, you can avoid the crawling/scraping entirely and get notified on new content.

Finally, make sure your crawler/scraper is identifiable by the UserAgent. You can supply your service name or web address in it to make it easier for website owners to find you and complain in case you’ve misconfigured something.

I guess it makes sense to see if using a service like, ScrapingHub, WrapAPI or GetData makes sense for your usecase, instead of reinventing the wheel.

No matter what your use case or approach is, please make sure you don’t put unnecessary pressure on others’ websites.

The post Fix Your Crawler appeared first on Bozho's tech blog.

TEDx: Гражданската активност като инвестиция

Post Syndicated from Bozho original

Бях поканен на TEDxVarna през есента и реших да превърна тази публикация за гражданската активност като инвестиция в презентация/лекция/talk (коя е най-подходящата дума?).

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

Ето видеото:

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

Как да допуснем услуги като Uber? [законопроект]

Post Syndicated from Bozho original

Съдът в Люксембург реши, че Uber е транспортна компания и предоставя таксиметрови услуги. Това е проблем не само за Uber, а за всички по-съвременни начини да предоставяш транспортна услуга, в това число децентрализирани варианти (например чрез блокчейн, въпреки целия ми скептицизъм към публичните такива).

За да бъдат допустими на пазара тези бизнес модели – дали Uber, дали Lyft, дали дори TaxiMe и TaxiStars, към които таксиметровите компании проявяват недоверие и се оптиват да ги изтикат за сметка на свои приложения, трябва законодателството да го позволява. Докато преди това решение Uber оперираше в (според тях) сива зона на нерегулиран бизнес, вече е ясно, че това не е така. И макар Uber да е най-популярният пример, те не са най-светлият такъв – компанията е на загуба и съвсем не е „цвете за мирисане“. Така че всичко недолу не би следвало да се разглежда като „как да узаконим Uber“, а как да не ограничаваме транспорта в градовете до „жълти коли с табелки, светлинки и таксиметрови апарати“.

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

Поради всичко това реших да напиша законопроект за изменение и допълнение на Закона за автомобилните превози. Докато пишех черновата, видях, че Естония вече е направила нещо такова, с доста сходен подход. Основните цели са:

  • Разграничаване на такситата, които можеш да си вземеш на улицата от тези, които можеш да вземеш единствено чрез диспечерска система (дали мобилно приложение, дали по друг начин, няма значение)
  • Допускане на измерване на разстоянието и съответно отчитането пред НАП със средства, различни от таксиметров апарат (например GPS + система, интегрирана с тази на НАП, както са направили в Естония преди време)
  • Улекотяване на регистрационния режим чрез премахване на разрешението от общината – общините, в които оперира даден автомобил се вписват от превозвача в регистъра на Изпълнителна агенция „Автомобилна администрация“, откъдето се черпи информация и за дължимия местен данък.
  • Запазване на данъка за таксиметрови превози към общините
  • Запазване на изискванията за техническа изправност, възраст на автомобилите, психическа годност и липса на присъди на водачите
  • Спазване на принципите на елекетронното управление – извличане на данните за автомобилите от регистъра на КАТ, позволяване на подаване на заявления по електронен път, включително автоматизирано, така че превозвачите да могат да интегрират вътрешните си системи за управление на автопарка с централния регистър. Премахване на задължението от носене на документи от страна на таксиметровите шофьори (като удостоверения) и проверката ми по електронен път
  • Премахване на централизираните изпити и обучения и заменянето им с обучителни материали (де факто прехъвлрне на отговорноста за обучение на шофьорите на превозвачите, които така или иначе имат интерес шофьорите им да не са неадекватни)
  • Премахване на възможността общината да определя размера на пазара и да разпределя участниците в него

Последните две точки са пожелателни, но според мен принципно важни. Ето и самият текст, с мотиви към всеки параграф:

Закон за изменение и допълнение на Закона за автомобилните превози

§1. В чл. 12а се правят следните изменения и допълнения:
1. В ал. 1, т.5 се изменя както следва: „Данни за моторните превозни средства, с които превозвачът извършва превозите:
а) регистрационен номер
б) дали автомобилът ще извършва таксиметров превоз единствено при повикване чрез диспечерска система
в) общините, в които моторното превозно средство ще извършва превози
2. Ал. 2 се отменя;
3. Създава се нова ал. 6: „(6) Заявления за вписване и за промяна на обстоятелства в регистъра, могат да се подават по автоматизирано и по електронен път по реда на Закона за електронното управление“
4. Създава се нова ал. 7: „(7) Обстоятелства за регистрираните автомобили, определени с наредбата по ал. 5, се извличат автоматично на база на регистрационния номер от националния регистър на пътните превозни средства по реда на Закона за електронното управление“
5. Създава се нова ал. 8: „(8) Изпълнителна агенция „Автомобилна администрация“ извъшва автоматизирани проверки за платен данък за таксиметров превоз на пътници и заличава вписаните в регистъра моторни превозни средства, за които данъкът не е платен за съответната година“
6. Създава се нова ал. 9: „(9) Изискванията към външния вид на автомобилите, които са регистрирани за извършване на таксиметров превоз единствено при повикване чрез диспечерска система могат да са различни от тези за останалите автомобили“
7. Създава се нова ал. 10: „(10) Автомобилите, които са регистрирани за извършване на таксиметров превоз единствено при повикване чрез диспечерска система, нямат право да престояват на местата, обозначени за престояване на таксиметрови автомобили“

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

§2. В чл. 24 се правят следните изменения и допълнения:
1. в ал. 1 след думите „електронен таксиметров апарат с фискална памет“ се добавят думите „или по други начини, позволяващи точно измерване на разстояние и отчитане пред данъчната администрация“, а думите „след издаване на разшрение за таксиметров превоз на пътници“ се заменят с думите „след вписване в регистрите по чл. 12, ал. 2 и по ал. 3, т.5“.
2. в ал. 3, т.5 изменя така: „Вписан е в регистър на водачи, извършващи таксиметров превоз, воден от председателя на Изпълнителна агенция „Автомобилна администрация“
3. ал. 4 се изменя така: „Ръководителят на съответното регионално звено на Изпълнителна агенция „Автомобилна администрация“ вписва лицата, отговарящи на изискванията по ал. 3, т. 1-4 и е декларирало, че се е запознало с обучителна информация, определена с наредбата по чл. 12а, ал. 5. Вписването се подновява на всеки 5 години по заявление на водача.
4. ал. 5 се отменя.
5. ал. 6 се изменя така: „Редът за вписването и подновяването на вписването в регистъра на водачите, извършващи таксиметров превоз, и за доказване на съответствието с изискванията по ал. 3, т. 1-4 се определя с наредбата по чл. 12а, ал. 5., като обстоятелствата, необходими за доказване на изискванията, се събират по служебен път“
6. в ал. 17 думите „отнема със заповед удостоверението на водач на лек таксиметров автомобил“ се заменят с думите „заличава вписването на водач, извършващ таксиметрови превоз“

Мотиви: Носенето на удостоверение е излишно, при положение, че контролиращите органи имат електронен достъп в реално време до регистъра. Поради тази причина изискването за удостоверение се заменя с наличие на вписване в регистъра.
Централизираните обучения не са добър механизъм за информираност на шофьорите (което е видно на практика), но създават административна тежест. Обученията и изпитите се заменят с деклариране (възможно по електронен път) от страна на водача, че се е запознал с обучителните материали. Тези материали могат да бъдат текстови или видео-уроци.
Чрез въвеждане на електронни услуги, водачите ще могат отдалечено и лесно да заявяват вписване в регистъра.
Въвежда се възможност за използване на алтернативни технологии на таксиметровия апарат с фискална памет, като например GPS устройства. С наредба ще бъдат определени условията за интегриране на отчетеното от тези устройства разстояние и съответна цена с данъчната администрация.

§3. В чл. 24а се правят следните изменения и допълнения:
1. ал. 1 се изменя така: „Водач, вписан в регистъра на водачи, извършващи таксиметров превоз, имат право да извършват такъв с всеки автомобил, вписан в регистъра по чл. 12, ал. 2 в рамките на общините, за които е валидно вписването“
2. ал. 2-9 се отменят
3. ал. 10 се изменя така: „Административните органи нямат право да определят ограничения на броя таксиметрови автомобили, опериращи на територията на дадена община“
4. ал. 11 се изменяе така: „Общинските съвети могат да определят минимални и максимални цени за таксиметров превоз на пътници за един километър пробег и за една минута престой по съответната тарифа, валидни за територията на съответната община“

Мотиви: допълнителните административни процедури извън регистрацията на превозвача и на водача са излишна административна тежест. Контролът на таксиметровия пазар от страна на общинския съвет, в т.ч. броя автомобили и тяхното разпределение между превозвачи е потенциален източник на корупция и пречи на конкуренцията.
Чрез регистъра по чл. 12, ал. 2 се събира информация в коя община оперират таксиметровите автомобили. Допуска се един автомобил да оперира в повече от една община, което е приложимо например в курортните комплекси.

§4. В чл. 24б след думите „таксиметровите апарати“ се добавят думите „или другите допустими технологични средства“

Мотиви: с наредба се определят и условията за използване и отчитане на други технологични средства, например GPS устройства.

§5. В чл. 95, се правят следните допълнения:
1. В ал. 1 след думите „таксиметров апарат“ се добавят думите „или друго допустимо технологично средство за отчитане на разстояние“
2. В ал. 2 се създава нова т.3: „3. извършва таксиметрови услуги в община, за която автомобилът, който управлява, не е регистриран в регистъра по чл. 12, ал 2“
§6. В чл. 96, ал. 4 след думите „таксиметров апарат“ се добавят думите „или друго допустимо технологично средство за отчитане на разстояние“

Разбира се, по-сложната част ще бъде коригирането на наредбите след това, включително намирането на начин за признаване на GPS координатите – ясно е, че както такситата имат „помпички“, така и GPS-ите на телефоните могат да бъдат „лъгани“.

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

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

Post Syndicated from Bozho original

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

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

Промените правят общо взето едно нещо: разрешава се строителството на ски писти и съоръжения в т.нар. „зона за строителство“ и „зона за туризъм“, които са 0,6%+2,2% от територията на парка. Строителството става само след екологична оценка (или поне така пише; дали такава няма да бъде правена проформа е друг въпрос)

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

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

Дали това обаче не е хитър начин да се скрие нещо – не знам. Според мен таблицата може да се прецизира и 9-ти ред да се разбие допълнително.

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

Тук трябва да се добави и решение на ВАС (Решение № 7214 от 2.10.2001), че ски зоната включва „съоръжения за обслужване на посетители“. Решението е спорно, обаче, тъй като приема, че законът допуска строеж на спортни и други съоръжения, но законът предвижда само техния ремонт. Което тълкуване пък се потвърждава от решение на ВАС по друг казус (№6883 от 09.06.2008 г. на ВАС по адм. д. № 4543 / 2008).

Та, в заключение:
– Зона IIa няма как да е допустима за строителство на писти и лифтове, а ако такова е било намерението, то не е било реализирано, тъй като в текста липсва.
– Измененият план противоречи на чл. 21 от Закона за защитените територии, тъй като позволява строителство на съоръжения, които законът не допуска.

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

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

Така че протестът е обоснован и той е протест както за Пирин, така и за законност.

(Заб.: сега навлизам в темата с Пирин, така че моля коригирайте грешни допускания и заключения, ако видите такива.)

OWASP Dependency Check Maven Plugin – a Must-Have

Post Syndicated from Bozho original

I have to admit with a high degree of shame that I didn’t know about the OWASP dependency check maven plugin. And seems to have been around since 2013. And apparently a thousand projects on GitHub are using it already.

In the past I’ve gone manually through dependencies to check them against vulnerability databases, or in many cases I was just blissfully ignorant about any vulnerabilities that my dependencies had.

The purpose of this post is just that – to recommend the OWASP dependency check maven plugin as a must-have in practically every maven project. (There are dependency-check tools for other build systems as well).

When you add the plugin it generates a report. Initially you can go and manually upgrade the problematic dependencies (I upgraded two of those in my current project), or suppress the false positives (e.g. the cassandra library is marked as vulnerable, whereas the actual vulnerability is that Cassandra binds an unauthenticated RMI endpoint, which I’ve addressed via my stack setup, so the library isn’t an issue).

Then you can configure a threshold for vulnerabilities and fail the build if new ones appear – either by you adding a vulnerable dependency, or in case a vulnerability is discovered in an existing dependency.

All of that is shown in the examples page and is pretty straightforward. I’d suggest adding the plugin immediately, it’s a must-have:


Now, checking dependencies for vulnerabilities is just one small aspect of having your software secure and it shouldn’t give you a false sense of security (a sort-of “I have my dependencies checked, therefore my system is secure” fallacy). But it’s an important aspect. And having that check automated is a huge gain.

The post OWASP Dependency Check Maven Plugin – a Must-Have appeared first on Bozho's tech blog.