In this industry, many companies already know the value and need for automation, but most don’t have, or can’t find, the talent to implement.
CDA delivers DevSecOps services and develops top talent with speed. During our upcoming DevSecOps webinar, we will demonstrate how to effectively integrate security into your DevOps, DevSecOps, and SecOps programs to protect devices in your environment from the most common threats of 2020.
We are always looking for a better way to validate security solutions for customers and help them realize where the gaps are in their existing security infrastructure. We focus on the people, the processes, and the platforms in place to ensure all the security sensors and tooling are working as expected. If they are not, we help them remediate the issue and continuously evolve.
The driving force for use case and requirements development is answering these and other questions:
Are we familiar with the top endpoint or web attacks used in the wild?
Are we familiar with the top web attacks used in the wild?
Does the DevOps team include security and risk assessment as part of their CI/CD pipeline workflow?
Are we sure our endpoint detection and response (“EDR”) solutions are working as expected to secure your environment?
Can we effectively capture the “right” artifacts in the SIEM without inundating the team with too much noise?
Here’s a sneak peek into the lab environment we will be demonstrating in our next webinar:
Platforms and Infrastructure
The overall lab is broken down into two different, purpose-built environments. The first is for testing our EDR and supporting infrastructure. This includes predominantly Windows systems, except for our attack infrastructure. We call this the EDR Lab, for endpoint detection and response testing. The second is our Web App Attack Lab, which is used for attacking web applications hosted in the DMZ behind a firewall. The numbers below provide some additional detail about the infrastructure and platforms in use. This is only a lab environment for the purpose of demonstration. We’ve included specific tools to demonstrate common use cases and impact.
1. Control Environment: Demonstrates the attacks without any tools in place. The goal is to demonstrate the effectiveness of the attacks on unprotected systems. This environment contains some very basic components:
Domain Controller: Windows Server 2019 Domain Controller with all the necessary supporting services (DNS, etc.)
Workstation: Windows 10 installation with default settings
Built-In Security Tools: We intend to use the out-of-the-box security features in the Windows operating system.
2. Locked Environment: Demonstrates validating our actual security controls, if everything goes as planned our security will prevail. This part of the lab includes the following:
a. Domain Controller: Windows Server 2019 Domain Controller with all the necessary supporting services (DNS, etc..) and our basic security stack. The stack includes the following for this lab:
Sysmon + Winlogbeat: We will install Sysmon and Winlogbeat. This will allow us to capture artifacts from the attack and send it to the SIEM for review or automated responses. The Sysmon configuration will be based on the widely used SwiftOnSecurity configuration (https://github.com/SwiftOnSecurity/sysmon-config).
Windows Defender: For the sake of simplicity we are using Windows Defender, since it is predominantly a detection-based solution, it does not really matter for the lab. We almost wanted to install Bromium on the Domain Controller, but resisted the urge.
Ivanti Application Control: In lieu of using a solution like AppLocker, we are adding Ivanti Application Control to the environment to enhance our application whitelisting and to control administrative rights for locally installed applications.
Sysmon + Winlogbeat: Same/Similar to DC configuration with some exceptions.
Windows Defender: Same/Similar to DC configuration with some exceptions.
Ivanti Application Control: Same/Similar to DC configuration with some exceptions.
CIS Security Baseline Configuration: Same/Similar to DC configuration with some exceptions (Windows 10 Baseline).
NOTE: We will most likely add Bromium to this config later if time allows.
3. Assumed Breach Attack Infrastructure:
MITRE Caldera: This set of tools is great for automated attack campaigns, we will use this to execute several attacks based on the MITRE ATT&CK framework with some support from the tools and research from Atomic Red Team and Red Canary.
Kali Linux: This set of tools is worthy of way too much detail to provide in this blog article. If you have never heard of Kali Linux, you need to check it out. We will use several of the tools included with Kali Linux to attack our infrastructure and test both the Control and Locked environment.
4. Automation Infrastructure:
Jenkins: We will use Jenkins to schedule jobs and for automation tasks.
Jira: Jira will be used for ticketing and issue reporting workflows associated with any automation tasks.
SIEM: ELK/Elastic: For our Security Information and Event Management, and mainly for log aggregation we will use ELK with any necessary add-ons.
Ansible Tower: While I am a fan of REST-APIs for automation, you need to consider environments where HTTP services may be blocked by policy, for that reason we plan to use some Ansible/YAML tools to automate things like Firewall audits and configuration lockdown, as well as automated black listing.
5. Control Environment: Demonstrates successful attacks against our web applications.
OWASP Juice Shop Project: For the purposes of testing a known vulnerable set of web applications, it is hard to use anything other than the vulnerable web app projects available from OWASP. For demonstrations and testing this is a great platform. It is also great for testing out your penetration testing skills.
VIP-NO-WAF: To support the Control Environment we will use an ADC hosted load balanced VIP (Virtual IP), pointing to the same web applications as the Locked Environment.
Layer 4 Firewall: The layer 4 firewall will be a Cisco ASAv, in this case you can use any firewall. We went for the most commonly deployed firewall used by our customers. This will be used for protection of the DMZ resources and will also be used to add visibility to attacks and provide an endpoint for some of our automated responses to attacks.
6. Locked Environment: Demonstrates a few more security controls and some event forwarding tools to collect artifacts.
OWASP Juice Shop Project: Same as above…
VIP-WITH-WAF: To support the Locked Environment we will implement an ADC based Web Application Firewall and supporting policies/profiles to protect against common attacks. In this lab we will leverage SNORT signatures as our source for attacks.
Layer 4 Firewall: Same as above…The layer 4 firewall will be a Cisco ASAv, in this case you can use any firewall. We went for the most commonly deployed firewall used by our customers. This will be used for protection of the DMZ resources and will also be used to add visibility to attacks and provide an endpoint for some of our automated responses to attacks.
7. External Pentest Attack Infrastructure:
Kali Linux: Same as above.
The lab environment described above is always evolving. During our webinar and subsequent blogs, we demonstrate how to effectively integrate security into your DevOps, DevSecOps and SecOps program to protect devices in your environment from the current most common threats of 2020 using tools like:
Atomic Red Team
Web Application Firewalls
During the webinar will discuss and demonstrate the following both manually and using automation and the tooling necessary to identify, protect, detect, respond, and recover:
SecOps Automation and Orchestration using Atomic Red Team/MITRE ATT&CK) (5 Demos)
T1055: Process Injection
T1053: Scheduled Tasks
T1077: Windows Admin Share
T1105: Remote File Copy
2. DevSecOps: OWASP Top 10 (3 Demos)
- SQL Injection (SQLi)
- Cross Site Scripting (XSS)
Sensitive Data Exposure (SDE)
Be Sure to check out the recorded webinar “The Power of DevSecOps Automation” on our YouTube channel!