As an application, Adobe Flash delivered rich experiences and games to people on the Internet. Since it was first released in 1996, it made games, animations, and other services possible through browsers. However, ask any security professional about Adobe Flash, and their response will be telling. According to CVE Details, more than 1000 security issues were discovered in Flash Player over the past fifteen years, and some of them were critical issues affecting millions.
Adobe regularly updated Flash over the course of its life, and in 2017 announced that it would remove support on the 31st of December 2020. With that date rapidly approaching, companies should be fully prepared for this.Adobe is set to remove support of Adobe Flash on the 31st December 2020. With that date rapidly approaching, companies need to be fully prepared says @Qualys. #ITAM Click To Tweet
At least, that’s the theory. In practice, Flash did more than run games in Internet browser sessions; it was used to power management tools for enterprise systems and applications, as well as ensuring that applications could run over multiple browsers consistently. Planning for end of life around Flash is therefore more involved than simply removing the plug-in from browsers.
To help, this article shares three steps for ensuring that your organization effectively manages the change and remains secure.
1. Know your status
The popularity of Flash over many years means that it’s still installed across many machines. From the heights of its popularity five years ago, when it could reach an estimated 1 billion devices and powered applications across Android and Facebook, today it’s not enabled by default and developers are encouraged to use other technologies such as HTML5. However, Flash remains in place for many organizations, either in their own internal applications or as embedded in other software tools.
Storage and IT management systems from companies like HPE and Hitachi Vantara use Flash within their middleware and management tools. These systems will have to be updated in order to carry on running, or risk potential problems. Getting visibility of these systems with Flash in place is therefore essential alongside any endpoints.
To prepare for this, start with knowing your current status – is Flash still installed on any endpoint devices that the company owns? If so, is it needed and what for? This will need collaboration between the IT asset management (ITAM) team and other departments to either access a list of current assets, or create that asset list in the first place.
Without this, it’s very difficult to prepare for any end of life software scenario. This has been made more difficult by the Coronavirus pandemic; currently, workers may be at home working on their home machines that have plug-ins like Flash installed, or may have corporate devices at home that are now pulling double duty as homework tools as well. Whatever the situation, getting an asset list in place that covers all assets – not just those on the corporate network – is the essential first step.Planning for end of life around Adobe Flash is more involved than simply removing the plug-in from browsers. This article by @Qualys explores. #ITAM #Adobe Click To Tweet
2. Prepare for unintended consequences
Once that asset list is completed, you should have a better picture of your current situation. Perhaps you only have Flash on a few endpoints and can ruthlessly remove it before December. If so, then congratulations.
Alternatively, you may have more Flash installs in place than you expected, or you may have a current application that still needs Flash. This will mean some change management planning is in order. For IT security teams, this will involve knowing what applications are involved, how critical they are and any mitigation plans that have to be implemented. In these circumstances, it’s not just visibility that is needed, but observability – this means being able to take data and use it to plan actions over time.
Tagging particular software assets can help here. By tracking specific software items like Flash and then using the asset list to help plan actions, you can make it easier to see how well any process is doing in meeting objectives. This data can also be used for other teams to see the progress through dashboards or other reporting.
For IT service management (ITSM) teams, looking at software implementations and current status will be required. This will involve looking at any software implementations and how they’ll handle the end of life. For example, a management app may receive an update before the end of the year to remove any dependency on Flash; in this case, implementing the update and checking that there are no problems caused. In this example, the potential impact is low and any change should go ahead as soon as is reasonable.
Alternatively, there may be no upgrade coming. This leads to a quandary – not moving will leave a potentially insecure software component installed, while moving to a new solution may involve a large capital expense. In these circumstances, it’s important to look at how any potential issue can be mitigated. For example, the management app may only need to connect to some internal systems, so external Internet access can be blocked as default. This should stop any casual attacks that would target issues, and provide time to plan any longer-term migration efforts.
For applications accessed by users, this may be more difficult. However, while Flash provides a useful runtime, it’s not the only plug-in that can be used in browsers, while functionality can be supported using standards like HTML5. This may therefore mean that systems may need to be updated or redeveloped. This kind of project can be hard to justify when it’s solely about fixing security issues. Instead, consider how any development work can add new functionality or support faster working practices as part of any move.
3. Support any major move around end of life software with effective collaboration
Any end of life project will need collaboration between teams in order to succeed. For service desk analysts, reporting on previous problems that were caused by the software can help show where there are issues. For Flash in particular, looking at security issues that had to be fixed or led to employee downtime can help build the case for migration. This can help the security team build up a fuller picture of why a problem has to be dealt with, rather than ignored. Tagging assets and using data to support those arguments can help.
During any migration or software update project, the service desk team can provide much needed communication services to employees about any change taking place. During any project like this, it’s worth spending time on how much to communicate out to the organization, and whether those activities should be active or passive.This article via @Qualys shares three steps for ensuring that your organization effectively manages the change around Adobe Flash end-of-life support, and remains secure. #ITAM #Adobe Click To Tweet
For bigger changes that might involve interruptions into how people work, it’s actually not possible to over-communicate – sharing information on changes before, during, and after any implementation is necessary. While dashboards and reports can be useful for sharing information, they should complement communication to users via official channels like email on the potential impacts that might occur.
After a change, there’ll still be problems that come up over time. The most common example will probably involve users with older and infrequently used applications that still rely on Flash. These should be discovered during any ITAM or application audits that take place, but may get missed due to only being used infrequently.
In these circumstances, service desk analysts should have a prepared process and script to go through with the user that can then provide results over to IT security. The details can then be used to plan around any response, from updating or replacing the application through to sandboxing the app so it can run in a more secure fashion.
For any end of life software project, the potential impact can be significant. Using asset management approaches like dynamic tagging can help improve the approach for specific and ubiquitous software like Flash, but the same principles can be applied to other issues like software vulnerabilities or other changes that are required and time-sensitive. In any eventuality, planning ahead across ITAM, ITSM, and security teams will be needed. This starts with awareness of the depth of the problem, but the next steps will depend on circumstances, costs, and priorities internally. With around six months to the official end of life date for Flash, collaboration will be essential to make this process simple and effective.
If you have any questions about, or opinions to add to, the above, then please let me know in the comments.