In addition to insomnia and lack of Star Trek reruns giving me reason to read through U.S. Government regulations, air travel provides another opportunity when I can peruse them. Several areas of the NIST 800-53Revision 4 draft continue to pique my curiosity. Today, it is System and Information Integrity control check SI-14: Non-Persistence.
SI-14 advocates minimizing the persistence mechanism by re-imaging a system, potentially on each re-boot,to minimize the length of time a compromised system is exposed to exploit. The concept is elegant; every time I log on to my system, my session is built from a read-only "gold image" greatly reducing the window of opportunity for an advanced attacker to penetrate deeper into the infrastructure. Using this approach, executables load from read-only sources ensuring that if the attacker injected malware into the running processes, those processes will load cleanly the next time.
If your environment adopts this approach, SI-14's recommendation may provide a safety net for recovering from successful attacks. Also, system reboots fix any undesired alterations by bringing up a good/ known state, SI-14's guidance may eliminate some IT problems with users that accidentally trash their environment.
I also see challenges:
- In my travels I have seen a significant number of organizations support a mobile or a distributed workforce, which makes administering master images extremely difficult. How do users get the read-only image? Would the difficulties in distributing and maintaining master images become such a burden that the IT groups would significantly delay system updates that may close vulnerabilities or correct execution bugs in the current code set? How will the organization address mobile users accessing IT resources through a VPN such that compromised systems do not provide the attacker easy entry?
- The SI-14 control advocates providing a limited window of opportunity for the APT to gain a permanent foothold in the environment. We know that one of the APT's early-stage goals entails compromising user credentials (recall Mandiant's 2012 M-Trends report that shows that 100% of the breaches we investigated involved compromised credentials). The APT typically starts the process of harvesting credentials in as quickly as five minutes after gaining access, giving them adequate time to compromise valid credentials within a typical eight hour work day.
- Not every system can be non-persistent. End-user data must be stored somewhere and the systems housing the data must get connected to the user's session when it starts up. This provides a vector for the APT to establish a persistent foothold.
- Finally, and most importantly in my mind, in the event of a successful attack, utilization of non-persistent sessions would eradicate evidence of the initial attack. The trail would be broken making it more difficult for forensic investigators to determine how the attacker penetrated the victim's defenses. This takes me back to the "don't re-image when you find malware until you've determined what it allowed the attacker to do" advice incident responders often give.
800-53 Revision 4's introduction of Control SI-14 - Non-Persistence describes an interesting approach to minimizing an environment's exposure to the APT, and I like how this control directly acknowledges the inevitability of breaches. However, organizations should not conclude that this strategy eliminates the need to explore systems for signs of compromise, and to forensically investigate potential breaches.
I am interested to hear about successes and challenges anyone has had with implementing non-persistent sessions as described in SI-14 of 800-53's Revision 4 draft. How the challenges are overcome in actual production enterprises would be another great topic of discussion!