Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes and what this means from a risk perspective. Attack surface analysis helps to identify what functions and what parts of the system you need to review/test for security vulnerabilities, high-risk areas of code that require defense-in-depth protection – what parts of the system that you need to defend, and when you have changed the attack surface and need to do some kind of threat assessment
Hi Ting-Yan,
I agree this should be done during development. By doing so, you begin to map out where an application could have vulnerabilities. Understanding this allows you to better understand the risk associated with an application and how to best mitigate those risks. By continuously revisiting, you are also managing the attack surface by monitoring what changed with the application.
This article provides four steps for attack surface analysis:
1) Define the attack surface of the application
2) Identify and map attack surfaces
3) Measure and evaluate the attack surface
4) Manage the attack surface
A key point I picked from this article is that security risk assessment is a critical and important step that an organization should focus on, because identifying the appropriate risks allows the organization to accurately define the critical risks in the application and establish appropriate controls to protect the system.
I agree that the security risk assessment is one of the most critical analyses organizations should focus on. It helps to identify these risks and also give them an impact score so organizations can better allocate resources and assess their own risk appetite within.
What I get from this article is that in order to attack your system, steal something or perform other annoying operations, the attacker needs to find a way or a certain channel. This is the whole purpose of Attack Surface Analysis: map the way in and out of the system, view the system from the perspective of the attacker, understand the most vulnerable parts of the system, and need to focus on testing and review. It is part of design and part of risk management.
Attack surface analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The main point is to understand the risk areas in an application and to find ways to minimize this. The first step is to identify and map the attack surface and review it from an attacker’s perspective. Read through the source code and identify different points of entry/exit. The next step is to measure and assess the attack surface, focusing on remote entry points. Once there is a baseline understanding of the attack surface, it can be used to identify and manage risks going forward as changes are made to the application.
Hi Priyanka,
I totally agree with you! I get a very similar understanding from “attack surface analysis”. I like that its purpose is to educate Web application developers on the areas of risk they need to focus on, which helps minimize the attack surface of an attacker.
I read all kinds of OWASP materials in the ITACS program, but this is my first exposure to attack surface analysis. This kind of deception is very helpful to understand more about the development aspect of the application, as well as the standard process of the review and testing of the security measures. Attack surface is the place where hackers can enter and obtain data. The attack process is divided into definition > identification > risk assessment > management. This analysis is very important, and as the scale of application increases, it will become more difficult to manage. My biggest reward is that if a very useful and successful application is developed and integrated with the existing system, the number of users will increase and the attack area will increase, resulting in more attack vectors and vulnerabilities. To make a long story short, this analysis looks like a lot of work done in technology. If an application is really attractive, it will never end. I think it is also necessary to note that this analysis should be carried out at the stage of development, and is often revisited, rather than waiting for the application to start.
The OWASP Cheat Sheet Series was created to provide simple and pragmatic collection of doing Attack Surface Analysis and managing an application’s Attack Surface. Attack Surface Analysis is the process to identify what parts of a system need to be reviewed and tested for security vulnerabilities, and developers and security specialist can use this to reduce related risk. And the process of Attack Surface Analysis have several step: defining the attack surface of an application, identifying and mapping the attack surface, measuring and assessing the attack surface, and managing the attack surface.
Mapping out the attack surface of the web application is extremely important in the risk identification process. Organizations must manage their attack surface and keep reviewing it over time as the attack surface grows. They need to be diligent with the management of the attack surface and make sure all risks are properly mitigated.
In an attack surface analysis, it’s imperative that the system is thoroughly tested for vulnerabilities that could occur. I believe the most important step in this process is defining the attack surface. When defining an attack surface, there are four important processes to take into account. First is to assess the sum of all paths going into and out of the application for data and commands. Second is to find the code that protects those paths. The third step is to find all the valuable data used in the application, which can include PII, secrets and keys, intellectual property, and critical business data. Lastly is to define the code that protects that data. Once defined, it makes it easy to assign roles and privilege levels for each level of the attack surface.
The attack surface analysis cheat sheet simplifies the rundown on how we can understand the applications’ attack surface. It helps developers understand how to manage the application security risks in their design and changes implemented.
The analysis is used to help us:
– identify what functions/parts of the system need to be tested/reviewed for security vulnerabilities
– identify high-risk areas of code, that may need defense-in-depth protection, and what parts of the system needs to be defended
– identify when the attack surface has a change and needs to be reassessed for threats.
This cheat sheet helps us to understand and manage application security risk from the developer’s perspective and use it to implement a risk assessment. In order to understand how to use the attack surface analysis, we can identify the parts of the system, which we need to evaluate the vulnerabilities. When we identify the high risks, we will implement defense-in-depth protection to mitigate the risk to an acceptable level. We also need documentation for everything we have done, and then the documentation will help us to control some similar risks efficiently. Also, this cheat sheet provides a manageable solution based on function, design, and technology, including login/authentication entry points, admin interfaces, and business workflows.
Attack surface analysis involves identifying all points of entry to the application whether it’s internal or external. Furthermore, it should be broken into separate groups such as all the API’s and databases it connects to or if it’s a web application with a login form. Vulnerability scanning and dynamic testing tools can be helped to perform the analysis. The more connections it has to other systems and services, the greater attack surface. The analysis helps reduce the attack surface and harden the system as much as possible to reduce the risk it poses to the organization. If there are any major changes after the analysis, it should be conducted again to identify how the attack surface has changed and if any new vulnerabilities have been introduced.
I believe the hardest attacks surfaces to map out are internal attacks, since most organizations operate on a trust basis with their employees. It is not easy to figure out who is more likely to go rogue within the pool of employees. However, such attacks can be mitigated by ensuring that no single employee has access to every part of the system, especially controls.
The important takeaway from this document is the task of identifying and mapping the attack surface. In any aspect of protection, you can only defend what you know needs to be defended, if you don’t have things on your radar that you should be protecting you are essentially asking for attackers to come after you. This section goes hand in hand with the NIST framework that focuses on categorization of assets. You need to take an inventory of all data and all assets and while doing this be as thorough as you can because attackers will find those low hanging fruit. There are also applications that can scan your system and let you know how many attacker surfaces you have within your organization.
As you pointed out, achieving system is a challenging task especially when dealing with security vulnerabilities that are oblivious to security professionals. They cannot afford to assume that all is secure because one thing that attackers have is time to find vulnerabilities in your system.
Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities
Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this.
1. identify what functions and what parts of the system you need to review/test for security vulnerabilities
2. identify high risk areas of code that require defense-in-depth protection – what parts of the system that you need to defend
3. identify when you have changed the attack surface and need to do some kind of threat assessment
The OWASP cheat sheet series is intended for developers to consider and apply the OWASP standard as they develop web apps. It can also be used by risk analysts in their assessments. This cheat sheet in particular focuses on the Attack Surface excluding insider threats, users and operators of the system. The goal is for developers and security experts to:
– map the system for vulnerabilities.
– based on that what parts need to be proactively defended
– note the changes to the attack surface and re-assess.
The attack surface is
– the paths for data/commands
– code to protect the paths
– all data related to the application
– code that protects the data
The cheat sheet goes into further detail explaining how to identify and map, measure and assess, and finally how to manage the attack surface.
Attack Surface Analysis is targeted to be used by developers to understand and manage application security risks as they design and change an application, The focus here is on protecting an application from external attack – it does not take into account attacks on the users or operators of the system.
Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes.
Attack Surface Analysis helps you to firstly identify what functions and what parts of the system you need to review/test for security vulnerabilities. Secondly, identify high risk areas of code that require defense-in-depth protection – what parts of the system that you need to defend. Thirdly, identify when you have changed the attack surface and need to do some kind of threat assessment.
I agree with your comment that attack surface analysis is about mapping ingress points for an application. I found it interesting that APIs were specifically called out in this and other readings in this section as most APIs have minimally a one time credential, a certificate and key associated to them. This gives an attacker several entry points by scooping up the credential with a sniffer or attacking the key if it is self signed and a standard Windows key generator is not used.
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query.
Broken Authentication.
Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII.
XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents.
Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced.
Security Misconfiguration. Security misconfiguration is the most commonly seen issue.
Cross-Site Scripting (XSS). XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript.
Insecure Deserialization. Insecure deserialization often leads to remote code execution.
Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application.
Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data.
This article was all about determining the attack surface (or possible vulnerabilities attackers could exploit) of an information system. The Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes and what this means from a risk perspective. The Attack Surface describes all of the different points where an attacker could get into a system, and where they could get data out. With this approach, you don’t need to understand every endpoint in order to understand the Attack Surface and the potential risk profile of a system. Instead, you can count the different general type of endpoints and the number of points of each type. You can also build up a picture of the Attack Surface by scanning the application. For web apps you can use a tool like the OWASP ZAP or Arachni or Skipfish or w3af or one of the many commercial dynamic testing and vulnerability scanning tools or services to crawl your app and map the parts of the application that are accessible over the web. Some web application firewalls (WAFs) may also be able to export a model of the application’s entry points.
Hi, Anthony, I agree with your point, and I also think the Attack Surface Analysis would helps organization to firstly identify what functions and what parts of the system they need to review/test for security vulnerabilities. Secondly, it also identify high risk areas of code that require defense-in-depth protection – what parts of the system that organization need to defend. Thirdly, it can identify when organization have changed the attack surface and need to do some kind of threat assessment.
Managing the attack surface is a vital step in mitigating the risks associated with the system. A lot goes into ensuring that one has a baseline understanding of the attack surface. Ranging from identifying the various vulnerabilities, possible attack vectors and adequacy in security measures in place. These aspects can then be used to create an outline of the attack surface and mapping out the attack surface to enable personnel have a better understanding of all possible risks associated with the system.
Without managing the attack surface, it is more cumbersome achieving optimum security for any system, therefore putting the system at risk. This is where we manage the risk and reduce it to residual risk hence ensuring that all possible loopholes are covered to the satisfaction of the organization.
I took away from this reading a standard method for assessing the attack surface for an application, measuring and assessing the attack surface and managing the attack surface. In this reading as well as the others for this unit, there were common themes around integrations between the application being assessed or hardened and other applications. Typically these integrations come in the form of a file transfer or an API. I find this very interesting because with any file transfer or API there is a credential associated to the integration. Solid management and password rotation or key rotation becomes critical to managing the integrity of the integration and harden it as an entry point for attackers.
Ting-Yen Huang says
Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes and what this means from a risk perspective. Attack surface analysis helps to identify what functions and what parts of the system you need to review/test for security vulnerabilities, high-risk areas of code that require defense-in-depth protection – what parts of the system that you need to defend, and when you have changed the attack surface and need to do some kind of threat assessment
Haozhe Lin says
Hi Ting-Yan,
I agree this should be done during development. By doing so, you begin to map out where an application could have vulnerabilities. Understanding this allows you to better understand the risk associated with an application and how to best mitigate those risks. By continuously revisiting, you are also managing the attack surface by monitoring what changed with the application.
Wenyao Ma says
This article provides four steps for attack surface analysis:
1) Define the attack surface of the application
2) Identify and map attack surfaces
3) Measure and evaluate the attack surface
4) Manage the attack surface
A key point I picked from this article is that security risk assessment is a critical and important step that an organization should focus on, because identifying the appropriate risks allows the organization to accurately define the critical risks in the application and establish appropriate controls to protect the system.
Mei X Wang says
Hi Wenyao,
I agree that the security risk assessment is one of the most critical analyses organizations should focus on. It helps to identify these risks and also give them an impact score so organizations can better allocate resources and assess their own risk appetite within.
Zibai Yang says
What I get from this article is that in order to attack your system, steal something or perform other annoying operations, the attacker needs to find a way or a certain channel. This is the whole purpose of Attack Surface Analysis: map the way in and out of the system, view the system from the perspective of the attacker, understand the most vulnerable parts of the system, and need to focus on testing and review. It is part of design and part of risk management.
Priyanka Ranu says
Attack surface analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The main point is to understand the risk areas in an application and to find ways to minimize this. The first step is to identify and map the attack surface and review it from an attacker’s perspective. Read through the source code and identify different points of entry/exit. The next step is to measure and assess the attack surface, focusing on remote entry points. Once there is a baseline understanding of the attack surface, it can be used to identify and manage risks going forward as changes are made to the application.
Wenyao Ma says
Hi Priyanka,
I totally agree with you! I get a very similar understanding from “attack surface analysis”. I like that its purpose is to educate Web application developers on the areas of risk they need to focus on, which helps minimize the attack surface of an attacker.
Haozhe Lin says
I read all kinds of OWASP materials in the ITACS program, but this is my first exposure to attack surface analysis. This kind of deception is very helpful to understand more about the development aspect of the application, as well as the standard process of the review and testing of the security measures. Attack surface is the place where hackers can enter and obtain data. The attack process is divided into definition > identification > risk assessment > management. This analysis is very important, and as the scale of application increases, it will become more difficult to manage. My biggest reward is that if a very useful and successful application is developed and integrated with the existing system, the number of users will increase and the attack area will increase, resulting in more attack vectors and vulnerabilities. To make a long story short, this analysis looks like a lot of work done in technology. If an application is really attractive, it will never end. I think it is also necessary to note that this analysis should be carried out at the stage of development, and is often revisited, rather than waiting for the application to start.
Xinyi Zheng says
The OWASP Cheat Sheet Series was created to provide simple and pragmatic collection of doing Attack Surface Analysis and managing an application’s Attack Surface. Attack Surface Analysis is the process to identify what parts of a system need to be reviewed and tested for security vulnerabilities, and developers and security specialist can use this to reduce related risk. And the process of Attack Surface Analysis have several step: defining the attack surface of an application, identifying and mapping the attack surface, measuring and assessing the attack surface, and managing the attack surface.
Jonathan Castelli says
Mapping out the attack surface of the web application is extremely important in the risk identification process. Organizations must manage their attack surface and keep reviewing it over time as the attack surface grows. They need to be diligent with the management of the attack surface and make sure all risks are properly mitigated.
Krish Damany says
In an attack surface analysis, it’s imperative that the system is thoroughly tested for vulnerabilities that could occur. I believe the most important step in this process is defining the attack surface. When defining an attack surface, there are four important processes to take into account. First is to assess the sum of all paths going into and out of the application for data and commands. Second is to find the code that protects those paths. The third step is to find all the valuable data used in the application, which can include PII, secrets and keys, intellectual property, and critical business data. Lastly is to define the code that protects that data. Once defined, it makes it easy to assign roles and privilege levels for each level of the attack surface.
Mei X Wang says
The attack surface analysis cheat sheet simplifies the rundown on how we can understand the applications’ attack surface. It helps developers understand how to manage the application security risks in their design and changes implemented.
The analysis is used to help us:
– identify what functions/parts of the system need to be tested/reviewed for security vulnerabilities
– identify high-risk areas of code, that may need defense-in-depth protection, and what parts of the system needs to be defended
– identify when the attack surface has a change and needs to be reassessed for threats.
Cami Chen says
This cheat sheet helps us to understand and manage application security risk from the developer’s perspective and use it to implement a risk assessment. In order to understand how to use the attack surface analysis, we can identify the parts of the system, which we need to evaluate the vulnerabilities. When we identify the high risks, we will implement defense-in-depth protection to mitigate the risk to an acceptable level. We also need documentation for everything we have done, and then the documentation will help us to control some similar risks efficiently. Also, this cheat sheet provides a manageable solution based on function, design, and technology, including login/authentication entry points, admin interfaces, and business workflows.
Anthony Wong says
Attack surface analysis involves identifying all points of entry to the application whether it’s internal or external. Furthermore, it should be broken into separate groups such as all the API’s and databases it connects to or if it’s a web application with a login form. Vulnerability scanning and dynamic testing tools can be helped to perform the analysis. The more connections it has to other systems and services, the greater attack surface. The analysis helps reduce the attack surface and harden the system as much as possible to reduce the risk it poses to the organization. If there are any major changes after the analysis, it should be conducted again to identify how the attack surface has changed and if any new vulnerabilities have been introduced.
Humbert Amiani says
Hi Anthony,
I believe the hardest attacks surfaces to map out are internal attacks, since most organizations operate on a trust basis with their employees. It is not easy to figure out who is more likely to go rogue within the pool of employees. However, such attacks can be mitigated by ensuring that no single employee has access to every part of the system, especially controls.
Austin Mecca says
The important takeaway from this document is the task of identifying and mapping the attack surface. In any aspect of protection, you can only defend what you know needs to be defended, if you don’t have things on your radar that you should be protecting you are essentially asking for attackers to come after you. This section goes hand in hand with the NIST framework that focuses on categorization of assets. You need to take an inventory of all data and all assets and while doing this be as thorough as you can because attackers will find those low hanging fruit. There are also applications that can scan your system and let you know how many attacker surfaces you have within your organization.
Humbert Amiani says
Hi Austin,
As you pointed out, achieving system is a challenging task especially when dealing with security vulnerabilities that are oblivious to security professionals. They cannot afford to assume that all is secure because one thing that attackers have is time to find vulnerabilities in your system.
Kyuande Johnson says
Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities
Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this.
1. identify what functions and what parts of the system you need to review/test for security vulnerabilities
2. identify high risk areas of code that require defense-in-depth protection – what parts of the system that you need to defend
3. identify when you have changed the attack surface and need to do some kind of threat assessment
Vanessa Marin says
The OWASP cheat sheet series is intended for developers to consider and apply the OWASP standard as they develop web apps. It can also be used by risk analysts in their assessments. This cheat sheet in particular focuses on the Attack Surface excluding insider threats, users and operators of the system. The goal is for developers and security experts to:
– map the system for vulnerabilities.
– based on that what parts need to be proactively defended
– note the changes to the attack surface and re-assess.
The attack surface is
– the paths for data/commands
– code to protect the paths
– all data related to the application
– code that protects the data
The cheat sheet goes into further detail explaining how to identify and map, measure and assess, and finally how to manage the attack surface.
Zhen Li says
Attack Surface Analysis is targeted to be used by developers to understand and manage application security risks as they design and change an application, The focus here is on protecting an application from external attack – it does not take into account attacks on the users or operators of the system.
Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes.
Attack Surface Analysis helps you to firstly identify what functions and what parts of the system you need to review/test for security vulnerabilities. Secondly, identify high risk areas of code that require defense-in-depth protection – what parts of the system that you need to defend. Thirdly, identify when you have changed the attack surface and need to do some kind of threat assessment.
Heather Ergler says
I agree with your comment that attack surface analysis is about mapping ingress points for an application. I found it interesting that APIs were specifically called out in this and other readings in this section as most APIs have minimally a one time credential, a certificate and key associated to them. This gives an attacker several entry points by scooping up the credential with a sniffer or attacking the key if it is self signed and a standard Windows key generator is not used.
Junhan Hao says
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query.
Broken Authentication.
Sensitive Data Exposure. Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII.
XML External Entities (XXE). Many older or poorly configured XML processors evaluate external entity references within XML documents.
Broken Access Control. Restrictions on what authenticated users are allowed to do are often not properly enforced.
Security Misconfiguration. Security misconfiguration is the most commonly seen issue.
Cross-Site Scripting (XSS). XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript.
Insecure Deserialization. Insecure deserialization often leads to remote code execution.
Using Components with Known Vulnerabilities. Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application.
Insufficient Logging & Monitoring. Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data.
Anthony Messina says
This article was all about determining the attack surface (or possible vulnerabilities attackers could exploit) of an information system. The Attack Surface Analysis is about mapping out what parts of a system need to be reviewed and tested for security vulnerabilities. The point of Attack Surface Analysis is to understand the risk areas in an application, to make developers and security specialists aware of what parts of the application are open to attack, to find ways of minimizing this, and to notice when and how the Attack Surface changes and what this means from a risk perspective. The Attack Surface describes all of the different points where an attacker could get into a system, and where they could get data out. With this approach, you don’t need to understand every endpoint in order to understand the Attack Surface and the potential risk profile of a system. Instead, you can count the different general type of endpoints and the number of points of each type. You can also build up a picture of the Attack Surface by scanning the application. For web apps you can use a tool like the OWASP ZAP or Arachni or Skipfish or w3af or one of the many commercial dynamic testing and vulnerability scanning tools or services to crawl your app and map the parts of the application that are accessible over the web. Some web application firewalls (WAFs) may also be able to export a model of the application’s entry points.
Zhen Li says
Hi, Anthony, I agree with your point, and I also think the Attack Surface Analysis would helps organization to firstly identify what functions and what parts of the system they need to review/test for security vulnerabilities. Secondly, it also identify high risk areas of code that require defense-in-depth protection – what parts of the system that organization need to defend. Thirdly, it can identify when organization have changed the attack surface and need to do some kind of threat assessment.
Humbert Amiani says
Managing the attack surface is a vital step in mitigating the risks associated with the system. A lot goes into ensuring that one has a baseline understanding of the attack surface. Ranging from identifying the various vulnerabilities, possible attack vectors and adequacy in security measures in place. These aspects can then be used to create an outline of the attack surface and mapping out the attack surface to enable personnel have a better understanding of all possible risks associated with the system.
Without managing the attack surface, it is more cumbersome achieving optimum security for any system, therefore putting the system at risk. This is where we manage the risk and reduce it to residual risk hence ensuring that all possible loopholes are covered to the satisfaction of the organization.
Heather Ergler says
I took away from this reading a standard method for assessing the attack surface for an application, measuring and assessing the attack surface and managing the attack surface. In this reading as well as the others for this unit, there were common themes around integrations between the application being assessed or hardened and other applications. Typically these integrations come in the form of a file transfer or an API. I find this very interesting because with any file transfer or API there is a credential associated to the integration. Solid management and password rotation or key rotation becomes critical to managing the integrity of the integration and harden it as an entry point for attackers.