Spencer Smith is a Symantec Distinguished Engineer, supporting Symantec’s security solutions.
Spencer, how did you come to Symantec?
I came to Symantec in 2003 to work on core technology used in Symantec Endpoint Protection and Norton Internet Security. I started as an engineer, became an architect, and have since designed and built many of the core technologies used in our security products today.
What is your role today?
In my current role, I look across the portfolio to identify challenges and opportunities that apply to all of our products. In that capacity, I help ensure that each of the products in our portfolio is maintaining a high standard of excellence with regard to their Software Development Life Cycle (SDLC).
The code in our products runs within our customers’ environments and interacts with our customers’ data. Our first care must be to not cause harm to those environments or data. As such, the security of our supply chain and the robustness of our code and its ongoing monitoring, measurement and maintenance is a top priority.
I also work with each of our separate product teams in combination with our core efficacy team to ensure we leverage the capabilities of all of our products to provide best of breed protection and detection. Our products evaluate potential threats at several different control points, including gateway, email, and endpoint. Each of those control points has different visibility and different tolerance for aggressive protection. An endpoint, for example, may see a new threat and block it based on behavioral analysis. We can then begin detecting and blocking that threat at other control points before the threat is even allowed to run. As the capabilities of each control point develop and evolve, we are always working to expand the breadth and increase the speed of that intelligence sharing between those control points.
What does being an innovator mean to you?
Innovative ideas don’t come out of thin air. High value innovation always starts with a thorough understanding of the problem space. I have seen attempts at innovation fail because they were either solving a non-existent problem or were not solving the root of the problem. For me, innovation starts with learning about the threat landscape, learning about our customers’ constraints and learning about the distinct capabilities of each of our control points. With that background, it is much more likely that ideas will have a high value, lasting impact. True innovation isn’t just a curious idea, it solves a real problem.
Once you have an idea about how to solve a problem facing our customers, it is necessary to decide how the solution will be delivered. Our products have been around for a long time. Increasing functionality by simply adding a new driver or executable is not sustainable. Innovation is also required to determine how a feature will be delivered in the product, how it will be updated, how it will be maintained, and how its value can be measured. The ability to deliver technologies to a shared platform as a functionality “blade” is an ongoing effort that we have been evolving within Symantec for over a decade. New functionality must fit into a cohesive product. Failing to do that will invariably lead to performance and stability problems down the road.
What are some of the team’s innovations that you are most proud of?
Recent innovations that I am particularly proud of are the recent addition of Yara support and the development of our Adaptive Isolation technology.
Yara has been around for some time and custom detections through Yara has been a common request from our most sophisticated customers. The challenge we faced with including Yara in our product, though, was that we would be effectively combining three sets of externally produced content: the Yara engine itself, the Yara rules provided by the customer and the content being scanned. Simply dropping this functionality in without any guardrails would be an unacceptable risk. A newly discovered vulnerability in the Yara engine could result in our product being the vector of an attack. A poorly written Yara rule could render an endpoint unusable. To protect our product and our customer’s environments, we chose to wrap the Yara engine in our ‘CP3’ engine. This engine allows us to run untrusted content in a protected environment and then extract the result. We built the CP3 environment to allow us to run emulation scans on script, macros, and executable content. It was a short step to embed the Yara engine in the same CP3 wrapper to provide the ability to get custom detections without putting the integrity of the system at risk.
Our new Adaptive Isolation feature continues to reduce even further the attack surface available to malicious actors that began with the release of Adaptive Protection. Adaptive Isolation uses our threat intelligence to identify actors that may not be confirmed as malicious but are not yet trustworthy. Those actors are then prevented from modifying critical resources on the endpoint. If the actor is not malicious, then blocking this access will likely have no effect. However, if the attacker is malicious, Adaptive Isolation will provide another layer of protection on top of our other network, static, and behavioral protections already in place.
In general, we emphasize protection in depth at each control point and between control points. It is always preferable to block a threat as early as possible. We are realistic, though. There is no single layer of protection that will prevent all attacks. We continue to innovate by safely narrowing the threat surface, adding new layers of protection, and sharing data between each layer of protection. The recent addition of Yara allows us to provide best in class protection out of the box, customer aware protection through our Adaptive technologies together with customer provided detections using a single footprint.
We encourage you to share your thoughts on your favorite social platform.