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 “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.