Blog 9

This is another key step in the Secure SDLC. It aims to reduce the risk by giving an attacker fewer opportunities to exploit a weakness or a vulnerability in a product. This step applies the least privilege principle by understanding the attack surface of the application and aiming to reduce it. This step also employs layered defenses.

What is the attack surface?  It is the combination of code, interfaces, services, and protocols available to all users – authenticated and unauthenticated and remote and local users. It is all the entry points into the application.

Attack Surface Analysis identifies those entry points and challenges if they are required or if they can be removed, disabled, or if additional protections can be implemented.  

Attack Surface Reduction aims to reduce the amount of code that is accessible to untrusted users.

The Threat Model is key in understanding the Attack Surface of an application, because there we documented all entry points and trust levels.  

Once we have this understanding, we again ask questions. These questions are basically the same each time, so this again can be easily implemented. Some of the questions are:

• Is this feature or service really required? If No, remove: if Yes, then:
  • Is this feature or service remotely accessible? If Yes, then:
    • Does it really need to be remotely accessible? If Yes, then:
      • Is the feature accessible to unauthenticated users? If Yes, then:
        • Does it need to be accessible to unauthenticated users? If No, disable that access; if Yes, then:
          • Is feature executing with least privileges? If No, apply the lowest set of privileges

The easiest is to write this as a flow diagram.  The teams will go through it a few times and learn this way of thinking rather quickly.

Blog 10

Something very important in my career was getting a certification in Information Security.  I chose the Certified Information Systems Security Professional (CISSP), granted by the International Information System Security Certification Consortium, also known as (ISC)².

I chose this certification, as it was and is considered the most complete one in the industry.  It is a credential that demonstrated that you have what it takes to effectively design, implement and manage a best-in-class cybersecurity program. With a CISSP, you validate your expertise in the industry, as a certain number of years of work experience is required. When I interview candidates for different Information Security positions, I look for this certification, as it gives me a certain level of certainty that this candidate at least understands the different Information Security domains.

Another benefit of having this certification is that it requires you to continue learning and keeping up-to-date with the industry. They require a certain number of hours spent in training or other activities that contributes to the profession. 

A few years ago, I returned to Carnegie Mellon University to get a CISO Executive Training, which helped me comply with this requirement.  Besides the obvious benefit of being back in that amazing place, and the people I got to meet and work with, this training helped me mainly in two ways:

1. I updated my knowledge about Information Security topics with new ways to solve certain issues and new tools.
2. It confirmed that the approaches that I had implemented and was implementing were aligned to the industry’s best practice.

This year, this requirement brought me to writing these blogs! =)

Blog 9

This is another key step in the Secure SDLC. It aims to reduce the risk by giving an attacker fewer opportunities to exploit a weakness or a vulnerability in a product. This step applies the least privilege principle by understanding the attack surface of the application and aiming to reduce it. This step also employs layered defenses.

What is the attack surface?  It is the combination of code, interfaces, services, and protocols available to all users – authenticated and unauthenticated and remote and local users. It is all the entry points into the application.

Attack Surface Analysis identifies those entry points and challenges if they are required or if they can be removed, disabled, or if additional protections can be implemented.  

Attack Surface Reduction aims to reduce the amount of code that is accessible to untrusted users.

The Threat Model is key in understanding the Attack Surface of an application, because there we documented all entry points and trust levels.  

Once we have this understanding, we again ask questions. These questions are basically the same each time, so this again can be easily implemented. Some of the questions are:

• Is this feature or service really required? If No, remove: if Yes, then:
  • Is this feature or service remotely accessible? If Yes, then:
    • Does it really need to be remotely accessible? If Yes, then:
      • Is the feature accessible to unauthenticated users? If Yes, then:
        • Does it need to be accessible to unauthenticated users? If No, disable that access; if Yes, then:
          • Is feature executing with least privileges? If No, apply the lowest set of privileges

The easiest is to write this as a flow diagram.  The teams will go through it a few times and learn this way of thinking rather quickly.

Blog 8

This is, in my opinion, the most critical strategic step to implement a successful Secure SDLC: assigning the Security Advisor role to one of the members of the Product Development Team. This person provides support to the Product Development Team in complying with the Secure SDLC process and is the Information Security representative within the Product Development Team. The Security Advisor helps the team implement security across the entire SDLC and gives his approval at the end before the product launches into Production.

The Security Advisor is a subject-matter expert from within the Product Development Team, what allows a deeper level of understanding of the ecosystem and associated threats. He is the first level of security support for the Product Development Team, acting as a security sounding board. He is the point of contact between the Product Development Team and the Information Security Team.

In my experience, it was key to develop the Secure SDLC practice together with someone in the Product Development Team who later became the Security Advisor. It was key because we included all his concerns and confirmed viability of what we were proposing. He became later the ambassador of the Secure SDLC within his team.

Because this responsibility was within the Product Development Team and not in Information Security, a completely different level of ownership of product security was achieved. It was no longer the traditional scenario where Information Security is viewed as the auditor or police asking for compliance with the process, but instead the reasons why the required steps were necessary were understood and Information Security was viewed as an enabler, a facilitator, to create secure products. Both teams worked towards the same goal.

Blog 7

Another part of the Secure SDLC that I think is key is defining the quality criteria or what we called the “rules of the game” up front.  It defines the priority to fix each issue.

The priority is derived form two factors: the sensitivity or classification of the data that is being handled (confidential, internal, etc.) and the Attack Surface [the authentication level (admin, user, anonymous) plus the access type (remote, local)]. Depending on the combination of these two factors the priority is established, i.e., which security issues will require to be fixed before going into Production and which allow for 30, 60 or more days after launch to be fixed. 

This standard rule, agreed and informed from the beginning of the projects’ SDLC, resulted in an important tool to improve the understanding of risks associated to security issues and to increase commitment for security from the Development team.

Blog 6

The heart of the Secure SDLC, and my favorite part, is the Threat Model. This is a document where all the security threats are identified at Design phase, before any coding begins. To build it, one takes the application architecture diagram and asks some simple and – and this is key in my view – standard questions. Here is a short description of how it works.

The architecture diagram is built of four core elements:

• Processes (like a web service)
• Data Stores (like a database)
• Data Flows (data moving between two elements)
• External Entities (anything outside our control that interacts with the application, like users)

Each element is subject to certain security threats. We used the STRIDE model for listing these threats – it stands for:

• S: Spoofing – the ability to pose as someone or something else
• T: Tampering – the ability to change something without authorization
• R: Repudiation – the ability to disavow a transaction
• I: Information Disclosure – the ability to view something without authorization
• D: Denial of Service – the ability to degrade a service
• E: Elevation of Privilege – the ability to elevate capabilities

As mentioned, each element of the application diagram is subject to certain threats:

• Processes are subject to all of them, the entire STRIDE
• Data Stores only to TID, and if logs are stored, then also to R
• Data Flows only to TID
• External Entities only to SRD

And each of these threats is mitigated by certain controls. For example, Spoofing is mitigated using authentication, Tampering using integrity controls, etc.

Then, one puts the threats and corresponding controls to each of the elements in the architecture diagram. And because there are always the same threats per element, it is very easy to build.

There a few more things that go into building a complete Threat Model, such as identifying the Attack Surface, i.e., the authentication level (admin, user, anonymous) and the access type (remote, local), and identifying the sensitivity or classification of the data that is being handled (confidential, internal, etc.), but this is in a nutshell how one is built. I think this is a brilliant way to ensuring security is included since the very design of the application.

Blog 5

As mentioned in previous blogs, Application Security is my favorite topic within Information Security.  Some of my work on this topic was the development of a Secure SDLC (Software Development Lifecycle) standard, which basically includes security in the entire SDLC, from the very early phases, before any coding begins. This is the best time to include security in an application, as mitigation of security and privacy issues at these early stages is much easier and less expensive than when the application has been built. Near the end of the development project, it is sometimes difficult to fix security issues – sometimes even not possible – and fixes are bolt on the application to mitigate the issue, but not really solving it.  

In this project, I had the fortune of working with Michael Howard, one of the creators of Microsoft SDL! He taught me and the team so much about how to get this rolling with very practical steps, and how to start that mind-shift among the Development teams. He was passionate about this topic as well, so I really enjoyed working with him.  The result was a process that was successfully adopted by the main Development area in the Company, with excellent results.  

In the next blogs, I will talk about some of the key steps in the Secure SDLC process.

Blog 4

As mentioned in Blog 2, after working 7 years in the financial industry for one of the banks with the highest Information Security standards, I accepted an offer in the Telecommunications sector. A whole different world.

Back then, the Telecommunications sector, as many other sectors, was not as regulated as the Financial sector was.  I was hired to be in charge of the security of a mobile money app. I joined a small team of very creative and passionate people, and soon after we were doing vulnerability assessments, identifying and fixing existing vulnerabilities. I soon was working with people across the world, as this app was in several of the countries the Telco operated in.  A couple of months later, I was moved to the global Information Security team, looking at the entire company. And about a year later I promoted to Head of the area.

I was able to implement several of the best practices I had learnt in my previous job. But just like it was in my first job, there was a lot of convincing to be done. It was understandable – I was asking to modify processes that had been done a certain way for decades, sometimes with no historical data of security incidents occurring, so I was again doing a lot of awareness around Information Security.  

This has been a ride… I have been in this job for ten years now and there is never a boring day. The Telco industry is a very rapid-changing industry.  There is always something new to learn, something to be adapted to a new service or a new technology.  Not to mention Information Security! Everyday there is something new, either from the bad guys (new attacks, malwares) or from the good guys (new ways to defend from the bad guys, new recommendations, new tools).  I say it again – I never have a boring day at work.

Nowadays, everyone talks about Information Security. Many companies need people with these skills to protect their networks and assets. I hope my story has encouraged you, the reader, to get into this amazing world of Information Security. Not just because there is a demand for Information Security professionals out there, but because in this fast-paced topic you will continuously learn (if you want to) and you will never get bored.

Blog 3

As mentioned in Blog 1, I had decided to get my master’s degree in Information Security, a career choice that was not that common back then.  For the ones who weren’t born yet or were too young, it is hard to imagine Information Security not being that popular, but it wasn’t!  Today, every day we see several news about a malware attack affecting large companies or organizations or … facilities or government offices, but back then this was rarely discussed.  

Shortly after my return, I remember that my friends in El Salvador made fun of my work, saying that it was a too sophisticated way for malicious actors to achieve their goals.  That it was much easier for them to use the traditional analogue ways, like assaulting people at gunpoint to take their money, instead of having to hack a computer or email to then rob people’s bank account credentials to then get their money.  I also remember people thinking I oversaw security guards and physical security when hearing I worked in security.   Around that time, I wrote a chapter in a book that talked about security in RFID (Radio Frequency Identification) with some cool people I had met at an RFID Security conference in MIT during my masters.  I remember I wrote about how people would give away their personal information to receive some small gift in return or to enter a drawing to win a prize.  It was very common to see this, and although it still happens today, I do believe people are much more conscious about protecting their personal information.   

I had a blast during my early years building the Information Security department at one of the largest banks in Central America.  At first, I was in charge of building the department in El Salvador, and later in all the Central American countries where we operated.  During this period, I spent a lot of my time explaining why it was important to protect our network, systems, data and how it was possible to access them if we didn’t put the right controls in place.  I remember having eternal discussions with some of my colleagues arguing about all kinds of threat scenarios exploiting x vulnerability.  Sometimes it felt like an endless battle, but this was part of what excited me about the topic – this was new and unknown for most, and I was responsible for making people aware, opening people’s eyes to the risks we were facing, and changing the status quo of how things were done.    

A few years later, this bank got acquired by one of the world’s largest banks.  The financial industry was one of the industries where Information Security was most mature, as there were some regulations requiring controls to be in place to protect the systems that managed money.  And within the financial sector, this bank was the leader in Information Security – they had one of the most mature security programs.   We needed to reach a certain level of security before a firewall dividing both networks could be removed.  This was a several-years project, during which I was Head of Information Security for Central America and was in charge of implementing the technical security controls.  I learned so much during this time.  This was like a second master’s degree! 

When we finished that project, I received a call from a Telco operating in Latin America and Africa offering me a position to lead the security of one of the first mobile money applications.  This was very exciting for me, as Application Security is one of the areas in Information Security I enjoy the most. And this was a mobile application – something that was very new.  So, after 7 years of working at the bank, and the completed project, I moved to the Telecommunications sector, and a new chapter in my career began.

Blog 2

Continuation of Blog 1…

And what a ride it was! My professors were some of the brightest minds in security. Some were from CERT, and they were trying to solve some of the biggest problems in the field.  At the end, I even had the opportunity to do some work with CERT. Amazing place! I remember thinking every day about the enormous delta of knowledge between what I knew in the morning vs. what I knew in the evening – it was huge! The rate at which I was learning was incredible!  And it was hard for me. I remember that in my first coding class (it was Java 1) I didn’t understand a thing! Mind that my undergrad was in Engineering, where I had one coding class at the most and in my work, besides a little bit of HTML – I did not code that much. I recall that I used that Christmas break to get a handle on Java! I spent it in Germany with my brother (Remember? The one in Part 1?) and he explained it all to me. When I returned, I did well in Java 1 and Java 2, and I even took an extra class called Data Structures, which was famous for being a hard one – and I loved it! I understood how those classes that one used in Java worked and I actually built them! Awesome! 

And my classmates… They were all so smart, creative, and interesting people. For some this was their second masters. And most of them were younger than me. They were from all over the world – Indian, Chinese, a few Europeans, and North Americans and even less Latin Americans (only about 2!). Besides what I learnt at the University, I also learnt a lot about their cultures and other ways of thinking. I fell in love with the Indian music and food! It was an amazing experience, and it was my jumpstart towards this amazing career, in which I never stop learning.

Towards the end, I didn’t know if I should pursue my PhD or start working. There were discussions to do my PhD with one of the professors at CERT. I also got into a few interview processes. I remember interviewing with McKinsey to work in Berlin, Germany. They flew us to NY for several rounds of interviews, but I did not pass the fourth interview. I remember walking the streets of NY all disappointed, entering a bar and ordering a Guinness and calling with my brother in Germany about the whole experience – because it was a great experience! I also interviewed with UBS to work in NY. I remember getting into second or third round of interviews but had to leave the process. Back home, my dad had had a mild heart attack, so I came back.  My scholarship also had a requirement to return to the country to bring the gained knowledge. So, I stayed.  A few weeks after my return, I was interviewing for a job, and about two months later I started my first job in Information Security! I was going to work in one of the largest banks in Central America, as Head of Information Security, to build that area from the ground up.  A huge challenge that I was eager to accept!

This was how I got into Information Security!  In Blog 3, I will talk about my first job in this amazing industry.