Generators in GO

Generator, simply, this is a function that returns the iterator. It's applicable in case of when you do not need to load all data in memory before processing or in cases when we can not receive all data at once or we generate it on the go. In some languages mainly used special keyword yield what returns some value until the next call of the next value from the iterator.

Let’s create the generator.

def gen(steps):
	for i in range(0, steps):
		yield i * i

The yield will generate something like this
Read more →

Testing in GO

When the creators of golang were developing the architecture of the language they were caring out about developers which will use it in real work. One of the most important processes of development it's the testing, and they did it very convenient and easy to use as they use it themselves.

To create the test enough to declare ".go" file with "_test" postfix in the name. This file will be ignored by the compiler when you will assemble your application. When you run the test every module in the project «go» compile the module with "_test.go" files as independent application and run the test cases one by one.

Let's make simple GO test

First of all, we need what exactly will be to test.

// fact.go
package fact

func Fact(v int) int {
	switch {
	case v < 2:
		return 1
	case v == 2:
		return 2
	return v * Fact(v-1)

Read more →

How (not) to do GDPR

I prepared a few simple recommendations for you.

1. Do not rush to break your software and business, unless you are deep into advertisement or social profiling or your IT processes imply dumping every piece of data you have on an unprotected file server. If you are doing personal data processing for a legitimate business purpose in a reasonable manner, it is safe to assume you can stand your ground under any GDPR related scrutiny.

I know a retail company that ceased CCTV recording in all their warehouses. The hell broke loose, even before the theft. The company turned completely unable to find misplaced items. Why? Because there was a guy «responsible» for GDPR compliance who had authority to handle it that way. When anyone opposed him, his answer was simple: fines are huge, risks are high and is your advice to do otherwise backed with any willingness to cover possible non-compliance issues from your own pocket? Ah, you do not have enough money anyway, so get lost.

What this guy was essentially doing is covering his own ass on INSANELY HUGE company's expense. Don't do it. GDPR is not about ruining your business (unless your business is very questionable already).

2. Do not buy shit. GDPR fearmongering is a goldmine for people selling «compliance solutions». But the truth is, there is no «compliance solution» you can buy. Under this hot GDPR sauce you would only buy things you do neither need nor want to buy. Less creative «solution providers» will sell to you some firewall-antivirus-encryption stuff for twice the regular price. More creative ones will sell to you data intelligence and audit tools of the most expensive variety, that won't help you at all. GDPR is not about buying anything (unless you neglected your basics before).

3. Do not pay for any certification. Currently there is no GDPR certification, which literally means any certification you get is totally irrelevant for GDPR. The idea «there must be some checklists and papers, so it is worth to get your ISO27K or whatever until more specific requirements would be in place, because ISO27K is a default way to prove to everyone you are a good citizen» sounds appealing, but the appeal of the idea is in its deceptive psychological comfort and nothing more.

Of course it is not all that simple. Some minor organisational effort is still required — as described by countless howto's: remove everything you do not actually need (and stop gathering it «just in case»), get consent when appropriate and keep track on what you do both for yourself and for data subject.

KRACK: no big deal either

Either your vital communications are end2end encrypted already, or you have more reasons to worry than just KRACK.

  • Endpoints are movable. There was a communication once performed via direct patch cord link. Next day it could go around half of the internet: someone decides to move one of endpoints to the cloud, to a different location, or else. And if you ever use your laptop or smartphone on the public wifi, the attack surface never changed for you at all.

  • You cannot reliably protect all endpoints on an Ethernet-like network 100% of the time. Chances are, someone is sniffing you from a compromised device with much higher probability than he/she could get through (relatively) short KRACK vulnerability window.

  • Do you watch your wired infrastructure close enough? Are you sure not just every network socket, but every centimetre of your network cabling is under control? Really? If your TV screen or printer in a public conference room is connected to the office network without 802.1x and VLAN separation, KRACK is not an issue.

On the doorsteps of ivory tower: encryption for a "demanding" customer

Recently I took a somewhat deeper-than-intended dive into a wonderful world of so-called “secure communications” (don’t ask me why, maybe I will tell you eventually). No, not Signal or Protonmail, nor Tox or OTR. I mean paid (and rather expensive) services and devices you probably never heard of (and had every reason not to). Do the names like Myntex, Encrochat, Skyecc, Ennetcom ring a bell? Probably it does not, as it should be, unless they fuck something up spectacularly enough to hit the newspaper headlines (some of them really did).

Three lessons should be learned

FIRST, while experts are discussing technical peculiarities, John Q. Public is not interested in all that technobabble. This attitude constitutes a security issue in its own right, but at least it is well-known and we know what we need to do: to educate the customer about several basic, intuitive and easy for a non-technical person concepts — OPSEC, attack surface, threat models, supply chain security, encryption key life cycle etc. And then we leave everything «more technical» to a trustworthy independent audit.

Right? NO. Those people are not interested AT ALL (technobabble included), and they treat your aforementioned audit with the same amount of interest. And your educational initiative goes the same way since the entire syllabus you call «very very basics every human being must understand» fits comfortably into the category «technobabble» in the customer's world view. For them «Military grade security» is just as convincing as «we had a public independent review» — a little more than white noise and the former is still more than the latter. Let alone the popular opinion about audit: «You could compromise your security by allowing god-knows-who look into the implementation details! It was careless!»

SECOND, as “business” customers do not really care about technology, you cannot show them the trustworthiness of your solution by using the technological correctness of this solution. There is no common ground, no scientific consensus, no expert is trusted, everything is «my word vs your word», no audit is reliable (and that’s yet another reason nobody is interested in audits).

For your customers the very notion of «trust» implies interpersonal relations. They cannot trust anything but people. A piece of software being trusted? Or better still: trusted for a certain particular property? — those notions are not welcome in a businessman's brain. However, that may not be a detriment. In the end of the day we can not eliminate the «human factor» from the software as long as humans write it (with all the backdoors and eastereggs). Trust (as your customers understand it) is all about loyalty. Trust (as you understand it) is an expression of your knowledge of the software capabilities. Perhaps someone should stop abusing the word, and I suggest to stick to the older meaning. Get yourself a new word! On the other hand, the traditional loyalty-driven interpretation of trust leads to horrible decisions in the context of infosec. A catastrophic clusterfuck of any magnitude, is easily forgiveable as long as it is caused by mere negligence as opposed to sabotage. «Yeah, people make mistakes, but they did their best, yes? They TRIED!»

THIRD is that trust issues with people lead those customers into miserable situations, as they know people no better than they know technology, but for no reason they feel more confident in that area. Running a successful business (especially risky one, if you know what I mean) reinforces confirmation bias about knowing people. First you make a lot of money, and next day you get scammed by a Nigerian prince, a Russian bride or a fake crypto.

I guess I should write a separate essay about liability shift and self-preservation mechanisms that sometimes fail in unexpected way for unexpected people, but not now.

On positive impact of ransomware on information security

I truly hate I need to write this. And I feel really sorry for those who were forced to learn it the hard way, but don't tell me you haven't been warned in advance years before. However.

— The end of compliance-driven security is now official. Petya is not impressed with your ISO27K certificate. Nor does it give a flying fsck about your recent audit performed by a Big4 company.
— Make prevention great again (in detection dominated world we live in now)! Too busy playing with your all-new AI-driven deep learning UEBA box? Ooops, your homework goes first. Get patched, enable smb signing, check your account privileges and do other boring stuff and then you may play.

Did I say BCP and business process maturity? Forget that, I was kidding, hahaha. That's for grown-ups.

Any sales pitch mentioning WannaCry is a scam.

snake oil
To suffer a significant damage from WannaCry, you need to craft a redundant clusterfuck of FIVE SIMULTANEOUSLY MET conditions:

  1. Failure to learn from previous cases (remember Cornflicker? It was pretty much similar thing)
  2. Workflow process failure (why do you need those file shares at all?)
  3. Basic business continuity management process failure (where are your backups?)
  4. Patch management process failure (to miss an almost two month old critical patch?)
  5. Basic threat intelligence and situational awareness failure (not like in «use a fancy IPS with IoC feed and dashboard with world map on it», more like «read several top security-related articles in non-technical media at least weekly»)

And after you won the bingo, you expect you can BUY something that will defeat such an ultimate ability to screw up? Duh.

The greatest problem with "public" schools that they are NOT public.

Do you, dear public, pay for those schools?
You do… you pay exactly «for» but not «to». The schools actually receive money from the govt, NOT from you. And you have no control over the money distribution. When the money are given to the schools they don't bear your scent anymore — these are «govt's money» at the moment. The govt decides who takes the money, and for these money, a school has to appease the govt, NOT you. These «public» schools are indeed the govt's schools.

Americans seem to forget the old russian proverb:
Who dines the girl, he dances her.