.leg.br

As soon as I decided I would be joining the Chamber of Deputies, I got in touch with some people I knew who worked there. Those contacts helped me arrange a conversation with the Infrastructure Coordinator, who, among other responsibilities, managed the security team. That was my way of trying to ensure I would be assigned there. I can’t say whether that made the difference, but the outcome was exactly what I wanted: from the very first day, I was part of the Computing Center’s security team.

That team’s responsibilities were pretty traditional for a security area within infrastructure: we took care of firewalls, antivirus, and any other project involving security-related aspects. In other words, the scope of the work was quite familiar to me.

When I got there, I was not immediately assigned to any specific project, so I ended up having some spare time. I was in the process of putting together the secure development course I mentioned in the chapter “AppSec Brasil 2009.” I showed the material to my boss, he liked it, and suggested we create an internal course for the Chamber’s developers. That’s how my first project at the institution was born: a course on security in Java software development.

I collaborated with the Chamber’s training center and we formally structured the course. During that process, I asked for feedback from a colleague who had also just joined the security team and had plenty of experience with software development. With his suggestions, I ended up adjusting and reorganizing most of the content.

I already mentioned my participation in the OWASP Summit. There, I learned more about ModSecurity, an OWASP open-source tool for implementing a WAF (Web Application Firewall). One of the Chamber’s most important systems was its institutional website, which served as an essential communication channel for citizens. At the time, it centralized most of the public information about what was happening at the Chamber.

Given the site’s importance, I thought it would be interesting to implement a low-cost WAF solution using open-source software. I took this idea to my boss and to the area coordinator, and they said they would evaluate it. Although it had not yet become an official project, I started building a demo environment to show how the solution could work.

The WAF I put together was basically a cluster of Linux machines using Linux-HA, which I already had experience with, running the Apache web server with HTTPS support and the ModSecurity module, and using the rules maintained by OWASP. I also prepared a mechanism to make it easier to update those rules, though there was still a lot of manual work involved. While setting up that environment, I ended up learning more about Apache, especially some monitoring features that would prove important when the system went into production.

Although we had managed to show the architecture worked well and offered good availability guarantees, approval to put the system into production was slow to come. Meanwhile, we kept working on other day-to-day activities and smaller projects, but I didn’t really understand the reason for the hesitation.

Over time, my focus ended up turning to the organization of AppSec Brasil 2009, as I’ve already described in a previous chapter. In one of the infrastructure team meetings, a concern came up that hosting a security conference could draw hackers’ attention and increase the volume of attacks on the Chamber’s systems, especially on the main website. In that meeting, I suggested that deploying the WAF would be a good way to increase the site’s protection and mentioned we were ready to put it into production. I left that meeting with the approval I had been waiting for quite a while.

The implementation was done in phases. In the first phase, the WAF operated only in logging-only mode, letting us observe the rules’ behavior and make adjustments without impacting users. In the second phase, we activated blocking and adjusted the blocking thresholds. The OWASP rules used a score-based model, in which each rule assigned a score and the final decision to block or allow a request depended on the sum of these scores. The tuning consisted of defining the value above which blocking would kick in.

After these adjustments, the solution went into production. In the first few days, we started running into some problems with site access. That’s when I had to study Apache’s multithreading model more deeply and learn how to tune the number of available workers. I also discovered tools that let you visualize the server’s load, showing how many workers were in use and how many were still available. If all of them were busy, new requests would be refused. On the other hand, if we kept too many workers, we could run out of memory and hurt performance. After some adjustments, we found a balanced configuration and the system stabilized.

At that time, my brother was working at the Legislative Chamber of the Federal District and told me about an incident in which their site was down for a long period. The problem had been caused by a change to the DNS of the Federal District government’s domain (df.gov.br), which ended up removing the Legislative Chamber’s subdomain (cl.df.gov.br). That incident made me realize that, even though the Constitution establishes independence between the Executive, Legislative, and Judiciary branches, in practice, on the internet, this independence did not exist. Generally, the Executive controlled the main domains and, consequently, had power over the other branches’ digital presence.

At that time, the Brazilian Internet Steering Committee began to announce the creation of new domains under .br. Shortly after, the .jus.br domain was introduced, aimed at the Judiciary branch. That’s when I had the idea of proposing the creation of the .leg.br domain.

There had always been a certain rivalry between the IT departments of the Chamber of Deputies and the Federal Senate, the two chambers that make up the Brazilian Congress. In general, Prodasen (the Senate IT department) had an advantage because it was older, more structured, and had more resources. If the Chamber took the initiative to create the .leg.br domain, that could give more visibility to our IT area. I talked about the idea with my boss, who encouraged me to take it to the director of the Computing Center. However, the director wasn’t interested in the proposal and the matter ended up being dropped. Years later, after I had already left the Chamber, I got a message from Olival, the boss who had supported the idea, with a link to a news story announcing the creation of the .leg.br domain. And, as you would expect, Prodasen ended up responsible for it.

We had other interesting projects and ideas during that period at the Chamber, but that’s a topic for another chapter.