The Wait

The following week, the onboarding for the new Central Bank analysts began. It was a training course that served as an introduction to what the Central Bank is, what it does, and also included presentations about some work processes common to all the bank’s employees. For two weeks, we were gathered together with all the new hires from various departments. That period also had an important social role, because it let us meet people we might not otherwise have a chance to meet again once work actually started and each of us went off to our own department.

After the onboarding, there was a waiting period until the new analysts officially started in their new roles. The problem was that there was no definition of how long it would take between the end of the training and the actual start date. On top of that, Gisele and I had passed the same exam, so we had both left our jobs at the start of the onboarding. Since the waiting period ended up being longer than expected, we started to worry about our finances. The good part was that the waiting period overlapped with the 2006 World Cup, and I ended up watching almost all the matches, something that would have been difficult if I had been working.

With the Central Bank’s delay in calling us and with the kids’ school vacation, we started to think about alternatives to reduce costs and decided to spend some time at our parents’ houses. Staying there was cheaper than traveling anywhere else, worked as a kind of vacation for the kids, and at the same time helped reduce our living costs. In parallel, we talked to a few contacts we still had in Belo Horizonte to check if we could land some kind of freelance work. We ended up getting some training and consulting work at UFMG, on a project Gisele had worked on when we lived in Belo Horizonte. My part was delivering basic training on secure development and security testing for web systems. From what I recall, it all went well and we managed to earn some money during that period. The funniest part was that, during the training for the testing team, some people got quite excited about the possibility of finding security problems in the systems. That engagement left me with the impression that there was very little material about security in software development, especially in Portuguese. Later, I ended up writing a bit about this subject.

After a lot of waiting, the Central Bank finally set the start date for the new analysts. It was a great relief. We would still have to work for a month before getting our first paycheck, but it was already comforting to know we would have a stable income again to support our family. Since I had done well in the exam and already knew some people inside the Central Bank, I managed to be assigned to the information security team within the IT department. The team was responsible for two big areas: one was network security and firewall administration, and the other was security and administration of the bank’s email infrastructure. I was placed in the firewall administration area. The Central Bank used Check Point and I didn’t have much experience with that platform, but learning to deal with the tool’s GUI wasn’t hard, since I had a good grasp of the basic concepts of networks and security.

The team was also responsible for some special projects related to information security, such as secure file transmission, administration of antivirus software on all of the bank’s computers, data protection, and security assessments of internally developed systems (also known as pentesting). As soon as I started working there, I began talking to colleagues about possible improvements, and one of the topics we discussed was performing security testing on web systems developed inside the bank. At that point, security testing for internal systems barely existed there. So we began experimenting with some web application testing tools, like Paros Proxy, and doing basic tests on the systems. One of the first tests we did was session hijacking. It was relatively easy to capture a user’s cookies and use them to gain unauthorized access to the system. Little by little, we learned more and developed that work, to the point where the bank ended up hiring an outsourced company to run regular penetration tests on the systems.

The Central Bank’s IT department had many characteristics inherited from the mainframe days. Despite the high cost of that kind of infrastructure, there were also interesting aspects in terms of operational maturity and security that came from that tradition. One example was the authentication and access control system. It was a pretty elaborate system that allowed very granular control over each employee’s access to each system. From a development standpoint, it was practically plug and play. The developer just had to use the correct libraries and define the access profiles within the system. The main work was deciding which features should be associated with each profile, not implementing the security mechanisms themselves.

Around that time, the Central Bank also began to provide laptops to some employees, mainly those who worked outside the bank’s headquarters. Areas like inspection, for instance, visited financial institutions in person, and laptops were very useful for that kind of work. At the same time, there was concern about the security of the data stored on those devices. That topic ended up becoming a project for the security team. I already had experience with a disk encryption tool called TrueCrypt and I liked the tool. I suggested we evaluate using TrueCrypt, and we ran some tests. The conclusion was that the software worked well but didn’t have some features important for a corporate environment like the Central Bank’s. Since the source code was available, my boss asked me to evaluate whether it would be possible to adapt it to our needs.

I managed to make some adjustments and include some additional features. The problem was that these modifications were very specific to the Central Bank’s environment and were unlikely to be accepted by the project maintainers. That would mean maintaining our own version of the software, a fork dedicated to our use only, which would mean considerable maintenance effort over time. At the same time, Windows began to include BitLocker, which was fully integrated with the operating system and with the Active Directory infrastructure. We did a new assessment and ended up deciding to use BitLocker. That episode ended up being a good lesson, because it’s not always worth modifying software just because it’s technically possible. There’s a maintenance cost that has to be taken into account.

While I was working in the security area, Gisele was on the team responsible for the Central Bank’s software development processes. Since I’ve always had an interest in security in software development, I thought our teams could collaborate. At that time, I was studying taint analysis methods in software. The idea is to check whether data received from external sources has been properly validated before being used by the system, whether for storage in a database or for display to the user. The Central Bank used Java, and I had found a tool that performed taint analysis on Java code and seemed very interesting. I talked to Gisele and we ended up putting together a project to introduce that kind of analysis into the bank’s development process.

We deployed it believing it would be a major success, but the developers’ reaction was pretty negative. The tool tended to generate a lot of noise, pointing out many problems that weren’t always very relevant. On top of that, the process we defined required developers to justify each alert generated by the tool, which created a considerable additional workload. With the increase in complaints and the difficulty of tuning the tool to reduce false positives, we ended up abandoning the initiative. Our collaboration on this project ultimately failed, and looking back, maybe one of the reasons was precisely our closeness. We trusted each other too much and ended up not doing the critical assessment the project required. We implemented everything very quickly and without enough testing, which contributed to the problems that appeared later.

After those projects came others, some even more important, but that’s already a story for another chapter.