Some thoughts on enterprise risk management, security awareness and stuff



It all started as a Facebook discussion. A colleague of mine witnessed an impressive talk on a conference: a representative of a penetration testing company claimed he would hack any company in one hour. He was challenged to do this, and here is the solution:

With simple search of social networks and the company’s website, he profiled the target company and obtained a contact of a sales person. Then he crafted simple trojan executable (not really tailored at this time, just some generic one), encrypted the archive and sent it to that person; then he called by phone pretending he has an urgent business proposal and mentioned the email he have just sent.

The salesperson replied: ”I cannot open the documents, my antivirus does not allow me to". «Strange, which one?» "(some name)" «Ok, I will send you a new archive, it should work». And it did (now it was a better crafted trojan).

Yes, simple as that.

Could it be thwarted with a proper training?

Yes. And no.

You may expect some vigilance from a person who understands the risks.
But what the risks are and could a training help to understand it?

From a salesperson's perspective, chances are there is a technical issue. A salesperson estimates the probability of this as, say, 90% (we may discuss his reasoning later).

“If I manage to close the deal, circumventing the procedures that do not allow me to open these documents, I get, say, $30K bonus. If I do not, I get nothing.
10% chance is there is a malicious hacker trying to steal the data from the company. If a hacker succeeds, and I get the blame, I am to be fired and I lose, say, $50K in total consequences”.

Given our salesman has a decent experience and learned some basic probability theory, it is totally acceptable for him to ignore the danger; this would be a reasonably profitable strategy that incurs no extra cost. Add some internal competition among sales people and you easily see that he would play this lottery again and again.

That's how single-parameter optimisation works. One cannot simply turn the «money seeking zombie» mode off.

Let's talk about someone a bit higher in a corporate food chain, or even at the top of it — CEO, CFO, VP of sales, etc.

The perspective changes drastically. If the contract is secured, the company gets $1M. If a large-scale network breach occurs, sensitive data get leaked, or something similarly happens, the company loses $15M. And that persons bonus is affected accordingly.

The balance is all different now (even if we assume probabilities to be the same).

Who is our CISO (or whoever is in charge of the data security) working for? The answer is obvious.

But there are caveats, as usual.

The first caveat is that if, say, our worst-case scenario loss is estimated to be low and the associated damage to be benign, then the doing nothing strategy of risk acceptance (as bad as it sounds) is a business justified course of action.
If you dislike this choice, you may try spend some resources to decrease the probability and the impact, don't expect the business side to be very cooperative. It is still a lot of money, but not enough to let you interfere with any revenue generating processes.

And the second caveat is more serious. It is that all our risk estimations are produced by the business risk management process, which is an enigma for us, a black box. It either works, or we blindly assume it works because it is «someone else's problem».

It the business risk management is ad hoc, or does not exist in your organisation, or is non-functional, it gets substituted with “information security risk management”, where the most prominent «information sources» are: «FBI/CSI reports», «SEC-mandated leak disclosures», «industry analysis reports» — the highest grade nonsense, zero relevance is guaranteed.

It is better than nothing to base our guess on, but a blatant attempt to sell our qualitative estimation as quantitative data is a pure hoax.

However, chances are there is no risk management at all in your company, not even a dysfunctional one.

I think most people in the industry know that, but most are afraid to tell the truth aloud.

If you do not know your business environment, the probability estimation is pointless.
If you do not know the real business impact of a breach, your loss estimation is baseless.

Multiply these to get nonsense squared.

But you need to “justify” your security choices anyway. Scaremongering sounds like a decent plan now?

Fingers vs Fingerprints



It turned out that my "Authentication vs Identification" article was not sufficiently conclusive in the sense that some hardcore biometrics fans still nurture a non-trivial and well justified objection. So I need to address and destroy it, in order to close the topic. My opponents' argument is:

Your analysis narrows the both sides of the problem to a knowledge/ownership claim. Even if you are right, the conclusion is only applicable to the authentication by means of a knowledge token, whereas all the rest relations between the user and the token (suitable for authentication purposes) are set aside. There is one particularly important relation (the one fundamental for the entire biometrics field): «the user is» or other way around «the token is a part of the user» — this relation implies inalienability which makes the token safe for authentication purposes.

It is true. Completely true. It is undeniably true! In the physical realm.
Read more →

On coming age of silver bullets

Silver bullet

I keep telling you time and again «there is no silver bullet in Information Security», despite the vendors blatant attempts to claim otherwise.

You cannot buy a box that solves your problems at once. Every tool needs a skilled person to be mastered by. And still we look forward with hope for the best and the victory of reason, while, trying to guess the shape of things to come. There are emerging technologies, deep learning, AIs and stuff that certainly will change everything. Someday. And there are promising startups that already started doing it. But is it really the most important change we expect — right now?
Read more →

Authentication vs Identification



Once again I have to return to the topic of strict antagonism between the authentication and the identification, meaning these very processes and the tokens involved as well. Before I indulge into boring you with tedious decomposition of entities you used to perceive as atomic, I present you a synthetic illustration of the difference in question. A bad guy tries to get a false-negative outcome of identification, and a false-positive outcome of authentication. This is not explanatory, yet very indicative, I hope it gives you an idea of the magnitude of the difference, and we are going to dig into this now.
Read more →

An Observation About Passphrases: Syntax vs Entropy



I suggested in the article to use passphrases instead of «traditional» passwords, for multiple reasons, including: sheer strength, memorability, and conforming to idiotic password creation policies without actually following detrimental recommendations of the policy authors.

This recommendation gives rise to a reasonable doubt: «what if syntactically correct phrases are as weak as dictionary words in comparison to a random string of symbols?''. Indeed, syntax itself should weaken a passphrase, as it provides some „predictability'' to the phrase. I want to address this problem, by comparing syntactically correct passphrases to random collections of words (which we all consider sufficiently strong… hopefully).
Read more →

Android's Security Policy Is: "All Or Nothing"

This is the essay about the biggest and the most successful infosec profanation campaign in the world. It undermines the very idea of security awareness in each and every aspect, and it does so very subtly too. Initially I wanted to tell you how this profanation works and why it would be successful at cleansing users' minds from any security related thoughts; today I have upgraded my test-bunny Android device and realized that my «prediction» is getting late — Android has entered the final stage of the campaign: after the applications succeeded at damaging users' security awareness, the core system itself openly stepped into the battle, to commit the final blow.
Read more →

On The "Bottom-Up" Approach To Data Security

Once I stated the title I immediately realized that there are many distinct dimensions having their own «bottoms» and «ups». So I must specify. The «bottom» is a set of elementary data manipulation operations available to you as a programmer or a data security specialist (although it is often the same «you»). The «top» is a transitive closure of this set. The set of operations available for a user is rather close to the «top», and mapping them into the basic data handling operations constitutes the essence of the programmer's job. The «bottom-up» approach to data security is a job of defining all the necessary data access rules in terms of the basic data handling operations — you apply certain restrictions to various data elements and they affect the data system overall behavior, namely data accessibility in the high-level terms used by the end users. The most elaborated text-book example of this approach is SQL — it gives you very low-level security bricks to build a custom building without specifying explicitly this building emergent properties.
Read more →

A Better SQL Security Approach

This is not only an SQL's problem, I am going talk about, this is a pretty general problem of all complex systems dealing with user permissions, however SQL constitutes the best possible illustration to the issue.The principal source of all evil is the generalized security policies, policies trying to cover the entire space of user actions by being formulated in basic general terms.
Read more →

An Embarrassing Security Hole In FFmpeg (how is it even possible?!)

A russian researcher Maxim Andreev (Максим Андреев) from cloud.mail.ru has discovered recently an appaling (and also embarrassing) security hole in FFmpeg (a popular open source video/audio processing library (yes, thanks god(s) it is open source)). The vulnerability may potentially lead to SSRF and local file read (which in turn may be pretty devastating). To put your computer at risk it is sufficient to keep it connected to the internet while processing with FFmpeg a specially crafted .mpeg file. So the attack may be aimed at servers and desktops as well, and it is important for the desktop users to know that nearly all GUI-oriented filemanagers and file-dialogs do run without a user's consent ALL the .mpeg files in the scope through the thumbnail creation procedure which is often built around FFmpeg library. Oh, my dear «user-friendliness»! Do you feel how problems are piling up?

The vulnerability is based upon the HLS (HTTP live streaming) feature (thanks to the reported vulnerability I now know what is live streaming — what a useful feature it must be). The core of the vulnerability is (as it happened many times before) a masquerade of filetypes multiplied by the stupidity of the modern days programmers. Effectively the worm is a PLAYLIST file masquerading as an ordinary .mpeg. And FFmpeg is programmed to process them «transparently» i.e. HIDE the distinction between them from the user. The playlist file is allowed to prescribe HTTP requeststs (supposedly to retrieve a file to play) and FFmpeg is eager to obey! Thus, FFmpeg being entitled to the access privileges of its caller SILENTLY sends HTTP-requests (full of potentially sensitive data) to an arbitrary HTTP-server in the internet.

Well done FFmpeg! well done!
And I personally send many non-sarcastic thanks to Maxim Andreev.

By the way, Maxim in his original article on habrahabr.ru describes some interesting practical exploits of the vulnerability, if anyone is interested, i can translate his article to English and post it here.

...and remember all vulnerabilities are deliberately created by someone.

This magic word "Cryptography"

This is a real life story. We were building an enterprise with micro-payments involved and stuff. We needed a terminal/kiosk network, and this task was bound to be outsourced. So my boss had found a company XYZ that offers ready-made solutions, and he asked me to investigate their offer. I returned to him with my verdict:
— we can't use this XYZ service, because they require our users to submit their passwords to XYZ and then XYZ logs into our system on user's behalf. This is plain out wrong, and should not be implemented ever.
He argued on the basis «a well established company can not possibly sell us junk» — so stunningly true! yeah! So he decided to carry out his own investigation.

A few days later he informed me of his decision:
— I have presented the XYZ's offer to a computer security specialist N. He advised us against using the XYZ's services because they do not employ cryptography.

So the story has ended quite happily. Thanks to the magic of the «cryptography».