CyberSecurity

01- Definition:

The software project lifecycle model has been evolved from waterfall to agile model, and now commonly used the Scaled agile framework.

In order to onboard the security practices within the software development lifecycle, the term DevSecOps has arisen starting from 2015 by different entities like Gartner, OWASP and NSA.

The term DevSecOps includes the SEC section between the development and operation to onboard all required activities related to the security within the software development lifecycle.

02- Process:

Here are the key DevSecOps practices summarized:

1. Shift Left Security:  Integrate security early in development (design, coding), from planning, analysis, design, implementation, deployment, and even after deployment by operations monitoring.

We will discuss the details hereunder, to clarify the security requirements management during the SDLC. 

2. Automated Security Testing
   Use tools for static (SAST), dynamic (DAST), and software composition analysis (SCA).

3. Threat Modeling
   Identifying risks before coding using STRIDE, OWASP, or MITRE, it helps identify early potential threats within your solution.

4. Secrets Management
   Prevent hardcoded credentials with vaults and scanning.
   Use vaults (e.g., HashiCorp Vault, AWS Secrets Manager). 

5. Dependency Scanning:  Continuously check third-party libraries for vulnerabilities.

• Snyk or OWASP Dependency-Check for small enterprises

• JFrog Xray or Sonatype Nexus IQ for large enterprises  

6. Security as Code: Define policies and configurations in code (e.g., OPA, Terraform), intersected with others.

7. Policy Enforcement in CI/CD
   - Block builds/releases if security checks fail.
   - Example: Enforce quality gates in SonarQube (e.g., no critical bugs allowed and the same for vulnerabilities)

8. Runtime Security Monitoring

• WAF: We application firewall

  • • Protect solutions from attacks

    • Sample: Blocks/alerts on web attacks like SQLi, XSS

    • Tools: 

• SIEM: Security Information and Event Management 

  • Collects, analyzes, and correlates security logs from multiple sources 

  • Tools: Splunk, IBM QRadar, Elastic Security, Azure Sentinel  

• IDS:Intrusion Detection System

  • Detect and respond to threats.

  • Snort, Suricata (NIDS), OSSEC (HIDS).

  • Focus on all network activity, not like WAF scope

  • Comes after WAF in the architecture, after the load balancer
    
    

9. Zero Trust Principles
   Enforce least privilege and continuous authentication.
   
   

10. Security Training
    Educate developers on secure coding and common vulnerabilities.

03- DevSecOps Benefits:

1. Early Security Integration
   Embed security checks early in development.
   Sample: Use SAST tools like SonarQube integrated into the IDE or CI pipeline.

2. Reduced Risk
   Continuously detect vulnerabilities to prevent surprises.
   Sample: Weekly vulnerability reports generated by OWASP Dependency-Check.

3. Improved Compliance
   Automate audit trails and enforce security policies.
   Sample: Use OPA/Gatekeeper to enforce Kubernetes security policies automatically.

4. Cost Efficiency
   Fix security issues early to reduce expensive fixes later.
   Sample: Automated unit tests that include security assertions to catch issues upfront.

5. Higher Quality Code
   Detect and fix security bugs during coding.
   Sample: Use ESLint security plugins combined with peer code reviews.

6. Automated Governance
   Enforce security policies as code with automated pipeline gates.
   Sample: Fail builds automatically on high severity security issues using GitLab CI security gates.

7. Continuous Monitoring
   Detect threats and anomalies in real time.
   Sample: Deploy Falco for runtime threat detection in Kubernetes or OpenShift clusters.

05- Shift Left Security within SDLC

5.1 Definition: Shift Left Security in Agile Engineering is the proactive integration of security practices, tooling, and expertise into the earliest stages of agile development, starting from persona definition, user story formulation, architecture, detailed design and coding, so that security is embedded into engineering workflows. 

This approach ensures that security considerations evolve in parallel with functional/non-functional requirements, enabling iterative detection, remediation, and prevention of vulnerabilities as part of routine sprint activities, rather than as a separate post-development phase.

5.2 Persona definition: Hacker Focus

During this phase, we consider the hacker as a persona from our solution, with clear objectives matched to our solution potential vulnerabilities objectives that match business capabilities.

 At this point, we have the following practices:

• Persona Identification: Omar G, the hacker

• Persona values:

  • • Steal sensitive data

    • Steal assets

    • Impact reputation

    • Content crawling

• Persona Characteristics:

  • • Tech expert

    • Patient

    • Multi-Vector capabilities

    • OS

    • Infra

    • DB

    • Dev

5.3 User story Formulation

During this phase, we formulate the security-related user stories, both functional and non-functional stories, considering the CIA triangle, mentioned in lecture 01. 

As a brief for CIA triangle, we consider generating user stories for the three aspects:

• Confidentiality: Ensuring only the right people can see the right data — protect secrets from prying eyes through encryption, access control, and classification.  

• Integrity: Making sure data and systems remain correct, untampered, and trustworthy — protect against unauthorized changes using hashing, digital signatures, and validation.

• Availability: Keeping systems and data accessible when needed — prevent downtime with redundancy, failover, and resilient design.

5.4 Business Governance Model

In order to govern the solution security model, you should consider concrete classification for the transactions, in order to have the proper security controls.

The golden rule here is: Scan your operations types.

 During this activity, you will be able to identify and classify each operation within your solution, and put the proper security control, that should be aligned with the business team when creating the user experience to balance between user experience and security requirements.

Sample Transactions classification:

• Authentication: Require OTP, CAPTCHA

• Payment: : Require OTP

• Assets transfer: : Require OTP

• Data Crawling: : Require CAPTCHA

• Sensitive data exposure: : Require OTP

• Financial reports: : Require OTP

Note: The mentioned governance model can be applied as follows within a contract as a security governance model

5.5 User stories Samples with full lifecycle impact

5.5 Business requirements tradeoff 

Definition: Requirements trade-offs happen when fulfilling one requirement negatively impacts another.

Security contradictions Examples:

• Strong security controls may reduce usability (e.g., MFA slowing onboarding).

• Strict input validation can slightly degrade performance.
  
  
  

Root cause: Conflicting priorities between business needs, technical limitations, and compliance obligations.

Resolution process:

1. Elicit requirements via workshops with both business and technical stakeholders.

2. Perform risk assessment to quantify the impact of relaxing or strengthening each requirement.

3. Apply security-by-design and defense in depth to mitigate risks without removing protections.

4. Define measurable acceptance criteria to ensure the chosen trade-off is testable.

1. Target System Identification

• Purpose: Define the scope of testing to avoid unnecessary or unauthorized activity.

• Actions:

  • Determine whether the target is an application, API, network service, or embedded software.

  • Document version, environment, and dependencies.

  • Confirm test permissions and approvals (security & legal compliance).

2. Input Identification

• Purpose: Locate all points where external data enters the system.

• Actions:

  • Review technical documentation and architecture diagrams.

  • Enumerate APIs, file parsers, network ports, form fields, configuration files, or command-line parameters.

  • Prioritize high-risk inputs based on sensitivity and exposure.
    
    

3. Generate Fuzzed Data

• Purpose: Simulate unexpected or malicious inputs.

• Actions:

  • Use fuzzing frameworks (e.g., AFL, libFuzzer, Peach Fuzzer).

  • Create malformed data (broken formats, invalid headers, encoding issues).

  • Add random data for unpredictability.

  • Include boundary cases (max length, zero length, extreme values).

4. Execute Fuzzed Data

• Purpose: Test system resilience under unexpected conditions.

• Actions:

  • Inject fuzzed inputs into the target via identified input vectors.

  • Control the execution pace to avoid denial-of-service from excessive load (unless intentional).

  • Automate execution for repeatability.
    
    

5. Observe System Behavior

• Purpose: Detect abnormal responses indicating vulnerabilities.

• Actions:

  • Monitor CPU, memory, and I/O usage.

  • Watch for crashes, hangs, timeouts, or incorrect outputs.

  • Enable debugging, logging, and instrumentation for deep insights.
    
    

6. Log Detected Defects

• Purpose: Ensure every issue is traceable and reproducible.

• Actions:

  • Record input payloads that caused anomalies.

  • Capture logs, stack traces, and system state snapshots.

  • Classify severity and potential exploitability.

  • Share findings with developers for remediation and retesting.

Rollout Strategy