Home - Sophia Tool
Sponsor |
Description | Available Status |
Key Features |
Potential Application |
Use Cases |
Resources | FAQ
SPONSOR
Back to the Top
The Sophia project is sponsored by the Department of Energy Office of Electricity Delivery and Energy Reliability (DOE-OE) in support of the US government effort to support the energy sector industry developed Roadmap to Achieve Energy Delivery Systems Security. The DOE-OE National SCADA Test Bed Program funded this effort as part of a Control System Situational Awareness Technology research and development project.
Description
Back to the Top
Sophia is a passive, real time tool for interdevice communication discovery and monitoring of the active elements in a Supervisory Control and Data Acquisition (SCADA) system.
Sophia monitors network traffic and extracts the source, destination, and port sets (conversations) between SCADA components. These conversations are stored in real time to establish a list of conversations that are valid.
After the tool has been in place for a period of time, the user accepts this list as representative of the normal conversations expected from their SCADA system, and the list of conversations is established as a baseline fingerprint (whitelist) of accepted conversations.
After the fingerprint is accepted, Sophia continues to monitor and capture conversations and generates an alert on any conversation or device that is not a part of the system fingerprint.
The user then analyzes the alert with three choices:
- Add the alert source to the whitelist (fingerprint) - the conversation or device is valid
- Add the alert source to the blacklist - not required for system operation, always alert
- Do nothing, leave the alert source on the greylist - Analyze it later, but do not alert on any further occurrences.
Sophia software was developed based on an industry need. This need was identified during on-site cyber security assessments, discussions with users at various SCADA user group meetings and training sessions, and with an understanding of open source tools used in evaluating the cyber security footprint of a SCADA system.
The idea behind this tool's development was to identify concerns related to SCADA deployment by using the same techniques as cyber attackers and to encourage mitigation of those concerns.
Sophia (Greek for Wisdom) provides the user with the knowledge to make wise decisions that enhance the security and reliability of their SCADA system.
Based on asset owner feedback and Department of Energy Office of Electricity Delivery and Energy Reliability (DOE-OE) milestones, Sophia is slated for commercialization for wide scale production distribution by October 2012.
Available Status
Back to the Top
Beta test program: The Sophia Beta test was completed on December 31, 2012. Additional applications for Beta testers will no longer be accepted.
Planned product transition to industry is in progress.
Key Features
Back to the Top
- Passive, online, real time conversation analysis; no interaction with the SCADA system
- SCADA network traffic visualization in a 3-D graphical environment
- Safe to use in a production environment
- Works with new and legacy systems
- Ease of use - can be learned quickly
- Detects conversations and alerts on those that are not part of normal SCADA operations
- Fingerprint export for offline analysis
- Software hooks allow sharing fingerprint data with third party tools for offline analysis
- Provides full functionality for SCADA installations in the Energy sector.
Potential Applications
Back to the Top
- Network traffic anomaly detection and alerting
- Vulnerability and Red Team Assessments
- Test Beds for Cyber Security System Analysis and Testing
- Network Mapping Tools and Techniques
- Secure Network Design Consultation.
Use Cases
Back to the Top
- Configuration Management: Alert may indicate the addition of a new component or process, triggering a configuration management review
- Fielding New Systems: Use a fingerprint developed as part of the factory acceptance test (FAT) during the Site Acceptance Test (SAT) to identify required site specific communications
- Firewall Rule Validation/Development: The fingerprint represents only what is needed for SCADA operations, providing critical information necessary for simple quality firewall rules
- Switch and Router Configuration: Switches and routers can be configured based on what is needed as identified in the fingerprint. Port security such as Access Control Lists (ACL) are easily created and used
- Component Hardening: All necessary ports are identified in the fingerprint. All other ports are not required for operation and can be disabled or blocked by a personal firewall, reducing exposure to cyber attack
- Patch Testing: When used on a quality system, changes in normal operational communications will be quickly identified as patches are rolled out. In some cases patches re-open previously disabled ports and services
- If newly identified ports are required, Sophia provides useful information necessary for a safe rollout of the patch on the active control system. Configuration management issues are identified; firewall rules may need changing, ACLs may need updating, etc.
- Situational Awareness: Alerts provide online identification of abnormal events. These alerts could indicate a cyber attack, unauthorized access, hardware or software failures, new processes coming online, new equipment added, etc.
Resources
Back to the Top
Video Screencast presentations of Sophia in operation:
Documents/links describing Sophia:
FAQ
Back to the Top
- Our practice is to test and validate any new hardware/software components in our development systems network environment, prior to installing them in the production domain. Would it present a problem if we were to install the tool in that environment, do some preliminary testing, and then move it into the production network? If we used that progression, would the information "learned" in development be able to be built-upon in production, or would we expect to have to create a new baseline?
This is a legitimate and good use of Sophia. Ideally the development systems network will be as close to the real system as possible and in that case Sophia fingerprints should be nearly identical from a high level view. The only hurdle currently concerns IP address changes. Sophia uses IP addresses as a key part of its fingerprint. If the two networks do not use the same IP addresses then the fingerprint will not port easily. That being said if you choose to use Sophia as such the project will be happy to consider development of tools necessary to make it work.
- Will you provide a secure, encrypted upload facility for our use in transmitting any information that we need to send to the team at INL, and vice versa?
The project uses an INL-based Apache server running mediawiki and https to control access to Sophia. This method limits access to INL employees and beta testing members. If more restrictions are needed a better solution will be needed. The project is now using unfuddle.com to track bug reports. Sensitive material should never be uploaded to the unfuddle.com site. In general we should be able to resolve issues without transmitting your sensitive information.
- Will it be possible for us to use a remote access tool, such as X-windows, to view and manage the application and the server from an office environment, rather than "camping out" in the server room?
Yes, there are two clients to Sophia. The first is a command line application that provides raw access to the Sophia fingerprint. The second is a visualization application that can do a remote connection to the server in order to get the fingerprint and display it. When running the visualization app remotely, the only thing that is lost is the ability to display individual packets traversing between hosts. This would take a considerable amount of bandwidth and as such the project has not exposed that option yet. We also have a tester that is looking at using a VNC viewer to access the Sophia server, so that a Windows client could access the visualization app. There are concerns about using this in a production environment, but it seems to work in a test environment.