All posts by Bozho

Какви са проблемите на системата за преброяването?

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

Проблемите на НСИ са сложни и многопластови и не могат да се обяснят просто с посочване на някого с пръст. Трябва, обаче, да търсят дългосрочни решения, а не оправдания.

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

  • НСИ е направил поръчка за готова система за преброяване, а не за разработка на такава. Като цяло разумно решение. Местният партньор на шведската фирма „производител“ е СкейлФокус, които е трябвало да направят инсталация, конфигурация и поддръжка. Много често компании предпочитат да имат местни партньори, при които отива процент от продажбата, т.нар. two tier (или понякога three tier) distribution model. Цената е за лиценз, инсталация и конфигурация и като цяло изглежда разумна. Функционалностите са доста повече от
    онлайн форми (на който му е интересно, техническото задание, предложението и договорът са на сайта на НСИ)
  • DDoS атаката е сериозна – ако наистина 250 гигабита в секунда са се „изсипали“ срещу системата, то на чисто софтуерно ниво няма какво да се направи – „тръбата“ се запушва, дори приложението да може да обработи данните. Засега няма причина да смятаме, че тази информация е грешна, най-много да е малко преувеличена, но дори да е наполовина, пак е значителна. Не съм съгласен, че „какво толкова сложно има да се защити една система“ – това не е софтуерен проблем, а мрежови. И няма прости и евтини решения.
  • НСИ не са били подготвени за такава атака, а е трябвало. Ползването на CloudFlare е недостатъчна мярка за критичността и репутационните щети. Обикновено проблемът с CloudFlare е не самият CloudFlare, а това, че по други данни (исторически и настоящи DNS записи и просто логическо мислене) може да се прескочи CloudFlare.
  • Тук обаче ще вдигна нещата едно ниво по-нагоре – това не е проект на НСИ, това е национален проект. НСИ просто е натоварен с неговото изпълнение. На ниво държава изгелжда липсва адекватна подготовка за защита от DDoS. Държавна агенция „Електронно управление“ и ресорните вицепремиери до момента е трябвало да осигурят такава не само на НСИ, но и за всички системи. Тя не е евтина, но работи (чрез т.нар. scrubbing центрове, които „почистват“ мръсния трафик преди да го изпратят към системите.) Кадровото осигуряване също е важна тема – колко ИТ експерти има НСИ и на какво заплащане и можем ли да очакваме да свършат всичко? Това също е системен проблем в държавата.
  • DDoS атаките рядко водят до изтичане на данни (сами по себе си – никога, но понякога се ползват за димна завеса, прикрирваща други действия; засега не изглежда да е такъв случаят).
  • съдейки по съобщенията за грешка, които излизаха в предните два дни, е имало и чисто интеграционни проблеми за проверката на въведените лични данни. За тези проблеми няма добро оправдание, а причината е липсата на координация между институциите и липсата на отговорен за процеса.

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

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

Obtaining TLS Client Certificates In Spring Integration

Post Syndicated from Bozho original https://techblog.bozho.net/obtaining-tls-client-certificates-in-spring-integration/

Spring Integration is a very powerful and extensible framework for, well, integrations. But sometimes it’s not trivial how to get some information that yo need. In my case – a certificate used for mutual authentication in a TLS (syslog over TLS) connection. You have a Java method that receives a Message and ideally you’d want to get the certificate chain used by the client to authenticate itself (e.g. you may need to extract the CN).

Fortunately, Spring Integration is flexible. And it can be done, but it’s a bit convoluted. I’ll use XML notation, but the same can be achieved through Java config.

<bean id="nioConnectionSupport" class="com.yourcompany.util.net.TLSMutualNioConnectionSupport">
        <constructor-arg ref="sslContextSupport" />
        <constructor-arg value="false" />
</bean>
<bean id="interceptorFactoryChain" class="org.springframework.integration.ip.tcp.connection.TcpConnectionInterceptorFactoryChain">
        <property name="interceptors">
            <bean class="com.yourcompany.util.net.TLSSyslogInterceptorFactory" />
        </property>
</bean>

<int-ip:tcp-connection-factory id="tlsConnectionFactory" type="server" port="${tcp.tls.port}"
                                   using-nio="true" nio-connection-support="nioConnectionSupport"
                                   single-use="false" interceptor-factory-chain="interceptorFactoryChain" />

The sslContextSupport would typically be a org.springframework.integration.ip.tcp.connection.DefaultTcpSSLContextSupport or a custom implementation (e.g. if you want to use a “blind” trust store)

Then you’d need the two classes. You can check them at their respective gists: TLSSyslogInterceptorFactory and TLSMutualNioConnectionSupport.

What do these classes do? The TLSSyslogInterceptorFactory sets a new header for the message that contains the client ceritficates. The TLSMutualNioConnectionSupport class sets the “wantClientAuth” option on the SSL Engine. There is another option – “needClientAuth” which would for client authentication, rather than just support it. Depending on the use case you can use one or the other.

Then you can obtain the certificates at your handler method via:

Certificate[] certificates = (Certificate[]) message.getHeaders().get(TLSSyslogInterceptorFactory.TLS_CLIENT_CERTIFICATES);

A small tip I wanted to share to help the next one trying to achieve that.

The post Obtaining TLS Client Certificates In Spring Integration appeared first on Bozho's tech blog.

Коалиция, плаващи мнозинства, кадруване, отговорност – изясняване на базовата политическа терминология

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

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

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

Коалиция е формулата, по която се осигурява тази подкрепа. Няколко партии се разбират предварително, че за определени въпроси (приоритети) ще гласуват заедно. Няма по всички теми да гласуват заедно, но по много на брой важни неща – ще. Коалиция не значи, че ще се делят министри (по формула 3-5-8 или каквото е съотношението), не значи, че на някой му се полагат или дължат постове. Разбирателството кои реформи ще се подкрепят заедно се оформя често като коалиционно споразумение. В него може да има формула и за министри и заместник-министри, а може и да няма. Заради Тройната коалиция думата „коалиция“ стана мръсна, но тя е просто един политически инструмент.

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

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

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

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

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

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

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

Накъде с електронните подписи

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

От около година подписвам електронни документи през демонстрационното приложение на Европейската комисия за електронно подписване (DSS, open source проект, доста читав). Защото Adobe Reader се счупи и не мога да го оправя. Т.е. не мога да подписвам PDF-и освен с DSS + NexU.

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

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

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

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

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

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

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

За скандала с Pegasus и следенето на журналисти

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

Тази сутрин по БНР обсъдихме шпионския софтуер Pegasus, използван за следене на журналисти и опозиционери в режими по света, в т.ч. в Унгария. Ето накратко:

  • софтуерът влиза през отваряне на злонамерен линк или през компрометирано приложение и получава пълен достъп до телефона, благодарение на уязвимости на операционните системи
  • оправданието винаги е „борба с тероризма“. Обаче никога няма данни за реално предотвратени атентати.
  • само „добрите“ правителства ще имат достъп е наивен аргумент и не работи. Всяко правителство може да се изкуши, а може и от некадърност да „изпусне“ софтуера в по-лоши ръце
  • NSO (компанията, която разработва и продава Pegasus) казват, че не знаят как клиентите им го ползват. Но някак знаят, че се ползва за борба с тероризма. Последно?
  • наличието на обобщен списък от следени номера може да значи, че компанията всъщност знае кои са следените с нейния софтуер. Това е още по-голям проблем.
  • имам призив към ИТ сектора: имаме лукса да отчитаме етичните аспекти на предлаганата ни работа, защото добре платена работа има много. Нека не избираме да създаваме кибероръжия. Това във връзка с факта, че NSO има българска дъщерна компания – Circles, в която (вероятно) се работи по продуктите им.
  • много е важен демократичният (парламентарен и не само) контрол върху службите. Засега няма индикации България да е ползвала този софтуер, но следва съответната парламентарна комисия да провери имало ли е транзакции към NSO или нейни свързани дружества.
  • трябва да се помисли за забрана на търговията с уязвимости и произтичащ от тях софтуер – от това се възползват репресивни режими и чужди служби и няма легитимна пазарна стойност.

Всеки път трябва да си припомняме, че няма как да гарантираме, че само „добрите“ имат достъп до дадена технология. Както при дебатите около отслабване на криптирането, така и при използването на spyware.

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

Въпроси и отговори за следизборните сглобки

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

Чета коментари и анализи на следизборната обстановка и доста въпроси и обвинения към Демократична България. Ето ги накуп и техните кратки отговори.

Искате ли постове?

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

А защо искате да се консултира с вас състава на кабинета?

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

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

Никога не сме обявявали бланкетна подкрепа. Условията винаги са били 12-те ни приоритета. Обявявали сме пълна готовност за разговори, не пълна готовност за подкрепа.

Христо Иванов иска ли да е министър или главен прокурор?

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

Отричате ли правото на първия да състави кабинет?

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

Говорите само за ДПС, забравихте ли Борисов?

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

Ако нямате доказателства за връзки с ДПС, защо поставяте условия?

За да гарантираме, че наистина няма да има зависимост от „златния пръст“ на ДПС. Комисиите за Росенец и ТЕЦ Варна биха били неприемливи за Доган.

Защо с 34 депутати поставяте условия на победителя?

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

Защо толкова искате да управлявате?

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

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

Следизборно

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

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

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

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

Благодаря на Демократична България и особено на доброволците на Да, България от 24-ти МИР.

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

Още веднъж – благодаря за цялата подкрепа и доверие. Ще ги приведа в действие и резултат.

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

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

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

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

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

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

В: В презентацията се споменаваше, че смарткартите имат чип на Infineon – проверено ли е дали тези модели са засегнати от уязвимостта ROCA, открита преди няколко години
О: Да, проверено е и няма тази уязвимост

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

В: Колко време издържа мастилото върху хартията на разпечатания протокол?
О: Мастилото и хартията са удостоверени, че издържат 5 години.

В: Кой извършва инсталирането и персонализирането на машините в складовете?
О: Доставчикът (Сиела-Норма)

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

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

В: При персонализирането на смарт картите къде се генерира частния ключ – на самата карта или извън нея?
О: На самата карта, което не позволява изтичане

В: Персонализирането синхронизирано ли е с решенията на РИК за проманя на листи (напр. при отказване, смърт)
О: Отразени са всички промени до момента. Оттук нататък всички промени минават през ЦИК и се синхронизират със Сиела.

В: Къде се намира частният ключ, с който се подписва протокола на флашката? На смарт картата или другаде?
О: На смарт картата (предназначена за членовете на СИК)

В: Кой присъства на правенето на build (системен образ)
О: Ще се използва билда от предните избори, на който са присъствали Сиела-Норма и представител на Държавна агенция „Електронно управление“

В: В какъв формат е системният образ?
O: FSA (File System Archive)

В: Изключена ли е възможността през USB порт да бъдат разпознавани клавиатури, мишки и други устройства (които потенциално могат да имат злонамерено действие)
О: Да, изключени са

В: Кой и как управлява ключовете за UEFI secure boot?
О: Въпрос от компетентността на ЦИК, с нужда от изпращане на писмен въпрос (членовете на ЦИК трябваше да излязат за заседание, което налагаше отнасянето до някои въпроси в тази форма)

В: Освен системната разписка, съдържаща хеша на всички файлове (с изключение на логове и временни), е възможно да се включи външен hash extractor, който да сметне хеша независимо. Как работи той?
О: Hash extractor-ът е bootable флашка, подписана със съответния ключ за UEFI secure boot, чрез която се извлича хеша.
Коментар: Тук предложението, което ще изпратим заедно с въпросите, е да се използва hash extractor-ът на извадка от машините преди и/или след изборите, за допълнителна проверка

В: Хешът на системния образ ще бъде ли публикуван?
О: Да

В: Как се гарантира рандомизацията на гласовете в криптираната част на флашката? (този въпрос ми беше в списъка, но го зададе колега от неправителствена организация. В доклада за предните избори пише, че всички файлове са с timestamp = 0 и със случайно генерирани имена, но колегата отбеляза, че ext3 файловата система има включено по подразбиране журналиране, което може да се използва за разкриване на поредността).
О: Слеед всеки подаден глас машината разменя съдържанието на новия глас със съществуващ клас в някакъв процент от случаите, така че да се получи рандомизация.

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

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

7 принципа на електронното управление

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

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

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

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

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

Every Serialization Framework Should Have Its Own Transient Annotation

Post Syndicated from Bozho original https://techblog.bozho.net/every-serialization-framework-should-have-its-own-transient-annotation/

We’ve all used dozens of serialization frameworks – for JSON, XML, binary, and ORMs (which are effectively serialization frameworks for relational databases). And there’s always the moment when you need to exclude some field from an object – make it “transient”.

So far so good, but then comes the point where one object is used by several serialization frameworks within the same project/runtime. That’s not necessarily the case, but let me discuss the two alternatives first:

  • Use the same object for all serializations (JSON/XML for APIs, binary serialization for internal archiving, ORM/database) – preferred if there are only minor differences between the serialized/persisted fields. Using the same object saves a lot of tedious transferring between DTOs.
  • Use different DTOs for different serializations – that becomes a necessity when scenarios become more complex and using the same object becomes a patchwork of customizations and exceptions

Note that both strategies can exist within the same project – there are simple objects and complex objects, and you can only have a variety of DTOs for the latter. But let’s discuss the first option.

If each serialization framework has its own “transient” annotation, it’s easy to tweak the serialization of one or two fields. More importantly, it will have predictable behavior. If not, then you may be forced to have separate DTOs even for classes where one field differs in behavior across the serialization targets.

For example the other day I had the following surprise – we use Java binary serialization (ObjectOutputStream) for some internal buffering of large collections, and the objects are then indexed. In a completely separate part of the application, objects of the same class get indexed with additional properties that are irrelevant for the binary serialization and therefore marked with the Java transient modifier. It turns out, GSON respects the “transient” modifier and these fields are never indexed.

In conclusion, this post has two points. The first is – expect any behavior from serialization frameworks and have tests to verify different serialization scenarios. And the second is for framework designers – don’t reuse transient modifiers/annotations from the language itself or from other frameworks, it’s counterintuitive.

The post Every Serialization Framework Should Have Its Own Transient Annotation appeared first on Bozho's tech blog.

10 бюрократични пречки, за чието премахване ще работя

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

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

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

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

Материалът 10 бюрократични пречки, за чието премахване ще работя е публикуван за пръв път на БЛОГодаря.

Защо „електронно управление“ и как ще работя за него в Народното събрание

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

На изборите на 11 юли съм на избираемото трето място в листата на Демократична България в 24 МИР (София) и ми се ще да направя ясна заявка за какво смятам, че ще съм полезен в парламента. На предните избори мотивирах участието си в листата (макар и по-назад), но сега трябва да направя следващата стъпка – да кажа защо смятам, че ще бъда полезен в парламента.

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

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

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

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

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

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

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

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

Мога да продължавам дълго, но обобщението е това – чрез електронно управление ще живеем по-добре.

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

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

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

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

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

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

A Developer Running For Parliament

Post Syndicated from Bozho original https://techblog.bozho.net/a-developer-running-for-parliament/

That won’t be a typical publication you’d see on a developer’s blog. But yes, I’m running for parliament (in my country, Bulgaria, an EU member). And judging by the current polls for the party I’m with, I’ll make it.

But why? Well, I’ll refer to four previous posts in this blog to illustrate my decision.

First, I used to be a government advisor 4 years ago. So the “ship of public service” has sailed. What I didn’t realize back then was that in order to drive sustainable change in the digital realm of the public sector, you need to have a political debate about the importance and goals of those changes, not merely “ghost-writing” them.

A great strategy and a great law and even a great IT system is useless without the mental uptake by a sufficient amount of people. So, that’s the reason one has to be on the forefront of political debate in order to make sure digital transformation is done right. And this forefront is parliament. I’m happy to have supported my party as an expert for the past four years and that expertise is valued. That’s the biggest argument here – you need people like me, with deep technical knowledge and experience in many IT projects, to get things done right on every level. That’s certainly not a one-man task, though.

Second, it’s a challenge. I once wrong “What is challenging for developers” and the last point is “open ended problems”. Digitally transforming an entire country is certainly a challenge in the last category – “open ended problems”. There is no recipe, no manual for that.

Third, lawmaking is quite like programming (except it doesn’t regulate computer behavior, it regulates public life, which is far more complex and important). I already have a decent lawmaking experience and writing better, more precise and more “digital-friendly” laws is something that I like doing and something that I see as important.

Fourth, ethics has been important for me as a developer and it’s much more important for a politician.

For this blog it means I will be writing a bit more high-level stuff than day-to-day tips and advice. I hope I’ll still be able to (and sometimes have to) write some code in order to solve problems, but that won’t be enough material for blogposts. But I’ll surely share thoughts on cybersecurity, quality of public sector projects and system integration.

Software engineering and politics require very different skills. I think I am a good engineer (and I hope to remain so), and I have been a manager and a founder in the last couple of years as well. I’ve slowly, over time, developed my communication skills. National politics, even in a small country, is a tough feat, though. But as engineers we are constantly expanding our knowledge and skills, so I’ll try to transfer that mindset into a new realm.

The post A Developer Running For Parliament appeared first on Bozho's tech blog.

The Syslog Hell

Post Syndicated from Bozho original https://techblog.bozho.net/the-syslog-hell/

Syslog. You’ve probably heard about that, especially if you are into monitoring or security. Syslog is perceived to be the common, unified way that systems can send logs to other systems. Linux supports syslog, many network and security appliances support syslog as a way to share their logs. On the other side, a syslog server is receiving all syslog messages. It sounds great in theory – having a simple, common way to represent logs messages and send them across systems.

Reality can’t be further from that. Syslog is not one thing – there are multiple “standards”, and each of those is implemented incorrectly more often than not. Many vendors have their own way of representing data, and it’s all a big mess.

First, the RFCs. There are two RFCs – RFC3164 (“old” or “BSD” syslog) and RFC5424 (the new variant that obsoletes 3164). RFC3164 is not a standard, while RFC5424 is (mostly).

Those RFCs concern the contents of a syslog message. Then there’s RFC6587 which is about transmitting a syslog message over TCP. It’s also not a standard, but rather “an observation”. Syslog is usually transmitted over UDP, so fitting it into TCP requires some extra considerations. Now add TLS on top of that as well.

Then there are content formats. RFC5424 defines a key-value structure, but RFC 3164 does not – everything after the syslog header is just a non-structured message string. So many custom formats exist. For example firewall vendors tend to define their own message formats. At least they are often documented (e.g. check WatchGuard and SonicWall), but parsing them requires a lot of custom knowledge about that vendor’s choices. Sometimes the documentation doesn’t fully reflect the reality, though.

Instead of vendor-specific formats, there are also de-facto standards like CEF and the less popular LEEF. They define a structure of the message and are actually syslog-independent (you can write CEF/LEEF to a file). But when syslog is used for transmitting CEF/LEEF, the message should respect RFC3164.

And now comes the “fun” part – incorrect implementations. Many vendors don’t really respect those documents. They come up with their own variations of even the simplest things like a syslog header. Date formats are all over the place, hosts are sometimes missing, priority is sometimes missing, non-host identifiers are used in place of hosts, colons are placed frivolously.

Parsing all of that mess is extremely “hacky”, with tons of regexes trying to account for all vendor quirks. I’m working on a SIEM, and our collector is open source – you can check our syslog package. Some vendor-specific parsers are yet missing, but we are adding new ones constantly. The date formats in the CEF parser tell a good story.

If it were just two RFCs with one de-facto message format standard for one of them and a few option for TCP/UDP transmission, that would be fine. But what makes things hell is the fact that too many vendors decided not to care about what is in the RFCs, they decided that “hey, putting a year there is just fine” even though the RFC says “no”, that they don’t really need to set a host in the header, and that they didn’t really need to implement anything new after their initial legacy stuff was created.

Too many vendors (of various security and non-security software) came up with their own way of essentially representing key-value pairs, too many vendors thought their date format is the right one, too many vendors didn’t take the time to upgrade their logging facility in the past 12 years.

Unfortunately that’s representative of our industry (yes, xkcd). Someone somewhere stitches something together and then decades later we have an incomprehensible patchwork of stringly-typed, randomly formatted stuff flying around whatever socket it finds suitable. And it’s never the right time and the right priority to clean things up, to get up to date, to align with others in the field. We, as an industry (both security and IT in general) are creating a mess out of everything. Yes, the world is complex, and technology is complex as well. Our job is to make it all palpable, abstracted away, simplified and standardized. And we are doing the opposite.

The post The Syslog Hell appeared first on Bozho's tech blog.

Какво ще се промени с нови избори?

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

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

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

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

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

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

Developers Are Obsessed With Their Text Editors

Post Syndicated from Bozho original https://techblog.bozho.net/developers-are-obsessed-with-their-text-editors/

Developers are constantly discussing and even fighting about text editors and IDEs. Which one is better, why is it better, what’s the philosophy behind one or the other, which one makes you more productive, which one has better themes, which one is more customizable.

I myself have fallen victim to this trend, with several articles about why Emacs is not a good idea for Java, why I still use Eclipse (though I’d still prefer some IDEA features), and what’s the difference between an editor and an IDE (for those who’d complain about the imprecise title of this post).

Are text editors and IDEs important? Sure, they are one of our main tools that we use everyday and therefore it should be very, very good (more metaphors about violin players and tennis players, please). But most text editors and IDEs are good. They evolve, they copy each other, they attract their audiences. They are also good in different ways, but most of the top ones achieve their goal (otherwise they wouldn’t be so popular). Sure, someone prefers a certain feature to be implemented in a certain way, or demands having another feature (e.g. I demand having call hierarchies on all constructors and IDEA doesn’t give me that, duh…) But those things are rarely significant in the grand scheme of things.

The comparable insignificance comes from the structure of our work, or why we are being now often called “software engineers” – it’s not about typing speed, or the perfectly optimized tool for creating code. Our time is dedicated to thinking, designing, reading, naming things. And the quality of our code writing/editing/debugging tool is not on the top of the list of things that drive productivity and quality.

We should absolutely master our tools, though. Creating software requires much more than editing text. Refactoring, advanced search, advanced code navigation, debugging, hot-swap/hot-deploy/reload-on-save, version control integration – all of these things are important for doing our job better.

My point is that text editors or IDEs occupy too much of developers’ time and mind, with too little benefit. Next time you think it’s a good idea to argue about which editor/IDE a colleague SHOULD be using, think twice. It’s not a good investment of your time and energy. And next time you consider standardizing on an editor/IDE for the whole team, don’t. Leave people with their preference, it doesn’t affect team consistency.

The post Developers Are Obsessed With Their Text Editors appeared first on Bozho's tech blog.

List of Open Source Security Tools

Post Syndicated from Bozho original https://techblog.bozho.net/list-of-open-source-security-tools/

As a founder of a security company, I’m constantly looking for open source tools to either incorporate in our offering, or get inspiration from, or provide integration with. And there are dozens of great open source security tools, so I decided to publish a list of them. This plethora of options is one of the reasons that security is so hard – they are many different ways to achieve something and it almost always involves headaches with configuring and connecting various “point solutions” (as marketers call them). So here’s the list in on apparent order (note that I’ve listed only defensive tools, offensive ones like metasploit, nmap, wireshark, etc. probably deserve a separate post):

Security monitoring, intrusion detection/prevention

  • Suricata – intrusion detection system
  • Snort – intrusion detection system
  • Zeek – network security monitoring
  • OSSEC – host-based intrusion detection system
  • Wazuh – a more active fork of OSSEC
  • Velociraptor – endpoint visibility and response
  • OSSIM – open source SIEM, at the core of AlienVault
  • SecurityOnion – security monitoring and log management
  • Elastic SIEM – SIEM functionality by Elasticsearch
  • Mozdef – SIEM-like layer ontop of
    Elasticsearch
  • Sagan – log analytics and correlation
  • Apache Metron – (retired) network security monitoring, evolved from Cisco OpenSOC
  • Arkime – packet capture and search tool (formerly Moloch)
  • PRADAS – real-time asset detection
  • BloodHound – ActiveDirectory relationship detection

Threat intelligence

  • MISP – threat intelligence platform
  • SpiderFoot – threat intelligence aggregation
  • OpenCTI – threat intelligence platform
  • OpenDXL – open source tools for security intelligence sharing

Incident response

Vulnerability assessment

  • OpenVAS – very popular vulnerability assessment
  • ZAProxy – web vulnerability scanner by OWASP
  • WebScarab – (obsolete) web vulnerability scanner by OWASP
  • w3af – web vulnerability scanner
  • Loki – IoC scanner
  • CVE Search – set of tools for search in CVE data

Firewall

  • pfsense – the most popular open source firewall
  • OPNSense – hardenedBSD-based firewall
  • Smoothwall – linux-based Firewall

Antivirus / endpoint protection

Email security

I’m sure there are more (and I’d be happy to add them, e.g. this list suggested in reddit, or others in the reddit thread). Assessing each individual tool, its ease of use, its compliance aspects and the combination between multiple tools is a hard task (here’s a SANS paper on “stitching” multiple tools together). And making sense of the whole landscape (as I’ve tried previously) hints about the complexity of a security professional’s job.

The post List of Open Source Security Tools appeared first on Bozho's tech blog.

Кратък наръчник на законодателя

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

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

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

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

  • Не трябва да се въвеждат изисквания за удостоверения – законите създават права и задължения. Когато в закон пише „заявителят представя удостоверение за Х“, то задължението за това е негово. Администрацията може да приложи Закона за електронното управление и вместо да го иска от гражданина, да го събере служебно и да му го представи за потвърждение, но това е заобиколен начин да се изпълни законовото изискване, и поради това не много го правят – а всеки закон се явява специален спрямо Закона за електронното управление и администрацията казва „ами то може в ЗЕУ да пише, че трябва да съберем служебно, ама в НАШИЯ закон пише вие да го представите“. Затова удостоверяването на обстоятелства трябва да е задължение на администрацията, напр. „органът по чл. ХХ установява наличието на следните обстоятелства“. Това оставя възможност все пак за изискване на удостоверение в подзаконовата нормативна уредба, ако такова не може да бъде събрано служебно или авотматизирано, но задължението да разбере дали заявителят отговаря на всички условия е на администрацията
  • Без декларации за служебно проверими обстоятелства – като алтернатива на удостоверенията се използват декларациите – заявителят декларира, че нещо е така, както пише в закона, но ако то се окаже иначе, той носи отговорност за деклариране на неистина (по чл. 313 от Наказателния кодекс). Има немалко дела за това – част от тях се разминават с административна санкция (НК позволява това), но това не значи, че е приятно. Другият минус на тези декларации е, че правят заявяването на услугите по-сложно – освен заявление трябва да се попълват по няколко декларации „по образец“. Нерядко законите (и съответно администрацията) ни кара да декларираме данни, с които администрацията разполага. Къде точно е границата между служебното събиране и декларирането не е очевидно, но ако нещо е толкова значимо, че да бъде законово изискване, то администрацията трябва да разполага с него в структуриран вид. Разбира се, понякога регистър липсва и декларацията е единственият начин, но това трябва да е само в преходен период – докато се появи такъв електронен регистър.
  • Минимизиране на нотариално заверените декларации – декларациите са неудобни, но когато трябва да се разходите до нотариус, това не само ни бави и струва пари, а и чупи възможността за изцяло електронно предоставяне на услугата. Защото документът, който изпращаме, трябва да е сканиран, а не в оригиналния си електронен вид. Още повече, че квалифицираният електронен подпис, поне за някои неща, може да бъде приравнен на нотариално заверен, защото доставчиците на квалифицирани удостоверителни услуги проверяват нашата самоличност като ни издават подписа, а към него съществуват технически гаранции, че не може да бъде копиран и използван от друг. Разбира се, нотариусите няма да останат без работа, но в момента законодателството изисква излишно много нотариални заверки (напр. декларацията по ЗМИП)
  • Необходимо е да се водят електронни регистри – когато се въвежда регистър със закон, той е редно да спазва изискванията на Закона за електронното управление. Макар това да звучи подразбиращо се, то не е така и е нужна изрична препратка към ЗЕУ. Всеки закон урежда реда на водене на своите регистри, но има много общи компоненти, които са съществени и няма нужда да се копират навсякъде – проследимост и история на действията, отворени данни, уникални идентификатори, отворени програмни интерфейси и т.н. Всички тези неща са описани в наредба към ЗЕУ, но рядко се изпълняват, защото липсва връзката между въведения със специален закон регистър и подзаконовата нормативна уредба на ЗЕУ. Затова за всеки нововъведен регистър е добре да има една алинея: „Регистърът по ал. х трябва да отговаря на изискванията на Закона за електронното управление“
  • Задължителна електронна комуникация за големите компании – когато кръгът регулирани от даден закон лица включва големи компании (напр. банки, застрахователи, телекоми), то задълженията за докладване могат и трябва да бъдат само по електронен път. Примерът отново е Законът за мерките срещу изпирането на пари, където има предвидена опция за електронно докладване за съмнителни транзакции от банките към ДАНС, но това не е задължително и съответно тази система не работи ефективно. Банките изпращат писма на хартия, които не е ясно доколко се обработват (имаше такъв казус покрай изтеглена голяма сума от обвиняем). Можем да презюмираме, че компании над определен размер са длъжни да имат адекватен ИТ капацитет.
  • Без несвързани изменения с „преходни и заключителни разпоредби“ – един закон може да изменя други закони, когато има логическа връзка между тях – напр. ако изменяш Закона за търговския регистър и регистъра на юридическите лица с нестопанска цел, ако някой друг закон споменава ЗТРРЮЛНЦ, той може да трябва да бъде изменен. Но нерядко депутатите използват този инструмент да правят абсолютно несвързани промени, защото нещо им е хрумнало (или защото трябва да прокарат нещо по-тихичко). Има си процедура за това – нов законопроект. Ако парламентът работи ефективно, може да гледа малки законопроекти отделно.
  • Без значителни промени между първо и второ четене – между двете четения депутатите могат да правят предложения за промени в даден законопроект. Това е съвсем естествено, тъй като на първо четене се приема законопроектът „по принцип“, а детайлите му се разглеждат на второ четене. Но съществува практиката след като е приет законопроект по принцип, в него да се направят толкова значителни промени, че принципното съгласие по него вече да не е налице. Напр. с редакция между първо и второ четене не върви да се променят данъчни ставки. Ако някой иска да внася някаква значителна промяна, да се е сетил навреме, когато се вкарват за разглеждане група законопроекти по един закон. Ако му е толкова важно, през председателския съвет да помоли да се изчака малко, докато са му готови измененията. Така е доста по-чисто и честно спрямо избирателите, а и спрямо изискванията за оценка на въздействието.

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

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

Коментари по доклада за съответствие на машините за гласуване

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

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

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

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

  • Предоставени са три машини. Това е малко, като не става ясно от кои партиди на доставка са били, т.е. дали от всяка доставка има поне по една машина.
  • В доклада пише, че „За цялостното произвеждане на изборен процес чрез ТУМГ се използват допълнителни инструменти създаването на Image и инсталирането на операционната система и приложния софтуер.“ – т.е. за всеки избор има отделен image на операционната система плюс приложния софтуер. Според мен е по-добре да има един image на операционната система, а изборите да се конфигурират на приложно ниво. Иначе стои възможността изискванията към операционната система, които според доклада са спазени, да не бъдат спазени при друг image
  • Пише също така, че „Операционната система, инсталирана в основната памет на ТУМГ, има вградена функция, която при всяко зареждане, изчислява контролна сума (”хеш”). Този „хеш“ се визуализира на екрана със системна информация и се отпечатва върху служебните разписки. Чрез проверка за съвпадение с предварително изчисления „хеш“ на компонентите подготвени за инсталиране в ТУМГ се удостоверява и може да се гарантира автентичността на инсталирания в основната памет на ТУМГ базов и потребителски софтуер;“ – това е много важно. Всички застъпници и наблюдатели трябва да поискат от секционните избирателни комисии тази разписка и да яснимат, за да се установи дали всички машини имат идентичен хеш (както се очаква в рамките на един избор). Друг коментар тук е, че не трябва да се разчита на вградената функционалност за изчисляване на хеша, защото тя може да бъде подменена и да визуализира не реалния, а избран хеш. Т.е. трябва при предварителен и последващ одит да се използва външен механизъм за това (поне върху артефактите на приложния софтуер)
  • Докладът казва и следното: „Промените в „образа“ (дизайна)на бюлетината се реализират чрез промени в изходния код на приложението. При произвеждане на нови избори, в които се налага промяна в „образа“ на бюлетината, е необходимо препрограмиране, компилиране и нова инсталация на приложния софтуер в ТУМГ“ – това е много странно решение. Дизайн трябва да може да се реализира чрез шаблони, които да се настройват, вместо да се компилира наново цялото приложение за гласуване. Компилирането наново означава, че освен дизайна, някой може да промени и функционалност по отчитането.
  • Данните и номенклатурите за съответния избор се зареждат чрез USB флаш памет на всяка машина. Прозрачността на този процес не е описана в изборния кодекс, а би следвало съдържанието на тази флаш памет да бъде гарантирано (подписано), и публикувано предварително.
  • Докладът отбелязва, че „При невъзможност имената на партиите и кандидатите, да бъдат визуализирани на един екран, бюлетината се извежда на няколко последователни екрана и преминаването към всеки от тях се извършва с бутони;“ – това е потенциален проблем за партии с по-задни номера. „Моята партия я няма тука“ е нещо, което хора могат да си кажат, докато опитват да гласуват. Не казвам, че е лесно да се направи интерфейсът така, че хем да е идентичен с хартиената бюлетина, хем да не крие част от партиите/коалициите, и този проблем е отчасти заложен от самия Изборен кодекс, но трябва да се отбележи.
  • Протоколът се записва на файл на флашката и се подписва електронно. Докладът, обаче, не казва с какъв частен ключ се случва това и как се управлява той, съответно къде се съхраняват публичните ключове. Дали има един ключ за всички машини или се генерира отделен ключ за всяка? Използват ли се смарткартите на СИК-овете или се съхранява отделно, и ако да – това място защитено ли е от изтичане (съответно от възможността някой да вземе ключа и да подпише нов, фалшифициран протокол). В техническата спецификация се говори за генериране на ключове, но от доклада не става ясно как машините поддържат описания там процес.
  • Техническата спецификация изисква покритие с автоматизирани тестове на поне 70%. Това не е установено от доклада, макар че изглежда, че достъп до изходния код е бил предоставен
  • В доклада много бегло се споменава как е протекъл анализа на изходния код, както и откриването на уязвимости – не се посочва дали са сравнявани наличните компоненти с бази данни от уязвимости (NVD/CVE). Не изглежда да е прилаган статичен анализ на кода за откриване на уязвимости (SAST)
  • Установена е липса на ПИН пликове – това не е драматично и не е част от машините, но изпълнителят трябва да го предостави в изборния ден. Наблюдателите и застъпниците е добре да следят дали такива пликове са налични.
  • Следният сценарий не е изпълнен: „Тестване на модула за валидация и обобщаване на контролни записки, както и проверка на съдържанието на ЗТУ и основната памет на дефектирала машина –чрез устройството за четена на 2D бар кода“, защото от ЦИК не са предоставили необходими документи. Това е притеснително, защото проверката на съдържанието е важно за интегритета на машинния протокол
  • В техническата спецификация има изискване системната информация да бъде електронно подписана. От докладът не става ясно дали това е така.
  • „Всеки запис е в отделен файл, със случайно генерирано име, а всички файлове имат една и съща дата и час.“ – имената вероятно зависят от текущото време, което се използва за генератора на случайни числа (съответно имена). Не изглежда да е направен анализ дали може от имената да се извлече поредността. Това е сложна задача и може би не попада в обхвата на такъв доклад, но в дългосрочен план тази функционалност трябва да се прегледа.
  • Споменава се, че дисковите дялове са криптирани, но не се казва с какъв ключ и дали е full disk encryption, както пише в техническата спецификация. Може би в протоколите има повече детайли.

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

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

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

За трите папки – съдебна реформа, изборна реформа, модернизация

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

В петък в Панорама Христо Иванов показа три папки, пълни със законопроекти. В едната – за съдебна реформа (вкл. изменение на конституцията), реформа на регулаторите и лустрация. Във втората – за промени в изборните правила, за да не гледаме пак този хаос, който се развива в момента. И третата – за модернизация и електронно управление.

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

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

Предлагаме изменения, с които:

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

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

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

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

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

Пътят ще е дълъг, но започва на 4-ти април. С номер 11.

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