Remember meForgot password?
    Log in with Twitter

article imageInterview: The consultant who discovered Cisco’s FTD Bug Special

By Tim Sandle     Sep 10, 2019 in Technology
A vulnerability in Cisco's Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to gain unauthorized read access to sensitive, private data. We speak to the man who discovered the issue.
This discovery shows how critical it is for businesses to test and verify new security tools before blindly trusting them to protect company data. New and interesting tools are developed every day, but organizations need to master the operations of basic tools before implementing new ones.
To discover more, Digital Journal spoke with Andrew Taylor, a senior architect of the technology practice at West Monroe Partners (a biz/tech consultancy).
Digital Journal: What is the story behind the vulnerability in Cisco's Firepower Threat Defense (FTD) Software?
Andrew Taylor: Cisco’s FTD platform is their new go-forward strategy for security appliances, on-track to replace their venerable ASA OS. Under the hood, it’s a co-existence of the ASA software, along with the Sourcefire IPS acquisition in 2013 and several other components to stitch that functionality together.
During normal operation and troubleshooting, operators usually must review each software stack separately, along with understating the tie-ins between them, since it’s a platform by acquisition rather than by design. I think that architecture lends itself to being more complex, which can ultimately lead to more bugs and security risks.
When this vulnerability was discovered, it wasn’t by extensive research or unrealistic configuration parameters. I think this is something that should have been discovered through basic integration testing with very typical traffic patterns.
DJ: How was the vulnerability discovered?
Taylor: During proactive scanning we noticed the Cisco FTD firewall was passing unintended traffic. Systems and services that were supposed to have access restrictions applied showed conflicting results from port scans. After recognizing the anomalous activity, we went through the process of determining what was happening and testing a few scenarios and narrowed it down to a repeatable set of conditions we could submit to Cisco.
After some initial vetting with Cisco engineers, it was clear the size and scope of the issue. We’re not a security research firm and deferred most of the investigation to Cisco.
DJ: What types of strategies should businesses be adopting?
Taylor: Organizations should take stock of their operational practices and adjust accordingly before looking for the next silver bullet to reduce security risk. Tools can help achieve those operational goals, but you must start with the right people and processes before adding anything else.
Enterprises need to work proactively — and continuously — to establish informed baselines and check for compliance against these baselines. It’s important that these continuous checks follow a regular and pre-determined cadence. Otherwise, they risk slipping through the cracks.
Automating baselines through processes and monitoring should be a primary focus for an IT team. While tools can have some very compelling features and bring value, understand how the environment would operate without them, and potential gaps that may bring.
DJ: Can new technologies help with monitoring and protection?
Taylor: An increasing amount of the IT stack can be automated, and that automation should go hand in hand with testing. Testing should go beyond ‘did the task complete’ and tie back to an operational baseline or sanity check. When standing up a new application stack, start with baselines that capture your expected conditions, and follow up frequently to update that monitoring based on events. Automation, hosted on prem or in the public cloud, should be scoped to change state, as well as update monitoring or protection parameters.
Public cloud providers especially can give you an almost overwhelming amount of telemetry and log data about your applications. Embrace and understand those capabilities, determine thresholds and test them. It’s unrealistic to anticipate every edge case but start with a few known failures or conditions that could be risky and build alerts to notify the appropriate teams. This could be as simple as monitoring for traffic on unexpected ports, or a large influx of traffic to specific endpoints. Not everything means there’s a breach but take those changes seriously to either update the monitoring model or investigate further.
DJ: How should businesses be altering their company culture?
Taylor: For enterprises, it’s understandable that getting a new project to go-live can leave teams fatigued to deal with immediate operations, but that post go-live time is often the most critical. Consider setting the project goal posts out a few weeks, beyond initial implementation and instead celebrate success once there is an understanding of consistent operations. In our engagements, we know that day one support can be more impactful and critical than the act of implementing or migrating services, that’s the end-user’s first impression.
Another culture shift is understanding that cybersecurity tools are not silver bullets to all risks. If a project is being led by a specific tool or tool selection process, seriously reconsider starting over and instead defining business risks and objectives. It can be challenging to deal with the pressure to reduce cybersecurity risk quickly, but making sure the effort is well spent and has organizational alignment is crucial.
More about Ciscos FTD Bug, Cisco, Cybersecurity, Cyberattack
More news from
Latest News
Top News