Control vs intelligence
Control does not require intelligence, intelligence does
I will go a little geeky on you this week. I have written this post a few years back, while working for large IT outsourcing company. I am sharing it now because I wish to expand on it in a new post.
Contrasting these concepts have implications reaching far beyond IT security.
When I told my manager, as an introduction to a point I wanted to make about a particular problem we were working on, that there are two approaches to security: control and intelligence, he started to laugh. I was not trying to be funny, so it took me a few second to realize why he was laughing.
A few weeks prior we had a conversation about some of the other teams.
My team shared the floor with a service desk team. They were first responders to various end-user issues. The team was dissolved when the function was moved to a cheaper location. Some people left, some moved with the job, some moved to other teams.
The two least capable guys on the floor ended up with the security team. They were both VERY nice guys. Very polite, respectful and helpful. They were just not very smart, to the point that I had difficulties communicating with them. I have below average patience for below average competence.
I found it ironic how security, with its claim of importance seeks and finds candidates with limited abilities and I shared my thoughts on it with my boss. That is why he was laughing, but that’s not what I meant with my comment.
I meant the other meaning of the word intelligence: information gathering, monitoring and analysis.
Intelligence actually does require intelligence which is one of the many reasons why most organizations tend to emphasize control instead. It is easier to focus on control than on intelligence.
We can either apply minute control to prevent breaches, or use monitoring to catch and track breaches.
We always have both approaches at work as any configuration represents some sort of control defining what is and what is not allowed, but when we step beyond that basic, we have to choose what to emphasize: control or intelligence.
In conceptual terms, security is a very simple thing. We need to define the entity to be protected, who or what can act on that entity and what those actions can be.
The entity can be just about anything. Facility, network, VPN, firewall or a single port of it, domain, server, service, network device, phone, voicemail, mailbox, database, DB table, you name it.
When it comes to the entity the most important question is the definition of its scope. A definition of what we apply the security to, what are we trying to protect.
The actor can be a person, a process, a protocol, a program or algorithm - anything that have the power to act on the entity.
When it comes to the actor, the most important aspect is the definition of its identity, including the understanding what this actor is capable of doing.
The act can be anything that can be done with the entity. Opening of a secured door, passing traffic through a firewall port, accessing a VPN or a domain, making changes to a document or record, starting a process, etc.
When it comes to the act, the important point is the tracking of the act, the ability to determine who acted on the entity and in what way did the act change it (if it did).
While this may seem like a long introduction and what I said may seem to be painfully obvious, I had to make them to show how the lack of understanding of these concepts is responsible for most domain management related security problems.
The problems
The scoping of the entity is either too small or too big. I have seen millions flushed down the toilet in projects trying to micromanage the scope of objects to which rights should be assigned separately. Years of delays and the cancellation of whole projects happened because the security team was fighting tooth and nail for retaining control over every single AD attribute making some applications inoperable in the process. They were able to do that because the corporate sponsor of the project gave them absolute authority. They decided that security is more important than the application it was supposed to protect.
This is an acute problem of outsourcing organizations with their institutionally cultivated distrust between teams that are supposed to cooperate.
I have also seen organizations where just about anybody and their uncle was allowed to do just about anything. I have seen several organizations with self-administered groups as members of the enterprise admin group. The lax scoping problems often come around as a rebellion against excessive controls. Controls make it difficult for admins to do their work and they either use major outages as excuses to remove them or to find ways to work around them.
The most problematic aspect of security is the identity of the Actor. Controlling people is easy in theory. In practice we have service accounts, group accounts, functional accounts and the likes. In most organizations, user accounts represent less than half of the Active Directory user accounts.
The greatest threat to a network is passwords for all powerful service accounts being exchanged in unencrypted e-mails. I have been subjected to several audits performed by major organizations such as KPMG making a fuss about the number of user accounts in the domain admin group while completely ignoring the danger represented by all powerful service accounts with their freely distributed passwords. In most organizations, nobody has a clue what is being done by those accounts.
The questions
The questions organizations need to ask from themselves is what exactly do they expect from internal security. What exactly are they trying to protect themselves from? Sabotage? Incompetence? Stealing? Spying? The typical answer would be ALL OF THE ABOVE but I hope you see how this is a cop out. Yet this is what most organizations do because they are too lazy to think about it.
The source of most security problems are incompetence and internal politics.
Business managers just want to make sure that only the ‘right’ people with the right skills will touch the systems. To make sure that a receptionist cannot delete the customer database or the desktop support guy will not start a script that will patch and reboot every server in the middle of the day. The bulk of the security efforts is directed to internal politics and not against outside threats.
Control is the lazy way to do security. The idea behind it is that once you establish and configure it, you can consider your security work done. If you have your policies established, you can use trained monkeys to manage them which is the aim of most organizations. You lay down the rules then make sure that nobody will deviate from them.
The two guys I was talking about at the beginning were the perfect examples of the attitudes associated with this approach. They were following the rules and made no exceptions. They did not have to think about what they were doing; they were just following the rules. Working in a security team was easier for them than working with end-users in the desktop support team. It’s a good thing to be a security guard. The rules are simple and they make you feel powerful.
The proper way to do security
The proper way to do effective security is simple:
Relax the scope
Be militant about the identity
Monitor and record every single activity
To understand this point, you have to start from the end. To be truly ‘in control’ of your network, what you need is information. The way to achieve that is through monitoring.
What you need is intelligence.
The company that fired me for writing posts like this has increased its market valuation fourfold since I parted with them in 2016. The level of incompetence in their Dilbert world was so alarming that I sold all my stocks as I was convinced that they will go down. I was clearly wrong.
What do you think: did corporate incompetence increase or decrease in the past eight years?
Like everything else on Substack, this is a reader supported publication.
You can help it by following or subscribing.
You can engage with it by clicking on like and/or commenting.
A ‘like’ costs nothing and is worth a lot.
You can help this Stack grow by sharing, recommending, quoting or referencing it.
You can support it by pledging your financial support.
Any and all of it will be much appreciated.