Security architecture and zero trust

Classic networks were built like a “castle and moat”: a strong outer firewall and full trust for everything inside. Today staff work from home, data lives in the cloud, devices sit in pockets and contractors connect with their own laptops. One employee fooled by phishing is already “inside” and can move freely across the network. The zero-trust model is the answer: “never trust, always verify”.

Defence in depth: the probability of layers

Defence in depth builds several imperfect but different layers: training, physical security, the perimeter, segmentation, the host (EDR, updates), the application and the data (encryption, backups). An attacker has to get through all of them. If the layers are independent, the probabilities of independent events multiply:

Zero trust: principles and components

The US National Institute of Standards and Technology document NIST SP 800-207 (2020) describes zero-trust architecture. The key ideas: network location grants no automatic trust; every access to every resource is authenticated and authorised separately; rights are minimal and granted per session; decisions rely on several signals — identity, device health, behaviour, time and data sensitivity; everything is monitored continuously and designed on the assumption that a breach has already happened.

SENSITIVITY = {'timetable': 1, 'grades': 2, 'payroll': 3}

def decide(req):
    reasons = []
    if not req['mfa']:
        reasons.append('no MFA')
    if not req['device_ok']:
        reasons.append('device not compliant')
    if SENSITIVITY[req['resource']] > req['clearance']:
        reasons.append('role not allowed')
    if SENSITIVITY[req['resource']] == 3 and req['risk'] != 'low':
        reasons.append('sign-in risk too high')
    return ('ALLOW', []) if not reasons else ('DENY', reasons)

requests = [
    {'user': 'aysel', 'resource': 'grades', 'clearance': 2, 'mfa': True, 'device_ok': True, 'risk': 'low', 'network': 'home'},
    {'user': 'murad', 'resource': 'grades', 'clearance': 2, 'mfa': True, 'device_ok': False, 'risk': 'low', 'network': 'office'},
    {'user': 'leyla', 'resource': 'payroll', 'clearance': 3, 'mfa': True, 'device_ok': True, 'risk': 'high', 'network': 'office'},
    {'user': 'elvin', 'resource': 'payroll', 'clearance': 1, 'mfa': False, 'device_ok': True, 'risk': 'low', 'network': 'office'},
]
for r in requests:
    verdict, why = decide(r)
    print(r['user'].ljust(6), r['network'].ljust(7), r['resource'].ljust(8), verdict, why)

aysel  home    grades   ALLOW []
murad  office  grades   DENY ['device not compliant']
leyla  office  payroll  DENY ['sign-in risk too high']
elvin  office  payroll  DENY ['no MFA', 'role not allowed']

Availability architecture: series and parallel

The “A” of the CIA triad is also a job for architecture. If components are connected in series (web server → database), the system works only when all of them work. If they are in parallel (two identical servers), the system stops only when all of them fail at once. For independent failures:

Connections: zero-trust ideas are applied in Google's BeyondCorp project, in cloud providers' identity services, in mutual TLS (mTLS) between microservices and in micro-segmentation. The availability formulas are used in cloud architecture (several data centres), in SRE practice and in service-level agreements (SLAs).

def series(*parts):
    # multiply all availabilities
    return 1

def parallel(*parts):
    # 1 - product of (1 - a)
    return 1

web = parallel(0.99, 0.99)
db = parallel(0.999, 0.999)
total = series(web, db)
print(f'web tier: {web:.4%}')
print(f'db tier: {db:.6%}')
print(f'whole system: {total:.4%}')
print(f'downtime per year: {(1 - total) * 365 * 24:.2f} h')

web tier: 99.9900%
db tier: 99.999900%
whole system: 99.9899%
downtime per year: 0.88 h