The Official (ISC)2 SSCP CBK Reference. Mike Wills

difference is in the methods. The sanitization methods are less physically destructive than disposal methods. For example, sanitizing nondigital media, such as paper documents, is accomplished by removing sensitive pages or entire sections or by redacting or obscuring specific text. In contrast, disposal of paper documents would entail cross-shredding, pulping, or burning the papers entirely. Sanitizing digital media, such as hard drives, would mean overwriting each sector and byte of the drive many times with random characters. (The NSA has been known to call this process zeroization, even though it doesn't actually recommend writing nothing but zeros to the media; this would risk a missed block or sector being completely readable.) Disposal of hard drives, in contrast, entails either degaussing the drive, physically abrading or chemically corroding the surface of the disk platters, or breaking the entire drive in a powerful shredder. Even when degaussed or abraded, disposal of sanitized media may be constrained by local laws, including any limitations on the search of trash disposal sites with or without a search warrant.

      NOTE Degaussing does not work on a solid-state drive (SSD) or optical disk.

Another slight difference you can see in the NIST verbiage is that sanitization is often a defense-in-depth approach to precede disposal and augment it as a security control. Imagine, for example, a scenario where a hard drive was not effectively destroyed by the organization's normal disposal method or was, for example, intercepted by a curious or malicious person in the chain of custody. Even if the drive wasn't destroyed but had been previously overwritten many times with random characters, it may still be unreadable, and the sanitization is a good mitigation for the failure in the disposal process.

      Having discussed the differences, what are the commonalities between sanitization and disposal? Essentially, everything else. The goal of both sanitization and disposal is to ensure that the data previously on the media is not readable or recoverable. They should both happen according to formal processes that review, approve, document, and verify the sanitization/disposal. In both cases, the methods and tools should be commensurate with the data stored on the media. This also includes the removal of external markings and labels.

      For both sanitization and disposal, the sensitivity of the data on the media should drive how rigorously you apply these processes and how thoroughly you control it procedurally. In some cases, also consider that it may be less expensive to apply the more stringent sanitization or disposal method to all media than to spend time separating them.

      Both sanitization and disposal use specific tools, whether software tools, grinder, shredder, degausser, etc. These tools need to be periodically tested to ensure they are effective and that the media/remnants cannot be read or restored.

      When storing and collecting media prior to sanitization or disposal, consider affording additional protection above and beyond normal media classification and marking. If there is a large quantity of nonsensitive information in one place, it can become more sensitive by aggregation.

       Media Disposal and Information Retention Must Match

      Almost every category of corporate or private-sector sensitive or classified information has to have a retention strategy defined for it, as part of keeping the organization compliant with a growing and sometimes bewildering body of law and potentially conflicting stakeholder interests. Make sure that your information library procedures, including the ones for destruction of information and disposal of media, match with those retention requirements. If they don't, you'll need help from senior management and the organization's legal team to find an acceptable solution.

IMPLEMENT SECURITY CONTROLS AND ASSESS COMPLIANCE

Although it seems a bit of an oversimplification to do so, you can characterize the world of information security controls (also known as risk mitigation controls) by their mix of physical, technical (or logical), and administrative elements. For example, a perimeter fence is both a physical investment in a control technology and its accompanying procedures for a periodic inspection, including “walking the fence line” by the security patrols and repairing damage by Mother Nature, vandals, or intrusion attempts. Technical or logical controls are the software and data settings, the jumper plugs or control switches, or other device or system configuration features that administrators use to get the software and hardware to implement a security control decision. Windows-based systems, for example, use software-defined data structures called group policy objects (GPOs) that apply logical rules to subjects and objects in the system to exert security control over their behavior. Most network devices are logically configured by interacting with their GUI, a built-in web page, or a command-line interpreter, to accomplish the technical configuration of that device so that it does its part in carrying out the organization's security policies.

      NOTE It's helpful to remember that a physical control interacts physically with the subject or object being controlled; technical and logical controls interact with data flows and signals being sent around the system as ways to control the logical behavior of software and hardware.

      Chapter 3 will focus on how you choose what mix of physical, logical, and administrative controls to build into your security architecture; here, we'll focus on them after you've installed them and declared them operational.

      Regardless of the type of control elements involved, compliance can be measured or assessed by the same set of techniques: review, audit, exercise, and operational evaluation. Help-desk trouble tickets, user complaints or suggestions, the “police blotter” or daily logs kept by your security teams, and many other sources of information should all be subject to review and audit. Performance metrics can also be adopted (preferably in automated ways) that can alert management when controls are not being used effectively, as indicated by increasing rates of incidents, error rates, problem reports, and end-user dissatisfaction with system usability and reliability. Don't forget to keep an eye on customer or client behavior and input: A decline in orders, transactions, or web page hits may be as much about the quality and price of your products as it is about the security (or lack thereof) of your information systems and practices, as seen by your customers.

      Technical Controls

In all cases, you should first have an administrative (people-facing) control document, such as a policy statement or a procedure, that provides the justification and the details you need to configure, operate, inspect, and update all of the technical settings that implement the electronic aspects of your security architecture. These include both the networks, servers, and endpoint technologies, such as software Group Policy Objects, parameter files, access control lists, or even jumper and patch panel settings. Also included are the programming, options, and controls for fire and safety alarm systems, motion detectors, entryway alarms, power conditioning, and environmental control systems. (Remember, it was through a maintenance back door in the heating, ventilation, and air conditioning systems that attackers were able to gain entry into Target's systems in 2013.)

      Two of the most common technical controls used in many security strategies are related to setting time limits on user activity. Session timeouts or inactivity lockouts can be implemented on an endpoint device level, on a per-user ID level, or by individual applications platforms, servers, or systems. They force a user to take a positive action to reconnect or renew a login (and go through some or all authentication factor steps) to continue, once their device, session, or use of that resource has been inactive for a specified period of time. This can be frustrating to users when they've come into a system via SSO authentication, gaining initial access to a set of resources and applications at the start of their workday but then having to repeatedly log back in again when they've let individual sessions with specific apps or servers go idle for too long. Session timeouts provide protection against the “lunchtime attack,” which got its name from an intruder being able to wander around an office building and find computers unattended but still logged into the system during lunch breaks. Device-level timeouts