All posts by Bozho

Нюансирано за Асандж

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

Арестуваха Джулиан Асандж.

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

За други е герой на свободното слово, който е разобличил американските власти нееднократно.

За първите той е прислужник на Кремъл, който използва свободата на словото като претекст да атакува Америка.

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

Реално… е по-сложно. Да, изтичането на класифицирана информация винаги крие рискове, ако не се прави внимателно, да, особено в последните години WikiLeaks и Кремъл работеха ръка за ръка, да, whistleblowers трябва да имат инструмент, с който да правят публично достояние силно спорни практики, като напр. Prism, и да, WikiLeaks имаше дисциплиниращ ефект.

Трябва ли обществото да знае всичко? По-скоро не. Концепцията за „класифицирана информация“ същество по обективни причини. Но определено има случаи, в които обществото трябва да знае за дадена класифицирана информация. Трябваше ли да знаем за това как американски войници застрелват цивилни и репортери на Ройтерс в Ирак, знаейки много добре, че не представляват опасност? Трябваше ли да знаем, че американското правителство е изградило сложна система за следене на всичко, което правим онлайн? Трябваше ли да знаем за писмата на Сурков (висшестоящ сътрудник в Кремъл), според които Русия има стратегическа цел да дестабилизира Украйна? Според мен и в трите случая, а и в много други – да. Неслучайно тези разкрития излязоха и през реномирани издания като The New York Times и The Guardian.

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

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

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

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

Command-line SQL Client for IBM i 7.x (AS/400)

Post Syndicated from Bozho original https://techblog.bozho.net/command-line-sql-client-for-ibm-i-7-x-as-400/

In the category of “niche blogposts”, this is probably the “nichest”. But it might be useful, so I’ll share it.

Recently I had to interface an IBM i system (think “mainframe”, though not exactly) from a command-line-only Linux environment. The interesting part is that you can access the IBM i files through SQL syntax, as they are tabular in nature. However, I failed to find a proper tool for that. There are UI tools by IBM but they don’t work in a headless environment.

So I decided to write my own simple tool – a command line SQL client for IBM i 7.x. It relies on an IBM-provided library (which, by the way, fails in some cases in headless environments as well, as it tries to prompt for certain data using awt/swing). The tool can be used after building it with maven and by simply executing SQL queries after connecting:

java -jar as400-sql-client.jar <connectionString> <username> <password>

It can be can be fond here. Apart from being useful in navigating the IBM system, it relies in the jline project which allows you to create rich command line tools that support autocomplete, history, coloring, etc.

I hope that nobody will need this tool, but in the rare case that someone does need it, I hope to save them hours of struggle.

The post Command-line SQL Client for IBM i 7.x (AS/400) appeared first on Bozho's tech blog.

Грешната посока на НАП с Наредба Н-18

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

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

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

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

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

Друг голям проблем в наредбата е честотата на промените в нея – за последните 2 години има 6 проекта за промени, (тук, тук, тук, тук, тук и тук). При такава динамика на нормативната уредба, бизнесът трябва да има хора на щат, които само да следят измененията в наредбата и да реализират техните изисквания.

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

Т.е. проблемите са сложност, непредсказуемост, висока цена за бизнеса, липса на адекватна оценка от страна на НАП.

А каква е целта? Целта е събиране на пари в бюджета, като оценката, която съм чувал (но не можах да намеря в мотивите) е 300 милиона на година.

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

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

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

Посоката трябва да бъде към опростяване на нормативната уредба и опростяване на инфраструктурата. И ето няколко предложения за правилна посока:

  • Отмяна на наредбата (която е от 2006-та) и създаването на изцяло нова такава, по-кратка, по-ясна и съобразена с реалностите на 2019-та.
  • Отпадане на задължението за касови апарати. През 2006-та връзка в реално време с НАП е била немислима, поради което фискалната памет е била начинът за сигурно съхранение на данни за продажбите (уж) без да може да бъде манипулирана. Това изискване вече няма смисъл, тъй като продажбите могат и се предават в реално време към НАП. Разбира се, всеки може да избере да си купи касов апарат, който покрива изискванията за връзка с НАП без да се налага да си купуваш софтуер и да се учиш на него – приложимо за малки магазинчета и кафенета, например. Но задължението да имаш касов апарат трябва да отпадне. Бележки могат да се издават от произволно печатащо устройство, стига да отговарят на базови изисквания за съдържанието им.
  • Връзка с НАП в реално време – за всяка продажба НАП може да издава уникален номер, който да се изписва на бележката. Така НАП ще получава данните за всяка продажба и никой няма да има право да издава бележка, ако не е получил номер от НАП. Освен ако няма проблем с връзката, в който случай бележката може да бъде издадена с локално генериран номер (UUID напр.), който впоследствие да се изпрати към НАП, при възстановяване на връзката (или на падналите сървъри). Такава разпоредба обхваща всички възможни сценарии на продажба, не изисква слагане на касови апарати в дейта-центрове, интеграции на онлайн магазини, и др. Има места, където връзка в реално време не е възможна (напр. в планината). Там фискалните устройства са подходящ заместител.
  • Отпадане на задължителните касови бележки. В холандските супермаркети винаги ме питаха дали искам касов бон. Защото няма нужда да хабим хартия и мастило, ако не ми трябва, при положение, че има връзка с НАП в реално време.
  • Електронни касови бележки – добра идея е да може бележката да бъде получена в електронен вид директно на смартфона на клиента (напр. чрез NFC).
  • Приложение за следене на разходите – при всичко гореизброено, остава проблемът, че някои търговци не пускат продажбата към НАП (в момента – не пускат на касовия апарат). Контролът на това най-лесно се осъществява от гражданите, които пазаруват. Те биха имали стимул да сканират QR кодове от касовите бележки, ако това им позволяваше да си следят разходите. В момента приложенията за целта разчитат на ръчно въвеждане и по-рядко на сканиране на бележки (аз не съм виждал такова, което да работи на кирилица, обаче). Ако QR кодът дава достатъчна информация за съдържанието на бележката, и в същото време изпраща номерът ѝ и номера на търговеца за проверка в НАП, това би било ефективен начин за намаляване на криенето на продажби. Това не изключва проверките от НАП, разбира се. И със сигурност приложението трябва да е така направено, че да НЕ изпраща на НАП данни за това кой клиент какво пазарува. Със сигурност не бих искал НАП да знае това за всеки. В този смисъл, приложението може и да не е направено от НАП, а от външен доставчик. НАП единствено трябва да определи формата на QR кода (съответно – на електронната „бележка“) и да предостави програмен интерфейс за проверка на номера на бележката.
  • Достъп до банкови сметки по желание на търговеца – когато става дума за онлайн магазини, връзката в реално време с НАП пак би значела допълнителен разход. Опция, която се ползва в Естония, доколкото знам, е търговецът да даде достъп на НАП до банковата сметка, по която получава онлайн плащанията (само до нея, не до всички сметки на фирмата). Така НАП ще има цялата нужна информация без изобщо да се налага търговецът да докладва продажби. Ако няма други приходи, това ще спести и подаването на декларации. PSD2 (втората директива за платежни услуги) така или иначе задължава банките да имат програмен интерфейс за достъп до сметки на клиенти, просто НАП ще трябва да получават такъв и да интегрират системите си. Тази стъпка е доброволна, разбира се – за улеснение на страните. Ако някой бизнес не желае да дава достъп до сметката си, НАП не може да го задължи.

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

Audit Trail in IT Context

Post Syndicated from Bozho original https://techblog.bozho.net/audit-trail-in-it-context/

An audit trail (or audit log) is something both intuitive and misleading at the same time. There are many definitions of an audit trail, and all of them give you an idea of what it is about:

A system that traces the detailed transactions relating to any item in an accounting record.

A record of the changes that have been made to a database or file.

An audit trail (also called audit log) is a security-relevant chronological record, set of records, and/or destination and source of records that provide documentary evidence of the sequence of activities that have affected at any time a specific operation, procedure, or event.

An audit trail is a step-by-step record by which accounting or trade data can be traced to its source

The definitions are clear, but they rarely give enough detail on how they apply to a particular IT setup. The Wikipedia article is pretty informative, but I prefer referring to the NIST document about audit trail. This relatively short document from more than 20 years ago covers many the necessary details.

I won’t repeat the NIST document, but I’d like to focus on the practical aspects of an audit trail in order to answer the question in the title – what is an audit trail? In the context of a typical IT setup, the audit trail includes all or some of the following:

  • Application-specific audit trail – ideally, each application records business-relevant events. They may be logged in text files or in separate database tables. They allow reconstructing the history much better than the arbitrary noisy logging that is usually in place
  • Application logs – this is a broader category as it includes logs that are not necessarily part of the audit trail (e.g. debug messages, exception stacktraces). Nevertheless, they may be useful, especially in case there is no dedicated application-specific audit trail functionality
  • Database logs – whether it is logged queries, change data capture or change tracking functionality, or some native audit trail functionality
  • Operating system logs – for Linux that would include the /var/log/audit/audit.log (or similar files), /var/log/auth.log. For Windows it would include the Windows Event logs for the Security and System groups.
  • Access logs – access logs for web servers can be part of the audit trail especially for internal systems where a source IP address can more easily be mapped to particular users.
  • Network logs – network equipment (routers, firewalls) generate a lot of data that may be seen as part of the audit trail (although it may be very noisy)

All of these events can (and should) be collected in a central place where they can be searched, correlated and analyzed.

Ideally, an audit trail event has an actor, an action, details/payload and optionally an entity (type + id) which is being accessed or modified. Having this information in a structured form allows for better analysis and forensics later.

Once the audit trails is collected, it has two other very important properties:

  • Availability – is the audit trail available at all times, and how far back in time can it be accessed (also referred to as “retention”). Typically application, system and network logs are kept for shorter periods of time (1 to 3 months), which is far from ideal for an audit trail. Many standards and regulation require higher retention periods of up to 2 years
  • Integritydata integrity is too often ignored. But if you can’t prove the integrity of your logs, both internally and to third parties (auditors, courts), then they are of no use.

Many organizations understand that the integrity of their audit trail is important only after a security incident takes place and they realize they cannot rely on their audit logs. It is better to protect the audit trail before something bad happens. And not just for some abstract reasons like “best practices” or “improved security”. A secure audit trail allows organizations to:

  • Identify that something wrong has happened. If the audit trail is not protected, a malicious actor can make it seem like nothing anomalous has taken place
  • Prove what happened and who did it. Digital forensics is important for large organizations. Especially in cases where lawsuits are involved.
  • Reconstruct the original data. The audit trail is not a replacement for a full backup, but it can allow you to reconstruct the data that was modified and the time it was modified, so that either you know which backup to use, or to avoid restoring form the backup altogether by just relying on the data provided in the audit trail.
  • Be compliant. Because of all the reasons stated above, many standards and regulations require a secure audit trail. Simple logs are usually not compliant, even though auditors may turn a blind eye.

The audit trail is an important concept, and has very practical implications. It is a widely researched topic, but in practice many IT setups lack sufficient audit trail capabilities. Partly because the risks are not immediately obvious, and partly because it is a technically challenging task.

(The article is originally published on our corporate blog, but I think it can be interesting here as well, so I copied most of it, leaving out the corporate references and calls to action)

The post Audit Trail in IT Context appeared first on Bozho's tech blog.

Пет политически клишета

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

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

  • Реформа. В общия случай значи „направихме работна група“ или „свикахме съвет“, което значи, че ако някой пита какво се случва, да може да се каже „работим, но темата е сложна“. Дори в добрия случай, „реформа“ значи „да променим няколко закона и няколко наредби“. В краен случай дори значи прокарване на нов закон. И често свършват дотук мераците за реформа, отчели сме, че нещо се е променило „в Държавен вестник“, а оттук нататък ако нищо не стане – администрацията е виновна. Ако една реформа наистина трябва да бъде такава, е нужно да бъде подкрепена както с нормативни изменения (без да го пише в закона не става), така и с финансиране, оперативни планове, хора, които да знаят за какво става дума и с политическа воля (вж. следващия абзац). Например реформа в електронното управление включва както промяна на някои закони, така и финансиране за ключови проекти, грамотни ръководители на процеса и желание да се налага реализирането на всички тези проекти въпреки пречките пред тях.
  • Политическа воля. Митичната политическа воля, която се материализира на някое заседание в някоя парламентарна комисия и после също толкова бързо изчезва. Докато не се наложи да изгрее от „кабинет 1“ в Министерски съвет под формата на „аз съм им казал“. Политическа воля има в редките случаи, в които повечко хора имат поне малка представа за какво става дума и са готови дори да свършат някаква работа, за да се случи нещото. Това нещо може да бъде реформа (вж. горната точка), проект (особено енергиен) и какво ли още не. На практика политическата воля се изявява като приносителят ѝ мести всички камъни, които се изсипват на пътя на някакво (уж) добро решение. Например, ако имаше политическа воля за електронно здравеопазване, то щеше вече да се е случило.
  • Консенсус. В редките случаи, когато мнозинството от хората, участващи в един дебат всъщност имат идея за какво говорят, може да се постигне съгласие за пътя напред, със съответните отстъпки от всяка от страните. Тъй като това е много рядък случай, консенсусът на практика значи, че достатъчно много хора са уцелили случайно припокриване на неразбирането си по дадената тема и са си стиснали ръцете. Чудесен пример беше парламентарният консенсус за изменението на Търговския закон, с което забраниха продаване на дружествени дялове при неплатени заплати и осигуровки. Пълно съгласие, пляскане с ръце и дружни танци, обаче за жалост никой не разбираше от темата и това създаде хаос за месеци напред. Консенсусът може и да е хубав, но по-често трябва да ни притеснява. Другият вариант е всички участници да знаят, че нещо трябва да се направи (я щото от Брюксел го искат, я защото е имало референдум, я защото е гореща тема), обаче никак не искат да правят нищо. И затова с дълги спорове не по същество се стига до „консенсус“. Ако може консенсусът да е в преходни и заключителни разпоредби, за да падне по-лесно, когато се промени „политическата ситуация“.
  • Волята на суверена. Или както беше казал някой – ако народът каже да ходим със зелени гащи, ще ходим със зелени гащи. На мен зеленото ми е любим цвят и нямам проблем с точно тази воля на суверена, само не ми се мисли далтонистите какво ще правят. Все пак се надявам наказанието да е административна санкция, ама де да знаеш, народът може и да реши да криминализира ходенето с червени гащи. Та тази воля кристализира на избори и референдуми. Особено на референдуми, и там „суверенът“ често значи „53-54% от тия, дето все пак са решили да гласуват“. Та, в общия случай, суверенът е едни 25-30 процента, които обаче са „казали“. Или са избрали някой и той сега има мнозинство и върви гордо и отваря врати, въоръжен с волята на суверена. Ако го питаме суверена дали е окей някой така си присвоява волята му, той няма да се съгласи. Ама затова няма да го питаме. А сериозно – волята на мнозинството е важна и с нея не бива да се злоупотребява. Тя не е абсолютна и константна, защото информацията и представите на хората се менят във времето. Тя е абсолютно нужна, за да се случват важни неща – например ако мнозинството не беше съгласно да влезем в ЕС, влизането в ЕС щеше да е много проблемен ход, който да „избухне“ в обществото доста бързо. За щастие, макар да нямаше референдум, нагласите (изразени и чрез гласуване за проевропейски послания) бяха ясни.
  • Стабилност. Стабилността значи или нищо да не се случва, или то да се случва предвидимо бавно. Защото пък ако нещо вземе, че се случи, то може да се окаже неприятно. Изненадващо. Или просто различно. Затова хубава си е стабилността – може нещата да не стават добре, ама поне стават както сме си свикнали. Текат едни поръчки, едни избори, тук-таме сменят някой министър, от време на време опозицията вземе, че дойде на власт. Ама толкова. Не че политическата стабилност не е важна – важна е, разбира се. Всяка среда, в която има остри противопоставяния и липса на перспектива какво ще стане след 6 месеца гони хора, отблъсква инвеститори, пречи на спокойния живот. Но ние не сме в такава турбулентна среда и стабилността е по-скоро заспиване, отколкото устойчиво развитие, каквото може да бъде.

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

Задължителни пръстови отпечатъци в личните карти в ЕС?

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

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

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

  • Какво толкова, те и сега МВР събират отпечатъци – МВР събират отпечатъци само за нужните на международните паспорти. Или поне така е по закон. Ако са ви взели отпечатъци при издаване на лична карта, това е превратно тълкуване на Закона за българските лични документи. Според действащите текстове на закона, за новите лични карти, които ще имат чип и ще позволяват записване на такива данни, ще се снемат отпечатъци само при изрично желание на гражданите. Това беше дълго обсъждан текст, в чието писане съм участвал. Причината за opt-in модела е, че няма особена полза от ICAO стандарта за електронни документи за пътуване що се отнася до лични карти, тъй като почти няма терминали за автоматично преминаване (e-gates), които да поддържат формат „лична карта“. А рисковете са немалки. Европейската комисия не е отчела този нюанс, между другото, и е писала, че България ще има задължителни отпечатъци в личните карти. Може и колегите им от МВР да с ги подвели. Щото кой да чете закона, пък и мотивите, с които е бил внесен.
  • Какво толкова ще стане, като ни запишат отпечатъците? – това е дълга техническа тема, но накратко – отпечатъците могат да изтекат. Дали през централизираната база данни, за която трябва да се грижи държавата, или през отделните носители. ICAO стандартът предвижда четене на отпечатъци без въвеждане на парола/PIN (за целите на граничните проверки), което води със себе си сложна и „чуплива“ система, в която участва всички държави, издаващи документи по този стандарт. Лошото е, че през годините стандартът е имал множество проблеми със сигурността, които са били коригирани, но някои от тях остават и на теория (надявам се да не видим скоро и на практика) някой може да ви прочете отпечатъците от личната карта в джоба както си стоите в метрото. Не е тривиално, поради ред причини, но е възможно. След това може да направи фалшив отпечатък, с който да излъже сензора на телефона ви, и да получи достъп до важни неща като имейл или дори банкова сметка. Как така фалшив отпечатък? Напълно изпълнимо е, както е показано тук, а сензорите макар да се подобряват, не мисля, че някога ще предотвратят тази възможност напълно. Има домашни брави, които се отварят с отпечатък. Има контролирани зони в офиси и предприятия, които се отварят отпечатък. Всички те стават по-уязвими.
  • Нали няма да има централна база данни с отпечатъци? Регламентът не предвижда задължително такава, но оставя на държавите членки да решат. Нашата вече е решила, тъй като съхранява в база данни отпечатъците, които е снела за паспортите ни. Дали това нарушава гражданските свободи – по-скоро да. Особено когато е ненужно и необосновано.
  • Всеки може да ни снеме отпечатъка от чаша, ако иска, каква е разликата? Разликата е в качеството на снетия отпечатък. В личните документи той е с висока резолюция и е пълен. Отпечатък от чаша няма да е достатъчен за качествен фалшив отпечатък, но този от личната карта ще е предостатъчеб.
  • Биометричната идентификация не е ли бъдещето? Надявам се не. Има много материали по темата, но заключението е, че ако биометричната идентификация е единственият компонент, то това не е достатъчно сигурно. Фундаменталният проблем е, че няма механизъм за промяна. Докато можете да си смените паролата, частния ключ или да си рестартирате OTP token устройсвото, отпечатъкът ви не подлежи на промяна – веднъж изтече ли, няма връщане.
  • Европейсеката Комисия не е ли оценила аспектите на информационната сигурност? Не, не е. В първоначалната оценка на въздейсетвието липсва анализ на ифнромационната сигурност. След като в рамките на вътрешното обсъждане получават коментар, че трябва да има такава, добавят едни 5-6 точки, които са непълни и несвързани и изобщо не са убедителни. Още повече, че ICAO след своя анализ правят отпечатъците в паспортите опционални. Преди години, когато обсъждахме въвеждането на стандарта в българските лични документи, изпратихме писмо до Европейската комисия и до ICAO с въпрос дали сигурността на стандарта е достатъчно висока. От ЕК отговориха с не особено адекватното „ами нямали сме проблеми досега“, а от ICAO отговориха с въпрос – може ли да предложите експерт за работна група. Стандартът е типичен „дизайн от комисия“ и има много потенциални проблеми. Надявам се те да бъдат изчистени някои от тези проблеми, а ЕК да не позволи обратно-съвместими документи (т.е. поддържащи „счупени“ версии на стандарта), но остава фундаменталният архитектурен проблем, който не знам има ли решение.
  • Какво мислят другите държави за биометричните документи? Не всички са щастливи. Когато преди години ЕС задължава всички паспорти да имат отпечатъци, Холандия пита съда трябва и личните карти да са с отпечатъци и съдът казва „не, не трябва“. Решението на съда е интересно за четене и с оглед настоящия Регламент, но като резултат Холандия спира да слага отпечатъци в личните си карти.
  • Това не е ли важна мярка за борба с тероризма и нелегалната миграция? Не, отпечатъците не помагат с нищо, в сравнение със снимката и лицевото разпознаване на границата. Няма сценарий, в който отпечатъкът да е решаващ. (А снимката не крие такива рискове
  • Какви са тогава аргументите „за“? И аз това се чудех. В оценката на въздействието Комисията описва някои притеснения и дори казва, че марката може да е непропорционална. Разбрах, че аргумент на държавите-членки е бил, че човек може да донесе фалшифицирана снимка, с която да се „лъжат“ алгоритмите за лицево разпознаване. На въпрос „защо не правите снимката при подаване на документите за лична карта“, отговорът е бил, че е много скъпо. Да, най-бедната държава в ЕС (България) го е направила – във всяка районно управление има цялата техника, необходима за издаване на документа – но за останалите щяло да е скъпо. Освен това как правене на снимка е скъпо, а снемане на отпечатъци – не е (качествените четци не са толкова евтини).
  • Противопоставянето на отпечатъците не пречи ли на електронното управление? Не, двете нямат общо. Отпечатъците са само за граничен контрол и нищо друго – вкъщи няма как да имате устройство, което да прочете отпечатъците от картата, съответно чрез тях да се идентифицирате пред държавен орган онлайн.

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

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

7 Questions To Ask Yourself About Your Code

Post Syndicated from Bozho original https://techblog.bozho.net/7-questions-to-ask-yourself-about-your-code/

I was thinking the other days – why writing good code is so hard? Why the industry still hasn’t got to producing quality software, despite years of efforts, best practices, methodologies, tools. And the answer to those questions is anything but simple. It involves economic incentives, market realities, deadlines, formal education, industry standards, insufficient number of developers on the market, etc. etc.

As an organization, in order to produce quality software, you have to do a lot. Setup processes, get your recruitment right, be able to charge the overhead of quality to your customers, and actually care about that.

But even with all the measures taken, you can’t guarantee quality code. First, because that’s subjective, but second, because it always comes down to the individual developers. And not simply whether they are capable of writing quality software, but also whether they are actually doing it.

And as a developer, you may fit the process and still produce mediocre code. This is why my thoughts took me to the code from the eyes of the developer, but in the context of software as a whole. Tools can automatically catch code styles issues, cyclomatic complexity, large methods, too many method parameters, circular dependencies, etc. etc. But even if you cover those, you are still not guaranteed to have produced quality software.

So I came up with seven questions that we as developers should ask ourselves each time we commit code.

  1. Is it correct? – does the code implement the specification. If there is no clear specification, did you do a sufficient effort to find out the expected behaviour. And is that behaviour tested somehow – by automated tests preferably, or at least by manual testing,.
  2. Is it complete? – does it take care of all the edge cases, regardless of whether they are defined in the spec or not. Many edge cases are technical (broken connections, insufficient memory, changing interfaces, etc.).
  3. Is it secure? – does it prevent misuse, does it follow best security practices, does it validate its input, does it prevent injections, etc. Is it tested to prove that it is secure against these known attacks. Security is much more than code, but the code itself can introduce a lot of vulnerabilities.
  4. Is it readable and maintainable? – does it allow other people to easily read it, follow it and understand it? Does it have proper comments, describing how a certain piece of code fits into the big picture, does it break down code in small, readable units.
  5. Is it extensible? – does it allow being extended with additional use cases, does it use the appropriate design patterns that allow extensibility, is it parameterizable and configurable, does it allow writing new functionality without breaking old one, does it cover a sufficient percentage of the existing functionality with tests so that changes are not “scary”.
  6. Is it efficient? – does work well under high load, does it care about algorithmic complexity (without being prematurely optimized), does it use batch processing, does it read avoid loading big chunks of data in memory at once, does it make proper use of asynchronous processing.
  7. Is it something to be proud of? – does it represent every good practice that your experience has taught you? Not every piece of code is glorious, as most perform mundane tasks, but is the code something to be proud of or something you’d hope nobody sees? Would you be okay to put it on GitHub?

I think we can internalize those questions. Will asking them constantly make a difference? I think so. Would we magically get quality software If every developer asked themselves these questions about their code? Certainly not. But we’d have better code, when combined with existing tools, processes and practices.

Quality software depends on many factors, but developers are one of the most important ones. Bad software is too often our fault, and by asking ourselves the right questions, we can contribute to good software as well.

The post 7 Questions To Ask Yourself About Your Code appeared first on Bozho's tech blog.

Implicit _target=”blank”

Post Syndicated from Bozho original https://techblog.bozho.net/implicit-_targetblank/

The target="_blank" href attributes has been been the subject of many discussions. When is it right to use it, should we use it at all, is it actually deprecated, is it good user experience, does it break user expectations, etc.

And I have a strange proposal for improving the standard behaviour in browsers – implicit target=_blank" in certain contexts. But let’s try to list when target="_blank" is a good idea:

  • On pages with forms when the user may need additional information in order to fill the form but you don’t want them to leave the form and lose their input
  • On homepage-like websites – e.g. twitter and facebook, where your behaviour is “browsing” and opening a link here and there. It may be applied to things like reddit or hacker news, though it’s currently not implemented that way there
  • In comment/review sections where links are user-provided – this is similar to the previous one, as the default behaviour is browsing through multiple comments and possibly following some of them

The typical argument here is that if a user wants to open a new page, they can do that with either the context manu or ctrl+click. Not many users know that feature, and even fewer are using it. And so many of these pages are confusing, and combined with a sometimes broken back-button it becomes a nightmare.

In some of these cases javascript is used to make things better (and more complicated). In the case of forms, javascript is added to warn people against leaving the page with an unfinished form. Javascript is used to turn certain links to target=”_blank” ones. Some people try to open new tabs with javascript.

So my proposal is to introduce a with the following values for open-links and on-form:

  • open-links="new-tab" – open a link tab for each link on the page or in the current div/section/…
  • open-links="new-window" – same as above, but open a new window (almost never a good idea)
  • open-links="new-tab-on-form" – only open a new tab if there a form on the page (possibly another requirement can be that the form is being partially filled)
  • open-links="new-window-on-form" – same as above, but with a new window
  • open-links="warn-on-form" – open the link in the same tab, but if there’s a partially filled form, warn the user they will lose their input

The default value, I think, should be new-tab-on-form.

It might introduce new complexities and may confuse users further. But I think it’s worth trying to fix this important part of the web rather than leaving each website handle it on their own (or forgetting to handle it).

The post Implicit _target=”blank” appeared first on Bozho's tech blog.

Мантрата „ЕНП“

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

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

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

Но искам да дам друг поглед върху ЕНП – дългосрочният им тренд. От 1999-та досега ЕНП губи подкрепа. По половин процент от 99-та до 2009-та, и 6.5% през 2014. По-интересното е каква е структурата на тази подкрепа. Разбих евродепутатите от последните два избора – 2009 и 2014 на „Източен блок“ и „Западна Европа“ (като Гърция и Кипър са част от „западна Европа“), за да видя как се движи ЕНП в тези два сегмента.

Източният блок има близо 27% от местата в Европейския парламент. Останалите 73% са за западна Европа.

През 2009-та ЕНП има 32.5% от депутатите си от източния блок. През 2014-та този процент расте до 39. ЕНП се превръща в ХДС+източноевропейски Борисовци. (ХДС – немският християндемократически съюз). Германия+Източна Европа правят 65% от депутатите на ЕНП.

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

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

Моят личен избор на европейско политическо семейство е Европейската демократическа партия (която е част от групата на АЛДЕ в парламента в момента, но няма на сметката си греха от приемането на ДПС).

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

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

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

Съмнителни новини

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

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

Забележете, че това не са „фалшиви новини“ – фактологията в тях не е грешна. Непълна е, но не е грешна. Коледният базар в Брюж наистина вече се казва „зимен базар“, а във френския парламент наистина е имало предложение в училищни формуляри да се използва „родител 1“ и „родител 2“.

Но въпреки негрешната фактология, има нещо съмнително в тези новини. Съмнителните неща са три:

  • Защо това е новина? – защо наименованието на коледен базар в Белгия или административни бланки във Франция заслужават място в българските новини? Не е от липса на какво да се каже, тъй като има доста по-значими неща, които се пропускат. Иначе имам и други предложения за новини – това, че лидерът на шотландската партия нарече Тереза Мей лъжкиня в парламента; мерките на немската власт срещу епидемията от морбили; сезирането на конституционния съд на Ямайка дали електронната идентичност е конституционна; изборите в Антигуа и Барбуда през 2018. Да, и тези новини имат малко до никакво значение за България, точно както белгийския коледен базар и френските бланки. Отговорът „защо това е новина“ е именно реакцията, която се очаква да предизвика – реакция, на възмущение. И затвърждаване на тезата за „прогниващия западен свят“. Теза, която се поддържа от пропагандата на Съветския съюз много отдавна и никога не е спирала да се лее от руски сайтове за фалшиви новини. Но вече „цаката“ е намерена и тези новини не са само в конспиративни групи във Фейсбук, в които се споделя как „Швеция легализира кръвосмешението“.
  • Пропуснатите нюанси. Това не е характерно само за този вид новини, но тук е доста ключово. Коледните базари в Брюж, например, се казват „зимни“ от няколко години. И това било така, защото продължават цяла зима. Нещо, което започва от ноември, не върви да е „коледно“. Но новината е представена все едно току-що някой е решил да „клекне“ на мюсюлманите и да се откаже от Християнските традиции (което не е вярно, тъй всички коледни реквизити на един такъв базар са налице). Относно „родител 1“ и „родител 2“ също са пропуснати важни моменти – правителството е внесло друго предложение за маркиране на различните случаи на родители и настойници (в т.ч. от един пол), а депутат е внесла изменение. Правителството дава негативно становище за предложението, а то все още не е окончателно прието, тъй като не е минало през сената. Също така, около година по-рано общината в Париж прави същата промяна в други бланки, или че в Германия бланките са такива отдавна и нищо кой знае какво не е станало, т.е. и това не е новост.
  • Източниците. Такъв тип новини се появяват в местната преса и най-често си остават там, докато някое международно издание (или сайт) не ги подхване и популяризира. В горните два случая това са Breitbart и Russia Today. Russia Today е директно финансирана от Кремъл и редакционната ѝ политика се определя от там. Както отбелязах по-горе, тезата за декадентния запад, който се превръща в Содом и Гомор, не е нова, а консистентно налагана поне откакто аз ползвам съзнателно интернет.

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

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

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

Няколко думи за електронното гласуване на Да, България!

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

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

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

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

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

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

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

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

Друг често задаван въпрос беше как гарантираме, че не са били регистрирани фалшиви профили за гласуване. За съжаление правителството за втора година отлага въвеждането на национална схема за електронна идентификация, в т.ч. с чип в личните карти. Т.е. нямаме правнозначимо средство за електронна идентификация на физически лица, на което да стъпим (ако имаше, то щеше да е базирано на PKI и смарткарти и/или HSM и/или secure storage на по-нови смартфони). Тръгвайки от тази изходна точка, разгледахме четири варианта:

  • използване на КЕП за гласуване. За съжаление твърде малко хора имат квалифициран електронен подпис, а и той не работи с мобилни приложения (в общия случай). Като цяло използването му е доста неудобно и това би било пречка.
  • прикачане на снимка на машинночетимата зона (MRZ) на личната карта – това би работело, но предположихме правилно, че хората са много резервирани към даването на каквито и да било лични данни, без значение колко GDPR-compliant сме. Имахме редица оплаквания и откази за регистрация дори само като искаме последни четири цифри на ЕГН
  • използване на облачен доставчик на eID и/или online enrollment (напр. EvroTrust). Сигурността щеше да е по-висока от тази на сканиране на лична карта, но тъй като всички системи за online enrollment изискват снимка на документ за самоличност (а някои и лицево разпознаване), отказът от регистрация заради ‘твърде много лични данни’ щеше да е масов.
  • настоящият подход с представяне на минимално количество данни и подбиране на случаен принцип и прозвъняване на някои регистрирани с цел проверка за измами.

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

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

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

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

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

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

How to create secure software? Don’t blink! [talk]

Post Syndicated from Bozho original https://techblog.bozho.net/how-to-create-secure-software-dont-blink-talk/

Last week Acronis (famous for their TrueImage) organized a conference in Sofia about cybersecurity for developers and I was invited to give a talk.

It’s always hard to pick a topic for a talk on a developer conference that is not too narrowly focused — if you choose something too high level, you can be uesless to the audience and seen as a “bullshitter”; if you pick something too specific, half of the audience may be bored because it is not their area of work.

So I chose the middle ground — an overview talk with as much specifics as possible in it. I tried to tell interesting stories of security vulnerabilities to illustrate my points. The talk is split in several parts:

  • Purpose of attacks
  • Front-end vulnerabilities (examples and best practices)
  • Back-end vulnerabilities (examples and best practices)
  • Infrastructure vulnerabilities (examples and best practices)
  • Human factor vulnerabilities (examples and best practices)
  • Thoughts on how this fits into the bigger picture of software security

You can watch the 30 minutes video here:

If you would like to download my slides, click here. or view them at SlideShare:

The point is — security is hard and there are a million things to watch for and a million things that can go wrong. You should minimize risk by knowing and following as much best practices as possible. And you should not assume you are secure, as even the best companies make rookie mistakes.

The security mindset, which is partly formalized by secure coding practices, is at the core of having a secure software. Asking yourself constantly “what could go wrong” will make software more secure. It is a whole other topic of how to make all software more secure, not just the ones we are creating, but it is less technical and goes through the topics public policies, financial incentives to invest in security and so on.

For technical people it’s important to know how to make a focused effort to make a system more secure. And to apply what we know, because we may know a lot and postpone it for “some other sprint”.

And as a person from the audience asked me — is not blinking really the way? Of course not, that effort won’t be justified. But if we cover as much of the risks as possible, that will give us some time to blink.

The post How to create secure software? Don’t blink! [talk] appeared first on Bozho's tech blog.

Avoid Lists in Cassandra

Post Syndicated from Bozho original https://techblog.bozho.net/avoid-lists-in-cassandra/

Apache Cassandra is fast and scalable database which over the years became almost as easy to use as a traditional SQL database. At least on the surface.

You an use SQL-like queries, but they have a lot of limitations; you have a schema, but it’s not as flexible to modify it as in a SQL database; you have the same tabular structure with a primary key, but it’s more complicated due to the differentiation between partition key and sorting key. And there are a lot of underlying details that seem irrelevant at first, but are crucial for performance and data consistency, like tombstones, SSTable compaction and so on.

But I want to discuss the “list” column type, as recently we’ve had a very elusive issue with it. We are in the business of guaranteeing data integrity, and that’s why our records are not updated, ever. This is a good fit for Cassandra, as updates are tricky to get right. But on one of our deployments we noticed something strange – very rarely, the hash of the data in a particular entry out of millions would not match upon comparison with the indexed data. Upon investigation, we noticed that a column of type “list” got duplicate values. It was not an issue with the code, because in this particular case the code was always using Collections.singletonList(..)

It appears that Cassandra is trying to be clever and when it sees identical entries in a batch insert, instead of overriding one with the other, it tries to merge them, resulting in a list with duplicate entries. Accounts of the issue are reported here and here.

Now, batches are a difficult topic and one of those things that look straight-forward but aren’t. In most cases, batches are an anti-pattern. There are cases where batches are useful, but it’s more rare than expected. That’s because of the distributed nature of Cassandra. Another complication comes from whether you are using token-aware or toke-unaware client policy, i.e. whether your client knows where each record belongs in order to send the request to it. I won’t go into details about batches, as they are well explained in the two linked articles.

Back to lists – since in our case we don’t have identical records in a batch, the issue was probably manifested because of a network timeout where the client didn’t receive confirmation of the write and re-attempted sending the same statement again. Whether being in a batch or not affects it, I can’t be sure. But it’s probably safer to assume that it might happen with or without a batch. I.e. lists can be merged in unexpected situations.

This is a serious reason for not using lists at all. Additional arguments are given by Walmart

Sets should be preferred to Lists as Sets (and Maps) avoid read-before-write pattern for updates and deletes

And this is just for a small number of items. Using collections for a large number of items (e.g. thousands) is another issue, as you can’t load the items in portions – they are all read at once.

In a Java application, for example, you can easily substitution the List with a Set even if the underlying column is of type List and that would help temporarily avoid the issues – data may still be duplicated in the database, but at least the application will work with unique values. Have in mind though, that ordering is not guaranteed by the Java Set, so if it matters for your logic, make sure you order by some well-defined comparison criteria.

The general advice of “avoid lists” (and “avoid batches”) paints an accurate picture of Cassandra. It looks straightforward to use, but once you get to production, you may realize there were some suboptimal design decisions.

The post Avoid Lists in Cassandra appeared first on Bozho's tech blog.

Борба с фалшиви лекарства по грешния начин

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

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

Става дума за директивата за верифициране на лекарства с цел борба с фалшиви такива, при която всеки производител на лекарства ги вкарва в една база данни, а всяка аптека или болница, която ги (про)дава на краен потребител, ги верифицира в системата преди да ги даде.

Първото двуминутно проучване показа, че директивата е от 2011-та и какво по дяволите са правили всички 8 години, не им е виновен ЕС за това.

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

Та, това на пръв поглед просто за техническа реализация решение, е толкова усложнено, че според мен едвам е заработило и поддръжката му ще бъде ужас. Направили са централен EU Hub, и 28 национални системи, които да се синхронизирт с този hub. Защо това е нужно и защо е задължително? На теория, защото държавите-членки са суверенни и трябва да имат базата си данни. На практика няма нужда. Която държава желае, може да има копие „за четене“ на данните. Така или иначе производителите ги публикуват в централната система. Ако пък идеята е била да се разтовари централната система от заявки за проверка – не звучи като добра идея да създадеш организационно усложнение, за да си спестиш централизираното управление на няколко десетки сървъра.

Българската организация, която въвежда системата си е свършила прилично работата – една от първите държави сме, която въвежда националната система, използвали са одобрен доставчик, провели са кампании, изпращали са писма, отчели са колко са получени и по какви причини. С URL-а не са се справили, де.. nbsbgiqe1.emvs-nbs.eu:8637 не е точно удобен за въвеждане.

Но тук идва фундаменталният проблем – би трябвало една такава система да има интерфейси, базирани на отворени стандарти (или дори да не са стандарти, да са публично-достъпни и утвърдени от ЕК).

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

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

Само че такова няма. Пардон, има едно, но то е от доставчик, който се връзва не към националната система директно, а към своя, от която пък изпраща данните на националните. И иска пари за това, разбира се. 220 лв годишно (за до 1000 лекарства на месец) и 660 лв годишно без ограничения може и да е добра оферта. (Но не съм сигурен има ли български превод). Приложението го няма в play store-a. А, има и един сайт на фирмата-доставчик на националната система, откъдето можели да се правят проверки. verilite.eu .. ако намерите бутон за регистрация, кажете.

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

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

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

Certificate Transparency Verification in Java

Post Syndicated from Bozho original https://techblog.bozho.net/certificate-transparency-verification-in-java/

So I had this naive idea that it would be easy to do certificate transparency verification as part of each request in addition to certificate validity checks (in Java).

With half of the weekend sacrificed, I can attest it’s not that trivial. But what is certificate transparency? In short – it’s a publicly available log of all TLS certificates in the world (which are still called SSL certificates even though SSL is obsolete). You can check if a log is published in that log and if it’s not, then something is suspicious, as CAs have to push all of their issued certificates to the log. There are other use-cases, for example registering for notifications for new certificates for your domains to detect potentially hijacked DNS admin panels or CAs (Facebook offers such a tool for free).

What I wanted to do is the former – make each request from a Java application verify the other side’s certificate in the certificate transparency log. It seems that this is not available out of the box (if it is, I couldn’t find it. In one discussion about JEP 244 it seems that the TLS extension related to certificate transparency was discussed, but I couldn’t find whether it’s supported in the end).

I started by thinking you could simply get the certificate, and check its inclusion in the log by the fingerprint of the certificate. That would’ve been too easy – the logs to allow for checking by hash, however it’s not the fingerprint of a certificate, but instead a signed certificate timestamp – a signature issued by the log prior to inclusion. To quote the CT RFC:

The SCT (signed certificate timestamp) is the log’s promise to incorporate the certificate in the Merkle Tree

A merkle tree is a very cool data structure that allows external actors to be convinced that something is within the log by providing an “inclusion proof” which is much shorter than the whole log (thus saving a lot of bandwidth). In fact the coolness of merkle trees is why I was interested in certificate transparency in the first place (as we use merkle trees in my current log-oriented company)

So, in order to check for inclusion, you have to somehow obtain the SCT. I initially thought it would be possible with the Certificate Transparency Java library, but you can’t. Once you have it, you can use the client to check it in the log, but obtaining it is harder. (Note: for server-side verification it’s fine to query the log via HTTP; browsers, however, use DNS queries in order to preserve the anonymity of users).

Obtaining the SCT can be done in three ways, depending on what the server and/or log and/or CA have chosen to support: the SCT can be included in the certificate, or it can be provided as a TLS extension during the TLS handshake, or can be included in the TLS stapling response, again during the handshake. Unfortunately, the few certificates that I checked didn’t have the SCT stored within them, so I had to go to a lower level and debug the TLS handshake.

I enabled TLS hadnshake verbose output, and lo and behold – there was nothing there. Google does include SCTs as a TLS extension (according to Qualys), but the Java output didn’t say anything about it.

Fortunately (?) Google has released Conscrypt – a Java security provider based Google’s fork of OpenSSL. Things started to get messy…but I went for it, included Conscrypt and registered it as a security provider. I had to make a connection using the Conscrypt TrustManager (initialized with all the trusted certs in the JDK):

KeyStore trustStore = KeyStore.getInstance("JKS");
trustStore.load(new FileInputStream(System.getenv("JAVA_HOME") + "/lib/security/cacerts"), "changeit".toCharArray());
ctx.init(null,new TrustManager[] {new TrustManagerImpl(trustStore, 
    null, null, null, logStore, null, 
    new StrictCTPolicy())}, new SecureRandom());
        

URL url = new URL("https://google.com");
HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
conn.setSSLSocketFactory(ctx.getSocketFactory());
conn.connect();
conn.getInputStream();
conn.disconnect();

And of course it didn’t work initially, because Conscrypt doesn’t provide implementations of some core interfaces needed – the CTLogStore and CTPolicy classes. The CTLogStore actually is the important bit that holds information about all the known logs (I still find it odd to call a “log provider” simply “log”, but that’s the accepted terminology). There is a list of known logs, in JSON form, which is cool, except it took me a while to figure (with external help) what are exactly those public keys. What are they – RSA, ECC? How are they encoded? You can’t find that in the RFC, nor in the documentation. It can be seen here that it’s ” DER encoding of the SubjectPublicKeyInfo ASN.1 structure “. Ugh.

BouncyCastle to the rescue. My relationship with BouncyCastle is a love-hate one. I hate how unintuitive it is and how convoluted its APIs are, but I love that it has (almost) everything cryptography-related that you may ever need. After some time wasted with trying to figure how exactly to get that public key converted to a PublicKey object, I found that using PublicKeyFactory.createKey(Base64.getDecoder().decode(base64Key)); gives you the parameters of whatever algorithm is used – it can return Elliptic curve key parameters or RSA key parameters. You just have to then wrap them in another class and pass them to another factory (typical BouncyCastle), and hurray, you have the public key.

Of course now Google’s Conscrypt didn’t work again, because after the transformations the publicKey’s encoded version was not identical to the original bytes, and so the log ID calculation was wrong. But I fixed that by some reflection, and finally, it worked – the certificate transparency log was queried and the certificate was shown to be valid and properly included in the log.

The whole code can be found here. And yes, it uses several security providers, some odd BouncyCastle APIs and some simple implementations that are missing in Google’s provider. Known certificates may be cached so that repeated calls to the log are not performed, but that’s beyond the scope of my experiment.

Certificate transparency seems like a thing that’s core to the internet nowadays. And yet, it’s so obscure and hard to work with.

Why the type of public key in the list is not documented (they should at least put an OID next to the public key, because as it turns out, not all logs use elliptic curves – two of them use RSA). Probably there’s a good explanation, but why include the SCT in the log rather than the fingerprint of the certificate? Why not then mandate inclusion of the SCT in the certificate, which would require no additional configuration of the servers and clients, as opposed to including it in the TLS handshake, which does require upgrades?

As far as I know, the certificate transparency initiative is now facing scalability issues because of the millions of Let’s encrypt certificates out there. Every log (provider) should serve the whole log to everyone that requests it. It is not a trivial thing to solve, and efforts are being put in that direction, but no obvious solution is available at the moment.

And finally, if Java doesn’t have an easy way to do that, with all the crypto libraries available, I wonder what’ the case for other languages. Do they support certificate transparency or they need upgrades?

And maybe we’re all good because browsers supports it, but browsers are not the only thing that makes HTTP requests. API calls are a massive use-case and if they can be hijacked, the damage can be even bigger than individual users being phished. So I think more effort should be put in two things:
1. improving the RFC and 2. improving the programming ecosystem. I hope this post contributes at least a little bit.

The post Certificate Transparency Verification in Java appeared first on Bozho's tech blog.

Да поговорим за ИТ фирмите и обществените поръчки

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

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

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

А този въпрос е важен, защото в крайна сметка реализацията

  • Некадърни фирми – да, ясно е, че има такива и то немалко – фирма с 1 старши разработчик и 7-8 младши за колкото може по-малки заплати, да наливат код, и все нещо ще излезе. Старшият разработчик ще следи процеса, и готово. Той самият може да не е достатъчно добър, но поне има опит. След това тези младши разработчици се изстрелват при първа по-адекватна възможност, защото виждат какъв ужас е. Има и други фирми – които си имат разработчици и мениджъри с опит, но просто никога не са правили софтуер както трябва. Винаги е било с процес „каубойско писане на код“, и „мазане“ – без оглед за производителност, информационна сигурност, удобство… и все някой друг е виновен. Някои не ползват контрол на версиите, не знаят какво е уеб-услуга и като цяло – останали са в 90-те. Виждал съм такива неща, че и за курсов проект не стават.
  • „Окопани“ фирми – когато „гаражна“ фирма е направила някакъв софтуер преди 20 години, който е успяла с някакви връзки да пробута я на някоя община, я на някоя областна или централна администрация, и после само тя може да го надгражда или поддържа. Промяната така или иначе е трудна, но дори при опит от страна на администрацията да се смени софтуера, има тежък отпор, който понякога стига до това да не се дава базата данни за миграция към евентуална нова система или пък до абсурдни твърдения, че фирмата има авторско право върху информацията в базата данни. Такива примери има твърде много и те са сериозен фактор.
  • Корупция – да, ясно е, че корупция има. И то доста. Някои фирми са „установени“ в някои администрации не просто заради предишен опит, ами и по линия на някакви политически връзки. Това го разбрах с почти челен сблъсък със системата на корупция – в една фирма, в която работех за кратко, едни шеф ме помоли да отида в едно министерство и да участвам в работна група по писане на задание. За поръчка, която явно е трябвало да спечелим. Трябваше ми около половин ден да загрея за какво точно става дума, но на въпроса „значи аз трябва да се правя на независим експерт и да напиша задание, по което после ние да кандидатстваме и да спечелим“ отговорът беше „Ами да. Те всички така правят“. Отказах да го направя (имайки лукса на гъвкавия и гладен софтуерен пазар), и в крайна сметка поръчката така и не се случи, но важното беше, че „всички така правят“. В случаите, когато фирмите не си пишат сами заданията, им ги пишат приятелски фирми, а след това се редуват. И после като резултатът е зле – „ами то така пишеше в заданието“. (Периодично има по някой скандал с това, че в метаданните на документите за някоя поръчка пише като автор – служител на някой от кандидатите). Противно на очакванията, обаче, не мисля, че ако махнем корупцията, всичко ще цъфне и върже. Останалите проблеми ще са налице и няма да позволят магическия прогрес (това не значи, че не трябва да се борим против нея, естествено). Корупцията има и друг аспект – фирми, които не са „в играта“ не кандидатстват, защото не знаят дали поръчката не е нагласена за някого. Нерядко стои въпросът „абе тая поръчка гласена ли е за някого или да участвам?“.
  • Недостатъчен капацитет – някоя фирма може да е добра, но да се е надценила и е кандидатствала по повече поръчки, отколкото може да поеме, но пък е взела, че ги е спечелила, и сега се чуди как да ги изпълни. Приоритизира един, забавя друг, наема хора „от кол и въже“, колкото да спази сроковете.
  • Остарели основни системи – когато основните ти системи са остарели и нямам как да направиш адекватна интеграция с тях, задачи, които са изглеждали лесни, стават доста трудни. Примери много, но да вземем МВР, където доскоро имаше стара система за регистрация в КАТ. На база на тази система нови функционалности, оптимизиране на процеси и други неща нямаше как да станат, или поне не лесно. Имаше един регистър, който е правен през 90-те. Доста неща зависеха от него, но просто нямаше как да се интегрират. И съответно интеграцията с него става „ръчно“. Примерите с носене на флашки рядко са заради липса на мрежда – по-често са заради стари системи без никакви точки за интеграция
  • Лоши задания – дори когато сме извън сценария „изпълнителят сам си пише заданието“, заданията са лоши. Администрацията рядко има капацитет да напише адекватно задание. Или копира от стари задания, или възлага на някой консултант да го напише (който я разбере за какво е поръчката, я не…а и да разбере, предава нещо полу-грамотно, което после трябва да се пише от нулата). А резултатът зависи в немалка степен от заданието – фирмите, разбираемо, често си дават зор повече от това, което се изисква от тях (има и похвални изключения). И съответно могат да свършат и чудесна работа, и никаква работа – зависи какво им се търси. Именно заради проблема със заданията въведохме две мерки. Едната е шаблонно задание с всички настъпвани през годините „мотики“, така че да не се правят нещата грешно. Разбира се, шаблонът допуска редакции за конкретния случаи (напр. ако системата не предполага пълнотекстово търсене, такова няма нужда да се изисква), но като цяло ограничава полето за ТНТМ-та. Другата мярка беше Държавно предприятие „Единен системен оператор“, което да поеме писането на задания (както и други дейности по проектите). Второто така и не се е случило все още.
  • Лошо управление на проектите от възложителя – това често е голям проблем. Може фирмата да има доброто желание и капацитета да направи проекта както трябва, но в администрацията просто няма никой, който да знае как се движи проект. Това беше още една причина, поради която въведохме Държавно предприятие, а също така и кратко преживял Project management office в Администрацията на Министерския сътвет. И двете в момента отсъстват и затова нещата се движат от редови служители в администрацията, които в добрия случаи са викали неволята достатъчно много пъти и горе-долу знаят как се управлява проект. В лошия (и вероятно по-масов) случай просто разписват протоколи и приемат проекта. Има десетки неща, за които възложителят има задължения – да осигури права за интеграция с други системи, да осигури хардуер (ако такъв не е заложен), да осигури помещения за хардуера (ако такъв е заложен), да осигури уточнения по изискванията на нормативната уредба в частта с бизнес анализа, и т.н. Има и друг тип проблеми – възложителят да има необмислени изисквания и да държи на тях, въпреки съветите на изпълнителя – напр. „това на уебсайта трябва да е точно както е на хартия“.
  • Независещи от никого обстоятелства – често срещан пример е срокове по някой закон (или Регламент на ЕС), които администрацията е опитала да спази в срок, ама заради тромави процедури, обжалвания, събаряне на търгове, КЗК, ВАС (малко корупцийка, съответно), нещата не са се получили. И когато все пак се стигне до изпълнение на проект, сроковете вече са „за вчера“, обаче политическият натиск расте, и съответно резултатът се приема с едно затворено око и едно гледащо в другата посока.
  • Липса на политическа подкрепа – един проект може да бъде неглижиран от политическото ръководство и това да го направи невъзможен за изпълнение. Например често се налага изменение на някоя наредба или заповед, за да може да се използват всички възможности на софтуера. Обаче ако никой от политическият кабинет „не даде едно рамо“, наредбата си остава от 94-та и програмистите псуват какви глупости ги карат да правят
  • ЗОП – на последно място, но изобщо не по важност, Законът за обществените поръчки е неподходящ за софтуерни проекти. Прекалено е бюрократичен и предполага до голяма степен т.нар. waterfall модел, което предполага много ниска гъвкавост. Освен всичко друго, за кандидатстване по процедура по ЗОП, фирмата трябва да има хора, които могат да се оправят с бюрократичния процес (който с новата директива е малко по-добър, но все пак изисква познаване на процедурите и опит с писане на документи). Как да напишеш офертата и техническото предложение, така че да покрият критериите за оценка, как да се вместиш в сроковете за кандидатстване. Ако нямаш опит със ЗОП, т.е. ако предимно работиш за частни клиенти, например извън България, то едва ли имаш голям шанс в една процедура по ЗОП. Съответно пък по ЗОП не можеш да оцениш реално кандидатите – всичките имат сертификати, всичките имат годишен оборот и всички ще напишат в техническото си предложение, че ще изпълнят всичко. И особено ако администрацията не е достатъчно технически грамотна, няма да може да оцени кой е вникнал повече в заданието и е разписал по-адекватно предложение. Бях предложил преди време като част от документацията по кандидатстване, да се представя код от предходни проекти, на база на който да се извличат някакви метрики – качество на кода, покритие с тестове и др. Само че „по ЗОП не може“.

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

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

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

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

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

Integrating Applications As Heroku Add-Ons

Post Syndicated from Bozho original https://techblog.bozho.net/integrating-applications-as-heroku-add-ons/

Heroku is a popular Platform-as-a-Service provider and it offers vendors the option to be provided as add-ons. Add-ons can be used by Heroku customers in different ways, but a typical scenario would be “Start a database”, “Start an MQ”, or “Start a logging solution”. After you add the add-on to your account, you can connect to the chosen database, MQ, logging solution or whatever.

Integrating as Heroku add-on is allegedly simple, and Heroku provides good documentation on how to do it. However, there are some pitfalls and so I’d like to share my experience in providing our services (Sentinel Trails and SentinelDB) as Heroku add-ons.

Both are SaaS (one is a logging solution, the other one – a cloud datastore), and so when a Heroku customer wants to add it to their account, we have to just create an account for them on our end.

In order to integrate with Heroku, you need to implement several endpoints:

  • provisioning – the initial creation of the resources (= account)
  • plan change – since Heroku supports multiple subscription plans, this should also be reflected on your end
  • deprovisioning – if a user stops using your service, you may want to free some resources
  • SSO – allows users to log in your service by clicking an icon in the Heroku console.

Implementing these endpoints following the tutorial should be straightforward, but it isn’t exactly. Hence I’m sharing our Spring MVC controller that handles it – you can check it here.

A few important bits:

  • You may choose not to obtain a token if you don’t plan to interact with the Heroku API further.
  • We are registering the user with a fake email in the form of <resourceId>@heroku.com. However, you may choose to use the token to fetch the emails of team members and collaborators, as described here.
  • The most important piece of data is the resource_id – store it in your users (or organizations) table and consider adding an index to be able to retrieve records by it quickly.
  • Return your keys and secrets as part of the provisioning request. They will be set as environment variables in Heroku
  • All of the requests are made from the Heroku servers to your server directly, except the SSO call. It is invoked in the browsers and so you should set the session cookie/token in the response. That way the user will be logged in your service.
  • When you generate your addon manifest, make sure you update the endpoint URLs

After you’re done, the alpha version appears in the marketplace (e.g. here and here). You should then have some alpha users to test the add-ons before it can be visible in the marketplace.

Integrating SaaS solutions with existing cloud providers is a good thing, and I’m happy that Heroku provides an automated way to do that. (AWS, for example, also has a marketplace, but integration there feels a bit strange and unpolished (I’ve hit some issues that were manually resolved by the AWS team).

Since many companies are choosing IaaS or PaaS for their services, having the ability to easily integrate an add-on service is very useful. I’d even go further and propose some level standardization for cloud add-ons, but I guess time will tell if we really need it, or we can spare a few days per provider.

The post Integrating Applications As Heroku Add-Ons appeared first on Bozho's tech blog.

Електронна държава [презентация]

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

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

Слайдовете можете да разгледате тук:

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

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

Types of Data Breaches and How To Prevent Them

Post Syndicated from Bozho original https://techblog.bozho.net/types-of-data-breaches-and-how-to-prevent-them/

Data breaches happen practically every day. Personal, including financial and medical data leak to cyber criminals as well as intelligence agencies. Some notable breaches include the Equifax breach, where dozens of personal data fields were leaked, and the recent Marriott breach, where passports, credit cards and locations of people at a given time were breached.

I’ve been doing some data protection consultancy as well as working on a data protection product and decided to classify the types of data breaches and give recommendations on how they can be addressed. We don’t always get to know how exactly the breaches happen, but from what is published in news articles and post-mortems, we can have a good overview on the breach landscape.

Control over target server – if an attacker is able to connect to a target server and gains full or partial control on it, they can do anything, including running SELECT * FROM ... , copying files, etc. How do attackers gain such control? In many ways, most notably RCE (remote code execution) vulnerabilities and weak admin authentication.

How to prevent it? Follow best security practices – regularly update libraries and software to get security patches, do not run native commands from within the application layer, open only necessary ports (80 and 443) to the outside world, configure 2-factor authentication for administrator login. Aim at having an intrusion detection / prevention system. Encrypt your data, and make the encryption as granular as possible for the most sensitive data (e.g. for SentinelDB we utilize per-record encryption) to avoid SELECT * breaches.

SQL injections – this is a rookie mistake that unfortunately still happens. It allows attackers to manipulate your SQL queries and inject custom bits in them that allows them to extract more data than they are supposed to.

How to prevent it? Use prepared statements for your queries. Never ever concatenate user input in order to construct queries. Run regular code reviews and use code inspection tools to catch such instances.

Unencrypted backups – the main system may be well protected, but attackers are usually after the weak spots. Storing backups might be such – if you store unencrypted backups that are accessible via weak authentication (e.g. over FTP via username/password), then someone may try to attack this weaker spot. Even if the backup is encrypted, the key can be placed alongside it, which makes the encryption practically useless.

How to prevent it? Encrypt you backups, store them in a way that’s as strongly protected as your servers (e.g. 2FA, internal-network/VPN only), and have your decryption key in a hardware security module (or equivalent, e.g. AWS KMS).

Personal data in logs – another weak spot other than the backups may be your logs. They usually lie on separate servers, and are not as well guarded. That’s usually okay, since logs don’t contain personal information, but sometimes they do. I recently stumbled upon a large company’s website that had their directory structure unprotected and they kept their access logs files alongside their static resources. In addition to that, they passed personal information as GET parameters, so you could get a lot of information by just getting the access logs. Needless to say, I did a responsible disclosure and the issue was fixed, but it was a potential breach.

How to prevent it? Don’t store personal information in logs. Avoid submitting forms with a GET method. Regularly review the code to check whether personal data is not logged. Make sure your logs are stored in a way as protected as your production servers and your backups. It could be a cloud service, it could be a local installation of an open source package, but don’t overlook the security of the log collection system.

Data pushed to unprotected storage – a recent Alteryx/Experian leak was just that – data placed on a (somewhat) public S3 bucket was breached. If you place personal data in weakly protected public stores (AWS S3, file sharing services, FTPs), then you are waiting for trouble to happen.

How to prevent it? Don’t put personal data publicly. How to prevent that from happening – always review your S3 buckets and FTP servers policies. Have internal procedures that disallow sharing personal data without protecting it with at least a password shared by a side-channel (messenger/sms).

Unrestricted API calls – that’s what caused the Facebook-Cambridge Analytics issue. No matter how secure your servers are, if you expose the data through your API without access restriction, rate-limiting, fraud-detection, audit trail, then your security is no use – someone will “scrape” your data through the API.

How to prevent it? Do not expose too much personal data over public or easily accessible APIs. Vet API users and inform your users whenever their data is being shared with third parties, via API or otherwise.

Internal actor – all of the woes above can happen due to poor security or due to internal actors. Even if your network is well guarded, an admin can go rogue and leak the data. For many reasons, nonincluding financial. An privileged internal actor has access to perform SELECT *, can decrypt the backups, can pretend to be a trusted API partner.

How to prevent it? Good operational security. A single sentence like that may sound easy, but it’s not. I don’t have a full list of things that have to be in place to guard against internal breaches – there are technical, organizational and legal measures to be taken. Have unmodifiable audit trail. Have your Intrusion prevention system (or logging solution) also detect anomalous internal behaviour. Have procedures that require two admins to work together in order to log in (e.g. split key) to the most. If the data is sensitive, do background checks on the privileged admins. And many more things that fall into the “operational security” umbrella.

Man-in-the-middle attacks – MITM can be used to extract data from active users only. It works on website without HTTPS, or in case the attacker has somehow installed a wildcard certificate on the target machine (and before you say that’s too unlikely – it happens way too often to be ignored). In case of a successful MITM attack, the attacker can extract all data that’s being transferred.

How to prevent it? First – use HTTPS. Always. Redirect HTTP to HTTPS. Use HSTS. Use certificate pinning if you control the updates of the application (e.g. through an app store). The root certificate attack unfortunately cannot be circumvented. Sorry, just hope that your users haven’t installed such shitty software. Fortunately, this won’t lead to massive breaches, only data of active users that are being targeted may leak.

JavaScript injection / XSS – if somehow an attacker can inject javascript into your website, they can collect data being entered. This is what happened in the recent British Airways breach. A remember a potential attack on NSW (Australia) elections, where the piwick analytics script was loaded from an external server that was vulnerable to a TLS downgrade attack which allowed an attacker to replace the script and thus interfere with the election registration website.

How to prevent it? Follow the XSS protection cheat sheet by OWASP. Don’t include scripts from dodgy third party domains. Make sure third party domains, including CDNs, have a good security level (e.g. run Qualys SSL test).

Leaked passwords from other websites – one of the issues with incorrect storage of passwords is password reuse. Even if you store passwords properly, a random online store may not and if your users use the same email and password there, an attacker may try to steal their data from your site. Not all accounts will be compromised, but the more popular your service is, the more accounts will be affected.

How to avoid it? There’s not much you can do to make other websites store passwords correctly. But you can encourage the use of pass phrases , you can encourage 2-factor authentication in case of sensitive data, or you can avoid having passwords at all and use an external OAuth/OpenID provider (this has its own issues, but they may be smaller than those of password reuse). Also have some rate-limiting in place so that a single IP (or an IP range) is not able to try and access many accounts consecutively.

Employees sending emails with unprotected excel sheets – especially non-technical organizations and non-technical employees tend to just want to get their job done, so they may send large excel sheets with personal data to colleagues or partners in other companies. Then once someone’s email account or server is breached, the data gets breached as well.

How to prevent it? Have internal procedures against sending personal data in excel sheets, or at least have people zip them and send passwords through a side channel (messenger/sms). You can have an organization-wide software that scans outgoing emails for attachments with excel sheets that contain personal data and have these email blocked.


Data breaches are prevented by having good information security. And information security is hard. And it’s the right combination of security practices and security products that minimize the risk of incidents. Many organizations choose not to focus on infosec, as it’s not their core business or they estimate that the risk is worth it, viewing breaches, internal actors manipulating data and other incidents as something that can’t happen to them. Until it happens.

The post Types of Data Breaches and How To Prevent Them appeared first on Bozho's tech blog.

Без регистри идва хаос

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

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

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

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

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

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

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

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

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

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

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

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