Data Spill – An Everyday Threat to National Security

By Michael Waksman, CEO, Jetico Inc. Oy

Data has a frequent troublesome habit of residing somewhere it shouldn’t. In national security spaces, classified data can end up on unclassified or lower-level classification systems. This is known as a data spill.

Other terms to describe this type of event include classified spill, contamination, and classified message incident. But they all mean the same thing – classified data existing in a location where it is not authorized.

How do data spills happen?
Several scenarios can lead to a data spill. A file moved to the wrong location is an obvious common example. In that situation, either a person with clearance or an automated process with clearance moves a file from a classified system to a system with lower classification or no classification.

Accidental email distribution is another typical fault that leads to a data spill. Perhaps the wrong file was mistakenly attached to an email.

Or someone accidentally clicked ‘Reply all’ rather than ‘Reply’ in a thread.

In addition, mismarked files on servers improperly marked hard copies or media, and Department of Defense (DoD) classification changes can all lead to data spills.

What kind of data spills happen?

There are three main categories of data spills:

• Inadvertent If someone had no reason to believe their actions would lead to a data spill, it can be called inadvertent. Relying on improperly marked data for decision making is a typical cause for an inadvertent spill.
• Willful When an individual purposefully disregards procedures or policies and causes a data spill, this is considered willful. Intentionally bypassing security controls is an example of this.
• Negligent
  Somewhere between the previous categories is the negligent data spill that occurs when a person acts unreasonably and causes an unauthorized disclosure.

  This can happen through careless attention to detail or a reckless disregard for procedures.

Whichever the category, the outcome is the same – protected data has become vulnerable by sitting somewhere it should not.

Responding to a data spill
If an organization has respect for information technology and resources dedicated to IT security, there will most likely be a reaction plan in place should a data spill occur.

Most frequently, a Facility Security Officer (FSO), Information Assurance Manager and IT security personnel are all dedicated to the protection of data. It is their responsibility to mitigate and investigate data spills.

An appropriate response to a data spill most often takes three phases:

• Detection and reporting
  If you discover a data spill, you must report it immediately and take no action yourself on the data, including deletion or forwarding.
  DoD contractors can report to the Original Classification Authority (OCA), Information owner/originator, Information System Security Manager (ISSM), Activity Security Manager, or Responsible Computer Incident Response Center.
  For other industry reporting, contact the Facility Security Officer (FSO), the Information Systems Security Manager (ISSM), or the Information Systems Security Officer (ISSO).
• Risk assessment and containment Repair can begin now that the spill has been noticed and the appropriate authorities have been contacted. The authorities will tally the risks associated with the breach and will seek guidance from the data owner.
  Deletion or further spreading of the classified data is still prohibited during this phase, and the systems involved in the spill are usually isolated for that purpose.
• Clean up Specific clean up procedures vary between the DoD and cleared defense contractors, but most include software overwriting of affected data sectors.

Correcting the data spill can be a minor task or a massive undertaking depending on the sensitivity of the data, the level of clearance of the systems and the personnel involved, and the kind of contaminated storage media.

Wiping files or entire hard drives involved in a data spill
In the event of a data spill, all involved endpoints should be wiped. The wiping process can target selected files or entire disks. Either way, the software used during the cleanup phase should meet the following requirements:

• A minimum of three-cycle overwriting sanitization is required to be a complete wipe (different specifications can be required by different organizations).
  The first cycle writes a pattern, the second follows with the complement pattern, and the third and final cycle is a different, unclassified pattern.
• Random data reading for overwriting verification should be included in the software, although a separate utility can be used for verification.
• Printed results of wipe including disk integrity reporting need to be included in the wiping software. Bad sectors or blocks on a disk require that the disk be destroyed or degaussed.
• Whole disk wipes must be complete, including partition tables, user data, operating systems, and any boot records. They must also wipe Device Configuration Overlay (DCO) sectors if the disks are ATA-6. A whole disk wipe must also be able to clear a Host Protected Area (HPA).

Center for Development of Security Excellence. “Student Guide Data Spills Short”. [Online], Available: http://www.cdse.edu/multimedia/shorts/spills/common/cw/data/CDSE_DS_Student_Guide.pdf [28 June 2017].
Defense Security Service. “DSS ISFO Process Manual for C&A of Classified Systems under NISPOM”. August 15, 2010.

Defense Security Service. “Manual for the Certification and Accreditation of Classified Systems under the NISPOM, Version 3.2”. November 15, 2013. [Online], Available: http://www.dss.mil/documents/odaa/ODAA%20Process%20Manual%20Version%203.2.pdf [28 June 2017].

Environmental Protection Agency (EPA). “Spillage of Classified Information onto Unclassified Systems”. Environmental Protection Agency (EPA) Information Procedure, November 9, 2015. [Online], Available: https://www.epa.gov/sites/production/files/2015-09/documents/cio-2150-p-20-0.pdf [28 June 2017].
NIST. “IR-9 INFORMATION SPILLAGE RESPONSE”. NIST Special Publication 800-53 (Rev. 4). [Online], Available: https://nvd.nist.gov/800-53/Rev4/control/IR-9 [28 June 2017].

About The Author
Since 2008 Michael Waksman has been leading the growth of Finnish data protection software developer Jetico. Trusted for over 10 years by the U.S. Department of Defense, Jetico’s BCWipe can wipe selected files beyond forensic recovery such as in response to classified data spills, while BestCrypt delivers compliant data encryption software for whole disks, virtual drives, and selected files or folders.
Mr. Waksman is vice-chairman of the Cyber Group in AFDA, the Association of Finnish Defense and Aerospace Industries.
Recognized as a security and privacy advocate, Mr. Waksman contributes an annual blog for Data Privacy Day and National Cyber Security Awareness Month.
He is a frequent speaker at international events, occasionally on behalf of the Finnish cybersecurity industry.
A dual citizen of both the United States and Finland, he is a native New Yorker but has been living in Helsinki for over 10 years.
In 2012, Mr. Waksman was honored with The Security Network’s Chairman’s Award for fostering collaboration between the United States and Finland.
Michael Waksman can be reached at [email protected] or @JeticoSoftware and at our company website https://www.jetico.com/.