One key point that I learnt from this document is how attack surface analysis helps in terms of mitigating cyber risks. The attack surface is any part of an application where an attacker can get into and they get data. Attack surface analysis helps security professionals to:
• determine what parts of the application are vulnerable to attacks,
• Identify what parts of the code include high risks areas and requires defense-in-depth protection,
• Identify task required for threat assessment.
Also, managing attack surface is crucial, security professionals should manage risks and track new vulnerabilities so that they can reflect changes to attack surface analysis as they make change to the application.
Attack surface analysis of an application is way to understand the security risks that may exist within an application. By doing an attack surface analysis you begin to map out where a web application could have vulnerabilities. Understanding the attack surfaces enables you to better understand the risk associated with an application and how to best mitigate against those risks. This is then called managing the attack surface. Managing the attack surface also includes monitoring what changed with the application, if there are any new approaches like new technologies implemented with the application and then what holes may have opened since you last assessed the attack surface. It is important to continually review the application to ensure that the attack surface hasn’t drastically changed and that you have it protected.
As I read through your response to the OWASP’s Attack Surface Analysis Cheat Sheet, I began to develop a better comprehension of how the Attack Surface Analysis can be applied both during and after information system deployment. Since the Attack Surface Analysis Cheat Sheet does focus primarily on external threats, I would hope that an equivalent Cheat Sheet such as this also exists for assessing internal threats as well (although they generally follow the same principles).
The article provides steps of attack surface analysis. There are four steps which are
1) Define the attack surface of an application
2) Identifying and mapping the attack surface
3) Measuring and assessing the attack surface
4) Managing attack surface
One key point I picked from the reading is that security risk assessment is the key important step which organization should focus on because identifying appropriate risks allow organization to accurately define critical risks in the application and establish proper controls to protect systems.
A proper risk assessment is important, especially since there can be a high amount of attack points within the application. Being able to determine the severity of the risks can help prioritize what actions are needed to mitigate those risks while keeping security costs within reason.
The unique thing I learned about this week’s reading as regards to applications is that its much easier to gain root access through application exploits than through attacks on traditional operating systems and that this is also the most dominant attacking vector today. More so, application hardening is harder than operating system hardening. It’s also important to note that baselines are used when creating secure application program configurations, stuff like easy passwords and default passwords should not be used.
Keeping the attack surface as small as possible in the application/OS environment by reducing/evaluating different attack vectors.
1) Identifying and Mapping the Attack Surface (User interface (UI) forms and fields, HTTP headers, APIs, Files, Databases)
2) Measuring and Assessing the Attack Surface ( remote entry points, interfaces with outside systems and to the Internet, internet-facing code, sanitizing any entries of Web forms and other systems)
3) Managing the Attack Surface (what changed, manage risks going forward)
Hi Joseph, it’s interesting to see the tidbit that you felt was most important from the OSWAP cheat sheet. I think it goes without saying that as you decrease the attack “area” the more secure a system will be. In other words, if you limit the number of open ports, vulnerable machines, and shared credentials the probability of an attack will go down. Like you mentioned in the 3 steps, identifying/mapping, measuring/assessing, and managing the attacks are at crucial actions to mitigate the attack surface.
My understanding from this reading is that Attack Surface Analysis is useful in educating the web application developers to understand the key risk areas of an application and approaches to minimize this attack surface from external attack. After reading, it is clear the importance of including security components right from the development stage and providing application developers with secure coding practices. Also, another important factor to note is the iterative need for considering security of an application, since after making changes to the original code and adding security components, there will be new holes in the application which might provide new areas of risk.
I completely agree with you! I received a very similar understanding from the Attack Surface Analysis. I like that it is geared towards educating the web application developers on what risk areas need to be focused on, This helps give the chance in minimizing the attack surface level from attackers.
Hi Aksahy, You’re right, changes to session management, authentication and password management directly affect the attack surface. Also, changes to authorization and access control logic, especially adding or changing role definitions, adding admin users or admin functions with high privileges affects the affect surface.
The Attack Surface Analysis shows the parts of a system that needs reviewing and tested for vulnerabilities. It also shows developers what part of the application is a risk area and open to attack. I find this interesting because this gives a chance to try to find a way to lower the risk level in this area.
I also am intrigued at how the attack surface shows the different areas an attacker could retrieve personal information. It’s great that internally,,you are able to view all of this information to be able to find a solution before the actual event occurs.
Good points, Natalie. , It is necessary to perform some analysis and risk assessment as you add new user types or roles or privilege levels to the interface and integrate with other systems. Also, it’s helpful to reduce the size of the Attack Surface when you can by simplifying the model, turning off features and interfaces that are not in use, introducing operational controls like a Web Application Firewall and real-time application-specific attack detection.
My interesting take for this week is the section about measuring and assessing the attack surface. According the cheat shit, once you have a map of the attack surface, next is to identify the high-risk areas. It focuses on remote entry points that interfaces with outsides systems and to the internet and especially where the system allows anonymous public access. The thinks to take note in this implementation include;
• Network-facing, especially internet-facing code
• Web forms
• Files from outside of the network
• Backwards compatible interfaces with other systems
• Custom APIs
• Security code
Hi Percy,
I like that list those are all at risk entry points. Reducing the attack surface is no easy task but understanding the attack surface is just as important. If you don’t know where to look for attacks then the attacks will certainly get by you.
As I was reading through the Attack Surface Analysis Cheat Sheet publicized by OWASP, which talks about the risk areas of applications and mitigation strategies that need to be understood by both developers and application security specialists to protect from external threats, my understanding of what is included in an application’s attack surface was challenged. While I had initially understood that all entry points and paths to get into and manipulate the application are included in an attack surface, I had not considered including the exit points and paths out of the application that can be used to siphon data in an Attack Surface Analysis.
Good point. Attack surfaces are the sum of the different points where an unauthorized user can try to enter data to or extract data from an environment. Everything that is vulnerable counts towards to attack surfaces.
Defining the attack surface of an application is crucial as it determines all points of access and where data can be extracted. What I found interesting was how the total number of attack points can be some number over a thousand, so the different points are broken down into categories (like login, workflows, interfaces, etc.) in order to manage this more efficiently. It’s also important to identify where valuable information can be found within the application, since this is what an organization is most likely trying to protect at the end of the day.
You have correctly pointed out that organization should first understand where the most valuable information can be stored/processed during the working of the application. This step is traditionally carried out in the Risk Assessment stage, where IT Auditors can provide independent opinions to the web application architects, so that it can be helpful for them to narrow down the attack surface and put more efforts on securing key areas of risk.
The OSWAP Attack Service Cheat Sheet outlined very important steps to keeping an information asset secure. The first note, that I deem as most important, is “Defining the Attack Surface of an Application”. I believe that defining the attack surface is the most important for the Auditors or Admins to complete because if the specific vulnerability that an attacker will get through, the information asset will be one step closer to being protected. Specifically, the four steps that were set out for identifying the attack surface are very crucial. The first and most important step would be the paths that the code, responsible for the vulnerability, exploits. Whether that is an input field or a button, securing the compromised code is the most valuable measure.
One key thing I learned from the OWASP cheat sheet is that changes to session management, authentication and password management directly affect the attack surface, so do changes to authorization and access control logic, especially adding or changing role definitions, adding admin users or admin functions with high privileges. So, it is necessary to perform some analysis and risk assessment as you add new user types or roles or privilege levels to the interface and integrate with other systems. It is also helpful to reduce the size of the Attack Surface when you can by simplifying the model, turning off features and interfaces that are not in use, introducing operational controls like a Web Application Firewall and real-time application-specific attack detection.
You’re right. Managing the level of identity and authentication can be a great way to control the size of the attack plane. Firewall and other controls are used to optimize the attack surface with high risk. This can help the company good IT security and cost control.
The OWASP Attack Surface Cheat Sheet talks about defining, identifying, measuring, evaluating, and managing the Attack Surface of an application. An attack plane is a defined area of a software application that is vulnerable to attack. The management attack is to minimize these areas. The management method has many different indicators, such as SAP, relative attack surface (RAS) and so on.
The key takeaway for me from the article is how to measure and detect the attack surface. Ways to measure and detect are network-facing, web forms, files from outside of the network, backwards compatible interfaces with other systems, custom APIs and security code. In my opinion the most common way is backwards compatible interfaces with other systems. In China, most banking related systems are still Windows XP and Internet Explorer 8 or 9, as they are made a long time ago and replacing them will cost a lot. But newer PCs and Macs don’t come with those which result in backward incompatible and increase vulnerability.
One key point that I learnt from this document is how attack surface analysis helps in terms of mitigating cyber risks. The attack surface is any part of an application where an attacker can get into and they get data. Attack surface analysis helps security professionals to:
• determine what parts of the application are vulnerable to attacks,
• Identify what parts of the code include high risks areas and requires defense-in-depth protection,
• Identify task required for threat assessment.
Also, managing attack surface is crucial, security professionals should manage risks and track new vulnerabilities so that they can reflect changes to attack surface analysis as they make change to the application.
Attack surface analysis of an application is way to understand the security risks that may exist within an application. By doing an attack surface analysis you begin to map out where a web application could have vulnerabilities. Understanding the attack surfaces enables you to better understand the risk associated with an application and how to best mitigate against those risks. This is then called managing the attack surface. Managing the attack surface also includes monitoring what changed with the application, if there are any new approaches like new technologies implemented with the application and then what holes may have opened since you last assessed the attack surface. It is important to continually review the application to ensure that the attack surface hasn’t drastically changed and that you have it protected.
As I read through your response to the OWASP’s Attack Surface Analysis Cheat Sheet, I began to develop a better comprehension of how the Attack Surface Analysis can be applied both during and after information system deployment. Since the Attack Surface Analysis Cheat Sheet does focus primarily on external threats, I would hope that an equivalent Cheat Sheet such as this also exists for assessing internal threats as well (although they generally follow the same principles).
The article provides steps of attack surface analysis. There are four steps which are
1) Define the attack surface of an application
2) Identifying and mapping the attack surface
3) Measuring and assessing the attack surface
4) Managing attack surface
One key point I picked from the reading is that security risk assessment is the key important step which organization should focus on because identifying appropriate risks allow organization to accurately define critical risks in the application and establish proper controls to protect systems.
A proper risk assessment is important, especially since there can be a high amount of attack points within the application. Being able to determine the severity of the risks can help prioritize what actions are needed to mitigate those risks while keeping security costs within reason.
The unique thing I learned about this week’s reading as regards to applications is that its much easier to gain root access through application exploits than through attacks on traditional operating systems and that this is also the most dominant attacking vector today. More so, application hardening is harder than operating system hardening. It’s also important to note that baselines are used when creating secure application program configurations, stuff like easy passwords and default passwords should not be used.
Keeping the attack surface as small as possible in the application/OS environment by reducing/evaluating different attack vectors.
1) Identifying and Mapping the Attack Surface (User interface (UI) forms and fields, HTTP headers, APIs, Files, Databases)
2) Measuring and Assessing the Attack Surface ( remote entry points, interfaces with outside systems and to the Internet, internet-facing code, sanitizing any entries of Web forms and other systems)
3) Managing the Attack Surface (what changed, manage risks going forward)
Hi Joseph, it’s interesting to see the tidbit that you felt was most important from the OSWAP cheat sheet. I think it goes without saying that as you decrease the attack “area” the more secure a system will be. In other words, if you limit the number of open ports, vulnerable machines, and shared credentials the probability of an attack will go down. Like you mentioned in the 3 steps, identifying/mapping, measuring/assessing, and managing the attacks are at crucial actions to mitigate the attack surface.
My understanding from this reading is that Attack Surface Analysis is useful in educating the web application developers to understand the key risk areas of an application and approaches to minimize this attack surface from external attack. After reading, it is clear the importance of including security components right from the development stage and providing application developers with secure coding practices. Also, another important factor to note is the iterative need for considering security of an application, since after making changes to the original code and adding security components, there will be new holes in the application which might provide new areas of risk.
Hi Akshay,
I completely agree with you! I received a very similar understanding from the Attack Surface Analysis. I like that it is geared towards educating the web application developers on what risk areas need to be focused on, This helps give the chance in minimizing the attack surface level from attackers.
Best,
Natalie
Hi Aksahy, You’re right, changes to session management, authentication and password management directly affect the attack surface. Also, changes to authorization and access control logic, especially adding or changing role definitions, adding admin users or admin functions with high privileges affects the affect surface.
The Attack Surface Analysis shows the parts of a system that needs reviewing and tested for vulnerabilities. It also shows developers what part of the application is a risk area and open to attack. I find this interesting because this gives a chance to try to find a way to lower the risk level in this area.
I also am intrigued at how the attack surface shows the different areas an attacker could retrieve personal information. It’s great that internally,,you are able to view all of this information to be able to find a solution before the actual event occurs.
Good points, Natalie. , It is necessary to perform some analysis and risk assessment as you add new user types or roles or privilege levels to the interface and integrate with other systems. Also, it’s helpful to reduce the size of the Attack Surface when you can by simplifying the model, turning off features and interfaces that are not in use, introducing operational controls like a Web Application Firewall and real-time application-specific attack detection.
My interesting take for this week is the section about measuring and assessing the attack surface. According the cheat shit, once you have a map of the attack surface, next is to identify the high-risk areas. It focuses on remote entry points that interfaces with outsides systems and to the internet and especially where the system allows anonymous public access. The thinks to take note in this implementation include;
• Network-facing, especially internet-facing code
• Web forms
• Files from outside of the network
• Backwards compatible interfaces with other systems
• Custom APIs
• Security code
Hi Percy,
I like that list those are all at risk entry points. Reducing the attack surface is no easy task but understanding the attack surface is just as important. If you don’t know where to look for attacks then the attacks will certainly get by you.
As I was reading through the Attack Surface Analysis Cheat Sheet publicized by OWASP, which talks about the risk areas of applications and mitigation strategies that need to be understood by both developers and application security specialists to protect from external threats, my understanding of what is included in an application’s attack surface was challenged. While I had initially understood that all entry points and paths to get into and manipulate the application are included in an attack surface, I had not considered including the exit points and paths out of the application that can be used to siphon data in an Attack Surface Analysis.
Hi Imran,
Good point. Attack surfaces are the sum of the different points where an unauthorized user can try to enter data to or extract data from an environment. Everything that is vulnerable counts towards to attack surfaces.
Defining the attack surface of an application is crucial as it determines all points of access and where data can be extracted. What I found interesting was how the total number of attack points can be some number over a thousand, so the different points are broken down into categories (like login, workflows, interfaces, etc.) in order to manage this more efficiently. It’s also important to identify where valuable information can be found within the application, since this is what an organization is most likely trying to protect at the end of the day.
Hello Sarah,
You have correctly pointed out that organization should first understand where the most valuable information can be stored/processed during the working of the application. This step is traditionally carried out in the Risk Assessment stage, where IT Auditors can provide independent opinions to the web application architects, so that it can be helpful for them to narrow down the attack surface and put more efforts on securing key areas of risk.
The OSWAP Attack Service Cheat Sheet outlined very important steps to keeping an information asset secure. The first note, that I deem as most important, is “Defining the Attack Surface of an Application”. I believe that defining the attack surface is the most important for the Auditors or Admins to complete because if the specific vulnerability that an attacker will get through, the information asset will be one step closer to being protected. Specifically, the four steps that were set out for identifying the attack surface are very crucial. The first and most important step would be the paths that the code, responsible for the vulnerability, exploits. Whether that is an input field or a button, securing the compromised code is the most valuable measure.
One key thing I learned from the OWASP cheat sheet is that changes to session management, authentication and password management directly affect the attack surface, so do changes to authorization and access control logic, especially adding or changing role definitions, adding admin users or admin functions with high privileges. So, it is necessary to perform some analysis and risk assessment as you add new user types or roles or privilege levels to the interface and integrate with other systems. It is also helpful to reduce the size of the Attack Surface when you can by simplifying the model, turning off features and interfaces that are not in use, introducing operational controls like a Web Application Firewall and real-time application-specific attack detection.
You’re right. Managing the level of identity and authentication can be a great way to control the size of the attack plane. Firewall and other controls are used to optimize the attack surface with high risk. This can help the company good IT security and cost control.
The OWASP Attack Surface Cheat Sheet talks about defining, identifying, measuring, evaluating, and managing the Attack Surface of an application. An attack plane is a defined area of a software application that is vulnerable to attack. The management attack is to minimize these areas. The management method has many different indicators, such as SAP, relative attack surface (RAS) and so on.
The key takeaway for me from the article is how to measure and detect the attack surface. Ways to measure and detect are network-facing, web forms, files from outside of the network, backwards compatible interfaces with other systems, custom APIs and security code. In my opinion the most common way is backwards compatible interfaces with other systems. In China, most banking related systems are still Windows XP and Internet Explorer 8 or 9, as they are made a long time ago and replacing them will cost a lot. But newer PCs and Macs don’t come with those which result in backward incompatible and increase vulnerability.