Tuesday, 5 February 2013
More Security Lessons Learned from the Y-12 Breach
clear
Our local newspaper, The Tennessean, recently ran a story on the Y-12 nuclear facility break-in last year.  The defendants are now scheduled for a May trial in the Eastern District Court of Tennessee.  This prompted me to review the Inspector General’s Y-12 security breach report  for lessons learned.  This report is one of the few published analyses of security breaches.  The other good examples I use come from court cases, where both sides’ arguments are heard by the court.  I believe that the observations from the IG report apply to security management in general.

So how did three people, average about 66 years, break through three fences to an enriched uranium facility?  Here are the summarized contributing factors:

1.    Poor response from the security officers on duty.  If you have outsourced security and are not testing the capabilities of your team, you may have surprises of this type.  Mock incidents should be staged to verify that such incidents are promptly and accurately detected.
2.    Poor maintenance of equipment.  A number of cameras were stationed to detect intruders.  They were either not functioning or not working at full capability.  If there is an application outage, it will be fixed according to defined user-based SLA’s.  Security capability should be maintained with similar written security SLA’s.
3.    Poor communications; when the trespassers banged on the wall of the security facility, security officers assumed they were maintenance workers.  No clear schedule for maintenance workers was communicated to them.  During the incident security officers communicated via cell phone, instead of by secure radio, as required by policy.  This again suggests that no testing of the incident response plan was carried out.

The biggest failure is that Y-12 did not test its incident response plan or operational security monitoring.  This would have highlighted shortcomings and hopefully led to corrective action.  Conclusion:  never trust a security control, unless it is regularly tested.  Trust but verify everything.
clear
Posted on 02/05/2013 9:57 AM by Frederick Scholl
clear