An attack surface is a lot like a system vulnerability. So, performing an attack surface analysis is similar to a vulnerability scan
However, there is one key difference between the two terms. While vulnerability scanning is more focused on the settings of your physical equipment, an attack surface analysis looks at the software that your company uses and how hackers can exploit it.
The most tempting lure for any hacker is the data that your company holds. Loss of data would be a big problem for our business, whether intentionally destroyed or stolen. There are many entry points that hackers can exploit. However, the main avenue for access to data is through a piece of software. Therefore, you need to protect access to software that leads through to important data stores.
The attack surface
The starting point of attack surface analysis is to work out precisely what your attack surface is. As has already been explained, an attack surface relates to the software that you run and specifically that software that gives access to data stores.
The ability of software packages to exchange data and the spread of access rights in regimes such as single sign-on means that potentially your attack surface could spread very wide. The starting point for identifying an attack surface is the software that directly accesses data. So, you need to look at your databases and file stores and the software that manages them. After that, ripple out to all software that links through to those data stores. So, you are looking at ERPs, productivity software, and log management systems.
Those software packages that directly access data store form the heartland of your attack surface, and they are easy to spot. For example, the software package that you use to issue invoices has a direct connection through to a data store, as does your CRM system.
Web applications and mobile apps complicate the detection of the attack surface. Website and mobile apps are built with APIs, which provide a large set of out-of-the-box functions and save programmers from writing code. However, those APIs are often hosted, which means that part of your software is run on someone else’s server.
You have no control over how those external systems are protected, and you do not know what data from your system get transferred back and forth to those servers while the processing takes place. For an example of this, consider the shopping cart app that is embedded into eCommerce websites. This doesn’t run on the server that hosts the website, and it processes product details and purchase transactions.
Another extension to your attack surface comes from plug-ins and integrations. Again, these involve data being sent out from your primary software system to secondary programs without knowing exactly what information is exchanged, where it is processed, or how it is protected. Examples of this scenario are monitoring software packages that gain permission to access your software or even databases directly.
One more problem that makes your attack surface broader lies with mobile apps and user-owned devices (BYOD). You have no control over what other apps your system users install on their devices or what access those apps get to the device’s operating system, from which they could launch processes to reap data from the corporate apps installed on the device.
Extending further out from data-accessing software, you reach the operating systems of all of your equipment. At this point, your attack surface bumps up against vulnerability management. Firmware and operating systems are in the realm of vulnerability scanners, so this is the limit of your attack surface.
Issues such as the potential use of browsers for malware infection or data theft and the possible manipulation of services, such as PowerShell, are the remit of antimalware systems.
So, your attack surface fits into a broader landscape of threat detection strategies. The precise boundaries between the three main areas of software, services, and operating systems can overlap.
Attack surface analysis strategies
There are a few terms that apply to the attack surface. One is “digital attack surface,” or “digital footprint.” Another term is “external attack surface.” This shows two perspectives for attack surface analysis – the same as the methods used for vulnerability scanning – internal and external.
When you perform attack surface analysis, you can choose to look at how a hacker sitting in a faraway place can access your data stores through your software, which is the external approach. The internal process looks at how a user account can get to your data.
Internal attack surface analysis aims to block insider threats and hijacked accounts. An insider threat could derive from a disgruntled employee or a worker that has been duped into actions through phishing. Similarly, phishing can gain a hacker the login credentials of an authorized user.
The purpose of external attack surface analysis is to tighten up data leakage possibilities, such as the use of corporate data by external systems – this would mean APIs or managed services that process your data. Internal attack surface analysis focuses on access rights management.
The aim of attack surface analysis
The main aim of attack surface analysis is to identify ways better to control system weaknesses and the likelihood of an attack. Reducing your attack surface is one of the best strategies to achieve that aim.
An internal attack surface analysis should focus on user account management. You need to look at the user groups you have set up in your identity and access management system and work out how to define each better. Following on from that, you need to look at which user accounts belong to each group.
Backend accounts for automated processes are problematic. These extend your attack surface, and there is little that you can do about them. Blocking access to these secondary data accessing packages would prevent them from working effectively. However, you probably have a good reason to buy and install those packages, so you need to allow them to function.
The answer to secondary access is to ensure tight access controls for those packages as well. Suppose those software packages aren’t directly accessed by users but send data off elsewhere through automated processes. In that case, you have a further extension to your attack surface that needs to be deal with. This could also cross into external attack surface analysis.
An external attack surface analysis looks at all potential access points for hackers that lie outside your home network. This includes cloud services and APIs. The analysis first needs to identify all of those external functions and services and then investigate the types of data each handles.
The analysis needs to seek information about the security processes in place by the providers of those external services. Details of protection would include data encryption systems both for transfers and for storage. Access controls on users on the remote system should also be considered.
Third-party risk assessment systems can help with external attack surface analysis. To an extent, you have to rely on third-party service providers’ honesty and their reputation. Third-party risk assessment systems track data leak events at a list of service providers, making it easier to determine whether those cloud services represent a security weakness.
The evolution of attack surface analysis
Recent shifts in working practices have made external attack surface analysis more critical. The move to home-based workers in response to COVID limitation measures means that software packages that previously were only accessed within the home network now have to be provided in remote locations to serve telecommuters.
Web sales platforms have become more critical as they replace stores and physical customer service points. In response to bans on store openings, many businesses have made their customer service interfaces directly accessible by the general public rather than in-store employees. Thus, those systems have crossed over into the external attack surface.
Another consequence of the rush to provide self-service systems to keep businesses running without personal contact has increased the use of off-the-shelf Web solutions. This complicates the tracking of the software hosting in the external attack surface.
Implementing an attack surface analysis
Attack surface analysis requires specialist skills. Penetration testers traditionally perform it. A penetration tester, or “pen tester,” acts as a hacker and uses every means available to break into a system, just as a hacker would. System administrators and company insiders are usually unwilling to go to the lengths that a hacker would employ because they are reluctant to break the system or fully compromise their security.
Start with an eDiscovery process to identify each data store and categorize the sensitivity within it. This will result in several different sensitivity classifications in each location. Isolate the highest-rated data first and then track all of the access points to that data. Chain through all of the software that accesses that data to the software interacts with that frontline circle of software. Keep chaining back until there is no more data sharing.
Repeat that function for every classification of data in each data store. In each data flow, mark the boundary between internal and external systems.
Dealing with attack surface analysis results
When you have your full data access map, you can start to look at ways to reduce that attack surface. As explained above, deal with the internal attack surface through access rights management and third-party risk analysis for the external attack surface.
By being an insider, you have an advantage over hackers. A hacker will keep probing a range of potential entry points into your system through hardware exploits and software security weaknesses. That constant trial and error, working blind, can be very time-consuming. By chaining from the inside towards the boundary, you can better arrive at those potential entry points. You will find that it is almost impossible to close down data exchanges between your first line circle of software through to data exchanges. For example, if you shut down EDI transmissions, your entire payments system would be made inoperable.
Protect the boundary of your system from attack and then fine-tune access rights within your business. Educate users to reduce the dangers of account credential disclosure and monitor all data outflows through emails and USB devices to stop sensitive data from getting outside of your system.
You will find that attack surface analysis is a highly complex process, thanks to extensive external methods that most business systems now deploy. On top of that problem, you have the headache of preventing data loss once those system access points have been identified.
The total of current system complexities means that it is impossible to perform an attack surface analysis manually. You need attack surface monitoring tools to define your attack surface properly and then watch over activity at its entry points. You will also need to employ automated data loss prevention systems to protect the sensitive data in your system from being leaked or stolen.
L’article How to Perform an Attack Surface Analysis in 2021 est apparu en premier sur Comparitech.
0 Commentaires