Gitlab CI/CD security scanners

Gitlab CI/CD scanners cover a range of different scan types which are necessary to ensure the code doesn't contain known vulnerabilities. 

SAST which stands for Static Application Security Testing discovers patterns of known vulnerabilities such as SQL injection, XSS, dangerous functions, etc by statically analysing the code. 

Dependency scanner is meant to find dependencies with known vulnerabilities. 

Secret Detection aims at discovering confidential values (secrets) that are hardcoded inside thecoe. These include values hardcoded passwords, private keys and private access tokens. 

DAST (Dynamic Application Security Testing) performs tests on the running version of software. That is, runtime values such as different user inputs could be used by the scanner to test the behaviour of software. This brings a lot of value to DAST compared to static testing tools such as SAST and Dependency scanning which are not aeare of the run-time behaviour of the software.

Container scanner discovers known vulnerabilities of the docker images that your application's image may use. It is noteble that continer scanner and dependency scanner are deemed as Software Composition Analysis (SCA). SCA aims at finding known vulnerabilities that are introduced by external sources, not the code we have written.

There are other scanners available in Gitlab such as API Fuzzer and IaC (Infra as Code) scanner.

We can use the above scanners to integrate security testing into CI/CD pipelines. This allows continious security testing according to a shift-left strategy rather than testing security late before going to production.

For further information you can see Gitlab's documentation:

https://docs.gitlab.com/ee/user/application_security/

Why CI/CD scanners are important, and what additional values does a tool like Gitlab provide? Well, assume tens of developers working on different projects in a company. You can imagine there might be tens or even hundreds of changes to the codes per day. Many of those changes may change the attack surface or introduce new vulnerabilities to your product. A CI/CD framework like Gitlab helps you automate security tests and simplifies the integration of scan jobs into the pipelines. That means your DevOps/DevSecOps engineers get rid of the maintainance burden of different security tools and can focus on the esults of secuity tests.

 

Credential Stuffing Attack

Credential Stuffing is a special type of brute-force attack, in which the attacker injects a list of previously breached username and passowords into the target to find a matching account and gain access to the application. A successful attack results in the account take-over and lets the attacker access to the victim's account. From the user's point of view, it is crutial to avoid using similar passwords in different sites, so that the breached accounts could not be used to access other sites. Furthermore, users should avoid using simple passwords. On the other hand, applications should enforce password security policies such as password complexity and length rules as well as preventing password reuse. In addition, multi-factor authentication would be a better solution. There is a comprehensive OWASP cheat sheet for prevention techniques.

OWASP credential stuffing page

My Favorite Security Blogs

Security blogs are one of my most favorite things in cyber space. I have been a security blogger since 2005 earlier in Persian and later in English. I also have been a fan of the world-renowned security bloggers, having their blogs in my top reading list. I believe that blogging, in its traditional form, has preserved its value despite the emerge and popularity of new media such as Twitter and Instagram. Here are some of my favorite individuals' security blogs:

Schneier on Security

Krebs on Security

Tao Security Blog

Troy Hunt

Graham Cluley

Lenny Zeltser

Anton on Security

On secure storage of passwords

Secure software protects users' passwords at rest. That is, unauthorized access by either an intruder or anyone having access to the storage space would not leak passwords. Password hashing is the accepted method for secure password storage. OWASP provides a comprehensive cheatsheet on secure password storage. 

It is recommended to use hash algorithms with salt (a random unique value for each password) so that cracking of the hash value using brute force and rainbow tables becomes harder. Salts are stored in the same database as passwords. Reusing the salt and using short length salts are among common implementation errors.  There are standard salted hash algorithms such as bcrypt and Argon2 (the winner of 2015 Password Hashing Competition) which are suitable for password hashing. In a 2019 post, Michele Preziuso discussed different attacks against password hashing algorithms (PBK2, bcrypt, scrypt, and argon2). He recommends the 'id' variant of Argon2 as well as scrypt as the most suitable choices considering different attack scenarios. 

Peppering is another step toward the security of password hashes. A (cryptographic) pepper is a secret input added to the password before hashing. Unlike the salt, the pepper is not stored with the hashed password, it is usually hardcoded in the application. The pepper is an additional defense when the attacker has access to the password storage area.

In her dev.to post, Nathalia Pierce provides best practices for secure password storage from a developer's viewpoint, and happycoding.io has a comprehensive tutorial for Java programmers.

PCI Guidance on Responding to a Cardholder Data Breach

PCI SSC has recently published guidance on responding to a cardholder data breach. The aim of the document is "to help merchants and service providers with incident response preparation. This guide also describes how and when a Payment Card Industry Forensic Investigator (PFI) should be engaged to assist."
 
As everyone knows, protecting the cardholder data is the main goal of PCI DSS, especially the PCI DSS. Therefore it obvious that PCI compliance mandates strict incident response activities in case of a data breach.
According to the guidance, an organization should be prepared for the data breach response by performing the following activities:
1- Implementing an IR (Incident Response) plan.
2- Limiting data exposure.
3- Planning the notification of all required parties.
4- Ensuring the inclusion of necessary measures in third-party contracts.   
The next steps are mainly about identifying and engaging a PFI (PCI Forensic Investigator).

Microsoft SQL Vulnerability Assessment

One of the best sources of security guidelines for different IT products is the product vendor. If you need a security baseline guide for an OS, DBSMS, and network device, first look for it in its vendor-provided documents. Microsoft products are a good example of above. For example, Microsoft has published SQL Vulnerability Assessment tool to aid DB admins in hardening the database as well as the DBMS. The tool is part of SQL Server Management Studio and requires it.
Which security policies, configurations and rules does the tool check? The below links provide a comprehensive checklist:
https://eitanblumin.com/sql-vulnerability-assessment-tool-rules-reference-list/
https://docs.microsoft.com/en-us/azure/sql-database/sql-database-vulnerability-assessment-rules

Reviewing logs of perimeter firewalls

When considering perimeter firewall policies, it is important how we collect logs of the traffic matching with each rule. A good practice is to collect all the outbound traffic logs that are matched by the last ''Deny All'' policy where all other rules are strictly accepting only the legitimate traffic. If the ''Accept'' policies are configured precisely, we can detect deviations from normal or expected behavior by reviewing logs of dropped outbound traffic. In specific, one may find internal IP addresses and ports that have been dropped, which means that the user was trying to bypass the restriction of the perimeter firewall and connect to an external IP/service.