As always, the primary ongoing assurance activity is the review of incidents conducted by the security program to determine if the program is efficiently and effectively protecting the scientific mission of the Laboratory. This ongoing review suggests that the program is functioning well and we continue to make adjustments to controls and policies as required by the environment.
1.0 Risks
1.1 Drive-by-download infections
Drive-by infections continue to generate the most damage at Berkeley Lab. However, the trend has decreased in the last trimester. Our existing mitigations (broad deployment of BigFix and isolating unpatched computers) continue to manage this risk to an acceptable level.
1.2 Continued Threats from Advanced Persistent Threat (APT)
This is an ongoing top risk, although we have not witnessed any significant activity in the last trimester.
1.3 Emergent Security Risks and Evolving Threats
Supervisory control and data acquisition systems (SCADA) have been of interest to cyber security for some time, although the actual risk is unknown or in some cases theoretical. SCADA covers systems that control processes that exist in the real world (versus software processes). Historically, SCADA systems were largely separate from the standard security threats because they often used proprietary protocols and were not online. However, as SCADA systems move online and use known protocols, they can open up new vulnerabilities that could result in attacks on physical systems (heating/cooling, water, etc).
The Cyber Team is working closely with the Bro development team to develop tools that can help us mitigate risks that may emerge from SCADA systems. One of the limits to defending against SCADA attacks is a lack of knowledge on how to analyze the protocols on which SCADA systems operate: How do they operate? What are normal usage patterns? A stronger understanding of how the systems operate allows you to detect anomalous behavior. As part of the project, we’ll use data feeds from LBNL SCADA systems to characterize usage patterns and then help develop detection algorithms.
2.0 LBNL Performance
2.1 Business Plan Performance
- New Border Router. We’ve acquired a new border router that will increase our blocking capacity from 100K to a million. Not only will this allow us to block new attacks, we’ll be able to tune our algorithms that were subject to capacity constraints.
- Communication and Outreach. We engaged both the broader cyber security community as well as our local user population by:
- Updating our website - the simplified structure should help users find the information they need more quickly. In addition, we introduced an Alerts feature that will better disseminate key information during a cyber event or vulnerability.
- Presented two talks at Educause’s cyber security conference
- Serving on the executive committee for NSM
- Automated processing of JC3 alerts. JC3 (DOE’s center for coordinating cyber information) publishes a number of alerts from a variety of sources. Processing these alerts, which are distributed via PDF, cost us about ten hours a week (.25 FTE). By automating this process, we saw greater consistency and speed of processing, reduction of manual labor, but also improved feedback - we have been able to improve the JC3 process by feeding back false positives. We shared this automation at NSM - DOE’s network security group.
- CPP Sensors. We are waiting to receive the package of documents that includes our data security terms. We sent our data security terms on March 25. The CPP sensor staff wanted to review it prior to attaching to the MOU and ISAs.
2.2 Audit: DOE Inspector General Audits
The Department of Energy’s Inspector General included Berkeley Lab in the following audits which are in process:
- FISCAM/Financial Reporting
- IT General & Application Controls
- IT Vulnerability Assessment (internal)
As always, we will consider any recommendations based on these audits in the context of our risk management approach and cost/benefit analysis.
We continue to make progress on our corrective action from our major FISMA audit last summer: Develop and implement a graded approach for web application input testing and ongoing review consistent with the Lab's risk management approach.
We’ve defined our graded approach (web servers open to the internet, business systems, other web servers) and rollout plan with the following project deliverables:
| Task | Status |
|---|---|
| Acquire tools (Netsparker and Burp) to enable manual scanning of web applications | Completed Oct 2012 |
| Setup and developing expertise in tools and results | Completed Nov 2012 |
| Scan all registered web servers with Netsparker | Completed April 2013 |
| Review and remediate appropriate results of registered web server scans | Summer 2013 |
| Credentialed scanning of selected Business Systems web applications | Summer 2013 |
We’ll consider the corrective action complete with the completion of credentialed scanning of selected business systems.
3.0 PEMP Goals, Objectives, Notable Outcomes
PEMP Objective 8.2 Notable Outcome to “To enhance our existing internal detection and response, LBNL will expand our intrusion detection system, Bro, to monitor key internal networks. This will increase the types and amount of information available to us about internal network activity allowing us to refine our responses to potentially malicious behavior on our internal network.”
Status: Complete
We completed our PEMP for FY13. This greatly increased our internal visibility on key subnets. Having a wide deployment of Bro internally will allow us to create new types of detection mechanisms that are optimized for the internal environment (e.g. to detect low and slow attacks) or that can be customized given the more narrow range of traffic types (e.g. restricted use of ports). It will also give us increased forensics to reconstruct an incident.
4.0 Noteworthy Accomplishments
The Cyber Team detected a number of infections at other .edus and provided them with information to help them mitigate the incidents.
