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.
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 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.
If you are responsible for some information or processes, you are responsible for their security from end to end.
Being responsible for something does not mean that you have to do everything. You can delegate tasks and subprocesses to providers, even critical ones, but you cannot delegate your responsibility.
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.
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.
I was one of those people that used to think and say that blockchain, and the different technologies around it, are solutions for problems that don’t exist. That many people talk about it without knowing any technical details or implications, or focusing on the wrong topics (e.g. politics, finance, etc.) didn’t help either.
However, lately, I have been changing my mind. I’m just starting to explore the technology, but I already think that it is very interesting, new, and that it has much more meat that I thought. I guess I was suffering the Dunning-Kruger effect: when I didn’t know too much about it, I was more sure about my thoughts. Now I have many questions.
Some years ago, me and a colleague were coached by two great professionals of our company. I used to pass some days during the week with one of them, and my colleague with the other.
One of the lessons they wanted to transmit us was the importance of great communication between colleagues. They used to talk every day, and share relevant information about different topics, meetings, or events they had participated in or discovered during the day. While they were coaching us, they used to talk about us too.
Every process has to have an owner. The owner is the person accountable for the success of the process. The owner is not who executes the process. Those who execute the process are the executors.
This article is about containers, the different types (depending on what privileges we let them have), and how they build their isolation: mainly kernel namespaces and capabilities, overlay filesystems, seccomp, and SELinux. My motivation to start this article was for me to understand a bit better how the combination of container isolation mechanisms and privileges affects (increasing or decreasing) the risk of kernel flaws.Continue reading “Containers: Rootful, Rootless, Privileged and Super Privileged”