Any SaaS solution is a n-tier system where all layers have to be protected, not only the application and its code

Any SaaS solution is a n-tier system, and as such, all the tiers should be protected, not only the application layer. If we put all our effort in the application and its code, we might miss important vulnerabilities in other parts of the attack surface.

Continue reading “Any SaaS solution is a n-tier system where all layers have to be protected, not only the application and its code”

Scanning Dockerfiles for security issues + Contributing to semgrep

Recently I had to scan some Dockerfiles to identify potential security issues.  In this case I wanted to use an automatic scanner. Automatic scanners have the problems we know about false positives and false negatives, but depending on the kind of work you want to do and the depth you need, they have a good benefit/effort ratio.

Continue reading “Scanning Dockerfiles for security issues + Contributing to semgrep”

The T approach to protect your company

The T approach means to go horizontally (breadth-first) across the company identifying its risk surface, and evaluating the probability and impact of each threat and risk. Then go vertically (depth-first) thinking how to implement security controls to really reduce the probability of the most important risk happening and reducing the impact in the case it happens Continue reading “The T approach to protect your company”

Logging and monitoring are different processes with different missions

Logging and monitoring are different processes with different missions. Logging is the process of storing data related to a system. This information can be used later to troubleshoot a problem or investigate an incident, including security incidents. Monitoring is a different beast. We monitor to have meaningful alerts when something specific happens. In order to monitor, we need logs. That’s the cause of the confusion, but they are different.

Continue reading “Logging and monitoring are different processes with different missions”

Why organizations should hire a good external red team

A red team is a service where some security experts attack an organization as if they were a real advanced attacker, but being careful about not damaging or interrupting the business of the hiring organization. Its objective is to identify the same security vulnerabilities that a real attacker could identify, and exploit them to reach valuable assets.

Continue reading “Why organizations should hire a good external red team”

How to define security requirements in an organization

What are security requirements

In every organization, it is important to define and document the cybersecurity requirements.

Requirements are mandatory security controls and practices defined by the security team, but that must be frequently implemented by other parts of the company. In this article I call these other parts of the company “engineering teams”.

Something similar to requirements are recommendations. Recommendations are very important, but optional, and very dependent on the specific case. While requirements have been decided by the company to be essential, recommendations are not essential.

The balance between what is mandatory (requirements) and what is optional (recommendations) is critical for keeping the organization agile and business-oriented.

Continue reading “How to define security requirements in an organization”