Neuroprivilogy is the Holy Grail

Is your Neuroprivilogy vulnerable?
The answer is most probably yes, you simply have no clue what Neuroprivilogy is (yet)…

The first step with any discussion is defining a fancy term to describe the phenomenon. That’s where Neuroprivilogy came about.
As the name suggests Neuroprivilogy is constructed from the words neural (network) and privileged (access), and can be defined as the science of privileged access points’ networks. Using the neural network metaphor, organization’s infrastructure is not flat but a network of systems (neuron=system). The connections between systems are access points similar to synapses (for neurons). Some of these access points are extremely powerful (i.e. privileged) while others are not. Regardless, access points should be accessed only by authorized sources.

This privileged access points’ network is vulnerable as you’ll find out by observing the Neuroprivilogy vulnerability 7 fallacies:

1. These access points have limited permissions
Systems almost always use proxy accounts to interact with other systems (e.g. application to database). Now let’s be honest – when was the last time we used any type of mechanism to restrict systems’ access based on anything (e.g. propagate end user permissions to the app-database interaction)? In most cases we simply grant privileged access rights to systems. Hey, it is much easier to use most permissive access rights required as the common (permission) denominator…

2. Given the associated high risk I probably already have controls in place
Does anything from the following list sounds familiar? Hardcoded passwords, clear text passwords in scripts, default password never changed, if we’ll touch it everything will break… The irony is personal accounts for real users has very limited access rights, while having stricter controls (even simple ones such as mandating frequently password change).

3. But I have all those security systems so I must be covered, right?
This topic calls for a separate blog post altogether, however I’ll point out the fundamental principle of most systems handling users and accounts (such as IAM, SIEM, GRC, etc.) - the prerequisite to all operations is identification of users. They are great tools for personal accounts correlated to known users, and not really for privileged access points used by non carbon based entities. The solution is very simple – use the adequate tools!

4. Privileged access points vulnerability is strictly for insiders
Picture yourself as the bad guy, which of the following would you target? Personal accounts with limited capabilities protected by some controls, OR privileged access points with limitless access protected by no control? The notion of an internal access point is long gone; especially with the borderless infrastructure trend (did I say cloud?).

5. Adding new systems (including security) should not impact my security posture
That’s where it gets interesting. Most systems interact with others, whether of infrastructure nature (such as database, user store) or services. Whenever adding a system to your environment you immediately add administrative accounts to the service, and interaction points (access points) to other systems. As already mentioned most of these powerful access points are poorly maintained, causing a local vulnerability (of the new system) as well global vulnerability (new system serves as a hopping point to other network nodes). Regardless, your overall security posture goes down.

6. I have much more accounts for real users than access points for systems
Though this fallacy might sound right, the reality is actually very different. It is not about how many systems you have but the inter-communication between them. Per enterprise customers I’ve talked with, the complexity of the network and magnitude of this challenge will surprise many.

7. This vulnerability is isolated to my traditional systems
Some of the more interesting attacks/breaches from the past year present an interesting yet non-expected trend. The target is no longer confined to the traditional server, application, or database. Bad guys attacked source code configuration management systems (Aurora attacks), point of sale devices, PLC (stuxnet), ATMs, Videoconferencing systems (Cisco), etc. The extent of this phenomenon is actually very surprising. I even heard the other day, pacemakers has privileged accounts (for remote management). Now this is what I call a life and death type of vulnerability!

When observing these fallacies and APT attacks characteristics, you realize Neuroprivilogy vulnerability is the Holy Grail for APT attackers. It perfectly fits the APT characteristics - not about quick/easy wins, but rather very patient, methodological and persistent attacks targeting a well defined (big) “prize”. You work the privileged access points’ network until finding the way in and winning the “big prize” (limitless access to the required/targeted parts of the infrastructure).

The dummy version of comparing traditional to APT attacks is: traditional = a quick and easy win, APT = keep your eyes on the prize.

Now going back to my opening question – is your Neuroprivilogy vulnerable? (No need to answer, just a rhetorical question)

BTW – an interesting TED talk about neural networks and how it actually defines us: http://www.ted.com/talks/sebastian_seung.html