Sometimes we think that the cybersecurity team should be like controllers or powerful people that can say to the rest of the company what they can do or not. That’s not how cybersecurity works and that’s not the best thing for the business. The cybersecurity team should not act as the police. They are more like the bodyguards that protect the Pope: they cannot tell the Pope where he can go or not; they can recommend the Pope not to do something, but they can’t force the Pope to do what they want; if the Pope wants to talk with that many people at this moment, the bodyguards can tell him what they think (if they react really fast), but they can’t forbid the Pope to get closer to the people, if he wants.
Segregation is one of those strategies that, when used well, can improve your security posture much more than any shinny expensive security solution. It is a key security concept. It is one of the main strategies that we can embrace to obtain real security, however, very frequently we don’t consider it. We apply segregation when we separate the asset from the threat. We implement segregation, for example, when we put a firewall between two networks. This is the most clear example, but we also apply segregation in many other situations: when we use containers; when we use virtual machines; when we close open ports; when we use different roles with different authorization levels; etc.
Pentesting in production has risks. I remember a story of a pentester who ran an automatic scanner to spider a site. After some minutes scanning and spidering, it found a path to a list of items that had a delete button next to each of them. The spidering process clicked all these buttons and deleted all the items in production.
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.
We usually talk more about protect, detect and respond, and less about vigilance. Vigilance is an important function that can provide a lot of value to any company. It is essential for risk evaluation, and can feed the rest of the processes of the cybersecurity team.
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
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.