1.
Malware is not Magic
Thinking sanely about malicious code
Warning: This presentation contains generalizations,
opinions, and statements intended to provoke thoughtful
discussion. Listen at your own risk.
Steven Parker
V.P. Technology Research and Projects
Energy Sector Security Consortium, Inc. (EnergySec)
steve@energysec.org
EnergySec
TM

2.
Goals
• “...requirements, technologies, deployment and
management of grid systems that allow them to be
resilient in the face of large-scale malware threats.”
• “...designed, installed, operated, and maintained to
survive an intentional cyber assault with no loss of
critical function.”
• “...detect, prevent, deter, and mitigate the introduction,
exposure, and propagation of malware.”
EnergySec
TM

3.
Things we need to stop
doing
• Thinking of malware as a distinct problem
• Malware is a vector, not a threat
• Malware is, simply, an asynchronous human attack
• Treating the symptoms
• Epoxied USB ports
• Blocking “dangerous” file types
• Relying on technology that doesn’t work
• Signature based anti-virus
EnergySec
TM

4.
So, what should we do?
• Split the problem space
• Vulnerabilities vs. Abuse of privilege
• Security vs. Trustworthiness
• What could malware do in a “perfectly secure”
environment?
• Focus areas for improvement
• Layered OS defenses
• Improved detection
• Tools for trust
EnergySec
TM

5.
Defense in depth
Defense in depth is not just for networks and systems. It
can be applied to operating system design as well.
• User/Admin distinction is a start
• Type Enforcement (SE Linux)
• Application sand boxing (chroot)
• Application virtualization
• What’s next?
EnergySec
TM

6.
Detection and response
There’s no such thing as stealth malware. To be effective,
actions must be taken, and those actions can be seen if
systems are designed with appropriate telemetry. We
need:
• Thoughtful design of system and application logs
• Distributed and centralized logging and analysis
• Change management/system integrity tools
• Automated response where possible
• Manual response everywhere else (Yes. People!)
EnergySec
TM

7.
Tools for trust
Our routine use of electronic systems involves a
tremendous amount of trust, most of it unwarranted.
How do we ensure that:
• Code does only what the author(s) intended?
• Code does only what the user(s) intended?
• Our hardware is not compromised?
• Updates are not compromised?
• Malicious code is not embedded?
• We maintain an appropriate balance between integrity
(preventing undesired actions) and availability (allowing
required actions)?
EnergySec
TM

8.
In Summary
Malware does not introduce new vulnerabilities;
however, it does increase risk by allowing attacks to be
automated, asynchronous, autonomous, and anonymous.
System security, in the traditional sense, is essential, but
insufficient. Rigidity and flexibility are competing goals;
any system worth using will be vulnerable to some
degree. Therefore, malware may be preventable, but the
vaccine would likely be fatal. We cannot for design for
immunity, but should design for resiliency and
survivability.
EnergySec
TM