One of the challenges that agile development methodologies brought with them is some level of perceived incompatibility with security governance methodologies and SDLs. No matter how you used to integrate security assurance activities with the rest of your engineering efforts, it is likely that Agile messed it up. It almost feels as if agile engineering methodologies had as a primary design goal the disruption of security processes.

But we often want Agile, and we want security too, so the gap has to be bridged. To this end, we need to first understand where the source of the conflict really is, and this also requires understanding where it is not. Understanding the non-issues is important, because there are some elements of agile engineering that are sometimes considered to be contradicting security interests where they really are not; and we would like to focus our efforts where it matters.

We will start by highlighting a few minor issues that are easy to overcome, and then discuss the more fundamental change that may in some cases be required to marry security governance with Agile.

Don’t get me wrong; Bitcoin and crypto currencies are a big deal, at least technology-wise. Bitcoin and blockchains taught us a lot on what can be done with security protocols, and at a lower level, it even taught us that computation inefficiency is not always a bad word, but something that can yield benefits, if that inefficiency is properly orchestrated and exploited. It was also the most prevalent demonstration of scarcity being artificially created by technology alone. As I wrote before, blockchains will probably have some novel use-cases one day, and Bitcoin, aside of being a mechanism for transferring money, also provides a target of speculation, which in itself can be (and is) monetized.

What I truly do not understand are the advocates who see Bitcoin wallets as the near-future replacement for bank accounts, and Bitcoin replacing banks (and other financial institutions) in the near future. I understand the motivation, as those are dreams easy to fall for, but for crypto-currency wallets to replace financial institutions much more is needed, and for the sake of this discussion I will not even delve into the many technical difficulties.

I recently came across this study titled “Unknown Threats are The Achilles Heel of Email Security”. It concludes that traditional e-mail scanning tools, that also utilize machine-learning to cope with emerging threats, are still not reacting fast enough to new threats. This is probably true, but I think this conclusion should be considered even more widely, beyond e-mail.

Threats are dynamic. Threat actors are creative and well-motivated enough to make threat mitigation an endlessly moving target. So aren’t we fortunate to have this new term, “machine learning”, recently join our tech jargon? Just like many other buzzwords, the term is newer than what it denotes, but nonetheless, a machine that learns the job autonomously seems to be precisely what we need for mitigating ever-changing threats.

All in all, machine-learning is good for security, but yet in some cases it is a less significant addition to our defense arsenal. Why? – Because while you learn, you often don’t do the job well enough; and a machine is no different. Eventually, the merits of learning-while-doing are to be determined by the price of the resulting temporary imperfectness.

One of the biggest technological controversies of the decade are blockchains. There is no debate on how brilliant the technology is. It is very clever, if not genius. The only debate is on how useful it really is. Crypto currencies like Bitcoin are a strong use-case for blockchains, but how many other real use-cases are there? Some people claim that blockchains will change the Internet for good, while others consider it as a clever solution still seeking a problem. Reality is probably somewhere in between, as it usually is.

Blockchains often appear to be more useful than they really are, because their proponents bring up uses for blockchains which could also be facilitated using other, simpler and traditional techniques. Most of those uses, which could also be attained without blockchains, are indeed better off without them. As clever as blockchains are, they always add complexity where they are deployed. In other words, I have not yet seen a single problem that could be solved by either blockchains or other technical means, and where the blockchain-based approach was the simpler one. It follows that if we want to discuss the true merits of blockchains, then we shall identify those problems that could be solved using blockchains, and which could not be solved by simpler existing technologies.

Years ago, we did not trust cloud service providers, or we trusted them only when we had no choice. Then, consumers started using web-mail and other such services, and finally companies also moved into replacing their own IT with cloud applications. By now, we trust our service providers sufficiently, for the most part. We model our risks, we consider the benefits, and we usually decide that it’s worth it. But often enough, our trust in service providers still does not cause us the necessary warm and fuzzy feeling that is required for us to hand off all our data to the cloud and live a truly digital life. As it seems, thinking you are secure is one thing, and feeling you are sufficiently secure, even with your most critical data, is something else.

What do we do for now? – Use the cloud, but not for everything…

How can you tell apart real company values from more superficial mantras or slogans?

There is one objective mark for values: they fight and they win, when contesting on scarce resources of any type.

A real company value wins fights against other interests when competing on budget, resource allocation, and other cost-bearing priorities.

If it does not fight – it’s not a value but a preference.

If it does not win – it’s not a value but a show.

One reason we struggle with finding a solution to the fake news problem is that we have never defined the problem properly. The term “fake news” started as referring to publications that look like news but are entirely fabricated. It then migrated to consist also of news articles that are just grossly inaccurate, to later expand further into consisting also of news one doesn’t like and tries to dispute.

It is amusing to see how we seek technical mitigation towards a problem which is entirely semantic. Just like a lie detector does not detect untruths but only the artifacts of a lying person, all technologies that are considered for fighting fake news do not detect untruths but mostly willful propaganda. However, just like plain deceiving, publishing propaganda also consists of many shades of grey, implying that whatever solutions we find, we will never be happy with them.

We should recalculate our route.

Do you know what all security documents have in common? — they all were at some time called “threat model”… A joke indeed, and not the funniest one, but here to make a point. There is no one approach to threat modelling, and not even a single definition of what a threat model really is. So what is it? It is most often considered to be a document that introduces the security needs of a system, using any one of dozens of possible approaches. Whatever the modelling approach is, the threat model really has just one strong requirement: it needs to be useful for whatever purpose it is made to serve. Let us try to describe what we often try to get from a threat model, and how to achieve it.

Computers today already know how to draw great paintings using artificial-intelligence (AI) algorithms, after analyzing many real-human paintings. A sales house just sold one machine-generated portrait painting for $540,000, and by now there are startups that produce AI-generated portraits for $40 a piece. On the musical front, there already are algorithms that, after analyzing compositions made by Bach, compose “Bach” symphonies that even avid listeners cannot tell apart from the real thing. This brings up the question of what’s in the future for artists, now that machines create art that is indistinguishable from that produced by humans.

The same question (at a lower scale) has also been asked about security professionals. Now that machine learning algorithms can tell good from bad when looking at any type of event data, what would human security analysts be left to do? Traditionally, machines used to only sort through records using rules that humans wrote for them, but as it seems, machines are constantly getting better at writing those rules for themselves as well.

So should both worry for their jobs? It is my stance that not at all, and for surprisingly similar reasons.

We grow increasingly reliant on quite a few Internet-based services: social networks, messaging, photo sharing, and the rest. The challenges we face with privacy, data ownership enforcement, surveillance, and other aspects of digital abuse could all be substantially reduced if those data sharing needs were addressed by the Internet as it was originally architected: decentralized and open. We have waited very long, and so remediation would take more than just new standards, but it is doable.