Defense in Depth and DevSecOps

Defense in depth is a layered security approach where a number of security mechanism come together at different layers to protect your Application/Infrastructure against Cyber attacks .

Let me give you a relevant real life example of a medieval castle

Fig 1 : Defense in depth for a Castle

The Medieval castle: the ultimate in Defence. A medieval lord, ensconced in his chambers in the keep, could sit by the fire confident that any attackers would need months to penetrate the layers of security that stood between him and the wilds of middle-ages Europe. His protection went beyond a simple reliance on thick stone walls; he was protected by a specific, proven approach to security known as Defence in Depth.

The same concept applies to Cyber security . Defence in Depth is the simple principle that while no security is perfect, the presence of many independent layers of defenses will geometrically increase the difficulty of an attacker to breach the walls, and slow them down to the point where an attack isn’t worth the expense it would take to initiate it. Each layer multiplies the effects of the previous layer. If the outer wall deters 90% of attacks, and the inner walls deters 90% of attacks, then in combination they deter 99% of attacks. Defence in Depth places the core assets behind layers of varied and individually effective security, each of which has to be circumvented for an attack to be successful.

In DevSecOps Defense in depth plays a vital role . Security mechanisms should be designed in such a way that they provide with a layered security approach. Please refer MITRE ATTCK MATRIX before proceeding further

• For eg : A SQLi vulnerability can be detected at WAF , SAST , DAST , SIEM. All of them offer the same outcome but at different stages of SDLC.
• Similarly , an exploit can be prevented by updating the vulnerable library(SCA) — you remove the vulnerability itself and thus Initial access is prevented . If by any chance Initial access occurs then Container Security (CS) can prevent further damage by preventing privilege escalation and lateral movement.

Fig 2: Prevention at different stages of an attack

Fig 3: Initial access — Vulnerable third party software

Fig 4: Privilege Escalation & Lateral movement

• The first step towards the DevSecOps approach is Threat modelling and Security architecture review .

Fig 5: DevSecOps Standard Model

• Security architecture review/design is nothing but just a manual review methodology to determine security flaws in infrastructure design and traffic flow.
• It is mainly divided into 5 parts :

→ Secure Network Flow

→ Secure API design

→ Secure Web application Design

→ Secure Infra and cloud components Design

→ Secure Cluster design

• If we have a threat modelling report with us and then proceed to design the architecture with the defense in depth approach , the impact of the breach if any occurs can be controlled to a great extent .
• Plus , you will have a attack resistant architecture way before you even start implementing any other security mechanisms .
• For eg: A zero day vulnerability exploit led to RCE of the internet exposed microservice . However , the access to database is restricted for the microservices via Identity and access management (IAM)control. In this scenario , IAM saved the day and the potential impact is data leakage but no modification/deletion. But , after reviewing the architecture you detected no Network ACLs for the DB ( which is a critical asset) so you apply the same. Now , from compromised microservice no traffic can hit the DB .
• Thus you can see how securely designing the architecture saved you even before applying the IAM security mechanism. Just keep in mind that this secure design should always be coupled with Defense in Depth.

Security architecture design by Defence in Depth methodology — Secure Network Flow

Consider the below microservice architecture running on Azure Devops and Azure cloud environment :

Fig 6: Microservice Application hosted on Azure cloud

Step 1 : Determine critical assets

• For a castle , the Kings chamber is the most critical asset and all the layered protections are focused in defending the same

Fig 7: Defense in depth focused at Critical asset (Kings Chamber)

• Similarly , for our given application the critical assets are the databases which holds its heart and soul .

Fig 8: DB and Offchain DB as critical assets

Step 2: Know your Attack and Target

Have a look at these definitions below ;

Describes the Attack:

· Attack Vector: the ‘route’ by which an attack was carried out. SQLi is typically carried out using a browser client to the web application. The web application is the attack vector (possibly also the Internet, the client application, etc.; it depends on your focus).

· Exploit: the method of taking advantage of a vulnerability. The code used to send SQL commands to a web application in order to take advantage of the unsanitized user inputs is an ‘exploit’.

Describes the Target:

· Attack Surface: describes how exposed one is to attacks. Without a firewall to limit how many ports are blocked, then your ‘attack surface’ is all the ports. Blocking all ports but port 80 reduces your ‘attack surface’ to a single port.

· Vulnerability: a weakness that exposes risk. Unsanitized user inputs can pose a ‘vulnerability’ by a SQLi method.

Now , the thing we need to do here is map these 5 values for your Critical assets

Possible Risk : Deletion, manipulation or exfiltration of confidential data

Threat : SQL injection

Attack vectors (how you enter) : Input from untrusted source

• Client browser to frontend
• Direct API calls from malicious user to Backend 2

Attack Surface (from where you enter): Frontend container , Backend 1 container

Possible Vulnerability : Unsanitized user inputs .

Step 3: Draw the entry path(attack surface) from attacker to critical assets

Fig 9: Entry Points for a potential attacker

Step 4: Place checkpoints along the path

Things you need to consider before placing the controls :

• Focus on the threat and corresponding vulnerabilities determined in STEP 2
• Make sure all the possible attack surfaces are addressed
• Refer MITRE ATTCK Matrix for the possible Tactics , techniques and procedures for the RISK determined in STEP 2

NOTE : You are not adding any security mechanisms ( eg : SCA,SAST,etc) here but just making sure traffic moves securely without exposing any security loopholes ( all this in the plan phase of SDLC )

Fig 10: Defense in Depth based Application architecture and traffic flow

Lets understand every Line of defense (Lod) in detail :

Lod 1 : Content security Policy , Security headers to prevent client side/Browser based attacks which can compromise the Frontend Microservice and thus lead to lateral movement which can eventually reach the critical asset .

Lod 2 : A perfectly tailored WAF rules based on legit expected traffic can help you block the malicious payloads before it reaches your application.

Lod 3 : Azure load balancer can be used to attain security features like setting HTTP response/request headers , TLS encryption , Rate limiting , etc.

Lod 4: Enable private communication between Application gateway and Ingress . Configure Network ACL to allow traffic only from Application gateway.

Lod 5: Input validation and output encoding at frontend Microservice

Lod 6: Network ACLs to prevent lateral movement

Lod 7 : Securing backend exposed to internet with Azure front door gateway and WAF

Lod 8 : API manager to define ,whitelist , authenticate and authorize APIs .

Lod 9 : Load balancer to expose the microservice securely (TLS, Security rules and headers )

Lod 10 : Input validation and output encoding at backend 1 Microservice

Lod 11 : Network ACLs to prevent lateral movement

Lod 12 : IAM protection for DB

Lod 13 : Network ACLs to prevent lateral movement

Lod 14 : Input validation and output encoding at backend 2 Microservice

Lod 15 : Network ACLs to prevent lateral movement

Lod 16 : Configure your AKS as per security best practice

Lod 17 : Configure strict IAM policies for every cloud resource provisioned. Make sure to whitelist ingress/egress if any of the resource is required to be exposed to Internet . Follow cloud security practices

• Now , have a look at Fig 2 . Security architecture review and design is just the first step towards your DevSecOps model.
• You now definitely have a attack resistant architecture but there are a number of vulnerabilities which may be present along the attack path.
• For eg : Frontend microservice has a vulnerable library which leads to RCE attack →frontend pod is having access permission which leads to container escape attack → attacker is now able to delete/modify your critical assets(DB)
• In order to prevent the above attack scenario you need to place other security mechanisms at different stages of SDLC to detect the security loopholes and vulnerabilities.

This way security mechanisms will intervene at different stages of attack and provide defense in depth.

Lets understand how this will help you in above described attack scenario:

Fig 11: Detection in depth

• SCA can help us catch the root cause ( vulnerable library ) during build phase ***blocks initial access*** Fig 11: Detection in depth
• Container Security mechanisms like ( Docker lint , K8 hardening) can help us identify the insecure YAML of frontend microservice during build phase *** blocks lateral movement and privilege escalation***
• DAST can help you identify RCE during testing phase ***blocks initial access***
• VAPT (AKS and WEB) can help you identify loopholes in your AKS and Pods provisioned on it during Staging Phase ***blocks initial access ,lateral movement and privilege escalation ***
• Monitoring tool like WAF can block RCE packets , SIEM tool can help you identify attack using behavioral analysis even if all the security mechanism fails to detect any vulnerability during Operation phase. ***Blocks collection, command and control, exfiltration and Impact***

So , we can see how every stage of attack is tackled at different phases of SDLC . That's the beauty of DevSecOps with Defense in depth