When we think about the prevention of breaches and remaining secure, we usually start with tools such as WAF (Web Application Firewall) and anti-virus software. We then automate them to improve effectiveness, hoping it will protect our most valuable data.

But despite our preventive measures, why are security incidents still continuing to grow?

That’s because we are leaving people out of the picture. Educating people should be the initial and end goal. Ignorance, trust, greed, and laziness can open doors to attacks from anywhere in the world.

Cybersecurity is a people problem, the solution lies in the people.

Complete with tools as resources, we can create a secure and continuous environment.

Based on the agile methodology, we are all one team divided into groups of people with different outputs. The key is to integrate those outputs into a continuous workflow, where security is included in every step.

Security shouldn’t be an isolated department. We need to eliminate the security bottleneck by incorporating it into engineering. This way all members can help each other embrace a secure system. Sprint by sprint, the whole team must work together in the integration to reduce the risk level and increase security.

In the Coding & Building Phase → SAST & SCA

— > Run Static Application Security Testing (SAST) against Source Code or Binaries of an Application.

- After every sprint, write new rules into SAST or LINTER/Code Quality tool based on reports and tune them to avoid false positives

- It can be embedded into the IDE

- The best approach is Abstract Syntax Trees, as it makes it more accurate

- Integrating SAST into the repository with every Pull Request yields great advantages

- Only run incremental scanning on every Commit (Commit Hook) so you don’t slow down the dev process

Tools: Bandit, Brakeman, NodeJSScan, FindSecBugs, GoSec

— > Run Source Composition Analysis & Software Bill of Materials.

Software is rarely built from scratch. They are a complex collection of various libraries and third-party dependencies.

- Avoid Inherited Risk

- Manage Licence Compliance

- Identify Component Age

- Identify Know Vulnerabilities

- Avoid Typo-squatting (Lookalike naming for modules). Write rules to avoid NPM modules with identical names or identical names with punctuation

Tools: CycloneDX, NPM Audit, OWASP Dependency Track, Safety, OWASP Dependency Check, Snyk

— > Safeguard Secrets/Sensitive Information in Centralised Source Repos

- Avoid sharing API Keys, Passwords, etc..

Tool: Talisman

In the Testing Phase -> DAST & IAST

→ Parameterised DAST with Test Frameworks

- Give QA Team a single fabric for both Test Automation and Security Testing

- Use proxy tools. They allow you to drive the traffic of desired functionality

- DAST Scanners perform infinitely better with “parameterisation”, especially SPAs and Dynamic-Front-end apps. It allows the tool to bypass the spidering process - which is time-consuming and ineffective

- Integrate security into unit test cases

- You can create your whole pipeline in Robot Framework. This way it is technology agnostic and can be versioned.

Tools: Selenium, OWASP ZAP, Robot Framework

→ Interactive Application Security Testing

This test is sitting with your build agent, has access to source code and reads all requests, registering findings in the app based on the flows.

- Run it in your staging or dev env

- With this test in place, false positive are extremely low

- They are faster than most DAST and SAST tools

- Can match source code(SAST) and payload(DAST)

- Is a combination of 3 tools in a single set of workflows — SAST, DAST and SCA

Tools: Contrast Security, OpenRASP, Synopsys, Checkmarx

While Releasing & Deploying → Security in IaC (Infrastructure as code)

→ Scan your container configuration

Containers are just configuration-based services. They run in the same machine along many others. A weak configuration allows an attacker to gain access to the machine though your container.

- Avoid manual deploy

- Run SAST against Kubernetes YAMLs and Specifications

- Run SAST against Dockerfiles and Containers Specifications

- Don’t run the container with root privileges

Tools: DockerSlim, AppArmor, SELinux

Let’s Build Pipelines!

TIP: If the team is not mature in terms of security, don’t break the build. Work with them to understand why would it break.

Start with an autonomous pipeline, then gradually move to an incremental one.

Autonomous Pipeline

- Security must be oriented around a parallel pipeline. This way you don’t slow down the dev team process

- The security engineer in charge on this pipeline must HELP the dev team to learn

- Use multiple tools for the same purpose to validate findings

- Open source libraries give you the power to extend and customise the tool based on your needs

- Weekly or after release, exhaustive SAST, Source Composition and DAST (backed by test automation)

- Every two months exhaustive DAST with all test cases

Incremental

- SAST, SCA run against current code commit and affected files (commit)

- DAST runs against smaller modules on a daily basis, backed by Test Automation

Correlation results

- Integrate Results with JIRA/Other Bug Tracking Systems

- Integrate with Test Management Frameworks.

- Leverage JIRA Webhooks to track state

Tools: Archery, DEFECTdojo

→Success Factors←

- Dockerise all tools so you can run them in any environment

- Use many different tools for the same purpose to avoid false positives

- Open source tools give you the flexibility to adjust them

- Categorise the vulnerabilities by CWE Id for better integration across all tools. Different tool may call the same vulnerability with different names. Using the CWE id helps you avoid duplication.

- Gather metrics and inject findings into the process. (update regression tests, patch outdated dependencies, etc..) ← this is how the pipeline learns how to be more secure

Now Integrate the People!

1.Business team <-> Security engineer

The business team needs to work with security engineers to identify their biggest concerns. Concurrently, security engineers drill down on common threats based on their experience. Together, they can create user stories with threat associated modelling.

2.QA team <-> Security engineer

The QA team creates test cases based on these user stories (acceptance tests). Based on the initial threat modelling, security engineers can introduce abuser stories where the tests are written from an attacker’s point of view.

3.Dev team <-> Security engineer

A training program is very important. The security engineer should run a workshop to teach the dev team to code securely, focusing on topics such as the biggest vulnerabilities and how to identify them, as well as on how to be a part of the team and not just a consultant. If the dev team writes less buggy code, building stronger security capabilities will be much easier.

They can also open a pull request and add any security comments as most devs like to read there.

The security engineer should also put in place any tool that can help devs recognise insecure code automatically as soon as possible, and implement SAST (static application security testing) integrated in the IDE and on every build. Threat modelling concerns should be injected into the dev unit tests as well.

4.Pen tester <-> Security Engineer <-> QA Team

The Pen tester needs to run manual tests on logic flaws before the security engineer, along with the QA team, can write scripts as a regression test with the findings from the pen tests (app logic) and include them into the pipeline.

5.Incident Response team <-> Dev Team <-> Security engineer

Incident response involves a security engineer who can identity the breach based on existing patterns and allocate the right dev team to fix the code.

- Track the right metrics. DeviceID, IP, and UserID will provide all required information to track back and identify

- Query efficiently. Too much information is not helpful if it is not readable

- Equip the right tools, OSQuery is great

- Plan for the AppSec attack. Simulations will keep everyone ready. You don’t want to improvise at 3am…

Don’t forget…

→ If you had ever experienced or are currently experiencing culture problems before this, it’s unlikely that new technology can fix any of that. Fix your culture problems first.

→ Continuously educate all team members about security based on the findings and get them gradually more involved. Engage, rather than enforce.