Security Architecture

[IDNeon]

Something Im working on while desperately trying to avoid "reinventing the wheel" is Security Architecture. 

And what that entails is building a network so that all its components are secure. But not with the frame of mind that vulnerabilities are patched and best practices are implemented. But from the frame of mind that attacks work on certain strategic principles and to prevent those principles from ever being exploited in the first place.

For instance in the most basic sense: an attacker controls a workstation and seeks privilege escalation or other credentials.

In most networks this workstation might have an administrator profile that was once logged in. Theoretically an attacker could use the credentials of that account to access other parts of the network.

Security Architecture attempts to implement compartmentalization completely, so that this is not the case.

The problems I run into is effectiveness. For instance enforcing compliance so that the implementation cannot simply be bypassed.  That's where my skill as a technical hacker is limited, and where I tend to do better with theoretical.

If all good soldiers made good generals then all soldiers would be generals. That maxim simply illustrates that a strategist need not necessarily be a good tactician or technician. But it would greatly help for me to have some pool of talent who are technically competent to help see the areas they would attack, that I can integrate a proper implementation of a technical control to prevent the purpose of the explout from ever existing.

The problem gets deeper and deeper as you explore each part. For instance if the goal is to isolate admin credentials so workstations compromised won't also compromise servers.

But then you have to enforce policies that limit domain users from logging onto servers at all. If so then what servers? Because those users may need some servers to be accessible.

Then how to prevent all sorts of other pathways of attack. What about hash passing? Man in the middle during remote logins?

Basically the architecture would have to isolate each facet while keeping the intended purpose working properly.

For instance if servers and workstations are on the same subnet then theoretically an attacker could packet capture and determine credentials or posion packets intended for servers.

So part of the architecture must include proper subnetting for that reason. 

On that note, I'll leave it there for now. I have been drawing out a high level diagram to help me sort out the many parts. When it's complete I can possibly share it with the intention of drilling down deeper to each element.

[IDNeon]

So I have begun building the outline for this comprehensive topic. The paper as im currently working on includes:

Logical controls. 

Control mechanisms.

Technical controls.

These 3 things describe the intention of your controls (logical controls) the bridge between your intentions and how to achieve those intentions (control mechanisms) and the controls as actually applied in a system suchas GPOs. (Technical controls).

Similar to programming, you have a problem, pseudo code to describe how to solve the problem and then the actual code that solves the problem.

Logical controls, continually asks the question, does my technical controls meet the obejctive? And the logical control should be an effective objective.

In the paper I begin to identify logical controls and attempt to briefly explain why they are effective, using citation to source material. For instance.

Logical control - limit users to workstations only. Reason? Pass the hash and other lateral attack methods.

Control mechanism - deny local logon, gpo controlling RDP, AD property logon computer.

Technical Controls - these would be the exact procedure to implement (for instance) Deny/Allow local logon with the intended outcome (user cannot log into server locally, but admins can).

 

This method can be expanded to all strategic objectives, described in this manner, then drilled down individually with citations for each methof and discussions how each method is effective.

Edited January 12, 2018 by IDNeon

[IDNeon]

Update: some areas of focus have emerged.

The goal continues to compartmentalize authenticated users so that a compromise in one compartment does not compromise the other.

This leads to the concept of the server compartment being the core, while the other compartment or compartments (note the multitude) is for the endpoints.

The problems here to be addressed is what happens to the compartmentalization when IT employee Bob tries to login to a workstation with a server-admin credentials.

Through various technical controls I've narrowed it down to as far as the authentication request is sent but not validated and no session key is returned.

However, is this enough? From that compromised workstation the attacker now has half of the key. The authentication request.

Can they pass this to another computer where server-admin is allowed a logon?

Or is there specifics to each request that prevents this pass?

Depending on that answer, compartmentalization may be achieved.

As for another issue.

Compromised endpoints may make-up a network of compromised devices with a command and control link. You may wipe one or several devices, even the current c&c, but as long as one compromised endpoint exists to take over as c&c then the attacker can continue to operate and expand in your network.

To isolate this potential may require extreme subnetting. In a subnet with proper access control. Where each endpoint only communicates outside of that subnet through its core. Then it is possible to isolate this network of compromise to just that subnet. In which case you can wipe all the endpoints in the subnet to nuke any c&c that would restore the network-of-compromise.

That concept is only starting to be developed but I think it's a step in the right direction.

[barry99705]

Don't forget to take into account useability.  I've seen networks so locked down they were almost useless.

[IDNeon]

On 1/29/2018 at 9:31 AM, barry99705 said:

Don't forget to take into account useability.  I've seen networks so locked down they were almost useless.

Unspoken truth for sure.

A real world example was a network I recently had to walk in on because of how messed up it had gotten by a number of issues. And one of them was the onsite IT moved the wrong servers physically to ports assigned to the wrong vlans for those servers. Among other physical issues. Such as switch configuration inconsistencies and problems.

Point being. Given how complex a working infrastructure can become. When I'm crafting this document the word "actionable" comes to mind.

If you have to build a space shuttle chances are your clients won't be able to.

But also actionable implies not just the useability for the end user and onsite admin. But the effectiveness of what can be implemented. 

Ideally I'll have this so much like legos that management can pick and choose what's most actionable for their needs while remaining effective and providing enough security to meet the expected risk. 

Edited January 31, 2018 by IDNeon